Pith. sign in

REVIEW 3 major objections 5 minor 42 references

Tolerating Disasters with Hierarchical Consensus

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

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

Pith's one-line read ORION claims that cluster confirmation plus rotation keeps geo-replicated Byzantine consensus safe even when every member of the global group is Byzantine, and supports the claim with a compositionality proof and a 20% higher throughput…

desk verdict A genuinely useful construction idea with a load-bearing gap: cluster confirmation as a trusted-component substitute is not sequenced in the pseudocode, so the headline all-Byzantine safety claim is unproved as written. read the letter →

arxiv 2504.21410 v1 pith:RLOEBTWG submitted 2025-04-30 cs.DC

Wassim Yahyaoui (SnT (uni.lu)) , Joachim Bruneau-Queyreix (LaBRI) , Jérémie Decouchant (TU Delft) , Marcus Völp (SnT (uni.lu)) This is my paper · ORCID
classification cs.DC
keywords Byzantinefaulttolerancehierarchicalconsensusgeo-replicationblockchainclusterconfirmationHotStuffDamysuspartialsynchrony
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 tries to establish that hierarchical Byzantine fault-tolerant consensus can be built safely from non-hierarchical building blocks without trusted hardware: a cluster's internal quorum of replicas can serve as the trusted checker and accumulator that hybrid protocols like Damysus use, and rotating which replicas form the global group preserves liveness even when every global representative is Byzantine. This matters because geo-replicated blockchains could then keep safety through accidental or malicious disasters that compromise the entire inter-cluster layer, while still gaining speed from local ordering. The paper demonstrates the construction by combining HotStuff for local ordering and Damysus for global consensus into ORION, proves a compositionality result, and reports about 20% higher throughput than GeoBFT with a modest latency increase.

What carries the argument

The load-bearing object is the cluster confirmation $\varphi = \langle h, v, h', v', ph, \vec{\sigma}_c^n \rangle$, a certificate that $2f_i+1$ replicas of one cluster have signed off on a global-group message in a given phase. The functions C-combine and C-match turn $F+1$ cluster confirmations into a global quorum certificate and check that enough confirmations from distinct clusters arrived. The proof treats these confirmations as a faithful replacement for Damysus's trusted checker and accumulator, while the rotation scheme (replacing representatives after progress or timeout) repeatedly returns the global group to a configuration with at most $F$ faulty members; that combination is what extends local safety and liveness to the global level.

What would settle it

Inspect Algorithm 2's CreateClusterSign for a record of the last signed $(h, view, phase)$; if no such record exists, a Byzantine representative can obtain confirmations for two different superblocks in the same phase from healthy local replicas, violating the sequencing premise of Theorem 2. A run that produces two cluster-confirmed prepare messages for different superblocks in one view would settle the central safety claim in the negative.

Watch

Extended reading notes

Core claim

The central claim is that cluster confirmation emulates Damysus's trusted services well enough to make the global group safe even when all of its representatives are Byzantine. A cluster confirmation is an approval signed by at least $2f_i+1$ replicas of a cluster for a message that the cluster's representative wants to send during global consensus; because a Byzantine representative cannot forge such an approval, the confirmation acts like an unforgeable token that has already checked the protocol's safety condition. The paper proves (Theorems 1 and 2) that if the cluster subprotocols are safe and live, then the composition with cluster confirmation and global rotation is safe and live, provided confirmations are sequenced and rotation repeatedly returns to a configuration with at most $F$ faulty representatives. ORION instantiates this with HotStuff for local pre-ordering and a three-phase Damysus-style global protocol in which superblocks carry only hashes of local blocks.

Load-bearing premise

The safety proof assumes cluster confirmations are sequenced, namely that a local replica advances to the state it will approve and never approves two conflicting global messages for the same phase, but the Algorithm 2 pseudocode shown for creating a cluster confirmation does not implement that bookkeeping.

Editorial extensions

