Sui測試網Wave 2官方回顧透露了哪些關鍵資訊？

Sui 測試網 Wave 2 已圓滿結束，本次測試幫助我們實現了在 Sui 上進行質押操作的目標。網路上的大量活動讓我們更有信心地認為我們在上線主網的旅程中又邁出了關鍵一步。非常感謝所有參與並幫助我們讓 Sui 變得更好的人！

我們從 Wave 2 中學到了很多，未來將發布一個由三部分組成的部落格系列來回顧 Wave 2 中的所有內容。第一篇部落格涵蓋網路方面，而接下來的文章將更深入地討論 Token 經濟學和 Frenemies game。

統計快照

在 Wave 2 期間，社區在三周，33 個 epoch 的測試中共同創造了多項新記錄。

超過 7000 個節點連接到 41 個驗證器 

169 萬個地址

3650 萬筆交易（比 Wave 1 增長 1.6 倍）

324 萬枚 NFT

發布了 118,614 份合約（比 Wave 1 增長了 45 倍）

質押 134 萬枚 SUI

處理了 735 萬次質押操作

觀察到 67 次 TPS 峰值

與 1 月份的前三周相比，Sui 錢包 DAU 在 Wave 2 期間增長了 2.2 倍，達到 17.1 萬，Sui 錢包的安裝量增長了 3 倍以上，達到 33.3 萬

Sui 區塊瀏覽器擁有 100 萬頁面瀏覽量和 57.1 萬獨立訪問者，創下歷史新高

Sui Discord 社區擁有超過 60 萬名成員，使其成為世界上最大的 web3 社區之一

需要特別提到的是，有四個智能合約在 Wave 2 期間處理了超過 100 萬筆交易，總共占 Wave 2 總交易量的 40%：

Sui 的系統對象位居榜首，處理了超過 730 萬筆與質押相關的交易。

Frenemies game 位居第二，在短短五天的遊戲時間內就完成了超過 350 萬筆交易。

第三個最活躍的智能合約是 8192 game，合約為 0x137aebf47cd16956b68633b6f6f00a992d87d9c6，處理了超過 200 萬筆交易。

第四活躍的智能合約是 Sui Capys，合約為 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93，處理了 160 萬筆交易。

特別祝賀突破百萬交易大關的社區項目 8192 game！此外也感謝用於提供 Wave 2 數據分析的社區項目 Suiscan。 

這些新記錄和網路活動水平使我們可以確定重要的軟體更新，並進一步與驗證者和節點營運商社區合作提高我們的營運能力。

值得關注的網路更新

與 Wave 1 類似，Wave 2 旨在發現 Sui 基礎設施上需要改進的方面。 

處理大型消息或交易

由於 Wave 2 專注於質押，網路經歷了很多的質押和取消質押交易，這幫助我們提高了處理大型網路消息和交易的能力。特別是，每個未決的質押委託和取消委託交易都會在 epoch change 期間生成一個事件。這會影響 epoch change 交易的交易大小，因為每個生成的事件都是交易效果的一部分。在 Wave 2 中，我們在一個 epoch 中看到了最多 23 萬次質押操作，因此該 epoch change 的交易效應變得非常大。  

這些超大交易會產生許多問題。如果 epoch change 交易效果變得太大而無法通過網路下載，epoch change 將失敗。如果交易影響大於最大 JSON RPC 響應，則無法檢索交易。任何嘗試加載如此大的交易的應用程序（例如 Explorer）都可能有崩潰的風險。如此大的交易在計算上也可能過於昂貴，以至於網路無法處理。在 Wave 2 期間，我們的團隊不得不提升了一些緊急限制，以保持網路在處理大量交易時正常運行。           

針對以上情況，我們加快了對對象（object）、包（package）和各種交易數據（輸入參數、交易效果、事件）的保護性大小限制的添加。這些限制將有助於確保儲存、網路和計算資源不會被主網上的超大交易平台淹沒。

更穩健地處理交易的類型參數輸入

