PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Distributed Consensus Protocols for Blockchain Networks

Yang Xiao, Ning Zhang, Wenjing Lou, Y. Thomas Hou

arXiv:1904.04098v4cs.CRcs.DC

TL;DR

Blockchain consensus protocols are numerous, but their differing assumptions, fault tolerance, scalability, and trade-offs require systematic comparison. This survey establishes a fault-tolerance foundation, introduces a five-component framework, and reviews protocols through abstractions, vulnerability analyses, and performance comparisons. It concludes that protocol families occupy different operating points, with BFT-style finalization supporting thousands of TPS only at network sizes typically around several hundred, while large-scale public networks generally use probabilistic finality and throughput capped by a hundred TPS for security reasons.

  • Problem

    The proliferation of blockchain consensus mechanisms creates a need for a formal, cohesive analysis of their performance, fault tolerance, security implications, and application suitability.

  • Method

    The survey synthesizes consensus protocols using a five-component framework, algorithmic abstractions, vulnerability analyses, and comparisons across performance and fault-tolerance dimensions.

  • Results

    BFT-style block finalization can achieve thousands of TPS with networks typically around several hundred nodes, whereas large-scale public protocols generally use probabilistic finality and throughput capped by a hundred TPS.

  • Takeaways & Limitations

    The survey provides a comprehensive view of protocol fundamentals, use cases, vulnerabilities, performance, and design trade-offs for researchers and developers.

Abstract

from arXiv · show

Since the inception of Bitcoin, cryptocurrencies and the underlying blockchain technology have attracted an increasing interest from both academia and industry. Among various core components, consensus protocol is the defining technology behind the security and performance of blockchain. From incremental modifications of Nakamoto consensus protocol to innovative alternative consensus mechanisms, many consensus protocols have been proposed to improve the performance of the blockchain network itself or to accommodate other specific application needs. In this survey, we present a comprehensive review and analysis on the state-of-the-art blockchain consensus protocols. To facilitate the discussion of our analysis, we first introduce the key definitions and relevant results in the classic theory of fault tolerance which help to lay the foundation for further discussion. We identify five core components of a blockchain consensus protocol, namely, block proposal, block validation, information propagation, block finalization, and incentive mechanism. A wide spectrum of blockchain consensus protocols are then carefully reviewed accompanied by algorithmic abstractions and vulnerability analyses. The surveyed consensus protocols are analyzed using the five-component framework and compared with respect to different performance metrics. These analyses and comparisons provide us new insights in the fundamental differences of various proposals in terms of their suitable application scenarios, key assumptions, expected fault tolerance, scalability, drawbacks and trade-offs. We believe this survey will provide blockchain developers and researchers a comprehensive view on the state-of-the-art consensus protocols and facilitate the process of designing future protocols.

I. INTRODUCTION

Blockchain provides a decentralized, replicated ledger, while distributed consensus determines how participants agree on it and strongly affects security and performance. This survey reviews competing protocols and compares their assumptions, fault tolerance, scalability, and trade-offs.

  • Blockchain replicates a transaction database across participating nodes without relying on a central authority to establish trust or clear transactions.
  • Consensus protocols ensure participants agree on a unified transaction ledger and influence transaction capacity, scalability, and fault tolerance.
  • Nakamoto consensus enabled Bitcoin to resist double-spending in a decentralized network, but its PoW mechanism raised energy-consumption and performance concerns.
  • Researchers proposed PoS, PoA, PoET, coordinated block generation, and incentive mechanisms to address PoW limitations and encourage honest participation.
  • The survey reviews classical fault tolerance and blockchain protocols using a five-component framework, algorithmic abstractions, vulnerability analyses, and comparisons.
  • Prior surveys compare protocol classes, committees, incentives, security, and performance, but differing coverage leaves motivation for further cohesive analysis.

B. Byzantine Fault Tolerant Consensus

