What key information was revealed in the official review of the Sui Testnet Wave 2?
Original Title: "What Key Information Was Revealed in the Official Review of Sui Testnet Wave 2?"
Original Author: Sui Foundation
Translated by: Babywhale, Foresight News
The Sui Testnet Wave 2 has successfully concluded, and this test has helped us achieve our goal of staking on Sui. The numerous activities on the network have given us more confidence that we have taken another crucial step in our journey to launch the mainnet. We are very grateful to everyone who participated and helped us make Sui better!
We learned a lot from Wave 2, and in the future, we will release a three-part blog series to review all the content in Wave 2. The first blog covers the network aspect, and the following articles will discuss Token economics and Frenemies game in more depth.
Statistics Snapshot
During Wave 2, the community collectively set multiple new records during a three-week, 33-epoch test.
Over 7000 nodes are connected to 41 validators.
169 million addresses
3650 million transactions (1.6 times the growth of Wave 1)
324 million NFTs
Published 118,614 contracts (45 times more than Wave 1).
Pledge 134,000 SUI
Processed 7.35 million staking operations.
Observed 67 TPS peak
Compared to the first three weeks of January, Sui Wallet's DAU increased by 2.2 times during Wave 2, reaching 171,000. The installation volume of Sui Wallet has increased by more than 3 times, reaching 333,000.
The Sui blockchain browser has achieved a historic high with 1 million page views and 571,000 unique visitors.
The Sui Discord community has over 600,000 members, making it one of the largest web3 communities in the world.
It is worth mentioning that four smart contracts processed over one million transactions during Wave 2, accounting for 40% of the total transaction volume in Wave 2.
Sui's system object ranks first, processing over 7.3 million transactions related to staking.
Frenemies game ranked second and completed over 3.5 million transactions in just five days of game time.
The third most active smart contract is 8192 game, with contract address 0x137aebf47cd16956b68633b6f6f00a992d87d9c6, which has processed over 2 million transactions.
The fourth most active smart contract is Sui Capys, with contract address 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93, processing 1.6 million transactions.
Congratulations to the community project 8192 game for breaking the one million transaction mark! Additionally, we would like to thank the community project Suiscan for providing Wave 2 data analysis.
These new records and levels of network activity enable us to identify important software updates and further collaborate with the validator and node operator communities to enhance our operational capabilities.
Worth noting network updates
Similar to Wave 1, Wave 2 aims to identify areas for improvement in the Sui infrastructure.
Handling large messages or transactions
Due to Wave 2's focus on staking, the network has experienced many staking and unstaking transactions, which has helped us improve our ability to handle large network messages and transactions. In particular, each pending staking and unstaking transaction generates an event during epoch change. This affects the transaction size of epoch change transactions, as each generated event is part of the transaction effect. In Wave 2, we saw up to 230,000 staking operations in one epoch, making the transaction effect of that epoch change very significant.
These large transactions will create many problems. If the epoch change transaction effect becomes too large to be downloaded through the network, the epoch change will fail. If the transaction has a greater impact than the maximum JSON RPC response, the transaction cannot be retrieved. Any application (such as Explorer) that attempts to load such large transactions may be at risk of crashing. Such large transactions may also be too expensive to compute, making it impossible for the network to handle. During Wave 2, our team had to raise some emergency restrictions to keep the network running smoothly when processing large numbers of transactions.
Regarding the above situation, we have accelerated the addition of protective size limits for objects, packages, and various transaction data (input parameters, transaction effects, events). These limitations will help ensure that storage, network, and computing resources are not overwhelmed by the super-large transaction platform on the main network.
More robust handling of transaction type parameter input
On February 1st, we discovered an error where if the Move module was specified as a transaction input in the type parameter, the transaction processing logic would not be able to correctly verify the dependencies of the Move module (i.e. whether the module to which the type belongs has been published). Since Move package publishing is done through Byzantine fault-tolerant broadcast fast path, some validators may learn about the published Move module before other validators and may disagree on the validity of transactions using this module in the type parameter. Such a transaction prevented the system from forming the next checkpoint, resulting in many full nodes stopping and validators forking the network. This was the main reason for the Wave 2 interruption in the early morning of February 1st.
In order to keep the testnet running in the event of invalid submitted transactions with module types, our team has implemented some emergency fixes:
- Always check if the module of the type parameter has been published.
- Invalid transactions allowed to fail and complete execution.
- Prevent further transactions with unpublished type parameters from being submitted.
Afterwards, we discovered the second error, which is that the transaction input check logic does not reject contracts that are not Move modules as inputs inserted into the type parameters. Because the type parameter must be a Move module, the transaction can never be completed, and the next checkpoint cannot be formed. Similarly, our team had to add an emergency fix to force problematic transactions to fail due to execution errors in order to restore the network.
We have added these two error fixes to Sui's codebase: Fix input object generation #7940.
Narwhal consensus mechanism delay improvement
Similar to Wave 1, the Wave 2 testnet provides a valuable opportunity to further test the Narwhal consensus with 41 decentralized validators. During Wave 2, we took the opportunity to optimize consensus delay reduction (submitting consensus in parallel to two validators, parallel certificate verification, min_header_delay parameter, one second min_header_delay). We continue to iterate on performance and will soon introduce more optimization plans.
值得注意的开发者经验教训
translates to
Valuable Lessons for Developers to Note
Although ensuring network stability is a top priority, our long-term goal is to make Sui the leading smart contract developer platform, where developers can create the best experience for Web3.x based on Sui. To achieve this, we also focus on the friction points between developers and users during Wave 2.
Token Management
During Wave 2, there were several factors that could lead users to encounter Token management issues. These issues typically manifest as errors indicating insufficient Gas fees, or a grayed-out staking button appearing even when the user appears to have sufficient SUI balance for the transaction.
Due to the active presence of Validator Game on the internet, the reference gas price may fluctuate and experience greater growth between each epoch than normal. The fluctuation of high gas prices may result in users not having enough value of a single token to pay for gas fees. Additionally, the initial reference gas price setting is higher than Devnet, which reduces the possibility of users holding multiple tokens and results in faster depletion of their coins. Finally, the staking operation essentially involves users delegating their existing SUI balance to one or more validators. However, the layout of SUI that users hold may not always match their expected staking operation.
We have increased the default faucet amount during the high reference Gas price;
We have resolved the SDK bug where Sui client selected a Gas object greater than gas_budget instead of gas_budget * gas_price;
Added basic Token management for Sui wallet staking. For each staking operation, we use paySui transactions to construct modules for staking and paying Gas respectively.
We plan to support programmable transactions soon, which will simplify application Token management.
Other gains from this round of testing
Every testnet of Wave is a combination of tension and excitement. We work with everyone in the Sui community with the intention of pushing the network's staking capabilities to the limit, and in this spirit, successfully strengthened Sui during Wave 2 of the testnet.
We greatly appreciate the active participation of the community, which helps generate high loads and discover issues. Our next milestone is to launch a permanent testnet for the developer community, which will no longer be temporary. We look forward to further collaboration at that time.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
