Beluga: Block Synchronization for BFT Consensus Protocols

Alberto Sonnino; Arun Koshy; Ilya Sergey; Jianting Zhang; Lefteris Kokoris-Kogias; Mingwei Tian; Tasos Kichidis

REVIEW 4 major objections 5 minor 1 cited by

Beluga: Block Synchronization for BFT Consensus Protocols

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

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

Pith's one-line read Beluga frames block synchronization as a first-class BFT module and proves it can keep optimistic latency while bounding adversarial recovery cost.

desk verdict A genuinely useful synchronizer abstraction and a real deployment, but the headline adverse-case latency bound depends on an unstated Latency Triangle assumption and a proof with a dimensional error. read the letter →

arxiv 2511.15517 v2 pith:WAJXEKIH submitted 2025-11-19 cs.CR cs.DC

Tasos Kichidis , Lefteris Kokoris-Kogias , Arun Koshy , Ilya Sergey , Alberto Sonnino , Mingwei Tian , Jianting Zhang This is my paper · ORCID

classification cs.CRcs.DC MSC 68M1468M15

keywords blocksynchronizerBFTconsensusreliablebroadcastpullinductionattackDAG-basedprotocolsadmissioncontrolreputationmechanismblockchain

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

The paper argues that the push-pull block-exchange layer under modern high-throughput BFT consensus is not a minor implementation detail but a formal component — the block synchronizer — with three requirements: every block must eventually be retrievable (G1), optimistic-path push latency must stay at the network delay δ (G2), and recovery traffic must remain bounded even when the adversary schedules message delivery (G3). It exhibits a new attack, the pull induction attack, that exploits unstructured push-pull designs to force honest validators into redundant pulls, stalling rounds. Beluga is the paper's instantiation: an admission-controlled push phase plus a hybrid pull phase that separates 'live' pulls (deterministic, latency-critical) from 'bulk' pulls (random, bandwidth-cheap), using an implicit proof-of-availability to accept blocks even when ancestors are temporarily missing. If the claims hold, any DAG-based BFT protocol can gain robust recovery without sacrificing happy-path speed, and real deployments can shake off targeted latency attacks.

What carries the argument

The ImPoA mechanism is the load-bearing object: a block is implicitly available when at least f+1 subsequent blocks (strong or weak links) reference it, which constitutes an implicit certificate of causal availability. Around it sit the admission-control push (reputation table with asymmetric decreases, parent selection of the top 2f+1 reputations) and the hybrid pull (deterministic pulls for live blocks on the critical path, randomized pulls for bulk blocks off the critical path). Together they keep pushes at one network delay while bounding pull amplification.

What would settle it

Run a 10-validator Beluga deployment with three Byzantine validators that each round share blocks with exactly one honest validator (the Sec. 3.1 pattern) and measure per-round latency; the paper predicts it converges to near 2Δ after stabilization. Alternatively, construct a network where honest pairwise paths are consistently slower than a two-hop relay through an honest intermediate (violating the Latency Triangle) and check whether an honest validator's reputation drops and round latency exceeds 2Δ.

Watch

Extended reading notes

Core claim

Beluga claims to be the first block synchronizer simultaneously satisfying G1, G2, G3: eventual availability of every accepted block, optimal δ push latency in the optimistic case, and bounded amplification under adversarial scheduling. The design builds a DAG in which validators reference parents chosen by admission control based on reputation, and it adds weak links, watermarks, and ancestor arrays so that a block is treated as 'implicitly available' once f+1 later blocks reference it. That implicit proof of availability lets validators accept live blocks without waiting for unavailable ancestors, moving missing data off the critical path. The paper proves round latency δ in happy cases an

Load-bearing premise

Theorem 5's nearly-2Δ adverse-case latency relies on Assumption 1 (Latency Triangle): after GST, direct communication between any two honest validators is always faster than relaying through a third validator; if that fails, an honest validator can appear slow, get blamed, and the performance guarantee weakens (correctness itself does not depend on this).

Editorial extensions

If this is right