Byzantine fault-tolerant consensus combines safety and liveness requirements with replication and ordered communication under explicit fault assumptions. Classical protocols differ in failure model, quorum threshold, and communication cost.

  • BFT consensus requires termination, agreement, validity, and integrity, with N ≥3f + 1 processes to tolerate f Byzantine failures.
  • Distributed consensus requires safety through identical ordered execution and liveness through serving all requests despite faulty servers.
  • State machine replication uses identical initial states, total-order broadcast, and deterministic execution to keep replicated servers synchronized.
  • In leader-based SMR, a primary receives client requests, initiates broadcast, and replicas update state before execution.
  • DLS provides a broadcast primitive with O(N^2) message complexity and tolerates f Byzantine processes when N ≥3f + 1; Tendermint adapts it for block finalization.
  • VR tolerates f crash failures when N ≥2f + 1 but no Byzantine failures, while Paxos has the same crash threshold and O(N^2) message complexity.

4) Practical Byzantine Fault Tolerance (PBFT):

PBFT is an SMR-based BFT protocol organized around normal operation, checkpoints, and view changes. It achieves agreement despite Byzantine servers under N ≥ 3f + 1, but its quadratic messaging limits scalability.

  • Protocol structure: PBFT comprises Normal-operation, Checkpoint, and View-change sub-protocols.Checkpoints track active requests and support safe log discarding, while view change replaces a failed primary.
  • Normal operation: The normal operation proceeds through pre-prepare, prepare, commit, and reply phases.Replicas relay prepare messages to all servers and execute requests after receiving at least 2f + 1 commit messages.
  • View change: When a primary fails, replicas broadcast view-change messages and the next-in-line replica becomes primary after receiving messages from 2f peers.The new primary informs the remaining replicas to resume normal operation.
  • Complexity and fault tolerance: O(N^2) message complexity and N ≥ 3f + 1 allow PBFT to tolerate f Byzantine servers while preserving the same result among honest servers.Servers require more than 2f + 1 prepare and commit messages before proceeding, preventing Byzantine servers from swaying the majority.
  • Asynchronous consensus: Asynchronous consensus cannot guarantee deterministic progress with even one crash failure, so randomized protocols use probabilistic termination.Bracha’s protocol uses three reliable-broadcast rounds per phase and randomizes proposal values when insufficient peer agreement exists.
  • Asynchronous consensus: Bracha’s reliable broadcast has O(N^2) message complexity per round, while randomized consensus requires O(2^N) expected rounds when f = O(N).In the benign case f = O(√N), the expected number of rounds is constant, yielding total message complexity O(N^2).
  • ACS: Ben-Or’s ACS combines reliable broadcast and binary asynchronous Byzantine agreement to produce a common subset, tolerating f Byzantine players when N ≥ 3f + 1.Its bit-denominated communication complexity is O(mN^2 + N^3) at each player.

3) HoneyBadgerBFT:

HoneyBadgerBFT is an asynchronous blockchain consensus protocol that combines encrypted transaction proposals with ACS-based agreement. It improves tolerance to unpredictable delays and leader bottlenecks, but confirmation latency remains externally influenced.

  • Protocol overview: HoneyBadgerBFT is designed for blockchain and lets players agree on a common set of sorted transactions for a block.It realizes atomic broadcast across players holding different transaction sets.
  • Protocol design: HoneyBadgerBFT follows Ben-Or’s ACS construction and combines erasure-coded RBC with common-coin ABA.Threshold public-key encryption is applied before ACS to prevent an adversary from censoring particular transactions.
  • Transaction batching: Each player proposes B/N randomly selected transactions per block cycle so proposals are mostly disjoint and blockchain throughput is maximized.B denotes the maximum number of transactions a block may contain.
  • Performance: O(|t|B) communication complexity per player, or O(|t|N) per transaction, results when the RBC dominates overhead.Here |t| is the average transaction bit-size and B is the batch size.
  • Advantages: HoneyBadgerBFT avoids timeout-based malfunction detection and leader rotation, reducing sensitivity to unpredictable delays and individual-leader bandwidth bottlenecks.Its Byzantine agreement instances execute concurrently, eliminating the need for a leader to start every consensus round.
  • Limitation: Asynchronous progress makes transaction confirmation latency externally influenced and uncontrollable, limiting suitability where low latency matters more than throughput.Industrial control and supply chain management are identified as examples of such applications.
  • Broader challenges: BFT protocols face scalability and blockchain-compatibility challenges, including quadratic communication growth and flexible node membership.PBFT throughput reportedly falls from 16,000 TPS at N = 8 to around 3,000 TPS at N = 64.

