This paper is included in the Proceedings of the 2020 USENIX Annual Technical Conference.

July 15–17, 2020978-1-939133-14-4

Open access to the Proceedings of the 2020 USENIX Annual Technical Conference

is sponsored by USENIX.

A Decentralized Blockchain with High Throughput and Fast Confirmation

Chenxing Li, Peilun Li, and Dong Zhou, Tsinghua University; Zhe Yang, Ming Wu, and Guang Yang, Conflux Foundation; Wei Xu, Tsinghua University; Fan Long,

University of Toronto and Conflux Foundation; Andrew Chi-Chih Yao, Tsinghua University

https://www.usenix.org/conference/atc20/presentation/li-chenxing

A Decentralized Blockchain with High Throughput and Fast Confirmation

Chenxing Li∗, Peilun Li∗, Dong Zhou, Zhe Yang†, Ming Wu†,Guang Yang†, Wei Xu, Fan Long‡†, Andrew Chi-Chih Yao

Tsinghua University †Conflux Foundation ‡University of Toronto

AbstractThis paper presents Conflux, a scalable and decentralizedblockchain system with high throughput and fast confir-mation. Conflux operates with a novel consensus pro-tocol which optimistically processes concurrent blockswithout discarding any as forks and adaptively assignsweights to blocks based on their topologies in the Con-flux ledger structure (called Tree-Graph). The adaptiveweight mechanism enables Conflux to detect and thwartliveness attack by automatically switching between anoptimistic strategy for fast confirmation in normal sce-narios and a conservative strategy to ensure consensusprogress during liveness attacks.

We evaluated Conflux on Amazon EC2 clusters withup to 12k full nodes. The consensus protocol of Confluxachieves a block throughput of 9.6Mbps with 20Mbpsnetwork bandwidth limit per node. On a combined work-load of payment transactions and Ethereum history trans-actions, the end-to-end system of Conflux achieves thethroughput of up to 3480 transactions per second whileconfirming transactions under one minute.

1 IntroductionFollowing the success of cryptocurrencies [2, 23],blockchain has evolved into a technology powering se-cure, decentralized, and consistent transaction ledgersat Internet-scale. Newer blockchain platforms such asEthereum [2, 35] support customized transaction rules assmart contracts, which greatly extend the capability ofblockchain ledgers beyond value transfers.

Blockchain platforms like Bitcoin [23] use Nakamotoconsensus. It organizes transactions into an ordered listof blocks, each of which contains multiple transactionsand a link to its predecessor. Participants (miners) solvesproof-of-work (PoW) puzzles to compete for the right ofgenerating the next block. To prevent an attacker fromreverting previous transactions, honest participants agree

∗The first two authors contributed equally.

on the longest chain of blocks as the correct history. Eachnew block is appended at the end of the longest chain tomake the chain longer and therefore harder to revert.

However, the performance remains one of the mostcritical issues of blockchains. Nakamoto consensus isbottlenecked by its slow block generation rate. For exam-ple, Bitcoin generates one 1MB block every 10 minutesand can therefore only process 7 transactions per second.Users have to wait for typically one hour (i.e., six blocks)to obtain high confidence on the finality of a transaction.

An ideal blockchain has the following four desirableproperties, security, decentralization, high throughput,and fast confirmation. The key challenge of buildingsuch a blockchain system is the threat of security attacks.To obtain high performance, the system typically has tooperate with a fast block generation rate. Because blockpropagation takes time, the system may therefore gen-erate many concurrent blocks (i.e., forks). In Nakamotoconsensus, concurrent blocks waste PoW computation be-cause they do not contribute to the finality of the longestchain. They make the system vulnerable to double spend-ing attacks that attempt to revert history transactions.

Moreover, a high block generation rate can make sev-eral recently proposed protocols vulnerable to livenessattacks [17, 31, 32]. An attacker can simultaneously gen-erate blocks at two competing branches and strategicallywithhold/release these blocks to maintain the balance ofthe two branches. The attacker with little PoW computa-tion power can stall the consensus progress [36].Conflux: We present Conflux, the first blockchain systemthat achieves all of the four desirable properties. Confluxcan process thousands of transactions per second whileconfirming each transaction with within one minute onaverage. With its novel consensus protocol, the consensuslayer of Conflux is no longer the performance bottleneck,i.e., the throughput saturates its underlying gossip net-work bandwidth and the confirmation speed is within thesame order of magnitude as the gossip network propa-

USENIX Association 2020 USENIX Annual Technical Conference 515

gation delay. Conflux is provably secure (see our formalproof in [19]). It is also as decentralized and permission-less as Bitcoin — participants can join and leave theconsensus process at any time and there is no privilegedcommittee or super-node dictating the process. Confluxalso implements a modified version of Ethereum Vir-tual Machine (EVM) [35] and most smart contracts inEthereum can be directly ported to Conflux.

To address the security attack challenge, Conflux orga-nizes blocks into a novel Tree-Graph structure, which isa tree embedded inside a direct acyclic graph (DAG). InTree-Graph, concurrent blocks are not considered harm-ful and they contribute to the Conflux ledger as well.Their PoW solutions will improve the finality of all oftheir ancestors and their transactions will be optimisti-cally included into the ledger total order. This securesConflux against double spending attacks and improvesthe Conflux throughput. To address liveness attacks, theconsensus protocol of Conflux inherently encodes twodifferent block generation strategies: an optimistic strat-egy that allows fast confirmation and a conservative strat-egy that ensures the consensus progress. Conflux uses itsnovel adaptive weight mechanism to combine these twostrategies into a unified consensus protocol.Adaptive Weight: Conflux assigns a weight to eachblock, which indicates the amount of finality that theblock contributes to its ancestors. For each new block,Conflux analyzes its topology in the Tree-Graph, decideswhether a liveness attack is potentially going on (e.g.,whether there are old ancestor blocks that are not final-ized yet), and then adaptively assigns weights to blocksin the Tree-Graph to switch between the two strategies.In normal scenarios, the mechanism assigns weights inone way that enables the optimistic strategy to confirmtransactions fast. When a liveness attack happens, themechanism assigns weights in another way that enablesthe conservative strategy to thwart the attack.Deferred Execution: The execution order of recentlypackaged transactions may oscillate temporarily in a sys-tem with fast block generation. A naive implementationof the transaction execution engine would have to rollback executions many times and waste computation re-sources. Conflux addresses this challenge with its de-ferred execution mechanism. Instead of executing trans-actions in every received block immediately, Confluxwaits for several blocks so that the order is relativelystabilized. Our observation is that users need to wait forthe stabilization of the total order anyway to confirm atransaction with high confidence. Therefore the deferredexecution does not harm the user experience at all.

Link-Cut Tree: An efficient consensus implementationis important to the performance of Conflux. To maintainthe Conflux Tree-Graph, a naive implementation has thetime cost of O(n) for processing a new block on average,where n is the number of existing blocks. To address thischallenge, Conflux uses link-cut tree to maintain weightvalues in Tree-Graph efficiently. It reduces the processingtime from O(n) to O(logn) per block.Experimental Results: We implemented Conflux andevaluated it with Amazon EC2 machines under the sameexperimental setup as previous work like Algorand andOHIE [11, 36]. Our experimental results show that withthe bandwidth limit of 20Mbps and the simulated realworld network latency setting, Conflux achieves a trans-action throughput of 9.6Mbps and a confirmation latencyof 47.75-51.54 seconds when running 3000-12000 nodes.For a combined workload of payment transactions andEthereum history transactions, Conflux achieves up to3480 transactions per second and confirms transactionswithin one minute with high confidence. Comparing toAlgorand [11], Conflux has more than 4x higher through-put and comparable confirmation speed. Comparing toOHIE [36], Conflux has the same throughput and oneorder of magnitude faster confirmation speed.Contribution: This paper makes the following contribu-tions: 1) we design and implement Conflux, a decentral-ized and smart-contract-enabled blockchain system withhigh throughput and fast confirmation; 2) we present anovel consensus protocol with the adaptive weight mech-anism; 3) we present a set of novel and critical optimiza-tions, including deferred execution and link-cut tree.

