Pith. sign in

REVIEW 3 major objections 3 minor 63 references

Zaptos: Towards Optimal Blockchain Latency

T0 review · 3 major / 3 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Zaptos claims that end-to-end blockchain latency can be reduced to consensus latency plus two unavoidable network hops, by optimistically executing and certifying blocks before consensus orders them.

desk verdict A genuinely useful and mostly honest pipeline-latency optimization for blockchains, with a clean safety proof and a real 25–40% win over its baseline, but the absolute 'sub-second at 20k TPS' claim rests on a measurement that omits the client-to-fullnode hops the paper's own model includes. read the letter →

arxiv 2501.10612 v1 pith:W64BCBNY submitted 2025-01-18 cs.DC cs.CR

Zhuolun Xiang , Zekun Li , Balaji Arun , Teng Zhang , Alexander Spiegelman This is my paper · ORCID
classification cs.DCcs.CR
keywords blockchainlatencypipelinedarchitectureparallelpipelineoptimisticexecutioncommitstatecertificationByzantinefaulttolerancehighthroughput
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Zaptos is a blockchain pipeline architecture that claims most of the latency users experience today is not consensus itself but the stages that follow it: execution, certification of the new state, and writing it to storage. The paper argues these stages can be run optimistically, in parallel with the rounds in which validators are still agreeing on a block's order. If that claim holds, a transaction can be confirmed almost as soon as consensus finishes, and the end-to-end latency equals the consensus latency plus two unavoidable client-to-fullnode and fullnode-to-validator hops. The authors implement this architecture on top of the Aptos blockchain and report sub-second end-to-end confirmation at 20,000 transactions per second on a 100-validator geo-distributed testbed, with 25-40% lower latency than the baseline pipeline.

What carries the argument

The mechanism is a parallel pipeline in which the three post-consensus stages - execution, state certification, and storage commit - are optimistically started on the block proposal itself rather than on the ordered block. The load-bearing identity is Theorem 4.3's latency formula: $T_{zaptos} = 2\delta_{cf} + 2\delta_{fv} + T_{con} + \max(T_{exe} - \delta_{vv}, 0) + \max(T_{cmt} - \delta_{vv}, 0) + \max(T_{exe} + T_{cmt} - 2\delta_{vv}, 0)$, which collapses to $2\delta_{cf} + 2\delta_{fv} + T_{con}$ when execution and commit each fit inside a round. Safety is carried by piggybacking certification votes on OrderVote: if enough honest validators certify a state before ordering, those same validators have voted to order the block, so the block can no longer be forked. That 'certified implies ordered' invariant is what lets the optimistic work be safe.

What would settle it

Deploy the same 100-validator, 64-core workload but place clients and fullnodes at network distances representative of real users (e.g., 50-100 milliseconds one-way per hop) and measure the median time from client submission to receipt of a valid inclusion proof. If that time exceeds one second at 20k TPS, the sub-second end-to-end claim is refuted; if it stays under one second, the optimistic-shadowing claim holds in a full end-to-end deployment.

Watch

Extended reading notes

Core claim

The paper's central claim is that end-to-end blockchain latency can be reduced to the consensus latency itself by optimistically shadowing every post-consensus stage. Concretely: a validator executes a block as soon as it receives the proposal rather than after the block is ordered; it writes the resulting state to storage before certification completes; and it piggybacks its certification vote on the final OrderVote message of consensus. The paper proves that the resulting protocol still satisfies Byzantine fault tolerant safety and liveness, and that when execution and commit each finish within one network round, Zaptos's end-to-end latency is $2\delta_{cf} + 2\delta_{fv} + T_{con}$, which is five rounds faster than the baseline Aptos pipeline whenever execution and commit each take at least one round. In the deployed system this yields 0.78 seconds at 20k TPS on 64-core machines, against 1.32 seconds for the baseline.

Load-bearing premise

The evaluation assumes client-to-fullnode and fullnode-to-validator latencies are negligible by co-locating those components with validators, while the paper's own end-to-end definition includes those two hops; if those hops take realistic internet time, the reported sub-second result at 20k TPS would be slower than one second.

Editorial extensions

