PaperlayerView exact revision on arXiv

Source-linked AI summary

Blockchain Consensus Protocols in the Wild

Christian Cachin, Marko Vukolić

arXiv:1707.01873v2cs.DC

TL;DR

Permissioned blockchain protocols need trustworthy consensus despite Byzantine faults, yet many newer proposals lack formal trust assumptions and security models. The paper reviews deployed protocols, examines their resilience under faults and attacks, and argues for cryptographic-style public review, detailed models, and formal proofs. Its analysis identifies concrete weaknesses, including Tangaroa’s safety and liveness failures, MultiChain’s takeover vulnerability, Ripple’s insufficient stated overlap, and limitations in some proprietary or fixed-leader designs.

  • Problem

    Many blockchain proposals lack formal trust assumptions and security models, while the industry lacks agreed realistic assumptions, standards, and validation for protocols.

  • Method

    The paper reviews consensus principles and protocols in permissioned blockchain platforms using available product descriptions or source code, then compares their fault models and resilience.

  • Results

    The review finds concrete resilience concerns, including Tangaroa violations of liveness and agreement, arbitrary transaction reversions in MultiChain, and Ripple’s required overlap exceeding its stated 1/5 threshold.

  • Takeaways & Limitations

    Trustworthy blockchain consensus should follow cryptography and security practice through broad agreement on assumptions, formal reasoning, expert review, open validation, and standards recommendations.

  • Takeaways & Limitations

    Chain’s Federated Consensus cannot prevent forks under a malicious generator and halts after generator crashes, requiring manual intervention.

Abstract

from arXiv · show

A blockchain is a distributed ledger for recording transactions, maintained by many nodes without central authority through a distributed cryptographic protocol. All nodes validate the information to be appended to the blockchain, and a consensus protocol ensures that the nodes agree on a unique order in which entries are appended. Consensus protocols for tolerating Byzantine faults have received renewed attention because they also address blockchain systems. This work discusses the process of assessing and gaining confidence in the resilience of a consensus protocols exposed to faults and adversarial nodes. We advocate to follow the established practice in cryptography and computer security, relying on public reviews, detailed models, and formal proofs; the designers of several practical systems appear to be unaware of this. Moreover, we review the consensus protocols in some prominent permissioned blockchain platforms with respect to their fault models and resilience against attacks. The protocol comparison covers Hyperledger Fabric, Tendermint, Symbiont, R3~Corda, Iroha, Kadena, Chain, Quorum, MultiChain, Sawtooth Lake, Ripple, Stellar, and IOTA.

1 Introduction

Permissioned blockchains apply distributed-systems techniques to reach consensus among known participants despite crashes, adversaries, and uncertain networks. The paper reviews deployed protocols, compares their resilience, and illustrates why ad-hoc designs require scrutiny.

  • Permissioned blockchains adapt Byzantine fault-tolerant techniques for consensus, state replication, and transaction broadcast under uncertain connectivity and adversarial nodes.
  • The paper surveys consensus protocols used in permissioned blockchain platforms and compares their underlying principles, resilience, and trustworthiness.
  • The authors argue that consensus protocols should not be developed ad hoc, but assessed using assumptions, security models, formal reasoning, and public discussion.
  • Tangaroa, also called BFT-Raft, is presented as a case study exposing serious flaws in a popular protocol that is not implemented in a blockchain platform.
  • The comparison covers permissioned platforms and also discusses Sawtooth Lake, Ripple, Stellar, and IOTA, which do not directly follow the BFT approach.

2 Trust in a blockchain protocol

Trust in blockchain protocols requires explicit security models, formal reasoning, and public expert validation rather than relying on functionality or untested claims. The paper argues that cryptographic methodology offers a model for establishing confidence in resilience, consistency, and liveness.

  • A secure solution must preserve its primary functionality while preventing, deterring, withstanding, or tolerating adversarial influences that could obstruct the task.This frames security as resilience of the intended service, not merely successful operation without attacks.
  • Blockchain protocols must specify trust assumptions and security models that define the environments in which their guarantees hold.These assumptions should include the network, synchronized clocks, and node behavior.
  • Experimental testing cannot exhaustively cover all scenarios allowed by a security model and can primarily demonstrate failures.Formal reasoning is therefore needed to justify security under every permitted scenario.
  • The growing blockchain field lacks broadly agreed realistic assumptions, security models, validation standards, and formal expressions of trust.Many proposals originate in fintech and startup settings without substantiating their security claims.
  • The paper argues that blockchain consensus design should adopt cryptography’s established reliance on formal models, proofs, expert review, and open validation.Cryptography combines formal security notions and provably secure protocols with human judgment about model appropriateness and deployment assumptions.