2 Related WorkNakamoto Consensus in Bitcoin: Transactions arepacked into blocks in Bitcoin. Each block has one pre-decessor block and all blocks form a tree structure withthe genesis block as the root. Participants agree on thelongest chain as the valid transaction history. Nakamotoconsensus has to use a relatively slow block genera-tion rate to avoid the generation of concurrent blocks,i.e., forks. This is essential for the safety against dou-ble spending attacks as shown in Figure 1a. More forkswould mean relatively less blocks in the longest chain.In Figure 1a, due to forks, only 20% of blocks are on thelongest chain so that an attacker with more than 20% ofthe network computation power can revert the longestchain to launch double spending attacks.GHOST: GHOST is a previous proposal to replace thelongest chain rule to improve the consensus safety undera fast block generation rate [32]. It is partially imple-mented in Ethereum [2]. Figure 1b presents an exam-

516 2020 USENIX Annual Technical Conference USENIX Association

G

… …

…

Forks

…

…

Forks The original longest chain (20% of blocks)

(a) An attacker with more than 20% of the network compu-tation power can revert the longest chain.

Genesis

Y Y Y Y

X X X New Block

X X

X

Y

(b) GHOST algorithm iteratively advances to the largestsubtree to select the agreed chain.

GY … Y Y

Y’ …

X … X

X’ …

…

…

Y’

New Block from X groupX

X’

…

… New Block from Y group

Malicious BlocksIn-Transit Blocks

Public Blocks

Expected blocks in total. These blocks are only visible to their own group.

� · d<latexit sha1_base64="YPQ6RFPy//dSHO7eZ2QRP1Ii8wM=">AAAB+HicbVDLSgMxFM34rPXRUZdugkVwVWaqoMuiG5cV7AM6Q8lkMm1oJhmSO0It/RI3LhRx66e4829M21lo64HA4ZxzuTcnygQ34Hnfztr6xubWdmmnvLu3f1BxD4/aRuWashZVQuluRAwTXLIWcBCsm2lG0kiwTjS6nfmdR6YNV/IBxhkLUzKQPOGUgJX6biUQNhwTHNBYAY77btWreXPgVeIXpIoKNPvuVxArmqdMAhXEmJ7vZRBOiAZOBZuWg9ywjNARGbCepZKkzIST+eFTfGaVGCdK2ycBz9XfExOSGjNOI5tMCQzNsjcT//N6OSTX4YTLLAcm6WJRkgsMCs9awDHXjIIYW0Ko5vZWTIdEEwq2q7ItwV/+8ipp12v+Ra1+f1lt3BR1lNAJOkXnyEdXqIHuUBO1EEU5ekav6M15cl6cd+djEV1ziplj9AfO5w8GRpKs</latexit>

New Blocks

(c) The attacker can strategically withhold or release his/herblocks to maintain the balance of two subtrees.

GY … Y Y

Y’ …

X … X

X’ …

…

…

Y’

New Block from Y group

X

X’

…

…

New Block from X group

Weighted Block (only 1/h blocks)Zero Weight Block

(d) If h is large enough, two groups will converge eventually.Figure 1: Double Spending Attack, GHOST, Liveness Attack,and Structured GHOST

ple to illustrate the GHOST algorithm. GHOST startsfrom the genesis block and iteratively advances to thechild block with the largest subtree to select the agreedchain [32]. In Figure 1b, the new block appends to theend of the agreed chain, which is in the subtree of X(containing 6 blocks) not in the subtree Y (containing 5blocks). The difference between GHOST and the longestchain rule is that all blocks generated by honest partici-pants will contribute to the finality of the agreed chain.Suppose G is an old enough block that is on the agreedchains of all honest participants. Future blocks generatedby honest participants will all contribute the finality of Gregardless of whether they are concurrent or not, becauseall of these blocks will be under the subtree of G. Unlikethe longest chain rule, an attacker would need more thanhalf of computation power to revert G from the agreedchain even with the presence of concurrent blocks [32].

Liveness Attack on GHOST: Unfortunately, GHOST isvulnerable to liveness attacks if the block generation rateis very fast. Figure 1c presents one example of such at-tacks. The example has the following settings: 1) the totalblock generation rate of honest participants is λ; 2) hon-est participants are devided into two groups with equalcomputation power (group X and group Y in Figure 1c);3) blocks will transmit instantly inside each group, butthe propagation between these two groups has a delayof d. In Figure 1c, each of the two groups extends itsown subtree following the GHOST rule. Note that re-cent generated blocks within the time period of d arein-transit blocks (gray blocks in Figure 1c), which areonly visible by the group who generates them. Thereforeeach group will believe its own subtree is larger until onegroup generates sufficiently more blocks than the otherto overcome the margin caused by the in-transit blocks.

In normal scenarios, one of the two groups will getlucky to enable the blockchain to converge. However,an attacker can mine under two subtrees simultaneouslyto delay the convergence. The attacker can strategicallywithhold or release the mined blocks to maintain thebalance of the two subtrees as shown in Figure 1c.

Theoretically, if honest participants evenly split due tonetwork delay and the margin caused by in-transit blocksis significant, i.e., λd > 1, a small portion of computationpower is enough to launch attacks. Previous work [36] in-cludes a simulation shows only 10% will do. In practice,even if honest participants do not have an even parti-tion, the more computation power the attacker controls,the more likely the attacker will succeed. Consider thepresence of mining pools, it is not rare to see one minercontrolling more than 20% of computation power. Sucha miner will be able to launch successful balance attackswithout even partition.DAG-based Structures: To improve the throughput andthe confirmation speed, researchers have explored sev-eral alternative structures to organize blocks. Inclusiveblockchain [17] extends the Nakamoto consensus andGHOST to DAG and specifies a framework to includeoff-chain transactions. In PHANTOM [31], participatingnodes first find an approximate k-cluster solution for itslocal block DAG to prune potentially malicious blocks.They then obtain a total order via a topological sort of theremaining blocks. Unfortunately, when the block genera-tion rate is high, inclusive blockchain and PHANTOMare all vulnerable to liveness attacks similar to Figure 1c.Therefore, unlike Conflux they cannot achieve both thesecurity and the high performance.

Some protocols attempt to obtain partial orders insteadof total orders for payment transactions. SPECTRE [30]

USENIX Association 2020 USENIX Annual Technical Conference 517

produces a non-transitive partial order for all pairs ofblocks in the DAG. Avalanche [4] connects raw transac-tions into a DAG and uses an iterative random samplingalgorithm to determine the acceptance of each transac-tion. Unlike Conflux, it is very difficult to support smartcontracts on these protocols without total orders.Hierarchical and Parallel Chains: Besides DAG, al-ternative ways to organize blocks include hierarchi-cal chains and parallel chains. For example, in Bit-coinNG [9], a macro block is generated every 10 minutes.The miner of such a block becomes the leader to gen-erate micro blocks that contain actual transactions untilthe next macro block. Similarly, FruitChain [27] packstransactions first into fruits (i.e., micro blocks) and thenpacks fruits into blocks. OHIE [36] runs multiple parallelchains with the standard Nakamoto consensus and thendeterministically sorts blocks to obtain a total order.

The shared property of these protocols is that only asmall portion of blocks (e.g., macro blocks in BitcoinNGand FruitChain) influence the total order of the transac-tion ledger. It mitigates the liveness attack issue in Fig-ure 1c because it reduces the chance of in-transit blocksinfluencing the total order. But these protocols have slowconfirmation speed because they need to wait for moreblocks to confirm transactions than other protocols. Forexample, BitcionNG has the same slow confirmationspeed as Bitcoin [9]; OHIE confirms transactions in about10 minutes on average only under an extremely fast blockgeneration rate of 64 blocks per second [36]. In contrast,Conflux has a much faster confirmation speed in normalcircumstances with no ongoing liveness attack.