2 月 1 日，我們發現了一個錯誤，如果將 Move 模塊指定為類型參數中的交易輸入，則交易處理邏輯無法正確驗證 Move 模塊的依賴項（即該類型所屬的模塊是否已發布）。由於 Move 包發布是通過拜占庭一致性廣播快速路徑進行的，因此某些驗證器可能會先於其他驗證器了解已發布的 Move 模塊，並且可能不同意在類型參數中使用此模塊的交易的有效性。一個這樣的交易阻止了系統形成下一個檢查點，結果導致許多全節點停止以及驗證器分叉網路。這是 2 月 1 日凌晨 Wave 2 中斷的主要原因。   

為了在存在類型參數中輸入模塊無效的已提交交易的情況下保持測試網運行，我們的團隊執行了一些緊急修復：

- 始終檢查類型參數的模塊是否已發布；

- 允許提交的無效交易通過失敗完成執行；

- 防止提交具有未發布類型參數的進一步交易 。

之後我們發現了第二個錯誤，即交易輸入檢查邏輯不拒絕將不是 Move 模塊的合約作為輸入插入到類型參數中。因為類型參數必須是 Move 模塊，所以交易永遠無法完成，也無法形成下一個檢查點。同樣，我們的團隊不得不添加緊急修復程序以強制有問題的交易因執行錯誤而失敗，以便恢復網路。 

我們在 Sui 的代碼庫中添加了這兩個錯誤的修複方案：修復輸入對象生成 #7940。

Narwhal 共識機制延遲改進

與 Wave 1 類似，測試網 Wave 2 提供了可以進一步測試具有 41 個去中心化驗證器的 Narwhal 共識的寶貴機會。在 Wave 2 期間，我們藉此機會進行了幾項共識的延遲減少優化（向兩個驗證者並行提交共識、並行證書驗證、min_header_delay 參數、一秒的 min_header_delay）。我們不斷迭代性能並將很快推出更多優化計劃。 

值得注意的開發者經驗教訓

雖然確保網路的穩定性是當務之急，但我們的長期目標是讓 Sui 成為首屈一指的智能合約開發者平台，開發者可以基於 Sui 為 Web3.x 創造最佳的體驗。為此，我們還在 Wave 2 期間關注了開發人員和用戶的摩擦點。

Token管理

在 Wave 2 期間，有幾個因素使用戶有可能遇到 Token 管理問題。這些問題通常表現為 Gas 費用不足的錯誤，或者在用戶似乎持有足夠的 SUI 餘額進行交易時出現灰色的質押按鈕。 

因為 Validator Game 在網路上的活躍，參考 Gas 價格可能會波動，並且在每個 epoch 之間都有比正常情況更大的增長。高 Gas 價格的波動可能會使用戶持有的單一 Token 價值不夠用來支付 Gas 費用。其次，初始參考 Gas 價格設置的比 Devnet 更高，這樣用戶持有多種 Token 的可能性更小，用完幣的速度也更快。最後，質押操作本質上涉及用戶將其現有 SUI 餘額委託給一個或多個驗證器。然而，用戶持有的 SUI 的布局可能並不總是與他們預期的質押操作相匹配。

我們在 Wave 2 期間進行了一些更改以緩解這種情況： 

我們在高參考 Gas 價格期間提高了默認 faucet 數量；

我們已解決 Sui 客戶端選擇大於 gas_budget 而不是 gas_budget * gas_price 的 Gas 對象的 SDK bug；

為 Sui 錢包質押添加了基本 Token 管理。其中，對於每個質押操作，我們使用 paySui 交易構建了分別用於質押和支付 Gas 的模塊。

我們計劃很快支持可編程交易，這將簡化應用程序 Token 管理。

本輪測試的其他收穫

每個測試網 Wave 都是緊張和興奮的結合。我們與 Sui 社區的每個人合作，有意將網路的質押能力推向極限，並本着這種精神在測試網 Wave 2 期間成功地加強了 Sui。

我們非常感謝社區的積極參與，這有助於產生高負載並發現問題。我們的下一個里程碑是為開發者社區啟動一個永久性測試網，該測試網將不再是臨時性的，我們期待屆時進一步合作。

原文連結