The Sui Thesis

Author: Lachlan Breakey

Zero Age (Kosmos II) is excited to announce our inclusion in the $300m Series B with participation from a16z, Jump, Binance labs, Franklin Templeton and other notable investors. Sui (meaning water) is a monolithic, open and permissionless smart contract platform that packages ‘objects’ in the Move Language.

Historically, the volume of on-chain transactions has been domiciled in state machines that promote monolithic architectures or promote Ethereum virtual machine compatibility (Eth, BSC & AVAX), but as the App-chain thesis builds conviction, increased contention has risen on the properties and associated tradeoffs for application development in different architectures. This debate is mainly a function of overall UX, expressiveness, fragmented liquidity composability, and latency that is incurred when moving between semi-interoperable app-chains. With the original Cosmos vision moving toward fruition including value accrual (although remains blurred), Interchain security and Cosmos Assembly, we believe emerging monolithic structures must reimagine execution environments and developer/user experience if they are going to remain competitive in the movement toward ‘modular’ paradigms. This piece has not been created to deeply examine the technical components of Sui and is instead intended to establish a general understanding of what drove our investment thesis into this new emerging L1.

Move

Within the L1 landscape, the Ethereum Virtual Machine (EVM) has been the most adopted run time environment, whether that be represented by other base settlement layers or L2 rollups who separate execution and consensus via taking transactions off-chain, bundling them and submitting them back on the L1, thereby reducing the computational load on Eth for example. (See Optimism, Arbitrum and Boba Network). Although the EVM is good for executing smart contracts, it is by no means the optimal execution environment. Its dominance is partly explained by backward compatibility. This is impactful because emerging chains/apps can now interact with existing Ethereum dApps, while enabling developers to unlock access to a mass of pre-deployed ‘secure’ codebase and libraries. Historically, the most optimal programming language hasn’t ‘won’ if you look at the adoption of Java. That said, this outcome does not preclude the perusal of different execution environments especially when they provide opportunities to increase throughput.

Before we touch on MoveVM, this piece will briefly discuss Move, which provides a safe and expressive vehicle to write smart contracts. The language was originally developed for the Libra/Diem blockchain that inherited funding from Facebook and others back in 2019.

Programming with scarcity

Move has been designed from scratch with the primary purpose of being a language that enables programming with scarcity and the ability to encode digital ownership of assets. This objective is completed via enforcing strict ‘linear logic’, meaning the user cannot lose ownership when moving between different modules, nor can the object be copied. Like all resources, for instance, when we talk about gold, there is inherent scarcity because the supply of assets is controlled and finite. In conventional programming languages, there is no baked-in scarcity, under the hood it’s all just bytecodes. For instance, if you’re stating x=y, what you’re really saying is copy the value stored in y and put it into x. This model is not appropriate for financial transactions because a user can copy x out of ‘thin air’. Thus you need the language to be able to programmatically talk about scarcity.

In the implementation of custom assets ERC-20, the burden is on the developer to have prudence and not produce programming mistakes that enable the duplication and mistreatment of scarce tokens. By baking scarcity into the core language, Move lowers the stakes and abstracts away some of the risks associated with smart contract development while having a structured representation of assets. Such safety features provide a fertile and attractive developer-friendly environment that is highly likely to attract sidelined Rust-based developers into web3.

Safety

Ongoing smart contract bugs have plagued the industry since its inception and 2022 being another year of reckoning ($3B already stolen according to Chainalysis). At the application stack, addressing vulnerabilities has been commonly first approached by appointing auditors such as Halborn or CertiK. Sui however, leverages Move to confront this problem at the language and protocol level.

Move enables the rejection of programs that do not uphold certain properties (type and safety rules). Historically, this has been completed by 1) using a compiler to check properties 2) “use low-level untyped assembly and perform these safety checks at runtime both solutions adding complexity and cost. In comparison, Move deploys a bytecode verifier, which at a high level acts as a guard to ensure the code passed is fit for execution. This becomes increasingly impactful for new developers entering the space, enabling them to find safety in the code they write.

The Move prover, a formal verification tool, provides an additional safety blanket. For example, if you say there will be only 250 of 250 objects of this type in this world then the prover can show that for all possible sequences of calls and transactions this property will continue to hold (this is done by fancy moon math that is outside the bounds of this piece)

Note that Move is both the programming language and the virtual machine (the environment in which smart contracts are executed). This design has an impact because it enables developers to express themselves without producing faulty code while promoting correctness.

Parallel Execution via a novel data structure

The endeavour to parallelise a runtime environment is not a new approach and has been deployed historically in symmetric multiprocessors (SMPs) and under-utilised GPUs. In a blockchain context, parallel execution has been utilised to combat the fundamental limitation of sequential ordering where the state of the blockchain is paused until the previous transaction is executed, resulting in a bottleneck for scalability. The high-level notion of parallelism is that by running independent transactions concurrently in different cores, blockchains can handle higher demand for block space without incurring arbitrarily high transaction fees. I will discuss the basics of how this is implemented in Sui’s model.

