Bitcoin-NG: A Scalable Blockchain Protocol - USENIX

Bitcoin-NG: A Scalable Blockchain Protocol
Ittay Eyal, Adem Efe Gencer, Emin Gün Sirer, and Robbert van Renesse, Cornell University
 https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/eyal

 This paper is included in the Proceedings of the
 13th USENIX Symposium on Networked Systems
 Design and Implementation (NSDI ’16).
 March 16–18, 2016 • Santa Clara, CA, USA
 ISBN 978-1-931971-29-4

 Open access to the Proceedings of the
 13th USENIX Symposium on
 Networked Systems Design and
 Implementation (NSDI ’16)
 is sponsored by USENIX.

Bitcoin-NG: A Scalable Blockchain Protocol∗

 Ittay Eyal Adem Efe Gencer Emin Gün Sirer Robbert van Renesse
 Cornell University

Abstract market cap; and attracted close to $1B in venture cap-
Cryptocurrencies, based on and led by Bitcoin, have ital [15]. The core technological innovation power-
shown promise as infrastructure for pseudonymous on- ing these systems is the Nakamoto consensus proto-
line payments, cheap remittance, trustless digital as- col for maintaining a distributed ledger known as the
set exchange, and smart contracts. However, Bitcoin- blockchain. The blockchain technology provides a de-
derived blockchain protocols have inherent scalability centralized, open, Byzantine fault-tolerant transaction
limits that trade off between throughput and latency, mechanism, and promises to become the infrastructure
which withhold the realization of this potential. for a new generation of Internet interaction, including
 This paper presents Bitcoin-NG (Next Generation), a anonymous online payments [14], remittance, and trans-
new blockchain protocol designed to scale. Bitcoin-NG action of digital assets [16]. Ongoing work explores
is a Byzantine fault tolerant blockchain protocol that is smart digital contracts, enabling anonymous parties to
robust to extreme churn and shares the same trust model programmatically enforce complex agreements [31, 56].
as Bitcoin. Despite its potential, blockchain protocols face a sig-
 In addition to Bitcoin-NG, we introduce several novel nificant scalability barrier [51, 36, 19, 5]. The maximum
metrics of interest in quantifying the security and effi- rate at which these systems can process transactions is
ciency of Bitcoin-like blockchain protocols. We imple- capped by the choice of two parameters: block size and
ment Bitcoin-NG and perform large-scale experiments block interval. Increasing block size improves through-
at 15% the size of the operational Bitcoin system, us- put, but the resulting bigger blocks take longer to propa-
ing unchanged clients of both protocols. These exper- gate in the network. Reducing the block interval reduces
iments demonstrate that Bitcoin-NG scales optimally, latency, but leads to instability where the system is in
with bandwidth limited only by the capacity of the indi- disagreement and the blockchain is subject to reorganiza-
vidual nodes and latency limited only by the propagation tion. Bitcoin currently targets a conservative 10 minutes
time of the network. between blocks, yielding 10-minute expected latencies
 for transactions to be encoded in the blockchain. The
1 Introduction block size is currently set at 1MB, yielding only 1 to 3.5
Bitcoin has emerged as the first widely-deployed, de- transactions per second for Bitcoin for typical transac-
centralized global currency, and sparked hundreds of tion sizes. Proposals for increasing the block size are
copycat currencies. Overall, cryptocurrencies have gar- the topic of heated debate within the Bitcoin commu-
nered much attention from the financial and tech sec- nity [47].
tors, as well as academics; achieved wide market pen- In this paper, we present Bitcoin-NG, a scalable
etration in underground economies [38]; reached a $12B blockchain protocol, based on the same trust model as
 Bitcoin. Bitcoin-NG’s latency is limited only by the
 ∗ The authors are supported in part by AFOSR grants FA2386-
 propagation delay of the network, and its bandwidth is
12-1-3008, F9550-06-0019, by the AFOSR MURI Science of Cy-
ber Security: Modeling, Composition, and Measurement as AFOSR limited only by the processing capacity of the individual
grant FA9550-11-1-0137, by NSF grants CNS-1601879, 0430161, nodes. Bitcoin-NG achieves this performance improve-
0964409, 1040689, 1047540, 1518779, 1561209, and CCF-0424422 ment by decoupling Bitcoin’s blockchain operation into
(TRUST), by ONR grants N00014-01-1-0968 and N00014-09-1-0652,
by DARPA grants FA8750-10-2-0238 and FA8750-11-2-0256, by
 two planes: leader election and transaction serialization.
MDCN/iAd grant 54083, and by grants from Microsoft Corporation, It divides time into epochs, where each epoch has a sin-
Facebook Inc., and Amazon.com. gle leader. As in Bitcoin, leader election is performed

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 45

randomly and infrequently. Once a leader is chosen, it is 2 Model and Goal
entitled to serialize transactions unilaterally until a new The system is comprised of a set of nodes N connected
leader is chosen, marking the end of the former’s epoch. by a reliable peer-to-peer network. Each node can poll
 While this approach is a significant departure from a random oracle [6] as a random bit source. Nodes can
Bitcoin’s operation, Bitcoin-NG maintains Bitcoin’s se- generate key-pairs, but there is no trusted public key in-
curity properties. Implicitly, leader election is already frastructure.
taking place in Bitcoin. But in Bitcoin, the leader is in The system employs a cryptopuzzle system, defined
charge of serializing history, making the entire duration by a cryptographic hash function H. The solution to
of time between leader elections a long system freeze. a puzzle defined by the string y is a string x such that
In contrast, leader election in Bitcoin-NG is forward- H(y|x) — the hash of the concatenation of the two —
looking, and ensures that the system is able to continually is smaller than some target. Each node i has a limited
process transactions. amount of compute power, called mining power, mea-
 sured by the number of potential puzzle solutions it can
 Evaluating the performance and functionality of new try per second. A solution to a puzzle constitutes a proof
consensus protocols is a challenging task. To help per- of work, as it statistically indicates the amount of work a
form this quantitatively and provide a foundation for node had to perform in order to find it.
the comparison of alternative consensus protocols, we At any time t, a subset of nodes B(t) ⊂ N are Byzan-
introduce several metrics to evaluate implementations tine and behave arbitrarily, controlled by a single adver-
of Nakamoto consensus. These metrics capture perfor- sary. The other nodes are honest — they abide by the
mance metrics such as protocol goodput and latency, as protocol. The mining power of each node i is m(i). The
well as various aspects of its security, including its ability mining power of the Byzantine nodes is less than 1/4 of
to maintain consensus and resist centralization. the total compute power at any given time:
 We evaluate the performance of Bitcoin-NG on a large 1
