Pith. sign in

REVIEW 3 major objections 4 minor 57 references

Hamava: Fault-tolerant Reconfigurable Geo-Replication on Heterogeneous Clusters

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

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

Pith's one-line read Clustered Byzantine replication can let replicas join and leave clusters, support unequal cluster sizes, and still guarantee agreement and a total order on operations.

desk verdict The reconfiguration and heterogeneity contributions are real, but the inter-cluster broadcast has a batch-completeness hole that breaks Agreement and Total order as written. read the letter →

arxiv 2412.01999 v3 pith:IE66WT52 submitted 2024-12-02 cs.DC

Tejas Mane , Xiao Li , Mohammad Sadoghi , Mohsen Lesani This is my paper · ORCID
classification cs.DC
keywords Byzantinefaulttoleranceclusteredreplicationreconfigurationdynamicmembershipgeo-replicationconsensus-agnosticheterogeneousclusters
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

HAMAVA claims that Byzantine-fault-tolerant replicated databases can be both geo-clustered and reconfigurable: replicas in different regions are grouped into clusters that may differ in size, and members may join or leave without a separate global consensus step for membership. The paper proves that this preserves safety and liveness, stated as Validity (every requested operation is eventually executed), Agreement (all correct processes execute the same operations in the same round), and Total order (a consistent execution order across processes). The design is a round-based meta-protocol: clusters order transactions locally, exchange only operations that carry signatures from a quorum of their source cluster, replace misbehaving leaders even in remote clusters, and apply membership changes uniformly at the next round boundary. If correct, the result is a permissioned blockchain or replicated database that churns its membership like a public network while keeping per-cluster Byzantine tolerance. Experiments instantiate the meta-protocol with HotStuff and BFT-SMaRt and report that heterogeneity raises throughput, reconfiguration costs little, and leader failures recover within a timeout.

What carries the argument

The load-bearing object is the operation certificate: each locally ordered operation is shipped to other clusters together with a signature set from at least $2f_j+1$ distinct members of its source cluster $C_j$, and remote replicas accept inter-cluster messages only when every certificate is valid (Algorithm 1, line 15). This certificate is what lets a cluster trust operations it never ordered itself, and the Agreement proof (Lemma 5) derives equality of received operation sets from quorum intersection on these certificates. Three sub-protocols hang off it: inter-cluster broadcast, which sends each batch to only $f_j+1$ remote replicas (at least one correct) that re-broadcast locally; heterogeneous remote leader change, which uses $f_j+1$ and $2f_j+1$ complaint-signature thresholds together with per-cluster counters $cn_j$ and $rcn_j$ to make Byzantine-forced or replayed leader changes impossible; and the Byzantine Reliable Dissemination (BRD) module, an echo/ready broadcast with timestamped valid sets carried across leader changes, which aggregates reconfiguration requests so that a Byzantine leader cannot drop them. Reconfigurations are deliberately handled as an unordered aggregated set in a workflow parallel to transaction ordering, and take effect only at the round boundary, so they never compete with transactions for consensus slots.

What would settle it

Instantiate the meta-protocol with a local ordering engine that does not expose per-operation quorum signatures, such as a view-based protocol whose only signed artifact is a per-view change summary. If the correct leader of a cluster cannot assemble the required $2f_j+1$ certificate for its own operations (Algorithm 1, line 15), no other cluster will accept its batch and the system will stall even with a correct leader, contradicting the claimed termination; if the acceptance check is loosened instead, a Byzantine leader can ship under-signed operations that make different clusters accept different sets, contradicting Agreement. Either outcome is directly observable with the paper's own protocol description.

Watch

Extended reading notes

Core claim