Prism operates with one proposer chain and many par-allel vote chains, each of which casts vote to decide thetotal order of blocks in the proposer chain [6]. The theo-retical simulation in [6] shows that Prism may achievehigh throughput and fast confirmation speed similar toour Conflux results in Section 6. But the simulation as-sumes a block propagation delay of one second, whichis too ideal (e.g., the measured block delay is 10-15 sec-onds in our experiments). It is therefore unclear how fasta blockchain system that implements Prism can confirmtransactions when running under practical P2P networks.Byzantine Fault Tolerance: ByzCoin [14] and Thun-derella [28] propose to achieve consensus by combiningthe Nakamoto consensus with Byzantine fault tolerance(BFT) protocols. Algorand [11], HoneyBadger [22], andStellar [21] replace the Nakamoto consensus entirelywith BFT protocols. In practice, all these proposals runBFT protocols within a confined group of nodes, sinceBFT protocols only scale up to dozens of nodes. Theconfined group is often chosen based on their recent

PoW computation power [14, 28], their stakes of the sys-tem [11], or external hierarchy of trusts [21, 22]. How-ever, these approaches may create undesirable hierarchiesamong participants and compromise the decentralizationof blockchain systems. In contrast, Conflux allows anyparticipant to join and leave the network without permis-sion. In addition, instead of eagerly deciding the total or-der of blocks as in BFT-based approaches, Conflux allowsmultiple blocks to be generated in parallel and finalizestheir orders later, which leads to its higher throughput.Sharding: Elastico [20], OmniLedger [15], Rapid-Chain [37], and Monoxide [33] split the blockchain stateinto shards. Instead of having every node to verify alltransactions, the systems select a small committee tomaintain each shard to improve scalability. Unlike Con-flux, such systems sacrifice security for scalability, i.e.,the committee configuration can only be changed slowly(like days) due to reconfiguration overhead and thereforea small shard may be vulnerable to powerful attackerswho can adaptively corrupt participants. This securityissue is so important that Vault [16] chooses to only usesharding to mitigate storage cost with the trade-off ofincreased network bandwidth cost. Also despite the highcombined throughput of all shards, the throughput ofinter-shard transactions is still limited.

3 OverviewWe will first present an example to illustrate a straw-man algorithm called structured GHOST that can de-fend against liveness attacks but has a sub-optimal con-firmation speed. We will then present an overview of theConflux consensus protocol, which uses the straw-manalgorithm as a building block.Structured GHOST: In our structured GHOST algo-rithm, only 1/h of blocks are weighted blocks that wouldcount in the chain selection process. These blocks areselected randomly based on their PoW solution quali-ties (e.g., the number of leading zeros of the PoW hash).During the chain selection, the structured GHOST itera-tively advances to the subtree with the largest number ofweighted blocks, instead of considering all blocks.

Figure 1d shows an example to illustrate how struc-tured GHOST can defend against the liveness attack wedescribed before. With a sufficiently large h value, theexpected number of in-transit weighted blocks (λd/h)will be very small. As shown in Figure 1d, the genera-tion of a weighted block of one group will very likely tomake the two subtrees to converge, unless another groupgenerates a concurrent weighted block. When λd/h� 1,the chance of such concurrent generation is very unlikely.Without the margin caused by the in-transit blocks, the

518 2020 USENIX Annual Technical Conference USENIX Association

Genesis

F J I

C E

D

H

K

…

…

…

Adaptive Weight Triggered

Liveness Attack Launched

Adaptive Weight End

N

Tx0 BTx2Tx3

ATx1

Tx0: Mint 10 coins to XTx1: X sends 8 to YTx2: X sends 8 to ZTx3: X deploys Foo

GTx3

(a) Tree-Graph Example. Solid blocks have weight one. Double-line blocks have weight600. Dotted-line blocks have weight zero.

f( ) =Weight of the new block

Is the past sub-graph safe from liveness

attacks?

Assign 1Assign h with 1/h chance. Otherwise 0.

Yes

No

(b) Adaptive Weight

Figure 2: Examples of Conflux Consensus on Tree-Graph

liveness attack is not possible without significant com-putation power. Although structured GHOST is secureagainst liveness attacks, it sacrifices the confirmationspeed — a user has to wait for the accumulation ofenough weighted blocks to confirm a transaction.Consensus with Two Strategies: The Conflux consen-sus protocol operates with two strategies, an optimisticstrategy similar to the GHOST algorithm and a conser-vative strategy similar to the above straw-man algori-htm. Our adaptive weight mechanism enables Confluxto encode these two strategies in a unified framework.In normal scenarios, Conflux would use the optimisticstrategy to achieve high performance. If a liveness attackhappens, the adaptive weight mechanism enables honestparticipants of Conflux to cooperatively switch to theconservative strategy to thwart the attack automatically.Tree-Graph: The Conflux consensus protocol operateson the local Tree-Graph state of each individual node.Figure 2a presents a running example of the local Tree-Graph state of a node in Conflux. We will use this ex-ample in the remaining of this section to illustrate thehigh-level ideas of the Conflux consensus protocol. Eachvertex in the Tree-Graph in Figure 2a corresponds to ablock. In Figure 2a, Genesis is the predefined genesisblock. Only Genesis, A, B, and G are associated withtransactions. There are two kinds of edges in the Tree-Graph, parent edges and reference edges:Parent and Reference Edges: Each block except Gen-esis has exactly one outgoing parent edge (solid linearrows in Figure 2a). For example, there is a parent edgefrom C to A. Each block can have multiple outgoing refer-ence edges (dashed line arrows in Figure 2a). A referenceedge corresponds to generated-before relationships be-tween blocks. For example, there is an edge from E to D.It indicates that D is generated before E.Pivot Chain: Note that all parent edges in the Tree-Graph together form a parental tree in which the genesisblock is the root. In the tree, Conflux selects a chain fromthe genesis block to one of the leaf blocks as the pivotchain. Each block in the Tree-Graph may have a different

weight determined by our novel adaptive weight mech-anism. Conflux iteratively advances to the subtree withthe heaviest total block weight to select the pivot chain.In Figure 2a before the liveness attack, Conflux selectsGenesis, A, C, E, and H as the pivot chain to append thenew block N. Note that Conflux does not selects the chainof Genesis, B, F, J, I, and K, because the subtree of A hasheavier weights than the subtree of B.Generating New Block: Whenever a node generates anew block, it first computes the pivot chain in its localTree-Graph state and sets the last block in the chain asthe parent of the new block. The node then finds all tipblocks in the Tree-Graph that have no incoming edgeand creates reference edges from the new block to eachof those tip blocks. For example, in Figure 2a, whengenerating N, the node chooses H as the parent of N andcreates a reference edge from N to K.Adaptive Weight: Figure 2b illustrates the basic idea ofthe adaptive weight mechanism. The goal is to assign adifferent weight to each generated block so that Confluxcan adaptively switch between the optimistic strategywith a fast confirmation and the conservative strategythat ensures the consensus progress. Conflux determinesthe weight of a new block based on its past sub-graph,i.e., all blocks that are reachable via a traversal from thenew block. As shown in Figure 2b, if the past sub-graphis safe — every old enough ancestor of the new blockin the past sub-graph is secured on the pivot chain withhigh probability, the weight of the new block will be one.If not, the new block will be assigned an adaptive weight— it gets a weight of h with the chance of 1/h (dependingon the PoW quality) or zero otherwise. Note that we seth = 600 in Conflux. See Section 4.1.Liveness Attack Resilience: Figure 2a shows how theadaptive weight mechanism stops liveness attacks. Sup-pose after the generation of N, an attacker launches aliveness attack similar to one described in Figure 1cto balance the subtree of A and B. After a while, allhonest participants start to generate blocks with adap-tive weights, because they find that the old ancestors of

USENIX Association 2020 USENIX Annual Technical Conference 519