emulation testbed consisting of 1000 nodes, amount- ∀t : ∑ m(b) < ∑ m(n)
 4 n∈N
ing to over 15% of the current operational Bitcoin net- b∈B(t)
work [41]. This testbed enables us to run unchanged because proof-of-work blockchains, Bitcoin-NG in-
clients, using realistic Internet latencies. We com- cluded, are vulnerable to selfish mining by attackers
pare Bitcoin-NG with the original Bitcoin client, and larger than 1/4 of the network [25].
demonstrate the critical trade-offs inherent in the original
Bitcoin protocol. Controlling for network bandwidth, re- Nakamoto Consensus
ducing Bitcoin’s latency by decreasing the block interval The nodes are to implement a replicated state machine
and improving its throughput by increasing the block size (RSM) [33, 50]. Properties of the system can be com-
both yield adverse effects. In particular, fairness suffers, pared to those of classical consensus [46]:
giving large miners an advantage over small miners. This
anomaly leads to centralization, where the mining power Termination There exists a time difference function
tends to be concentrated under a single controller, break- ∆(·) such that, given a time t and a value 0 < ε < 1,
ing the basic premise of the decentralized cryptocurrency the probability is smaller than ε that at times t  ,t  >
vision. Additionally, mining power is lost, making the t + ∆(ε) a node returns two different states for the
system more vulnerable to attacks. In contrast, Bitcoin- machine at time t.
NG improves latency and throughput to the maximum al-
 Agreement There exists a time difference function ∆(·)
lowed by network conditions and node processing limits,
 such that, given a 0 < ε < 1, the probability that at
while avoiding the fairness and mining power utilization
 time t two nodes return different states for t − ∆(ε)
problems.
 is smaller than ε.
 In summary, this paper makes three contributions. Validity If the fraction of mining power of Byzantine
First, it outlines the Bitcoin-NG scalable blockchain pro- ∑ m(b)
 nodes is bounded by f , i.e., ∀t : ∑b∈B(t)m(n) < f ,
tocol, which achieves significantly higher throughput and n∈N
 then the average fraction of state machine transi-
lower latency than Bitcoin while maintaining the Bit-
 tions that are not inputs of honest nodes is smaller
coin trust assumptions. Second, it introduces quantita-
 than f .
tive metrics for evaluating Nakamoto consensus proto-
cols. These metrics are designed to ground the ongoing
discussion over parameter selection in Bitcoin-derived 3 Bitcoin and its Blockchain Protocol
currency. Finally, it quantifies, through large-scale ex- Bitcoin is a distributed, decentralized crypto-currency [7,
periments, Bitcoin-NG’s robustness and scalability. 8, 9, 43], which implicitly defined and implemented

46 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association

Nakamoto consensus. Bitcoin uses the blockchain pro- required (in expectancy) the most mining power to gen-
tocol to serialize transactions of the Bitcoin currency erate. All miners add blocks to the heaviest chain of
among its users. The replicated state machine maintains which they know, with random tie-breaking. We note
the balances of the different users, and its transitions are that choosing a longest branch at random is suggested
transactions that move funds among them. This state ma- by Eyal and Sirer [25]. The operational client currently
chine is managed by the system nodes, called miners. chooses the first branch it has heard of, making it more
 Each user commands addresses, and sends Bitcoins vulnerable in the general case. The heaviest chain a node
by forming a transaction from her address to another’s knows is the serialization of RSM inputs it knows, and
address and sending it to the nodes. More explicitly, a hence describes the RSM’s state. The formation of forks
transaction is from the output of a previous transaction is undesirable, as they indicate that there is no globally-
to a specific address. An output is spent if it is the in- agreed RSM state.
put of another transaction. A client owns x Bitcoins at Branches and blocks outside the main chain are called
time t if the aggregate of unspent outputs to its address pruned (and not orphans, as is common in informal dis-
is x. Transactions are protected with cryptographic tech- cussions, since they have a parent in the block tree).
niques that ensure only the rightful owner of a Bitcoin Transactions in pruned blocks are ignored. They can be
address can transfer funds from it. Miners accept trans- placed in the main chain at any later time, unless a con-
actions only if their sources have not been spent, thereby tradicting transaction (that spends the same outputs) was
preventing users from double-spending their funds. The placed there in the meantime.
miners commit the transactions into a global append- Block dissemination over the Bitcoin overlay network
only log called the blockchain. takes seconds, whereas the average mining interval is ten
 The blockchain records transactions in units of blocks. minutes. Therefore, accidental bifurcation occurs on av-
Each block includes a unique ID, and the ID of the pre- erage about once every 60 blocks [18].
ceding block. The first block, dubbed the genesis block, We are now ready to describe Bitcoin-NG.
is defined as part of the protocol. A valid block contains
(1) a solution to a cryptopuzzle involving the hash of 4 Bitcoin-NG
the previous block, (2) the hash (specifically, the Merkle Bitcoin-NG is a blockchain protocol that serializes trans-
root) of the transactions in the current block, which have actions, much like Bitcoin, but allows for better latency
to be valid, and (3) a special transaction, called the coin- and bandwidth without sacrificing other properties.
base, crediting the miner with the reward for solving the The protocol divides time into epochs. In each epoch,
cryptopuzzle. This process is called Bitcoin mining, and, a single leader is in charge of serializing state machine
by slight abuse of terminology, we refer to the creation transitions. To facilitate state propagation, leaders gener-
of blocks as block mining. The specific cryptopuzzle is ate blocks. The protocol introduces two types of blocks:
a double-hash of the block header whose result has to be key blocks for leader election and microblocks that con-
smaller than a set value. The problem difficulty, set by tain the ledger entries. Each block has a header that con-
this value, is dynamically adjusted such that blocks are tains, among other fields, the unique reference of its pre-
generated at an average rate of one every ten minutes. decessor; namely, a cryptographic hash of the predeces-
 sor header.
Mining When a miner creates a block, she is compen-
 We detail the operation of the protocol in this section
sated for her efforts with Bitcoins. This compensation
 and explain its incentive system in Section 5.
includes a per-transaction fee paid by the users whose
transactions are included, as well as an amount of new 4.1 Key Blocks and Leader Election
Bitcoins that did not exist before.
 Key blocks are used to choose a leader. Like a Bitcoin