HAMAVA's central claim is that heterogeneous, reconfigurable clustered Byzantine replication is achievable: as long as no cluster has more than one-third Byzantine members, clusters of different sizes can agree on a consistent execution history while replicas join and leave and leaders misbehave. The protocol proceeds in rounds with three stages: in stage one, each cluster orders its transactions with any local total-order broadcast and, in parallel, collects join and leave requests into an unordered set; in stage two, the cluster leader broadcasts the locally ordered operations to other clusters, sending the operations together with certificates of at least $2f_j+1$ signatures from the source cluster to $f_j+1$ members of each remote cluster, where they are re-broadcast locally; in stage three, every replica executes the received operations in a fixed cluster order. If a remote leader withholds its operations, a complaint mechanism that requires $f_j+1$ and then $2f_j+1$ signatures, protected by monotonic complaint counters, triggers the replacement of that remote leader. Reconfigurations are applied only in stage three, so every cluster adopts the same membership for the following round, which the authors prove closes both the forged-certificate and the censorship attacks that stale membership views enable, yielding Theorem 1 (Validity), Theorem 2 (Agreement), and Theorem 3 (Total order). The authors also report implementations over HotStuff and BFT-SMaRt whose measurements show throughput gains from heterogeneity and modest cost from reconfiguration.

Load-bearing premise

The design assumes that whatever local method a cluster uses to order its own transactions can be made to attach, to every ordered operation, a signed certificate from more than two-thirds of that cluster's current members; if a chosen local mechanism cannot produce such per-operation certificates, clusters can neither assemble valid outgoing messages nor verify incoming ones.

Editorial extensions

If this is right

  • Clusters can adopt joins and leaves at every round boundary without a global membership consensus, because reconfiguration sets are collected in parallel with ordering and applied uniformly in stage three.
  • Heterogeneous deployments are safe: since every inter-cluster message is sized and checked by the target cluster's own $f_j$, large clusters cannot exploit stale smaller thresholds to forge certificates, and small clusters cannot be censored by senders aiming at outdated larger thresholds.
  • Operators can trade layout for speed: with a fixed number of nodes, splitting into more clusters improves throughput and latency, and placing each cluster inside one region outperforms spreading it across regions.
  • Leader failure including a Byzantine leader that behaves locally but stalls inter-cluster communication is recoverable: the remote leader change protocol replaces the leader within a configurable timeout, and measured throughput returns to its prior level.
  • Reconfiguration is cheap in practice: the measured throughput drop during concentrated join and leave churn stays small, at most about 12% for the HotStuff instantiation and 10% for the BFT-SMaRt instantiation in the frequency experiments.

Reading between the lines

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

  • I read the paper's 'consensus-agnostic' claim as bounded by its certificate interface: a local engine that cannot expose a per-operation quorum signature set would need an adapter before the agreement proofs apply, since only HotStuff and BFT-SMaRt are instantiated and both naturally emit such certificates.
  • A combination stress test the paper does not run, membership churn arriving in the same round as a leader failure, would exercise the interaction between the reconfiguration workflow and remote leader change, where worst-case recovery timing might differ from the isolated fault scenarios reported.
  • Because the order of reconfiguration requests within a round is immaterial, the protocol extends naturally to batched membership policies such as admission quotas or per-round rate limits without touching the safety argument.
  • The signed-complaint channel used for remote leader change is a generic cross-cluster accountability mechanism; the same structure could carry other governance actions, such as auditing a remote cluster or certifying its configuration.
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 / 4 minor

Summary. The paper presents HAMAVA, a Byzantine fault-tolerant geo-replication protocol for heterogeneous clusters with dynamic membership. The protocol divides replicas into clusters, lets each cluster order transactions and reconfiguration requests locally, then exchanges the resulting operations between clusters through an inter-cluster broadcast, and finally executes all operations in a deterministic global order. The paper states and proves safety and liveness properties (Theorems 1-3), claims the protocol is consensus-agnostic, and reports experimental results from instantiations with HotStuff and BFT-SMaRt on Google Cloud, including comparisons with GeoBFT and measurements under reconfiguration and failures.

Significance. If the claimed properties were established, HAMAVA would be a meaningful step toward scalable and reconfigurable Byzantine geo-replication: it supports heterogeneous cluster sizes and dynamic membership while preserving per-cluster fault thresholds, and it reduces global communication relative to non-clustered replication. The paper contains a substantial algorithmic presentation, explicit theorem statements and proof attempts, and a broad evaluation that compares against GeoBFT and studies reconfiguration frequency, network latency, and leader failures. However, the central safety proof has a load-bearing gap: the inter-cluster broadcast authenticates individual operations but not the completeness of the round batch, and Lemma 5, on which Theorems 2 and 3 rest, is therefore false as stated. The liveness proof also assumes an exponential timer backoff that does not appear in the protocol code, and the 'consensus-agnostic' claim is stronger than the required certificate interface justifies.