IV. AN OVERVIEW OF BLOCKCHAIN CONSENSUS

Blockchain infrastructure combines peer-to-peer participation with hash-chained transaction storage and Merkle-tree integrity checks. Consensus protocols must satisfy ledger requirements through five components: proposal, propagation, validation, finalization, and incentives.

  • Blockchain infrastructure: Blockchain networks are peer-to-peer systems in which nodes operate autonomously under shared rules for consensus, transaction processing, and ledger management.The network commonly overlays the Internet and relies on transport-layer protocols for message delivery.
  • Network categories: Permissionless blockchains allow free participation under pseudonyms, whereas permissioned blockchains require authorization and revealed identities.Permissioned networks are suited to internal or multiparty business applications because of identity-based governance.
  • Blockchain data structure: Blocks are chronologically linked by hash pointers, and each block contains transactions organized with a Merkle tree for integrity checking.The Merkle root summarizes the transactions included in a block.
  • Transactions: A blockchain transaction records token redistribution between accounts through signed inputs and outputs.Transactions must be valid and free of double spending before inclusion in blocks.
  • Consensus goals: Blockchain consensus targets a common transaction history and requires termination, agreement, validity, and integrity.Agreement adds total ordering, while integrity requires consistent transactions and correctly hash-chained blocks.
  • Consensus components: The five consensus components are block proposal, information propagation, block validation, block finalization, and incentive mechanism.Incentives promote honest participation and, with generation proofs, help deter Sybil attackers in large permissionless networks.

V. THE NAKAMOTO CONSENSUS PROTOCOL AND VARIATIONS

Nakamoto consensus combines proof-of-work block generation, gossip-based propagation, validation, longest-chain selection, and probabilistic finality. Its security depends on an honest majority of hashing power, while forks and temporary conflicting blocks are resolved probabilistically.

  • Protocol overview: Nakamoto consensus is Bitcoin’s protocol and uses proof of work to generate blocks by finding a hash preimage below a dynamically adjusted difficulty target.The target is adjusted to maintain an average block-generation interval.
  • Information propagation and validation: Nodes advertise newly received or generated blocks, retrieve requested blocks, validate them, and relay them through the peer-to-peer network.Validation includes double-spending checks and proof-of-work validity checks on block headers.
  • Finality and security: Accepted blocks have probabilistic finality: their probability of later removal decreases exponentially as the blockchain grows.Temporary conflicting decisions are permitted, and the protocol achieves eventual double-spending resistance rather than immediate deterministic finality.
  • Fork resolution: The longest valid chain represents consensus, and miners extend it while orphaning competing blocks when forks occur.Forks arise when blocks at the same height propagate concurrently; the first-arrived or longest-chain choice determines continuation.
  • Incentives: Block rewards and transaction fees incentivize block generation, while proof-of-work converts scarce computing power into resistance against Sybil identities.Mining revenue is tied to computing power, and the protocol includes coinbase rewards plus transaction fees.
  • Finality and security: If the network synchronizes faster than block production and malicious miners control less than 50% of hashing power, honest miners can eventually outgrow malicious branches.The stable prefix is the probabilistically settled portion of the blockchain.

C. Drawbacks and Vulnerabilities of Nakamoto Consensus

