Architecture and Consensus
AptosBFT: a consensus model based on HotStuff
There is a leader who suggests a new block, and the rest of the validators vote on it.
Since all the validators communicate with the leader, the total number of messages sent out in every round is much lower than if the validators alos communicated with each other (similar to Harmony’s consensus).
Once everyone agrees that a block is valid, it becomes final — this fast finality is a key advantage of Aptos over other blockchains.
The leader changes with every round of voting, with a new leader selected in a verifiably random way.
The leader can work on several blocks at the same time (one in the Pre-Commit stage, another in the Commit stage, etc.) — this is called pipelining.
Block-STM: Atpos’ parallel execution engine
STM = Software Transactional Memory
Block-STM is a system that can process up to 160,000 transactions per second.
- Transactions are first executed by the nodes in parallel and only then validated.
- If there is a problem at this stage, a transaction can be aborted and re-executed or discarded.
Block-STM determines the dependencies between transactions, so if an operation cannot be validated, those that depend on it will also be re-executed. Once the conflicts have been settled, all the transactions in a block are committed to the blockchain together (lazy commit).
Not having to execute all the transactions sequentially or define the dependencies in advance saves a lot of time and resources (scalability).
Sui: getting rid of consensus for simple transactions
Eliminates consensus for many transactions altogether.
Simple transactions that have no dependencies are confirmed virtually instantly.
- I.e. simple transfer of tokens by the owner to another address
- Sender broadcasts the transaction, collects validators’ votes (handshakes), and receives a so-called certificate of validity.
However, Sui use a more traditional BFT consensus for more complex transactions that involve shared objects — assets tha can be modified by m ore than one owner. This applies to many interactions with smart contracts.
This approach makes a Sui an L1 for specific use cases (dApp with huge number of simple transactions such as games and airdrops).
Sui also uses parallel execution for simple transactions without dependencies, while complex oeprations are executed sequentially in precise order.
Narwhal and Tusk
Narwhal is the mempool module. It ensures that transaction data is available. The architecture is a DAG (Directed Acylic Graph). Many elements of the transactions are linked together as a network rather than a chain.
Tusk is the consensus module that orders tha transactions submitted for consensus (for complex transactions).
Narwhal and Tusk allow each validator to process more transactions in a unit of time.
Performance
Aptos: 130,000 TPS and sub-second finality
- Parallel Transaction Execution: If there is a problem with validation, an operation is re-executed together with those that depend on it.
- State Sync: A protocol that allows non-validator peers to verify and synchronize data across the blockchain.
- Lazy Commit: All the operations in a block are committed in bulk.
- Collaborative Scheduling: Transaction execution is scheduled in such a way as to use the resources efficiently.
Sui: “unlimited” TPS and near-instant finality
Team claims their TPS is potentially “infinite”. As the network load grows, Sui nodes can keep adding workers (a sort of secondary nodes) to create a mini-network and execute more transactions.
In a recent test, a single node running on a Macbook Pro with 8 cores processed 120,000 transactions per second (though strongly dependent on the type of transactions). With more complex transactions, the same node could execute only 20,000 TPS.
Since no consensus is needed in most cases, finality is sub-second. In this regard, Sui and Aptos have similar time to finality.