Testnet Wave 2 Recap - Network Learnings

Testnet Wave 2 concluded successfully and helped us achieve the goal of exercising staking operations on Sui. The tremendous amount of activity on the network gave us greater confidence that we have taken yet another crucial step in the journey towards Mainnet. We would like to give a huge thanks to all who participated and helped us make a better Sui!

Due to the incredible and extensive learnings from Wave 2, we’ll be publishing a three part blog series to recap everything from Wave 2. This first blog covers network learnings, while upcoming articles will discuss tokenomics and the Frenemies game in more depth.

Stats Snapshot

During Wave 2 the community achieved multiple new records together during this three week run, which spanned 33 epochs.

• Over 7,000 nodes connected to 41 validators
• 1.69 million addresses
• 36.5 million transactions (1.6x increase over Wave 1)
• 3.24 million NFTs
• 118,614 packages published (45x increase over Wave 1)
• 1.34 million SUI staked
• 7.35 million staking operations processed
• 67 peak TPS observed
• Sui Wallet DAU increased 2.2X to 171K during Wave 2 (when compared to the previous three weeks in January), Sui Wallet installs increased over 3X to 333K (when compared to the previous three weeks in January)
• New all-time highs for Sui Explorer with 1M page views and 571K unique visitors
• Over 600,000 members in the Sui Discord community, making it one of the largest web3 communities in the world

In particular, four smart contracts received well over 1 million transactions during Wave 2, and in total accounted for ~40% of all Wave 2 transactions:

1. Sui’s system object topped the list, handling over 7.3 million staking-related transactions.
2. The Frenemies game came in second, with over 3.5 million transactions in just five days of gameplay.
3. The third most active smart contract is the 8192 game, with the object ID 0x137aebf47cd16956b68633b6f6f00a992d87d9c6, which handled just over 2 million transactions.
4. The fourth most active smart contract is Sui Capys, object ID 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93, which came in with 1.6 million transactions.

Special congratulations to the 8192 community project for crossing the one million transaction mark! We would also like to express our gratitude to the Suiscan community project for providing Wave 2 analytics.

These new records and this new level of activity gave us the opportunity to identify material software improvements, as well as to further mature our operational muscle along with our validators and node operator community.

Notable Sui Network Learnings

Similar to Wave 1, Wave 2 was designed to stress and uncover improvements for Sui’s infrastructure.

Handling Excessively Large Messages or Transactions

As Wave 2 was focused on staking, the network experienced a high rate of staking and unstaking transactions that helped us push the boundary for handling large network messages and transactions. In particular, each pending stake delegation and un-delegation transaction generated an event during epoch change. This affects the transaction size of the epoch change transaction because every generated event is part of the transaction effect. During Wave 2 we saw a maximum of 230,000 staking operations during one epoch, and as a result the transaction effect of this epoch change became exceedingly large.

These extra large transactions create a number of problems. If the epoch change transaction effect becomes too large to be downloaded over the network, the epoch change will fail. If the transaction effect is larger than the max JSON RPC response, the transaction cannot be retrieved. Any apps, such as Explorer, that try to load such a large transaction may risk crashing. Such a large transaction can also be computationally too expensive for the network to process. During Wave 2 our team had to apply a number of emergency limit increases in order to keep the network operating with large transactions.

Thanks to these findings, we accelerated the addition of protective size limits for objects, packages, and various transaction data (input arguments, transaction effects, events). These limits will help ensure that storage, network, and computation resources are not overwhelmed by excessively large transactions at Mainnet.

More Robust Handling of Type Argument Input for Transactions

On February 1 we discovered a bug where, if a Move module is specified as a transaction input in type arguments, the transaction processing logic does not properly validate dependencies of the Move module (i.e. whether the module that the type belongs to has been published). Because Move package publishing happens via the Byzantine consistent broadcast fast path, it’s possible that some validators will become aware of a published Move module before others, and may disagree on the validity of a transaction using this module in a type argument. One such transaction prevented the system from forming the next checkpoint, and as a result led to a number of halted full nodes and forked (or diverged) validators. This was the main cause of Testnet Wave 2’s outage during the early morning hours of February 1.

To keep Testnet moving forward in the presence of a committed transaction with an invalid input module in type arguments, our team performed a number of emergency fixes:

• Always check that the module of a type argument is published
• Allow the committed invalid transaction to finish execution by failing
• Prevent further transactions with unpublished type arguments from being committed

We found a second bug where the transaction input checking logic does not reject object IDs that are not Move modules being inserted in the type arguments as input. Because type arguments must be Move modules, the transaction can never complete and the next checkpoint cannot be formed. Again, our team had to add emergency fixes to force the problematic transaction to fail with an execution error in order to recover the network.

A long-term fix for both bugs was added in the Sui repo as Fix input object generation #7940.

Narwhal Consensus Latency Improvements

Similar to Wave 1, Testnet Wave 2 provided a valuable opportunity to further characterize Narwhal consensus with 41 decentralized validators. During Wave 2 we took the opportunity to make several consensus latency-reduction optimizations (parallel consensus submission to two validators, parallel certificate verification, min_header_delay parameter, one second min_header_delay). We are continuously iterating on performance and have more optimizations planned soon.

Notable Developer Experience Learnings

While ensuring the stability of the network was a priority, our long-term goal is for Sui to become the premier smart contract developer platform from which builders can create optimal experiences for web3. To that end we also monitored developer and user friction points during Wave 2.

Coin Management

During Wave 2, several factors made it more likely for users to encounter coin management issues. These issues typically manifested as either an insufficient gas fee error or a grayed-out staking button appearing while the user seemingly holds a sufficient SUI balance for the transaction.

Due to the Validator Game being actively played on the network, it was possible for the reference gas prices to fluctuate and have larger-than-normal increases from epoch to epoch. Fluctuations to high gas prices could make it less likely for users to hold a single coin with a high enough value for gas fees. Secondly, the initial reference gas price was set to a higher number than on Devnet, making it less likely for users to have multiple coins and quicker to exhaust coins. Lastly, staking operations by nature involve users delegating their existing SUI balance to one or more validators. However, the coin layout of the user’s SUI balance may not always match their intended staking operation.

A number of changes were made during Wave 2 to mitigate the situation:

• We raised the default faucet amount during periods of high reference gas price
• We addressed a bug in the SDK where the Sui client selects a gas object that is larger than gas_budget rather than gas_budget * gas_price
• Basic coin management was added for Sui Wallet staking, where for each staking operation, a paySui transaction was used to construct a staking coin for delegation and a gas coin to fund the delegation.

Soon we plan to support Programmable Transactions, which will simplify coin management for applications. Please stay tuned!

More Testnet Success

Each Testnet Wave delivers a combination of trepidation and excitement. In partnership with everyone in the Sui community, we deliberately pushed the network’s staking capability to its limits, and in that spirit successfully strengthened Sui during Testnet Wave 2.

We would like to give a huge thanks to the community for their phenomenal participation, which helped generate load and uncover issues. Our next milestone is to launch a permanent testnet for the builder community that will no longer be transient, and we look forward to further collaboration at that time.

And stay tuned for two more articles describing our Testnet Wave 2 learnings!