their new generated blocks (e.g., A or B in Figure 2a) arestill not secured on the pivot chain with high probabil-ity. This essentially enables the consensus protocol tooperate in the conservative strategy similar to the struc-tured GHOST algorithm. In Figure 2a, the heavy weightblocks make Conflux to converge to the the subtree ofA. After more blocks being generated under A, the pastsub-graph of new generated blocks will become safe. Par-ticipants therefore assign weight one to the new blocks,automatically swtiching back to the optimistic strategy.Epoch and Block Order: Parent edges, reference edges,and the pivot chain together enable Conflux to split allblocks in a Tree-Graph into epochs. Every block on thepivot chain corresponds to one epoch. Each epoch con-tains all blocks 1) that are reachable from the correspond-ing block in the pivot chain via the combination of parentand reference edges (including the pivot chain block it-self) and 2) that are not included in previous epochs. Forexample, in Figure 2a, J belongs to the epoch of H be-cause J is reachable from H but not reachable from theprevious pivot chain blocks.

Conflux then derives a total order of all blocks in theTree-Graph with the following rules. Conflux first sortsblocks based on their epochs. For blocks within the sameepoch, Conflux sorts them based on their topologicalorder. Conflux break ties determinisitcally (e.g., withthe PoW quality or the block hash). For example, in Fig-ure 2a, Conflux will obtain the following block total orderfor all blocks before the liveness attack: Genesis, A, B,C, D, F, E, G, J, I, H, K, and N.Transaction Order: Conflux first sorts transactionsbased on the total orders of their enclosing blocks. Iftwo transactions belong to the same block, Conflux sortsthe two transactions based on the appearance order inthe block. Conflux checks the conflicts of the transac-tions at the same time when deriving the order. If twotransactions are conflicting with each other, Conflux willdiscard the second one. If one transaction appears in mul-tiple blocks, Conflux will only keep the first appearanceand discard all redundant ones. In Figure 2a, the transac-tion total order is Tx0, Tx1, Tx2, Tx3, and Tx3. Confluxdiscards Tx2 because it conflicts with Tx1.

4 Consensus on Tree-GraphThe local state of a node in Conflux is S = 〈B,g〉, where Bis the set of blocks and g ∈ B is the genesis block. Thereare several fields associated with a block b ∈ B. b.parentdenotes the parent block of b. b.pred_blocks denotes theset of predecessor blocks linked by the reference andparent edges from b. b.pow_quality is the quality of thePoW solution — for b to be valid, b.pow_quality must no

Child(B,b) = {b′ | b′ ∈ B, b′.parent= b}SubT(B,b) = (∪i∈Child(B,b)SubT(B, i))∪{b}SubTW(B,b) = ∑i∈SubT(B,b) i.weightPast(b) = (∪i∈b.pred_blocksPast(i))∪b.pred_blocksPastW(b) = ∑i∈Past(b) i.weight

Figure 3: The definitions of utility functions.Input :A set of blocks B and a starting block b.Output :The pivot block for the subtree of b.

1 if Child(B,b) = /0 then2 return b

3 else4 w←max{SubTW(B, i) | i ∈ Child(B,b)}5 a← argmin

i∈Child(B,b){i.hash | SubTW(B, i) = w}

6 return Pivot(B,a)Figure 4: The definition of Pivot(B,b).

less than the PoW difficulty D. b.weight is the adaptiveweight of b. We use b.hash to denote the hash of b – allnodes in Conflux share a predefined deterministic hashfunction that maps each block to a unique id.

Figure 3 defines several utility functions and notations.Child() returns the set of child blocks of a given block.SubT() returns the set of blocks in the subtree of a givenblock in the parental tree. SubTW() returns the sum ofthe weights in the subtree. Past() returns the set of blocksthat are generated before a given block. PastW() returnsthe sum of the weights of the past block set of a block.Note that Past(b) and PastW(b) are determined at thegeneration time of b and remain constant afterwards. Inthis section, we use lists to denote chains and serializedorders. “◦” denotes the concatenation of two lists.

4.1 Pivot Chain and Adaptive WeightPivot Chain: Figure 4 presents the pivot chain selectionalgorithm in Conflux. Given a set of blocks B and thestarting genesis block g, Pivot(B,g) returns the leaf blockof the selected pivot chain. The algorithm recursivelyadvances to the child block whose corresponding subtreehas the largest total weights (lines 4-6). To break ties,the algorithm selects the child block with the smallestunique hash id (line 5). The algorithm terminates until itreaches a leaf block (lines 1-2).Adaptive Weight: Figure 5 presents how we calculatethe weight of a block b. The algorithm first determineswhether the block should have adaptive weight or notbased on the past block set of b (lines 1-11). If not, theweight of the block will be one (lines 12-13). If so, thealgorithm checks the PoW solution quality against a dif-ficulty that is h times higher than the base validationdifficulty. The weight of the block will be h if it passesthe check and be zero if it fails (lines 14-17).

To determine whether b should have adaptive weight,the algorithm operates at a sub-Tree-Graph that only con-tains blocks in the past set of b. It inspects every block in

520 2020 USENIX Annual Technical Conference USENIX Association

Input :A new block bOutput :The adaptive weight of b

1 B← Past(b)2 a← b.parent3 adaptive← False4 Let f (x) =

2 ·SubTW(B,x)−SubTW(B,x.parent)+x.parent.weight5 Let t(x) = |TimerChain(b)|− |TimerChain(x.parent)|6 Let g(x) = |SubT(B,x.parent)|7 while a.parent 6=Nil do8 if f (a)< α and (t(a)> β or g(a)> γ) then9 adaptive← True

10 break

11 a← a.parent

12 if not adaptive then13 return 1

14 else if b.pow_quality ≥ h ·D then15 return h

16 else17 return 0

Figure 5: The definition of AdaptiveWeight(b)

Input :A block b.Output :The timer chain of the past sub-graph of b.

1 if b.pred_blocks= /0 then2 return b

3 else4 a← argmax

i∈b.pred_blocks{|TimerChain(i)|}

5 if b.pow_quality > h0 ·D then6 return TimerChain(a)◦b

7 else8 return TimerChain(a)

Figure 6: The definition of TimerChain(b).

the path from the genesis to b.parent. For each inspectedblock a, it determines 1) whether a is still not secure onthe pivot chain with high probability – the subtree weightof a is not significantly larger than the weight of the sib-ling subtrees of a (i.e., f (a)< α) and 2) whether a is oldenough – there is an enough amount of timer ticks or anenough number of blocks in the subtree of its parent (i.e.,t(a) > β or g(a) > γ). If any inspected block satisfiesthese two conditions, b should have adaptive weight.

The intuition is that to make progress, for any pivotchain block a′ in Tree-Graph, after a certain period oftime, one of the child subtree of a′ (e.g., the subtree of a)should become dominant. If the attacker attempts to main-tain the balance between the subtrees of two (or more)children of a′ for a long time, the condition at line 8 willbecome true for a. Therefore, all honest participants willstart to generate blocks with adaptive weights. Confluxwill essentially operate with a conservative strategy simi-lar to the structured GHOST algorithm (see Section 3).This will thwart the attack to ensure the progress.Timer Chain: Because an attacker with enough compu-tation power may influence the subtree sizes of recent

Input :The local state S = 〈B,g〉 and a new discoveredblock b

1 if b.pow_quality ≥ D then2 Wait until Past(b)⊆ B3 if Pivot(Past(b),g) = b.parent then4 b.weight← AdaptiveWeight(b)5 S← 〈B∪{b},g〉

Figure 7: The block validation procedure.Input :A block bOutput :An ordered list of all blocks in Past(b)∪{b}

1 if b.parent= Nil then2 return /0

3 L← ConfluxOrder(b.parent)4 B∆← (Past(b)−Past(b.parent)−{b.parent})∪{b}5 while B∆ 6= /0 do6 B′

∆←{x | |x.pred_blocks∩B∆|= 0}

7 Sort all blocks in B′∆

in order as a1,a2, . . . ,ak8 such that ∀1≤ i < j ≤ k, ai.hash< a j.hash9 L← L◦a1 ◦a2 ◦ . . .◦ak

10 B∆← B∆−B′∆

11 return L

Figure 8: The definition of ConfluxOrder().pivot chain blocks via strategically withholding minedblocks, only counting the number of blocks under thesubtree of a pivot block is not sufficient to detect whetherthe pivot block is old enough or not. To this end, Con-flux uses a timer chain mechanism to obtain an attackerresilient estimation for the generation time of each block.

