Pith. sign in

REVIEW 3 major objections 4 minor 46 references

Revisiting consensus protocols through wait-free parallelization

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

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

Pith's one-line read Any primary-backup Byzantine fault-tolerant consensus protocol can be parallelized into wait-free instances, so a slow or malicious leader throttles only its own instance and delays stay bounded.

desk verdict Step-wise parallelization is a genuine protocol-agnostic contribution; the wait-free theorem that supports the title is asserted, not proved, and rests on an unstated coordination assumption. read the letter →

arxiv 1908.01458 v2 pith:NGUEEKPZ submitted 2019-08-05 cs.DC cs.DB

Suyash Gupta , Jelle Hellings , Mohammad Sadoghi This is my paper · ORCID
classification cs.DCcs.DB
keywords Byzantinefaulttoleranceprimary-backupconsensuswait-freeparallelizationsoftfailuredetectionblockchaindeterministicexecutionorderclientassignmentprotocol-agnosticdesign
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

Permissioned blockchains and replicated databases often use primary-backup consensus, where one server—the primary—coordinates each round; if that server is slow or malicious, the whole system waits. This paper proposes to run m parallel instances of the same underlying consensus protocol, each with a different primary, and to combine their decisions into a single execution order. Its central claim is that this can be done in a wait-free way: an instance led by a healthy primary keeps making progress whatever the other instances do, and the time between accepting a client request and executing it stays bounded. The paper further claims the method applies to any well-behaved primary-backup protocol as a black box, evens out replica load, and shrinks the damage a faulty primary can cause.

What carries the argument

The load-bearing mechanism is the soft-failure principle (Definition 4.3) with the related gap size sigma and skip size epsilon. Each replica locally watches whether its instance is still working on round rho while another instance has already moved to round rho+sigma; if so, it treats the instance's primary as possibly faulty and pushes the instance's current round toward the failure decision F. The skip size epsilon then excludes the recovered instance from the next epsilon rounds so it can catch up, and the paper shows this keeps the per-request execution delay bounded even when one primary crashes or throttles. Two supporting mechanisms complete the design: the unified primary-replacement protocol, which deterministically selects a fresh, unused primary for every failed instance so that all non-faulty replicas agree on the same primary assignment without coordination, and the deterministic round-execution protocol, which orders the client requests accepted in a round by the permutation f_S(Hash(S) mod |S|!) of the accepted requests, so every replica executes them in the same order while no instance has a permanent position of privilege.

What would settle it

Deliver the same round rho on instance I_i to two non-faulty replicas over asymmetric links, and start round rho+sigma on another instance so that one replica's soft-failure detector classifies I_i as failed while the other has already accepted S(CR_rho) for I_i. If the first replica records F and the second records S(CR_rho) for the same instance and round, non-divergence is broken and Theorem 4.4 is refuted.

Watch

Extended reading notes

Core claim

The central claim is Theorem 4.4: when several instances of a primary-backup consensus protocol run in parallel under this design, each instance is wait-free—it can keep making successful consensus decisions without outside interference, and the delay between an instance accepting a client request and replicas executing it is upper-bounded. To get this, the paper introduces a soft-failure rule: an instance that falls more than sigma rounds behind the fastest instance is treated as failed, excluded from the next epsilon rounds, and its current round is moved to a failure decision using the underlying protocol's fault-detection machinery. Combined with a unified primary-replacement rule that lets all replicas pick the same new primary for a failed instance while keeping primaries distinct, and a deterministic hash-seeded permutation that orders each round's accepted requests identically on every replica, the paper argues that the whole parallelized protocol still satisfies termination and non-divergence. Theorem 4.6 states that this method turns any general primary-backup consensus protocol into a high-performance parallelized wait-free protocol in which every client eventually sees its requests executed, non-faulty replicas share load evenly, and faulty replicas have minimal impact.

Load-bearing premise

The whole design assumes that when one replica locally decides an instance is lagging, the underlying protocol's fault-detection machinery can make every non-faulty replica end that instance's current round with the same failure decision F, even though different replicas may have different views of who is lagging.

Editorial extensions