Forks Any miner may add a valid block to the chain block, a key block contains the reference to the previ-
by simply publishing it over an overlay network to all ous block (either a key block or a microblock, usually
other miners. If multiple miners create blocks with the the latter), the current Unix time, a coinbase transaction
same preceding block, the chain is forked into branches, to pay out the reward, a target value, and a nonce field
forming a tree. Other miners may subsequently add new containing arbitrary bits. As in Bitcoin, for a key block
valid blocks to any of these branches. When a miner to be valid, the cryptographic hash of its header must be
tries to add a new block after an existing block, we say smaller than the target value. Unlike Bitcoin, a key block
it mines on the existing block. If this block is a leaf of a contains a public key that will be used in subsequent mi-
branch, we say he mines on the branch. croblocks.
 To resolve forks, the protocol prescribes on which As in Bitcoin, for a miner to generate a key block, it
chain the miners should mine. The criterion is that the must iterate through nonce values until the crypto-puzzle
winning chain is the heaviest one, that is, the one that condition is met. Consequently, the interval between

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 47

40% 60% 3 4
 fees

 1 2 1 2
 PK sig sig sig PK sig 
 Figure 2: When microblocks are frequent, short forks
 10 seconds occur on almost every leader switch.
 10 minutes
Figure 1: Structure of the Bitcoin-NG chain. Mi-
croblocks (circles) are signed with the private key match- to-be-pruned microblock (blocks A3 and A4 in the fig-
ing the public key in the last key block (squares). Fee is ure) before the new key block (block B in the figure). It
distributed 40% to the leader and 60% to the next one. is resolved once the key block propagates to that node.
 Therefore, a user that sees a microblock should wait for
 the propagation time of the network before considering
consecutive key blocks is exponentially distributed. To it in the chain, to make sure it is not pruned by a new key
maintain a set average rate, the difficulty is adjusted by block.
deterministically changing the target value based on the
Unix time in the key block headers. 4.4 Remuneration
 In case of a fork, just as in Bitcoin, the nodes pick To motivate mining, a leader is compensated for her ef-
the branch with the most work, aggregated over all key forts by the protocol. Remuneration is comprised of two
blocks, with random tie breaking. parts. First, each key block entitles its generator a set
 amount. Second, each ledger entry carries a fee. This
4.2 Microblocks fee is split by the leader that places this entry in a mi-
Once a node generates a key block it becomes the leader. croblock, and the subsequent leader that generates the
As a leader, the node is allowed to generate microblocks next key block. Specifically, the current leader earns 40%
at a set rate smaller than a predefined maximum. The of the fee, and the subsequent leader earns 60% of the
maximum rate is deterministic, and can be much higher fee, as illustrated in Figure 1. The choice of this distribu-
than the average interval between key blocks. The size tion is explained in Section 5.
of microblocks is bounded by a predefined maximum. In practice, the remuneration is implemented by hav-
Specifically, if the timestamp of a microblock is in the fu- ing each key block contain a single coinbase transaction
ture, or if its difference with its predecessor’s timestamp that mints new coins and deposits the funds to the current
is smaller than the minimum, then the microblock is in- and previous leaders. As in Bitcoin, this transaction can
valid. This bound prohibits a leader (malicious, greedy, only be spent after a maturity period of 100 key blocks,
or broken) from swamping the system with microblocks. to avoid non-mergeable transactions following a fork.
 A microblock contains ledger entries and a header.
The header contains the reference to the previous block, 4.5 Microblock Fork Prevention
the current Unix time, a cryptographic hash of its ledger Since microblocks do not require mining, they can be
entries, and a cryptographic signature of the header. The generated cheaply and quickly by the leader, allowing
signature uses the private key that matches the public key it to split the brain of the system, publishing differ-
in the latest key block in the chain. For a microblock to ent replicated-state-machine states to different machines.
be valid, all its entries must be valid according to the This allows for double spending attacks, where different
specification of the state machine, and the signature has nodes believe the same coins were spent with different
to be valid. Figure 1 illustrates the structure. transactions.
 Note that microblocks do not affect the weight of the To demotivate such behavior, we use a dedicated
chain, as they do not contain proof of work. This is crit- ledger entry that invalidates the revenue of fraudulent
ical for keeping the incentives aligned, as explained in leaders. Past work has used such entries in different
Section 5. contexts [22, 4, 13]. In Bitcoin-NG, the entry is called
 a poison transaction, and it contains the header of the
4.3 Confirmation Time first block in the pruned branch as a proof of fraud. The
When a miner generates a key block, he may not have poison transaction has to be placed on the blockchain
heard of all microblocks generated by the previous within the maturity window of the misbehaving leader’s
leader. If microblock generation is frequent, this can key block, and before the revenue is spent by the mali-
be the common case on leader switching. The result cious leader. Besides invalidating the compensation sent
is a short microblock fork, as illustrated in Figure 2. to the leader that generated the fork, a poison transaction
Such a fork is observed by any node that receives the grants the current leader a fraction of that compensation,

48 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association

e.g., 5%. The choice of this value is explained in Sec- Consider a miner whose mining power ratio out of
tion 5. all mining power in the system is α. Denote by rleader
 Only one poison transaction can be placed per cheater, the revenue of the leader from a transaction, leaving
even if the cheater creates many forks. The cheater’s rev- (1 − rleader ) for the next miner. In Bitcoin-NG, we have
enue that is not relayed to the poisoner is lost. rleader = 40%. The value of rleader has to be such that
 the average revenue of a miner trying the above attack
5 Security Analysis is smaller than his revenue placing the transaction in a
 public microblock as it should:
5.1 Incentives
 Win 100% Lose 100%, but mine after txn
This section describes how miners with capacity smaller      
than 1/4 of the total network are incentivized to follow α × 100% + (1 − α) × α × (100% − rleader ) < rleader ,
the protocol. Specifically, miners are motivated to (1)
 1−α
include transactions in their microblocks, (2) extend the therefore rleader > 1 − 1+α−α 2 . Assuming the power of

heaviest chain, and (3) extend the longest chain. Unlike an attacker is bounded by 1/4 of the mining power, we
in Bitcoin, the latter two points are not identical. obtain rleader > 37%, hence rleader = 40% is within range.
Heaviest Chain Extension The motivation for extend- Longest Chain Extension To increase his revenue
ing the heaviest chain is the same as in Bitcoin. Since from a transaction, a miner could avoid the transaction’s
the honest majority will extend the heaviest chain, it will microblock and mine on a previous block. Then he
remain the main chain with high probability. A dishon- would place the transaction in its own microblock and
est majority may arbitrarily switch to any branch and try mining the subsequent key block. His revenue in this
win [32]. A minority choosing to mine on another branch case must be smaller than his revenue by mining on the
will not catch up with an honest majority, therefore it will transaction’s microblock as prescribed:
mine on the main chain to ensure its revenues. We there- Place in Mine next Mine on existing
fore argue that the guarantees of Bitcoin-NG are similar microblock key block microblock
         
