Zaptos: Towards Optimal Blockchain Latency

TL;DR

Zaptos targets end-to-end blockchain latency, a critical user-facing metric often overlooked in favor of throughput-focused BFT consensus work. It builds on Aptos' pipelined architecture and introduces optimistic execution, optimistic commit, and certification piggybacking to shadow non-consensus stages under consensus latency, achieving sub-second latency at 20k TPS in geo-distributed settings. The paper provides formal safety and liveness proofs, an implementation in Rust atop Aptos, and thorough evaluations showing substantial latency reductions under both common and failure scenarios. The practical impact is a scalable, low-latency blockchain design that preserves high throughput and robustness, offering compelling performance gains for real-world deployments and DApps that require rapid finality.

Abstract

End-to-end blockchain latency has become a critical topic of interest in both academia and industry. However, while modern blockchain systems process transactions through multiple stages, most research has primarily focused on optimizing the latency of the Byzantine Fault Tolerance consensus component. In this work, we identify key sources of latency in blockchain systems and introduce Zaptos, a parallel pipelined architecture designed to minimize end-to-end latency while maintaining the high-throughput of pipelined blockchains. We implemented Zaptos and evaluated it against the pipelined architecture of the Aptos blockchain in a geo-distributed environment. Our evaluation demonstrates a 25\% latency reduction under low load and over 40\% reduction under high load. Notably, Zaptos achieves a throughput of 20,000 transactions per second with sub-second latency, surpassing previously reported blockchain throughput, with sub-second latency, by an order of magnitude.

Figures (12)

• Figure 1: Illustration of the pipelined architecture of modern blockchains such as Aptos Blockchain aptos-whitepaper. The figure shows client ${\sf C}_{i}\xspace$, fullnode ${\sf F}_{i}\xspace$, and validator ${\sf V}_{i}\xspace$. Each box represents a stage in the blockchain that a block of transactions needs to go through from left to right. The pipeline consists four stages, including consensus (which consists dissemination and ordering), execution, certification and commit.
• Figure 2: Illustration of Zaptos. The left figure illustrates the Zaptos's parallel pipeline architecture. It shows client ${\sf C}_{i}\xspace$, fullnode ${\sf F}_{i}\xspace$, and validator ${\sf V}_{i}\xspace$, and each box represents a stage in the blockchain that a block of transactions needs to go through from left to right. The right figure illustrates the dependencies between stages of the same block. Solid arrow denotes direct dependency (a stage starts immediately once all its direct dependencies finishes), dotted arrow denotes indirect dependency (stages connected via more than one direct dependencies). The receipt of block proposal triggers opt-execution. The finishing of opt-execution triggers opt-commit, and triggers certification once OrderVote is also sent. When the state is certified and opt-commit finishes, the commit is completed.
• Figure 3: Illustration of the pipelining of consecutive blocks in the Aptos Blockchain. A validator can pipeline different stages of consecutive blocks, e.g., for blocks ${\sf B}\xspace_1,{\sf B}\xspace_2,{\sf B}\xspace_3$ in the figure, in the dotted slot, the validator can perform in parallel the commit stage (IO-intensive) of ${\sf B}\xspace_1$, the certification stage of ${\sf B}\xspace_2$, the execution stage (CPU-intensive) of ${\sf B}\xspace_3$, and the consensus stage (network-intensive) of subsequent blocks. In practice, the durations of the stages may vary, leading to imperfect alignment. As long as the parallel stages utilize distinct resources, the pipeline improves throughput by maximizing resource utilization compared to non-pipelined designs.
• Figure 4: Illustration of the pipelining of consecutive blocks in Zaptos. The left figure illustrates the pipelining. Similar to \ref{['fig:pipeline-baseline']}, a validator can also pipeline different stages of consecutive blocks. The right figure illustrates the dependencies between stages of consecutive blocks, e.g., the execution and commit stages of block ${\sf B}\xspace_2$ also depends on the execution and commit stages of its parent block ${\sf B}\xspace_1$, respectively. The boxes representing stages have been slimmed down for presentation purposes only.
• Figure 5: Common case performance of Zaptos and Aptos Blockchain.

Theorems & Definitions (5)

• definition 1: BFT SMR
• corollary 1
• theorem 1
• theorem 2
• corollary 2