If this is right

  • A single faulty primary can no longer throttle the entire replicated service; only the instance it leads stalls, and it either skips epsilon rounds or is replaced while the other instances keep committing.
  • The delay between accepting a client request and executing it is bounded by parameters tied to network latency and timeouts, rather than by the slowest or most malicious instance.
  • Existing PBFT-style implementations can be parallelized without rewriting their internals, because the method only assumes well-defined rounds, termination, and non-divergence.
  • With round-robin client assignment and instance-change requests, every client eventually sees its request executed, and load is spread evenly across non-faulty replicas.
  • The same wait-free parallelization applies to partial-consensus protocols, whose eventual checkpoint and recovery steps restore full agreement.

Reading between the lines

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

  • The wait-free guarantee in Theorem 4.4 is inherited from a coordination assumption: a local soft-failure observation must be converted by the underlying protocol into a unified F decision across all non-faulty replicas; the paper treats this as infrastructure, so any implementation must supply it.
  • Since the ordering digest is unknown to primaries until the round completes, the same hash-seeded ordering could be lifted out and used as a standalone front-running defence in any primary-backup protocol; the paper notes the unpredictability but does not develop this as an independent tool.
  • A natural next step is empirical: run the design over m instances of an existing PBFT-style implementation, vary m, and compare measured acceptance-to-execution delays with the bound predicted from sigma and epsilon; the paper itself reports no experiments.
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 proposes a protocol-agnostic paradigm for parallelizing primary-backup Byzantine fault-tolerant consensus protocols. The approach runs m instances of an underlying consensus protocol in parallel, with distinct primaries per instance. Section 3 develops a step-wise design: a deterministic round-execution protocol that orders accepted client requests via a hash-derived permutation, and a unified primary-replacement protocol that keeps the set of primaries distinct across instances. Section 4 introduces a wait-free redesign. The key idea is that instances should not wait for one another: successful instances proceed to future rounds, while lagging instances are declared to suffer a "soft failure" (Definition 4.3) and skip the next ε rounds. The paper claims in Theorem 4.4 that instances are wait-free and that the delay between accepting a client request and executing it is upper-bounded, and in Theorem 4.6 that the paradigm yields a high-performance parallelized wait-free consensus protocol with balanced load and minimized impact of faulty replicas. The proof of Theorem 4.6 is given, but it relies on Theorem 4.4, for which no proof is supplied.

Significance. If established, the result would be practically significant: it offers a black-box way to reduce primary load and mitigate the throughput impact of faulty or slow primaries in permissioned blockchain systems. The paper has real strengths: the black-box round model (Definition 3.1) is a clean abstraction; the deterministic ordering protocol (Section 3.1) is coherent; and the unified primary-replacement protocol comes with a stated invariant and a proof (Proposition 3.7). The paper also ships a formal-looking theorem structure, and the wait-free goal is clearly defined. However, the central wait-free claim is not proven, and the soft-failure mechanism relies on an unstated assumption about the underlying protocol's fault-detection interface. Because the headline contribution depends on these points, the significance is conditional until the missing proof and assumptions are supplied.

major comments (3)
  1. [Section 4.1, Theorem 4.4] Theorem 4.4 is the load-bearing claim of the paper, but it is asserted without proof. The theorem states that instances are wait-free and that the delay between accepting a client request and executing it is upper-bounded. No argument is given for either conjunct, and the bound is not derived from any explicit timing model. The text informally relates σ to network latency and timeouts, and ε to σ and primary-replacement time, but Definition 4.3 does not define a formal round structure or synchrony assumptions under which such a bound can be proven. The manuscript needs either a full proof of Theorem 4.4 or a precise statement of the timing assumptions and a derivation of the bound.
  2. [Section 4.1, Definition 4.3] The soft-failure rule assumes a capability that the black-box consensus model of Definition 3.1 does not provide. Definition 3.1 guarantees that a round fails with decision F only when all non-faulty replicas observe the failure; it gives no primitive by which a single replica that locally detects a lag can force the round to end with a unanimous F. In the soft-failure description, each replica locally detects the soft failure and "uses the fault detection infrastructure of the underlying consensus protocol to work towards ending the ongoing consensus round with a decision F." This leaves open the possibility that one non-faulty replica treats round ρ as failed and moves to ρ+ε while another non-faulty replica has already accepted S(CR) for round ρ. Such a split would violate the non-divergence invariant on which Proposition 3.7 and the overall correctness argument depend. The paper must either specify a fault-detection interface that guarantees a coordinated unanimous F decision, or change the soft-failure mechanism to one that provably maintains non-divergence.
  3. [Section 4.3, Theorem 4.6] The proof of Theorem 4.6 explicitly invokes Theorem 4.4 for the wait-free property and for the claim that the impact of faulty replicas is minimized. Since Theorem 4.4 is unsupported, the main conclusions of Theorem 4.6 are also unsupported. Additionally, the proof's termination argument is too brief: it says termination follows directly from termination of the underlying consensus protocol, but for the client-side guarantee (every client eventually sees its requests executed) one must also argue that a client assigned to an instance with a faulty primary eventually reaches a non-faulty primary or is reassigned, and that soft-failure skipping does not indefinitely defer the client's request. These points should be made explicit.
