In the past period of time, there have been articles on the analysis of Sui , but most of these articles have missed one of the most critical innovations – Sui’s data model and transaction processing channel. I’ll 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 behind the 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 “constructing a block – consensus – executing – updating the Merkle tree”, and all transactions must be processed before continuing downstream in the process. And when a new block starts to build, the processing of the transaction is also suspended.
Below is a diagram of the transaction processing channel of a traditional blockchain and its problems. 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 , the balance of a certain token, a certain smart contract, these 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 image below is a simple example depicting 5 different transactions that can be grouped into 3 groups (we’ll come back to specific objects and shared objects later). These 3 sets 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 sends a BAYC NFT to Bruce, Alice sends a Punk NFT to Alex, Jane uses a DEX, etc. All these transactions need to be collectively ordered, executed, and finally represented on the Merkle tree.
For example, it’s like taking a bus. On the traditional blockchain, all passengers must queue (consensus) to get on the bus, each passenger needs to check the ticket (execution) before departure, and then get off at the same location (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 the 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 Different vehicles are sent to their destination in parallel.
The innovation of Sui is not only in the parallel processing of transactions (more on this 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 on 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, and will not be billed until a series of related transactions are finalized.
In addition, it should be noted that in the previous case, some transactions only correspond to a specific object, such as only Bob can initiate transactions about the BAYC NFT he owns. Transactions for a specific object class can skip consensus (only Byzantine consensus broadcasting is required) because the owner can confirm the transaction order.
For another class of transactions, so-called shared object transactions (such as 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 in.
Simply put, transactions of specific object classes can be executed in parallel, and transactions of shared object types can also be executed in parallel with each other, but each shared object needs to be executed sequentially (other static/dynamic techniques are applied here).
All in all, you can understand it as:
- With regular blockchains, all transactions need to be ordered collectively and then executed.
- For Sui, all transactions will be differentiated, sorted, and sorted according to a certain logic, and then executed. The data model can make the dependencies between different transactions clearer, only transactions that share objects need collective ordering, transactions of specific objects do not need this consensus negotiation process.
So, what product problems does this architecture of Sui solve? Let’s move on.
The first is the ability to scale horizontally. On Sui, each group of transactions is processed in parallel, which is like the above-mentioned 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 . At this point, Sui can be sharded with 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 support the continuous growth of their scale. The blockchain with a performance limit 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 the 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 fairly complex topic. Suffice it to say that Sui significantly improves composability both at the contract level and at the asset level (objects of different types can be nested within other objects).
Then there’s the ability 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. The architecture of Sui 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 characters on a Sui can simply look at the objects that represent those characters. They don’t need to mine all the data from the Merkle tree data structure.
Finally, there is on-chain storage . All kinds of asset data, such as the game’s 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.
This long post ends here. These contents are high-dimensional, but not very comprehensive. However, I hope you can learn more about Sui through this content.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/sui-founders-own-handwriting-take-crowding-bus-as-an-example-to-illustrate-suis-performance-advantages/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.