Mysticeti-style uncertified DAG protocols can keep their δ happy-path latency while gaining the bounded-recovery guarantee they previously lacked.
The pull induction attack, which the paper measures as up to 50x latency inflation and 15x throughput loss on existing systems, is neutralized: admission control stops low-reputation blocks from entering the DAG as parents.
Any BFT consensus protocol that can apply its ordering rules to RBC patterns in the DAG can adopt Beluga as a drop-in dissemination layer without altering safety logic.
Production blockchains can expect tail-latency stability under network degradation; the Sui deployment reports a 5x reduction in 95th-percentile latency under attack.
The block synchronizer abstraction gives protocol designers a single module to specify, verify, and tune for data dissemination, separating it from the safety-critical ordering core.

Reading between the lines

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

The reputation asymmetry (small increases, huge decreases) effectively makes the system game-theoretically stable against rational Byzantine validators: the cost of staging a pull-induction delay exceeds any plausible benefit, so the protocol may push even rational adversaries toward honest dissemination.
If the Latency Triangle assumption fails in real networks — e.g., under network-level routing manipulation or when an intermediate validator has a faster link than the direct pairwise path — the 'nearly 2Δ' guarantee could degrade; an adversarial relay could make honest validators appear slow and trigger the blame mechanism. This is an editorial implication, not stated in the paper.
The same ImPoA idea could be ported to leader-based (PBFT-style) protocols: replacing explicit certificates with implicit availability from later references might cut the two-round certificate overhead while preserving totality guarantees.
A concrete testable extension is to instrument Beluga with a tunable reputation-decrease constant RL and measure the observed worst-case round latency versus the bound's 1/RL dependence; the paper's Theorem 5 predicts a specific quantitative relation.

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.

Desk Editor's Note

read the letter

Short version: Beluga is a serious systems paper with a genuinely useful abstraction and a real deployment, but the headline '~2Δ adverse-case round latency' is conditional on an assumption the abstract doesn't mention, and the proof as written has a dimensional error. The core design is still sound and the paper deserves a real referee.

What's new: the block-synchronizer abstraction is a good way to talk about the push-pull glue that every high-throughput BFT stack actually has. The ImPoA mechanism — using f+1 references from later rounds as implicit availability evidence — is a neat idea that credibly separates live pulls from bulk recovery. Naming the pull induction attack is useful even if the underlying withholding behavior is familiar; formalizing it as a class helps structure the design space. The paper also ships a commit-pinned implementation, reports a production adoption on Sui, and shows large under-attack improvements over their baseline. That's real evidence and should be credited.

Where it's soft: Theorem 5's near-2Δ bound is the main advertised performance claim, and it depends on Assumption 1 (Latency Triangle) in Appendix A. That assumption is not in the abstract and is not part of the standard partial-synchrony model. Without it, Lemma 3 fails: an honest validator with a slow direct link can receive another honest block via a relay first, trigger a pull, accumulate f+1 reports, and get its reputation cut enough to be excluded from parent selection. Since honest blocks need 2f+1 parents, excluding one honest validator can force references to adversary blocks and reintroduce the exact latency the theorem promises to bound. The paper does say correctness doesn't rely on the assumption — that's accurate and important — but the abstract's 'bounding the cost of recovery' and Table 1's ~2Δ entries are performance claims, and those do rely on it.

Also, the proof itself is a sketch. The final formula mixes dimensions: (R_m−R_h)f/(2ΔR_L^2) has units 1/time next to dimensionless terms. That's fixable, but it signals the case analysis isn't tight. G3's 'bounded amplification' is only argued in expectation for the random bulk pull; there's no deterministic bound on retries, which is a gap if G3 is stated categorically. The correctness theorems are also induction sketches rather than machine-checked or fully detailed proofs. The evaluation has no error bars and appears to be single-run, which is typical but still limits confidence. None of these are load-bearing enough to kill the paper — the design is plausible and the empirical direction is clear — but they are exactly what a referee should push on.

Who should read it: anyone working on DAG-based BFT or on making reliable-broadcast guarantees practical. It will be a useful reference for the abstraction and the attack. I'd send it to peer review with a request for a tightened proof, an explicit statement of Assumption 1 in the abstract or a weaker bound without it, and a reproducible evaluation with variance.

Referee Report

4 major / 5 minor