Figure 6 presents the definition of TimerChain(b),which is the longest chain of blocks in the past sub-graphof b whose PoW qualities are h0 times higher than the nor-mal difficulty. We then use the length of the timer chainas the timer tick of the generation time estimation of eachblock (i.e., line 5 in Figure 5). When h0 is large enoughrespecting the network delay, the attacker cannot stop thegrowth of the timer chain, because honest participantswill contribute to the timer chain almost synchronously.In Conflux we set h0 = 360. See Section 6.1.

4.2 Block Validation and Total OrderBlock Validation: Figure 7 presents the validation pro-cedure for a new discovered block. It first checks whetherthe block has a PoW solution with a sufficient quality(line 1). The procedure will wait for all blocks in its pastsub-graph being processed first (line 2). The procedurewill then compute the pivot chain in its past sub-Tree-Graph to check whether it selects the right parent (line3). If so, the procedure computes the weight of the newblock and adds it to the local Tree-Graph state (lines 4-5).Block Order: Figure 8 defines ConfluxOrder(),our block ordering algorithm. Given a block b,ConfluxOrder(b) returns the total order of all blocks inPast(b)∪{b}. The algorithm sorts the blocks based ontheir corresponding epochs, i.e., it first recursively ordersall blocks in previous epochs. It then computes all blocks

USENIX Association 2020 USENIX Annual Technical Conference 521

in the epoch of b as B∆ (line 4). It topologically sorts allblocks in B∆ and appends them to the result list (lines5-10), and uses the hashes to break ties (lines 7-8).

4.3 CorrectnessWe next discuss the intuitions behind the correctness ofour consensus algorithm. Suppose the network togetherhas a block generation rate of λ. The correctness of Con-flux is based on the following assumptions: 1) attackerscontrol at most δ of the total block generation power(δ < 0.5); 2) the network is d-synchronous, i.e., if at timet one honest node broadcast a block via the gossip net-work, then before time t+d, all honest nodes will receivethis block and add this block into their local states.Adversary Model: The attacker can choose arbitrarystrategies to disrupt honest nodes. We also assume 1)attackers immediately receive all blocks and transactionsfrom the gossip network, 2) attackers can arbitrarily con-trol the communication of honest nodes as long as thed-synchronous assumption holds. The attacker howeverdoes not have the capability to reverse cryptographicfunctions. Therefore honest nodes can reliably verify theintegrity of a block in the presence of the attacker.Safety: Conflux is safe against double spending attacksbecause of two facts: 1) to revert a transaction in anepoch, the attacker has to revert the pivot chain blockassociated with the epoch from the pivot chain; 2) revert-ing an old pivot chain block that is on the common pivotchain of all honest nodes requires the attacker to competewith all honest nodes together. Although honest nodesmay generate blocks that are concurrent with each other,all of these blocks will be under the subtree of the com-mon pivot chain block. As the time passes by, it will beimpossible for the attacker to forge an alternative heaviersubtree without the pivot chain block.Liveness: Many previous consensus algorithms basedon tree and DAG can only provide liveness guaranteesif the block generation rate is significantly slower thanthe block propagation delay (i.e., λ ·d� 1) [13, 26]. Incontrast, Conflux is safe against liveness attacks at theprotocol level even when the block generation rate is fast,because if the consensus does not make progress for acertain period of time, all honest nodes will start to gen-erate blocks with adaptive weights. In this scenario, onlyblocks with very high PoW quality will decide the totalorder and the block generation rate of these blocks is sig-nificantly slower than the block propagation delay (i.e.,λ·dh � 1 for a large enough h). Because concurrent gener-

ation of such heavy weight blocks is rare, an attacker hasto release a large number of previously withheld blocks tobalance a new generated heavy block or all honest nodes

will make progress and will recognize the heavy block asa common pivot chain block. Because block withholdingcapability of an attacker is limited by its block generationpower, the attacker will eventually run out of blocks tocontinue the liveness attack. We prove in [19] that whenδ < 1/2, once a block in Conflux is seen by an honestnode, its order will become irreversible with exceptionrisk ε after d ·O(log(1/ε)) time.Confirmation Policy: Conflux confirms a block b if forany ancestor block of b, the corresponding subtree totalweight is heavier than all of the subtrees of its siblings bya margin. This margin is not a preset value. It depends onthe status of blockchain protocol. With the parameter set-ting used in our experiments, this margin is about 20∼30in normal scenarios for obtaining the same confidenceas waiting six blocks in Bitcoin. Specially, if Conflux isin the conservative mode and is generating blocks withadaptive weights, we need to wait six blocks with heavyweights instead. See [19] for the detailed formulas of therisk in confirming a block.

5 Implementation and OptimizationsWe have implemented Conflux in Rust [1].Difficulty Adjustment: For brevity, our algorithm inSection 4 assumes a constant PoW difficulty. Confluxoperates with a difficulty adjustment mechanism tailoredfor Tree-Graph. Every 5000 epochs, Conflux counts thenumber of blocks generated in the last 5000 epochs andadjusts the difficulty accordingly to maintain a stableblock generation interval. Instead of setting the weight ofevery normal block to one, Conflux sets the weight to thedifficulty of the block. For a block with a heavy adaptiveweight, its weight will be its difficulty multiplied by h.The rationale is to allow the block weight to align withthe accumulated PoW as the difficulty changes.Storage: A Conflux full node stores the blockchain ac-count state as Merkle Patricia Trees [35] in a key-valueDB. To save storage space, Conflux periodically formscheckpoints at specific epoch heights (e.g., every 200kepoch heights) when the confirmation risk of the pivotchain blocks at these heights become extremely low. Af-ter a checkpoint, all history transactions before it can besafely discarded — all full nodes treat the checkpointblock as the new genesis. Note that full nodes still storeall block headers to help new nodes bootstrapping.Bootstrap: To bootstrap a new full node to join the net-work, it first synchronizes all the block headers in theledger from the peers and decides the latest confirmedcheckpoint block based on the headers. It then fetchesthe corresponding checkpoint state from the peers andcontinues the execution from that state.

522 2020 USENIX Annual Technical Conference USENIX Association

Pivot Parent Edge

Non-Pivot Parent EdgeReference Edge

Block1

Deferred State Root Edge

DeferRoot

TX1

Executed

1

2

3

Block2

DeferRoot

TX2

Block1

DeferRoot

TX1

Block2

DeferRoot

TX2

Block3

DeferRoot

TX3

Block4

DeferRoot

TX4

Block1

DeferRoot

TX1

Block2

DeferRoot

TX2

Block3

DeferRoot

TX3

Block4

DeferRoot

TX4

Block5

DeferRoot

TX5

Figure 9: Save Redundant Execution by Deferred Execution

Transaction Relay: For a high performance blockchainlike Conflux, it is critical to minimize the redundant trans-actions that are transferred. Ideally and optimally, eachnode should only receive each transaction exactly once.In current Bitcoin and Ethereum implementation, transac-tions are disseminated among nodes via flooding, whichmay waste network bandwidth resources. Erlay [24] triesto solve this issue of Bitcoin by letting peers exchangesets of unsent transactions that are encoded with PinS-ketch algorithm [8]. However, this method cannot beapplied in Conflux, since it only works well when thedifference between the transaction sets of two peers issmall. Conflux is not this case because the transactionthroughput of Conflux is orders of magnitude higher thanBitcoin. Conflux instead only floods 4-byte short trans-action ids and pulls the missed transactions from peers.The short id is built by a SipHash [12] on the SHA-3hash of the transaction and a peer-specific random nonceto significantly decrease the id conflict rate.Signature Verification: Signature verification iscomputation-intensive and may become a bottleneckwhen the throughput is high. Conflux therefore uses athread-pool to parallel the signature verification for differ-ent transactions to avoid bottlenecking other components.Incentive Mechanism: For every mined block, Confluxassigns its block generation reward based on how manyother blocks that are generated in parallel in Tree-Graph,i.e., blocks that are not in the past and future sets of themined block. The more blocks are in parallel with themined block, the smaller the block reward would be. Thisincentive mechanism penalizes malicious behaviors suchas withholding mined blocks and not referencing otherblocks. Because every block receives reward regardlessof whether they are on the pivot chain or not, this mecha-nism nullifies selfish mining attack strategies [10, 25, 29].See [7] for the details of the incentive mechanism.

