Source-linked AI summary
Scaling Nakamoto Consensus to Thousands of Transactions per Second
Chenxing Li, Peilun Li, Dong Zhou, Wei Xu, Fan Long, Andrew Yao
TL;DR
Blockchain performance is limited by discarded concurrent blocks, slow confirmation, and the resulting throughput bottleneck. Conflux uses a DAG-based consensus protocol to process concurrent blocks, agree on their total order, and derive transaction order deterministically. Evaluations with up to 20k full nodes report 5.76GB/h, equivalent to 6400 transactions per second, with 4.5-7.4-minute confirmation, while shifting the bottleneck to individual-node processing capability.
Problem
Standard Nakamoto consensus discards concurrent blocks as forks, limiting throughput and making high-confidence Bitcoin confirmation take hours.
Method
Conflux uses a DAG-based consensus protocol that processes concurrent blocks, agrees on a block total order, and derives transaction order deterministically.
Results
5.76GB/h, equivalent to 6400 transactions per second for typical Bitcoin transactions, is achieved with 4.5-7.4-minute confirmation under the 40Mbps setting.
Takeaways & Limitations
Conflux throughput is no longer limited by consensus but by the processing capability of individual nodes.
Takeaways & Limitations
The paper focuses on consensus protocol design and implementation and leaves a compatible incentive mechanism for future work.
Abstract
from arXiv · showhide
This paper presents Conflux, a fast, scalable and decentralized blockchain system that optimistically process concurrent blocks without discarding any as forks. The Conflux consensus protocol represents relationships between blocks as a direct acyclic graph and achieves consensus on a total order of the blocks. Conflux then, from the block order, deterministically derives a transaction total order as the blockchain ledger. We evaluated Conflux on Amazon EC2 clusters with up to 20k full nodes. Conflux achieves a transaction throughput of 5.76GB/h while confirming transactions in 4.5-7.4 minutes. The throughput is equivalent to 6400 transactions per second for typical Bitcoin transactions. Our results also indicate that when running Conflux, the consensus protocol is no longer the throughput bottleneck. The bottleneck is instead at the processing capability of individual nodes.
1 Introduction
Conflux addresses blockchain performance limits by processing concurrent blocks in a DAG and deriving transaction order after block-order consensus. Its evaluation reports thousands of transactions per second, minute-scale confirmation, and node-processing rather than consensus as the throughput bottleneck.
- Motivation: Bitcoin’s standard Nakamoto consensus discards concurrent blocks as forks and limits throughput to 7 transactions per second, with confirmation often taking hours.The protocol’s slowness is presented as necessary for defense against adversaries, while users typically wait for tens of additional blocks.
- Conflux: Conflux optimistically processes concurrent transactions and blocks, deferring transaction ordering until it derives that order from an agreed block total order.Conflicting or duplicated transactions are deterministically discarded except for the first occurrence.
- Conflux: Conflux represents block relationships with parent and reference edges in a direct acyclic graph rather than discarding concurrent blocks as chain forks.The protocol uses these relationships to incorporate concurrent contributions and later reconcile their order.
- Experimental Results: Experiments deployed up to 20k full nodes, and results indicate that individual-node processing capability rather than consensus limits Conflux throughput.The evaluation used 800 Amazon EC2 virtual machines and compared Conflux with Bitcoin and GHOST.
- Experimental Results: 5.76GB/h is the reported throughput under a 40Mbps bandwidth limit, equivalent to 6400 transactions per second for typical Bitcoin transactions.Under 20Mbps, Conflux achieves 2.88GB/h; the reported throughput is 11.62x Bitcoin and GHOST and 3.84x Algorand.
- Experimental Results: 4.5-7.4 minutes is Conflux’s confirmation time under the 4MB/2.5s and 40Mbps setting.Under the 4MB/5s and 20Mbps setting, confirmation takes 7.6-13.8 minutes.
2 Overview and Example
Conflux replaces a linear blockchain with a DAG that preserves concurrent blocks, then deterministically orders blocks and derives a transaction ledger. Its pivot chain partitions the DAG into epochs, while reference relationships preserve generated-before information and transaction conflicts are resolved during ordering.
- Architecture: Conflux nodes maintain local DAGs containing all known blocks, enabling eventual agreement on a total order of blocks and transactions.Each node updates its local DAG when it generates or receives a block.
- Transaction Order: Conflux derives transaction order from block order, discarding later conflicting or duplicate transactions while retaining the first occurrence.In the example, Tx3 is discarded because it conflicts with Tx2.
- DAG and Edges: Each non-genesis block has one parent edge representing a voting relationship and may have multiple reference edges representing generated-before relationships.Parent edges form the parental tree; reference edges connect a new block to previously known blocks without incoming edges.
- Pivot Chain: Conflux selects a GHOST-based pivot chain by repeatedly choosing the child with the largest subtree, rather than necessarily selecting the longest chain.In the example, the pivot chain is Genesis, A, C, E, and H, while the longest parental-tree chain is Genesis, B, F, J, I, and K.
- Block Total Order: Each pivot-chain block forms an epoch, and Conflux orders blocks first by epoch, then topologically within each epoch, using unique ids to break ties.The resulting order follows happens-before relationships between epochs and deterministic tie-breaking within an epoch.
- Security Intuition: A newly generated attacker block cannot precede an earlier block merely by choosing an early parent, because it remains in a future epoch until referenced by future pivot-chain blocks.Reverting an enclosed transaction therefore requires reverting the corresponding pivot-chain partition.
3 Conflux Consensus
Conflux formalizes consensus over a local DAG, selects a deterministic pivot chain, and derives a total block order by epoch-wise topological sorting. Its safety and liveness follow from the pivot chain, while confirmation risk is bounded probabilistically and decreases with stability time.
- Consensus Algorithm: A Conflux local state is a graph G = ⟨B,g,P,E⟩ containing blocks, genesis, parent mappings, and directed reference or parent edges.An edge ⟨b,b′⟩ indicates that b′ happens before b, and every block has a parent edge to P(b).
- Consensus Algorithm: Conflux defines deterministic graph utilities for chains, children, siblings, subtrees, generated-before relations, past sets, and total ordering.These functions support pivot selection and ordering blocks across the DAG.
- Consensus Algorithm: New blocks use the last pivot-chain block as parent, reference all local blocks without incoming edges, and are broadcast to other nodes.The implementation broadcasts individual blocks rather than the whole graph to avoid unnecessary network transmissions.
- Consensus Algorithm: ConfluxOrder recursively orders earlier epochs, topologically sorts the current epoch, and uses unique hashes to break ties between unordered blocks.The unique hash function maps distinct blocks to distinct integer identifiers.
- Assumptions: Under the stated adversary model, the attacker has arbitrary disruption strategies but less block-generation power than all honest nodes combined, with λa = q·λh and 0 ≤q < 1.The model also assumes cryptographic functions cannot be reversed.
- Correctness: Conflux inherits GHOST’s pivot-chain safety and liveness properties, and deterministic ordering makes a stabilized pivot-chain prefix irreversible for all nodes.A pivot-chain prefix can be stabilized with arbitrarily low, but nonzero, reversal risk after sufficient waiting.
- Confirmation: The probability that a pivot-chain block is displaced is bounded using subtree sizes, block-generation rates, and the elapsed stability interval.The stated bound provides a way to estimate the stability of each individual pivot-chain block; prefix stability is determined by its least stable block.
4 Implementation
The implementation extends Bitcoin Core to represent and disseminate Conflux’s DAG while preserving block validity and synchronization. It adds reference-edge metadata, DAG-aware validation, timestamp handling, and bootstrapping messages.
- Block and Network Layer: A received block is validated by traversing its DAG past with breadth-first search, and is valid only when all past blocks have been received.This ensures the consensus layer receives blocks whose reachable history is available.
- Stale Blocks: Timestamp invalidation is scaled to the experimental block-generation rate, while Conflux retains invalid-timestamp blocks and ignores them during processing.At one block every 20 seconds, the implementation checks against the median timestamp of the previous 330 blocks.
- Bootstrapping: A bootstrapping node downloads the complete tree or DAG rather than only the selected chain and uses additional messages to synchronize tips and chains.The synchronization process retrieves blocks beginning after the peer’s last known block.
5 Experimental Results
Conflux’s experiments evaluate throughput, confirmation time, attacker-risk trade-offs, and scalability against Bitcoin and GHOST. Conflux processes concurrent blocks without discarding forks, achieving high throughput while maintaining minute-scale confirmation and scaling to 20k full nodes.
- Throughput: 2.88GB/h throughput was achieved under the 4MB/5s block-generation setting, equivalent to 3200 transactions per second for Bitcoin-sized transactions.Throughput was limited by individual-node processing capability rather than the consensus protocol, and could increase with a higher bandwidth limit.
- Throughput: 8% of Bitcoin blocks and 8.6% of GHOST blocks were on the agreed chains under 4MB/5s, while Conflux included all blocks.Forked blocks in Bitcoin and GHOST do not contribute to the resulting total order, whereas Conflux processes concurrent blocks.
- Confirmation Time: 10.0min was Conflux’s average confirmation time under 4MB/5s, and its confirmation time was similar to GHOST across configurations.Conflux confirmation relies on the corresponding pivot-chain blocks following the GHOST rule.
- Risk Tolerance: 16.8 minutes was the median confirmation time at 30% attacker block-generation power with 99.99% confidence.For both Conflux and GHOST, confirmation time grew exponentially as attacker power increased, while confirmation risk dropped exponentially with longer waiting.
- Scalability: 20k full nodes were supported with average confirmation time under 10.7 minutes, while network diameter grew linearly as node count doubled.Under 4MB/10s, throughput remained 720MB/h, and the increase in network diameter was small even with 20k nodes.
6 Related Work
Conflux extends Nakamoto-style consensus with DAG-based ordering while preserving a total transaction order. Compared with related approaches, it distributes ordering across all participants and trades shorter latency for higher throughput.
- DAG-based consensus: Conflux provides a total order over all transactions, unlike SPECTRE’s non-transitive partial orders, supporting applications such as smart contracts.PHANTOM also targets total transaction ordering but is described as vulnerable to liveness attacks.
- DAG-based consensus: 5.76GB of transactions per hour were committed and confirmed within 4.5-7.4 minutes in Conflux’s empirical evaluation with 10k full nodes.The paper identifies this as the first empirical evaluation of DAG-based blockchains and notes that comparable measurements for other DAG protocols are unavailable.
- Nakamoto consensus: Conflux includes blocks outside pivot chains while maintaining a total-ordered, irreversible transaction log, unlike Bitcoin and GHOST.This design produces a performance boost by retaining contributions that chain-based protocols discard.
- Consortium consensus: Conflux decides transaction order through all network participants rather than a confined group, and tolerates half the network being malicious.Its deferred ordering and parallel block generation trade higher throughput for longer latency; the paper reports 3.84x Algorand throughput with shorter Algorand confirmation time.
7 Conclusion
Conflux is presented as a fast, scalable, decentralized blockchain with proved safety. Its DAG-based consensus exploits transaction parallelism and defers total-order reconciliation while providing the interface of chain-based systems.
- 7 Conclusion: Conflux exploits blockchain parallelism through DAG-based consensus and defers total-order reconciliation while retaining the external interface of traditional chain-based systems.The paper presents this design as addressing blockchain performance bottlenecks and supporting a wide range of applications.
- 7 Conclusion: Amazon EC2 deployments validate orders-of-magnitude throughput improvement for Conflux.The conclusion characterizes Conflux as fast, scalable, decentralized, and provably safe.
- 7 Conclusion: Conflux is presented as a promising solution to blockchain performance bottlenecks.The stated scope includes a wide range of blockchain applications.
A.1 Overview
PHANTOM derives a total block order from a local DAG in two phases. It first identifies potentially malicious blocks through 2-coloring, then topologically sorts the blue blocks using a main chain.
- Topological sorting: PHANTOM’s first phase 2-colors DAG blocks blue and red to eliminate potentially malicious blocks.The coloring procedure recursively considers ancestor subgraphs, selects a highest-scoring tip, and classifies anti-chain blocks using k.
- Topological sorting: The score of a block is |BLUEk(past(b))|, and the highest-scoring tip determines the main chain.The chain tip is bmax, with predecessors selected by the highest score within past(bmax).
- Topological sorting: PHANTOM’s second phase topologically sorts all blue blocks based on the main chain.The correctness proof relies on the robustness of that main chain.
A.2 Liveness attack
The PHANTOM liveness attack lets an attacker with limited computation power keep a previously accepted block reversible for arbitrarily long periods. Under the stated network and parameter assumptions, the attack can persist indefinitely with high probability.
- Assumptions: The attack assumes honest-to-honest message propagation is bounded, while attacker-to-honest messages are delivered immediately.The parameter gap k∆ = k − k′ captures the difference between PHANTOM’s parameter k and the honest-network anti-set bound k′.
- Attack construction: The attacker withholds each malicious block until a specified honest block is generated, then releases it together with that honest block and its ancestors.The strategy requires malicious blocks to be mined within prescribed intervals; missing those timing conditions constitutes attack failure.
- Attack construction: The attack uses malicious blocks with large anti-sets and honest blocks with small anti-sets to give malicious blocks an advantage in PHANTOM’s blue-set calculation.The resulting blue sets include all blocks in an attacker block’s past but only honest blocks in an honest block’s past.
- Attack outcome: An attacker can remove block b2 from every honest node’s main chain as long as the liveness attack has not failed.This prevents honest nodes from treating b2 as irreversible because the attacker can reorder the main chain.
- Attack persistence: An attacker with 15% computation power can maintain the attack infinitely with probability 98.9% when k∆ ≥ 40.The result follows from a positive probability of completing all required mining tasks without violating the attack schedule.