Sui Network launches permanent testnet, learn about the important updates in one article.

The long-awaited ‘Sui permanent testnet’ has finally arrived! Unlike the previous Wave 1 and Wave 2 testnets, this version of the testnet will run for a long time, be decentralized, and permissionless, and it will continue to run after the mainnet launch.

With the launch of this version of the network, the community will benefit from some important feature updates.

Core Network

Dynamic validator set: Candidates who meet the staking requirements can join the network at epoch boundaries, and validators who have joined can leave the network at epoch boundaries. This validator node model truly achieves permissionless.

Protocol software and Sui Framework upgrade support: Unlike Devnet, Testnet will not be cleared every time the software is updated (unless in special circumstances). If there are planned software updates or data clears on the testnet, the community will be notified in advance.

Full node recovery from data snapshot: Node operators can use checkpoints to quickly start full nodes instead of waiting for full nodes to fully synchronize from scratch.

Address and signature updates: Account addresses, object IDs, and transaction IDs have been upgraded from 20 bytes to 32 bytes to avoid hash collisions. In addition, considering performance optimization, the default hash function has been updated from SHA3 to Blake2b. To support large-scale transactions, digital signatures now use hash signatures instead of serialized BCS data. This achieves compatibility between Sui and hardware wallets, where the signing API of hardware wallets typically has very limited input size.

To achieve the vision of making Sui the most friendly development platform, we view the permanent testnet as an important milestone and call it Sui DevX 1.0, with the following core developer primitives:

1.Collect developer feedback
2.Improve infrastructure to increase Sui developer efficiency
3.Realize a decentralized but not scattered Sui ecosystem

The development primitives include:

Programmable transaction blocks: This data structure can link a series of transactions together, including splitCoin, mergeCoins, transferObjects, moveCall, makeMoveVec, and publish, to create custom atomic transaction blocks that better meet the needs of applications. Therefore, moveCall can customize the call to existing on-chain functions, and programmable transaction blocks essentially provide transaction composability, enhancing the generality of the Sui Move programming model; it also simplifies gas fee management, and applications can pass in arrays of Coin Objects as gas fees and perform Coin splitting/merging in programmable transaction blocks without having to select Coins before submitting execution.

Sponsored transactions & gas station: Although sponsored transactions have been supported since the V0.27 version, we are pleased to announce that the Shinami gas station (guide, API) is now available on Sui’s permanent testnet!

Object Display Standard: Standardize the off-chain display of the same type of Object using a set of named template standards. Sui Explorer and Sui Wallet now support Object Display standards. Sui APIs and Typescript/Rust SDKs also support Object Display standards. This data structure was completed through multiple communications and joint writing efforts of the Sui community, and we would like to thank Capsules and OriginByte for their efforts in this standard.

Kiosk Standard: Kiosk is a powerful new module that supports listing for sale Objects and executing creator-defined royalty policies when Objects are sold. The combination of Object Display and Kiosk fills two key gaps in building collectibles and trading platforms on Sui. We encourage ecosystem wallets, browsers, and markets to explore Object Display and Kiosk standards to achieve seamless compatibility across the entire ecosystem.

RPC Revamp: There are now more aggregation-based RPC get* functions: getEpoch, getNetworkMetrics, getMoveCallMetrics, queryObjects. JSON RPC batch requests have been deprecated and replaced with MultiGet* methods. System events have been deprecated and replaced with dedicated fields in transaction responses. Finally, some legacy RPC functions (marked unsafe_*) have been deprecated and replaced with Programmable Transaction Blocks.

Zero-knowledge proof: The Move API now supports Groth16 ZKP verification using the BN254 elliptic curve and BLS12-381 (the two most widely used curves). This provides computing proofs in Sui smart contracts and supports privacy-preserving applications.

Two Granularity of Timestamps: A fine-grained Clock module that supports 2-3 second granularity for near real-time applications, as well as a coarse-grained Epoch timestamp.

Move Package Upgrade: This is a basic feature that allows developers to update Move contract dependency-related packages. Contract updates will be launched on the testnet in the next update (tentatively scheduled for the first week of April)! Please stay tuned!

In addition to using Devnet and Testnet, we also encourage developers to develop and iterate in local environments. The sui-test-validator binary has been improved to help with the local development process.

Devnet vs. Permanent Testnet

The table below lists the differences between Devnet and the permanent testnet

  • Devnet is a development-focused test network, while Permanent Testnet is a stable test network used for deploying actual applications.
  • Devnet’s nodes are operated by Mysten Labs, while Permanent Testnet has multiple validator nodes operated by different entities.
  • On Devnet, the number and hardware specifications of nodes can be changed at any time, while on Permanent Testnet, nodes and hardware specifications are limited.
  • On Devnet, there are no economic or financial implications, while transactions on Permanent Testnet are treated as real-world transactions and may have economic or financial implications.
  • Devnet’s data may be cleared or reset, while data on Permanent Testnet is persistent and can be used for testing and iteration.
  • Devnet is more convenient for fast development and testing, while Permanent Testnet is better for testing the performance and stability of actual applications.

What's your reaction?

Related Posts

Load More Posts Loading...No More Posts.