5.1 Deferred ExecutionIn Conflux, when a block just enters the Tree-Graph struc-ture, its position in the total order will change frequently.Although such oscillation will stop in a short time, itposes a challenge for the transaction execution engine.In typical blockchain systems, all transactions in a blockimmediately get executed in a node as soon as it is dis-covered. Such naive approach may execute transactionsin a block many times as the order of the block oscillates.This incurs significant execution overhead. The top partof Figure 9 illustrates this problem. When a full node justgets the Block2, it is on the pivot chain and the total or-der of transactions is {T X1,T X2}. T X2 is then executedin this order. But, when the node later gets Block3 andBlock4, Block2 does not belong to pivot chain anymoreand T X3 is positioned between T X1 and T X2 in the newlydecided total order. T X2 has to be executed again.

Conflux uses a novel deferred execution mechanism toaddress this issue. The insight is that, just like users wait-ing for a period of time to confirm transactions, Confluxcan wait for the total order position of a block to almoststabilize to execute its transactions. Conflux delays theexecution by k-epochs. Specifically, unlike Ethereumwhere the header of each block b contains a merkle stateroot that corresponds to the execution results after pro-cessing all transactions in and before b, the header of b inConflux contains a deferred root that corresponds to theexecution results of the block that are k-hops older thanb along its path to the root. We set k to five in Confluxso that Conflux can avoid re-execution of transactions inmost cases. Five is also smaller than the typical numberof epochs that an user needs to wait to confirm transac-tions and therefore it does not impact the user experience.

Figure 9 presents an example to illustrate the savingof redundant executions by using deferred execution. Forillustration purpose, we set k to be one in this example.Therefore in Figure 9, the Block2 stores the state rootbased on the execution of T X1. When the full node getsBlock3 and Block4, in order to verify the deferred stateroot of Block4, the system needs to execute T X3 but doesnot need to execute T X2 because T X2 is positioned afterT X3 in the decided total order. When getting and veri-fying Block5, Conflux then needs to produce the statebased on the execution of T X4 which depends on T X2. Inthe process, although the pivot chain oscillates betweenBlock2 and Block3, T X2 only gets executed once.

5.2 Link-cut Tree OptimizationsMaintaining pivot chain in Conflux is not trivial. Addinga new block to the Tree-Graph requires updating thesubtree weights of all the blocks from this new block back

USENIX Association 2020 USENIX Annual Technical Conference 523

to the genesis. The naive approach will takes O(n) timeto complete, because the Tree-Graph height is usuallylinear to the number of blocks. To efficiently update thesubtree weights, Conflux uses a data structure called link-cut tree [3]. Link-cut tree splits a tree structure into oneor more paths, and represents each path using a splaytree, a form of balanced binary search tree invented byTarjan et al. [5]. The link-cut tree is ideal for maintainingvalues like the subtree weights in the Conflux consensusprotocol, because it enables the following operations atan amortized cost of O(logn): 1) increase or decreasevalues of all nodes along a path in the tree by a givenvalue; 2) find the minimum or maximum value amongvalues of all nodes along a path; 3) find the least commonancestor (LCA) of two nodes in the tree.Update Pivot Chain: Conflux tracks the last pivot chainblock of the current Tree-Graph state. Conflux uses thelink-cut tree to maintain the total subtree weights of eachblock. When Conflux discovers a new block b, it insertsb into the link-cut tree and increases the total subtreeweights of all blocks along the path from b to the root(i.e., genesis) by b.weight. Note that adding b may trig-ger a pivot chain change — instead of running the chainselection algorithm from the root, Conflux uses the link-cut tree to calculate the LCA of b and the current lastpivot block p. If the weight of the subtree p belongs tois still heavier than the one b belongs to, no pivot chainupdate occurs. Otherwise, Conflux re-runs the selectionalgorithm from the LCA block. Because long range pivotchain reorganization is extremely rare, rerunning the al-gorithm from the LCA block is not expensive in practice.

6 Experimental ResultsWe next present a systematic evaluation of Conflux onits throughput, confirmation speed, and scalability. Wealso evaluate important design aspects of Conflux, e.g.,the adaptive weight mechanism for defending againstliveness attacks, the deferred execution for optimizingthe transaction execution, as well as link-cut tree foroptimizing the Tree-Graph maintainance.

We deployed Conflux on up to 800 Amazon EC2m5.2xlarge virtual machines (VM), each of which has 8cores and 1Gbps network throughput. By default, we runone Conflux full node in each VM. To model the networklatency, we use the intercity latency measurements [34]and assign each VM to one of 20 major cities. We emu-late the intercity delay by inserting artificial delays. Foreach full node, the gossip network of Conflux connectsit to an average of 10 randomly selected peers.

When we measure the confirmation speed of a trans-action, we count a transaction as confirmed if we can

obtain the same confidence as empirically confirming atransaction in Bitcoin after waiting six Bitcoin blocks.In our experiments, unless otherwise noted, we limit thebandwidth of each full node to 20Mbps and we assigneach full node with an equal block generation power.

6.1 Protocol Parameter CalibrationTo calibrate Conflux consensus protocol parameters, werun a set of experiments with 200 Conflux full nodeson Amazon EC2 with one full node per VM. We runConflux with a set of different combinations of block sizelimits and block generation rates to measure the blockpropagation delays. For each setting, we run Confluxfrom the genesis for 10 minutes and fill each block to fullwith randomly generated simple payment transactions.

Figure 10a and 11a presents the experimental resultsof Conflux where we fix the block generation rate at fourblocks per second and change the block size limit. Aver-age network delay corresponds to the number of secondson average for a generated block to reach more than 50%of participants. Network delay (99%) corresponds thenumber of seconds for all blocks to reach more than 99%of participants. In our experiments, we use the networkdelay (99%) number as the network diameter d for calcu-lating parameters. There are often one or two machineslagging behind for some blocks and we can tolerate themas temporary failure nodes.

Conflux achieves the throughput of 9.6Mbps at thesetting of 300K × 4 blocks per second. We find thatConflux almost saturates its underlying gossip networkcapability, considering that we limit the bandwidth ofeach full node to 20Mbps, which is only enough to sendeach block twice on average. With block sizes of 350Kand beyond, full nodes start to experience significantlyhigher delay and may not be able to catch up new blocks.

Figure 10b and 11b presents the experimental resultsof Conflux where we fix the block generation through-put at 9.6Mbps and change the block generation ratefrom 2 blocks/s to 16 blocks/s. Our results show that asConflux operates with faster block generation rate andsmaller blocks, the network propagation delay decreases.But the delay no longer decreases much as it approachesthe latency limit of the network. Smaller network prop-agation delay will improve the confirmation speed oftransactions, but there are additional costs for using highgeneration rate. 1) Conflux full nodes have to store allblock headers (block content could be pruned away withcheckpoint techniques) and the average header size ofConflux is 300∼500 bytes; 2) high block generation ratesincur more blocks in parallel and these blocks cannot pro-cess transactions with dependencies.

524 2020 USENIX Annual Technical Conference USENIX Association

150 200 250 300Block size (KBytes)

0

20

40

60

80Ne

twor

k de

lay

(sec

)Block interval 0.25 seconds

Network delay (Avg)Network delay (P99)Conflux Confirmation speedGHOST Confirmation speed

0

20

40

60

80

Conf

irmat

ion

spee

d (s

ec)

(a) Latency vs. block sizes.

1/2 1/4 1/8 1/16Block interval (sec)

0

20

40

60

80

Netw

ork

dela

y (s

ec)

Block generation throughput 9.6 MbpsNetwork delay (Avg)Network delay (P99)Conflux Confirmation speedGHOST Confirmation speed