minor comments (4)
  1. [Abstract and title] The title contains a line-break artifact "paralle lization" in the supplied text; this should be corrected to "parallelization."
  2. [Section 3.1, Figure 3] The pseudocode calls fS(Hash(S) mod |S(Dρ)|!) but the domain of fS is {0, ..., |S|!-1}. Since |S| = |S(Dρ)|, the modulo expression is in range, but the notation is easy to misread; a short clarifying sentence would help.
  3. [Section 4.2, client instance-change] The instance-change mechanism says a client is reassigned "in round ρ + 2σ," but σ is a time duration while ρ is a round number. The manuscript uses σ, ε, and ρ in the same expressions without formally relating rounds to time; this makes the description hard to interpret and should be clarified.
  4. [Section 4.1, paragraph after Definition 4.3] The paragraph says that "natural fluctuations in the performance of an instance can cause an unjust replacement of its primary" and then describes a recovery mechanism, but no invariant or proof is given for the combined soft-failure-plus-replacement behavior. This is related to the major concern about coordinated failure decisions and should be addressed in the revision.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the parallelization paradigm and its wait-free claim are built directly on the black-box consensus model; the main gap is an unproven theorem, not a circular derivation.

full rationale

The paper's derivation chain is self-contained. The ordering protocol (Section 3.1) and the unified primary replacement protocol (Section 3.2) are constructed directly from the black-box consensus model of Definition 3.1, with non-divergence and determinism argued in Proposition 3.7 and Proposition 3.4. Theorem 4.6 is a composition of these pieces, the termination/non-divergence of the underlying consensus protocol, the client-assignment rules, and Theorem 4.4. None of these inputs is a fitted parameter, a renamed version of the claimed output, or an imported self-citation. The wait-free claim in Theorem 4.4 is asserted without proof and relies on the soft-failure rule of Definition 4.3, which assumes that a local detection can use the underlying consensus protocol's fault-detection infrastructure to end a round with F; this is a correctness assumption that the black-box model does not explicitly justify, but it is not circular because the paper does not define wait-freedom in terms of sigma and epsilon, nor does it use Theorem 4.4 as an input to itself. Self-citations [21,22,23,37] are announcements, background, or unrelated prior work and do not carry the derivation. No fitted input is called a prediction and no uniqueness theorem is imported. The central risk is therefore an unsupported liveness/safety assumption about the underlying protocol, not circularity.

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

The central claim rests on the black-box round model and on soft-failure assumptions that are not proven for generic consensus protocols. No free numerical parameters are fitted; m, sigma, and epsilon are design parameters. No invented entities are introduced.

free parameters (3)
  • m
    Number of parallel instances. Central claims require m > f and, for replacement, m <= n - f; no value is fitted, but the guarantees depend on choosing m in this range.
  • sigma (gap size)
    Soft-failure threshold determined by network latency and timeout. If too small, non-faulty primaries are wrongly skipped; if too large, malicious slowdown is tolerated.
  • epsilon (skip size)
    Number of consensus rounds skipped after a failure. Determined by sigma and the time to replace a primary, and it appears in the bounded-delay claim of Theorem 4.4.
