The Sui Smart Contracts Platform

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

1. Claim 01 · Paper model

   Objects, not accounts, are the state

   The ledger is a set of typed objects with owners. A transaction names the objects it will touch. If it names them, the protocol knows whether a global order is required.

2. Claim 02 · Paper model

   Owned objects take a fast path

   If an object has one owner, and the transaction only touches objects that owner holds, validators can sign it without agreeing on an order against unrelated transactions. Causal order is enough.

3. Claim 03 · Paper model

   Shared objects take consensus

   Anything two parties might touch at once goes through a Byzantine total order. The paper does not claim that every transaction skips consensus. It claims that many do.

4. Claim 04 · Paper model

   Move enforces ownership in the type

   The language is how 'this object has one owner' stays true as code evolves. A fast path that the type system does not police is just an honour system.

5. Claim 05 · Paper model

   The split is the product decision

   Games and simple transfers fit owned objects. An order book does not. A pitch that quotes the fast path for a shared-state application is quoting the wrong paragraph.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

1. 01 Objects, not accounts, are the state

   Observation

   What the study says

   The ledger is a set of typed objects with owners. A transaction names the objects it will touch. If it names them, the protocol knows whether a global order is required.

   Model

   What has to hold

   Object ownership is enforced by execution, not only by the transaction's claim.

   Falsifier

   What would retire it

   Does this application touch a shared object on the hot path?

2. 02 Owned objects take a fast path

   Observation

   What the study says

   If an object has one owner, and the transaction only touches objects that owner holds, validators can sign it without agreeing on an order against unrelated transactions. Causal order is enough.

   Model

   What has to hold

   The consensus path for shared objects is live. A deadlock there freezes every shared application even while owned-object transfers still work.

   Falsifier

   What would retire it

   What quorum signs an owned-object certificate?

3. 03 Shared objects take consensus

   Observation

   What the study says

   Anything two parties might touch at once goes through a Byzantine total order. The paper does not claim that every transaction skips consensus. It claims that many do.

   Model

   What has to hold

   The consensus path for shared objects is live. A deadlock there freezes every shared application even while owned-object transfers still work.

   Falsifier

   What would retire it

   Does this application touch a shared object on the hot path?

4. 04 Move enforces ownership in the type

   Observation

   What the study says

   The language is how 'this object has one owner' stays true as code evolves. A fast path that the type system does not police is just an honour system.

   Model

   What has to hold

   Object ownership is enforced by execution, not only by the transaction's claim.

   Falsifier

   What would retire it

   Does this application touch a shared object on the hot path?

5. 05 The split is the product decision

   Observation

   What the study says

   Games and simple transfers fit owned objects. An order book does not. A pitch that quotes the fast path for a shared-state application is quoting the wrong paragraph.

   Model

   What has to hold

   The consensus path for shared objects is live. A deadlock there freezes every shared application even while owned-object transfers still work.

   Falsifier

   What would retire it

   Does this application touch a shared object on the hot path?

03 Sequence

One action, as an operating tape

1. 01A user builds a transaction that lists the object identifiers it reads and writes.
2. 02If every object is owned by that user and no shared object is involved, validators check the owner's signature and the object versions, then sign.
3. 03A quorum of those signatures is a certificate. The transaction can be executed from the certificate.
4. 04If any object is shared, the transaction is ordered by the consensus protocol first, then executed in that order.
5. 05The resulting objects have new versions. A later transaction that names a stale version fails.

04 Load-bearing

The argument, and where a pitch drops it

1. Causal order is not 'no consensus'

   The cut

   The fast path still needs a quorum of validators. It skips a total order among independent transactions. It does not skip trust in the validator set. An attacker who can forge a quorum can forge either path.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   A later client, parameter or reward formula is a different object from this paragraph.

2. Versioning is the double-spend protection

   The cut

   An owned object has a version. Two transactions that name the same version cannot both gather certificates. That replaces the usual nonce-on-one-account model. Wallets that do not track versions will confuse users even when the protocol is correct.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   The fast path disappears as soon as the object is shared. Many applications will share state and should not quote the fast path.

3. Shared state is where the system becomes ordinary

   The cut

   The moment an application uses a shared object, latency looks like other Byzantine chains. The paper's contribution is to make that moment explicit. Hiding shared objects inside a framework, so developers think they are on the fast path, undoes the honesty of the design.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   The fast path disappears as soon as the object is shared. Many applications will share state and should not quote the fast path.

05 Register

What has to be true

• Stake and threshold · Not re-measured

  Validators are the same quorum you would trust for a normal chain. The fast path is not a lighter trust assumption.

• Model · Not re-measured

  Object ownership is enforced by execution, not only by the transaction's claim.

• Model · Not re-measured

  Clients learn certificates and new versions reliably. A client who misses a version is stuck until it catches up.

• Model · Not re-measured

  The consensus path for shared objects is live. A deadlock there freezes every shared application even while owned-object transfers still work.

06 Divergence

What happened after the paper

Sui launched with this object model and later tuned consensus for the shared-object path. The distinction between owned and shared remains the paper's real teaching. Marketing that says every transaction avoids consensus is not the paper.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

1. Kill test 1Does this application touch a shared object on the hot path?
2. Kill test 2What quorum signs an owned-object certificate?
3. Kill test 3How does a client discover the current version of an object?
4. Kill test 4What is the latency of the shared path, stated separately from the owned path?
5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

09 Lexicon

Terms, opened into the record

Owned object

A piece of state with a single owner. Transactions on it can be certified without a global order against other owners.

Shared object

A piece of state more than one party may touch. It is sequenced by consensus.

Certificate

A quorum of validator signatures on a transaction, sufficient to execute an owned-object call.

Object version

The counter that makes a second spend of the same state fail, because the stale version no longer certifies.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

11 Related

The next papers, as theses

• Aptos · 2022

  The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure

  Aptos Labs' 2022 paper for a Move-based chain that pipelines dissemination, ordering, execution and certification, and that treats protocol upgrades as a first-class feature rather than a hard-fork event.

• Diem · 2020

  The Diem Blockchain

  The technical paper for the Libra, later Diem, payment chain: a permissioned BFT ledger, a Move language for resources, and a reserve-backed currency proposal. The project was wound down in 2022. The paper still matters because Move, and the account model Aptos and Sui started from, was specified here.

• Solana · 2018

  Solana: A new architecture for a high performance blockchain

  Yakovenko's design note for a ledger that encodes the passage of time as a verifiable hash chain, called Proof of History, so that validators spend less effort agreeing on order.