major comments (3)
  1. [§III (Alg. 1), §IX Lemma 5, §X-B] The inter-cluster broadcast authenticates individual operations but not the completeness of the round batch. A Byzantine leader of cluster C_j can locally order a batch {A,B,C} and call inter-broadcast(r,{A,B},certs) toward one remote cluster and inter-broadcast(r,{A,B,C},certs) toward another; line 15 checks only that each operation in ops carries at least 2f_j+1 signatures, so every operation in both messages has a valid certificate. Correct receivers in both clusters broadcast Local, set operations_j <- ops, and stop timer_j (lines 16-19), so no remote leader change is triggered. The proof of Lemma 5 uses the assertion '|ops|=|ops'|' without deriving it from any protocol action, which makes the lemma false as stated. Since Lemma 5 is the premise for Theorems 2 and 3, Agreement and Total order do not follow. The problem also occurs within a single remote cluster: a correct process may receive two valid Local messages from C_j with different subsets and overwrite operations_j at line 18, so two correct processes in the same remote cluster can end the round with different operations_j.
  2. [Alg. 2, lines 3 and 20; §X-A Lemma 2 proof] The liveness proof assumes that remote-leader-change timers grow unboundedly after GST, as the proof of Lemma 2 states, 'the timer for remote leader change increases exponentially and eventually, all the messages are delivered within a bounded delay after GST.' However, the protocol code does not implement this backoff: Algorithm 2 initializes timer_j to the fixed value Delta and line 20 resets timer_j to Delta after every complaint. Under a partial-synchrony schedule in which message delays exceed Delta, the proof's assumption does not hold, and the conclusion that all correct processes eventually adopt the same correct leader is not established. This gap affects the proof of Theorem 1 (Validity) and the eventual-progress part of the liveness claim.
  3. [Abstract; §II System and Threat Model; Alg. 7] The 'consensus-agnostic' claim is stronger than what the protocol actually requires. The local replication mechanism must deliver, for each ordered operation, a commit certificate containing at least 2f_i+1 signatures from distinct members of the cluster (Algorithm 7 lines 17-19; Algorithm 1 line 15). Many total-order broadcast and BFT consensus implementations do not expose per-operation quorum-signed certificates; the paper demonstrates only HotStuff and BFT-SMaRt. The claim should be restricted to local mechanisms that can be adapted to emit such certificates, and the certificate interface should be stated explicitly as part of the total-order broadcast abstraction rather than implied by 'any local replication mechanism.' This issue is independent of the batch-completeness gap in the first major comment: even when per-operation certificates are available, the batch itself is not certified.
minor comments (4)
  1. [§II.A] The sentence 'The Byzantine replicas of C2 and C2 are the red replicas {p3} and {p1,p2} respectively' should presumably read 'C1 and C2' rather than 'C2 and C2.'
  2. [§X-A Lemma 1 proof] The proof refers to 'rb' and 'the validity of reliable broadcast,' but Algorithm 1 uses the AuthenticatedBestEffortBroadcast abstraction abeb at line 16; the abstraction names should be aligned.
  3. [Title and Abstract] The paper alternates between the names HAMAVA and AVA for the same system, and the abstract says 'we present AVA' while the title and body use HAMAVA; the naming should be made consistent.
  4. [Fig. 4a] The caption for the latency-breakdown experiment does not clearly identify which panel corresponds to AVA-BFTSMART and which to AVA-HOTSTUFF, making the left/right labels in the caption hard to follow.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the safety/liveness derivation is self-contained apart from a minor self-citation to the authors' extended report; the serious Lemma 5 gap is a proof error, not a circular reduction.

full rationale

I walked the derivation chain from the TOB/BRD/leader-election abstractions to Theorems 1-3. No prediction is obtained by fitting: the theorems are proved from stated quorum-intersection and TOB agreement/total-order properties, and the performance evaluation is measured, not derived. The only self-citation is [41], the authors' extended report; Section II says 'We detail the stages in the extended report [41]' and Section IX says 'All the proofs including the properties of sub-protocols are available in the extended report [41] § IX.' The appendix restates the main proofs, so this self-citation is supplementary rather than load-bearing; it does not by itself establish a theorem in the paper. The serious issue in Lemma 5's proof -- it assumes |ops|=|ops'| when Algorithm 1 (lines 15-17) only checks per-operation certificates, not batch completeness -- is a correctness gap (a Byzantine leader can send valid subsets to different clusters), not a circular reduction: no quantity is defined in terms of itself and no fitted input is renamed as a prediction. Hence the circularity score is 1.