to those of Bitcoin [40] with respect to the Termination rleader + α(100% − rleader ) < 100% − rleader ,
and Agreement properties of Nakamoto consensus.
 Microblocks carry no weight, not even as a secondary therefore rleader < 1−α
 2−α . Assuming the power of an at-
index. If they did, it would increase the system’s vul- tacker is bounded by 1/4 of the mining power, we obtain
nerability to selfish mining [24, 44, 49]. In selfish min- rleader < 43%, hence rleader = 40% is within range.
ing, an attacker withholds blocks it has mined and pub- Optimal Network Assumption Incentive compatibil-
lishes them judiciously to obtain a superior presence in ity cannot be maintained in Bitcoin-NG for an attacker
the main chain. If microblocks carried weight, an at- larger than about 29%. For larger attackers, the inter-
tacker could keep secret microblocks and gain advantage section of the two conditions is empty. But this limit
by mining on microblocks unpublished to anyone else. does not come into play in the general case, where
 We conclude that Bitcoin-NG does not introduce a Bitcoin-NG, like Nakamoto’s blockchain with random
new vulnerability to selfish mining strategies, and so tie breaking [25], are secure only against attackers
Bitcoin-NG is resilient to selfish mining against attack- smaller than 23.2% [49] due to selfish mining attacks.
ers with less than 1/4 of the mining power. We therefore However, under optimal network assumptions, Bit-
argue that the guarantees of Bitcoin-NG are similar to coin’s blockchain is more resilient than Bitcoin-NG: As-
those of Bitcoin with respect to the validity property of suming a zero latency network where an attacker cannot
Nakamoto consensus. rush messages — i.e., receive a message and send its own
Transaction Inclusion A leader earns 40% of a trans- such that other nodes receive the attacker’s message be-
action’s revenue by placing it in a microblock. However, fore the original one — Bitcoin is believed to be secure
he could potentially improve his revenue by secretly try- against selfish mining attackers of size up to almost 1/3.
ing to earn 100% of the fee. To do so, first, the leader Bypassing Fee Distribution We note that a user can
creates a microblock with the transaction, but does not circumvent the 40 − 60% transaction fee distribution by
publish it. Then, he tries to mine on top of this se- paying no transaction fee, and instead paying the current
cret microblock, while other miners mine on older mi- leader directly, using the coinbase address of the leader’s
croblocks. If the leader succeeds in mining the subse- key block. However, a user does not gain a significant ad-
quent key block, he obtains 100% of the transaction fees. vantage by doing so. As we have seen above, paying only
Otherwise, he waits until the transaction is placed in a the current leader increases the direct motivation of the
microblock by another miner and tries to mine on top of current leader to place the transaction in a microblock,
it. but reduces the motivation of future miners to mine on

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 49

this microblock. Moreover, if the leader does not include 2’ 3’ 4’ 5’ 6’ 7’ 8’
the transaction before the end of its epoch, subsequent 1
leaders will have no motivation to place the transaction. 2 3 4 5 6 7
 Other motives for fee manipulation, such as paying a
large fee to encourage miners to choose a certain branch Figure 3: Key block fork. Blocks B and C have the
after a fork, apply to Bitcoin as well as Bitcoin-NG, and same chain weight, and the fork is not resolved until key
are outside the scope of this work. block D is published.

5.2 Other concerns
 Such changes are especially problematic for small alt-
Wallet Security The possibility of placing a poison coins. When their value rises, they observe a rapid rise in
transaction allows an attacker that obtains a leader’s pri- mining power, and subsequently a drop in mining power
vate key to revoke his revenue retroactively and earn a once the difficulty rises. Then, since the difficulty is high,
small amount. However, such an attacker is better off the remaining miners need a longer time to generate the
trying to steal the full leader’s revenue when it becomes next block, potentially orders of magnitude longer.
available, therefore the introduction of the poison trans- In Bitcoin-NG, difficulty adjustments can create a sim-
action does not add a significant vulnerability. ilar problem; however, it only affects key blocks. Mi-
Censorship Resistance A central goal of Bitcoin is to croblocks are generated at the same constant rate. As a
prevent a malicious discriminating miner from dropping consequence, in case of a sudden mining power drop,
a user’s transactions. Censorship resistance is not im- Bitcoin-NG’s censorship resistance is reduced, as key
pacted by the frequent microblocks of Bitcoin-NG. blocks are generated infrequently. If a malicious miner
 First, we note that a leader’s absolute power is lim- becomes a leader, it will generate microblocks until an
ited to his epoch of leadership. A malicious leader can honest leader finds a key block. Nevertheless, transaction
perform a DoS attack by placing no transactions in mi- processing continues at the same rate, in microblocks.
croblocks. Similarly, a benign leader that crashes dur- Additionally, even until the difficulty is tuned to a correct
ing his epoch of leadership will publish no microblocks. value, the ratio of time during which malicious miners
Their influence ends once the next leader publishes his are leaders remains proportional to their mining power.
key block. The impact of such behaviors is therefore Forks When issuing microblocks at a high frequency,
similar to that in Bitcoin, where nodes may mine empty Bitcoin-NG observes a fork almost on every key block
blocks, but rarely do. generation, as the previous leader keeps generating mi-
 Assuming an honest majority and no backlog, a user croblocks until it receives the key block (Figure 2).
will have her transaction placed in the first block gener- These forks are resolved quickly — once the new key
ated by an honest miner. Since at least 3/4 of the blocks block arrives at a node, it switches to the new leader.
are generated by honest miners, the user will have to wait In comparison, when running Bitcoin at such high fre-
for 4/3 blocks on average, or 13.33 minutes. Key block quency, forks are only resolved by the heaviest chain ex-
intervals can be set to a rate that would reduce censorship tension rule, and since different miners may mine on dif-
to the minimum allowed by the network without incur- ferent branches, branches remain extant for a longer time
ring prohibitive deterioration of other metrics. compared to Bitcoin-NG.
 Bitcoin-NG may also experience key block forks,