If this is right

  • Any blockchain whose consensus ends with an OrderVote round can adopt the three optimizations and expect end-to-end latency equal to its consensus latency plus the two unavoidable client-side hops, provided execution and commit each finish within one network round.
  • The deployed system sets a new operating point on the throughput-latency curve: 20k TPS at 0.78 seconds median end-to-end latency, versus 1.32 seconds for the baseline at the same throughput.
  • When execution or commit takes longer than one round, Zaptos does not fully shadow them; Theorem 4.3 gives the exact residual latency, so system operators can predict when the optimization stops being complete.
  • In a client-to-validator model, Zaptos's optimizations still reduce latency by three rounds, so the architecture applies beyond the fullnode-based model used by Aptos.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's common-case numbers collapse client-to-fullnode and fullnode-to-validator hops to zero, so the reported 0.78 seconds at 20k TPS should be read as a lower bound; adding just 50 milliseconds per hop yields roughly 0.98 seconds, already near the one-second line.
  • The safety argument for piggybacked certification relies on the consensus protocol ending with a dedicated OrderVote round; DAG-based protocols whose finality is determined structurally rather than by a final vote round would need an equivalent step before the certification trick transfers unchanged.
  • The paper does not quantify the cost of reverting optimistically committed but orphaned blocks; under sustained leader equivocation, storage reversion could offset some of the common-case latency gains, although the failure experiments show Zaptos still improves average latency.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. The paper proposes Zaptos, a pipelined blockchain architecture that overlaps execution, certification, and commit with consensus. Three optimizations are introduced: optimistic execution when a block proposal is first received, optimistic commit to storage before certification, and piggybacking CertifyVote messages onto consensus OrderVote messages. The paper proves BFT SMR safety and liveness (Theorem 4.2), derives latency formulas for the Aptos baseline and Zaptos (Theorem 4.3), and evaluates a Rust implementation on a geo-distributed 100-validator testbed, reporting 25--40% latency reduction relative to the authors' own Aptos baseline and a headline of sub-second latency at 20,000 TPS.

Significance. If the results hold, Zaptos is a valuable and relatively simple latency optimization for pipeline-based blockchains. The safety proof is clean and does not rely on fitted parameters; the latency model is explicit and falsifiable; and the implementation is substantial, building on the production Aptos codebase. The comparative evaluation against the Aptos baseline is internally consistent and supports the claimed 25--40% reduction. The main concerns are with the absolute headline claims and with the correctness of the latency equality in Theorem 4.3, not with the core architectural idea.

major comments (3)
  1. [§4.4, Eqs. (1)--(2), Corollary 4.4] I cannot reproduce Eq. (2) as an equality from Algorithm 2. As a concrete counterexample, set δcf=δfv=0, δvv=1, Texe=Tcmt=2, and take dissemination D=1.5 so that Tcon=4.5. Eq. (2) gives Tzaptos = 4.5 + (2−1) + (2−1) + (2+2−2) = 8.5, and Eq. (1) gives Tbaseline = 1 + 4.5 + 4 + 4 = 13.5, a reduction of 5. Tracing the algorithm, validators receive the proposal at D+δ=2.5, finish optimistic execution at 4.5, send CertifyVote at 4.5, aggregate it at 5.5, and finish optimistic commit at 6.5; the fullnode is co-located, so the Zaptos latency is 6.5, not 8.5, and the reduction is 7. The problem is that the three max terms in Eq. (2) are treated as additive independent delays, whereas the correct extra over Tcon should be a single max of the relevant completion times. The theorem should be corrected, or explicitly restated as an upper bound, and Corollary 4.4 should say 'at least 5 rounds' rather than '5 rounds'.
  2. [§6.1 Metrics; §6.2 Figure 5b; Abstract] The paper's own definition of end-to-end blockchain latency (Section 2.4) and Theorem 4.3 include 2δcf + 2δfv, yet the evaluation metric in Section 6.1 is 'measured from the fullnode receives the client's transaction to fullnodes commits the client's transaction,' with clients and fullnodes co-located with validators. Thus the reported 0.78s at 20k TPS (Figure 5b) omits the client-to-fullnode round trip and, by co-location, the fullnode-to-validator latencies that the stated definition includes. Adding δcf=δfv=50ms gives approximately 0.98s, and δcf=δfv=100ms gives approximately 1.18s, so the abstract's 'sub-second latency at 20,000 TPS' is not established by the experiment as reported. The authors explicitly acknowledge this simplification in Section 6.1; my concern is that it is load-bearing for the absolute headline, even though the comparative 25--40% reduction is unaffected. Please either measure the full path, or re-label the claim as validator-side/fullnode-side latency.
  3. [Abstract; §6.2] The claim that Zaptos 'surpasses previously reported blockchain throughput, with sub-second latency, by an order of magnitude' is not supported by any comparison in the evaluation. Figure 5 compares only Zaptos with the authors' own Aptos baseline; no data from other blockchain systems are reported, even though references [5] and [10] are cited as latency benchmarks. Either provide the comparative data or remove/qualify the order-of-magnitude statement.
