Sui founder's handwritten note: Using "taking the bus" as an example to illustrate Sui's performance advantages

Author: Evan Cheng, CEO and Co-founder of Mysten Labs

Source: https://twitter.com/EvanWeb3/status/1569414553322274818

Compiled by: Azuma, Odaily Planet Daily

Recently, there have been articles analyzing Sui in the market, but most of these articles have missed one crucial innovation — Sui's data model and transaction processing channel. I will explain this in three parts in the following tweets:

Part 1: Transaction Processing Channels in Traditional Blockchains

Part 2: Transaction Processing Channels in Sui

Part 3: Advantages of Sui

The operational logic of a blockchain is that, over time, validators collectively add new blocks to the chain. The transaction processing channel is at the forefront of the process of "building blocks — consensus — execution — updating the Merkle tree," meaning all transactions must be processed before they can continue downstream in this process. When a new block begins to be constructed, transaction processing is also paused.

Below is a diagram illustrating the transaction processing channel of traditional blockchains and its issues. We have seen many projects attempting to solve these problems using different methods.

Sui distinguishes and organizes data through "objects." An NFT, a token balance, a smart contract — these are all different objects (which can be understood as types), meaning that transactions on the Sui chain can be grouped and processed based on the different objects.

The following image is a simple example describing five different transactions that can be divided into three groups (we will return to discuss specific objects and shared objects later). These three groups of transactions can be processed in parallel.

In other traditional blockchains, all unrelated transactions within a single block must be processed sequentially. For example, if Bob sends a BAYC NFT to Bruce, Alice sends a Punk NFT to Alex, and Jane uses a DEX, all these transactions must be collectively ordered by consensus, executed, and ultimately reflected in the Merkle tree.

To put it simply, it's like taking a bus. In traditional blockchains, all passengers must queue (consensus) to board, each passenger must have their ticket checked before departure (execution), and then all must get off at the same location (Merkle tree update). Only when the bus is empty again can new passengers board, and the chain can continue to operate; whereas on Sui, the chain groups all passengers based on their destination (objects), checks the tickets of each group in parallel, and then sends them to their destinations using different vehicles in parallel.

Sui's innovation is not just in parallel processing of transactions (more on this will be shared in the future), but also that the results of transactions are submitted to the objects after execution (for example, if a token balance is 10, and 5 are sent, the remaining balance is 5), which can be immediately used as inputs for future transactions. Sui treats the Merkle tree as part of the checkpoint for newly created blocks, and accounting will only occur after a series of related transactions are finalized.

Additionally, it is important to note that in the previous example, some transactions correspond to a specific object, such as only Bob being able to initiate a transaction regarding his BAYC NFT. Transactions of specific objects can skip consensus (only Byzantine agreement broadcasting is needed) because the owner can confirm the transaction order.

For another type of transaction, namely shared object transactions (like DEX smart contracts), consensus must be reached because there is no single owner to determine the order. This is where our Narwhal & Bullshark consensus comes into play.

In simple terms, transactions of specific objects can be executed in parallel, while shared object transactions can also be executed in parallel among themselves, but transactions involving shared objects need to be executed in order (other static/dynamic techniques are applied here).

In summary, you can understand that:

• For conventional blockchains, all transactions need to be collectively ordered and then executed.

• For Sui, all transactions are distinguished and organized based on certain logic before being ordered and executed. The data model clarifies the dependencies between different transactions, where only shared object transactions need collective ordering, while specific object transactions do not require this consensus negotiation process.

So, what product issues can Sui's architecture solve? Let's continue to explore.

First is the ability for horizontal scalability. On Sui, each group of transactions is processed in parallel, just like each group of passengers takes different vehicles. Therefore, if there are more groups of passengers (transactions), Sui only needs to provide more vehicles. Regarding this, Sui can scale horizontally through internal validators — more workers to handle more transactions.

Why is the ability for horizontal scalability important? Think about the needs of some large projects when considering their underlying infrastructure; they need to ensure that the underlying system can support sustained growth in scale. A blockchain with performance limits will become a barrier for these projects. Sui's design is aimed at addressing such peak demands.

Second is composability. What is feasible on Sui that is not feasible on other smart contract platforms? For example, passing assets as parameters to functions, returning certain assets from functions, storing assets within a data structure, or directly storing them within another asset.

I may write a dedicated tweet about composability in the future, as it is a rather complex topic. I just want to say that Sui significantly enhances composability at both the contract level and the asset level (different types of objects can be nested within other objects).

Next is partial replayability. Blockchains provide a historical record of all transactions, which is helpful for checking past information. However, if a product needs to care about certain on-chain data, reading it can be very costly. Sui's architecture allows these projects to focus only on the evolution of the objects they care about, which is partial replay.

For example, an RPG game that places all characters on Sui can simply observe the objects representing these characters. They do not need to dig through all the data from the Merkle tree data structure.

Finally, there is on-chain storage. Various asset data, such as game races, levels, experience, etc., can be stored within Sui's objects. Sui can use traditional methods to expand on-chain storage, and the cost of updating on-chain assets is now much lower.

This long tweet comes to an end. These content dimensions are high but not very comprehensive. However, I hope you can deepen your understanding of Sui through this information.