Summary. The paper introduces the block synchronizer abstraction for BFT consensus protocols, specifies desirable goals (G1 eventual availability, G2 optimistic push latency, G3 bounded amplification), identifies a 'pull induction attack' against existing best-effort push/random-pull synchronizers, and presents Beluga, a synchronizer combining an admission-control mechanism based on validator reputation, an optimistic best-effort push, and a hybrid pull protocol that separates live (latency-critical) pulls from bulk (background) pulls using an Implicit Proof-of-Availability (ImPoA) scheme. The authors prove (or sketch proofs) that Beluga satisfies the block-synchronizer properties, claim an average adverse-case round latency approaching 2Δ, and report an implementation integrated into Mysticeti/Sui with AWS experiments showing up to 3× throughput and 25× latency improvements over baseline under the pull induction attack, plus a production deployment on Sui mainnet.

Significance. If the claims are made rigorous, the paper addresses a real and practically important gap: the block-dissemination layer of high-throughput DAG-based BFT protocols is often ad hoc, and the pull induction attack is plausible in deployed systems. Beluga's design ideas—reputation-based admission control, ImPoA to pull off the push path, and the live/bulk distinction—are clever and have been validated in production, which is a meaningful strength. The paper also contributes a clear problem formulation and a comparative table of synchronizer properties. However, the theoretical performance guarantee is the paper's central advertised contribution, and it currently rests on an auxiliary assumption (the Latency Triangle), a dimensional error in the final formula, and an unquantified random-pull amplification bound. The empirical results and the production deployment are valuable, but the analytical claims need to be corrected and restated before the paper can be accepted as a rigorous treatment of bounded-amplification synchronization.

major comments (4)

[Appendix A, proof of Theorem 5] The headline adverse-case claim ('nearly 2Δ' round latency) and Lemma 3 ('honest validators never blamed') rely on Assumption 1 (Latency Triangle), which is introduced only in Appendix A and is not part of the standard partial-synchrony model stated in Sec. 2. Under the stated model, after GST the adversary controls message ordering; it can deliver a block that references an honest validator v_i's block before v_i's direct message reaches v_j. This causes v_j to pull and report v_i. If f+1 honest validators issue such reports, v_i's reputation drops by R_L and admission control may exclude v_i from parent selection, forcing honest proposers to reference adversary-controlled blocks and inducing further pulls. Thus Lemma 3 is false without Assumption 1, and the Theorem 5 bound is not supported in the paper's own network model. The paper notes that correctness does not rely on Assumption 1,
[Appendix A, proof of Theorem 5] The displayed bound at the end of the proof of Theorem 5 is dimensionally inconsistent. The expression is 2Δ(1 + (3+2f)/(2R_L) + (R_m−R_n)f/(2Δ R_L^2)). The second term is dimensionless, while the third term has units 1/Δ if R_m, R_n, R_L are dimensionless reputation scores. Tracing back, |D_2| = (R_m−R_h)f/R_L is a number of rounds, so the extra latency it contributes is |D_2|·2Δ = 2Δ(R_m−R_h)f/R_L, and dividing by R_L rounds gives a term 2Δ(R_m−R_h)f/R_L^2, not a term with Δ in the denominator. The formula as written cannot be evaluated and indicates a unit error in the case analysis. Please correct the algebra and define all quantities with units.
[Sec. 4.3.2 / Sec. 1 G3] The bounded-amplification guarantee (G3) is not rigorously established. For bulk blocks, a validator chooses a provider uniformly at random and retries after timeout Δ_bk if it receives no response. The paper repeatedly uses 'eventually' (e.g., in Theorems 2 and 4) and 'within 2Δ' (e.g., in Lemmas 1 and 2) for this random pull, but no deterministic bound on the number of retries is given. In the worst case, the randomly chosen validator may never be one that stores the block, so the number of pull requests is unbounded. If the intended guarantee is 'with probability 1' or 'in expectation', that should be stated precisely and the theorems should be quantified accordingly. Alternatively, a deterministic fallback (e.g., after O(1) random tries, pull from all validators) would make the amplification bound clean. As written, the proof sketch does not establish G3 under adversarial scheduling.
[Sec. 5.2 / Table 1] Theorem 5 is stated as 'Beluga can achieve a round latency of nearly 2Δ under adverse cases,' but the proof in Appendix A establishes only an average over a window of R_L rounds (Lemma 7). Lemma 5 explicitly allows some rounds to have latency 3Δ, and Lemma 6 shows an average of 2Δ over a pair of rounds. The abstract and Table 1 present the adverse-case latency as '~2Δ' without this caveat. Please state the precise quantification: is the bound per-round, expected per-round, or a long-run average? If the bound is average-only, say so in the theorem statement and in Table 1, and make clear that an adversary can still cause occasional rounds at 3Δ.