If this is right

  • Global safety no longer depends on any member of the global group being honest: every global message that changes the chain must carry approval from honest local quorums, so the inter-cluster layer can delay but not corrupt the chain.
  • Geo-replicated blockchains built this way keep their durability guarantee through whole-cluster disasters, such as fires or blackouts, as long as each surviving cluster still has $2f_i+1$ correct replicas to confirm global messages.
  • Block dissemination becomes fully asynchronous and decoupled from ordering, because global superblocks only carry hashes of local blocks; throughput can then scale without paying wide-area bandwidth for transaction data.
  • The compositionality theorem means other safe and live local protocols can be lifted to the global level using cluster confirmation and rotation, without adding trusted hardware.
  • In the reported wide-area deployment, ORION beats GeoBFT by about 20% throughput at roughly 31% higher latency, and beats non-hierarchical PBFT and HotStuff on both throughput and latency.

Reading between the lines

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

  • Editorial inference: the protocol text does not fully establish the sequenced-confirmation condition that Theorem 2 needs, because Algorithm 2's CreateClusterSign does not record previously signed $(h, view, phase)$ values; implementing that bookkeeping, such as rejecting any confirmation that does not extend the last confirmed superblock, would close the gap.
  • Editorial inference: the idea of replacing a trusted component with a cluster quorum is not limited to Damysus; other hybrid BFT protocols that rely on a trusted monotonic counter could in principle substitute cluster confirmations for the counter, reducing hardware requirements in geo-replicated settings.
  • Editorial inference: because global consensus runs on hashes, a natural next experiment is to map ORION's throughput against superblock size and inter-cluster bandwidth; the reported 20% improvement over GeoBFT is measured at one deployment configuration and may shift as those parameters change.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The manuscript proposes ORION, a hierarchical Byzantine fault-tolerant consensus protocol for geo-replicated blockchains. It combines HotStuff for local cluster consensus, consistent broadcast for block dissemination, and a Damysus-style global consensus layer in which per-cluster confirmation is meant to replace Damysus's trusted checker and accumulator. The main theoretical contribution is a compositionality claim (Section VI, Theorems 1 and 2): if the local subprotocols are safe and live, then cluster-confirmed state transitions plus a rotating global group yield global safety and liveness, even when all global representatives are Byzantine. The paper also reports an AWS-based evaluation showing higher throughput than GeoBFT and non-hierarchical baselines.

Significance. The idea of replacing trusted components with cluster-level quorum confirmations is original and potentially useful; it would give a principled construction of hierarchical BFT protocols from non-hierarchical ones without trusted hardware, and the combination of HotStuff and Damysus is novel. The paper's proof strategy is clearly stated, and the comparison to GeoBFT provides a useful datapoint. However, the central safety theorem depends on a sequencing invariant that is not implemented in the pseudocode, and the rotation/liveness argument is asserted rather than proved. The paper also does not ship code or machine-checked proofs, so the formal claims are supported only by an informal proof sketch. Since the gaps are load-bearing for the headline claim, the paper as submitted is not yet publishable, but the issues appear addressable within the manuscript's scope.