Resilience to Mining Power Variation Following Bit-
 where multiple key blocks are generated after the same
coin’s success, hundreds of alternative currencies were
 prefix of key blocks, as shown in Figure 3. This rarely
created [57], most with Bitcoin’s exact blockchain struc-
 happens, due to the low frequency and quick propagation
ture, and many with the same proof-of-work mechanism.
 of the small key blocks. The duration of such a fork may
To maintain a stable rate of blocks, different instances of
 be long, lasting until the next key block. The result is
the blockchain tune their proof of work difficulty at dif-
 therefore infrequent, but long, key block forks.
ferent rates: Bitcoin once every 2016 blocks – about 2
 Although such long forks are undesirable, they are not
weeks, Litecoin [37] every 2016 blocks (produced at a
 dangerous. The knowledge of the fork is propagated
higher rate) – about 3.5 days, and Ethereum [56] on ev-
 through the network, and once it reaches the nodes, they
ery block – about 12 seconds. However, whichever ad-
 are aware of the undetermined state. All transactions that
justment rate is chosen, these protocols are all sensitive
 appear only on one branch are therefore uncertain until
to sudden mining power drops. Such drops happen when
 one branch gains a lead.
miners are incentivized to stop mining due to a drop in
the currency’s exchange rate, or to mine for a different Double Spending Double-spending attacks remain a
currency that becomes more profitable due to a change vulnerability in Bitcoin-NG, though to a lesser extent
in mining difficulty or exchange rate of either currency. than in Bitcoin.

50 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association

Consider a Nakamoto blockchain and a Bitcoin- 1 2
NG blockchain with the same bandwidth, where the : 1 2
Nakamoto block interval is the same as the key-block
 : 1 2 3
interval. A double-spending attacker publishes a trans-
action tA , receives a service from a merchant, and pub- 1 2 3
 :
lishes an alternative conflicting transaction tB . A mer-
chant that requires very high confidence should wait for Δ1 Δ2
several Nakamoto blocks, or an equivalent number of
 Figure 4: Point-consensus delay example with three Bit-
Bitcoin-NG key blocks. With lower confidence require-
 coin nodes a, b, and c that generate blocks at heights 1, 2,
ments, the guarantees of the protocols differ.
 and 3 (explosions) and learn that these blocks are in the
 In Nakamoto’s blockchain, blocks are infrequent, and main chain (clouds). Intervals ∆1 and ∆2 are the 50%-
transactions are collected by miners until they find a point consensus delays at times t1 and t2 , respectively:
block. Until that time, a transaction tA can be replaced by At least a majority of the nodes at ti agree on the history
another transaction tB without cost. Publication of con- until ti − ∆i .
flicting transactions with different destinations is prohib-
ited by the standard Bitcoin software, which also warns
the user of conflicting transactions propagating in the The consensus delay is the best point-consensus-delay
network [30]. the system achieves for a certain fraction of the time, on
 In contrast, in Bitcoin-NG, microblocks are frequent, average. More formally, the (ε, δ ) consensus delay of a
and so a leader commits to a transaction by placing it in system is the δ -percentile ε-point-consensus-delay. For
a microblock. It cannot place tB without forming a fork example, if 90% of the time, 50% of the nodes agree on
and subsequently losing all of its prize from its leader- the state of the state machine 10 seconds ago (but not less
ship epoch via a poison transaction. than that), then the (50%, 90%)-consensus delay is 10
 Other attacks are still possible, where a miner mines seconds.
before the microblock of transaction tA and later places Fairness We calculate two ratios: (1) the ratio of tran-
a conflicting tB . Here, the attacker loses the fees of sitions not coming from the largest miner with respect
all transactions in pruned microblocks, but this may be to all transitions, and (2) the ratio of mining power not
worthwhile since the loot from the double-spend can be owned by the largest miner with respect to all mining
arbitrarily high. An attacker can mine to prune the chain power. We call the ratio of these ratios the fairness.
in advance, and then place a conflicting transaction, or Optimally the fairness is 1.0: The largest miner and
try to prune after the fact. the non-largest miners’ representation in the transitions
 Reasoning about such attacks calls for a formaliza- set should be the same as their respective mining powers.
tion of the attacker’s incentives and power. We defer
 Mining Power Utilization The security of a proof-of-
formal analysis that quantifies the security guarantees of
 work system derives from the mining power used to se-
Bitcoin-NG and Nakamoto’s blockchain to future work.
 cure it; that is, the mining power an attacker has to out-
In practice, merchants perform risk analysis to choose a
 run to obtain disproportionate control. The mining power
strategy appropriate for their business.
 utilization is the ratio between the mining power that
6 Metrics secures the system and the total mining power. Min-
 ing power wasted on work that does not appear on the
We now detail novel metrics by which blockchains can blockchain accounts for the difference.
be evaluated. These metrics are designed to evaluate the
unique properties of Nakamoto consensus. Subjective Time to Prune Due to the probabilistic na-
 ture of Nakamoto consensus, a node may learn of a state
Consensus Delay Intuitively, consensus delay is the machine transition and subsequently learn that this tran-
time it takes for a system to reach agreement. We start sition has not occurred – that it was pruned from history.
by defining, for a specific execution and time, how long This is the case with pruned branches in Bitcoin.
back nodes have to look to find a point where they agree The δ time to prune is the δ -percentile of the differ-
on the state. ence between the time a node learns about a transition
 In a specific execution of an algorithm, given a time t that will eventually be pruned, and the time it learns that
and a ratio 0 < ε ≤ 1, the ε point consensus delay is the this transition has not occurred. This implies what time a
smallest time difference ∆ such that at least ε · |N | of user has to wait to be confident a transition has occurred.
the nodes at time t report the same state machine transi- Note that this metric only considers transitions that are
tion prefix up to time t − ∆. An example for the Bitcoin eventually pruned. Figure 5 illustrates an example with
protocol is illustrated in Figure 4. the Nakamoto Blockchain.

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 51

Time to prune
 30%

 Mining Power
 2’ 3’

 Ratio of
 0 1 20%
 2 3 4
 10%
 
 Time to win 0
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
 Mining Pools (Descending Mining Power)
Figure 5: A fork in the blockchain with blocks drawn at
their generation times, on a time X axis. Subjective time Figure 6: Error bars represent the 75th, 50th and 25th
to prune is measured from when a node learns of a block percentiles of the corresponding batch.
in a branch until it realizes what the main chain is. Time
to win is measured from the creation time of a block until
the last time a node generated a conflicting block. Consequently, mining power tends to centralize in the
 form of industrial mining and open mining pools. In-
 dustrial miners are companies that operate large-scale