minor comments (3)
  1. [§2.3, §7] There are stray LaTeX artifacts and typos: '⁄pilcrow' and '∥' in Section 2.3, 'as followings' and 'cruicial' in Section 7, and 'transaciton' in the related-work discussion. These should be cleaned up.
  2. [§6.2] Figure 5 reports 25th/75th percentile bars but does not state how many experiment repetitions were run or whether the plotted points are single runs. Please state the number of runs and how the reported percentiles are aggregated across runs.
  3. [§4.4] The sentence 'Results from Section 6.2 under medium load also partially validates Theorem 4.3' appears before the evaluation and without a specific pointer. Consider moving this remark to Section 6 and making the comparison quantitative, especially given the issue with Eq. (2) noted above.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the latency theorems are self-contained derivations from stated architectural assumptions, and the evaluation is a comparative implementation measurement, not a fitted prediction.

full rationale

The paper's central theoretical claim, Theorem 4.3, is a closed-form calculation from stated variables (δcf, δfv, δvv, Tcon, Texe, Tcmt) and the stage dependencies of Algorithms 1 and 2. Corollary 4.4's 5-round improvement follows algebraically from the theorem's formulas when Texe ≥ δvv and Tcmt ≥ δvv; no parameter in the formula is fitted to the experimental curves, so the '5 rounds' result is not a renamed fit. The optimality statement is explicitly conditional: if the consensus protocol has optimal latency and the client-fullnode-validator path is assumed unavoidable, then the pipeline achieves 2δcf + 2δfv + Tcon. That is a stated architectural assumption, not a conclusion forced by definition. The evaluation does not fit the theory to data; it measures both systems and notes that the breakdown 'partially validates' the theorem, which is legitimate support rather than circularity. Self-citations appear for implementation components (Jolteon*, Block-STM, Aptos AIPs) and for some consensus-latency references, but the load-bearing lower bound is also backed by an external reference [41], and the order-vote interface is satisfied by many non-self protocols (PBFT, Tendermint, HotStuff, etc.). Thus no load-bearing argument reduces to a self-citation chain. Finally, Section 6.1's decision to treat client-to-fullnode and fullnode-to-validator latencies as negligible is an explicit scoping assumption that affects the interpretation of the reported absolute 'sub-second end-to-end' number, but it is not a circular derivation: the measured value is not used to define the theoretical result, and the comparative latency-reduction claim is unaffected because both systems incur the same omitted hops.

Assumptions & free parameters 0 free parameters · 7 assumptions · 0 invented entities

No free parameters are fitted; the latency formulas use symbolic constants and conditional inequalities. The axioms are the standard synchrony, fault, channel, consensus-interface, and determinism assumptions plus two modeling simplifications: the constant-delay latency model and the negligible client-hop evaluation setting.

assumptions (7)
  • domain assumption Partial synchrony with GST and bounded delays after GST (Section 2.1).
    Underlies the liveness argument for consensus and the eventual ordering of blocks in Corollary 4.1.
  • domain assumption BFT model with n=3f+1 validators and up to f malicious (Section 2.1).
    Provides the quorum size 2f+1 used throughout the safety proof.
  • domain assumption Reliable and authenticated point-to-point channels (Section 2.1).
    Needed for validators to verify signatures and for messages to be delivered eventually.
  • domain assumption Consensus provides Block Proposal, Order Vote, Order Proof and satisfies Safety/Liveness (Section 2.3).
    Zaptos's safety proof (Theorem 4.2) and Corollary 4.1 rely on these interfaces and on the consensus Safety/Liveness guarantees.
  • domain assumption Execution is deterministic (Section 2.3).
    Required for CertifyVote messages to refer to the same state digest and for commit consistency.
  • ad hoc to paper Latency model with constant symmetric delays and equal stage times (Section 4.4).
    Used in Theorem 4.3 to derive the 5-round improvement; real stage times vary with load and hardware.
  • ad hoc to paper Evaluation simplification: client-fullnode and fullnode-validator latencies negligible (Section 6.1).
    Makes the measured metric a fullnode end-to-end latency, not the client-to-client end-to-end latency defined in Section 2.4.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Zaptos: Towards Optimal Blockchain Latency." pith.science (2026). https://pith.science/paper/W64BCBNY