minor comments (5)

[Table 1] The rows labeled 'Beluga' under each existing protocol are easy to misread as a separate synchronizer rather than the same Beluga module integrated with that consensus protocol. Consider using an explicit column 'Synchronizer protocol' with entries like 'Beluga (over Multi-chain)'.
[Sec. 4.3.1 and Figure 8] The statement 'a validator references B only if it (i) receives B, and (ii) can verify the availability of B's causal history (lines 4-5, Figure 8)' points to the wrong lines. Lines 4-5 of Figure 8 assign B.parents and B.weaklinks; the 'acceptable' condition is defined in the AC parent selection procedure (line 15). Please fix the pointer.
[Sec. 2] Assumption 1 is used to prove a main theorem but appears only in Appendix A. State it in Sec. 2 or at the start of Sec. 5.2 so the reader knows the adverse-case performance claim is conditional on this assumption.
[Sec. 1] The phrase 'we empirically uncover the same implicit two-phase pattern' is not backed by a description of the empirical methodology in the main text. The paper cites codebases, but no systematic study is described. Please add a sentence explaining the methodology or refer to a separate artifact.
[Sec. 2.1] Round-Progression says 'at least 2f+1 validators (not necessarily honest)' but Theorem 3's proof shows all honest validators progress. Make the definition consistent with the proof, or clarify that honest progress implies the definition.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Beluga's analysis is self-contained; the 2-delta bound is an analytic result under a stated assumption, not a fit, and self-citations are background facts.

full rationale

Beluga's derivation chain is self-contained. The correctness lemmas (Theorems 1-4) verify the block-synchronizer specification directly from the protocol's pseudocode; accepting a block is defined to coincide with receiving/storing it, so these are immediate specification checks, not a prediction reused as input. The adverse-case latency claim (Theorem 5) is an analytic bound under an explicitly stated Assumption 1 (Latency Triangle) and a tunable penalty R_L; R_L is a protocol constant (e.g., 10,000) set before the AWS measurements, and the evaluation is an independent head-to-head comparison against baseline Mysticeti, not a fit of the model to the reported 3x/25x numbers. Self-citations to Mysticeti, Narwhal, Bullshark, and Hammerhead supply background, baseline properties, and design inspiration from published or code-released work; none are used as a uniqueness theorem to force Beluga's design, so they are not load-bearing. The main concerns - the strength of Assumption 1 and the dimensional inconsistency in the final formula of Appendix A - are correctness/robustness issues, not circular reductions: failing the assumption would weaken Lemma 3 and the 2-delta bound, but it does not mean the bound is assumed as an input. No fitted input is renamed as a prediction, and no known result is merely relabelled.

Assumptions & free parameters 2 free parameters · 5 assumptions · 1 invented entities

The central claim rests on the standard partial-synchrony model plus protocol-internal rules (verified references, chaining by author) and, for the adverse-case performance bound, on the non-standard Latency Triangle assumption. The only hand-set free parameter affecting the asymptotic bound is R_L, with a secondary retry timeout Δ_bk left unspecified.

free parameters (2)

R_L (reputation penalty) = 10,000 (default; paper states e.g., RL=10,000)
Chosen by hand in Sec. 4.2; controls how quickly Byzantine validators are excluded and appears in the asymptotic bound of Theorem 5.
Δ_bk (bulk pull retry timeout) = not specified ('some predefined time')
Random bulk-pull retry interval introduced in Sec. 4.3.2; its value affects recovery latency and message complexity but is not instantiated in the paper.

assumptions (5)

