Sui

Sui Sui uses a hybrid consensus model, the base transaction layer of which has been adapted from the original FastPay system developed in 2017. This base layer utilizes a dPoS consensus mechanism similar to GTBS, called Byzantine Consistent Broadcast. However, for shared objects (like smart contracts) which require a defined global order, a different consensus mechanism called Narwhal and Tusk may be used, which is currently under development by the Sui team. Narwhal is designed to handle the high throughput of transaction processing, while Tusk provides an asynchronous Byzantine Fault Tolerant (BFT) consensus mechanism for achieving precise ordering of these shared objects, a process known as Byzantine Agreement. In Sui, transactions are initially signed by the user, and the client sends the transaction to all authorities (analogous to validators or representatives). Upon receiving the transaction, each authority validates the authenticity of the transaction and returns a signature to the client, called a partial certificate. Once the client has collected enough partial certificates, equal to the quorum of that epoch (two-thirds plus one of the authorities), it forms a full transaction certificate. What happens next depends on the type of transaction. If the transaction involves shared objects (such as smart contract objects), the full transaction certificate is sent to the authorities and a higher-level Byzantine Agreement Protocol, which is responsible for the global ordering of the shared objects. This separate consensus mechanism, which is detailed in the Narwhal and Tusk white paper, uses an synchronous consensus mechanism based on a DAGbased mempool. Authorities then wait for the Byzantine Agreement Protocol to finalize the transaction, ensuring the correct ordering of shared objects before the process proceeds. If the transaction does not involve shared objects, or if it does involve shared objects that have been ordered by the Byzantine Agreement Protocol, each authority validates the authenticity of the full transaction certificate sent by the client and summarizes the result into a signed effects response. Clients are responsible for collecting each signed effects response from the authorities until a quorum of the signed effects has been collected, equal to two-thirds plus one of the authorities. Clients bundle these signed effects responses into an effects certificate, which provides proof to any entity that the transaction may proceed. Finally, either the client or the recipient (if the client sent the effects certificate directly) publishes the effects certificate to the authorities, who then independently update their internal ledgers. At this point, the transferred assets are available for use by the recipient. Unlike Sui, GTBS does not utilize a separate consensus mechanism for the global ordering of shared objects. This greatly reduces the complexity and latency of the system, but at the cost of liveness for the shared objects. For more information on the engineering trade-offs of using two consensus mechanisms, see the reference provided by the Sui team. Like Sui, GTBS is expected to scale linearly with the number of workers, analogous to persistent “machines” in other systems. Unlike persistent machines, however, workers are spawned as needed for each incoming request and terminate when the request is handled. This allows GTBS to scale completely linearly, bound only by available hardware, by increasing the workers available to each representative as network throughput increases. Unlike GTBS, Sui is limited by the number of cores per machine, preventing true linear scaling. GTBS is only dependent on the number of workers it can spawn assuming that no bottlenecks, like internal network bandwidth, impede it. In practice, however, the serverless workers in GTBS are provided by either Google Cloud Run or AWS Lambdas and are almost unbounded.