Nakamoto consensus faces a throughput–security trade-off and substantial energy costs. Shorter block intervals or larger blocks increase capacity but impair propagation and security, while proof-of-work drives high electricity consumption.

  • Tight tradeoff between performance and security: Bitcoin processes up to 7 TPS, compared with VISA’s average of 2500 TPS, reflecting Nakamoto consensus’s limited transaction throughput.The limitation is tied to probabilistic finality, block interval, and block size.
  • Tight tradeoff between performance and security: Reducing the 10-minute block interval or increasing the 1MB block size can worsen propagation, increase forks, and undermine main-chain security.Higher fork rates waste honest mining power and can lower the hashing-power threshold needed for a double-spending attack.
  • Energy consumption: As of November 2019, an average Bitcoin transaction consumed 431 KWh of electricity, driven directly by proof-of-work block proposing.Maintaining the average 10-minute interval as mining capacity grows requires higher difficulty and encourages additional mining hardware.

3) Eclipse attack:

The survey describes vulnerabilities and proposed variations around Nakamoto consensus, including eclipse and selfish-mining attacks, GHOST, Bitcoin-NG, and hybrid PoW–BFT designs. These mechanisms trade decentralization, throughput, finality, and attack resistance in different ways.

  • 3) Eclipse attack:: An eclipse attacker can isolate a victim miner from the main network, preventing the victim from contributing normally to main-chain extension.The attack exploits weak peer-to-peer connectivity; secure channels and greater connectivity and geographic diversity are proposed countermeasures.
  • 4) Selfish mining:: Selfish mining exploits withheld blocks and strategic publication, allowing a sufficiently capable group to earn disproportionate revenue and potentially attract additional miners.The threshold depends on communication capability γ and approaches zero as γ approaches 1.
  • 1) GHOST Rule:: GHOST incorporates orphaned blocks into security, reducing fork impacts and permitting shorter block intervals than the longest-chain rule.Its probabilistic finality still requires more than 50% honest mining power.
  • 1) GHOST Rule:: Ethereum’s GHOST variation supports a 10–15 second block interval and up to 25 TPS, versus Bitcoin’s 10-minute interval and 7 TPS.The cited comparison contrasts the shorter interval and higher throughput achieved with uncle-block handling.
  • 2) Bitcoin-NG:: Bitcoin-NG separates leader election into PoW key blocks and transaction serialization into micro blocks generated by the current key-block miner.Micro-block frequency and size determine throughput but excessive frequency can exhaust bandwidth and increase key-block forks.
  • 3) ByzCoin:: Hybrid protocols combine PoW-based identity or committee formation with BFT mechanisms, while ByzCoin requires N ≥3f + 2 and remains vulnerable to key-block forks that can stall PBFT.ByzCoin uses deterministic prioritization to reduce fork impacts and selfish-mining effects.

4) Pass and Shi’s hybrid consensus:

Pass and Shi’s hybrid consensus uses a sliding-window consensus group selected from recent stable-chain miners while keeping PBFT off-chain. Hybrid PoW-BFT designs use PoW to maintain scalable consensus groups, with signature aggregation helping reduce communication complexity.

  • Pass and Shi’s hybrid consensus: The consensus group comprises the last λ miners of the stable blockchain portion, whose latest Θ(λ) blocks are truncated.The window-based design is described as less susceptible to forks than ByzCoin’s similar sliding-window approach.
  • Pass and Shi’s hybrid consensus: PBFT remains off-chain, with only the consensus epoch number and transaction-log digest attached to new blocks.
  • Hybrid PoW-BFT designs: Hybrid PoW-BFT protocols use PoW to maintain a stable consensus group for each BFT instance, limiting communication overhead as the group grows.Open computational participation functions as soft permission control for public blockchains.
  • Hybrid PoW-BFT designs: CoSi and aggregated signature gossip can reduce communication complexity in sparsely connected peer-to-peer networks and support more consensus participants.
  • Design space: Hybrid PoW-BFT designs remain one family among multiple possible PoW-BFT and PoX-BFT combinations, with cryptographic techniques often serving as complementary components.