major comments (3)
  1. [§V-C, Algorithm 2; §VI, Definition 4, Lemma 1, Theorem 2] The proof that cluster confirmation emulates Damysus's trusted accumulator assumes a sequencing property that the pseudocode does not implement. Definition 4 states that state transitions are executed under cluster confirmation only if n−f replicas approve, and the following paragraph requires confirmations to be 'sequenced'; Lemma 1's proof then assumes that a healthy replica accepts a new state s′ only after n−f replicas confirmed the transition leading to s′. In Algorithm 2, CreateClusterSign signs the tuple (h, view, h′, v′, phase) and only then executes phase++; it never records the confirmed hash h, never checks that h extends the replica's currently confirmed chain, and increments the phase counter after signing rather than advancing the chain state before approval. The pseudocode also does not specify whose `phase` is used when the leader combines partial signatures, since the replica branch increments a per-replica phase after signing. Cl-Prepare (lines 17–20) verifies only VERIFY(Ext), view = v, and h ≠ ⊥; Cl-Pcom verifies only view, phase, and signatures; Algorithm 1, line 17 checks only SB > h′. A Byzantine representative can therefore obtain cluster confirmations for two different superblocks at the same phase, or for a superblock that does not extend the highest confirmed superblock, because no per-chain-state monotonicity is enforced. Consequently the equivalence between cluster confirmation and a trusted accumulator is not established, and Theorem 2's safety guarantee for an all-Byzantine global group does not follow from the given protocol. Please modify CreateClusterSign and the local confirmation checks to record, for each view and phase, the last confirmed superblock hash and to reject any approval that does not extend it, or provide a precise invariant and proof that the current checks already guarantee sequencing.
  2. [§VI, final paragraph; Algorithm 1, lines 41–47] The liveness conclusion rests on the assertion that 'our rotation scheme iterates through all combinations of replicas from the individual clusters,' but this is not demonstrated. The pseudocode's NewView phase merely increments `view` on timeout or execution and sends a cluster-signed message to the next view's leader; there is no proof that this process deterministically enumerates all combinations of representatives, that it cannot be stalled indefinitely by Byzantine representatives suppressing messages, or that each configuration with at most F faulty representatives is held for time t. Since Theorem 1's precondition is t-rotation safety, this is a load-bearing gap. Please specify the rotation schedule and prove that it reaches and dwells in healthy configurations repeatedly after GST.
  3. [§IV (superblock acceptance conditions) vs. Algorithm 1 and Algorithm 2] The text states that a superblock is accepted only if blocks from a cluster are queued in a local-order preserving manner and stored durably in at least F+1 clusters, but no pseudocode path verifies these conditions. In the Prepare phase, representatives check only VERIFY and SB > h′ (Alg. 1, line 17), and Cl-Prepare checks only VERIFY(Ext), view, and h ≠ ⊥ (Alg. 2, lines 17–20). A Byzantine global leader can therefore obtain cluster confirmations for a superblock that references blocks that are absent, out of order, or not durably stored, and the Decide phase (lines 34–38) then instructs replicas to execute it. Global durability is thus not enforced by the protocol as written; either the confirmation functions must include the availability/ordering checks, or the paper must provide an additional argument that blocks referenced by a cluster-confirmed superblock are guaranteed to be present at all correct replicas.
minor comments (5)
  1. [§V-C, 'Clusters confirmations' paragraph] The text says 'A cluster confirmation is referred to as an n-cluster confirmation if it encompasses N signatures from separate clusters'; the symbol n is already used for the number of replicas per cluster, so this should be 'N-cluster confirmation' or the notation should be made consistent.
  2. [Algorithm 2, line 24] In Cl-Pcom, the assignment 'preph← h ; preph← v ;' overwrites preph with v; the second assignment should presumably set a separate variable (e.g., prepv).
  3. [§V-B] 'HotSuff-based consensus protocol' contains a typo; it should be 'HotStuff-based'.
  4. [§VI, Theorem 2 proof] The phrase 'Since n−f>f' is used to argue about global quorums, but the global threshold is F+1 out of N=2F+1; please keep the cluster-level n/f and the global F/N notation distinct to avoid confusion.
  5. [§VII] No fault-injection experiments are described; the claim that ORION 'outperforms GeoBFT in terms of throughput under faults' is not supported by the reported evaluation, which only varies cluster sizes and numbers of clusters.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the compositionality proof is a conditional argument with independent external support, and the identified 'sequencing' gap is a missing derivation, not circular reasoning.

full rationale

The paper's central contribution is a compositional safety/liveness theorem (Theorems 1 and 2) plus a protocol construction (ORION) that instantiates the theorem's hypotheses. The derivation chain does not reduce to its own inputs. Theorem 2 explicitly assumes 'all state transitions are cluster confirmed' and proves safety from that hypothesis together with the local safety of the subprotocols; this is a standard conditional proof, not a self-definitional circle. Lemma 1 uses a quorum argument (n-f > f) to show that healthy replicas retain correct states when they only approve transitions confirmed by a majority of local replicas; the argument does not presuppose the theorem it supports. The equivalence between cluster confirmation and Damysus's trusted accumulator is argued through unforgeable threshold signatures and the local replicas' safety checks, not by defining Damysus's properties into existence. The subprotocol safety of Damysus and HotStuff is cited from prior published work ([11] and [14]); although one current author co-authored Damysus, that citation is external, peer-reviewed support and is not used to smuggle in an unverified assumption. The performance comparison is empirical and not derived from the protocol's own claims. The reader's concern about the 'sequenced' cluster-confirmation requirement (Definition 4) points to a possible mismatch between the proof's assumptions and the pseudocode in Algorithm 2; that is an omitted or missing derivation, not circular reasoning, because the proof does not assume its conclusion. No fitted parameters are renamed as predictions, no uniqueness theorem is imported from the authors' prior work, and no known result is merely renamed. The paper is self-contained in its argumentation modulo the cited external protocol proofs. Therefore the circularity score is 0.

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