Time to Win The δ time to win is the δ percentile of mining facilities. Smaller miners that run private min-
the difference between the first time a node believes a ing rigs typically join forces and form mining pools. All
never-to-be-pruned-transition has occurred and the last members of a pool work together to mine each block,
time a (different) node disagrees, believing an alternative and share their revenues when one of them successfully
transition has occurred. It is zero if there are no disagree- mines a block.
ments, or if the latter time is earlier. Figure 5 illustrates To reflect in our setup the varying power of miners,
an example for the Bitcoin protocol. we examined the hash power distribution among Bitcoin
 mining entities. The information we require for the anal-
7 Experimental Setup
 ysis, the identity of the entities generating each block,
We evaluate Bitcoin and Bitcoin-NG with 1000-node ex- is voluntarily provided by miners. We used a public
periments running in real time on an emulated network. API [10] to gather this information for the year ending
 on August 31, 2015. We note that about 9% of the blocks
Implementation For Bitcoin we run the standard
 are unidentified. We considered each such block as gen-
client (release 0.10.0), hereinafter Bitcoin, with minimal
 erated by a different individual miner.
instrumentation to log sufficient information.
 For each week of the year, we calculate the weekly
 We implemented all Bitcoin-NG elements that are sig-
 mining power of each entity, and assign rank 1 to the
nificant for a performance analysis in the absence of an
 largest weekly mining power, rank 2 to the second
adversary, by modifying the standard Bitcoin client (re-
 largest, and so on. Figure 6 shows the weekly mining
lease 0.10.0). We did not implement the fee distribu-
 power of each entity by rank up to 20. Bars of the same
tion and the microblock signature check. Both elements
 shade at different ranks show the distribution of a spe-
have negligible impact on performance — fee distribu-
 cific week. Each batch of bars represents the collection
tion requires about one fixed point operation per trans-
 of ratios for the nth highest block generating pool. We
action and signature checking adds several milliseconds
 note that the ranks of different entities is not preserved
per microblock.
 throughout the weeks. The y-axis represents the weekly
Simulated Mining The time it takes a miner to find ratio of blocks generated by a pool.
a solution follows a geometric probability distribution, To model the size distribution of mining entities, we
which can be approximated as an exponential distribu- approximate it with an exponential distribution with an
tion due to the improbability of a success in each guess exponent of −0.27. It yields a 0.99 coefficient of deter-
and the rate of guessing. mination compared with the medians of each rank.
 In our experiments we replace the proof of work mech-
 Network The structure of Bitcoin’s overlay network
anism with a scheduler that triggers block generation at
 is complicated, and much of it is intentionally hidden
different miners with exponentially distributed intervals.
 to preserve Bitcoin’s security against denial of service
Mining Power The probability of mining a block is (DoS) and to maintain participants’ privacy. (Other
proportional on average to the mining power used for work [29, 41] discusses details on the peer-to-peer net-
solving the cryptopuzzle. Since blocks are generated work.) Nodes do not reveal their neighbors, but provide
at average set intervals and the total amount of min- superset of nodes they have discovered. Many of the
ing power is large, the interval between block genera- nodes are hidden behind firewalls making it difficult to
tion events of a small miner is extremely large. A single even estimate the full size of the network. The latency
home miner using dedicated hardware is unlikely to mine among nodes is unknown. Moreover, for many of the
a block for years [54]. metrics that we measure, a critical measure is the time it

52 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association

40 with the same set of transactions. The transactions are of
 35 Percentile 75
 Percentile 50 identical size; the operational Bitcoin system as of today,
 Latency [sec]
 30 Percentile 25 at 1MB blocks every 10 minutes, has a bandwidth of 3.5
 Propagation

 25
 such transactions per second.
 20
 15 8 Evaluation
 10
 5 We evaluate Bitcoin-NG and compare it with Bitcoin in
 0 two sets of experiments, varying block frequency and
 20k 40k 60k 80k 100k
 block size.
 Block Size [Byte]
 Overall, the experiments show that it is possible to
Figure 7: In our system, block propagation time grows improve Bitcoin’s consensus delay and bandwidth by
linearly with block size. This qualitatively matches the tuning its parameters, but its performance deteriorates
linear relation observed in measurements of the opera- dangerously on all security-related metrics. Bitcoin-NG
tional Bitcoin network [18]. qualitatively outperforms Bitcoin, as it suffers no such
 deterioration, while enjoying superior performance in al-
 most all metrics across the entire measured range. The
takes between the generation of a block by some miner bandwidth of Bitcoin-NG is only limited by the process-
and the time at which another miner starts mining on it. ing speed of the individual nodes, as higher throughput
The block not only has to be propagated and verified by does not introduce key-block forks. The consensus delay
the second miner, but that second miner must also prop- is determined directly by the network propagation time,
agate the details to its mining hardware. In the case of because in the common case all nodes agree on the main
mining pools with many distant worker miners, this may chain once they receive the latest key block.
incur a non-negligible delay. In the experiments that follow, we choose the 90th
 Lacking an existing model of the system, we construct percentile. Lower percentiles maintain the same trends,
a random network by connecting each node to at least 5 and very low percentiles show excellent performance –
other nodes, chosen uniformly at random. We measured there is always a small subset of nodes that has the cor-
the latency to all visible Bitcoin nodes from a single van- rect chain. However, with higher percentiles, the results
tage point on April 7th, 2015, and created a latency his- are lost in the noise. With 1000 nodes and at high per-
togram. We then set the latency among each pair of centiles, e.g., 99%, we are measuring the 10th slowest
nodes in the experiments based on this histogram. The node. Since there are always a few nodes that lag be-
bandwidth is set to about 100kbit/sec among each pair of hind, either consistently or temporarily, the results then
nodes. are dominated by this random behavior, and the trends
 To verify the validity of our setup and topology, we are not visible.
compare Bitcoin’s propagation properties in our setup We measure the metrics we introduced by instantiat-
and in the operational system. We perform experiments ing them to Nakamoto’s blockchain and to Bitcoin-NG
with different block sizes while changing the block fre- as follows.
quency so that the transaction-per-second load is con-
stant. Figure 7 shows a linear relation between the block Consensus delay We take the (90%, 90%)-consensus
size and the propagation time, similar to the linear re- delay based on block generation times. Point-con-
lation measured in the Bitcoin operational network by sensus-delay for Bitcoin is illustrated in Figure 4.
Decker and Wattenhofer [18]. As mentioned in Section 5, a user who requires
 high confidence (e.g., 99%) will not gain better la-