1) Peercoin and Nxt:

Peercoin and Nxt replace PoW block generation with stake-based hashing, while differing in how stake value changes over time. The broader committee-based PoS family instead uses MPC to coordinate block-generation opportunities.

  • Peercoin and Nxt: Peercoin and Nxt use chain-based PoS, preserving gossiping, validation, longest-chain, and probabilistic-finality components while replacing PoW block generation.Chain-based PoS minters deposit stake and run a PoS-specific block-generation loop.
  • Peercoin and Nxt: Peercoin values stake with coin age, allowing unused stake value to appreciate linearly over time, whereas Nxt resets appreciation after each block cycle.
  • Security analysis: Chain-based PoS tolerates up to 50% malicious stake, but attackers controlling more than 50% can grow a malicious chain faster and double-spend.
  • Committee-based PoS: Committee-based PoS uses MPC to determine a stakeholder committee that generates blocks in an orderly sequence instead of relying solely on hashing puzzles.CoA generates random bytes through MPC, feeds them to FTS, and obtains a shared pseudo-random block-generation sequence.

2) Ouroboros:

Ouroboros organizes time into epochs and slots, electing slot leaders through a publicly verifiable secret-sharing process. Related variants address synchrony, sporadic participation, finality, and committee scalability constraints.

  • Ouroboros: Ouroboros divides time into fixed epochs, each containing N slots assigned to individual slot leaders who generate blocks.Stakeholders with sufficient stake become electors and collectively select the next epoch’s leaders through publicly verifiable secret sharing.
  • Ouroboros: PVSS-based leader selection produces a common random seed and ensures electors obtain the same slot-leader sequence.
  • Ouroboros Praos: Ouroboros Praos supports partially synchronous networks with unknown message-delay bounds and uses empty slots to address desynchronization concerns.Its VRF-based privacy and KES provide flexible participation and forward security against posterior corruption.
  • Snow White: Snow White accommodates sporadic online and offline participation through asynchronous consensus, committee reconfiguration, and checkpointing.These mechanisms support operation under frequent disconnections and volatile message delays while protecting earlier history from posterior corruption.
  • Security analysis: Committee-based PoS retains longest-chain probabilistic finality, while larger committees can increase communication overhead, latency, and desynchronization risk.Limiting committee size through minimum-stake requirements trades participation breadth for performance.

2) Algorand:

Algorand combines committee-based PoS block proposal with Byzantine agreement for block finalization. Its design uses cryptographic sortition for committee selection and BA⋆ to agree on a proposed or empty block.

  • Algorand: Algorand selects the block-proposing committee using cryptographic sortition, a VRF-based process that ranks candidates according to their coin holdings.Eligible users broadcast proofs that others can verify using the proposer’s public key.
  • Algorand: BA⋆ reduces finalization to binary Byzantine agreement over either a proposed block or an empty block.Under strong network synchrony, the committee exchanges votes and decides the final outcome.
  • Casper FFG: Casper FFG applies stake-weighted checkpoint voting to finalize checkpoints on top of Ethereum’s PoW-based block proposal mechanism.
  • Casper FFG and Ethereum 2.0: Ethereum 2.0’s planned PoS-and-sharding design faces challenges from small-shard takeover risk and inter-shard coordination and transfer.
  • Security analysis: BFT-based PoS tolerates up to 1/3 Byzantine validators in Tendermint and up to 1/3 maliciously controlled stake in Algorand and Casper FFG.

D. Delegated PoS (DPoS)

