Translator: Odaily Azuma
In the past period of time, there have been articles analyzing Sui on the market, but most of these articles have missed one of the most critical innovations - Sui's data model and transaction processing channel. I will explain this in three parts in the next tweet:
Part1: Transaction processing channel of traditional blockchain
Part2: Sui's transaction processing channel
Part3: Advantages of Sui
The logic of the operation of the blockchain is that over time, validators will 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", and all transactions must be processed before proceeding downstream of the process. And when a new block starts to be built, the processing of transactions will also be suspended.
The following is a schematic diagram of the transaction processing channel and its problems in the traditional blockchain. We have seen many projects trying to solve these problems in different ways.
Sui's approach is to distinguish and organize data through "objects". A certain NFT, a certain token balance, and a certain smart contract are all different objects (which can be understood as types), which means that transactions on the Sui chain can be grouped and processed according to different objects.
The diagram below is a simple example depicting 5 different transactions that can be divided into 3 groups (we will come back to 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 need to be processed sequentially. For example, Bob sent a BAYC NFT to Bruce, Alice sent a Punk NFT to Alex, Jane used a certain DEX, etc. All these transactions need to be collectively sorted and executed according to the consensus, and finally displayed on the Merkle tree.
To use an analogy, it's like taking a bus.On the traditional blockchain, all passengers must line up (consensus) to get on the bus, each passenger needs to check the ticket before departure (execution), and then get off at the same place (Merkel tree update), only when the bus Only after the car is empty again can it continue to accommodate new passengers, and the chain can continue to run forward; on top of Sui, the chain will group all passengers according to the destination (object), and the tickets of each group of passengers will be checked in parallel, and then by Different vehicles are sent to the destination in parallel.
Sui's innovation is not only in the parallel processing of transactions (about this, we will share more in the future), the transaction results will also be submitted to the object after execution (for example, a token with a balance of 10, sent 5, 5) remaining in the balance, they can be used immediately as input for future transactions. Sui uses the Merkle tree as part of the checkpoint for new blocks, which will not be recorded until a series of related transactions are finalized.
In addition, it should be noted that in the previous cases, some transactions only correspond to a specific object, for example, only Bob can initiate transactions on the BAYC NFT he owns. Transactions of a specific object class can skip consensus (requiring only Byzantine consensus broadcast), since the owner can confirm the order of transactions.
For another type of transaction, the so-called shared object transactions (such as DEX smart contracts), it must be agreed, because there is no single owner to determine the order. This is where our Narwhal & Bullshark consensus comes in.
Simply put,Specific object-type transactions can be executed in parallel, and shared object-type transactions can also be executed in parallel with each other, but each shared object needs to be executed sequentially (other static/dynamic technologies are applied here).
All in all, you can understand it as:
For a regular blockchain, all transactions need to be sorted collectively and then executed.
For Sui, all transactions will be distinguished, sorted and sorted according to a certain logic, and then executed. The data model can make the dependencies between different transactions clearer. Only the transactions of shared objects need to be sorted collectively, and the transactions of specific objects do not need this consensus negotiation process.
So, what product problems can this architecture of Sui solve? Let's move on.
The first is the ability to scale horizontally.On top of Sui, each group of transactions is processed in parallel, which is like the above mentioned that each group of passengers will take a different car, so if there are more groups of passengers (transactions), Sui only needs to be equipped with more cars . In this regard, Sui can be sharded and scaled through internal validators - more workers to process more transactions.
Why is the ability to scale horizontally important? Think about the needs of some large-scale projects when considering the bottom layer. They need to ensure that the bottom layer can carry their continuous growth in scale. Blockchains with upper performance limits will become an obstacle for these projects to settle in. Sui is designed to deal with this Peak demand.
The second is composability.What is possible on Sui but not on other smart contract platforms? For example, passing an asset as a parameter to a function, such as returning an asset from a function, or storing an asset in a data structure, or directly in another asset.
I'll probably write another tweet about composability in the future, as it's a rather complex topic. Suffice it to say that Sui significantly improves composability both at the contract level and at the asset level (different types of objects can be nested within other objects).
and thenAbility to partially replay. Blockchain provides a history of all transactions, which is helpful for checking past information. However, if a product needs to care about some on-chain data, reads can be very expensive. Sui's architecture allows these projects to focus only on the evolution of the objects they care about, i.e. partial replay.
For example, an RPG game that puts all the characters on Sui could simply look at the objects that represent those characters. They don't need to mine all the data from the Merkle tree data structure.
FinallyOn-chain storage. Various asset data, such as game race, level, experience, etc., can be stored in Sui objects. Sui can use traditional methods to scale on-chain storage, and it is now much cheaper to update on-chain assets.
Related Reading
Related Reading
Inventory of 20 noteworthy projects in Sui ecology, 8 of which have entered the testing stage