No Transaction Propagation The goal of this work is tency with Bitcoin-NG, and must wait for several
to optimize the consensus mechanism of the Blockchain. key blocks to accept a transaction as completed.
However, when generating blocks at high frequencies, The guarantees in such cases are similar to those
the overhead of filling in the blocks by generating and of Bitcoin with the same block interval as Bitcoin-
propagating transactions becomes a dominant factor with NG’s key-block interval.
Bitcoin’s current implementation. This is not an inherent
property of Bitcoin’s protocol, or of a Blockchain proto- Fairness We calculate the proportion of (1) the ratio of
col in general. To reduce the noise caused by the transac- blocks in the main chain not generated by the largest
tion generation and propagation mechanism, we reduce miner with respect to all blocks in the main chain,
transaction handling to the minimum. Before starting an and (2) the ratio of blocks not generated by the
experiment, we initialize the blockchain with artificial largest miner with respect to all generated blocks.
transactions and top up the mempools (the data struc- Mining power utilization We calculate the proportion
ture storing yet-to-be-serialized transactions) of all nodes between the aggregate work of the main chain

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 53

Bitcoin Time to prune For each node and for each branch, we
 Bitcoin-NG measure the time it took for the node to prune this
 4.5
 branch. This is the time between the receipt of the
 Transaction Frequency

 4
 3.5 first branch block and the receipt of the main chain
 3
 2.5
 block that is longer than this branch (Figure 5). We
 2 take the 90th percentile of all samples.
 1.5
 1 Time to win We take the 90th percentile of the time
 0.5
 0 from the generation of each main-chain block to the
 0.01 0.1 1
 last time another miner generates a block that is not
 Consensus Latency [sec]

 its descendant (Figure 5).
 100

 Experiments We run multiple experiments with differ-
 10
 ent parameters. The figures show the average value for
 each group of measurements with error bars marking the
 1 extreme values. The sampled values are shown as mark-
 0.01 0.1 1
 1 ers.
 0.9 For each execution we run for 50-100 Bitcoin blocks
 0.8
 or Bitcoin-NG microblocks. We perform multiple short
 Fairness

 0.7
 0.6 runs since all transactions are preloaded for each ex-
 0.5
 0.4
 ecution. The mean key-block interval in our experi-
 0.3 ments is 10 seconds, so each experiment includes leader
 0.2 changes. We do not consider cases where key-block
 0.01 0.1 1
 forks occur, since in reality one would choose a much
 Mining Power Utilization

 1
 0.9 larger key-block interval, e.g., 10 minutes, making key-
 0.8
 0.7 block forks extremely rare (more rare than with the op-
 0.6 erational Bitcoin system).
 0.5
 0.4
 0.3
 8.1 Block Frequency
 0.2
 0.01 0.1 1 First, we run experiments targeted at improving the con-
 45
 40 sensus delay. For Bitcoin, we vary the frequency of block
 Time to Win [sec]

 35 generation by reducing the proof-of-work difficulty. For
 (percentile 90)

 30
 25 Bitcoin-NG, keeping the key block generation at one ev-
 20 ery 100 seconds, we vary the frequency of microblock
 15
 10 generation. For each frequency, we choose the block
 5 size (microblock size for Bitcoin-NG) such that the pay-
 0
 0.01 0.1 1 load throughput is identical to that of Bitcoin’s opera-
 400
 350 tional system, that is, one 1MB block every 10 minutes.
 Time to Prune [sec]

 300 Figure 8 shows the results.
 (percentile 90)

 250
 200
 We confirm that the bandwidth, measured as transac-
 150 tion frequency, is close to 3.5, the operational Bitcoin
 100 rate of for such transactions. In our experiments, Bit-
 50
 0
 coin’s bandwidth is smaller than that of Bitcoin-NG, giv-
 0.01 0.1 1 ing Bitcoin an advantage with respect to the other met-
 Block Frequency [1/sec] rics.
 As expected, a higher block frequency reduces Bit-
 coin’s consensus latency as transactions are placed in the
 Figure 8: Reducing latency. ledger at a higher frequency. Time to prune improves
 significantly as block frequency increases. Nevertheless,
 Bitcoin’s frequent forks leave it with higher consensus
 latency and time to prune than Bitcoin-NG. We note that
 blocks and all blocks. In Bitcoin-NG, difficulty is although they can be made arbitrarily rare, key block
 only accrued in key blocks, so microblock forks do forks do occur. Such key-block forks are only resolved
 not reduce mining power utilization. once one branch has more key blocks than the others, re-

54 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association

sulting in a long time to prune if key block intervals are Bitcoin
long. Bitcoin-NG
 14
 Bitcoin’s mining power utilization drops quickly as

 Transaction Frequency
 12
frequency increases, tending towards 1/4, the size of the 10
largest miner. At the extreme, block generation is so 8
fast that by the time a miner learns of a block generated 6
by another miner, that other miner has generated more 4

blocks. Then, only the largest miner generates main 2
 0
chain blocks, and the other miners catch up. This also 1280 2.5k 5k 10k 20k 40k 80k
 250

 Consensus Latency [sec]
implies the deterioration of fairness, as forks are likely to
be resolved by the largest miner extending its preferred 200

branch. As miners struggle to catch up with the leading 150
pack, slow miners mine on old blocks and the time to win 100
metric increases. 50
 Since contention in Bitcoin-NG is limited to key block
 0
generation, forks remain rare despite high frequencies 1.1
 1280 2.5k 5k 10k 20k 40k 80k
of microblocks. Increasing the microblock frequency 1
achieves reduction of both consensus delay and time to 0.9
 0.8

 Fairness
prune. All other metrics are unaffected and remain at the 0.7
optimal level. 0.6
 In the low-frequency experiments of Bitcoin-NG, we 0.5
 0.4
observe a slight mining power utilization decrease and 0.3
time to prune increase. This is an artifact of the exper- 1
 1280 2.5k 5k 10k 20k 40k 80k
 Mining Power Utilization

imental setup. We run the experiments over a set num- 0.9
ber of blocks, therefore these low contention experiments 0.8

run for an extended period, enough to observe key block 0.7
 0.6
forks. Note, however, that a realistic Bitcoin-NG imple-
 0.5