domain assumption Assumption 1 (Latency Triangle): after GST, the direct network latency between any two honest validators is always faster than via an intermediate validator.
Stated in Appendix A; necessary for Lemmas 3, 5–7 and Theorem 5, i.e., for the headline adverse-case latency and the claim that honest validators never get blamed.
standard math Partial synchrony with GST and known bound Δ after GST (Dwork et al.).
Standard model adopted from [26] at the start of Sec. 2; underpins all timing analysis.
domain assumption Reliable point-to-point channels between honest parties: any honest message is eventually delivered.
Assumed in Sec. 2 threat model; needed so random pulls eventually reach an honest holder of the block.
domain assumption Each validator's block references its own previous block, so the last accepted block from a validator bounds all earlier blocks of that validator as available.
Invoked in Sec. 4.3.1 for missing-block identification; inherited from Mysticeti [11].
ad hoc to paper A validator references a block via strong/weak links only after verifying availability of the block's causal history (Fig. 8, lines 4–5).
This is the foundation of ImPoA: an implicit certificate consists of f+1 such verified references. It is a protocol-internal assumption, not established by an external theorem.

invented entities (1)

Implicit Proof-of-Availability (ImPoA)
purpose: Lets a validator treat a block as available if referenced by f+1 subsequent blocks, so missing ancestors can be pulled off the critical path.
A new protocol primitive; its correctness rests on the paper's own Theorems 1–2 and the internal assumption about link verification, with no falsifiable handle outside the paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Beluga: Block Synchronization for BFT Consensus Protocols." pith.science (2026). https://pith.science/paper/WAJXEKIH

@misc{pith2026251115517,
  author       = {Pith},
  title        = {Pith review of: Beluga: Block Synchronization for BFT Consensus Protocols},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WAJXEKIH}},
  note         = {Machine review of arXiv:2511.15517}
}

read the original abstract

Modern high-throughput BFT consensus protocols use streamlined push-pull mechanisms to disseminate blocks and keep happy-path performance optimal. Yet state-of-the-art designs lack a principled and efficient way to exchange blocks, which leaves them open to targeted attacks and performance collapse under network asynchrony. This work introduces the concept of a block synchronizer, a simple abstraction that drives incremental block retrieval and enforces resource-aware exchange. Its interface and role fit cleanly inside a modern BFT consensus stack. We also uncover a new attack, where an adversary steers honest validators into redundant, uncoordinated pulls that exhaust bandwidth and stall progress. Beluga is a modular and scarcity-aware instantiation of the block synchronizer. It achieves optimal common-case latency while bounding the cost of recovery under faults and adversarial behavior. We integrate Beluga into Mysticeti, the consensus core of the Sui blockchain, and show on a geo-distributed AWS deployment that Beluga sustains optimal performance in the optimistic path and, under attack, delivers up to 3x higher throughput and 25x lower latency than prior designs. The Sui blockchain adopted Beluga in production.

Figures

Figures reproduced from arXiv: 2511.15517 by the authors.