The central claims rest on the protocol structure and on external correctness proofs of HotStuff and Damysus, not on fitted constants. The main load-bearing assumption beyond the standard system model is the sequencing of cluster confirmations, which is asserted but not implemented in the pseudocode.

assumptions (5)
  • domain assumption Standard partial synchrony after an unknown GST with a known bound Delta
    Section III states the model; liveness is proved only after GST.
  • domain assumption HotStuff and Damysus are safe and live under their stated assumptions (external proofs)
    Section VI invokes proofs from Decouchant et al. and Yin et al. as building blocks.
  • ad hoc to paper Cluster confirmations are sequenced: replicas advance the state they plan to change before approving a message and only approve from that state
    Definition 4 and the paragraph after it in Section VI assert sequencing without specifying a concrete mechanism in Algorithms 1-2. This is load-bearing for Theorem 2.
  • ad hoc to paper The global rotation schedule eventually and repeatedly selects configurations with at most F faulty representatives, because it iterates through all combinations of replicas
    Section VI, final paragraph. The paper does not define a concrete schedule that provably covers all combinations within bounded time.
  • domain assumption Each cluster has n_i = 3f_i + 1 replicas and there are N = 2F + 1 clusters
    Section III defines the quorum sizes used throughout the proofs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Tolerating Disasters with Hierarchical Consensus." pith.science (2026). https://pith.science/paper/RLOEBTWG

@misc{pith2026250421410,
  author       = {Pith},
  title        = {Pith review of: Tolerating Disasters with Hierarchical Consensus},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RLOEBTWG}},
  note         = {Machine review of arXiv:2504.21410}
}
read the original abstract

Geo-replication provides disaster recovery after catastrophic accidental failures or attacks, such as fires, blackouts or denial-of-service attacks to a data center or region. Naturally distributed data structures, such as Blockchains, when well designed, are immune against such disruptions, but they also benefit from leveraging locality. In this work, we consolidate the performance of geo-replicated consensus by leveraging novel insights about hierarchical consensus and a construction methodology that allows creating novel protocols from existing building blocks. In particular we show that cluster confirmation, paired with subgroup rotation, allows protocols to safely operate through situations where all members of the global consensus group are Byzantine. We demonstrate our compositional construction by combining the recent HotStuff and Damysus protocols into a hierarchical geo-replicated blockchain with global durability guarantees. We present a compositionality proof and demonstrate the correctness of our protocol, including its ability to tolerate cluster crashes. Our protocol -ORION 1 -achieves a 20% higher throughput than GeoBFT, the latest hierarchical Byzantine Fault-Tolerant (BFT) protocol.

Figures

Figures reproduced from arXiv: 2504.21410 by the authors.