0

20

40

60

80

Conf

irmat

ion

spee

d (s

ec)

(b) Latency vs. block intervals.

3.0k 6.0k 9.0k 12.0kNumber of nodes

0

20

40

60

80

100

Netw

ork

dela

y (s

ec)

Block interval 0.25 seconds and block size 300KBNetwork delay (Avg)Network delay (P99)Conflux Confirmation speedGHOST Confirmation speed

0

20

40

60

80

100

Conf

irmat

ion

spee

d (s

ec)

(c) Scalability

Figure 10: Network Delay and Confirmation Speed

150 200 250 300Block size (bytes)

10 1

100

101

Thro

ughp

ut (M

bps)

Block interval 0.25 seconds

ConfluxGHOST

(a) Throughput vs. block sizes.

1/2 1/4 1/8 1/16Block interval (sec)

10 1

100

101

Thro

ughp

ut (M

bps)

Block generation throughput 9.6 Mbps

ConfluxGHOST

(b) Throughput vs. block intervals.

3.0k 6.0k 9.0k 12.0kNumber of nodes

10 1

100

101

Thro

ughp

ut (M

bps)

Block interval 0.25 seconds and block size 300KB

ConfluxGHOST

(c) Scalability

Figure 11: Throughput

Based on the above trade-off, we choose the blockgeneration rate of 4 blocks per second and the block sizelimit of 300K. With the measured network propagationdelay, we determine the adaptive weight algorithm param-eters following suggestions in our theory analysis [19].1) h = 600 is large enough to enable Conflux to tolerateliveness attacks from a powerful attacker that controls40% of the network computation power; 2) β = 160 andγ = 10000 so that the confirmation policy gives a desir-able margin; 3) α = 1800 since it requires α ≥ 3h; 4)h0 = 360 so the timer chain will have rare forks. Fig-ure 10 plots the average confirmation speed under thisset of parameters.

Compared to GHOST (by only considering pivotblocks as valid), Conflux achieves the similar confirma-tion latency while provides significantly higher through-put. As Figure 11b shows, the transaction throughput ofGHOST decreases with increasing block generation ratesince more concurrently generated blocks with smallersize lead to less valid transactions.

6.2 Performance ResultsConsensus Scalability Results: We next evaluate theconsensus protocol performance as the number of nodesincreases. Due to our resource limitation, we have to run15 full nodes per VM. Because we are evaluating the con-sensus protocol only, we turn off signature verificationand transaction execution to ensure enough computationresources for 15 full nodes sharing each VM.

Figure 10c presents the network propagation delayand the average transaction confirmation speed when run-ning Conflux with different numbers of full nodes. In

0 500 1000 1500 2000Timestamp (s)

1000000

2000000

3000000

4000000

Tota

l Tx

Coun

tETH (k=5)ETH (k=1)ETH + Payment (k=5)

Figure 12: End-to-end Results for ETH Workload

all the experiments, Conflux successfully operates withthe block throughput of 9.6Mbps (300K × 4 blocks persecond). Our results highlight the fast confirmation speedof Conflux, it confirms transactions on average in 47.75-51.54 seconds when running 3000-12000 full nodes. Ourresults also show that the consensus protocol of Confluxscales well. As the number of nodes increases, the net-work propagation delay only increases slightly so doesthe confirmation speed.

Note that our experimental setup is as same as theAlgorand and OHIE papers [11, 36], therefore we candirectly compare our results with their results. Com-pared to Algorand [11], Conflux achieves more than 4xthroughput and similar confirmation latency. Comparedto OHIE [36], Conflux achieves similar throughput butone order of magnitude faster confirmation.End-to-end Results: With the calibrated parameters, werun Conflux on 400 VMs (one node per VM) to mea-sure the throughput and the confirmation speed of Con-flux. To obtain a representative workload, we collectedthe first four million transactions from the Ethereumblockchain [2]. This includes both payment transactionsand smart contract transactions. We converted these col-

USENIX Association 2020 USENIX Annual Technical Conference 525

0 1000 2000 3000 4000 5000Timestamp (s)

0

2000

4000

6000

8000

Subt

ree

Wei

ght

Subtree 1Subtree 2Adaptive Weight TriggeredAdaptive Weight End

Figure 13: Subtree Weights under Liveness Attack

lected transactions into Conflux transaction format. Werun two experiments, one experiment with the collectedEthereum transactions only and another experiment witha combined workload of the collected Ethereum trans-actions and randomly generated payment transactions.We terminate an experiment once Conflux processes fourmillion transactions in total.

Figure 12 presents the number of processed transac-tions overtime. Our experimental results show that Con-flux achieves a throughput of 1392 transactions per sec-ond for Ethereum workload and 3480 transactions persecond for the combined workload. The average con-firmation latencies are under one minute for both theEthereum workload and the combined workload. Notethat in the combined workload experiment, 14% of pro-cessed transactions are from Ethereum history.

Conflux achieves higher transaction throughput onthe combined workload than on the Ethereum historyworkload. A primary reason is that Ethereum is a muchslower blockchain and its transaction history does nothave enough parallelism to saturates the Conflux con-sensus layer. We find that during the execution, futuretransactions in the Ethereum history often depends onprevious transactions and full nodes of Conflux oftendo not have enough pending transactions ready to pickup so concurrent blocks pack duplicate transactions. Asecondary reason is that Ethereum history contains moresmart contract transactions which are more expensive toprocess than payment transactions.Deferred Execution: Conflux by default defers the exe-cution of transactions by five epochs k = 5. To illustratethe effect of the deferred execution optimization, we runa modified version of Conflux on the Ethereum historyworkload with k = 1. The results in Figure 12 show thatthis causes a 11.6% slowdown of Conflux on the transac-tion throughput because of the frequent re-execution oftransactions during order oscillation.

6.3 Liveness Attack and Link-cut TreeLiveness Attack: We conducted a liveness attack experi-ment to evaluate the security of Conflux. The experimentincludes three nodes, two honest nodes and one attacker

node. They keep a four block per second block generationrate for entire network. The block propagation networkdelay between the two honest nodes are 20 seconds andthe attacker node does not relay honest blocks. We useonly two honest nodes with significant delay to simulatethe ideal liveness attack scenario in Figure 1c — a power-ful attacker that evenly splits honest nodes in two groupsand honest nodes with no latency inside a group and max-imum latency between the two groups. The attacker nodecontrols 30% of the total computation power. It launchesthe attack by finding the first fork between the two honestnodes and try to mine blocks under the lighter subtree tokeep the two subtrees balanced.

Figure 13 shows how the weights of the two forkedsubtrees change along the time. The attack starts at thetimestamp 0. During the time when the attack is per-formed and no adaptive weight is triggered, the weightsof the two forked subtrees are almost perfectly balanced.The adaptive weight mechanism triggers the conserva-tive strategy at timestamp 2,909 s. After that, the livenessattack quickly fails and the two honest nodes can thenagree on the same pivot block and generate blocks underits subtree. After another 1,264 s, the two honest nodescome back to the optimistic strategy.Link-cut Tree: To evaluate the benefits of link-cut tree,we run experiments on a micro-benchmark, a Tree-Graphthat contains 1.5 million blocks, to measure the blockprocessing throughput of the naive as well as our opti-mized approaches. Our experimental results show thatthe naive appraoch slows down to less than 4 blocks persecond when the number of blocks in the Tree-Graphgrows to one million, while our approach processes 5000blocks per second on average.

7 Conclusion

Conflux is a scalable and decentralized blockchain plat-form with high throughput and fast confirmation. Itsnovel consensus protocol makes Conflux secure againstboth double spending attacks and liveness attacks, even ifConflux operates with a fast block generation rate. Con-flux provides a promising solution to address the perfor-mance bottleneck of blockchains and opens up a widerange of blockchain applications.

Acknowledgments

We thank Bo Qiu and Yanpei Liu for their helps on theexperiments. We thank Xi Wang and the anonymousreviewers for their insightful comments on the early draftof this paper. We note that [18] describes an early versionof the Conflux system.

