The short brief of the author: Lshoo has more than 10 years experience in programming and engineering, especially as an experienced developer in the Dfinity ecosystem. His team is translating the new version of Move language docs and will be ready next week.The content of this article was inspired from the latest office hour of CFG Labs, the topic of which is the new layer1 Sui and the introduction of Move language.You can always visit the video through the following link https://youtu.be/nYekgb_3pus (Mandarin speaking)
The Overview and summary of Move Language
Sui is a permissionless decentralized smart contract platform which focuses on low latency,highly performance and horizontal scalability. The smart contract development language is Move while the chain itself is built using Rust. Sui has some significant characteristics. Firstly, Sui is highly secure which is important in the blockchain and Defi area. Also, Sui is aiming to solve the state bloat problem through horizontal scalability enabled by “intra”-validator sharding. Importantly, this preserves atomic composability of state updates, which is not the case for inter-validator sharding, multi-chain architectures, subchains, or L2’s. Sui is dedicated to providing the user experience that’s Web2 equivalent, focusing on applications such as gaming and Socials. In terms of design, Sui redesigned the codebase from Libra and Diem, which is instead strictly followed in Move language based projects such as Aptos. The core team has years of experience in developing chains and wallets in some big giants including Facebook/Diem.
Move could produce Lib and frameworks like general language. The contract itself is also static immutable Lib,where contract data is stored in Move or the global storage for the chain. Various contracts could refer or compose with each other. Move language inherits the native features of Rust, for example the ownership. By further internalizing features for ownership, Move languages will be more suitable for assets such as financial assets. For example, Once I transfer the asset from A to B, the ownership is transferred as well. Also, some prerequisites are also made to make sure assets can’t be copied, mutable, or discarded while in general language such as Rust, Solidity, this is not the case. Hence problems such as reentrancy attacks can happen in Ethereum. (Of course, other assets including fungible, or non-fungible assets, or the capabilities such as the granting the permission to call certain functions or create other objects, and the smart contracts that can manage other assets etc can be encoded by Objects.)
In summary, Move language has certain features such as ownership, prerequisite assets are not allowed to be copied or discarded randomly. Also, Move language defines all assets as objects and the objects themselves are owned by an address. Note, every object is owned by a single address, and each address can own an arbitrary number of objects. Move programmes define operations such as the creation of custom rules, transfer of assets, operations that mutate assets etc based on these objects.
All are objects with globally unique IDs
Sui defines all objects, and each Sui object has a globally unique identifier, which works as a persistent identifier for the object, and flows between owners and flows in and out of other objects. Each ID is assigned by the object, and the transaction itself creates the object. This ID is assigned to the object by the transaction that created it. The ID is created as increments. In addition to the ID, each object also carries metadata for its ownership. There are three kinds of objects, the first one is immutable objects (such as Package, module, here called module, other chains are called smart contracts). Move programs are composed of a set of modules, and each module contains structure declarations and function declarations. Modules can import struct types from other modules and call functions declared by other modules. Of course, there are another two types including the single-owner objects and shared objects. Objects controlled by a single address are called single-owner objects, and objects can also share read/write permissions with other objects, or only with read permissions. The ownership of an object determines whether or how a transaction uses the object as an input. To summarize, a single-owner object can only be used in transactions initiated by its owner or treat its parent object as an input, while shared objects can be used by any transaction, but only with specified mutability permissions.
For example, if I have a shared object, so many people can modify it, in this case, we need consensus. As a user, when you need to access contracts and objects, you need to go through the consensus process. A single-owner object can become a shared object, or can turn the contents of the shared object, sub-objects, into a single-owner object. Single-owner objects can also be turned into immutable objects, but this direction is irreversible.
Consensus mechanism
Sui's consensus mechanism is also very interesting, and it mainly revolves around three objects. For immutable objects, they can be understood as constants and can be referenced at random, so consensus is not required. Single-owner objects are broadcast through the DAG+BFT Consistent Broadcast Protocol, which does not require consensus. When I find this object, I only need to find the dependency path of this object, because when each object is generated, it is implemented according to the previous object and the dependency path. For example, If I have a transaction, from account A to account B, this object will generate a new version, which means that the immutable object can no longer become the owner object. In addition to being immutable, his version or hash changes. And this hash will also be generated based on the previous version of the same object, the signature of the transaction, the timestamp, and hence a new hash value will be generated. So this is the scenario for DAG dependency, which is quite similar to Bitcoin's UTXO model. Through this way, anyone can find the entire relationship network of the current object, thereby ensuring the credibility of the transfer of the object. Transfer is also the targeting market for Sui, where any single transaction can be submitted fastly without everyone operating the same object. It’s worth mentioning that Sui verifies the transactions one by one, rather than the put several transactions in the block, which significantly reduces the latency and improves throughput. Shared objects are based on the BFT consensus, Narwhal and Tusk developed by Mysten Labs, which is inspired from Libra’s BFT consensus.
The global storage of Sui
** **The global storage of the Move language will bring about the problems such as state bloat, so global storage of Sui is instead re-designed independently from the global storage of the Move language, and economic incentives such as storage funds have been introduced. We will further introduce the detail in the next article focusing on Sui’s economic incentive mechanism design approach. It’s worth mentioning here that The CTO of Mysten Labs mentioned in discord that the current storage size limit is 1 megabyte (it’s not the final size and is subject to change according to the testnet performance) , through this way, the storage for things like NFT pictures or game props are expected to be solved realistically. In terms of cost, on-chain data storage presents serious challenges: for example, a validator that processes and writes data to storage today may be different from validators who need to store that data in the future. If users only pay for computation when writing, future users will need to pay subsidized fees for storage from past users. So negative network externalities could bring further potential risks to Sui. So users for Sui have to pay both computation and storage upfront fees in order to mitigate the risks. The storage fee will be deposited into the storage fund and used to adjust the future stake reward allocated to the validator, and this reward is based on the proportion of staking share for SUI stakers (under design of the POS mechanism). This design will help to maintain the sustainability for the entire network and provide continuous incentives to Sui's validators. Then compared to other solutions, such as arweave, IPFS, what is the functional difference and new experience of this global storage (the question comes from member A of our community). So for large objects, we encourage everyone to use the chain such as arweave or IPFS, and for small objects (1 megabyte threshold), Sui provides a more user-friendly experience and experience such as calling APIs.The global storage of the Move language itself can also provide such similar experience. For the 1 megabyte threshold here, another member (member B of our community) believes that less than 1 megabyte may be more suitable for some texts, long texts.The core problem here is that small file storage will take up a lot of storage space. In a decentralized environment, how to ensure that miners retain historical data in accordance with the agreement under the current incentivised model? (Member C’s idea). Under Sui's economic design, validators are always incentivised to delete old data. At present, we have not seen a similar design mechanism explained in the Sui document such as proof of space time or challenge mechanism introduced in Filecoin in the Sui document.
Emphasis on designing for ordinary users while lowering the threshold for developers
At the beginning of this year, Sui published some articles talking about the vision for Web3, through the development of more user and developer friendly products. They also claimed that the TPS can theoretically reach up to 120K theoretically. This is mainly because in the single-owner mode, the BFT mechanism for multi-round consensus can be replaced by the DAG+BFT consistent broadcast protocol grough more efficient back-and-forth communication. In other blockchains, validators instead have to work together to synchronize the data. The official release of the demo for the gaming is very fast. The visual quality is also very good. Sui has made a special SDK for the game (with partners to develop this GameSDK). This works well because for the Move language itself, you can develop a toolkit, and the Move language itself has its own framework in addition to the standard library, and each chain has its own framework.The Lib can further enhance the functions on your chain. This is a big advantage of the Move language. So for developers, when developing, you don’t have to be familiar with Move language itself, which greatly reduces the threshold for developers. At the same time, in order to improve the user experience, users usually need to register the web3 wallet to use the service, but on the Sui network, it can be solved by sending emails, such as receiving tokens by email. At the same time, if you don’t have a gas fee to pay, you can also use entrusted payment, or get incentivised under the physical work. For example, you can get a corresponding gas fee by watching advertisements and playing games (this seems to get inspired from the latest design concept of Ethereum, entrusted payment) . Therefore, Sui has made a lot of innovations and designs when it comes to user experience. At present, its incentive testnet has just been launched, and the distribution mechanism is also very attractive. In addition to the design of the storage fund, the Sui Foundation awards 2,000 SUI to participants in each testnet wave. At the same time, the Sui Foundation promises to incentivise 10% of tokens to the best-performing validators who continue to participate in the Sui mainnet.
The trade-off problem of egineering design
Design complexity
How to avoid data bloate problems? Member C believes that pictures, chains, and binary data put together will bring about the problem of state bloate. Indeed, Sui is also trying to solve this problem in the design. Whereas traditional blockchains typically require only one consensus protocol, Sui requires two: (1) a Byzantine consensus broadcast-based protocol to handle simple transactions, and (2) a consensus protocol to handle transactions with shared objects. This means that the Sui team needs to maintain a larger codebase. Transactions involving shared objects will incur the upfront cost before submitting them to the consensus protocol. And this cost is mainly used to safely combine the above two protocols. On other blockchains, transactions are instead submitted directly to the consensus protocol without incurring any cost. Note that the finality of shared object transactions is still in the 2-3 second range (despite this cost). Building efficient synchronizers in Sui is harder than in other blockchains. The synchronizer subprotocol allows validators to update each other by sharing data, and slow validators can catch up. More and more protocols seem to improve the throughput by using the design rationale from the classical databases (the simplest path to store the server is to store in blobs, clobs （data type in data base), store the binary code and isolate it).
Sequential write in simple case
Traditional blockchains require all nodes to synchronize information, reach consensus, and order all the transactions. For example, the proposer can do the sandwich attack or frontrunning through prioritizing his own transaction (BAD MEV), even though the transaction of others is submitted first, which will cause the MEV problem, which will cause damage to users and the whole ecosystem. However, Sui forges consensus for most transactions (the first type: immutable objects and the second type: the consistent broadcast protocol of DAG+BFT in single-owner mode),in order to reduce network latency issues.In this manner, In this manner, Sui enables multi-lane processing and eliminates head-of-line blocking. Other transactions don’t need to wait for the completion of the first transaction’s increment in a single lane. Sui provides a lane of the appropriate breadth for each transaction. Simple transactions require viewing only the sender account, which greatly improves the system’s capacity. So Sui's immutable object is public, read-only, does not belong to anyone, everyone can refer to it, but cannot modify it, if the object becomes immutable and it will become irreversible.
Complex total query
Compared with the traditional blockchain, Sui's total query may be more difficult because it does not emphasize the total order of transactions (Total Order) but adopts a random order (Casual order). In terms of local reads, total queries are fairly rare, but useful in some cases. For example, if a new validator joins the network and needs to download the total state to disk, or an auditor wants to audit the entire blockchain.
Sui tries to solve this problem through the design of checkpoints. A checkpoint is established each time a increment is added to the blockchain resulting from an authenticated transaction. Checkpoints work much like a write-ahead log, which stores state before the program is fully executed. The calls in this program represent smart contracts in the blockchain. Checkpoints contain not only transactions, but also commitments to the state of the blockchain before and after the transaction.
Sui uses state commitments on epoch changes. Sui requires a single answer from multiple validators and utilizes a secondary protocol to obtain a hash representing the state of the blockchain. The protocol consumes very little bandwidth and does not cause transaction congestion issues. Validators produce checkpoints during every epoch change. Sui requires validators to generate checkpoints more frequently as well. Therefore, users can use these checkpoints to audit the blockchain.
Summarize
To sum up, we have sorted out the technical features and engineering mechanism of Sui. For Sui, the Move language is the core. Many features derived from Move, such as objects and consensus mechanisms, are very unique and different from the design of other chains. The general consensus, blocks, transaction, order, etc. for other chains have been redesigned on Sui to ensure sufficient security, but of course, flexibility is sacrificed to some extent due to the design trade off. For example, the performance immutability problem due to the immutability. Assets, objects, you have to sign the user, it has nothing to do with the contract itself. The asset is not under the contract name, the contract does not save data, instead the asset is stored under the user address. In the global storage design, the public key is the account address. In general, an interesting intake is that we found that functional design has been used to improve the overall performance of various blockchains, including immutability, including the Actor model (internal immutability), and the use of isolation mechanisms to enhance fianality parallelism and higher TPS. Although Sui does not directly adopt the Actor model, it is similar to the Actor's design. Through independent design such as DAG, concurrency is guaranteed, and by adding corresponding features, it targets specific use cases to bring users a better user experience.
From the user's point of view, if we define the development difficulty for Rust as 100, then the development difficulty for the streamlined Move language is ranked somewhat as10 (CosmWasm, Rust is 20-30). At the same time, Move writes code and compiles it into the bytecode of Move VM (virtual machine), which is a bit like webassembly (So webassembly is 01 binary, bytecode, the above is Rust, and then the above is Move).
Reference
** **