Figure 1
Figure 1. Structure of our blockchain [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. Communication phases in HotStuff mediately detected and will trigger a global view change. This effectively transforms clusters into trusted components that the global consensus protocol considers as entities that may only fail by crashing. Upon detecting malicious behavior or on timeout, our rotation mechanism replaces the replicas in the global group until eventually a healthy configuration with less than F faulty… view at source ↗
Figure 4
Figure 4. Phases of the Damysus-based global consensus protocol [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (2 more)
Figure 5
Figure 5. Figure 5: Throughput depending on the number N of clusters (each cluster contains 10 replicas, and tolerates f = 3 Byzantine replicas). 3 5 7 9 11 Number of clusters (N = 2F+1) 200 400 600 Latency (ms) HotStuff PBFT GeoBFT Orion [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 8
Figure 8. Figure 8: Latency depending on the number of replicas in a cluster (with [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 36 canonical work pages

  1. [1]

    SoK: Scalability Techniques for BFT Consensus

    C. Berger, S. Schwarz-R ¨usch, A. V ogel, K. Bleeke, L. Jehl, H. P. Reiser, and R. Kapitza, “Sok: Scalability techniques for BFT consensus,” arXiv preprint arXiv:2303.11045, 2023

    work page Pith review arXiv 2023

  2. [2]

    Steward: Scaling byzantine fault-tolerant repli- cation to wide area networks,

    Y . Amir, C. Danilov, D. Dolev, J. Kirsch, J. Lane, C. Nita-Rotaru, J. Olsen, and D. Zage, “Steward: Scaling byzantine fault-tolerant repli- cation to wide area networks,” IEEE Transactions on Dependable and Secure Computing, vol. 7, no. 1, pp. 80–93, 2008

    work page 2008

  3. [3]

    Hierarchical byzantine fault-tolerance protocol for permissioned blockchain systems,

    Q. T. Thai, J.-C. Yim, T.-W. Yoo, H.-K. Yoo, J.-Y . Kwak, and S.-M. Kim, “Hierarchical byzantine fault-tolerance protocol for permissioned blockchain systems,” The Journal of Supercomputing , vol. 75, no. 11, pp. 7337–7365, 2019

    work page 2019

  4. [4]

    Resilientdb: Global scale resilient blockchain fabric,

    S. Gupta, S. Rahnama, J. Hellings, and M. Sadoghi, “Resilientdb: Global scale resilient blockchain fabric,” Proc. VLDB Endow. , vol. 13, no. 6, pp. 868–883, 2020

    work page 2020

  5. [5]

    A scalable byzantine fault tolerance algorithm based on a tree topology network,

    W. Jiang, X. Wu, M. Song, J. Qin, and Z. Jia, “A scalable byzantine fault tolerance algorithm based on a tree topology network,” IEEE Access , 2023

    work page 2023

  6. [6]

    Research on consensus efficiency based on practi- cal byzantine fault tolerance,

    L. Zhang and Q. Li, “Research on consensus efficiency based on practi- cal byzantine fault tolerance,” in 2018 10th international conference on modelling, identification and control (ICMIC) . IEEE, 2018, pp. 1–6

    work page 2018

  7. [7]

    Scalable dynamic multi-agent practical byzantine fault-tolerant consensus in permissioned blockchain,

    L. Feng, H. Zhang, Y . Chen, and L. Lou, “Scalable dynamic multi-agent practical byzantine fault-tolerant consensus in permissioned blockchain,” Applied Sciences, vol. 8, no. 10, p. 1919, 2018

    work page 1919

  8. [8]

    A high performance two-layer consensus architecture for blockchain-based IoT systems,

    H. Qushtom, J. Mi ˇsi´c, V . B. Miˇsi´c, and X. Chang, “A high performance two-layer consensus architecture for blockchain-based IoT systems,” Peer-to-Peer Networking and Applications, pp. 1–13, 2022

    work page 2022

Show all 42 references
  1. [9]

    An optimized byzantine fault tolerance algorithm for consortium blockchain,

    Y . Li, L. Qiao, and Z. Lv, “An optimized byzantine fault tolerance algorithm for consortium blockchain,” Peer-to-Peer Networking and Applications, vol. 14, pp. 2826–2839, 2021

    2021

  2. [10]

    Efficient byzantine fault-tolerance,

    G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, and P. Verissimo, “Efficient byzantine fault-tolerance,” IEEE Transactions on Computers , vol. 62, no. 1, pp. 16–30, 2011

    2011

  3. [11]

    DAMYSUS: stream- lined BFT consensus leveraging trusted components,

    J. Decouchant, D. Kozhaya, V . Rahli, and J. Yu, “DAMYSUS: stream- lined BFT consensus leveraging trusted components,” in Proceedings of the 17th European Conference on Computer Systems , 2022, pp. 1–16

    2022

  4. [12]

    Dis- secting bft consensus: In trusted components we trust!

    S. Gupta, S. Rahnama, S. Pandey, N. Crooks, and M. Sadoghi, “Dis- secting bft consensus: In trusted components we trust!” in Proceedings of the 18th European Conference on Computer Systems , ser. EuroSys ’23, New York, NY , USA, 2023, p. 521–539

    2023

  5. [13]

    Vivisecting the dissection: On the role of trusted components in bft protocols,

    A. Bessani, M. Correia, T. Distler, R. Kapitza, P. Esteves-Verissimo, and J. Yu, “Vivisecting the dissection: On the role of trusted components in bft protocols,” 2023

    2023

  6. [14]

    Hot- Stuff: BFT consensus with linearity and responsiveness,

    M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “Hot- Stuff: BFT consensus with linearity and responsiveness,” in Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing , 2019, pp. 347–356

    2019

  7. [15]

    Practical byzantine fault tolerance and proactive recovery,

    M. Castro and B. Liskov, “Practical byzantine fault tolerance and proactive recovery,” ACM Transactions on Computer Systems (TOCS) , vol. 20, no. 4, pp. 398–461, 2002

    2002

  8. [16]

    State machine replication for the masses with BFT-smart,

    A. Bessani, J. Sousa, and E. E. Alchieri, “State machine replication for the masses with BFT-smart,” in 2014 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. IEEE, 2014, pp. 355–362

    2014

  9. [17]

    Zyzzyva: speculative byzantine fault tolerance,

    R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva: speculative byzantine fault tolerance,” in Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles , 2007, pp. 45–58

    2007

  10. [18]

    Peerreview: Practical accountability for distributed systems,

    A. Haeberlen, P. Kouznetsov, and P. Druschel, “Peerreview: Practical accountability for distributed systems,” ACM SIGOPS operating systems review, vol. 41, no. 6, pp. 175–188, 2007

    2007

  11. [19]

    Attested append- only memory: making adversaries stick to their word,

    B. Chun, P. Maniatis, S. Shenker, and J. Kubiatowicz, “Attested append- only memory: making adversaries stick to their word,” 2007, pp. 189– 204

    2007

  12. [20]

    TrInc: Small trusted hardware for large distributed systems,

    D. Levin, J. R. Douceur, J. R. Lorch, and T. Moscibroda, “TrInc: Small trusted hardware for large distributed systems,” 2009, pp. 1–14

    2009

  13. [21]

    Concurrent prac- tical byzantine fault tolerance for integration of blockchain and supply chain,

    X. Xu, D. Zhu, X. Yang, S. Wang, L. Qi, and W. Dou, “Concurrent prac- tical byzantine fault tolerance for integration of blockchain and supply chain,” ACM Transactions on Internet Technology (TOIT), vol. 21, no. 1, pp. 1–17, 2021

    2021

  14. [22]

    Beh-raft- chain: a behavior-based fast blockchain protocol for complex networks,

    L.-e. Wang, Y . Bai, Q. Jiang, V . C. Leung, W. Cai, and X. Li, “Beh-raft- chain: a behavior-based fast blockchain protocol for complex networks,” IEEE Transactions on Network Science and Engineering , vol. 8, no. 2, pp. 1154–1166, 2020

    2020

  15. [23]

    Dp-hybrid: a two-layer consensus protocol for high scalability in permissioned blockchain,

    F. Wen, L. Yang, W. Cai, and P. Zhou, “Dp-hybrid: a two-layer consensus protocol for high scalability in permissioned blockchain,” in Blockchain and Trustworthy Systems: Second International Conference, BlockSys 2020, Dali, China, August 6–7, 2020, Revised Selected Papers 2 . ...

    2020

  16. [24]

    A scalable multi-layer PBFT consensus for blockchain,

    W. Li, C. Feng, L. Zhang, H. Xu, B. Cao, and M. A. Imran, “A scalable multi-layer PBFT consensus for blockchain,” IEEE Transactions on Parallel and Distributed Systems , vol. 32, no. 5, pp. 1146–1160, 2020

    2020

  17. [25]

    Saguaro: Efficient processing of transactions in wide area networks using a hierarchical permissioned blockchain,

    M. Javad Amiri, Z. Lai, L. Patel, B. Thau Loo, E. Lo, and W. Zhou, “Saguaro: Efficient processing of transactions in wide area networks using a hierarchical permissioned blockchain,” arXiv e-prints, pp. arXiv– 2101, 2021

    2021

  18. [26]

    Nar- whal and tusk: a dag-based mempool and efficient BFT consensus,

    G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Nar- whal and tusk: a dag-based mempool and efficient BFT consensus,” in Proceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 34–50

    2022

  19. [27]

    Bullshark: Dag BFT protocols made practical,

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

    2022

  20. [28]

    The swirlds hashgraph consensus algorithm: Fair, fast, byzan- tine fault tolerance,

    L. Baird, “The swirlds hashgraph consensus algorithm: Fair, fast, byzan- tine fault tolerance,” Swirlds Tech Reports SWIRLDS-TR-2016-01, Tech. Rep, vol. 34, 2016

    2016

  21. [29]

    Aleph: Efficient atomic broadcast in asynchronous networks with byzantine nodes,

    A. Gagol, D. Lesniak, D. Straszak, and M. Swietek, “Aleph: Efficient atomic broadcast in asynchronous networks with byzantine nodes,” in Proceedings of the 1st ACM Conference on Advances in Financial Technologies, 2019, pp. 214–228

    2019

  22. [30]

    Secure high-rate transaction processing in bitcoin,

    Y . Sompolinsky and A. Zohar, “Secure high-rate transaction processing in bitcoin,” in International conference on financial cryptography and data security. Springer, 2015, pp. 507–527

    2015

  23. [31]

    The honey badger of BFT protocols,

    A. Miller, Y . Xia, K. Croman, E. Shi, and D. Song, “The honey badger of BFT protocols,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security , 2016, pp. 31–42

    2016

  24. [32]

    Red belly: a secure, fair and scalable open blockchain,

    T. Crain, C. Natoli, and V . Gramoli, “Red belly: a secure, fair and scalable open blockchain,” in 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 466–483

    2021

  25. [33]

    Mir-BFT: High- throughput BFT for blockchains,

    C. Stathakopoulou, T. David, and M. Vukolic, “Mir-BFT: High- throughput BFT for blockchains,” arXiv preprint arXiv:1906.05552 , 2019

    1906 arXiv

  26. [34]

    Alder: Unlocking blockchain performance by multiplexing consensus protocols,

    K. Korkmaz, J. Bruneau-Queyreix, S. B. Mokhtar, and L. R ´eveill`ere, “Alder: Unlocking blockchain performance by multiplexing consensus protocols,” in 2022 IEEE 21st International Symposium on Network Computing and Applications (NCA) , vol. 21. IEEE, 2022, pp. 9–18

    2022

  27. [35]

    Algorand: Scaling byzantine agreements for cryptocurrencies,

    Y . Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand: Scaling byzantine agreements for cryptocurrencies,” in Proceedings of the 26th symposium on operating systems principles , 2017, pp. 51–68

    2017

  28. [36]

    A secure sharding protocol for open blockchains,

    L. Luu, V . Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, “A secure sharding protocol for open blockchains,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 17–30

    2016

  29. [37]

    Rapidchain: Scaling blockchain via full sharding,

    M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scaling blockchain via full sharding,” in CCS, 2018

    2018

  30. [38]

    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 (JACM) , vol. 35, no. 2, pp. 288–323, 1988

    1988

  31. [39]

    Asynchronous byzantine agreement protocols,

    G. Bracha, “Asynchronous byzantine agreement protocols,” Information and Computation, vol. 75, no. 2, pp. 130–143, 1987

    1987

  32. [40]

    Practical byzantine reliable broadcast on partially connected networks,

    S. Bonomi, J. Decouchant, G. Farina, V . Rahli, and S. Tixeuil, “Practical byzantine reliable broadcast on partially connected networks,” in 2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS). IEEE, 2021, pp. 506–516

    2021

  33. [41]

    How to share a secret,

    A. Shamir, “How to share a secret,” Communications of the ACM , vol. 22, no. 11, pp. 612–613, 1979

    1979

  34. [42]

    Cobra: Dynamic proactive secret sharing for confidential BFT services,

    R. Vassantlal, E. Alchieri, B. Ferreira, and A. Bessani, “Cobra: Dynamic proactive secret sharing for confidential BFT services,” in 2022 IEEE symposium on security and privacy (SP) . IEEE, 2022, pp. 1335–1353

    2022

Pith tools

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