mentation can space the key blocks much further apart 0.4
without affecting performance. Then, due to their small 0.3
size, key-block forks are highly unlikely, even more so 180
 1280 2.5k 5k 10k 20k 40k 80k

than with standard blocks of Nakamoto’s blockchain at 160
 Time to Win [sec]

 140
 (percentile 90)

the same rate, due to the small size of the key blocks. 120
 100
8.2 Block Size 80
 60
 40
To study bandwidth scalability, we run experiments with 20
different block sizes. We use high frequencies, simi- 0
 1280 2.5k 5k 10k 20k 40k 80k
 300
lar to those of Ethereum [12], setting Bitcoin’s block
 Time to Prune [sec]

 250
frequency to 1/10sec and Bitcoin-NG’s microblock fre-
 200
quency to 1/10sec and key block frequency to 1/100sec.
 150
Figure 9 shows the result.
 100
 As expected, the transaction frequency increases with
 50
block size; the horizontal line shows the operational Bit-
 0
coin rate. 1280 2.5k 5k 10k 20k 40k 80k
 Large blocks take longer to verify and propagate. Block Size [Byte, log scale]
Therefore, although block frequency is constant, the time
it takes for a miner to learn of a new block is longer, and
so the chance for forks increases. Figure 9: Increasing throughput.
 These experiments demonstrate the expected trade-off
between bandwidth and latency. Consensus latency in-
creases due to forks, as it takes longer to choose the main While this trade-off may be acceptable, allowing for
chain. The time to win also increases, as blocks take some hunt for a sweet spot on the trade-off curve, the
longer to catch up with the larger blocks, as does time to real problem pertains to security. The forks cause signif-
prune due to the many forks. icant mining power loss, reaching about 80% at Bitcoin’s

USENIX Association 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) 55

bandwidth (though at a higher block frequency), making However, in GHOST, blocks on pruned subtrees only
the system vulnerable to attackers that are much smaller. affect the selection rule at the branch point. The Bitcoin-
 Even more detrimental is the reduction in fairness. NG protocol maintains a small fork rate at high band-
Even a minor degradation in fairness is dangerous, since width and throughput, allowing for better mining power
it provides incentives to miners to avoid losses by join- utilization and fairness. Moreover, to use GHOST in an
ing forces to enjoy the advantage of mining in a larger operational system, a challenge remains. In Bitcoin, at
pool. This leads to centralization of the mining power, any given time, at least one node knows what the main
obviating Bitcoin’s security properties. chain is since it knows all of its blocks. In GHOST,
 Bitcoin-NG demonstrates qualitative improvement, this is not the case, and it is possible that no single node
suffering no significant degradation in the security- has enough information to determine which is the main
related metrics of fairness and mining power. Under chain. Our technical report [23] provides an example.
heavy load, however, the clients are approaching their One solution to finding the true main chain in GHOST
processing capacity, making it hard for them to keep up, is to propagate all blocks, or all block headers [51].
and we observe degradation in consensus latency and However, this exposes the system to denial-of-service at-
time to prune. tacks, as a malicious node can overwhelm the network
 with low-difficulty blocks. There may be heuristics to
9 Related Work avoid the security danger; we do not address this ques-
 tion, but have evaluated the system by implementing it,
Model As in Bitcoin [43] and enhancements
 propagating all blocks. Under these conditions, GHOST
thereof [56, 51, 36], the goal of Bitcoin-NG is to
 performs worse than Bitcoin as the overhead of propa-
implement an RSM in an open system. The exact
 gating all blocks outweighs the benefits of the chain se-
assumptions and guarantees are explored in different
 lection rule. Nevertheless, a practical implementation of
works [11, 40, 26]. Our model is similar to those of
 GHOST, overcoming remaining challenges, can be used
Aspnes et al. [2] and Garay et al. [26], and our definition
 to complement Bitcoin-NG and allow for a higher fre-
of Nakamoto Consensus is similar to that of Garay
 quency of key blocks.
et al. [26]. These are different from the model and
goal of classical Byzantine fault tolerant RSMs. The Inclusive Blockchains Lewenberg et al. [36] replace
latter, by and large, (1) assume static or slow-to-change the blockchain structure with a directed acyclic graph.
membership, allowing for quorum systems and recon- There still is a main chain, but its blocks may refer to
figurations thereof, and (2) do not guarantee fairness pruned branches to include their transactions. Analysis
of representation of honest parties in the state machine demonstrates considerable improvement of fairness and
transitions. mining power utilization. Bitcoin-NG achieves optimal
 The problem of leader election was apparently first fairness and mining power utilization. Using Bitcoin-NG
formulated and solved in 1977 by Gerard LeLann [34]. with an inclusive blockchain to increase key block fre-
In 1982, Hector Garcia-Molina addressed the problem in quency may prove problematic: Decommissioned lead-
a distributed system that admits failures [27]. Since then ers could retroactively introduce transactions and have
leader election has been extensively used to improve the them included by the current leader. This could allow for
performance of distributed systems (e.g., [20, 42]). In DoS and double-spending attacks.
these classical consensus protocols, the leader’s role is to
 Faster Bitcoin Significant effort by Bitcoin’s core de-
propose decisions that have to be confirmed by a quorum.
 velopers is put into improving the performance of the
This can be compared to blockchain protocols where the
 Bitcoin client and technical aspects of its protocol. While
block of a leader (as defined here) is confirmed in retro-
 this work can provide significant improvement and en-
spect by subsequent blocks of subsequent leaders.
 able better scaling, it does not eliminate the inherent lim-
GHOST The GHOST protocol of Sompolinsky et itation that stems from forks forming at high rates.
al. [51] improves on Bitcoin’s scalability by changing its Stathakopoulou et al. suggest reducing propagation
chain selection rule. While, in Bitcoin, the chain with the delay in the Bitcoin network [53]. However, their
most work (accumulated over all chain blocks, based on suggestions imply significant compromises on security.
their proofs of work) is the main chain, with GHOST, at First, they have nodes propagate transaction inventories
a fork, a node chooses the side whose sub-tree contains before they know the actual transactions in each inven-
more work (accumulated over all sub-tree blocks). The tory; this allows an attacker to swamp the network at no
benefit is that the heaviest sub-tree choice takes into ac- cost by publishing transaction IDs for non-existent trans-
count proof of work that does not end up in the main actions. Second, they form a network by having nodes
chain. Thus, GHOST improves both fairness and the prefer connections with close neighbors — exactly the
mining power utilization under high contention. opposite of the current security-oriented algorithm.

56 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’16) USENIX Association