**Figure 2.** The pull induction attacks: the adversary [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

**Figure 3.** The ImPoA-based hybrid pull protocol for [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Beluga can be integrated into any BFT consensus protocol. By [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

**Figure 5.** Figure 5: Comparative throughput-latency performance of Mysticeti equipped with Beluga and with the baseline push-pull block synchronizer. WAN [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]

**Figure 6.** Figure 6: Comparative throughput-latency performance of Mysticeti [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]

**Figure 8.** Figure 8: Beluga’s AC-based optimistic push protocol for validator [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency
cs.DC 2026-07 accept novelty 7.0 of 10

Vote-counting 2-delay BFT under hybrid faults requires n ≥ 5f + 3c + 1; Orcaella adds a 4-delay path safe against extra alive-but-corrupt faults.

Reference graph

Works this paper leans on

50 extracted references · 4 linked inside Pith · cited by 1 Pith paper

[1]

Prism: Scaling bitcoin by 10,000 x,

L. Yang, V . Bagaria, G. Wang, M. Alizadeh, D. Tse, G. Fanti, and P. Viswanath, “Prism: Scaling bitcoin by 10,000 x,”arXiv preprint arXiv:1909.11261, 2019

arXiv 1909
[2]

Narwhal and tusk: a dag-based mempool and efficient bft consen- sus,

G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Narwhal and tusk: a dag-based mempool and efficient bft consen- sus,” inProceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 34–50

2022
[3]

Tendermint: Byzantine fault tolerance in the age of blockchains,

E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” Ph.D. dissertation, University of Guelph, 2016

2016
[4]

Be aware of your leaders,

S. Cohen, R. Gelashvili, L. K. Kogias, Z. Li, D. Malkhi, A. Sonnino, and A. Spiegelman, “Be aware of your leaders,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2022, pp. 279–295

2022
[5]

Practical byzantine fault tolerance,

M. Castro, B. Liskovet al., “Practical byzantine fault tolerance,” in OsDI, vol. 99, no. 1999, 1999, pp. 173–186

1999
[6]

Autobahn: Seamless high speed bft,

N. Giridharan, F. Suri-Payer, I. Abraham, L. Alvisi, and N. Crooks, “Autobahn: Seamless high speed bft,” inProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, 2024, pp. 1–23

2024
[7]

Hashgraph—scalable hash tables using a sparse graph data structure,

O. Green, “Hashgraph—scalable hash tables using a sparse graph data structure,”ACM Transactions on Parallel Computing (TOPC), vol. 8, no. 2, pp. 1–17, 2021

2021
[8]

The blocklace: A byzantine-repelling and universal conflict-free replicated data type,

P. S. Almeida and E. Shapiro, “The blocklace: A byzantine-repelling and universal conflict-free replicated data type,” 2025. [Online]. Available: https://arxiv.org/abs/2402.08068

arXiv 2025

Show all 50 references

[9]

Grassroots systems: Concept, examples, implementation and applications,

E. Shapiro, “Grassroots systems: Concept, examples, implementation and applications,” 2024. [Online]. Available: https://arxiv.org/abs/ 2301.04391

2024
[10]

Bullshark: Dag bft protocols made practical,

A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris-Kogias, “Bullshark: Dag bft protocols made practical,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2705–2718

2022
[11]

Mysticeti: Reaching the latency limits with uncertified dags,

K. Babel, A. Chursin, G. Danezis, A. Kichidis, L. Kokoris-Kogias, A. Koshy, A. Sonnino, and M. Tian, “Mysticeti: Reaching the latency limits with uncertified dags,” inNetwork and Distributed Systems Security Symposium (NDSS), 2025

2025
[12]

Cachin, R

C. Cachin, R. Guerraoui, and L. Rodrigues,Introduction to reliable and secure distributed programming. Springer Science & Business Media, 2011

2011
[13]

Sui blockchain,

MystenLabs, “Sui blockchain,” https://github.com/mystenlabs/sui, 2025, accessed: 2025

2025
[14]

Narwhal and tusk implementation,

A. Sonnino, “Narwhal and tusk implementation,” https://github.com/ asonnino/narwhal, 2025, accessed: 2025

2025
[15]

Hotstuff implementation,

——, “Hotstuff implementation,” https://github.com/asonnino/ hotstuff/tree/3-chain, 2025, accessed: 2025

2025
[16]

Mysticeti: Low-latency dag consensus with fast commit path,

M. Labs, “Mysticeti: Low-latency dag consensus with fast commit path,” https://github.com/asonnino/mysticeti, 2024

2024
[17]

Jolteon implementation,

A. Sonnino, “Jolteon implementation,” https://github.com/asonnino/ hotstuff, 2025, accessed: 2025

2025
[18]

Diem blockchain,

Diem Association, “Diem blockchain,” https://github.com/diem/diem, 2025, accessed: 2025

2025
[19]

Autobahn artifact,

N. Giridharan, “Autobahn artifact,” https://github.com/neilgiri/ autobahn-artifact, 2025, accessed: 2025

2025
[20]

Mahi-mahi consensus implementation,

P. Tennage, “Mahi-mahi consensus implementation,” https://github. com/PasinduTennage/mahi-mahi-consensus, 2025, accessed: 2025

2025
[21]

Ditto implementation,

D. Xiang, “Ditto implementation,” https://github.com/danielxiangzl/ Ditto, 2025, accessed: 2025

2025
[22]

Asynchronous byzantine agreement protocols,

G. Bracha, “Asynchronous byzantine agreement protocols,”Informa- tion and computation, vol. 75, no. 2, pp. 130–143, 1987

1987
[23]

Bullshark implementation,

A. Sonnino, “Bullshark implementation,” https://github.com/ asonnino/narwhal/tree/bullshark, 2025, accessed: 2025

2025
[24]

Sailfish codebase,

Nibesh Shrestha, “Sailfish codebase,” https://github.com/nibeshrestha/ sailfish, 2025, accessed: 2025

2025
[25]

“Sui,” https://sui.io/, 2024

2024
[26]

Consensus in the presence of partial synchrony,

C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,”Journal of the ACM, vol. 35, no. 2, pp. 288– 323, 1988

1988
[27]

Dashing and star: Byzantine fault tolerance with weak certificates,

S. Duan, H. Zhang, X. Sui, B. Huang, C. Mu, G. Di, and X. Wang, “Dashing and star: Byzantine fault tolerance with weak certificates,” inProceedings of the Nineteenth European Conference on Computer Systems, 2024, pp. 250–264

2024
[28]

Shoal++: High throughput dag bft can be fast!

B. Arun, Z. Li, F. Suri-Payer, S. Das, and A. Spiegelman, “Shoal++: High throughput dag bft can be fast!”arXiv preprint arXiv:2405.20488, 2024

2024 arXiv
[29]

Sailfish: To- wards improving the latency of dag-based bft,

N. Shrestha, R. Shrothrium, A. Kate, and K. Nayak, “Sailfish: To- wards improving the latency of dag-based bft,”Cryptology ePrint Archive, 2024

2024
[30]

Optimistic, signature-free reliable broadcast and its applications,

N. Shrestha, Q. Yu, A. Kate, G. Losa, K. Nayak, and X. Wang, “Optimistic, signature-free reliable broadcast and its applications,” inProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, 2025

2025
[31]

Shoal: Improving DAG-BFT latency and robustness,

A. Spiegelman, B. Arun, R. Gelashvili, and Z. Li, “Shoal: Improving DAG-BFT latency and robustness,” inFinancial Cryptography and Data Security (FC 2024), Revised Selected Papers, Part I, ser. Lecture Notes in Computer Science, vol. 14744. Cham: Springer, 2025, pp. 92–109, fC ...

2024 doi
[32]

Sailfish++ codebase,

Qianyu Yu, “Sailfish++ codebase,” https://github.com/qyu100/ SFSailfish/tree/OptSFSailfish, 2025, accessed: 2025

2025
[33]

Good-case latency of byzantine broadcast: A complete categorization,

I. Abraham, K. Nayak, L. Ren, and Z. Xiang, “Good-case latency of byzantine broadcast: A complete categorization,” inProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, 2021, pp. 331–341

2021
[34]

Asynchronous data dissemination and its applications,

S. Das, Z. Xiang, and L. Ren, “Asynchronous data dissemination and its applications,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 2705–2721

2021
[35]

T. I. team, https://docs.iota.org/about-iota/iota-architecture/consensus, 2025

2025
[36]

Cordial miners: Fast and efficient consensus for every eventuality,

I. Keidar, O. Naor, O. Poupko, and E. Shapiro, “Cordial miners: Fast and efficient consensus for every eventuality,” 2023. [Online]. Available: https://drops.dagstuhl.de/entities/document/10. 4230/LIPIcs.DISC.2023.26

2023
[37]

Twins: Bft systems made robust,

S. Bano, A. Sonnino, A. Chursin, D. Perelman, Z. Li, A. Ching, and D. Malkhi, “Twins: Bft systems made robust,” inACM PODC, 2021

2021
[38]

Hammerhead: Leader reputation for dynamic scheduling,

G. Tsimos, A. Kichidis, A. Sonnino, and L. Kokoris-Kogias, “Hammerhead: Leader reputation for dynamic scheduling,” 2023. [Online]. Available: https://arxiv.org/abs/2309.12713

2023 arXiv
[39]

State machine replication in the libra blockchain,

M. Baudet, A. Ching, A. Chursin, G. Danezis, F. Garillot, Z. Li, D. Malkhi, O. Naor, D. Perelman, and A. Sonnino, “State machine replication in the libra blockchain,”The Libra Assn., Tech. Rep, vol. 7, 2019

2019
[40]

Proof of availability and retrieval in a modular blockchain architecture,

S. Cohen, G. Goren, L. Kokoris-Kogias, A. Sonnino, and A. Spiegel- man, “Proof of availability and retrieval in a modular blockchain architecture,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2023, pp. 36–53

2023
[41]

Efficient dispersal of information for security, load balancing, and fault tolerance,

M. O. Rabin, “Efficient dispersal of information for security, load balancing, and fault tolerance,”Journal of the ACM (JACM), vol. 36, no. 2, pp. 335–348, 1989

1989
[42]

Asynchronous verifiable information dispersal,

C. Cachin and S. Tessaro, “Asynchronous verifiable information dispersal,” in24th IEEE Symposium on Reliable Distributed Systems (SRDS’05). IEEE, 2005, pp. 191–201

2005
[43]

Asynchronous verifiable information dispersal with near- optimal communication,

N. Alhaddad, S. Das, S. Duan, L. Ren, M. Varia, Z. Xiang, and H. Zhang, “Asynchronous verifiable information dispersal with near- optimal communication,”Cryptology ePrint Archive, 2022

2022
[44]

T. T. Team, “Tokio,” https://tokio.rs, 2024

2024
[45]

Ed25519 for consensus-critical contexts,

H. de Valence, “Ed25519 for consensus-critical contexts,” https: //crates.io/crates/ed25519-consensus, 2024

2024
[46]

Rustcrypto: Hashes,

RustCrypto, “Rustcrypto: Hashes,” https://github.com/RustCrypto/ hashes, 2024

2024
[47]

writev(3) - linux man page,

Die.Net, “writev(3) - linux man page,” https://linux.die.net/man/3/ writev, 2024

2024
[48]

Sapling (minibytes),

Meta, “Sapling (minibytes),” https://github.com/facebook/sapling/ tree/main/eden/scm/lib/minibytes, 2024

2024
[49]

Validator deployment amd configuration,

T. S. Team, “Validator deployment amd configuration,” https://docs. sui.io/guides/operator/validator/validator-config, 2025. Appendix A. Performance Analysis under Adverse cases In this section, we give a rigorous proof to show that Beluga can achieve a round latency of nearly...

2025
[50]

commodity servers

https://github.com/asonnino/beluga/tree/paper (commit9a3d2a3) (eu-west-2), Paris (eu-west-3), Stockholm (eu-north-1), Mumbai (ap-south-1), Singapore (ap-southeast-1), Sydney (ap-southeast-2), Tokyo (ap-northeast-1), and Seoul (ap- northeast-2). Validators are distributed acros...

Pith tools

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

[1] [1]

Prism: Scaling bitcoin by 10,000 x,

L. Yang, V . Bagaria, G. Wang, M. Alizadeh, D. Tse, G. Fanti, and P. Viswanath, “Prism: Scaling bitcoin by 10,000 x,”arXiv preprint arXiv:1909.11261, 2019

arXiv 1909

[2] [2]

Narwhal and tusk: a dag-based mempool and efficient bft consen- sus,

G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Narwhal and tusk: a dag-based mempool and efficient bft consen- sus,” inProceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 34–50

2022

[3] [3]

Tendermint: Byzantine fault tolerance in the age of blockchains,

E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” Ph.D. dissertation, University of Guelph, 2016

2016

[4] [4]

Be aware of your leaders,

S. Cohen, R. Gelashvili, L. K. Kogias, Z. Li, D. Malkhi, A. Sonnino, and A. Spiegelman, “Be aware of your leaders,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2022, pp. 279–295

2022

[5] [5]

Practical byzantine fault tolerance,

M. Castro, B. Liskovet al., “Practical byzantine fault tolerance,” in OsDI, vol. 99, no. 1999, 1999, pp. 173–186

1999

[6] [6]

Autobahn: Seamless high speed bft,

N. Giridharan, F. Suri-Payer, I. Abraham, L. Alvisi, and N. Crooks, “Autobahn: Seamless high speed bft,” inProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, 2024, pp. 1–23

2024

[7] [7]

Hashgraph—scalable hash tables using a sparse graph data structure,

O. Green, “Hashgraph—scalable hash tables using a sparse graph data structure,”ACM Transactions on Parallel Computing (TOPC), vol. 8, no. 2, pp. 1–17, 2021

2021

[8] [8]

The blocklace: A byzantine-repelling and universal conflict-free replicated data type,

P. S. Almeida and E. Shapiro, “The blocklace: A byzantine-repelling and universal conflict-free replicated data type,” 2025. [Online]. Available: https://arxiv.org/abs/2402.08068

arXiv 2025