Assumptions & free parameters 3 free parameters · 6 assumptions · 1 invented entities

The correctness of HAMAVA rests on six axioms: partial synchrony, the per-cluster f_i assumption, authenticated links, the TOB certificate interface, the leader election guarantees, and the (proof-only) exponential timer behavior. The paper adds three tunable parameters (∆, α, ϵ) that affect liveness and performance but are set by hand. One new abstraction, BRD, is introduced and promises independent reuse but has no external validation. No physical entities are invented.

free parameters (3)
  • Remote leader change timeout ∆ = 20 s in E4/E5 experiments
    Algorithm 2 line 3 sets timer_j ← ∆; Section V E4 says the timeout 'can be adjusted according to the local network latency' and was set to 20 s. Liveness of leader change depends on ∆ exceeding the actual delivery delay after GST; the proof of Lemma 2 assumes exponential growth of timers, which Algorithm 2 does not implement.
  • Reconfiguration collection trigger fraction α = unspecified
    Algorithm 7 line 20 starts BRD dissemination when |operations_i| = batch-size × α. This hand-chosen fraction must balance time for collecting join/leave requests against time for disseminating them before inter-cluster broadcast; the paper gives no default or tuning rule.
  • Complaint rejection guard ϵ = unspecified
    Algorithm 2 line 25 skips changing the leader when ∆ − timer_i ≤ ϵ, to avoid disruption from simultaneous remote complaints. The value of ϵ is not derived and affects liveness during reconfiguration.
assumptions (6)
  • domain assumption Partial synchrony: after an unknown global stabilization time, messages between correct replicas are eventually delivered within a bounded delay.
    Stated in Section II (Threat Model) and used in the liveness proofs of Lemma 2 and Lemma 4.
  • domain assumption At any time, each cluster C_j has at most f_j Byzantine replicas out of 3f_j+1 replicas.
    Stated in Section II; all quorum sizes, certificates, and safety/liveness arguments depend on per-cluster f_j.
  • domain assumption Replicas are identified by public keys, are computationally bounded, and use authenticated links (apl) and authenticated best-effort broadcast (abeb).
    Stated in Section II; prevents forgery and allows certificates of signatures to serve as proofs of quorum delivery.
  • domain assumption The local total-order broadcast (TOB) satisfies validity, agreement, total order, and supplies commit certificates of 2f_i+1 signatures for every delivered operation.
    Invoked in Section VIII (Local ordering) and Algorithm 1 line 15; Theorem 2 and Lemma 5 inherit agreement of operations from this interface.
  • ad hoc to paper The leader election module (Algorithm 9) guarantees uniform leaders, monotonically increasing timestamps, and eventual election of a correct leader.
    Section VIII asserts these guarantees ('This module guarantees...') but the paper does not prove them; BRD termination and remote leader change liveness rely on them.
  • ad hoc to paper Remote-leader-change timers grow unboundedly (exponentially) after GST.
    Lemma 2's proof states 'the timer for remote leader change increases exponentially,' but Algorithm 2 line 20 resets timer_j to a fixed ∆. The liveness proof and the algorithm diverge on this point.
invented entities (1)
  • Byzantine Reliable Dissemination (BRD) module
    purpose: Collects reconfiguration requests into a set and uniformly disseminates the same set to every correct replica in a cluster, surviving Byzantine leaders via echo/ready amplification and leader-change value adoption.
    BRD is introduced in Section IV as a general reusable module of independent interest, but it is only validated inside HAMAVA; no standalone implementation, formal machine-checked proof, or external benchmark is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hamava: Fault-tolerant Reconfigurable Geo-Replication on Heterogeneous Clusters." pith.science (2026). https://pith.science/paper/IE66WT52

@misc{pith2026241201999,
  author       = {Pith},
  title        = {Pith review of: Hamava: Fault-tolerant Reconfigurable Geo-Replication on Heterogeneous Clusters},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IE66WT52}},
  note         = {Machine review of arXiv:2412.01999}
}
read the original abstract