@misc{pith2026250110612,
  author       = {Pith},
  title        = {Pith review of: Zaptos: Towards Optimal Blockchain Latency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W64BCBNY}},
  note         = {Machine review of arXiv:2501.10612}
}
read the original 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

Figures reproduced from arXiv: 2501.10612 by the authors.

Figure 1
Figure 1. Illustration of the pipelined architecture of modern blockchains such as Aptos Blockchain [ [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Illustration of Zaptos. The left figure illustrates the Zaptos’s parallel pipeline architecture. It shows client [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Illustration of the pipelining of consecutive blocks in the [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Illustration of the pipelining of consecutive blocks in Zap [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Common case performance of Zaptos and Aptos [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Latency breakdown of common case: 32 CPUs. [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: Latency breakdown of common case: 64 CPUs. [PITH_FULL_IMAGE:figures/full_fig_p012_7.png]
Figure 8
Figure 8. Figure 8: Failure case performance of Zaptos and Aptos Blockchain, [PITH_FULL_IMAGE:figures/full_fig_p012_8.png]
Figure 9
Figure 9. Figure 9: Illustration of the coupled-consensus-execution pipeline [PITH_FULL_IMAGE:figures/full_fig_p016_9.png]
Figure 11
Figure 11. Figure 11: Illustration of the consensus-then-execution pipeline ar [PITH_FULL_IMAGE:figures/full_fig_p016_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

63 extracted references · 56 canonical work pages

  1. [5]

    Aptos. 2024. E2E Latency Comparison Benchmark. https://github.com/aptos- labs/e2e-latency-bench

    work page 2024

  2. [10]

    Aptos. 2024. Real-time E2E Latency Comparison Dashboard of Ma- jor Blockchains. https://aptoslabs.grafana.net/public-dashboards/ f32a07a7ef01456cbb9f79ac975fb00e?orgId=1&refresh=15m

    work page 2024

  3. [1]

    Ittai Abraham, Kartik Nayak, Ling Ren, and Zhuolun Xiang. 2021. Good-case latency of byzantine broadcast: A complete categorization. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing . 331–341

    work page 2021

  4. [2]

    Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Lavent- man, Yacov Manevich, et al. 2018. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference. 1–15

    work page 2018

  5. [3]

    Aptos. 2022. The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infras- tructure. https://aptosfoundation.org/whitepaper/aptos-whitepaper_en.pdf

    work page 2022

  6. [4]

    Aptos. 2023. AIP-33 - Block Gas Limit. https://github.com/aptos-foundation/ AIPs/blob/main/aips/aip-33.md

    work page 2023

  7. [6]

    Aptos. 2024. Gas and Storage Fees. https://aptos.dev/en/network/blockchain/gas- txn-fee

    work page 2024

  8. [7]

    Aptos. 2024. Move - A Web3 Language and Runtime. https://aptos.dev/en/ network/blockchain/move

    work page 2024

Show all 63 references
  1. [8]

    Aptos. 2024. Official implementation in Rust. https://github.com/aptos-labs/ aptos-core

    2024

  2. [9]

    Aptos. 2024. The pipeline implementation. https://github.com/aptos-labs/aptos- core/tree/main/consensus/src/pipeline

    2024

  3. [11]

    Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegel- man. 2024. Shoal++: High Throughput DAG BFT Can Be Fast! arXiv preprint arXiv:2405.20488 (2024)

    2024 arXiv

  4. [12]

    Kushal Babel, Andrey Chursin, George Danezis, Lefteris Kokoris-Kogias, and Al- berto Sonnino. 2023. Mysticeti: Low-Latency DAG Consensus with Fast Commit Path. arXiv preprint arXiv:2310.14821 (2023)

    2023

  5. [13]

    Sam Blackshear, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Xun Li, Mark Logan, Ashok Menon, Todd Nowacki, Alberto Sonnino, et al . 2024. Sui lutris: A blockchain combining broadcast and con- sensus. In Proceedings of the 2024 on ACM SIGSAC Co...

    2024

  6. [14]

    Dan Boneh, Ben Lynn, and Hovav Shacham. 2001. Short signatures from the Weil pairing. In Advances in Cryptology—ASIACRYPT 2001: 7th International Conference on the Theory and Application of Cryptology and Information Security Gold Coast, Australia, December 9–13, 2001 Proceedi...

    2001

  7. [15]

    Ethan Buchman. 2016. Tendermint: Byzantine fault tolerance in the age of blockchains. Ph. D. Dissertation

    2016

  8. [16]

    Vitalik Buterin and Virgil Griffith. 2017. Casper the friendly finality gadget.arXiv preprint arXiv:1710.09437 (2017)

    2017 arXiv

  9. [17]

    Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. 2001. Se- cure and efficient asynchronous broadcast protocols. In Annual International Cryptology Conference. Springer, 524–541

    2001

  10. [18]

    Daniel Cason, Enrique Fynn, Nenad Milosevic, Zarko Milosevic, Ethan Buchman, and Fernando Pedone. 2021. The design, architecture and performance of the tendermint blockchain network. In 2021 40th International Symposium on Reliable Distributed Systems (SRDS). IEEE, 23–33

    2021

  11. [19]

    Miguel Castro and Barbara Liskov. 1999. Practical Byzantine fault tolerance. In Proceedings of the third Symposium on Operating Systems Design and Implementa- tion (OSDI). USENIX Association, 173–186

    1999

  12. [20]

    Benjamin Y Chan and Elaine Shi. 2020. Streamlet: Textbook Streamlined Blockchains. In Proceedings of the 1st ACM Conference on Advances in Finan- cial Technologies (AFT)

    2020

  13. [21]

    Wuhui Chen, Ding Xia, Zhongteng Cai, Hong-Ning Dai, Jianting Zhang, Zicong Hong, Junyuan Liang, and Zibin Zheng. 2024. Porygon: Scaling Blockchain via 3D Parallelism. In 2024 IEEE 40th International Conference on Data Engineering (ICDE). IEEE, 1944–1957

    2024

  14. [22]

    Shir Cohen, Rati Gelashvili, Lefteris Kokoris Kogias, Zekun Li, Dahlia Malkhi, Alberto Sonnino, and Alexander Spiegelman. 2022. Be aware of your leaders. In International Conference on Financial Cryptography and Data Security . Springer, 279–295

    2022

  15. [23]

    Tyler Crain, Christopher Natoli, and Vincent Gramoli. 2021. Red belly: A secure, fair and scalable open blockchain. In2021 IEEE Symposium on Security and Privacy (SP). IEEE, 466–483

    2021

  16. [24]

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegel- man. 2022. Narwhal and Tusk: a DAG-based mempool and efficient BFT consen- sus. In Proceedings of the Seventeenth European Conference on Computer Systems . 34–50

    2022

  17. [25]

    Diem. 2020. The Diem Blockchain. https://developers.diem.com/docs/technical- papers/the-diem-blockchain-paper/

    2020

  18. [26]

    Diem. 2020. The pipeline implementation. https://github.com/diem/diem/tree/ main/consensus/src/experimental

    2020

  19. [27]

    Diem. 2024. Official implementation in Rust. https://github.com/diem/diem

    2024

  20. [28]

    Isaac Doidge, Raghavendra Ramesh, Nibesh Shrestha, and Joshua Tobkin. 2024. Moonshot: Optimizing Chain-Based Rotating Leader BFT via Optimistic Propos- als. arXiv preprint arXiv:2401.01791 (2024)

    2024 arXiv

  21. [29]

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988. Consensus in the presence of partial synchrony. Journal of the ACM (JACM) 35, 2 (1988), 288–323

    1988

  22. [30]

    Ethereum. 2024. Gas and fees. https://ethereum.org/en/developers/docs/gas/

    2024

  23. [31]

    Ethereum. 2024. Gas and fees: block-size. https://ethereum.org/en/developers/ docs/gas/#block-size

    2024

  24. [32]

    Facebook. 2013. RocksDB: A Persistent Key-Value Store for Fast Storage Envi- ronments. https://rocksdb.org

    2013

  25. [33]

    Ethereum Foundation. 2020. PROOF-OF-STAKE (POS). https://ethereum.org/en/ developers/docs/consensus-mechanisms/pos/. (2020)

    2020

  26. [34]

    Zhenhuan Gao, Yuxuan Hu, and Qinfan Wu. 2021. Jellyfish Merkle Tree

    2021

  27. [35]

    Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang. 2022. Jolteon and ditto: Network-adaptive efficient consensus with asynchronous fallback. In International conference on financial cryptography and data security. Springer, 296–315

    2022

  28. [36]

    Rati Gelashvili, Alexander Spiegelman, Zhuolun Xiang, George Danezis, Zekun Li, Dahlia Malkhi, Yu Xia, and Runtian Zhou. 2023. Block-stm: Scaling blockchain Zaptos: Towards Optimal Blockchain Latency Conference’17, July 2017, Washington, DC, USA execution by turning ordering c...

    2023

  29. [37]

    Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zel- dovich. 2017. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th symposium on operating systems principles . 51–68

    2017

  30. [38]

    Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. 2019. SBFT: a scalable and decentralized trust infrastructure. In 2019 49th Annual IEEE/IFIP International Conference on Depend...

    2019

  31. [39]

    Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman

  32. [40]

    Idit Keidar, Oded Naor, Ouri Poupko, and Ehud Shapiro. 2022. Cordial miners: Fast and efficient consensus for every eventuality.arXiv preprint arXiv:2205.09174 (2022)

    2022 arXiv

  33. [41]

    Petr Kuznetsov, Andrei Tonkikh, and Yan X Zhang. 2021. Revisiting optimal resilience of fast byzantine consensus. InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing . 343–353

    2021

  34. [42]

    Aptos Labs. 2024. AIP-106 - Optimistic Quorum Store. https://github.com/aptos- foundation/AIPs/blob/main/aips/aip-106.md

    2024

  35. [43]

    Aptos Labs. 2024. AIP-89 Consensus Latency Reduction using Order Votes. https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-89.md

    2024

  36. [44]

    LESLIE LAMPORT, ROBERT SHOSTAK, and MARSHALL PEASE. 1982. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4, 3 (1982), 382–401

    1982

  37. [45]

    Zekun Li. 2021. [dip-213] decoupled execution. https://github.com/diem/dip/ pull/214

    2021

  38. [46]

    David Mazieres. 2015. The stellar consensus protocol: A federated model for internet-level consensus. Stellar Development Foundation 32 (2015), 1–45

    2015

  39. [47]

    Ralph C Merkle. 1987. A digital signature based on a conventional encryption function. In Conference on the theory and application of cryptographic techniques . Springer, 369–378

    1987

  40. [48]

    Satoshi Nakamoto. 2008. Bitcoin whitepaper. URL: https://bitcoin. org/bitcoin. pdf-(: 17.07. 2019) 9 (2008), 15

    2008

  41. [49]

    NEAR. 2024. Consensus. https://nomicon.io/ChainSpec/Consensus

    2024

  42. [50]

    Patrick O’Grady. 2024. Vryx: Fortifying Decoupled State Machine Repli- cation. https://hackmd.io/@patrickogrady/rys8mdl5p#Vryx-Fortifying- Decoupled-State-Machine-Replication

    2024

  43. [51]

    Rust. 2024. blstrs library. https://docs.rs/blstrs/latest/blstrs/

    2024

  44. [52]

    Rust. 2024. Rust Programming Language. https://www.rust-lang.org/

    2024

  45. [53]

    Rust. 2024. tokio library. https://docs.rs/tokio/latest/tokio/

    2024

  46. [54]

    Rust. 2024. Trait Future. https://doc.rust-lang.org/std/future/trait.Future.html

    2024

  47. [55]

    Solana. 2024. Whitepaper. https://solana.com/solana-whitepaper.pdf

    2024

  48. [56]

    Alexander Spiegelman, Balaji Aurn, Rati Gelashvili, and Zekun Li. 2023. Shoal: Improving dag-bft latency and robustness. InInternational Conference on Financial Cryptography and Data Security . Springer

    2023

  49. [57]

    Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris- Kogias. 2022. Bullshark: Dag bft protocols made practical. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security . 2705–2718

    2022

  50. [58]

    Chrysoula Stathakopoulou, Tudor David, and Marko Vukolic. 2019. Mir-bft: High-throughput bft for blockchains. arXiv preprint arXiv:1906.05552 92 (2019)

    2019 arXiv

  51. [59]

    Sui. 2024. Official implementation in Rust. https://github.com/MystenLabs/sui

    2024

  52. [60]

    XRP. 2024. Consensus Protocol. https://xrpl.org/docs/concepts/consensus- protocol

    2024

  53. [61]

    Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abra- ham. 2019. Hotstuff: Bft consensus with linearity and responsiveness. In Proceed- ings of the 2019 ACM Symposium on Principles of Distributed Computing . ACM, 347–356

    2019

  54. [62]

    Saman Taghavi Zargar, James Joshi, and David Tipper. 2013. A survey of defense mechanisms against distributed denial of service (DDoS) flooding attacks. IEEE communications surveys & tutorials 15, 4 (2013), 2046–2069. Conference’17, July 2017, Washington, DC, USA Figure 9: Ill...

    2013

  55. [2021]

    InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing

    All you need is dag. InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing. 165–175

    2021

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.