Transaction Lifecycle
At a high level, the following figure outlines the lifecycle of a transaction on the Sui blockchain.
The following steps align with those in the preceding image.
The first step of the process is the creation of a transaction. A user with a private key creates and signs a user transaction to either mutate objects they own, or a mix of objects they own and shared objects.
Sui sends the transaction to each validator (often through a Full node). Validators perform a series of validity and safety checks, sign it, and return the signed transaction to the client.
The client then collects the responses from a supermajority of validators to form a transaction certificate. As a result, unlike consensus-based blockchains, Sui validators do not need to propagate signatures on a best-effort basis (gossip signatures) or aggregate certificates. This effort is now the responsibility of the client or gateway.
After assembling the certificate, the client sends it back to all validators, who check its validity and acknowledge its receipt to the client. If the transaction involves owned objects exclusively, Sui can process the transaction certificate immediately and execute it without waiting for the consensus engine (direct fast path). All certificates are forwarded to the Sui DAG-based consensus protocol (also operated by the Sui validators).
Consensus eventually outputs a total order of certificates; the validators check and execute those that contain shared objects.
Clients can collect a supermajority of validator responses, assemble them into an effect certificate, and use it as proof of the settlement of the transaction.
Subsequently, Sui forms checkpoints for every consensus commit, which it also uses to drive the reconfiguration protocol.
The complete Sui Lutris paper provides additional detail on how the safety and liveness protocols operate, as well as proofs of security for them in the standard distributed systems model with Byzantine participants in partial synchrony.