Other Notable examples of chains adopting a parallel runtime include Solana’s (Sealevel), which is an account-based VM design. At a high level, it allows for non-overlapping transactions or those that do not depend on the output of another to be executed simultaneously. Anatoly’s blog post in 2019 explores Sealevel in more detail . Other instances of protocols adopting parallelism can be found in Fuel, an optimistic L2 building on top of Eth.

Step one in parallel execution is to identify transactions that are independent of each other. For instance, if I’m sending SUI to my Grandma and at the same time John wants to send SUI to Bob the two transactions do not affect the other’s execution. Alternatively, one scenario where transactions are dependent on each other is in an order book (CLOB) environment. This is because users are interacting with the same smart contract and pool of orders and therefore must be executed sequentially. Thus, as the composability of Defi primitives continue to increase the line between dependent and independent transactions becomes more opaque and harder to identify. That said, there are still theoretical improvements in throughput at the margin.

Sui approaches this by defining a state storage model that identifies objects based on two principles:

1. Assets (objects) that can be shared where reads and writes are permissioned =contents may change but ts ID remains as does the metadata relating to ownership
2. Read-only objects that cannot be mutated or deleted

Transactions that touch a shared object (has dependencies) go through full consensus (Narwhal & Tusk )and is sequenced and executed like normal. Transactions that don’t require Byzantine system broadcast to commit in parallel and thus avoid the constraint of firstly ordering transactions (Some class of computation that doesn’t require ordering) thereby increasing the throughput of the state machine.

Key notion: Sui didn’t have to build an order to commit transactions because ordering is not going to change their effect.

It should be noted that parallelism is not the antidote to all the world’s problems with liveliness and network centralization both being salient challenges (Solana signifies this). In reality, many blockchain state transitions are dependent on each other, meaning there is usually one contract that the majority of the user base is interacting with uniformly. For instance, during NFT mints whereby bots perpetually spam the network, parallel execution is unable to isolate that specific hotspot or contention of state. This notion is signified by Amdahl’s law where “the overall performance improvement gained by optimising a single part of the system is limited by the fraction of time the improved part is used”. That is, regardless of the magnitude of improvement the increase in performance of the system is limited by the task that cannot benefit from the improvement.

That said, when coupled with innovative consensus mechanisms, I believe Sui’s novel execution runtime will dramatically improve throughput at the margin and enable distributed systems to move closer to that Visa-like throughput we have all been dreaming of.

Narwhal & Tusk

Consensus mechanisms have long been a bottleneck for scalability in distributed systems, with the task of ordering transitions in the state while reaching a 66% agreement being an increasingly studied aspect of cryptography. Sui subscribes to a modular approach via the Novel mempool and consensus engine, Narwhal and Tusk. This duel system is composed of two tasks;

1. Narwhal: ensures the availability of the data submitted to consensus via a data-layer solution known as a Directed Acyclic graph (DAG). The difference between the sequential or linear ordering of consensus (as in Eth) and a DAG, is that it forms a tree-like structure because individual transactions are linked to numerous other transactions.

Source: The Block

The main advantage of this approach over a sequential system (leader broadcasting) is that instead of one transaction proposed by the leader, they can nominate multiple “certificates of availability”, removing the initial constraint for transactions that do not require the knowledge of the previous transaction. Ultimately, this DAG structure enables scarce resources (the availability of data or transaction information )to be broadcasted more efficiently, increasing scalability and throughput.

2. Tusk: “ an asynchronous ordering algorithm for consensus”. By obtaining the DAG from Narwhal, validators interpret the DA and use “shared randomness” to propose a complete order of transactions. Please see the following paper for an in-depth dive into the implementation of Narwhal and Tusk.

SUI Token (10,000,000,000 finite supply)

In alignment with its PoS predecessors, SUI holders can stake the native token and participate in governance parameters including future upgrades to the network. Moreover, SUI is used for gas fees when submitting transactions or interacting with smart contracts, while also rewarding honest behavior by validators who secure the network. For more information regarding the gas pricing mechanisms please visit the Sui tokenomics paper.

One of the more distinct aspects of the token design is the introduction of a storage fund. The idea is that generally there is a mismatch between validators executing and storing data and those needing to store it in the future which places the burden on subsequent users to pay excessive fees (in comparison to early entrants). Sui develops an antidote to this problem by requiring users to pay for both computation and storage. The storage fees are then taken out of circulation and held in a storage fund to be redistributed to future validators. Note that upon increased load and activity, there are higher storage requirements meaning that more SUI is removed from circulation (increases deflationary properties), resulting in upward price pressure. Ultimately, this novel design uses elegant crypto-economic incentives to remove future constraints on the network.

Parting Comments

At Kosmos, we believe Sui is optimising for the correct metrics to enable mass adoption while providing a free environment for developer expression.By optimising for visa-like throughput, Sui unlocks applications and potential use cases including low-latency on-chain trading, social media networks (on-chain Reddit) and complex game logic that was previously impaired by slower designs. Although we align, but are not tethered, to the modular approach, there are tradeoffs inherent in decoupling the functions of blockchain that may enable Monolithic designs to be the ‘end game’ if they continue to make computational advancements.