3 Consensus

Consensus protocols replicate state-machine services across nodes and order blockchain transactions despite failures, attacks, and network uncertainty. The section presents the models and protocol families used for this task, then illustrates how Byzantine-design mistakes can violate liveness or agreement.

  • Protocol families: Permissioned blockchain consensus draws on Paxos/Viewstamped Replication and PBFT, with BFT-SMaRt identified as the most advanced and widely tested implementation.The paper contrasts the relative availability of PBFT-based systems with systems implementing Paxos/VSR.
  • Consensus: Consensus in blockchain systems orders transactions so replicated nodes maintain a common ledger despite crashes, malicious behavior, and communication interruptions.Blockchain replication is used for resilience, while nodes validate information before appending it.
  • State-machine replication: State-machine replication combines a deterministic service state machine with a consensus protocol that disseminates requests in an agreed sequence.The paper uses consensus broadly for atomic broadcast, treating transactions and requests as messages delivered in that sequence.
  • Asynchronous and eventually synchronous models: The paper assumes eventual synchrony: messages may be delayed arbitrarily, but eventually arrive within a fixed unknown bound.Protocols preserve safety during asynchronous periods under the stated fault assumptions, while liveness depends on eventual synchrony.
  • Byzantine-design pitfalls: Tangaroa can violate liveness when a malicious leader wins an election and refuses to work after becoming leader.Nodes cannot verify that the leader waited for its timeout before taking leadership.
  • Byzantine-design pitfalls: Tangaroa’s reuse of Raft’s low-level messaging can violate agreement, allowing correct nodes to decide differently and permissioned ledgers to fork.Byzantine leaders require additional message-exchange rounds beyond Raft’s structure.

4 Permissioned blockchains

This section compares implemented consensus protocols in permissioned blockchain platforms and summarizes their resilience properties. It emphasizes numeric fault assumptions while noting that platforms do not yet support more complex power structures.

  • Scope: The comparison covers consortium blockchain systems and summarizes each protocol’s consensus resilience properties.The reviewed systems include Hyperledger Fabric, Tendermint, Symbiont Assembly, R3 Corda, Iroha, Kadena, Chain, Quorum, and MultiChain.
  • Scope: The review considers implemented protocols available as open source or described in sufficient marketing detail.Paper-only protocols are excluded from this section.
  • Fault assumptions: All implemented protocols discussed assume independent failures, selfish behavior, and node subversion, motivating a numeric fraction of potentially faulty nodes.This assumption underlies the trust model used in the comparison.
  • Comparison framework: Table 1 uses ✓ for resilience, − for non-resilience, ? for unassessable properties, and additional symbols for special assumptions or exceptions.The table notes non-final decisions for MultiChain, trusted hardware for PoET, and a special-validator condition for Ripple.
  • Fault assumptions: No platform yet supports more complex fault assumptions such as stake-based consensus or arbitrary consortium power structures.The paper identifies generic Byzantine quorum systems as a possible basis for such extensions.
  • Hyperledger Fabric: Fabric V1 separates smart-contract transaction execution from transaction ordering and can use Kafka, a PBFT-based orderer under development, or BFT-SMaRt.With Kafka, Fabric inherits crash resilience from ZooKeeper; PBFT and BFT-SMaRt provide resilience against subverted nodes.

4.3 Tendermint

Tendermint is a PBFT variant that disseminates transactions by gossip and rotates its leader after every block. Although additional mechanisms reportedly prevent a known livelock, thorough peer-reviewed correctness analysis remains pending.

  • Protocol design: Tendermint is a BFT protocol best described as a PBFT variant using Bracha-style Byzantine reliable broadcast.Clients disseminate transactions to validators through a gossip protocol rather than sending them directly to all nodes.
  • Protocol design: Tendermint changes its leader after every block, its most significant departure from PBFT.The protocol incorporates aspects of PBFT’s view-change mechanism into its common-case message pattern.
  • Protocol design: When a validator’s leader-message timer expires, it continues the broadcast pattern but votes for a nil block.This timeout behavior resembles PBFT’s view-change timer.
  • Correctness caveat: The original Tendermint description contains a livelock bug involving validators’ locking and unlocking votes.Additional mechanisms not described in the cited report are said to prevent the livelock from occurring.
  • Correctness caveat: Tendermint and its implementation still require thorough, peer-reviewed correctness analysis.The paper states that the protocol appears sound after considering the additional mechanisms.