assumptions (7)
  • domain assumption The system requires n > 3f, where n is the number of replicas and f is the number of Byzantine faulty replicas.
    Stated in Section 2 as inherited from general-purpose consensus protocols that ensure non-divergence without synchronous communication.
  • domain assumption Non-faulty replicas are deterministic and behave according to the protocol.
    Stated in Section 2; needed so identical consensus decisions lead to identical execution order.
  • standard math A collision-resistant hash function exists and is practically impossible to invert or collide.
    Assumed in Section 2 and used in Section 3.1 to make the deterministic execution order unpredictable before the round completes.
  • domain assumption A consensus protocol can be modeled as a black box in which each round yields a single decision S(CR) or F agreed by all non-faulty replicas, and failure decisions are unanimous.
    Definition 3.1 is the basis for the round-level parallelization and for the unified primary replacement invariants.
  • domain assumption At most f replicas are faulty in a given window, and faulty replicas can recover over time.
    Section 3.2 uses this to justify both in-place recovery and unified primary replacement.
  • ad hoc to paper All instances coordinated by non-faulty primaries reach successful consensus decisions roughly within the same time, bounded by sigma.
    Section 4.1 explicitly bases the soft-failure principle on this timing assumption; it is not derived from the underlying protocol.
  • ad hoc to paper A replica that locally detects a soft failure can use the underlying protocol's fault detection infrastructure to end that instance's round with a unanimous F decision.
    Section 4.1 relies on this to convert local lag detection into a common failure decision, but the paper does not prove that a general black-box consensus protocol supports this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Revisiting consensus protocols through wait-free parallelization." pith.science (2026). https://pith.science/paper/NGUEEKPZ

@misc{pith2026190801458,
  author       = {Pith},
  title        = {Pith review of: Revisiting consensus protocols through wait-free parallelization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NGUEEKPZ}},
  note         = {Machine review of arXiv:1908.01458}
}
read the original abstract

The recent surge of blockchain systems has renewed the interest in traditional Byzantine fault-tolerant consensus protocols. Many such consensus protocols have a primary-backup design in which an assigned replica, the primary, is responsible for coordinating the consensus protocol. Although the primary-backup design leads to relatively simple and high performance consensus protocols, it places an unreasonable burden on a good primary and allows malicious primaries to substantially affect the system performance. In this paper, we propose a protocol-agnostic approach to improve the design of primary backup consensus protocols. At the core of our approach is a novel wait-free approach of running several instances of the underlying consensus protocol in parallel. To yield a high performance parallelized design, we present coordination-free techniques to order operations across parallel instances, deal with instance failures, and assign clients to specific instances. Consequently, the design we present is able to reduce the load on individual instances and primaries, while also reducing the adverse effects of any malicious replicas.

Figures

Figures reproduced from arXiv: 1908.01458 by the authors.