DPoS selects a limited consensus group through public stake delegation, combining representative voting with committee-based consensus. Its design controls messaging overhead, uses rewards to encourage participation, and can tolerate one-third malicious delegates when BFT finalization is used.

  • Delegation process: DPoS elects a limited consensus group through public stake delegation, with token holders voting for delegates using their stakes.The most-voted delegates form the consensus group, and voters can switch their delegation through another blockchain transaction.
  • Delegation process: DPoS controls consensus-group size so that protocol messaging overhead remains manageable.The elected group members are called delegates and participate as representatives of their voters.
  • Consensus operation: EOSIO limits consensus participation to its top 21 delegates and uses pipelined PBFT-style consensus to finalize proposed blocks.Block-proposal rights are equally shared among the 21 delegates.
  • Incentive mechanism: DPoS rewards delegates through daily vote-rewards and block rewards for validation work.The incentive mechanism is designed to encourage honest delegation and consensus participation.
  • Security analysis: 1/3 of delegates is the stated malicious-delegate tolerance when BFT is used for block finalization.For EOSIO, this corresponds to at most 6 out of 21 delegates being malicious.
  • Security analysis: PoS remains vulnerable to costless simulation, in which attackers can reproduce blockchain history without computation-intensive work.The survey identifies this as a major vulnerability of non-BFT-based PoS schemes, especially chain-based PoS.

3) Posterior corruption:

The survey examines posterior corruption and related PoS vulnerabilities arising from costless simulation and public staking history. It also reviews alternative mechanisms that use checkpointing, authority, trusted hardware, or storage resources, each with distinct security and decentralization trade-offs.

  • Posterior corruption: Posterior corruption exploits public staking history by bribing former large stakeholders to support an alternative chain.The attack targets stakeholders who once held substantial stakes but hold little at present.
  • Long-range attacks: Long-range attacks let colluding attackers regrow a valid chain from near the genesis block through costless simulation.Early blockchain history may have contained few stakeholders and little competition, allowing attackers to reproduce PoS blocks quickly.
  • Mitigations: Checkpointing can resolve general long-range attacks but may undermine permissionless-blockchain decentralization because authoritative entities must endorse finality.Checkpointing is widely used in BFT protocols to finalize agreements and discard older records.
  • Proof of Authority: PoA replaces monetary-token staking with identity staking and relies on a small, trusted validator group.Its fault tolerance depends on the consensus protocol used by that group; BFT provides a one-third threshold, while AuRa can tolerate up to 50% colluding validators.
  • Proof of Elapsed Time: PoET replaces hashing-intensive mining with random exponential back-off executed in trusted environments, but remains vulnerable to Sybil attacks.PoET can tolerate up to 50% malicious TEE nodes and is most suited to permissioned blockchains with authenticated participants running one TEE node.
  • Proof of TEE-Stake: PoTS combines TEE-certified committee selection with staking and can tolerate up to 50% malicious stake at TEE nodes.The survey reports greater robustness against Sybil attacks than PoET, while noting that TEE hardware still creates a single point of risk.
  • Proof of Retrievability: PoR uses storage resources for challenge-response retrievability and can support meaningful storage tasks beyond block production.Compared with PoW, storage consumes less energy and can be recycled; the survey states that meaningful storage use is not found in other proof-of-X schemes.

E. Ripple Consensus Protocol/Algorithm (RCPA)

RCPA uses validator-defined UNLs and repeated transaction filtering to finalize ledger epochs, with an 80% final-round voting threshold. Its 1/5 fault-tolerance bound trades against lower connectivity and message complexity, while DAG protocols pursue throughput beyond linear blockchains.

  • Protocol setting: Ripple treats individual transactions, rather than blocks, as the ledger’s atomic items.RCPA underlies Ripple, a global payment and gross settlement network operated by Ripple.
  • Validator network: Each validator establishes a unique UNL of trusted peers with which it directly exchanges messages.Reciprocal UNL relationships define fully connected UNL cliques.
  • Consensus operation: RCPA runs in epochs that finalize transactions through multiple rounds of filtering, then marks the ledger closed.Nodes collect transactions, broadcast candidate sets to UNL peers, and vote yes or no on transaction veracity.
  • Consensus threshold: 80% is the final-round yes-vote threshold, matched to an assumption that any two UNL cliques overlap by at least 20%.With sufficiently many rounds, valid transactions proposed by non-faulty nodes should eventually exceed the threshold in an ideal environment.
  • Security analysis: RCPA requires no more than 1/5 faulty nodes in every UNL clique to ensure overall network consensus.Compared with PBFT’s 1/3 Byzantine tolerance and O(N^2) messaging, RCPA uses a 1/5 bound and O(NK) message complexity per block cycle.
  • Security analysis: Ripple’s 1/5 fault tolerance and synchrony requirement may be restrictive for low-trust environments, consistent with its corporate and financial-institution customer base.Stellar shifted to federated Byzantine quorum systems and achieves a 1/3 BFT bound with looser synchrony requirements.
  • DAG-based protocols: DAG-based consensus seeks higher throughput by avoiding a linearly growing chain of blocks with fixed time intervals.In blockDAGs, blocks can reference multiple parents, making parent selection a central design challenge; SPECTRE and PHANTOM address this problem.