4.5 R3 Corda – Raft and BFT-SMaRt

Corda uses a Hash-DAG of states and transactions rather than one globally ordered blockchain. Notary services validate transaction uniqueness, and BFT-SMaRt-based notaries tolerate subversion of f < n/3 nodes.

  • Transaction model: Corda does not order all transactions into one virtual execution; it represents transactions and states as a hashed directed acyclic graph.Only nodes affected by a transaction store it.
  • Notary services: Each Corda transaction consumes states controlled by one notary, which atomically verifies validity and uniqueness.Transactions spanning states governed by different notaries use a specialized notary-changing transaction.
  • Transaction model: Nodes store only the transactions and states that concern them, enabling data partitioning across the network.This differs from most other distributed ledgers described in the paper.
  • Notary services: A Corda notary orders and timestamps transactions referencing it and cryptographically signs statements of transaction uniqueness.Other nodes can rely on these assertions without directly communicating with the notary.
  • Notary services: Corda may deploy multiple notary services, each serving transactions involving states under its control.The resilience tables distinguish Raft-based and BFT-SMaRt-based notary services.
  • Resilience: With BFT-SMaRt running on n nodes, a Corda notary tolerates subversion of f < n/3 nodes.This is the stated resilience threshold for the BFT-SMaRt-based notary service.

4.6 Iroha – Sumeragi

Iroha’s Sumeragi is inspired by BChain’s chain-style Byzantine replication, but its documented broadcast behavior departs from that pattern. Its resilience therefore can only be characterized under the assumption that Sumeragi correctly implements BChain.

  • Sumeragi is heavily inspired by BChain, a chain-style Byzantine replication protocol using a chain topology.
  • Chain replication arranges nodes linearly, balancing load and enabling high throughput at the cost of higher latency and slower reconfiguration after faults.
  • Sumeragi orders nodes using a reputation system that considers each node’s age and past performance.
  • Sumeragi departs from the chain pattern because both the leader and tail broadcast to all nodes, so it is neither BChain nor chain replication.
  • Assuming correct BChain implementation, Sumeragi relies on the standard eventually-synchronous BFT assumptions.

4.7 Kadena – Juno and ScalableBFT

Juno claimed a BFT-Raft protocol under standard BFT assumptions, but was later replaced by proprietary ScalableBFT. Because ScalableBFT is unavailable for public review and its resilience cannot be assessed, the paper withholds a summary classification.

  • Juno claimed to use Byzantine Fault Tolerant Raft with n nodes, f < n/3 Byzantine faults, and eventual synchrony.
  • ScalableBFT replaced Juno’s protocol, but its proprietary design and implementation are unavailable for public review.
  • ScalableBFT might inherit Tangaroa’s problems, while its public claim that majority replication commits transactions does not establish the required consensus resilience.
  • 2f + 1 Byzantine quorum members are required when n = 3f + 1, so merely replicating among a majority does not suffice.
  • The claimed throughput exceeds 7000 tps, compared with 30’000–80’000 tps reported for a representative state-of-the-art BFT evaluation.
  • Because Juno and ScalableBFT cannot be assessed for resilience or intended consensus behavior, the paper provides no summary table.

4.9 Quorum – QuorumChain and Raft

Quorum provides QuorumChain and Raft-based consensus, but QuorumChain has unclear fault assumptions and can fail under malicious or multiple block-makers. Raft is presented as appropriate for protected environments without adversarial nodes.

  • Quorum is an enterprise-focused Ethereum variant with QuorumChain and Raft-based consensus as its two protocols.
  • QuorumChain’s trust model identifies voter and block-maker nodes but does not clearly specify how they may fail or behave adversarially.
  • QuorumChain propagates blocks and votes through Ethereum gossip, with block-makers proposing and voters validating and approving blocks.
  • QuorumChain: One malicious block-maker can create chain forks, while a single block-maker crash halts the protocol; synchronized clocks are also required.
  • QuorumChain: With m > 1 block-makers, safety is not guaranteed and network effects can produce forks even when all block-makers are correct.
  • Raft-based consensus: Raft replicates transactions so every participating node outputs the same sequence, making it appropriate for protected environments without adversarial nodes.

