Disclaimer: This study note serves as a personal reminder rather than a comprehensive list of all the concepts in the whitepaper.

• Global object pool: In Sui, persistent storage is supported via Sui’s global object pool rather than the account-based global storage of core Move

  • Move vs. the Sui Move

• Modules, Types and Abilities

• Objects and Ownership

  • objects are first-class citizens of the system

  • package code objects, and struct data objects

• Transactions: public tx (i.e. publish a package), call tx (i.e. call a package)

• Transaction Effects, Events, Create/Update/Wrap/Delete

• FastPay + Delegated Proof-of-Stake

  • requires 2/3 stake from honest authorities

  • liveness and eventual delivery: at least one honest party acts as a relay for each certificate between authorities

• object reference, transaction certificate, effect certificate

• persistent stores on authorities: 4 key-value maps

• causality & parallelism

• owned objects vs. shared objects

  execution for transactions involving read-only and owned objects requires only consistent broadcast and a single certificate to proceed; and Byzantine agreement is only required for transactions involving shared objects (using a high-throughput consensus system)

• full client (replica) and light client

To ensure that more resources result in increased capacity quasi-linearly, the Sui design aggressively reduces bottlenecks and points of synchronization requiring global locks within authorities. Processing transactions is cleanly separated into two phases, namely (1) ensuring the transaction has exclusive access to the owned or shared objects at a specific version, and (2) then subsequently executing the transaction and committing its effects.

In my view, the most significant innovations of Sui are:

• split the common “fire-and-forget” mode of broadcasting transactions in traditional blockchain networks to the two phases: 1) collect enough signatures from validators; 2) create the certificate and broadcast.

• object-based global storage rather than account-based

• differentiate the processes for handling single-owner objects from those for handling shared objects.

By combining these elements, the system realizes high throughput, low latency, and horizontal scalability.

However, effective utilization of the system demands careful design of the data model and operations by developers. For instance, the suitability of using the single-owner object model for creating a standard ERC-20 token is not immediately apparent.

Disclaimer: This study note serves as a personal reminder rather than a comprehensive list of all the concepts in the whitepaper.

• Global object pool: In Sui, persistent storage is supported via Sui’s global object pool rather than the account-based global storage of core Move

  • Move vs. the Sui Move

• Modules, Types and Abilities

• Objects and Ownership

  • objects are first-class citizens of the system

  • package code objects, and struct data objects

• Transactions: public tx (i.e. publish a package), call tx (i.e. call a package)

• Transaction Effects, Events, Create/Update/Wrap/Delete

• FastPay + Delegated Proof-of-Stake

  • requires 2/3 stake from honest authorities

  • liveness and eventual delivery: at least one honest party acts as a relay for each certificate between authorities

• object reference, transaction certificate, effect certificate

• persistent stores on authorities: 4 key-value maps

• causality & parallelism

• owned objects vs. shared objects

  execution for transactions involving read-only and owned objects requires only consistent broadcast and a single certificate to proceed; and Byzantine agreement is only required for transactions involving shared objects (using a high-throughput consensus system)

• full client (replica) and light client

To ensure that more resources result in increased capacity quasi-linearly, the Sui design aggressively reduces bottlenecks and points of synchronization requiring global locks within authorities. Processing transactions is cleanly separated into two phases, namely (1) ensuring the transaction has exclusive access to the owned or shared objects at a specific version, and (2) then subsequently executing the transaction and committing its effects.

In my view, the most significant innovations of Sui are:

• split the common “fire-and-forget” mode of broadcasting transactions in traditional blockchain networks to the two phases: 1) collect enough signatures from validators; 2) create the certificate and broadcast.

• object-based global storage rather than account-based

• differentiate the processes for handling single-owner objects from those for handling shared objects.

By combining these elements, the system realizes high throughput, low latency, and horizontal scalability.

However, effective utilization of the system demands careful design of the data model and operations by developers. For instance, the suitability of using the single-owner object model for creating a standard ERC-20 token is not immediately apparent.