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
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.