4.10 MultiChain

MultiChain uses a dynamic permissioned model in which permitted nodes mine without computational puzzles. Its random timeouts and non-final consensus permit forks, and a single attacking node can potentially control the network.

  • MultiChain targets permissioned financial-industry blockchains and multi-currency consortium exchanges while seeking Bitcoin compatibility.
  • Its dynamic permissioned model maintains a public-key-identified list of permitted nodes that can change through blockchain transactions.
  • Permitted nodes can generate blocks after random timeouts, without solving computational puzzles, subject to diversity parameter ρ.
  • Random timeouts and network uncertainty can create forks even when all nodes are correct.
  • A single attacking node can potentially take over the network and revert arbitrarily many past transactions under favorable network conditions.
  • MultiChain provides non-final transactions, and under its non-final consensus model it remains consistent and live only with one single correct node.

4.11 Further platforms

The paper examines further permissioned-blockchain consensus platforms, including proprietary designs and hashgraph. Hashgraph targets asynchronous Byzantine consensus with randomized consensus to address the FLP impossibility.

  • HydraChain: HydraChain adds a permissioned distributed ledger to Ethereum using a proprietary protocol initially inspired by Tendermint.Without a clear protocol explanation and formal review, its correctness remains unclear.
  • Hashgraph: Hashgraph is implemented in the proprietary Swirlds platform and the open-source Babble platform for distributed applications.
  • Hashgraph: Hashgraph targets consensus among n permissioned nodes while tolerating f < n/3 Byzantine faults in a completely asynchronous model.Its white paper states safety and liveness arguments and describes randomized consensus as a way to circumvent the FLP impossibility.

5 Permissionless blockchains

The paper reviews consensus mechanisms that differ from traditional permissioned BFT or permissionless proof-of-work models, emphasizing their trust assumptions and resilience boundaries. It discusses PoET, Ripple, Stellar, and IOTA, including concrete concerns about hardware dependence, quorum overlap, centralization, and unresolved analysis.

  • Scope: Proof-of-work and proof-of-stake dominate permissionless blockchains but are generally coupled to cryptocurrencies and lie outside this paper’s scope.
  • 5.1 Sawtooth Lake – Proof of Elapsed Time: PoET uses Intel SGX to generate and attest random waiting times for leader election and blockchain extension.Each node invokes an SGX enclave, waits for the generated delay, and proves that the waiting step was correctly performed.
  • 5.1 Sawtooth Lake – Proof of Elapsed Time: PoET removes mining’s energy waste, but leader probability remains proportional to controlled hardware modules and security depends on hardware running on potentially adversarial hosts.
  • 5.1 Sawtooth Lake – Proof of Elapsed Time: With authenticated modules in permissioned settings, traditional BFT protocols can tolerate f < n/2 subverted nodes and exceed 70’000 tps in a LAN.The paper contrasts this with PoET, noting BFT’s efficiency, hardware independence, and final decisions.
  • 5.2 Ripple and Stellar: Ripple documentation requires 4/5 of validators to be correct, corresponding to tolerating f < n/5 subverted nodes under traditional BFT terminology.
  • 5.2 Ripple and Stellar: Ripple’s peer-reviewed analysis requires more than 2/5 overlap between validator lists when ρ = 0.8, contradicting Ripple’s stated 1/5 minimum.
  • 5.2 Ripple and Stellar: Ripple’s default validator list is dominated by five Ripple-operated validators, making trust substantially less decentralized than its flexible trust model suggests.
  • 5.2 Ripple and Stellar: Ripple ledger entries typically complete in under four seconds, while its test network reports about 1000 tps compared with several 10’000 tps for small traditional BFT systems.

6 Conclusion

The paper summarizes prominent blockchain consensus protocols, focusing on permissioned systems with identified participants. It argues that trustworthy protocol development requires cryptographic and distributed-systems practice, while its overview provides a basis for formal reviews and technical comparisons.

  • The paper surveys prominent blockchain consensus protocols, focusing on permissioned systems whose participants are identified.
  • Consensus protocols should be developed like cryptographic systems, using established security and distributed-systems knowledge rather than relying on hype.
  • Open discussion, expert reviews, broad validation, and standards recommendations are proposed for building trustworthy systems.
  • The overview establishes common ground for formal protocol reviews and more technical comparisons.
Loading 1707.01873v2…