526 2020 USENIX Annual Technical Conference USENIX Association

References[1] Conflux-Rust. https://github.com/

Conflux-Chain/conflux-rust.

[2] Etherum White Paper. https://github.com/ethereum/wiki/wiki/White-Paper.

[3] Link/cut tree. https://en.wikipedia.org/wiki/Link/cut_tree.

[4] Snowflake to Avalanche: A Novel Metastable Con-sensus Protocol Family for Cryptocurrencies.

https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV.

[5] Splay tree. https://en.wikipedia.org/wiki/Splay_tree.

[6] Vivek Bagaria, Sreeram Kannan, David Tse, GiuliaFanti, and Pramod Viswanath. Prism: Deconstruct-ing the blockchain to approach physical limits. InProceedings of the 2019 ACM SIGSAC Conferenceon Computer and Communications Security, CCS’19, page 585–602, New York, NY, USA, 2019. As-sociation for Computing Machinery.

[7] Yuxi Cai, Fan Long, Andreas Park, and AndreasVeneris. Engineering economics in the confluxnetwork. arXiv preprint arXiv: 2004.13696, 2020.

[8] Yevgeniy Dodis, Leonid Reyzin, and Adam Smith.Fuzzy extractors: How to generate strong keys frombiometrics and other noisy data. In Christian Cachinand Jan L. Camenisch, editors, Advances in Cryp-tology - EUROCRYPT 2004, pages 523–540, Berlin,Heidelberg, 2004. Springer Berlin Heidelberg.

[9] Ittay Eyal, Adem Efe Gencer, Emin Gün Sirer,and Robbert Van Renesse. Bitcoin-ng: A scalableblockchain protocol. In NSDI, pages 45–59, 2016.

[10] Ittay Eyal and Emin Gün Sirer. Majority is notenough: Bitcoin mining is vulnerable. In Interna-tional conference on financial cryptography anddata security, pages 436–454. Springer, 2014.

[11] Yossi Gilad, Rotem Hemo, Silvio Micali, GeorgiosVlachos, and Nickolai Zeldovich. Algorand: Scal-ing byzantine agreements for cryptocurrencies. InProceedings of the 26th Symposium on OperatingSystems Principles, pages 51–68. ACM, 2017.

[12] Aumasson JP. and Bernstein D.J. Siphash: Afast short-input prf. Progress in Cryptology - IN-DOCRYPT, 2012.

[13] Aggelos Kiayias and Giorgos Panagiotakos. Speed-security tradeoffs in blockchain protocols. IACRCryptology ePrint Archive, 2015:1019, 2015.

[14] Eleftherios Kokoris Kogias, Philipp Jovanovic,Nicolas Gailly, Ismail Khoffi, Linus Gasser, andBryan Ford. Enhancing bitcoin security and perfor-mance with strong consistency via collective sign-ing. In 25th USENIX Security Symposium (USENIXSecurity 16), pages 279–296, 2016.

[15] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Li-nus Gasser, Nicolas Gailly, Ewa Syta, and BryanFord. Omniledger: A secure, scale-out, decentral-ized ledger via sharding. In 2018 IEEE Sympo-sium on Security and Privacy (SP), pages 583–598.IEEE, 2018.

[16] Derek Leung, Adam Suhl, Yossi Gilad, and Nick-olai Zeldovich. Vault: Fast bootstrapping for cryp-tocurrencies. In Proceedings of the 2019 AnnualNetwork and Distributed System Security Sympo-sium (NDSS), San Diego, CA, 2019.

[17] Yoad Lewenberg, Yonatan Sompolinsky, and AvivZohar. Inclusive block chain protocols. In Interna-tional Conference on Financial Cryptography andData Security, pages 528–547. Springer, 2015.

[18] Chenxing Li, Peilun Li, Dong Zhou, Wei Xu,Fan Long, and Andrew Chi-Chih Yao. Scalingnakamoto consensus to thousands of transactionsper second. arXiv preprint, 1805.03870, 2018.

[19] Chenxing Li, Fan Long, and Guang Yang. GHAST:Breaking confirmation delay barrier in nakamotoconsensus via adaptive weighted blocks. arXivpreprint arXiv:2006.01072, 2020.

[20] Loi Luu, Viswesh Narayanan, Chaodong Zheng,Kunal Baweja, Seth Gilbert, and Prateek Saxena. Asecure sharding protocol for open blockchains. InProceedings of the 2016 ACM SIGSAC Conferenceon Computer and Communications Security, CCS’16, pages 17–30, New York, NY, USA, 2016. ACM.

[21] David Mazieres. The stellar consensus protocol: Afederated model for internet-level consensus. Stel-lar Development Foundation, 2015.

[22] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi,and Dawn Song. The honey badger of bft protocols.In Proceedings of the 2016 ACM SIGSAC Confer-ence on Computer and Communications Security,pages 31–42. ACM, 2016.

USENIX Association 2020 USENIX Annual Technical Conference 527

[23] Satoshi Nakamoto. Bitcoin: A peer-to-peer elec-tronic cash system,” http://bitcoin.org/bitcoin.pdf.

[24] Gleb Naumenko, Gregory Maxwell, Pieter Wuille,Alexandra Fedorova, and Ivan Beschastnikh. Erlay:Efficient transaction relay for bitcoin. In Proceed-ings of the 2019 ACM SIGSAC Conference on Com-puter and Communications Security, CCS ’19, page817–831, New York, NY, USA, 2019. Associationfor Computing Machinery.

[25] Kartik Nayak, Srijan Kumar, Andrew EdmundMiller, and Elaine Shi. Stubborn mining: General-izing selfish mining and combining with an eclipseattack. In IEEE European Symposium on Securityand Privacy, pages 305–320, 2016.

[26] Rafael Pass, Lior Seeman, and Abhi Shelat. Anal-ysis of the blockchain protocol in asynchronousnetworks. In Annual International Conference onthe Theory and Applications of Cryptographic Tech-niques, pages 643–673. Springer, 2017.

[27] Rafael Pass and Elaine Shi. Fruitchains: A fairblockchain. In Proceedings of the ACM Symposiumon Principles of Distributed Computing, pages 315–324. ACM, 2017.

[28] Rafael Pass and Elaine Shi. Hybrid consensus:Efficient consensus in the permissionless model.In LIPIcs-Leibniz International Proceedings in In-formatics, volume 91. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2017.

[29] Ayelet Sapirshtein, Yonatan Sompolinsky, and AvivZohar. Optimal selfish mining strategies in bitcoin.CoRR, abs/1507.06183, 2015.

[30] Yonatan Sompolinsky, Yoad Lewenberg, and AvivZohar. Spectre: Serialization of proof-of-workevents: confirming transactions via recursive elec-tions, 2016.

[31] Yonatan Sompolinsky and Aviv Zohar.Phantom, a scalable blockdag protocol.https://eprint.iacr.org/2018/104.pdf.

[32] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In Interna-tional Conference on Financial Cryptography andData Security, pages 507–527. Springer, 2015.

[33] Jiaping Wang and Hao Wang. Monoxide: Scale outblockchains with asynchronous consensus zones.In 16th USENIX Symposium on Networked SystemsDesign and Implementation (NSDI 19), pages 95–112, Boston, MA, 2019. USENIX Association.

[34] WonderNetwork. Global ping statistics: Pingtimes between WonderNetwork servers. https://wondernetwork.com/pings, Apr. 2018.

[35] Gavin Wood. Ethereum: A secure decentralisedgeneralised transaction ledger eip-150 revision(759dccd - 2017-08-07), 2017. Accessed: 2018-01-03.

[36] Haifeng Yu, Ivica Nikolic, Ruomu Hou, and PrateekSaxena. OHIE: Blockchain scaling made simple.arXiv preprint arXiv:1811.12628, 2018.

[37] Mahdi Zamani, Mahnush Movahedi, and MarianaRaykova. Rapidchain: A fast blockchain protocolvia full sharding.

528 2020 USENIX Annual Technical Conference USENIX Association