Figure 1
Figure 1. A basic flow of tasks undertaken by a replica while em [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. A high-level overview of a replica R. The replica coordinates a single consensus round among m instances of some consensus protocol. Each instance yields a consensus decision. The success decisions yield a set of client requests, which are executed in a deterministic order. The failure decisions are collected and can be used to replace primaries in a unified manner. to denote the partitioning of Dρ into sets of succ… view at source ↗
Figure 3
Figure 3. The execution protocol running at each non-faulty replica of service S = (C, R, F). Lemma 3.3. Function fS is a bijection from {0, . . . , |S|! − 1} to all possible permutations of S. Proof. The proof is by induction on the size of S. The base case is |S| = 1, in which case fS = {0 7→ S}, a bijection. As the induction hypothesis, we assume that fS′ is a bijection for all S ′ with |S ′ | ≤ j. Next, consider the case … view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The unified primary re￾placement protocol running at each non-faulty replica of service S = (C, R, F). 3.2.2 Unified primary replacement A second way to deal with faulty primaries is by replacement. Indeed, when m ≤ n − f our paradigm can aim for a stable set of m non-…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 35 canonical work pages

  1. [1]

    Synchronous byzantine agreement with expected O(1) rounds, expected O(n2) communication, and op- timal resilience, 2018

    Ittai Abraham, Srinivas Devadas, Danny Dolev, Kartik Na yak, and Ling Ren. Synchronous byzantine agreement with expected O(1) rounds, expected O(n2) communication, and op- timal resilience, 2018

    work page 2018

  2. [2]

    Pri me: Byzantine replication under attack

    Yair Amir, Brian Coan, Jonathan Kirsch, and John Lane. Pri me: Byzantine replication under attack. IEEE Transactions on Dependable and Secure Computing , 8(4):564–577, 2011. doi:10.1109/TDSC.2010.70

    doi:10.1109/tdsc.2010.70 2011

  3. [3]

    Blockchain for development: Emerg- ing opportunities for mobile, identity and aid, 2017

    GSM Association. Blockchain for development: Emerg- ing opportunities for mobile, identity and aid, 2017. URL: https://www.gsma.com/mobilefordevelopment/wp-content/uploads/2017/12/Blockchain-for-Development.pdf

    work page 2017

  4. [4]

    The next 700 BFT protocols

    Pierre-Louis Aublin, Rachid Guerraoui, Nikola Kneževi ć, Vivien Quéma, and Marko Vukolić. The next 700 BFT protocols. ACM Transactions on Computer Systems , 32(4):12:1–12:45,

    work page

  5. [5]

    RBFT: Redundant byzantine fault tolerance

    Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quéma . RBFT: Redundant byzantine fault tolerance. In 2013 IEEE 33rd International Conference on Distributed Com puting Systems, pages 297–306. IEEE, 2013. doi:10.1109/ICDCS.2013.53. 12

    doi:10.1109/icdcs.2013.53 2013

  6. [6]

    Christian Berger and Hans P. Reiser. Scaling byzantine co nsensus: A broad analysis. In Proceedings of the 2Nd Workshop on Scalable and Resilient In frastructures for Distributed Ledgers, SERIAL’18, pages 13–18. ACM, 2018. doi:10.1145/3284764.3284767

    work page arXiv 2018

  7. [7]

    Blockchain in Europe: Closing the s trat- egy gap

    Burkhard Blechschmidt. Blockchain in Europe: Closing the s trat- egy gap. Technical report, Cognizant Consulting, 2018. URL : https://www.cognizant.com/whitepapers/blockchain-in-europe-closing-the-strategy-gap-codex3320.pdf

    work page 2018

  8. [8]

    A leader-free byzantin e consensus algorithm

    Fatemeh Borran and André Schiper. A leader-free byzantin e consensus algorithm. In Distributed Computing and Networking , pages 67–78. Springer Berlin Heidelberg, 2010. doi:10.1007/978-3-642-11322-2_11

    work page doi:10.1007/978-3-642-11322-2_11 2010

Show all 46 references
  1. [9]

    Blockchain consensu s protocols in the wild (keynote talk)

    Christian Cachin and Marko Vukolic. Blockchain consensu s protocols in the wild (keynote talk). In 31st International Symposium on Distributed Computing , volume 91 of Leibniz In- ternational Proceedings in Informatics (LIPIcs) , pages 1:1–1:16. Schloss Dagstuhl–Leibniz- Zentr...

    2017 doi

  2. [10]

    The impact of blockchain technology on finance: A catalyst fo r change

    Michael Casey, Jonah Crane, Gary Gensler, Simon Johnso n, and Neha Narula. The impact of blockchain technology on finance: A catalyst fo r change. Techni- cal report, International Center for Monetary and Banking St udies, 2018. URL: https://www.cimb.ch/uploads/1/1/5/4/11541416...

    2018

  3. [11]

    Practical byzantine f ault tolerance

    Miguel Castro and Barbara Liskov. Practical byzantine f ault tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Imple mentation, pages 173–186. USENIX Association, 1999

    1999

  4. [12]

    Practical byzantine f ault tolerance and proac- tive recovery

    Miguel Castro and Barbara Liskov. Practical byzantine f ault tolerance and proac- tive recovery. ACM Transactions on Computer Systems , 20(4):398–461, 2002. doi:10.1145/571637.571640

    2002

  5. [13]

    Major collection of the fall auction seaso n to be recorded with blockchain technology, 2018

    Christie’s. Major collection of the fall auction seaso n to be recorded with blockchain technology, 2018. URL: https://www.christies.com/presscenter/pdf/9160/RELEASE_ChristiesxArtoryxEbsworth_9160_1.pdf

    2018

  6. [14]

    Making byzantine fault tolerant systems tolerate byzantine fault s

    Allen Clement, Edmund Wong, Lorenzo Alvisi, Mike Dahli n, and Mirco Marchetti. Making byzantine fault tolerant systems tolerate byzantine fault s. In Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation , pages 153–168. USENIX Association, 2009

    2009

  7. [15]

    Blockchain and GDPR: How blockchain could address five areas associated with gdpr compliance

    Cindy Compert, Maurizio Luinetti, and Bertrand Portier . Blockchain and GDPR: How blockchain could address five areas associated with gdpr compliance. Technical report, IBM Security, 2018. URL: https://public.dhe.ibm.com/common/ssi/ecm/61/en/61014461usen/security-ibm-security-s...

    2018

  8. [16]

    Bitcoin’s growing energy problem

    Alex de Vries. Bitcoin’s growing energy problem. Joule, 2(5):801–805, 2018. doi:10.1016/j.joule.2018.04.016

    2018 doi

  9. [17]

    Untangling blockchain: A data processing view of bl ockchain sys- tems

    Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Ji Wang. Untangling blockchain: A data processing view of bl ockchain sys- tems. IEEE Transactions on Knowledge and Data Engineering , 30(7):1366–1385, 2018. doi:10.1109/TKDE.2017.2781227

    2018

  10. [18]

    Blockchain for agriculture and food: Findings from the p i- lot study

    Lan Ge, Christopher Brewster, Jacco Spek, Anton Smeenk, and Jan Top. Blockchain for agriculture and food: Findings from the p i- lot study. Technical report, Wageningen University, 2017. URL: https://www.wur.nl/nl/Publicatie-details.htm?publicationId=publication-way-353330323634

    2017

  11. [19]

    Gordon and Christian Catalini

    William J. Gordon and Christian Catalini. Blockchain te chnology for healthcare: Facilitat- ing the transition to patient-driven interoperability. Computational and Structural Biotech- nology Journal, 16:224–230, 2018. doi:10.1016/j.csbj.2018.06.003

    2018 doi

  12. [20]

    Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu

    Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahli a Malkhi, Benny Pinkas, Michael K. Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. SBFT: a scalable and decentralized trust infrastru cture, 2018. URL: https://arxiv.org/abs/1804.01626. 13

    2018 arXiv

  13. [21]

    Bri ef announcement: revisiting consensus protocols through wait-free parallelization

    Suyash Gupta, Jelle Hellings, and Mohammad Sadoghi. Bri ef announcement: revisiting consensus protocols through wait-free parallelization. I n 33nd International Symposium on Distributed Computing , 2019

    2019

  14. [22]

    Blockchain Transaction Processing , pages 1–11

    Suyash Gupta and Mohammad Sadoghi. Blockchain Transaction Processing , pages 1–11. Springer International Publishing, 2018. doi:10.1007/978-3-319-63962-8_333-1

    2018 doi

  15. [23]

    Brief announcemen t: the fault-tolerant cluster- sending problem

    Jelle Hellings and Mohammad Sadoghi. Brief announcemen t: the fault-tolerant cluster- sending problem. In 33nd International Symposium on Distributed Computing , 2019

    2019

  16. [24]

    The promise of blockchain

    Matt Higginson, Johannes-Tobias Lorenz, Björn Münster mann, and Peter Braad Ole- sen. The promise of blockchain. Technical report, McKinsey &Company, 2017. URL: https://www.mckinsey.com/industries/financial-services/our-insights/the-promise-of-blockchain

    2017

  17. [25]

    Kamel Boulos, James T

    Maged N. Kamel Boulos, James T. Wilson, and Kevin A. Claus on. Geospatial blockchain: promises, challenges, and scenarios in health and healthca re. International Journal of Health Geographics, 17(1):1211–1220, 2018. doi:10.1186/s12942-018-0144-x

    2018 doi

  18. [26]

    Zyzzyva: Speculative byzantine fault tolerance

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: Speculative byzantine fault tolerance. In Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems Principles , pages 45–58. ACM, 2007. doi:10.1145/1294261.1294267

    2007

  19. [27]

    Zyzzyva: Speculative byzantine fault tolerance

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: Speculative byzantine fault tolerance. ACM Transactions on Computer Systems , 27(4):7:1–7:39, 2009. doi:10.1145/1658357.1658358

    2009

  20. [28]

    Karame, and N

    Jian Liu, Wenting Li, Ghassan O. Karame, and N. Asokan. S calable byzantine consensus via hardware-assisted secret sharing. IEEE Transactions on Computers , 68(1):139–151, 2019. doi:10.1109/TC.2018.2860009

    2019

  21. [29]

    Menezes, Scott A

    Alfred J. Menezes, Scott A. Vanstone, and Paul C. Van Oor schot. Handbook of Applied Cryptography. CRC Press, Inc., 1st edition, 1996

    1996

  22. [30]

    The honey badger of BFT protocols

    Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of BFT protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer an d Communications Security, pages 31–42. ACM, 2016. doi:10.1145/2976749.2978399

    2016

  23. [31]

    Bitcoin: A peer-to-peer electronic c ash system

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic c ash system. URL: https://bitcoin.org/en/bitcoin-paper

  24. [32]

    Nawab and M

    F. Nawab and M. Sadoghi. Blockplane: A global-scale byza ntizing middleware. In 2019 IEEE 35th International Conference on Data Engineering (IC DE), pages 124–135, April

    2019

  25. [33]

    Byzantine Agreement , pages 255–259

    Michael Okun. Byzantine Agreement , pages 255–259. Springer New York, 2016. doi:10.1007/978-1-4939-2864-4_60

    2016 doi

  26. [34]

    Blockchain and economic dev elopment: Hype vs

    Michael Pisa and Matt Juden. Blockchain and economic dev elopment: Hype vs. reality. Technical report, Center for Global Developme nt, 2017. URL: https://www.cgdev.org/publication/blockchain-and-economic-development-hype-vs-reality

    2017

  27. [35]

    Bitcoin developer guide: P2p network, 2 018

    Bitcoin Project. Bitcoin developer guide: P2p network, 2 018. URL: https://bitcoin.org/en/developer-guide#p2p-network

  28. [36]

    Blockchain – an opportunity for energy producers an d consumers?, 2016

    PwC. Blockchain – an opportunity for energy producers an d consumers?, 2016. URL: https://www.pwc.com/gx/en/industries/energy-utilities-resources/publications/opportunity-for-energy-pr oducers.html

    2016

  29. [37]

    Transaction Proces sing on Modern Hardware

    Mohammad Sadoghi and Spyros Blanas. Transaction Proces sing on Modern Hardware. Synthesis Lectures on Data Management , 14(2):1–138, 2019

    2019

  30. [38]

    Conflict-free replicated data types

    Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Z awirski. Conflict-free replicated data types. In Proceedings of the 13th International Conference on Stabil ization, Safety, and Security of Distributed Systems , pages 386–400. Springer-Verlag, 2011

    2011

  31. [39]

    Introduction to Distributed Algorithms

    Gerard Tel. Introduction to Distributed Algorithms . Cambridge University Press, 2nd edi- tion, 2001

    2001

  32. [40]

    Tanenbaum

    Maarten van Steen and Andrew S. Tanenbaum. Distributed Systems . Maarten van Steen, 3th edition, 2017. URL: https://www.distributed-systems.net/. 14

    2017

  33. [41]

    Spin one’s wheels? byzantine fault tolerance with a spinnin g primary

    Giuliana Santos Veronese, Miguel Correia, Alysson Nev es Bessani, and Lau Cheuk Lung. Spin one’s wheels? byzantine fault tolerance with a spinnin g primary. In 28th IEEE International Symposium on Reliable Distributed Systems , pages 135–144. IEEE, 2009. doi:10.1109/SRDS.2009.36

    2009 doi

  34. [42]

    Sustainability of bitcoin and blockch ains

    Harald Vranken. Sustainability of bitcoin and blockch ains. Current Opinion in Environ- mental Sustainability , 28:1–9, 2017. doi:10.1016/j.cosust.2017.04.011

    2017 doi

  35. [43]

    Ethereum: a secure decentralised generali sed transaction ledger

    Gavin Wood. Ethereum: a secure decentralised generali sed transaction ledger. EIP-150 revision. URL: https://gavwood.com/paper.pdf

  36. [44]

    LinBFT: Linear-communication byzantine faul t tolerance for public blockchains,

    Yin Yang. LinBFT: Linear-communication byzantine faul t tolerance for public blockchains,

  37. [2018]

    URL: https://arxiv.org/abs/1807.01829. 15

    arXiv

  38. [2019]

    doi:10.1109/ICDE.2019.00020

    2019

Pith tools

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