{"id":"652a2d1b-0e56-4f92-9a6b-6a3cbea08516","arxiv_id":"2501.10612","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"By overlapping execution, storage, and state certification with consensus ordering, Zaptos cuts blockchain latency by up to five network rounds and reports sub-second latency at 20k TPS.","lead":"Zaptos is a redesigned blockchain pipeline that starts executing, storing, and certifying blocks before consensus formally orders them, cutting latency by 25-40% against the Aptos pipeline in geo-distributed tests. It reports 20,000 transactions per second at sub-second latency on 100 validators.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Evaluation's 'end-to-end' latency excludes the two client/fullnode network hops that Theorem 4.3 and the abstract's sub-second claim include; with realistic δcf+δfv the 20k TPS headline is not established.","rationale":"In good faith, the paper's core contribution is a plausible parallel-pipeline architecture: optimistic execution, optimistic commit, and piggybacked certification are described concretely, the safety proof in Theorem 4.2 is internally consistent, and the latency accounting in Theorem 4.3 cleanly separates consensus, execution, certification, and commit phases. The comparative evaluation against the authors' Aptos baseline supports a meaningful latency reduction, and the Byzantine failure experiments add useful evidence. The single most load-bearing concern is the mismatch between the paper's definition of end-to-end latency and the metric actually measured. The manuscript explicitly admits in Section 6.1 that client-to-fullnode and fullnode-to-validator latencies are assumed negligible and that clients/fullnodes are co-located with validators, while the abstract and Section 6.2 make absolute sub-second and order-of-magnitude claims that depend on those omitted hops. The reader's weakest assumption identifies exactly this gap, and I agree with that assessment. The concern is not that the architecture is unsound; it is that the headline absolute performance number is not yet supported by the experimental evidence as reported. This warrants a conditional verdict rather than acceptance or rejection, and the reader's conditional judgment should stand unchanged. The proposed concrete test—re-running with realistic network hops or injecting the paper's own regional RTT values—would settle whether the sub-second claim survives, and would also clarify whether the claimed margin over prior systems is real or an artifact of the measurement boundary.","tokens_in":22780,"tokens_out":8554,"duration_ms":85258,"concrete_test":"Re-run the 64-CPU, 20k TPS experiment with clients and fullnodes placed at realistic geo-distributed distances (or inject the measured one-way latencies from the paper's stated 25-317ms regional RTT range into the client-to-fullnode and fullnode-to-validator links), keeping the open-loop workload. If the p50 client-observed confirmation latency exceeds 1.0s, the abstract's 'sub-second end-to-end latency at 20k TPS' claim should be revised to 'sub-second pipeline latency' or the omitted network hops must be folded into the reported number. Also report the 25th and 75th percentiles as in Figure 5 to show whether the conclusion is robust across the latency distribution.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The absolute headline claim—'Zaptos achieves 20,000 TPS with sub-second latency' (Abstract) and 'sub-second end-to-end blockchain latency with a throughput of 20,000 TPS' (Section 6.2)—is not supported by the measurement as reported. Theorem 4.3 defines end-to-end latency as 2δcf + 2δfv + Tcon + ... (Section 4.4), where δcf is client-to-fullnode one-way latency and δfv is fullnode-to-validator one-way latency. Section 6.1 states: 'we simplify the experiments by assuming constant and negligible latencies for both client-to-fullnode and fullnode-to-validator communication... we let each fullnode and client be co-located with a validator.' The Metrics paragraph then defines the measured latency as 'measured from the fullnode receives the client's transaction to fullnodes commits the client's transaction,' which excludes the client-to-fullnode submission hop, the fullnode-to-client response hop, and, by co-location, both fullnode-validator hops. Thus the reported 0.78s at 20k TPS (Section 6.2) omits the entire 2δcf + 2δfv term that the paper's own definition and Theorem 4.3 include. Adding realistic one-way values, e.g., δcf = δfv = 50ms, raises the estimate to 0.98s—still nominally sub-second but with no margin; δcf = δfv = 100ms gives 1.18s, above the headline threshold. The comparative 25-40% reduction claim is unaffected because both Zaptos and the Aptos baseline incur the same omitted hops, but the absolute 'sub-second end-to-end' and 'optimal blockchain latency' claims are not established by the presented experiment. This is an evaluation-to-claim mapping gap, not a demonstrated flaw in the parallel-pipeline mechanism or its safety proof.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":23130,"tokens_out":34806,"duration_ms":330576,"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":[{"comment":"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'.","section":"§4.4, Eqs. (1)--(2), Corollary 4.4"},{"comment":"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.","section":"§6.1 Metrics; §6.2 Figure 5b; Abstract"},{"comment":"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.","section":"Abstract; §6.2"}],"minor_comments":[{"comment":"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.","section":"§2.3, §7"},{"comment":"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.","section":"§6.2"},{"comment":"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.","section":"§4.4"}],"recommendation":"major_revision","confidential_remarks":"The paper comes from Aptos Labs and evaluates a modification of the Aptos blockchain against the authors' own baseline. This is not itself a problem, but it makes the unsupported 'order of magnitude' headline and the unmeasured client-to-fullnode hops more consequential. The theoretical latency formula in Theorem 4.3 appears to be an overestimate rather than an equality, which should be fixed or carefully restated before the paper can be accepted."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know first: Zaptos is a real optimization, not a mirage. The three ideas—optimistic execution on proposal receipt, optimistic commit before certification, and piggybacking state certification on the consensus OrderVote—are combined in a way I haven't seen before. Porygon piggybacks on a later consensus instance; Zaptos attaches certification to the same block's OrderVote. The safety proof (Theorem 4.2) is clean: if a quorum of CertifyVotes forms before ordering, the OrderVote implies the block cannot fork. The latency accounting (Theorem 4.3) is also a fair derivation from stated assumptions. The authors deserve credit for writing the pipeline architecture down in pseudocode and for releasing a production-grade implementation on the Aptos codebase.\n\nThe comparative result is the paper's real contribution. Against their own Aptos baseline, under identical primitives, they show a 25% latency cut at low load and over 40% at high load. Those numbers will survive scrutiny because both systems incur the same omitted network hops.\n\nNow the soft spots, in order of seriousness. First, the stress-test note is correct and it lands. The paper's own Theorem 4.3 and the abstract define end-to-end latency from client submission to client confirmation, i.e., 2δcf + 2δfv + Tcon + …. But Section 6.1 co-locates clients and fullnodes with validators and then measures \"from the fullnode receives the client's transaction to fullnodes commits the client's transaction.\" That excludes the entire 2δcf + 2δfv term. Add realistic 50ms one-way hops and the reported 0.78s becomes roughly 0.98s; at 100ms hops it is 1.18s. The sub-second headline at 20k TPS is therefore not established by the presented experiment. Second, the abstract's \"by an order of magnitude\" claim comparing to previously reported systems is not backed by any cross-chain benchmark in the paper—it is an assertion. Third, no variance across runs is reported, and the artifact link is a branch rather than a pinned release. These are presentation and evidence gaps, not holes in the mechanism.\n\nIs it a serious paper? Yes. The proof is self-contained, the implementation is substantial, and the comparative latency reduction is credible. A good referee can fix the claims and ask for the missing artifact and variance data. The work is squarely aimed at blockchain systems researchers and practitioners; it deserves refereeing, not desk rejection.","headline":"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.","tokens_in":23674,"tokens_out":1088,"would_cite":true,"duration_ms":13423,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["blockchain latency","pipelined architecture","parallel pipeline","optimistic execution","optimistic commit","state certification","Byzantine fault tolerance","high throughput"],"falsifier":"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.","tokens_in":22550,"feed_emoji":"⚡","tokens_out":9613,"duration_ms":82248,"temperature":0.7,"pith_summary":"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.","feed_headline":"Parallel pipeline cuts blockchain latency to sub-second at 20k TPS","feed_subtitle":"Zaptos runs execution, certification and commit inside consensus, cutting five network rounds per block.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"The open-source Aptos codebase is both the baseline pipeline and the codebase Zaptos extends.","marker":"[8]"},{"why":"The Diem decoupled-execution design that first introduced the pipelined architecture formalized in Algorithm 1.","marker":"[45]"},{"why":"Jolteon, the consensus protocol whose improved form supplies the 3-round ordering latency and order-vote structure used in the evaluation.","marker":"[35]"},{"why":"Moonshot's optimistic-proposal technique is used to reduce the block interval to one round in the deployed system.","marker":"[28]"},{"why":"Block-STM, the parallel execution engine shared by both baseline and Zaptos.","marker":"[36]"},{"why":"The BLS multisignature scheme used to aggregate order proofs and state certificates.","marker":"[14]"},{"why":"The 3-round lower bound on consensus ordering latency used to argue that Zaptos's latency is optimal when execution and commit are fully shadowed.","marker":"[1]"},{"why":"The matching lower bound for fast Byzantine consensus under partial synchrony, cited alongside [1].","marker":"[41]"}],"fun_headline_variants":["Zaptos cuts latency to consensus speed, 20k TPS sub-second","Five rounds faster: Zaptos hits sub-second at 20k TPS","Zaptos: pipeline to sub-second latency at 20k TPS","Zaptos races Aptos: 0.78s block time at 20k TPS","Parallel pipeline: Zaptos slashes latency to 0.78s"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Zaptos cuts latency to consensus speed, 20k TPS sub-second","Five rounds faster: Zaptos hits sub-second at 20k TPS","Zaptos: pipeline to sub-second latency at 20k TPS","Zaptos races Aptos: 0.78s block time at 20k TPS","Parallel pipeline: Zaptos slashes latency to 0.78s"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000951,"raw_usage":{"total_tokens":4024,"prompt_tokens":882,"completion_tokens":3142,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":498,"completion_tokens_details":{"reasoning_tokens":3034}},"tokens_in":498,"tokens_out":3142,"duration_ms":20163,"temperature":1.0,"reasoning_tokens":3034,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T19:02:23.363263+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The open-source Aptos codebase is both the baseline pipeline and the codebase Zaptos extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Diem decoupled-execution design that first introduced the pipelined architecture formalized in Algorithm 1."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Jolteon, the consensus protocol whose improved form supplies the 3-round ordering latency and order-vote structure used in the evaluation."},{"cited_title":"Moonshot: Optimizing Chain-Based Rotating Leader BFT via Optimistic Proposals","cited_arxiv_id":"2401.01791","evidence_quote":"Moonshot's optimistic-proposal technique is used to reduce the block interval to one round in the deployed system."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Block-STM, the parallel execution engine shared by both baseline and Zaptos."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The BLS multisignature scheme used to aggregate order proofs and state certificates."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The 3-round lower bound on consensus ordering latency used to argue that Zaptos's latency is optimal when execution and commit are fully shadowed."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The matching lower bound for fast Byzantine consensus under partial synchrony, cited alongside [1]."}],"review_version":1}