2) PHANTOM:

The survey contrasts DAG-based consensus designs, emphasizing their transaction-processing mechanisms, finality assumptions, fault tolerance, and scalability trade-offs. It presents DAG protocols as promising for large permissionless networks while noting unresolved security concerns.

  • PHANTOM: PHANTOM extends SPECTRE by providing a fully linear ordering of transactions and blocks in a blockDAG.This addresses SPECTRE’s weak liveness and increased exposure to balancing attacks caused by incomplete ordering.
  • PHANTOM: SPECTRE and PHANTOM retain Nakamoto-style PoW proposal, gossip propagation, and validity checks, tolerating up to 50% malicious computing power.Their blockDAG structure can theoretically support arbitrary throughput, limited by network bandwidth and node processing speed.
  • TxDAG: TxDAG protocols assign unique transactions to vertices, avoiding the overlapping transactions and conflict-resolution overhead found in blockDAGs.This design can free processing capacity and support higher transaction throughput.
  • Tangle: Tangle requires each new transaction to approve two tips, while its DAG structure theoretically supports millions of transactions per second or unbounded capacity.In practice, its security depends on PoW and its MCMC tip-selection scheme has been reported vulnerable to parasite-chain attacks.
  • Byteball and Nano: Byteball uses a main chain and fixed witness group for consensus, whereas Nano uses parallel account-specific blockchains with stake-weighted fork voting.Byteball’s identified witnesses support deterministic finality but reduce decentralization; Nano isolates faulty transactions to affected accounts but requires high synchrony and may scale poorly.

IX. ON DESIGNING BLOCKCHAIN CONSENSUS PROTOCOL

The survey argues that blockchain consensus design has shifted toward more formal, modular approaches grounded in distributed computing, cryptography, and trusted computing. It frames protocol design as balancing security, decentralization, and scalability according to application needs.

  • A. The Paradigm Shift in Protocol Design: Recent blockchain protocols increasingly adapt reliable broadcast, Byzantine agreement, MPC, trusted execution environments, and formal security frameworks.This marks a shift from heuristic design toward more rigorous scientific analysis.
  • B. The Security–Decentralization–Scalability Trilemma: Consensus protocols should balance security, decentralization, and scalability rather than optimize a single objective.Scalability includes remaining secure and efficient as transaction throughput and network size increase.
  • B. The Security–Decentralization–Scalability Trilemma: Higher scalability can involve lower security: shorter Nakamoto block intervals increase throughput but also increase the chance of a 51%-attack.The security implications of DAG scalability with network size and throughput remain insufficiently studied.
  • B. The Security–Decentralization–Scalability Trilemma: Greater decentralization can reduce synchrony, giving well-connected nodes communication advantages that may impair consensus security.Geographic diversity can enhance liveness by making censorship more difficult, while sparse connectivity can create unfair dissemination advantages.
  • Design Implications: There is no one-size-fits-all consensus protocol, so designers can combine or update individual components for specific application needs.Modular changes are especially valuable in established networks because protocol changes require network-wide consensus and substantial coordination.
Loading 1904.04098v4…