Fault-tolerant replicated database systems consume less energy than the compute-intensive proof-of-work blockchain. Thus, they are promising technologies for the building blocks that assemble global financial infrastructure. To facilitate global scaling, clustered replication protocols are essential in orchestrating nodes into clusters based on proximity. However, the existing approaches often assume a homogeneous and fixed model in which the number of nodes across clusters is the same and fixed, and often limited to a fail-stop fault model. This paper presents heterogeneous and reconfigurable clustered replication for the general environment with arbitrary failures. In particular, we present AVA, a fault-tolerant reconfigurable geo-replication that allows dynamic membership: replicas are allowed to join and leave clusters. We formally state and prove the safety and liveness properties of the protocol. Furthermore, our replication protocol is consensus-agnostic, meaning each cluster can utilize any local replication mechanism. In our comprehensive evaluation, we instantiate our replication with both HotStuff and BFT-SMaRt. Experiments on geo-distributed deployments on Google Cloud demonstrates that members of clusters can be reconfigured without considerably affecting transaction processing, and that heterogeneity of clusters may significantly improve throughput.

Figures

Figures reproduced from arXiv: 2412.01999 by the authors.

Figure 1
Figure 1. HAMAVA Reconfigurable Clustered Replication Protocol receive the message from a remote cluster, they trigger the remote leader change protocol to eventually change the leader of that remote cluster. Stage 3: Execution. Finally, in the third stage, each replica orders the transactions and reconfigurations that it has received from all clusters by a predefined order for the clusters, executes them in order, and issues… view at source ↗
Figure 2
Figure 2. Reconfiguration: Collection and Dissemination [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Throughput and latency as a function of number of clusters (with 96 nodes) E0. in the same region (two left plots) [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: E2. Latency breakdown for AVA-BFTSMART (left) and AVA-HOTSTUFF (right and shaded) in (a). 1 region: Asia, 2 regions: EU and Asia, and 3 regions: EU, Asia, US. E3. Impact of heterogeneity on throughput and latency for AVA-HOTSTUFF in (b) and (c) and for AVA-BFTSMART in …
Figure 6
Figure 6. Figure 6: E7. AVA-HOTSTUFF vs GeoBFT. 1. Clusters located in the same region: (a) throughput and latency. 2. Clusters located in multiple regions: (b) throughput and latency. from transactions and are processed in sequence. In contrast, HAMAVA processes them in parallel with tra…
Figure 7
Figure 7. Figure 7: E7. Impact of reconfiguration frequency on (a,c) throughput, and (b,d) latency. Reconfigurations begin at 80 seconds. We experiment with two frequencies: (1) once every 20 seconds, and (2) continuously, without any delay between reconfiguration requests. With AVA-HOTST…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 52 canonical work pages

  1. [1]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”White paper, 2008

    work page 2008

  2. [2]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Woodet al., “Ethereum: A secure decentralised generalised trans- action ledger,”Ethereum project yellow paper, vol. 151, no. 2014, pp. 1–32, 2014

    2014

  3. [3]

    A stealthier partitioning attack against Bitcoin peer-to-peer network,

    M. Tran, I. Choi, G. J. Moon, A. V . Vu, and M. S. Kang, “A stealthier partitioning attack against Bitcoin peer-to-peer network,” in2020 IEEE symposium on security and privacy (SP). IEEE, 2020, pp. 894–909

    work page 2020

  4. [4]

    On the security and performance of proof of work blockchains,

    A. Gervais, G. O. Karame, K. W ¨ust, V . Glykantzis, H. Ritzdorf, and S. Capkun, “On the security and performance of proof of work blockchains,” inProceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 3–16

    work page 2016

  5. [5]

    Three birds with one stone: Efficient partitioning attacks on interdependent cryptocurrency networks,

    M. Saad and D. Mohaisen, “Three birds with one stone: Efficient partitioning attacks on interdependent cryptocurrency networks,” in2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 111– 125

    work page 2023

  6. [6]

    Blockchain censorship,

    A. Wahrst ¨atter, J. Ernstberger, A. Yaish, L. Zhou, K. Qin, T. Tsuchiya, S. Steinhorst, D. Svetinovic, N. Christin, M. Barczentewiczet al., “Blockchain censorship,” inProceedings of the ACM on Web Conference 2024, 2024, pp. 1632–1643

    work page 2024

  7. [7]

    Practical Byzantine fault tolerance,

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

    work page 1999

  8. [8]

    The honey badger of BFT protocols,

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

    work page 2016

Show all 57 references
  1. [9]

    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,” inProceedings of the 2019 ACM Symposium on Principles of Distributed Computing, 2019, pp. 347–356

    2019

  2. [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

  3. [11]

    Hyperledger fabric: a distributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y . Manevichet al., “Hyperledger fabric: a distributed operating system for permissioned blockchains,” inProceedings of the thirteenth EuroSys conference, 2018, pp. 1–15

    2018

  4. [12]

    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, p. 92, 2019

    1906 arXiv

  5. [13]

    Caper: a cross- application permissioned blockchain,

    M. J. Amiri, D. Agrawal, and A. E. Abbadi, “Caper: a cross- application permissioned blockchain,”Proceedings of the VLDB Endow- ment, vol. 12, no. 11, pp. 1385–1398, 2019

    2019

  6. [14]

    Proof-of- Execution: Reaching consensus through fault-tolerant speculation,

    S. Gupta, J. Hellings, S. Rahnama, and M. Sadoghi, “Proof-of- Execution: Reaching consensus through fault-tolerant speculation,” inProceedings of the 24th International Conference on Extending Database Technology, EDBT 2021, Nicosia, Cyprus, March 23 - 26, 2021, 2021, pp. 301–312

    2021

  7. [15]

    Blockchains vs. distributed databases: Dichotomy and fusion,

    P. Ruan, T. T. A. Dinh, D. Loghin, M. Zhang, G. Chen, Q. Lin, and B. C. Ooi, “Blockchains vs. distributed databases: Dichotomy and fusion,” in Proceedings of the 2021 International Conference on Management of Data, 2021, pp. 1504–1517

    2021

  8. [16]

    LineageChain: a fine-grained, secure and efficient data provenance system for blockchains,

    P. Ruan, T. T. A. Dinh, Q. Lin, M. Zhang, G. Chen, and B. C. Ooi, “LineageChain: a fine-grained, secure and efficient data provenance system for blockchains,”The VLDB Journal, vol. 30, pp. 3–24, 2021

    2021

  9. [17]

    HotStuff-1: linear consensus with one-phase speculation,

    D. Kang, S. Gupta, D. Malkhi, and M. Sadoghi, “HotStuff-1: linear consensus with one-phase speculation,”SIGMOD, 2025

    2025

  10. [18]

    The Bedrock of Byzantine fault tolerance: A unified platform for BFT protocols analysis, implementation, and experimen- tation,

    M. J. Amiri, C. Wu, D. Agrawal, A. E. Abbadi, B. T. Loo, and M. Sadoghi, “The Bedrock of Byzantine fault tolerance: A unified platform for BFT protocols analysis, implementation, and experimen- tation,” in21st USENIX Symposium on Networked Systems Design and Implementation, NS...

    2024

  11. [19]

    Solida: A blockchain protocol based on reconfigurable Byzantine consensus,

    I. Abraham, D. Malkhi, K. Nayak, L. Ren, and A. Spiegelman, “Solida: A blockchain protocol based on reconfigurable Byzantine consensus,” arXiv preprint arXiv:1612.02916, 2016

    2016 arXiv

  12. [20]

    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

  13. [21]

    Casper the friendly finality gadget,

    V . Buterin and V . Griffith, “Casper the friendly finality gadget,”arXiv preprint arXiv:1710.09437, 2017

    2017 arXiv

  14. [22]

    Algorand: Scaling Byzantine agreements for cryptocurrencies,

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

    2017

  15. [23]

    Omniledger: A secure, scale-out, decentralized ledger via sharding,

    E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford, “Omniledger: A secure, scale-out, decentralized ledger via sharding,” in2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018, pp. 583–598

    2018

  16. [24]

    RapidChain: A fast blockchain protocol via full sharding

    M. Zamani, M. Movahedi, and M. Raykova, “RapidChain: A fast blockchain protocol via full sharding.”IACR Cryptol. ePrint Arch., vol. 2018, p. 460, 2018

    2018

  17. [25]

    Quorum systems in permissionless networks,

    C. Cachin, G. Losa, and L. Zanolini, “Quorum systems in permissionless networks,” in26th International Conference on Principles of Distributed Systems, 2023

    2023

  18. [26]

    Steward: Scaling Byzantine fault-tolerant replication 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 replication to wide area networks,”IEEE Transactions on Dependable and Secure Computing, vol. 7, no. 1, pp. 80–93, 2008

    2008

  19. [27]

    ResilientDB: Global scale resilient blockchain fabric,

    S. Gupta, S. Rahnama, J. Hellings, and M. Sadoghi, “ResilientDB: Global scale resilient blockchain fabric,”Proceedings of the VLDB Endowment, vol. 13, no. 6, 2020

    2020

  20. [28]

    RCC: resilient concurrent consensus for high-throughput secure transaction processing,

    S. Gupta, J. Hellings, and M. Sadoghi, “RCC: resilient concurrent consensus for high-throughput secure transaction processing,” in37th IEEE International Conference on Data Engineering, ICDE 2021, Chania, Greece, April 19-22, 2021. IEEE, 2021, pp. 1392–1403

    2021

  21. [29]

    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,” inProceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 34–50

    2022

  22. [30]

    Foundations of dynamic BFT,

    S. Duan and H. Zhang, “Foundations of dynamic BFT,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2022, pp. 1546–1546

    2022

  23. [31]

    Smartmerge: A new approach to reconfiguration for atomic storage,

    L. Jehl, R. Vitenberg, and H. Meling, “Smartmerge: A new approach to reconfiguration for atomic storage,” inInternational Symposium on Distributed Computing. Springer, 2015, pp. 154–169

    2015

  24. [32]

    BChain: Byzantine repli- cation with high throughput and embedded reconfiguration,

    S. Duan, H. Meling, S. Peisert, and H. Zhang, “BChain: Byzantine repli- cation with high throughput and embedded reconfiguration,” inPrinci- ples of Distributed Systems: 18th International Conference, OPODIS 2014, Cortina d’Ampezzo, Italy, December 16-19, 2014. Proceedings

    2014

  25. [33]

    Springer, 2014, pp. 91–106

    2014

  26. [34]

    Reconfiguring a state machine,

    L. Lamport, D. Malkhi, and L. Zhou, “Reconfiguring a state machine,” ACM SIGACT News, vol. 41, no. 1, pp. 63–73, 2010

    2010

  27. [35]

    The part-time parliament,

    L. LAMPORT, “The part-time parliament,”ACM Transactions on Com- puter Systems, vol. 16, no. 2, pp. 133–169, 1998

    1998

  28. [36]

    The next 700 BFT protocols,

    R. Guerraoui, N. Kne ˇzevi´c, V . Qu´ema, and M. Vukoli ´c, “The next 700 BFT protocols,” inProceedings of the 5th European conference on Computer systems, 2010, pp. 363–376

    2010

  29. [37]

    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,” in2014 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. IEEE, 2014, pp. 355–362

    2014

  30. [38]

    Feasibility analysis for Sybil attacks in shard-based permissionless blockchains,

    T. Rajabi, A. A. Khalil, M. H. Manshaei, M. A. Rahman, M. Dakhilalian, M. Ngouen, M. Jadliwala, and A. S. Uluagac, “Feasibility analysis for Sybil attacks in shard-based permissionless blockchains,”Distributed Ledger Technologies: Research and Practice, vol. 2, no. 4, pp. 1–21, 2023

    2023

  31. [39]

    Optimal Sybil-resilient node admission control,

    N. Tran, J. Li, L. Subramanian, and S. S. Chow, “Optimal Sybil-resilient node admission control,” in2011 Proceedings IEEE INFOCOM. IEEE, 2011, pp. 3218–3226

    2011

  32. [40]

    You are where you have been: Sybil detection via geo-location analysis in OSNs,

    X. Zhang, H. Zheng, X. Li, S. Du, and H. Zhu, “You are where you have been: Sybil detection via geo-location analysis in OSNs,” in2014 IEEE Global Communications Conference. IEEE, 2014, pp. 698–703

    2014

  33. [41]

    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

  34. [42]

    A V A: reconfigurable fault- tolerant geo-replication on heterogeneous clusters,

    T. Mane, X. Li, M. Sadoghi, and M. Lesani, “A V A: reconfigurable fault- tolerant geo-replication on heterogeneous clusters,”arXiv preprint, 2024

    2024

  35. [43]

    Geobft codebase,

    R. team, “Geobft codebase,” https://github.com/apache/ incubator-resilientdb/archive/refs/tags/v3.0.zip

  36. [44]

    Paxos made simple,

    L. Lamport, “Paxos made simple,”ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001), pp. 51–58, 2001

    2001

  37. [45]

    SharPer: Sharding permissioned blockchains over network clusters,

    M. J. Amiri, D. Agrawal, and A. El Abbadi, “SharPer: Sharding permissioned blockchains over network clusters,” inProceedings of the 2021 international conference on management of data, 2021, pp. 76–88

    2021

  38. [46]

    ByShard: sharding in a Byzantine envi- ronment,

    J. Hellings and M. Sadoghi, “ByShard: sharding in a Byzantine envi- ronment,”VLDB J., vol. 32, no. 6, pp. 1343–1367, 2023

    2023

  39. [47]

    Towards scaling blockchain systems via sharding,

    H. Dang, T. T. A. Dinh, D. Loghin, E.-C. Chang, Q. Lin, and B. C. Ooi, “Towards scaling blockchain systems via sharding,” inProceedings of 13 the 2019 international conference on management of data, 2019, pp. 123–140

    2019

  40. [48]

    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,” inProceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 17–30

    2016

  41. [49]

    Replay at- tacks and defenses against cross-shard consensus in sharded distributed ledgers,

    A. Sonnino, S. Bano, M. Al-Bassam, and G. Danezis, “Replay at- tacks and defenses against cross-shard consensus in sharded distributed ledgers,” in2020 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2020, pp. 294–308

    2020

  42. [50]

    On the impossibility of group membership,

    T. D. Chandra, V . Hadzilacos, S. Toueg, and B. Charron-Bost, “On the impossibility of group membership,” inProceedings of the fifteenth annual ACM symposium on Principles of distributed computing, 1996, pp. 322–330

    1996

  43. [51]

    Group communica- tion specifications: a comprehensive study,

    G. V . Chockler, I. Keidar, and R. Vitenberg, “Group communica- tion specifications: a comprehensive study,”ACM Computing Surveys (CSUR), vol. 33, no. 4, pp. 427–469, 2001

    2001

  44. [52]

    A secure group membership protocol,

    M. K. Reiter, “A secure group membership protocol,”IEEE Transactions on Software Engineering, vol. 22, no. 1, pp. 31–42, 1996

    1996

  45. [53]

    Au- tomatic reconfiguration for large-scale reliable storage systems,

    R. Rodrigues, B. Liskov, K. Chen, M. Liskov, and D. Schultz, “Au- tomatic reconfiguration for large-scale reliable storage systems,”IEEE Transactions on Dependable and Secure Computing, vol. 9, no. 2, pp. 145–158, 2010

    2010

  46. [54]

    From Byzantine replication to blockchain: Consensus is only the beginning,

    A. Bessani, E. Alchieri, J. Sousa, A. Oliveira, and F. Pedone, “From Byzantine replication to blockchain: Consensus is only the beginning,” in 2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2020, pp. 424–436

    2020

  47. [55]

    Lazarus: Automatic management of diversity in bft systems,

    M. Garcia, A. Bessani, and N. Neves, “Lazarus: Automatic management of diversity in bft systems,” inProceedings of the 20th International Middleware Conference, 2019, pp. 241–254

    2019

  48. [56]

    Byzantine chain replication,

    R. Van Renesse, C. Ho, and N. Schiper, “Byzantine chain replication,” inPrinciples of Distributed Systems: 16th International Conference, OPODIS 2012, Rome, Italy, December 18-20, 2012. Proceedings 16. Springer, 2012, pp. 345–359

    2012

  49. [57]

    The SMART way to migrate replicated stateful services,

    J. R. Lorch, A. Adya, W. J. Bolosky, R. Chaiken, J. R. Douceur, and J. Howell, “The SMART way to migrate replicated stateful services,” in Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006, 2006, pp. 103–115. 14 APPENDIX VIII. PROTOCOLSTAGE...

    2006

Pith tools

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