Sui Lutris: Analysis of the Core Distributed System Protocol of the Sui Public Chain

Mysten Labs updated the Sui Lutris white paper on August 18, confirming the following important points after months of testing:

1. Sui can handle 140k to 150k operations per second when using PTBs and 5K TPS. This indicates that Sui's actual performance on the mainnet peak (around 700 TPS) is significantly higher than the benchmark results.

2. Even in the case where some validators stop running, the final confirmation delay of Sui can still be maintained at below 0.5 seconds.

The white paper details the operational mechanisms of Sui and provides security proofs along with guidance on how external testers can reproduce the relevant data.

After the launch of the Sui mainnet, it quickly attracted the development of applications such as games and NFTs. The recent Sui Lutris technical report released by Mysten Labs introduces a distributed system that supports Sui, which can achieve high throughput and long-term stability while maintaining low latency.

Since the birth of Bitcoin, blockchain technology has made significant progress, with emerging applications such as games and NFTs constantly appearing. The blockchain community has been working hard to improve technical efficiency, especially in handling high loads and real-time latency.

Currently, L1 blockchains face two major challenges: achieving high throughput on a low-latency basis while ensuring the long-term stability of the consensus protocol. These challenges can be addressed through the dynamic participation and configuration of validation nodes.

An effective way to achieve high throughput is to adopt DAG-based consensus protocols, such as Narwhal/Bullshark used by Sui. These protocols allow the blockchain to execute a large number of transactions simultaneously, making them very suitable for application scenarios like games and NFTs. However, DAG-based protocols may result in a few seconds of delay, which can significantly impact common transfer or gaming operations.

On the other hand, consensus-less protocols demonstrate great potential in reducing latency and scalability, as seen in the early research of the FastPay prototype. These protocols achieve fast transaction processing by eliminating consensus, without the need to order independent transactions that are processed in parallel. However, they are only applicable to a limited category of simple blockchain operations, which restricts the expressive power of smart contracts, and there are challenges in reconfiguring a dynamically changing set of validating nodes.

Although both protocols have potential, they are not yet widely used in production-grade blockchains. They have mainly been proposed at academic conferences and have not been widely adopted by the blockchain community. Sui Lutris, as the core protocol supporting the Sui network, cleverly combines DAG-based consensus and non-consensus methods, achieving the advantages of both: sub-second latency (less than 1 second) and sustained throughput of thousands of transactions per second. Sui not only achieves these two goals but also retains the ability to execute complex contracts on shared objects, generate checkpoints, and reconfigure the set of validating nodes across cycles.

Consensus and Non-Consensus Methods

Sui Lutris adopts a unique approach that combines the two strategies mentioned above. To ensure the security of single owner assets (unique objects) operation, the system uses a consistent broadcasting protocol among verification nodes to achieve latency below consensus. Sui Lutris relies solely on consensus to handle complex smart contracts running on shared objects, which can be modified by any user. Additionally, Sui Lutris supports network maintenance operations such as defining checkpoints and reconfiguring verification nodes. This innovative strategy provides a solution that balances the advantages of both sides when handling transactions in a replicated Byzantine environment.

The trading lifecycle of Sui Lutris is as follows:

1. Users create and sign transactions to modify the objects they own or change the combination of exclusive and shared objects.

2. Transactions are sent from the full node to each Sui Lutris validator node, which performs a series of validity and security checks, signs the transactions, and returns the signed transactions to the client.

3. The client collects responses from most validation nodes to form a transaction certificate. At this point, the transaction is confirmed as irreversible and achieves finality.

4. After the certificate integration is completed, it is sent back to all validation nodes, which check its validity and confirm receipt to the client. If the transaction involves exclusive objects, the transaction certificate can be processed and executed immediately, without waiting for the consensus engine (direct fast path). All certificates will be forwarded to the DAG-based consensus protocol.

5. The number of the consensus final output certificate, the verification node checks and executes the transaction containing the shared object.

6. Customers can collect the responses from most verification nodes and assemble them into a valid certificate to serve as proof of transaction settlement.

7. Subsequently, checkpoints are formed for each consensus submission, which can also be used to drive the reconfiguration protocol.

In addition to the main trading process, Sui Lutris also provides a range of facilities supporting product-level blockchain:

• Implement checkpoint protocol to generate historical records of all transactions in the system, applicable for complete audits and efficient synchronization of full nodes and lagging verification nodes.
• Supports reconfiguration at the end of each cycle, during which the set of validator nodes and their voting rights may change.
• Safely "unlock" assets that have been mistakenly locked at the end of the cycle, minimizing losses caused by errors.

Sui, as a blockchain that manages a large amount of value for users, Sui Lutris is its core foundation. The complete technical report provides more detailed information about the security and liveliness of the protocol operation, as well as the security proof of partial synchrony with Byzantine participants in the standard distributed system model.