Algorand: Scaling Byzantine Agreements

for Cryptocurrencies
Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, Nickolai Zeldovich
MIT CSAIL

ABSTRACT open setting: since anyone can participate, an adversary can

create an arbitrary number of pseudonyms (“Sybils”) [21],
Algorand is a new cryptocurrency that confirms transactions
making it infeasible to rely on traditional consensus proto-
with latency on the order of a minute while scaling to many
cols [15] that require a fraction of honest users.
users. Algorand ensures that users never have divergent
views of confirmed transactions, even if some of the users Bitcoin [41] and other cryptocurrencies [23, 53] address
are malicious and the network is temporarily partitioned. this problem using proof-of-work (PoW), where users must
In contrast, existing cryptocurrencies allow for temporary repeatedly compute hashes to grow the blockchain, and
forks and therefore require a long time, on the order of an the longest chain is considered authoritative. PoW ensures
hour, to confirm transactions with high confidence. that an adversary does not gain any advantage by creating
Algorand uses a new Byzantine Agreement (BA) protocol pseudonyms. However, PoW allows the possibility of forks,
to reach consensus among users on the next set of trans- where two different blockchains have the same length, and
actions. To scale the consensus to many users, Algorand neither one supersedes the other. Mitigating forks requires
uses a novel mechanism based on Verifiable Random Func- two unfortunate sacrifices: the time to grow the chain by one
tions that allows users to privately check whether they are block must be reasonably high (e.g., 10 minutes in Bitcoin),
selected to participate in the BA to agree on the next set and applications must wait for several blocks in order to
of transactions, and to include a proof of their selection in ensure their transaction remains on the authoritative chain
their network messages. In Algorand’s BA protocol, users (6 blocks are recommended in Bitcoin [7]). The result is that
do not keep any private state except for their private keys, it takes about an hour to confirm a transaction in Bitcoin.
which allows Algorand to replace participants immediately This paper presents Algorand, a new cryptocurrency de-
after they send a message. This mitigates targeted attacks signed to confirm transactions on the order of one minute.
on chosen participants after their identity is revealed. The core of Algorand uses a Byzantine agreement protocol
We implement Algorand and evaluate its performance on called BA⋆ that scales to many users, which allows Algo-
1,000 EC2 virtual machines, simulating up to 500,000 users. rand to reach consensus on a new block with low latency and
Experimental results show that Algorand confirms transac- without the possibility of forks. A key technique that makes
tions in under a minute, achieves 125× Bitcoin’s throughput, BA⋆ suitable for Algorand is the use of verifiable random
and incurs almost no penalty for scaling to more users. functions (VRFs) [38] to randomly select users in a private
and non-interactive way. BA⋆ was previously presented at a
1 INTRODUCTION workshop at a high level [37], and a technical report by Chen
and Micali [16] described an earlier version of Algorand.
Cryptographic currencies such as Bitcoin can enable new
Algorand faces three challenges. First, Algorand must
applications, such as smart contracts [24, 49] and fair pro-
avoid Sybil attacks, where an adversary creates many
tocols [2], can simplify currency conversions [12], and can
pseudonyms to influence the Byzantine agreement protocol.
avoid trusted centralized authorities that regulate transac-
Second, BA⋆ must scale to millions of users, which is far
tions. However, current proposals suffer from a trade-off
higher than the scale at which state-of-the-art Byzantine
between latency and confidence in a transaction. For exam-
agreement protocols operate. Finally, Algorand must be re-
ple, achieving a high confidence that a transaction has been
silient to denial-of-service attacks, and continue to operate
confirmed in Bitcoin requires about an hour long wait [7].
even if an adversary disconnects some of the users [29, 51].
On the other hand, applications that require low latency
cannot be certain that their transaction will be confirmed, Algorand addresses these challenges using several tech-
and must trust the payer to not double-spend [45]. niques, as follows.
Double-spending is the core problem faced by any cryp- Weighted users. To prevent Sybil attacks, Algorand as-
tocurrency, where an adversary holding $1 gives his $1 to two signs a weight to each user. BA⋆ is designed to guarantee
different users. Cryptocurrencies prevent double-spending consensus as long as a weighted fraction (a constant greater
by reaching consensus on an ordered log (“blockchain”) of than 2/3) of the users are honest. In Algorand, we weigh
transactions. Reaching consensus is difficult because of the users based on the money in their account. Thus, as long as

1
more than some fraction (over 2/3) of the money is owned by means transactions in Bitcoin take on the order of an hour
honest users, Algorand can avoid forks and double-spending. to be confirmed. Many follow-on cryptocurrencies adopt
Consensus by committee. BA⋆ achieves scalability by Bitcoin’s proof-of-work approach and inherit its limitations.
choosing a committee—a small set of representatives ran- The possibility of forks also makes it difficult for new users
domly selected from the total set of users—to run each step to bootstrap securely: an adversary that isolates the user’s
of its protocol. All other users observe the protocol mes- network can convince the user to use a particular fork of the
sages, which allows them to learn the agreed-upon block. blockchain [28].
BA⋆ chooses committee members randomly among all users By relying on Byzantine agreement, Algorand eliminates
based on the users’ weights. This allows Algorand to ensure the possibility of forks, and avoids the need to reason about
that a sufficient fraction of committee members are honest. mining strategies [8, 25, 46]. As a result, transactions are
However, relying on a committee creates the possibility of confirmed on the order of a minute. To make the Byzan-
targeted attacks against the chosen committee members. tine agreement robust to Sybil attacks, Algorand associates
Cryptographic sortition. To prevent an adversary from weights with users according to the money they hold. Other
targeting committee members, BA⋆ selects committee mem- techniques have been proposed in the past to resist Sybil
bers in a private and non-interactive way. This means that attacks in Byzantine-agreement-based cryptocurrencies, in-
every user in the system can independently determine if they cluding having participants submit security deposits and
are chosen to be on the committee, by computing a func- punishing those who deviate from the protocol [13].
tion (a VRF [38]) of their private key and public information
from the blockchain. If the function indicates that the user Byzantine consensus. Byzantine agreement protocols
is chosen, it returns a short string that proves this user’s have been used to replicate a service across a small group
committee membership to other users, which the user can of servers, such as in PBFT [15]. Follow-on work has shown
include in his network messages. Since membership selec- how to make Byzantine fault tolerance perform well and
tion is non-interactive, an adversary does not know which scale to dozens of servers [1, 17, 33]. One downside of Byzan-
user to target until that user starts participating in BA⋆. tine fault tolerance protocols used in this setting is that they
require a fixed set of servers to be determined ahead of time;
Participant replacement. Finally, an adversary may tar-
allowing anyone to join the set of servers would open up the
get a committee member once that member sends a message
protocols to Sybil attacks. These protocols also do not scale
in BA⋆. BA⋆ mitigates this attack by requiring committee
to the large number of users targeted by Algorand. BA⋆ is a
members to speak just once. Thus, once a committee member
Byzantine consensus protocol that does not rely on a fixed
sends his message (exposing his identity to an adversary),
set of servers, which avoids the possibility of targeted attacks
the committee member becomes irrelevant to BA⋆. BA⋆
on well-known servers. By weighing users according to their
achieves this property by avoiding any private state (except
currency balance, BA⋆ allows users to join the cryptocur-
for the user’s private key), which makes all users equally
rency without risking Sybil attacks, as long as the fraction of
capable of participating, and by electing new committee
the money held by honest users is at least a constant greater
members for each step of the Byzantine agreement protocol.
than 2/3. BA⋆’s design also allows it to scale to many users
We implement a prototype of Algorand and BA⋆, and use
(e.g., 500,000 shown in our evaluation) using VRFs to fairly
it to empirically evaluate Algorand’s performance. Experi-
select a random committee.
mental results running on 1,000 Amazon EC2 VMs demon-
Most Byzantine consensus protocols require more than
strate that Algorand can confirm a 1 MByte block of transac-
2/3 of servers to be honest, and Algorand’s BA⋆ inherits
tions in ∼22 seconds with 50,000 users, that Algorand’s la-
this limitation (in the form of 2/3 of the money being held
tency remains nearly constant when scaling to half a million
by honest users). BFT2F [35] shows that it is possible to
users, that Algorand achieves 125× the transaction through-
achieve “fork∗ -consensus” with just over half of the servers
put of Bitcoin, and that Algorand achieves acceptable latency
being honest, but fork∗ -consensus would allow an adver-
even in the presence of actively malicious users.
sary to double-spend on the two forked blockchains, which
Algorand avoids.
2 RELATED WORK Honey Badger [39] demonstrated how Byzantine fault tol-
Proof-of-work. Bitcoin [41], the predominant cryptocur- erance can be used to build a cryptocurrency. Specifically,
rency, uses proof-of-work to ensure that everyone agrees Honey Badger designates a set of servers to be in charge
on the set of approved transactions; this approach is of- of reaching consensus on the set of approved transactions.
ten called “Nakamoto consensus.” Bitcoin must balance the This allows Honey Badger to reach consensus within 5 min-
length of time to compute a new block with the possibil- utes and achieve a throughput of 200 KBytes/sec of data
ity of wasted work [41], and sets parameters to generate a appended to the ledger using 10 MByte blocks and 104 par-
new block every 10 minutes on average. Nonetheless, due ticipating servers. One downside of this design is that the
to the possibility of forks, it is widely suggested that users cryptocurrency is no longer decentralized; there are a fixed
wait for the blockchain to grow by at least six blocks be- set of servers chosen when the system is first configured.
fore considering their transaction to be confirmed [7]. This Fixed servers are also problematic in terms of targeted at-

2
tacks that either compromise the servers or disconnect them malicious users, but this is not required to prevent forks or
from the network. Algorand achieves better performance double spending.
(confirming transactions in about a minute, reaching similar Proof-of-stake avoids the computational overhead of
throughput) without having to choose a fixed set of servers proof-of-work and therefore allows reducing transaction con-
ahead of time. firmation time. However, realizing proof-of-stake in practice
Bitcoin-NG [26] suggests using the Nakamoto consensus is challenging [4]. Since no work is involved in generating
to elect a leader, and then have that leader publish blocks blocks, a malicious leader can announce one block, and then
of transactions, resulting in an order of magnitude of im- present some other block to isolated users. Attackers may
provement in latency of confirming transactions over Bitcoin. also split their credits among several “users”, who might
Hybrid consensus [30, 32, 42] refines the approach of using get selected as leaders, to minimize the penalty when a bad
the Nakamoto consensus to periodically select a group of leader is caught. Therefore some proof-of-stake cryptocur-
participants (e.g., every day), and runs a Byzantine agree- rencies require a master key to periodically sign the correct
ment between selected participants to confirm transactions branch of the ledger in order to mitigate forks [31]. This
until new servers are selected. This allows improving perfor- raises significant trust concerns regarding the currency, and
mance over standard Nakamoto consensus (e.g., Bitcoin); for has also caused accidental forks in the past [43]. Algorand
example, ByzCoin [32] provides a latency of about 35 sec- answers this challenge by avoiding forks, even if the leader
onds and a throughput of 230 KBytes/sec of data appended to turns out to be malicious.
the ledger with an 8 MByte block size and 1000 participants Ouroboros [30] is a recent proposal for realizing proof-of-
in the Byzantine agreement. Although Hybrid consensus stake. For security, Ouroboros assumes that honest users can
makes the set of Byzantine servers dynamic, it opens up the communicate within some bounded delay (i.e., a strongly
possibility of forks, due to the use of proof-of-work consen- synchronous network). Furthermore, it selects some users
sus to agree on the set of servers; this problem cannot arise to participate in a joint-coin-flipping protocol and assumes
in Algorand. that most of them are incorruptible by the adversary for
Pass and Shi’s paper [42] acknowledges that the Hybrid a significant epoch (such as a day). In contrast Algorand
consensus design is secure only with respect to a “mildly assumes that the adversary may temporarily fully control the
adaptive” adversary that cannot compromise the selected network and immediately corrupt users in targeted attacks.
servers within a day (the participant selection interval), and
explicitly calls out the open problem of handling fully adap- Trees and DAGs instead of chains. GHOST [47], SPEC-
tive adversaries. Algorand’s BA⋆ explicitly addresses this TRE [48], and Meshcash [5] are recent proposals for increas-
open problem by immediately replacing any chosen com- ing Bitcoin’s throughput by replacing the underlying chain-
mittee members. As a result, Algorand is not susceptible to structured ledger with a tree or directed acyclic graph (DAG)
either targeted compromises or targeted DoS attacks. structures, and resolving conflicts in the forks of these data
Stellar [36] takes an alternative approach to using Byzan- structures. These protocols rely on the Nakamoto consensus
tine consensus in a cryptocurrency, where each user can trust using proof-of-work. By carefully designing the selection
quorums of other users, forming a trust hierarchy. Consis- rule between branches of the trees/DAGs, they are able to
tency is ensured as long as all transactions share at least one substantially increase the throughput. In contrast, Algorand
transitively trusted quorum of users, and sufficiently many is focused on eliminating forks; in future work, it may be
of these users are honest. Algorand avoids this assumption, interesting to explore whether tree or DAG structures can
which means that users do not have to make complex trust similarly increase Algorand’s throughput.
decisions when configuring their client software.
3 GOALS AND ASSUMPTIONS
Proof of stake. Algorand assigns weights to users propor-
tionally to the monetary value they have in the system, in- Algorand allows users to agree on an ordered log of transac-
spired by proof-of-stake approaches, suggested as an alter- tions, and achieves two goals with respect to the log:
native or enhancement to proof-of-work [3, 10]. There is a Safety goal. With overwhelming probability, all users
key difference, however, between Algorand using monetary agree on the same transactions. More precisely, if one honest
value as weights and many proof-of-stake cryptocurrencies. user accepts transaction A (i.e., it appears in the log), then
In many proof-of-stake cryptocurrencies, a malicious leader any future transactions accepted by other honest users will
(who assembles a new block) can create a fork in the network, appear in a log that already contains A. This holds even for
but if caught (e.g., since two versions of the new block are isolated users that are disconnected from the network—e.g.,
signed with his key), the leader loses his money. The weights by Eclipse attacks [28].
in Algorand, however, are only to ensure that the attacker Liveness goal. In addition to safety, Algorand also makes
cannot amplify his power by using pseudonyms; as long as progress (i.e., allows new transactions to be added to the log)
the attacker controls less than 1/3 of the monetary value, under additional assumptions about network reachability
Algorand can guarantee that the probability for forks is neg- that we describe below. Algorand aims to reach consensus
ligible. Algorand may be extended to “detect and punish” on a new set of transactions within roughly one minute.

3
 Assumptions. Algorand makes standard cryptographic
assumptions such as public-key signatures and hash func-
tions. Algorand assumes that honest users run bug-free
software. As mentioned earlier, Algorand assumes that the
fraction of money held by honest users is above some thresh-
old h (a constant greater than 2/3), but that an adversary can
participate in Algorand and own some money. We believe
that this assumption is reasonable, since it means that in
order to successfully attack Algorand, the attacker must in-
vest substantial financial resources in it. Algorand assumes
that an adversary can corrupt targeted users, but that an
adversary cannot corrupt a large number of users that hold a
significant fraction of the money (i.e., the amount of money
Figure 1: An overview of transaction flow in Algorand.
held by honest, non-compromised users must remain over
the threshold).
BA⋆ executes in steps, communicates over the same gos-
To achieve liveness, Algorand makes a “strong synchrony” sip protocol, and produces a new agreed-upon block. BA⋆
assumption that most honest users (e.g., 95%) can send mes- can produce two kinds of consensus: final consensus and
sages that will be received by most other honest users (e.g., tentative consensus. If one user reaches final consensus,
95%) within a known time bound. This assumption allows this means that any other user that reaches final or tenta-
the adversary to control the network of a few honest users, tive consensus in the same round must agree on the same
but does not allow the adversary to manipulate the network block value (regardless of whether the strong synchrony
at a large scale, and does not allow network partitions. assumption held). This ensures Algorand’s safety, since this
Algorand achieves safety with a “weak synchrony” as- means that all future transactions will be chained to this
sumption: the network can be asynchronous (i.e., entirely final block (and, transitively, to its predecessors). Thus, Al-
controlled by the adversary) for a long but bounded period gorand confirms a transaction when the transaction’s block
of time (e.g., at most 1 day or 1 week). After an asynchrony (or any successor block) reaches final consensus. On the
period, the network must be strongly synchronous for a rea- other hand, tentative consensus means that other users may
sonably long period again (e.g., a few hours or a day) for have reached tentative consensus on a different block (as
Algorand to ensure safety. More formally, the weak syn- long as no user reached final consensus). A user will con-
chrony assumption is that in every period of length b (think firm a transaction from a tentative block only if and when a
of b as a day or a week), there must be a strongly synchronous successor block reaches final consensus.
period of length s < b (an s of a few hours suffices). BA⋆ produces tentative consensus in two cases. First,
Finally, Algorand assumes loosely synchronized clocks if the network is strongly synchronous, an adversary may,
across all users (e.g., using NTP) in order to recover liveness with small probability, be able to cause BA⋆ to reach tenta-
after weak synchrony. Specifically, the clocks must be close tive consensus on a block. In this case, BA⋆ will not reach
enough in order for most honest users to kick off the recovery consensus on two different blocks, but is simply unable to
protocol at approximately the same time. If the clocks are confirm that the network was strongly synchronous. Algo-
out of sync, the recovery protocol does not succeed. rand will eventually (in a few rounds) reach final consensus
on a successor block, with overwhelming probability, and
4 OVERVIEW thus confirm these earlier transactions.
Algorand requires each user to have a public key. Algorand The second case is that the network was only weakly
maintains a log of transactions, called a blockchain. Each synchronous (i.e., it was entirely controlled by the adversary,
transaction is a payment signed by one user’s public key with an upper bound on how long the adversary can keep
transferring money to another user’s public key. Algorand control). In this case, BA⋆ can reach tentative consensus
grows the blockchain in asynchronous rounds, similar to on two different blocks, forming multiple forks. This can in
Bitcoin. In every round, a new block, containing a set of turn prevent BA⋆ from reaching consensus again, because
transactions and a pointer to the previous block, is appended the users are split into different groups that disagree about
to the blockchain. In the rest of this paper, we refer to Algo- previous blocks. To recover liveness, Algorand periodically
rand software running on a user’s computer as that user. invokes BA⋆ to reach consensus on which fork should be used
going forward. Once the network regains strong synchrony,
Algorand users communicate through a gossip protocol.
this will allow Algorand to choose one of the forks, and then
The gossip protocol is used by users to submit new transac-
reach final consensus on a subsequent block on that fork.
tions. Each user collects a block of pending transactions that
We now describe how Algorand’s components fit together.
they hear about, in case they are chosen to propose the next
block, as shown in Figure 1. Algorand uses BA⋆ to reach Gossip protocol. Algorand implements a gossip network
consensus on one of these pending blocks. (similar to Bitcoin) where each user selects a small random

4
set of peers to gossip messages to. To ensure messages cannot
be forged, every message is signed by the private key of its
original sender; other users check that the signature is valid
before relaying it. To avoid forwarding loops, users do not
relay the same message twice. Algorand implements gossip
over TCP and weighs peer selection based on how much
money they have, so as to mitigate pollution attacks.
Block proposal (§6). All Algorand users execute crypto-
graphic sortition to determine if they are selected to propose
a block in a given round. We describe sortition in §5, but at
a high level, sortition ensures that a small fraction of users Figure 2: An overview of one step of BA⋆. To simplify
are selected at random, weighed by their account balance, the figure, each user is shown twice: once at the top of the
and provides each selected user with a priority, which can be diagram and once at the bottom. Each arrow color indicates
compared between users, and a proof of the chosen user’s a message from a particular user.
priority. Since sortition is random, there may be multiple
W = i w i , the probability that user i is selected is propor-
Í
users selected to propose a block, and the priority deter-
tional to w i /W . The randomness in the sortition algorithm
mines which block everyone should adopt. Selected users
comes from a publicly known random seed; we describe
distribute their block of pending transactions through the
later how this seed is chosen. To allow a user to prove that
gossip protocol, together with their priority and proof. To
they were chosen, sortition requires each user i to have a
ensure that users converge on one block with high probabil-
public/private key pair, (pki ,ski ).
ity, block proposals are prioritized based on the proposing
Sortition is implemented using verifiable random func-
user’s priority, and users wait for a certain amount of time
tions (VRFs) [38]. Informally, on any input string x, VRFsk (x)
to receive the block.
returns two values: a hash and a proof. The hash is a hashlen-
Agreement using BA⋆ (§7). Block proposal does not guar- bit-long value that is uniquely determined by sk and x, but
antee that all users received the same block, and Algorand is indistinguishable from random to anyone that does not
does not rely on the block proposal protocol for safety. To know sk. The proof π enables anyone that knows pk to check
reach consensus on a single block, Algorand uses BA⋆. Each that the hash indeed corresponds to x, without having to
user initializes BA⋆ with the highest-priority block that they know sk. For security, we require that the VRF provides
received. BA⋆ executes in repeated steps, illustrated in Fig- these properties even if pk and sk are chosen by an attacker.
ure 2. Each step begins with sortition (§5), where all users
5.1 Selection procedure
check whether they have been selected as committee mem-
bers in that step. Committee members then broadcast a Using VRFs, Algorand implements cryptographic sortition
message which includes their proof of selection. These steps as shown in Algorithm 1. Sortition requires a role parameter
repeat until, in some step of BA⋆, enough users in the com- that distinguishes the different roles that a user may be se-
mittee reach consensus. (Steps are not synchronized across lected for; for example, the user may be selected to propose
users; each user checks for selection as soon as he observes a block in some round, or they may be selected to be the
the previous step had ended.) As discussed earlier, an impor- member of the committee at a certain step of BA⋆. Algorand
tant feature of BA⋆ is that committee members do not keep specifies a threshold τ that determines the expected number
private state except their private keys, and so can be replaced of users selected for that role.
after every step, to mitigate targeted attacks on them.
Efficiency. When the network is strongly synchronous, procedure Sortition(sk, seed,τ , role,w,W ):
BA⋆ guarantees that if all honest users start with the same ⟨hash, π ⟩ ← VRFsk (seed||role)
initial block (i.e., the highest priority block proposer was hon- p ← Wτ
est), then BA⋆ establishes final consensus over that block j←0
and terminates precisely in 4 interactive steps between users. < kj =0 B(k;w,p), kj+1
hÍ 
B(k;w,p)
hash Í
while 2hashlen =0
do
Under the same network conditions, and in the worst case of j++
a particularly lucky adversary, all honest users reach consen- return ⟨hash, π , j⟩
sus on the next block within expected 13 steps, as analyzed
Algorithm 1: The cryptographic sortition algorithm.
in Appendix C.

5 CRYPTOGRAPHIC SORTITION It is important that sortition selects users in proportion to

Cryptographic sortition is an algorithm for choosing a ran- their weight; otherwise, sortition would not defend against
dom subset of users according to per-user weights; that Sybil attacks. One subtle implication is that users may be
is, given a set of weights w i and the weight of all users chosen more than once by sortition (e.g., because they have

5
a high weight). Sortition addresses this by returning the j 5.2 Choosing the seed
parameter, which indicates how many times the user was Sortition requires a seed that is chosen at random and pub-
chosen. Being chosen j times means that the user gets to licly known. For Algorand, each round requires a seed that
participate as j different “sub-users.” is publicly known by everyone for that round, but cannot be
To select users in proportion to their money, we consider controlled by the adversary; otherwise, an adversary may
each unit of Algorand as a different “sub-user.” If user i be able to choose a seed that favors selection of corrupted
owns w i (integral) units of Algorand, then simulated user users.
(i, j) with j ∈ {1, . . . ,w i } represents the j t h unit of currency In each round of Algorand a new seed is published. The
i owns, and is selected with probability p = Wτ , where W is seed published at Algorand’s round r is determined using
the total amount of currency units in Algorand. VRFs with the seed of the previous round r − 1. More specifi-
As shown in Algorithm 1, a user performs sortition by cally, during the block proposal stage of round r − 1, every
computing ⟨hash, π ⟩ ← V RFsk (seed||role), where sk is the user u selected for block proposal also computes a proposed
user’s secret key. The pseudo-random hash determines seed for round r as ⟨seedr , π ⟩ ← VRFsku (seedr −1 ||r ). Algo-
how many sub-users are selected, as follows. The prob- rand requires that sku be chosen by u well in advance of the
ability that exactly k out of the w (the user’s weight) seed for that round being determined (§5.3). This ensures that
sub-users are
selected follows the binomial distribution, even if u is malicious, the resulting seedr is pseudo-random.
B(k;w,p) = wk p k (1−p)w −k , where w k =0 B(k;w,p) = 1. Since This seed (and the corresponding VRF proof π ) is included
Í
B(k 1 ;n 1 ,p) + B(k 2 ;n 2 ,p) = B(k 1 + k 2 ;n 1 + n 2 ,p), splitting a in every proposed block, so that once Algorand reaches agree-
user’s weight (currency) among Sybils does not affect the ment on the block for round r − 1, everyone knows seedr at
number of selected sub-users under his/her control. the start of round r . If the block does not contain a valid seed
To determine how many of a user’s w sub-users (e.g., because the block was proposed by a malicious user
are selected, the sortition algorithm divides the inter- and included invalid transactions), users treat the entire pro-
val
hÍ [0, 1) into consecutive intervals of the form I j = posed block as if it were empty, and use a cryptographic hash
j
B(k;w,p), kj+1 function H (which we assume is a random oracle) to com-

B(k;w,p) for j ∈ {0, 1, . . . ,w }. If
Í
k =0 =0
pute the associated seed for round r as seedr = H(seedr −1 ||r ).
hash/2hashlen (where hashlen is the bit-length of hash) falls in The value of seed0 , which bootstraps seed selection, can be
the interval I j , then the user has exactly j selected sub-users. chosen at random at the start of Algorand by the initial partic-
The number of selected sub-users is publicly verifiable using ipants (after their public keys are declared) using distributed
the proof π (from the VRF output). random number generation [14].
Sortition provides two important properties. First, given a To limit the adversary’s ability to manipulate sortition,
random seed, the VRF outputs a pseudo-random hash value, and thus manipulate the selection of users for different com-
which is essentially uniformly distributed between 0 and mittees, the selection seed (passed to Algorithm 1 and Algo-
2hashlen − 1. As a result, users are selected at random based rithm 2) is refreshed once every R rounds. Namely, at round r
on their weights. Second, an adversary that does not know Algorand calls the sortition functions with seedr −1−(r mod R) .
ski cannot guess how many times user i is chosen, or if i was
chosen at all (more precisely, the adversary cannot guess any 5.3 Choosing sku well in advance of the seed
better than just by randomly guessing based on the weights). Computing seedr requires that every user’s secret key sku
The pseudocode for verifying a sortition proof, shown in is chosen well in advance of the selection seed used in
Algorithm 2, follows the same structure to check if that user that round, i.e., seedr −1−(r mod R) . When the network is not
was selected (the weight of the user’s public key is obtained strongly synchronous, the attacker has complete control over
from the ledger). The function returns the number of selected the links, and can therefore drop block proposals and force
sub-users (or zero if the user was not selected at all). users to agree on empty blocks, such that future selection
seeds can be computed. To mitigate such attacks Algorand
relies on the weak synchrony assumption (in every period
procedure VerifySort(pk, hash, π , seed,τ , role,w,W ): of length b, there must be a strongly synchronous period of
length s < b). Whenever Algorand performs cryptographic
if ¬VerifyVRFpk (hash, π , seed||role) then return 0;
sortition for round r , it checks the timestamp included in
p ← Wτ
the agreed-upon block for round r − 1 − (r mod R), and uses
j←0
j the keys (and associated weights) from the last block that
B(k;w,p), kj+1
hÍ 
B(k;w,p)
hash Í
while 2hashlen < k=0 =0
do was created b-time before block r − 1 − (r mod R). The lower
j++ bound s on the length of a strongly synchronous period
return j should allow for sufficiently many blocks to be created in
Algorithm 2: Pseudocode for verifying sortition of a user order to ensure with overwhelming probability that at least
with public key pk. one block was honest. This ensures that, as long as s is suit-
ably large, an adversary u choosing a key sku cannot predict
the seed for round r .

6
 This look-back period b has the following trade-off: a large other hand, waiting too long will receive all block proposals
b mitigates the risk that attackers are able break the weak but also unnecessarily increase the confirmation latency.
synchronicity assumption, yet it increases the chance that To determine the appropriate amount of time to wait for
users have transferred their currency to someone else and block proposals, we consider the plausible scenarios that a
therefore have nothing to lose if the system’s security breaks. user might find themselves in. When a user starts waiting for
This is colloquially known as the “nothing at stake” problem; block proposals for round r , they may be one of the first users
one possible way to avoid this trade-off, which we do not to reach consensus in round r − 1. Since that user completed
explore in Algorand, is to take the minimum of a user’s round r − 1, sufficiently many users sent a message for the
current balance and the user’s balance from the look-back last step of BA⋆ in that round, and therefore, most of the
block as the user’s weight. network is at most one step behind this user. Thus, the user
Appendix A formally analyzes the number of blocks that must somehow wait for others to finish the last step of BA⋆
Algorand needs to be created in the period s when the net- from round r − 1. At this point, some proposer in round r
work is strongly connected. We show that to ensure a small that happens to have the highest priority will gossip their
probability of failure F , the number of blocks is logarith- priority and proof message, and the user must somehow wait
mic in F1 , which allows us to obtain high security with a to receive that message. Then, the user can simply wait until
reasonably low number of required blocks. they receive the block corresponding to the highest priority
proof (with a timeout λ block , on the order of a minute, after
6 BLOCK PROPOSAL which the user will fall back to the empty block).
To ensure that some block is proposed in each round, Al- It is impossible for a user to wait exactly the correct
gorand sets the sortition threshold for the block-proposal amount for the first two steps of the above scenario. Thus,
role, τproposer , to be greater than 1 (although Algorand will Algorand estimates these quantities (λ stepvar , the variance
reach consensus on at most one of these proposed blocks). in how long it takes different users to finish the last step
Appendix B proves that choosing τproposer = 26 ensures that of BA⋆, and λ priority , the time taken to gossip the priority
a reasonable number of proposers (at least one, and no more and proof message), and waits for λ stepvar + λ priority time
than 70, as a plausible upper bound) are chosen with very to identify the highest priority. §10 experimentally shows
high probability (e.g., 1 − 10−11 ). that these parameters are, conservatively, 5 seconds each.
As mentioned above, Algorand would remain safe even if
Minimizing unnecessary block transmissions. One these estimates were inaccurate.
risk of choosing several proposers is that each will gossip
their own proposed block. For a large block (say, 1 MByte), Malicious proposers. Even if some block proposers are
this can incur a significant communication cost. To reduce malicious, the worst-case scenario is that they trick different
this cost, the sortition hash is used to prioritize block propos- Algorand users into initializing BA⋆ with different blocks.
als: For each selected sub-user 1, . . . , j of user i, the priority This could in turn cause Algorand to reach consensus on
for the block proposal is obtained by hashing the (verifiably an empty block, and possibly take additional steps in doing
random) hash output of VRF concatenated with the sub-user so. However, it turns out that even this scenario is relatively
index. The highest priority of all the block proposer’s se- unlikely. In particular, if the adversary is not the highest pri-
lected sub-users is the priority of the block. ority proposer in a round, then the highest priority proposer
Algorand users discard messages about blocks that do not will gossip a consistent version of their block to all users.
have the highest priority seen by that user so far. Algorand If the adversary is the highest priority proposer in a round,
also gossips two kinds of messages: one contains just the they can propose the empty block, and thus prevent any real
priorities and proofs of the chosen block proposers (from transactions from being confirmed. However, this happens
sortition), and the other contains the entire block, which also with probability of at most 1 −h, by Algorand’s assumption
includes the proposer’s sortition hash, and proof. The first that at least h > 2/3 of the weighted user are honest.
kind of message is small (about 200 Bytes), and propagates
quickly through the gossip network. These messages enable 7 BA⋆
most users to learn who is the highest priority proposer, and
The execution of BA⋆ consists of two phases. In the first
thus quickly discard other proposed blocks.
phase, BA⋆ reduces the problem of agreeing on a block to
Waiting for block proposals. Each user must wait a cer- agreement on one of two options. In the second phase, BA⋆
tain amount of time to receive block proposals via the gossip reaches agreement on one of these options: either agreeing
protocol. Choosing this time interval does not impact Algo- on a proposed block, or agreeing on an empty block.
rand’s safety guarantees but is important for performance. Each phase consists of several interactive steps; the first
Waiting a short amount of time will mean no received pro- phase always takes two steps, and the second phase takes
posals. If the user receives no block proposals, he or she two steps if the highest-priority block proposer was honest
initializes BA⋆ with the empty block, and if many users do (sent the same block to all users), and as we show in our
so, Algorand will reach consensus on an empty block. On the analysis an expected 11 steps in the worst case of a malicious

7
highest-priority proposer colluding with a large fraction of procedure CommitteeVote(ctx, round, step,τ , value):
committee participants at every step.
// check if user is in committee using Sortition (Alg. 1)
In each step, every committee member casts a vote for
role ← ⟨“committee”, round, step⟩
some value, and all users count the votes. Users that receive
⟨sorthash, π , j⟩ ← Sortition(user.sk, ctx.seed,τ , role,
more than a threshold of votes for some value will vote
ctx.weight[user.pk], ctx.W )
for that value in the next step (if selected as a committee
// only committee members originate a message
member). If the users do not receive enough votes for any
if j > 0 then
value, they time out, and their choice of vote for the next
Gossip(⟨user.pk, Signeduser.sk (round, step,
step is determined by the step number.
sorthash, π ,H (ctx.last_block), value)⟩)
In the common case, when the network is strongly syn-
chronous and the highest-priority block proposer was hon- Algorithm 4: Voting for value by committee members.
est, BA⋆ reaches final consensus by using its final step to user.sk and user.pk are the user’s private and public keys.
confirm that there cannot be any other agreed-upon block
in the same round. Otherwise, BA⋆ may declare tentative 7.2 Voting
consensus if it cannot confirm the absence of other blocks Sending votes (Algorithm 4). Algorithm 4 shows the
due to possible network asynchrony. pseudocode for CommitteeVote(), which checks if the user
A key aspect of BA⋆’s design is that it keeps no secrets, is selected for the committee in a given round and step of
except for user private keys. This allows any user observing BA⋆. The CommitteeVote() procedure invokes Sortition()
the messages to “passively participate” in the protocol: verify from Algorithm 1 to check if the user is chosen to partici-
signatures, count votes, and reach the agreement decision. pate in the committee. If the user is chosen for this step, the
7.1 Main procedure of BA⋆ user gossips a signed message containing the value passed to
The top-level procedure implementing BA⋆, as invoked by CommitteeVote(), which is typically the hash of some block.
Algorand, is shown in Algorithm 3. The procedure takes a To bind the vote to the context, the signed message includes
context ctx, which captures the current state of the ledger, a the hash of the previous block.
round number, and a new proposed block, from the highest- Counting votes (Algorithm 5 and Algorithm 6). The
priority block proposer (§6). Algorand is responsible for CountVotes() procedure (Algorithm 5) reads messages that
ensuring that the block is valid (by checking the proposed belong to the current round and step from the incomingMsgs
block’s contents and using an empty block if it is invalid, buffer. (For simplicity, our pseudocode assumes that a back-
as described in §8). The context consists of the seed for ground procedure takes incoming votes and stores them into
sortition, the user weights, and the last agreed-upon block. that buffer, indexed by the messages’ round and step.) It pro-
For efficiency, BA⋆ votes for hashes of blocks, instead of cesses the votes by calling the ProcessMsg() procedure for
entire block contents. At the end of the BA⋆ algorithm, we every message (Algorithm 6), which ensures that the vote is
use the BlockOfHash() function to indicate that, if BA⋆ has valid. Note that no private state is required to process these
not yet received the pre-image of the agreed-upon hash, it messages.
must obtain it from other users (and, since the block was ProcessMsg() returns not just the value contained in the
agreed upon, many of the honest users must have received message, but also the number of votes associated with that
it during block proposal). value. If the message was not from a chosen committee
The BA⋆ algorithm also determines whether it established member, ProcessMsg() returns zero votes. If the committee
final or tentative consensus. We will discuss this check in member was chosen several times (see §5), the number of
detail when we discuss Algorithm 8. votes returned by ProcessMsg() reflects that as well. Pro-
cessMsg() also returns the sortition hash, which we will use
later in Algorithm 9.
procedure BA⋆(ctx, round, block):
As soon as one value has more than T · τ votes,
hblock ← Reduction(ctx, round,H (block)) CountVotes() returns that value. τ is the expected num-
hblock⋆ ← BinaryBA⋆(ctx, round, hblock) ber of users that Sortition() selects for the committee, and is
// Check if we reached “final” or “tentative” consensus the same for each step (τstep ) with the exception of the final
r ← CountVotes(ctx, round, final,Tfinal ,τfinal ,λ step ) step (τfinal ). T is a fraction of that expected committee size
if hblock⋆ = r then (T > 23 ) that defines BA⋆’s voting threshold; this is also the
return ⟨final, BlockOfHash(hblock⋆ )⟩ same for every step except the final step, and we analyze it in
else §7.5. If not enough messages were received within the allo-
return ⟨tentative, BlockOfHash(hblock⋆ )⟩ cated λ time window, then CountVotes() produces timeout.
Algorithm 3: Running BA⋆ for the next round, with a The threshold ensures that if one honest user’s CountVotes()
proposed block. H is a cryptographic hash function. returns a particular value, then all other honest users will
return either the same value or timeout, even under the
weak synchrony assumption (see Lemma 1 in Appendix C.2).

8
 procedure CountVotes(ctx, round, step,T ,τ ,λ): procedure Reduction(ctx, round, hblock):
start ← Time() // step 1: gossip the block hash
counts ← {} // hash table, new keys mapped to 0 CommitteeVote(ctx, round, reduction_one,
voters ← {} τstep , hblock)
msgs ← incomingMsgs[round, step].iterator() // other users might still be waiting for block proposals,
while True do // so set timeout for λ block + λ step
m ← msgs.next() hblock1 ← CountVotes(ctx, round, reduction_one,
if m = ⊥ then Tstep ,τstep ,λ block + λ step )
if Time() > start + λ then return timeout; // step 2: re-gossip the popular block hash
else empty_hash ← H (Empty(round,H (ctx.last_block)))
⟨votes, value, sorthash⟩ ← ProcessMsg(ctx,τ ,m) if hblock1 = timeout then
if pk ∈ voters or votes = 0 then continue; CommitteeVote(ctx, round, reduction_two,
voters ∪ = {pk} τstep , empty_hash)
counts[value] + = votes else
// if we got enough votes, then output this value CommitteeVote(ctx, round, reduction_two,
if counts[value] > T · τ then τstep , hblock1 )
return value hblock2 ← CountVotes(ctx, round, reduction_two,
Tstep ,τstep ,λ step )
Algorithm 5: Counting votes for round and step. if hblock2 = timeout then return empty_hash ;
else return hblock2 ;
procedure ProcessMsg(ctx,τ ,m): Algorithm 7: The two-step reduction.
⟨pk, signed_m⟩ ← m
if VerifySignature(pk, signed_m) , OK then On the other hand, if the highest-priority block proposer
return ⟨0, ⊥, ⊥⟩ was dishonest, different users may start Reduction() with
⟨round, step, sorthash, π , hprev, value⟩ ← signed_m different hblock parameters. In this case, no single hblock
// discard messages that do not extend this chain value may be popular enough to cross the threshold of votes.
if hprev , H (ctx.last_block) then return ⟨0, ⊥, ⊥⟩; As a result, Reduction() will return empty_hash.
votes ← VerifySort(pk, sorthash, π , ctx.seed,τ , 7.4 Binary agreement
⟨“committee”, round, step⟩, ctx.weight[pk], ctx.W )
return ⟨votes, value, sorthash⟩ Algorithm 8 shows BinaryBA⋆(), which reaches consensus
on one of two values: either the hash passed to BinaryBA⋆()
Algorithm 6: Validating incoming vote message m.
or the hash of the empty block. BinaryBA⋆() relies on Re-
duction() to ensure that at most one non-empty block hash
7.3 Reduction is passed to BinaryBA⋆() by all honest users.
The Reduction() procedure, shown in Algorithm 7, converts Safety with strong synchrony. In each step of
the problem of reaching consensus on an arbitrary value BinaryBA⋆(), a user who has seen more than T · τ
(the hash of a block) to reaching consensus on one of two votes for some value will vote for that same value in the
values: either a specific proposed block hash, or the hash next step (if selected). However, if no value receives enough
of an empty block. Our reduction is inspired by Turpin and votes, BinaryBA⋆() chooses the next vote in a way that
Coan’s two-step technique [50]. This reduction is important ensures consensus in a strongly synchronous network.
to ensure liveness. Specifically, user A may receive votes from an adversary
In the first step of the reduction, each committee member that push the votes observed by A past the threshold, but
votes for the hash of the block passed to Reduction() by the adversary might not send the same votes to other users
BA⋆(). In the second step, committee members vote for (or might not send them in time). As a result, A returns
the hash that received at least T · τ votes in the first step, consensus on a block, but other users timed out in that step.
or the hash of the default empty block if no hash received It is crucial that BinaryBA⋆() chooses the votes for the next
enough votes. Reduction() ensures that there is at most one step in a way that will match the block already returned by
non-empty block that can be returned by Reduction() for all A. Algorithm 8 follows this rule: every return statement
honest users. is coupled with a check for timeout that sets the next-step
In the common case when the network is strongly syn- vote to the same value that could have been returned.
chronous and the highest-priority block proposer was hon- It is also crucial that BinaryBA⋆() is able to collect enough
est, most (e.g., 95%) of the users will call Reduction() with votes in the next step to carry forward the value that A
the same hblock parameter, and Reduction() will return that already reached consensus on. If there are many users like
same hblock result to most users as well. A that have already returned consensus, BinaryBA⋆() may

9
 procedure BinaryBA⋆(ctx, round, block_hash): votes. In this case, A will return consensus on block_hash,
but all other users will move on to the next step. Now, the
step ← 1
other users vote for block_hash again, because CountVotes()
r ← block_hash
returned timeout. However, let’s assume the network drops
empty_hash ← H (Empty(round,H (ctx.last_block)))
all of these votes. Finally, the users vote for empty_hash
while step < MaxSteps do
in the third step, the network becomes well behaved, and
CommitteeVote(ctx, round, step, τstep , r)
all votes are delivered. As a result, the users will keep vot-
r ← CountVotes(ctx, round, step,Tstep ,τstep ,λ step )
ing for empty_hash until the next iteration of the loop, at
if r = timeout then
r ← block_hash which point they reach consensus on empty_hash. This is
undesirable because BinaryBA⋆() returned consensus on two
else if r , empty_hash then
different hashes to different honest users.
for step < s ′ ≤ step + 3 do
CommitteeVote(ctx, round, s ′, τstep , r ) BA⋆() addresses this problem by introducing the notion
if step = 1 then of final and tentative consensus. Final consensus means that
CommitteeVote(ctx, round, final, τfinal , r ) BA⋆() will not reach consensus on any other block for that
return r round. Tentative consensus means that BA⋆() was unable to
step++ guarantee safety, either because of network asynchrony or
due to a malicious block proposer.
CommitteeVote(ctx, round, step, τstep , r)
r ← CountVotes(ctx, round, step,Tstep ,τstep ,λ step ) BA⋆() designates consensus on value V as “final” if
if r = timeout then BinaryBA⋆() reached consensus on V in the very first step,
r ← empty_hash and if enough users observed this consensus being reached.
Specifically, BinaryBA⋆() sends out a vote for the special
else if r = empty_hash then
final step to indicate that a user reached consensus on some
for step < s ′ ≤ step + 3 do
CommitteeVote(ctx, round, s ′, τstep , r ) value in the very first step, and BA⋆() collects these votes
return r to determine whether final consensus was achieved. In a
step++ strongly synchronous network with an honest block pro-
poser, BinaryBA⋆() will reach consensus in the first step,
CommitteeVote(ctx, round, step, τstep , r) most committee members will vote for the consensus block
r ← CountVotes(ctx, round, step,Tstep ,τstep ,λ step ) in the special final step in BinaryBA⋆(), and will receive
if r = timeout then more than a threshold of such votes in BA⋆(), thus declaring
if CommonCoin(ctx, round, step,τstep ) = 0 then the block as final. The final step is analogous to the final
r ← block_hash confirmation step implemented in many Byzantine-resilient
else protocols [15, 34].
r ← empty_hash
Intuitively, this guarantees safety because a large thresh-
step++ old of users have already declared consensus for V , and will
// No consensus after MaxSteps; assume network not vote for any other value in the same round. In our ex-
// problem, and rely on §8.2 to recover liveness. ample above, where user A reached consensus on a different
HangForever() block than all other users, neither block would be designated
Algorithm 8: BinaryBA⋆ executes until consensus is as final, because only one user (namely, A) observed consen-
reached on either block_hash or empty_hash. sus at the first step, and there would never be enough votes
to mark that block as final. Appendix C.1 formalizes and
not have enough users to push CountVotes() in the next step proves this safety property.
past the threshold. To avoid this problem, whenever a user One subtle issue arises due to the fact that BA⋆ relies on
returns consensus, that user votes in the next three steps a committee to declare final consensus, instead of relying on
with the value they reached consensus on. all participants. As a result, even if one user observes final
In the common case, when the network is strongly syn- consensus, an adversary that controls the network may be
chronous and the block proposer was honest, BinaryBA⋆() able to prevent a small fraction of other users from reaching
will start with the same block_hash for most users, and will any kind of consensus (final or tentative) for an arbitrary
reach consensus in the first step, since most committee mem- number of steps. Each of these steps give the adversary
bers vote for the same block_hash value. an additional small probability of reaching consensus on a
different value (e.g., the empty block). To bound the total
Safety with weak synchrony. If the network is not probability of an adversary doing so, BA⋆ limits the total
strongly synchronous (e.g., there is a partition), BinaryBA⋆() number of allowed steps; Appendix C.1 relies on this. If the
may return consensus on two different blocks. For example, protocol runs for more than MaxSteps steps, BA⋆ halts with-
suppose that, in the first step of BinaryBA⋆(), all users vote out consensus and relies on the recovery protocol described
for block_hash, but only one honest user, A, receives those in §8.2 to recover liveness.

10
 procedure CommonCoin(ctx, round, step, τ ): 4500
5·10^-9
minhash ← 2hashlen 4000
for m ∈ incomingMsgs[round, step] do 3500
⟨votes, value, sorthash⟩ ← ProcessMsg(ctx,τ ,m)

Committee Size
3000
for 1 ≤ j < votes do 2500
h ← H (sorthash||j) 2000
if h < minhash then minhash ← h; 1500
return minhash mod 2 1000
Algorithm 9: Computing a coin common to all users. 500
0

76

78

80

82

84

86

88

90
Getting unstuck. One remaining issue is that consensus % of Honest Users
could get stuck if the honest users are split into two groups,
A and B, and the users in the two groups vote for different Figure 3: The committee size, τ , sufficient to limit the proba-
values (say, we are in step 1, A votes for empty_hash, and bility of violating safety to 5×10−9 . The x-axis specifies h, the
B votes for block_hash). Neither group is large enough to weighted fraction of honest users. ⋆ marks the parameters
gather enough votes on their own, but together with the selected in our implementation.
adversary’s votes, group A is large enough. In this situation,
the adversary can determine what every user will vote for in with the lowest hash is honest, then all users that received
the next step. To make some user vote for empty_hash in the his message observe the same coin.
next step, the adversary sends that user the adversary’s own If a malicious committee-member happens to hold the
votes for empty_hash just before the timeout expires, which, lowest hash, then he might send it to only some users. This
together with A’s votes, crosses the threshold. To make the may result in users observing different coin values, and thus
user vote for block_hash, the adversary does not send any will not help in reaching consensus. However, since sor-
votes to that user; as a result, that user’s CountVotes() will tition hashes are pseudo-random, the probability that an
return timeout, and the user will choose block_hash for the honest user has the lowest hash is h (the fraction of money
next step’s vote, according to the BinaryBA⋆() algorithm. held by honest users), and thus there is at least an h > 23
This way, the adversary can split the users into two groups probability that the lowest sortition hash holder will be hon-
in the next step as well, and continue this attack indefinitely. est, which leads to consensus with probability 12 · h > 13 at
The attack described above requires the adversary to each loop iteration. This allows Appendix C.3 to show that,
know how a user will vote after receiving timeout from with strong synchrony, BA⋆ does not exceed MaxSteps with
CountVotes(). The third step of BinaryBA⋆() is designed overwhelming probability.
to avoid this attack by pushing towards accepting either
block_hash or empty_hash based on a random “common coin,” 7.5 Committee size
meaning a binary value that is predominantly the same for The fraction h > 32 of weighted honest users in Algorand
all users. Although this may sound circular, the users need must translate into a “sufficiently honest” committee for
not reach formal consensus on this common coin. As long as BA⋆. BA⋆ has two parameters at its disposal: τ , which con-
enough users observe the same coin bit, and the bit was not trols the expected committee size, and T , which controls the
known to the attacker in advance of the step, BinaryBA⋆() number of votes needed to reach consensus (T ·τ ). We would
will reach consensus in the next iteration of the loop with like T to be as small as possible for liveness, but the smaller
probability 1/2 (i.e., the probability that the attacker guessed T is, the larger τ needs to be, to ensure that an adversary
wrong). By repeating these steps, the probability of consen- does not obtain enough votes by chance. Since a larger com-
sus quickly approaches 1. mittee translates into a higher bandwidth cost, we choose
To implement this coin we take advantage of the VRF- two different parameter sets: Tfinal and τfinal for the final
based committee member hashes attached to all of the mes- step, which ensures an overwhelming probability of safety
sages. Every user sets the common coin to be the least- regardless of strong synchrony, and Tstep and τstep for all
significant bit of the lowest hash it observed in this step, other steps, which achieve a reasonable trade-off between
as shown in Algorithm 9. If a user gets multiple votes (i.e., liveness, safety, and performance.
several of their sub-users were selected), then Common- To make the constraints on τstep and Tstep precise, let us
Coin() considers multiple hashes from that user, by hashing denote the number of honest committee members by д and
that user’s sortition hash with the sub-user index. Notice the malicious ones by b; in expectation, b +д = τstep , but b +д
that hashes are random (since they are produced by hashing can vary since it is chosen by sortition. To ensure liveness, as
the pseudo-random VRF output), so their least-significant we prove in Appendix C.2, BA⋆ requires 12 д +b ≤ Tstep ·τstep
bits are also random. The common coin is used only when and д > Tstep · τstep .
CountVotes() times out, giving sufficient time for all votes to Due to the probabilistic nature of how committee members
propagate through the network. If the committee member are chosen, there is always some small chance that the b and

11
д for some step fail to satisfy the above constraints, and the other (the one with the higher round number r 2 ), since
BA⋆’s goal is to make this probability negligible. Figure 3 there must be some predecessor of the r 2 block in round r 1 ,
plots the expected committee size τstep that is needed to and the safety condition guarantees that the r 1 block is the
satisfy both constraints, as a function of h, for a probability of only possible such block.
violation of 5 × 10−9 ; Appendix B describes this computation The remaining issue is that, if the network is not strongly
in more detail. The figure shows a trade-off: the weaker the synchronous, BA⋆ may create forks (i.e., different users reach
assumption on the fraction of money held by honest users consensus on different blocks). This does not violate safety,
(h), the larger the committee size needs to be. The results because BA⋆ will return tentative consensus in this situation.
show that, as h approaches 23 , the committee size grows However, forks do impact liveness: users on different forks
quickly. However, at h = 80%, τstep = 2, 000 can ensure that will have different ctx.last_block values, which means they
these constraints hold with probability 1 − 5 × 10−9 (using will not count each others’ votes. As a result, at least one of
Tstep = 0.685). the forks (and possibly all of the forks) will not have enough
The constraints on τfinal and Tfinal are dictated by the participants to cross the vote threshold, and BA⋆ will not be
proof of safety under weak synchrony; Appendix C.1 shows able to reach consensus on any more blocks on that fork.
that τfinal = 10, 000 suffices with Tfinal = 0.74. To resolve these forks, Algorand periodically proposes a
With these parameters, BA⋆ ensures safety even if the fork that all users should agree on, and uses BA⋆ to reach
lowest-priority block proposer is malicious (proposes dif- consensus on whether all users should, indeed, switch to
ferent blocks). Appendix C provides proofs of BA⋆’s safety this fork. To determine the set of possible forks, Algorand
under weak synchrony (§C.1), liveness under strong syn- users passively monitor all BA⋆ votes (i.e., even votes whose
chrony (§C.2), and efficiency (§C.3). prev_hash value does not match the current user’s chain),
and keep track of all forks. Users then use loosely synchro-
8 ALGORAND nized clocks to stop regular block processing and kick off the
Building Algorand on top of the primitives we have described recovery protocol at every time interval (e.g., every hour),
so far requires Algorand to address a number of higher-level which will propose one of these forks as the fork that every-
issues, which this section discusses. one should agree on.
8.1 Block format The recovery protocol starts by having users propose a
fork using the block proposal mechanism (§6). Specifically,
Algorand’s blocks consist of a list of transactions, along
if a user is chosen to be a “fork proposer,” that user proposes
with metadata needed by BA⋆. Specifically, the metadata
an empty block whose predecessor hash is the longest fork
consists of the round number, the proposer’s VRF-based
(by the number of blocks) observed by the user so far. Each
seed (§6), a hash of the previous block in the ledger, and a
user waits for the highest-priority fork proposal, much as
timestamp indicating when the block was proposed. The
in the block proposal mechanism. Each user validates the
list of transactions in a block logically translates to a set
proposed block, by ensuring that the block’s parent pointer
of weights for each user’s public key (based on the balance
is a chain that is as long as the longest chain seen by that
of currency for that key), along with the total weight of all
user. Choosing the longest fork ensures that this fork will
outstanding currency.
include all final blocks. Finally, the user invokes BA⋆ to
Once a user receives a block from the highest-priority pro-
reach consensus on this block, passing the round number
poser, the user validates the block contents before passing it
found in the proposed block.
on to BA⋆. In particular, the user checks that all transactions
are valid; that the seed is valid; that the previous block hash In order for BA⋆ to reach consensus on one of the forks,
is correct; that the block round number is correct; and that all Algorand users must use the same seed and user weights.
the timestamp is greater than that of the previous block and This means that Algorand must use user weights and seeds
also approximately current (say, within an hour). If any of from before any possible forks occurred. To do this, Algorand
them are incorrect, the user passes an empty block to BA⋆. relies on the weak synchrony assumption—namely, that in
every period of length b (think of b as 1 day), there must
8.2 Safety and liveness be a strongly synchronous period of length s < b (think of
To a large extent, Algorand relies on BA⋆ to reach consensus s as a few hours). Under this assumption, using the block
on blocks in the ledger. Algorand confirms transactions only timestamps, Algorand quantizes time into b-long periods
when they appear in a final block, or in the predecessor of a (think days), and finds the most recent block from the next-
final block. Final blocks guarantee that no other block could to-last complete b-long period. Algorand then uses the seed
have reached consensus in the same round. This means from this block, and uses user weights from the last block
that all final blocks are totally ordered with respect to one that was agreed upon at least b-long time before it (§5.3).
another, since (1) blocks form a linear chain, and (2) there can Algorand takes the seed from the block from the next-
be exactly one final block at any given position in the chain. to-last b-long period because the most recent b-long period
In other words, given two final blocks, one of them (the one may still have an unresolved fork. Such a fork would prevent
with the smaller round number r 1 ) must be a predecessor of users from agreeing on the seed and weights used in the

12
recovery. However, as long as Algorand can recover within number. For τstep > 1, 000, the probability of this attack is
the s-long strongly synchronous period in the most recent less than 2−166 at every step, making this attack infeasible.
b-long period, all users will agree on the same block from
Storage. The block history and matching certificates allow
the next-to-last period (as long as their clocks are roughly
new users to catch-up, and are not required for users who
synchronized).
are already up-to-date with the current ledger. Therefore Al-
To ensure that Algorand recovers from a fork (i.e., most gorand distributes certificate and block storage across users.
honest users switch to the same fork) within the s-long syn- For N shards, users store blocks/certificates whose round
chronous period, Algorand users repeatedly attempt to reach number equals their public key modulo N.
consensus on a fork (applying a hash function to the seed
each time to produce a different set of proposers and com- 8.4 Communication
mittee members), until they achieve consensus. Since, by Gossiping blocks and relaying messages. Algorand’s
assumption, Algorand is operating in a strongly synchronous block proposal protocol (§6) assumed that chosen users can
period, it is not important whether BA⋆ returns “final” or gossip new blocks before an adversary can learn the user’s
“tentative” consensus in this case. When Algorand is recov- identity and mount a targeted DoS attack against them. In
ering outside of a strongly synchronous period, we cannot practice, Algorand’s blocks are larger than the maximum
ensure recovery within s time. packet size, so it is inevitable that some packets from a cho-
sen block proposer will be sent before others. A particularly
8.3 Bootstrapping fast adversary could take advantage of this to immediately
Bootstrapping the system. To deploy Algorand, a com- DoS any user that starts sending multiple packets, on the
mon genesis block must be provided to all users, along with presumption that the user is a block proposer.
the initial cryptographic sortition seed. The value of seed0 Formally, this means that Algorand’s liveness guarantees
specified in the genesis block is decided using distributed are slightly different in practice: instead of providing liveness
random number generation [14], after the public keys and in the face of immediate targeted DoS attacks, Algorand
weights for the initial set of participants are publicly known. ensures liveness as long as an adversary cannot mount a
targeted DoS attack within the time it takes for the victim
Bootstrapping new users. Users that join the system need to send a block over a TCP connection (a few seconds). We
to learn the current state of the system, which is defined to believe this does not matter significantly; an adversary with
be the result of a chain of BA⋆ consensus outcomes. To such a quick reaction time likely also has broad control over
help users catch up, Algorand generates a certificate for ev- the network, and thus can prevent Algorand nodes from
ery block that was agreed upon by BA⋆ (including empty communicating at all. Another approach may be to rely
blocks). The certificate is an aggregate of the votes from the on Tor [19] to make it difficult for an adversary to quickly
last step of BinaryBA⋆() (not including the final step) that disconnect a user.
would be sufficient to allow any user to reach the same con- To avoid an adversary from sending garbage messages and
clusion by processing these votes (i.e., there must be at least overwhelming Algorand’s gossip network, Algorand nodes
⌊Tstep · τstep ⌋ + 1 votes). Importantly, the users must check must validate messages before relaying them. Specifically,
the sortition hashes and proofs just like in Algorithm 6, and Algorand nodes should validate each message using Algo-
that all messages in the certificate are for the same Algorand rithm 6, and avoid relaying more than one message signed
round and BA⋆ step. by a given public key per ⟨round, step⟩.
Certificates allow new users to validate prior blocks. Users Scalability. The communication costs for each user depend
validate blocks in order, starting from the genesis block. This on the expected size of the committee and the number of
ensures that the user knows the correct weights for verifying block proposers, which Algorand sets through τproposer , τstep ,
sortition proofs in any given round. Users can also request and τfinal (independent of the number of users). As more
a certificate proving the safety of a block; this is simply the users join, it takes a message longer to disseminate in the
collection of votes for the final step. Since final blocks are gossip network. Algorand’s gossip network forms a random
totally ordered, users need to check the safety of only the network graph (each user connects to random peers). Our
most recent block. theoretical analysis suggests that almost all users will be
One potential risk created by the use of certificates is that part of one connected component in the graph, and that dis-
an adversary can provide a certificate that appears to show semination time grows with the diameter of that component,
that BA⋆ completed after some large number of steps. This which is logarithmic in the number of users [44]. Experi-
gives the adversary a chance to find a BA⋆ step number ments confirm that Algorand’s performance is only slightly
(up to MaxSteps) in which the adversary controls more affected by more users (§10).
than a threshold of the selected committee members (and Since our random graph uses a fixed number of peers,
to then create a signed certificate using their private keys). one potential concern is that it may contain disconnected
We set the committee size to be sufficiently large to ensure components [22]. However, only a small fraction of users
the attacker has negligible probability of finding such a step might end up in a disconnected component, which does

13
Parameter Meaning Value siping 1 KB to 90% of the Bitcoin peer-to-peer network takes
h assumed fraction of honest weighted users 80% about 1 second. We conservatively set λ priority to 5 seconds.
R seed refresh interval (# of rounds) 1,000 (§5.2) λ block ensures that Algorand can make progress even if
τproposer expected # of block proposers 26 (§B.1) the block proposer does not send the block. Our experiments
τstep expected # of committee members 2,000 (§B.2)
Tstep threshold of τstep for BA⋆ 68.5% (§B.2)
(§10) show that about 10 seconds suffices to gossip a 1 MB
τfinal expected # of final committee members 10,000 (§C.1) block. We conservatively set λ block to be a minute.
Tfinal threshold of τfinal for BA⋆ 74% (§C.1) λ step should be high enough to allow users to receive
MaxSteps maximum number of steps in BinaryBA⋆ 150 (§C.1) messages from committee members, but low enough to allow
λ priority time to gossip sortition proofs 5 seconds
λ block timeout for receiving a block 1 minute Algorand to make progress (move to the next step) if it does
λ step timeout for BA⋆ step 20 seconds not hear from sufficiently many committee members. We
λ stepvar estimate of BA⋆ completion time variance 5 seconds conservatively set λ step to 20 seconds. We set λ stepvar , the
estimated variance in BA⋆ completion times, to 10 seconds.
Figure 4: Implementation parameters.

not pose a problem for BA⋆. Moreover, Algorand replaces

10 EVALUATION
gossip peers each round, which helps users recover from Our evaluation quantitatively answers the following:
being possibly disconnected in a previous round. • What is the latency that Algorand can achieve for con-
firming transactions, and how does it scale as the number
9 IMPLEMENTATION of users grows? (§10.1)
We implemented a prototype of Algorand in C++, consist- • What throughput can Algorand achieve in terms of trans-
ing of approximately 5,000 lines of code. We use the Boost actions per second? (§10.2)
ASIO library for networking. Signatures and VRFs are im- • What are Algorand’s CPU, bandwidth, and storage costs?
plemented over Curve 25519 [6], and we use SHA-256 for (§10.3)
a hash function. We use the VRF outlined in Goldberg et
al [27: §4]. • How does Algorand perform when users misbehave?
(§10.4)
In our implementation each user connects to 4 random
peers, accepts incoming connections from other peers, and • Does Algorand choose reasonable timeout parameters?
gossips messages to all of them. This gives us 8 peers on (§10.5)
average. We currently provide each user with an “address To answer these questions, we deploy our prototype of
book” file listing the IP address and port number for every Algorand on Amazon’s EC2 using 1,000 m4.2xlarge virtual
user’s public key. In a real-world deployment we imagine machines (VMs), each of which has 8 cores and up to 1 Gbps
users could gossip this information, signed by their keys, or network throughput. To measure the performance of Algo-
distribute it via a public bulletin board. This naïve design of rand with a large number of users, we run multiple Algorand
the gossip protocol in our prototype implementation is po- users (each user is a process) on the same VM. By default, we
tentially susceptible to Sybil attacks, since it does not prevent run 50 users per VM, and users propose a 1 MByte block. To
an adversary from joining the gossip network with a large simulate commodity network links, we cap the bandwidth
number of identities. We leave the problem of implementing for each Algorand process to 20 Mbps. To model network la-
a Sybil-resistant gossip network to future work. tency we use inter-city latency and jitter measurements [52]
One difference between our implementation and the pseu- and assign each machine to one of 20 major cities around the
docode shown in §7 lies in the BinaryBA⋆() function. The world; latency within the same city is modeled as negligible.
pseudocode in Algorithm 8 votes in the next 3 steps after We assign an equal share of money to each user; the equal
reaching consensus. For efficiency, our implementation in- distribution of money maximizes the number of messages
stead looks back to the previous 3 steps before possibly re- that users need to process. Graphs in the rest of this section
turning consensus in a future step. This logic produces equiv- plot the time it takes for Algorand to complete an entire
alent results but is more difficult to express in pseudocode. round, and include the minimum, median, maximum, 25th,
Figure 4 shows the parameters in our prototype of Algo- and 75th percentile times across all users.
rand; we experimentally validate the timeout parameters in
§10. h = 80% means that an adversary would need to control 10.1 Latency
20% of Algorand’s currency in order to create a fork. By Figure 5 shows results with the number of users varying from
analogy, in the US, the top 0.1% of people own about 20% of 5,000 to 50,000 (by varying the number of active VMs from
the wealth [40], so the richest 300,000 people would have to 100 to 1,000). The results show that Algorand can confirm
collude to create a fork. transactions in well under a minute, and the latency is near-
λ priority should be large enough to allow block proposers constant as the number of users grows. (Since τfinal = 10, 000,
to gossip their priorities and proofs. Measurements of mes- the time it takes to complete the final step increases until
sage propagation in Bitcoin’s network [18] suggest that gos- there are 10,000 users in the system; before this point, users

14
 25 60
BA Final Step
20
50 BA w/o Final Step
Block Proposal
40
15

Time (s)
Time (s)

30
10 20

5 10
Round Completion 0
0

1MKB
B
B

MB
2M

4M

8M
5K
7K
K

10
10

15

25

50

51
Number of Users Block Size
Figure 5: Latency for one round of Algorand, with 5,000 to Figure 7: Latency for one round of Algorand as a function
50,000 users. of the block size.

120 proposed block. The block proposal time for small block
sizes is dominated by the λ priority + λ stepvar wait time. For
100 large block sizes, the time to gossip the large block contents
80 dominates. BA⋆ except for the final step, in the middle of
the graph, is the time it takes for BA⋆ to reach the final step.
Time (s)

60 Finally, BA⋆’s final step, at the top of the graph, is the time
40 it takes BA⋆ to complete the final step. We break out the
final step separately because, for the purposes of through-
20 put, it could be pipelined with the next round (although our
Round Completion
0 prototype does not do so).
The results show that Algorand’s agreement time (i.e.,
75K
10 K
0K
0K

0K

0K
50

15

25

50

Number of Users BA⋆) is independent of the block size, and stays about the
Figure 6: Latency for one round of Algorand in a configura- same (12 seconds) even for large blocks. The throughput
tion with 500 users per VM, using 100 to 1,000 VMs. can be further increased by pipelining the final step, which
takes about 6 seconds, with the next round of Algorand. The
are selected more than once and send fewer votes with higher fixed time for running BA⋆ and the linear growth in block
weights.) propagation time (with the size of the block) suggest that
To determine if Algorand continues to scale to even more increasing the block size allows one to amortize the time it
users, we run an experiment with 500 Algorand user pro- takes to run BA⋆ to commit more data, and therefore reach
cesses per VM. This configuration runs into two bottlenecks: a throughput that maximizes the network capability.
CPU time and bandwidth. Most of the CPU time is spent At its lowest latency, Algorand commits a 2 MByte block
verifying signatures and VRFs. To alleviate this bottleneck in about 22 seconds, which means it can commit 327 MBytes
in our experimental setup, for this experiment we replace of transactions per hour. For comparison, Bitcoin commits a
verifications with sleeps of the same duration. We are un- 1 MByte block every 10 minutes, which means it can com-
able to alleviate the bandwidth bottleneck, since each VM’s mit 6 MBytes of transactions per hour [9]. As Algorand’s
network interface is maxed out; instead, we increase λ step block size grows, Algorand achieves higher throughput at
to 1 minute. the cost of some increase to latency. For example, with a
Figure 6 shows the results of this experiment, scaling the 10 MByte block size, Algorand commits about 750 MBytes of
number of users from 50,000 to 500,000 (by varying the num- transactions per hour, which is 125× Bitcoin’s throughput.
ber of VMs from 100 to 1,000). The latency in this experiment
10.3 Costs of running Algorand
is about 4× higher than in Figure 5, even for the same num-
ber of users, owing to the bandwidth bottleneck. However, Users running Algorand incur CPU, network, and storage
the scaling performance remains roughly flat all the way to costs. The CPU cost of running Algorand is modest; when
500,000 users, suggesting that Algorand scales well. running 50 users per VM, CPU usage on the 8-core VM was
about 40% (most of it for verifying signatures and VRFs),
10.2 Throughput meaning each Algorand process uses about 6.5% of a core.
In the following set of experiments we deploy 50,000 users In terms of bandwidth, each user in our experiment with
on our 1,000 VMs (50 users per machine). Figure 7 shows 1 MByte blocks and 50,000 users uses about 10 Mbit/sec (em-
the results with a varying block size. The figure breaks the pirically computed as the total amount of data sent, divided
Algorand round into three parts. Block proposal (§6), at the by the duration of the experiment). We note that the com-
bottom of the graph, is the time it takes a user to obtain the munication cost per user is independent of the number of

15
 25 around 1 second, well under λ priority (5 seconds), confirming
the measurements by Decker and Wattenhofer [18].
20
11 FUTURE WORK
15 This paper focused on the consensus mechanism for commit-
Time (s)

ting transactions, and addressing the associated scalability

10 and security challenges. There remain a number of open
problems in designing permissionless cryptocurrencies:
5
Incentives. In order to encourage Algorand users to par-
Round Completion
0 ticipate, i.e., be online when selected and pay the network
0 5 10 15 20 cost of operating Algorand, the system may need to include
% Malicious Users
incentives, possibly in form of a reward mechanism. Design-
ing and analyzing an incentive mechanism includes many
Figure 8: Latency for one round of Algorand with a varying
challenges, such as ensuring that users do not have perverse
fraction of malicious users, out of a total of 50,000 users.
incentives (e.g., to withhold votes), and that malicious users
users running Algorand, since users have an expected fixed cannot “game the system” to obtain more rewards than users
number of neighbors they gossip messages to, and the num- who follow the protocol (e.g., by influencing seed selection).
ber of messages in the consensus protocol depends on the Cost of joining. To join Algorand, new users fetch all ex-
committee size (rather than the total number of users). isting blocks with their accompanying certificates, which
In terms of storage cost, Algorand stores block certificates can comprise a large amount of data. Other cryptocurrencies
in order to prove to new users that a block was committed. face a similar problem, but since the throughput of Algorand
This storage cost is in addition to the blocks themselves. Each is relatively high, this may create a scalability challenge.
block certificate is 300 KBytes, independent of the block size;
Forward security. Attackers may attempt to corrupt users
for 1 MByte blocks, this would be a ∼30% storage overhead.
over time, since identities of committee members are re-
Sharding block storage across users (§8.3) reduces storage
vealed after they send a message. If an attacker manages to
costs proportionally. For example, sharding modulo 10 would
obtain enough user keys, he could construct a fake certificate
require each user to store, on average, 130 KB for every 1MB
to create a fork. One solution would be for users to forget
block that is appended to the ledger.
the signing key before sending out a signed message (and
10.4 Misbehaving users commit to a series of signing keys ahead of time, perhaps
using identity-based encryption [11, 20]).
Algorand’s safety is guaranteed by BA⋆ (§7), but proving this
experimentally would require testing all possible attacker 12 CONCLUSION
strategies, which is infeasible. However, to experimentally
show that our Algorand prototype handles malicious users, Algorand is a new cryptocurrency that confirms transactions
we choose one particular attack strategy. We force the block on the order of a minute with a negligible probability of fork-
proposer with the highest priority to equivocate about the ing. Algorand’s design is based on a cryptographic sortition
proposed block: namely, the proposer sends one version of mechanism combined with the BA⋆ Byzantine agreement
the block to half of its peers, and another version to others protocol. Algorand avoids targeted attacks at chosen partic-
(note that as an optimization, if a user receives to conflicting ipants using participant replacement at every step. Exper-
versions of a block from the highest priority block proposer imental results with a prototype of Algorand demonstrate
before the block proposal step is complete, he discards both that it achieves sub-minute latency and 125× the throughput
proposals and starts BA⋆ with the empty block). Malicious of Bitcoin, and scales well to 500,000 users.
users that are chosen to be part of the BA⋆ committee vote
ACKNOWLEDGMENTS
for both blocks. Figure 8 shows how Algorand’s performance
is affected by the weighted fraction of malicious users. The Thanks to Iddo Bentov, Ethan Heilman, Jelle van den Hooff,
results show that, at least empirically for this particular at- and our shepherd, Robbert van Renesse, for their helpful com-
tack, Algorand is not significantly affected. ments and suggestions. Gilad, Hemo, and Zeldovich were
supported by NSF awards CNS-1413920 and CNS-1414119.
10.5 Timeout parameters
The above results confirm that BA⋆ steps finish in well un- REFERENCES
der λ step (20 seconds), that the difference between 25th and [1] M. Abd-El-Malek, G. R. Ganger, G. R. Goodson, M. K.
75th percentiles of BA⋆ completion times is under λ stepvar Reiter, and J. J. Wylie. Fault-scalable Byzantine fault-
(5 seconds), and that blocks are gossiped within λ block (1 tolerant services. In Proceedings of the 20th ACM Sym-
minute). We separately measure the time taken to propa- posium on Operating Systems Principles (SOSP), pages
gate a block proposer’s priority and proof; it is consistently 59–74, Brighton, UK, Oct. 2005.

16
 [2] I. Bentov and R. Kumaresan. How to use Bitcoin to [16] J. Chen and S. Micali. Algorand. Technical report, 2017.
design fair protocols. In Proceedings of the 34th Annual URL http://arxiv.org/abs/1607.01341.
International Cryptology Conference (CRYPTO), Santa
Barbara, CA, Aug. 2014. [17] A. Clement, E. L. Wong, L. Alvisi, M. Dahlin, and
M. Marchetti. Making Byzantine fault tolerant sys-
[3] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld. Proof tems tolerate Byzantine faults. In Proceedings of the
of activity: Extending Bitcoin’s proof of work via proof 6th Symposium on Networked Systems Design and Im-
of stake. In Proceedings of the 2014 Joint Workshop on plementation (NSDI), pages 153–168, Boston, MA, Apr.
Pricing and Incentives in Networks and Systems, Austin, 2009.
TX, June 2014.
[18] C. Decker and R. Wattenhofer. Information propaga-
[4] I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurren- tion in the Bitcoin network. In Proceedings of the 13th
cies without proof of work. In Proceedings of the 2016 IEEE International Conference on Peer-to-Peer Comput-
Financial Cryptography and Data Security Conference, ing, Sept. 2013.
2016.
[19] R. Dingledine, N. Mathewson, and P. Syverson. Tor:
[5] I. Bentov, P. Hubáček, T. Moran, and A. Nadler. Tor- The second-generation onion router. In Proceedings
toise and hares consensus: the Meshcash framework of the 13th Usenix Security Symposium, pages 303–320,
for incentive-compatible, scalable cryptocurrencies. San Diego, CA, Aug. 2004.
Cryptology ePrint Archive, Report 2017/300, Apr. 2017.
http://eprint.iacr.org/. [20] N. Döttling and S. Garg. Identity-based encryption
from the Diffie-Hellman assumption. In Proceedings
[6] D. J. Bernstein. Curve25519: New Diffie-Hellman speed of the 37th Annual International Cryptology Confer-
records. In Proceedings of the 9th International Confer- ence (CRYPTO), pages 537–569, Santa Barbara, CA, Aug.
ence on Theory and Practice in Public-Key Cryptogra- 2017.
phy (PKC), pages 207–228, New York, NY, Apr. 2006.
[21] J. R. Douceur. The Sybil attack. In Proceedings of the 1st
[7] Bitcoin Wiki. Confirmation. https://en.bitcoin. International Workshop on Peer-to-Peer Systems (IPTPS
it/wiki/Confirmation, 2017. ’02), Cambridge, MA, Mar. 2002.
[8] BitcoinWiki. Mining hardware comparison, [22] P. Erdős and A. Rényi. On the evolution of random
2016. https://en.bitcoin.it/wiki/Mining_ graphs. Publications of the Mathematical Institute of the
hardware_comparison. Hungarian Academy of Sciences, 5:17–61, 1960.
[9] BitcoinWiki. Bitcoin scalability. https://en. [23] Ethereum Foundation. Ethereum, 2016. https://www.
bitcoin.it/wiki/Scalability, 2017. ethereum.org/.
[10] BitcoinWiki. Proof of stake. https://en.bitcoin. [24] Ethereum Foundation. Create a democracy contract in
it/wiki/Proof_of_Stake, 2017. Ethereum, 2016. https://www.ethereum.org/dao.
[11] D. Boneh and M. K. Franklin. Identity-based encryption
[25] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin
from the Weil pairing. In Proceedings of the 21st Annual
mining is vulnerable. In Proceedings of the 2013 Financial
International Cryptology Conference (CRYPTO), Santa
Cryptography and Data Security Conference, Mar. 2014.
Barbara, CA, Aug. 2001.
[26] I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse.
[12] G. Brockman. Stellar, July 2014. https://stripe.
Bitcoin-NG: A scalable blockchain protocol. In Pro-
com/blog/stellar.
ceedings of the 13th Symposium on Networked Systems
[13] V. Buterin. Minimal slashing conditions. https: Design and Implementation (NSDI), pages 45–59, Santa
//medium.com/@VitalikButerin/minimal- Clara, CA, Mar. 2016.
slashing-conditions-20f0b500fc6c, Mar. 2017.
[27] S. Goldberg, M. Naor, D. Papadopoulos, and L. Reyzin.
[14] C. Cachin, K. Kursawe, F. Petzold, and V. Shoup. Secure NSEC5 from elliptic curves: Provably preventing
and efficient asynchronous broadcast protocols. In DNSSEC zone enumeration with shorter responses.
Proceedings of the 21st Annual International Cryptology Cryptology ePrint Archive, Report 2016/083, Mar. 2016.
Conference (CRYPTO), pages 524–541, Santa Barbara, http://eprint.iacr.org/.
CA, Aug. 2001.
[28] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg.
[15] M. Castro and B. Liskov. Practical Byzantine fault tol- Eclipse attacks on Bitcoin’s peer-to-peer network. In
erance and proactive recovery. ACM Transactions on Proceedings of the 24th Usenix Security Symposium,
Computer Systems, 20(4), Nov. 2002. pages 129–144, Washington, DC, Aug. 2015.

17
[29] S. Higgins. Bitcoin mining pools targeted in wave of [42] R. Pass and E. Shi. Hybrid consensus: Efficient consen-
DDoS attacks. Mar. 2015. https://www.coindesk. sus in the permissionless model. Cryptology ePrint
com/bitcoin-mining-pools-ddos-attacks/. Archive, Report 2016/917, 2016. http://eprint.
iacr.org/.
[30] A. Kiayias, I. Konstantinou, A. Russell, B. David, and
R. Oliynykov. Ouroboros: A provably secure proof-of- [43] Peercointalk. Peercoin invalid checkpoint.
stake blockchain protocol. Cryptology ePrint Archive, https://www.peercointalk.org/t/invalid-
Report 2016/889, 2016. http://eprint.iacr.org/. checkpoint/3691, 2015.
[31] S. King and S. Nadal. PPCoin: Peer-to-peer crypto- [44] O. Riordan and N. Wormald. The diameter of sparse ran-
currency with proof-of-stake, Aug. 2012. https: dom graphs. Combinatorics, Probability and Computing,
//peercoin.net/assets/paper/peercoin- 19(5-6):835–926, Nov. 2010.
paper.pdf.
[45] P. Rizzo. BitGo launches “instant” Bitcoin transaction
[32] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, tool, Jan. 2016. http://www.coindesk.com/bitgo-
L. Gasser, and B. Ford. Enhancing Bitcoin security instant-bitcoin-transaction-tool/.
and performance with strong consistency via collec-
tive signing. In Proceedings of the 25th Usenix Security [46] J. Rubin. The problem of ASICBOOST, Apr.
Symposium, pages 279–296, Austin, TX, Aug. 2016. 2017. http://www.mit.edu/~jlrubin/public/
pdfs/Asicboost.pdf.
[33] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. L.
Wong. Zyzzyva: Speculative Byzantine fault tolerance. [47] Y. Sompolinsky and A. Zohar. Secure high-rate trans-
ACM Transactions on Computer Systems, 27(4):7:1–39, action processing in Bitcoin. In Proceedings of the 2015
2009. Financial Cryptography and Data Security Conference,
2015.
[34] L. Lamport. The part-time parliament. ACM Transac-
tions on Computer Systems, 16(2):133–169, 1998. [48] Y. Sompolinsky, Y. Lewenberg, and A. Zohar. SPECTRE:
A fast and scalable cryptocurrency protocol. Cryptol-
[35] J. Li and D. Mazières. Beyond one-third faulty replicas ogy ePrint Archive, Report 2016/1159, 2016. http:
in Byzantine fault tolerant systems. In Proceedings of //eprint.iacr.org/.
the 4th Symposium on Networked Systems Design and
Implementation (NSDI), Cambridge, MA, Apr. 2007. [49] N. Szabo. Smart contracts: Formalizing and securing
relationships on public networks. First Monday, 2(9),
[36] D. Mazières. The Stellar consensus protocol: Sept. 1997. http://firstmonday.org/ojs/index.
A federated model for internet-level consensus. php/fm/article/view/548/469.
https://www.stellar.org/papers/stellar-
consensus-protocol.pdf, 2014. [50] R. Turpin and B. A. Coan. Extending binary Byzan-
tine agreement to multivalued Byzantine agreement.
[37] S. Micali. Fast and furious Byzantine agreement. In Information Processing Letters, 18(2):73–76, Feb. 1984.
Proceedings of the Innovations in Theoretical Computer
Science (ITCS) Conference, 2017. [51] M. Vasek, M. Thornton, and T. Moore. Empirical analy-
sis of denial-of-service attacks in the Bitcoin ecosystem.
[38] S. Micali, M. O. Rabin, and S. P. Vadhan. Verifiable ran- In Proceedings of the 18th International Financial Cryp-
dom functions. In Proceedings of the 40th Annual IEEE tography and Data Security Conference, Barbados, Mar.
Symposium on Foundations of Computer Science (FOCS), 2014.
New York, NY, Oct. 1999.
[52] WonderNetwork. Global ping statistics: Ping times
[39] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song. The
between WonderNetwork servers, Apr. 2017. https:
Honey Badger of BFT protocols. In Proceedings of the
//wondernetwork.com/pings.
23rd ACM Conference on Computer and Communications
Security (CCS), pages 31–42, Vienna, Austria, Oct. 2016. [53] Zerocoin Electric Coin Company. ZCash: All coins are
created equal, 2017. https://z.cash.
[40] A. Monaghan. US wealth inequality: top 0.1%
worth as much as the bottom 90%, Nov. 2014.
https://www.theguardian.com/business/2014/ A NUMBER OF REQUIRED BLOCKS FOR
nov/13/us-wealth-inequality-top-01-worth- UNPREDICTABLE SELECTION SEED
as-much-as-the-bottom-90.
Theorem 1. Under strong synchrony, the probability that
[41] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash the attacker can compute the next k selection seeds decreases
system. https://bitcoin.org/bitcoin.pdf, 2008. exponentially with k.

18
Proof. Let h denote the fraction of honest users. When the For f (k + 1), if the root has exactly c malicious children
block that was agreed upon for round r is proposed by an left of the first honest child, then the adversary has c + 1 op-
honest user i, then seedr +1 , which sets the priorities among tions for seedr +1 . The adversary can generate k + 1 malicious
block proposers for round r + 1, takes a uniformly random blocks iff he can generate at least k malicious blocks starting
value. Therefore, the highest priority for proposing a block at from one of the c + 1 options he has for the block following
round r + 1 has probability h of belonging to an honest user, the root. The probability that at least one of c + 1 options
and so does every priority in the increasing sequence (i.e., does generate k non-honest blocks is less than (c + 1)f (k) by
the second highest priority also has probability h, and so on). union bound. So we get the recursive formula:
If the priority belongs to an honest user, then that user will
propose a non-empty block which will become the unique
certified block for round r + 1. If the c highest priorities f (k + 1) ≤
∞
belong to malicious users instead, then the adversary can
Õ
Pr[adv. has exactly c leftmost children] · (c + 1)f (k) =
make any of those c users propose the next block (and have c=1
that block agreed upon by all honest users), or he might ∞
(1 −h)(1 +h)
(1 −h)c h · (c + 1)f (k) =
Õ
force the round r + 1 block to be the empty block (by sending f (k)
c=1
h
the proof of selection with the highest priority, and then not
sending the actual block). So the adversary has c + 1 choices So by induction,
for the value of seedr +1 . These options give the adversary the
power to influence future seeds and ensure a malicious block (1 −h)(1 +h) k −1

(1 −h)(1 +h)
 k −1
proposer with probability greater than 1 −h. We now prove f (k) ≤ ( ) f (1) = (1 −h)
h h
that the adversary has limited power to influence future (1)
seeds.
Since h ≥ 32 it holds that,
For the proof, we build a tree, where each node represents
a user’s priority value, and contains the next selection seed, 1
f (k) ≤ · (0.84)k−1 ≤ (0.84)k
as set by that user (if the associated priority is the highest 3
announced); each node in the tree can belong to an honest Thus, for failure probability f that the attacker can control
or a malicious user. The root of this tree belongs to the last k blocks in a row, it is sufficient to chose k = log0.84 f . For
honest user who proposed a block that was agreed upon. The f = 10−18 , it is sufficient to use k = 238. If we assume a
selection seed in the root is seedr , which is the last seed that somewhat higher honesty rate, e.g., h = 34 , then it is sufficient
was in a block proposed by an honest user. The children of to use k = 77. □
the root represent the users ordered from left to right, in de-
creasing priority order, determined by seedr , and each child B NUMBER OF SELECTED USERS
node also contains a possible value for seedr +1 . We define
We have at least h ·U honest sub-users, where U is the total
the children of each child node using the same procedure we
number of minimal Algorand units in the system. We assume
used for the root. Each node’s children define an order of the
a large number of currency units in Algorand (namely, U
users, which is sampled with a pseudo-random permutation
can be made arbitrarily large). At each round, the number of
of all user priorities (set by the selection seed in the father
sub-users selected for a given role varies, but the expected
node).
number of selected sub-users, τ , is fixed. The probability p of
We refer to blocks set by honest/malicious users as hon- a sub-user to be selected is given by the formula p = Uτ . What
est/malicious blocks (respectively). We wish to bound the is the probability
that exactly K sub-users are sampled?
expected number of blocks between two consecutive honest- There are UK subsets of U , consisting of exactly K
blocks. For the proof, we give the adversary the power to, sub-users. For each such set, the probability that exactly the
given a selection seed, know the positions of the users in sub-users of that set are sampled form U is p K (1 − p)U −K .
the decreasing order of priorities. If the leftmost child of the So the probability that exactly K ∈ {0, 1, . . .} sub-users are
root represents an honest user, then block at round r + 1 will sampled is:
be honest, so the number of malicious blocks between the
two honest blocks is 0. If the leftmost child is malicious, then U K
 
p (1 −p)U −K
number of malicious blocks before the next honest block is K
at least 1. This happens with probability 1 −h, so the proba-
bility that at least one non-honest block appears before the This is equal to:
next honest block is 1 −h. If we let f (k) denote the probabil-
ity that at least k non-honest blocks appear before the next U! τ τ U · · · (U − K + 1) τ K τ
( )K (1− )U −K = K
(1− )U −K
honest block, then f (1) = 1 − h. We will now inductively K!(U − K)! U U U K! U
compute an upper bound on f (k), using f (1) as the base
case. For the purposes of Algorand, we can take U to be arbitrarily

19
large and fix K, so that effectively, The condition is violated when K + 2L > 2Tstep · τstep , so
the probability that condition (2) is violated is given by the
U · · · (U − K + 1) formula:
=1
UK
(hτstep )K ((1 −h)τstep )L −τstep
∞
Õ
and e =
τ K! L!
τ U −K (1 − U )U e −τ K +2L>2Tstep ·τstep
(1 − ) = = = e −τ
U (1 − Uτ )K 1
(hτstep )K ((1 −h)τstep )L −τstep
∞
Õ ∞
Õ
e
So the probability of sampling exactly K sub-users is: K! L!
L=0 K =max{Tstep ·τstep −2L,0}

(τ )K
e −τ (2) This sum converges and we upper-bound its value for
K!
particular choice of h,Tstep ,τstep parameters.
B.1 Block proposers In particular, the parameters Tstep and τstep are selected
We need that at least one proposer is selected every round, so as to ensure that both conditions hold with probability F
but not too many users are selected. Let the expected in a randomly generated committee. Here, F is a parameter
number of proposers be τproposer . We can use the formula which marks a negligible probability for failure of either
in Equation 2 to obtain the probability of 0 good proposers as: condition, which we usually set to F = 10−12 or F = 10−18 .

(τproposer )0 −τproposer Analysis behind Figure 3. For a given fraction of honest

e = e −τproposer committee members h (x-axis of Figure 3), the goal is to
0!
minimize the expected committee size, while maintaining
For τproposer = 26, the probability that we get at least one
the probability that conditions (1) or (2) fail to be at most F . If
proposer but no more than 70 is:
some value of τstep satisfies both conditions with probability
70 1 − F for some appropriate value of Tstep , then any larger
Õ 26K value of τstep also does for the same Tstep with probability
e −26 > 1 − 10−11
K =1
K! at least 1 − F . So to find the optimal τstep , we start with an
arbitrary high value for τstep , say 10,000, and then see if we
B.2 Committee members
can find aTstep > 32 that satisfies conditions (1) and (2). If such
If #дood is the number of honest committee members and threshold exists, then we decrease τstep and test whether a
#bad is the number of malicious committee members, then good threshold exists too. We continue this iterative process
we want the following conditions to be satisfied for some pre- until finding the minimal committee size and corresponding
determined threshold Tstep · τstep . We give explicit formulas threshold Tstep that ensure both conditions.
for the probability that each condition is violated. To check if a particular value for τstep works, we do a
Condition (1), #дood > Tstep · τstep . This condition is vio- binary search to find the highest Tstep ∈ ( 23 , 1] value such that
lated when the number of honest committee members is condition (1), #дood > Tstep ·τstep , fails with probability ≤ 12 F ,
≤ Tstep · τstep . From Equation 2, the probability that we then check if, for that particular value of Tstep , condition (2)
have exactly K honest committee members is (hτstep )K −hτstep
e . also fails with probability ≤ 12 F . By the union bound, the
K!
Thus, the probability that the condition is violated is given probability that either condition fails is F , so the expected
by the formula: committee size τstep works.
With the above approach, we find an approximation of the
Tstep ·τstep optimal value for τstep that is within 1% of the true optimal
Õ (hτstep )K −hτstep
e value for τstep .
K!
k =0
C BA⋆ ANALYSIS
Condition (2), # 12 дood + #bad ≤ Tstep ·τstep . As above, the
probability that #bad = L is In this section we analyze the safety, liveness, and efficiency
of BA⋆, presented in §7.
((1 −h)τstep )L −(1−h)τstep
e C.1 Safety with weak synchrony
L!
Theorem 2. Assume the parameters Tfinal = 0.74, τfinal =
So the probability that both #дood = K and #bad = L is:
10, 000 and Tstep = 0.685, τstep = 2000 (as in Figure 4). Fix
(hτstep )K −hτstep ((1 −h)τstep )L −(1−h)τstep a round r = 0 mod R (where R is the selection seed refresh
e e = interval, see §5.2). The probability that there exists a round
K! L!
r ≤ r ′ < r + R, such that BA⋆ (Algorithm 3) returns for one
(hτstep )K ((1 −h)τstep )L −τstep honest user a final consensus for block A, and for another honest
e user a consensus (final or tentative) for block B , A, is < 10−7 .
K! L!

20
Corollary 3. Given Theorem 2 and since R = 103 (i.e., every has i malicious members and a targeted BinaryBA⋆ commit-
103 consecutive rounds starting with an integral multiple of R tee has j malicious members, where i + 3j = 4, 100. Intuitively,
get their committees from the same selection seed), we expect however, if the adversary concentrates all of his computa-
BA⋆ to return for one honest user a final consensus for block A, tional power on finding a round (with highly malicious final
and for another honest user a consensus (final or tentative) for committee to finalize block A) and a targeted step within that
block B , A for the same round, only once every 103 · 107 = 1010 round (with a highly malicious committee to certify block B)
rounds. such that i + 3j = 4, 100, then for all other rounds and steps,
the number of malicious committee members is random,
Proof. We next prove Theorem 2. In §5.3 and Appendix A we
which makes the probability that the attacker succeeds in
showed that the weak synchrony assumption allows Algo-
one of those round/step pairs negligible (< 10−20 ).
rand to select the users’ public keys (and associated weights)
before the adversary knows the selection seed, ensuring More precisely, if the adversary targets two round/step
random sampling of users for BA⋆ committees. We next pairs where i + 3j > 3850, then both of those pairs will have
leverage this property to, informally, show that the commit- i + 3j < 3950. This is true, because the probability that i + 3j >
tee members for the final step represent well all the users 3850 is approximately 0.41 · 10−18 , while the probability that
in the system. Therefore, if sufficiently many of them vote i + 3j > 3950 is approximately 0.6 · 10−23 , so the probability
for a block to be final, then sufficiently many of the users that both events happen for two specific round-step pairs is
have finished BinaryBA⋆ at the first step and will not vote less than 2.5 · 10−41 . Since for a specific selection seed there
2 3

in future steps (so no other block can be approved). are R = 103 rounds with 102 steps each, there are 10 2·10 =
1 10
We set τfinal = 10, 000 and assume that the weighted 2 10 possible pairs of round/step. The probability that the
honest fraction of users is h = 0.8. Thus, the expected attacker manages to target more than one round/step where
number of honest members in the final step committee i +3j > 3950 is therefore, by union bound, less than 2.5·10−41 ·
is 0.8 · 10, 000 = 8000, while the expected number of mali- 0.5 · 1010 = 1.25 · 10−31 < 2−93 , so it should never happen.
cious members for that step is 0.2 · 10, 000 = 2000. We next In sum, the attacker has two strategies: (1) target one
show that the probability that 7400 step-final votes for a round and step within that round such that i + 3j ≤ 4, 100, or
round-r ′ block A are produced, but another block B is also (2) target multiple step/round pairs where i + 3j ≤ 3950. We
certified for the same round, is negligible. next analyze these two strategies.
Let seedr −1−(r mod R) be the seed used for selecting the com- Strategy 1: one round/step pair where i + 3j ≤ 4100. If
mittees for round r ′ ∈ [r ,r + R). If the round when that seed the final step committee at round r’ has i malicious mem-
was published, i.e. round r − 1 − (r mod R), happens when bers, then any other committee at the same round has at
the network is not strongly synchronous, then the adversary most 4100−i malicious members. Clearly, the worst case is
3
may manipulate the selection of the seed (seedr −1−(r mod R) ) when i + 3j = 4100. Thus, in order to prove that the proba-
by discarding block proposals from honest users. We first bility of failure is 10−7 , we need to show that for all integral
show that despite the ability of the attacker to manipulate tuples (i, j) on the line i + 3j = 4100, the probability that both
the seed, it is infeasible to compute a seed that: (1) gives i committees have enough users is less than 10−7 . Equiva-
malicious committee members in the r ′ round final step, lently, for each integral value j in the interval [0, 4100 3 ], we
and (2) j malicious committee members in some other step need to prove that for i = 4100 − 3j, the probability that both
of round r ′, where i + 3j > 4, 100. committees have enough honest members (i.e., the final
The expected numbers for i and j are 0.2 · 1000 = 2000 and committee has 0.74 · 10, 000 −i = 7400 −i and the other com-
0.2 · 2000 = 400 respectively. So for a fixed round and step, mittee has 0.685 · 2000 − j = 1370 − j honest members) is less
we apply the formula in Equation 2, to find the probability than 10−7 (since Tfinal = 0.74, τfinal = 1000 and Tstep = 0.685,
that a random seed gives i + 3j > 4, 100: τstep = 2000). For each integral value j ∈ [0, 4100 3 ] we did a
Õ 2000i 400j separate calculation to prove that the desired probability
≃ 2−100 always is less than 10−7 .
i+3j >4,100
i!e 2000 j!e 400
We next describe the method used to upper-bound the
To check if a seed value satisfies i + 3j > 4, 100, the ad- probability for each tuple (i, j) = (4100 − 3j, j).
versary has to do at least one cryptographic hash or VRF Fix (i, j). The i malicious votes go towards the final block
operation. Each round has committees for at most MaxSteps A, while the j votes go towards certifying another block B. So
= 150 steps. For each round, only 2/3 of those 150 (i.e., 100) 7400−i more signatures are required for the final committee
committees can create a certificate (only those that vote in and 1370 − j more signatures for the other committee. Let AÛ
the first or second step in the BinaryBA⋆ loop). So by union denote the set of honest users who would vote to approve
bound, the probability that a seed value gives i + 3j > 4, 100 block A as final (if completed BinaryBA⋆ at the first step and
for a specific round (and any step of that round) is ≃ 2−93 . So selected to the final committee), and BÛ the set of honest
it is infeasible for the adversary to find such a seed. users who would vote to certify another block B (, A) if they
Notice that our argument above does not exclude the possi- were in a committee and did not finish BinaryBA⋆ at the
bility that more than a single pair of round final committee first step. Clearly, AÛ ∩ BÛ = ∅. So each honest user eventually

21
becomes a member of at most one of the two sets. For the currency units which might be arbitrarily large. We therefore
7400 and 1370 thresholds to both be reached, set AÛ must evaluate an upper bound:
include 7400 −i committee members for final, while set BÛ
f −1
must include 1370 − j committee members for another step. 100 H− H
f −1 f
∞
(1600 H100 )c ª
Õ   Õ
We say that an honest user “joins” set AÛ when that user ≤ Pr H ≤n ≤ H ­
©
100 100 f −1
®
H − 100 H
counts sufficiently many (more than Tstep · τstep ) votes for f =1 «c=1370−j
c!e 1600 H ¬
block_hash to complete BinaryBA⋆ in its first step. Else
(after the first step of BinaryBA⋆), we say that the honest The above is the upper Riemann sum of the integral
f −1
user “joins” set B.Û Without strong synchrony, the network H − 100 H c
(1600 )
of c=1370−j from 0 to H , where the interval
Í∞ H
is under the attacker’s control, so the attacker can choose f −1
H − 100 H
c!e 1600 H
whether a user joins set AÛ or BÛ (by delivering votes to that [0,H ] is partitioned into 100 equal parts. Since the function
user). This allows the attacker to get some feedback: if the (1600 HH−k )c
is decreasing in k, this is an upper bound.
Í∞
attacker lets a user join set A,Û then he can observe whether c=1370−j 1600 H −k
c!e H
that user is selected to the final committee (i.e., see if that It is evaluated as follows:
user votes). In this fashion the attacker can let users join
f −1 f
 
set AÛ one by one until sufficiently many votes are produced Pr H ≤n ≤ H =
to approve block A as final, and then join the rest of the 100 100
honest users to set B.Û
f
Therefore, users join set AÛ in some order. Let n be the size Pr [the H honest users in AÛ produce 7400-i votes]−
100
of AÛ when the users in set AÛ can, for the first time, produce
7400 −i final step votes in the targeted round. Let H be the f −1
Pr [the H honest users in AÛ produce 7400-i votes] =
total number of units of Algorand currency held by honest 100
users; to simplify our proof, we assume that each user has f
(8000 100 )7400−i
f −1
(8000 100 )7400−i
exactly one unit of currency so H is also the number of users f
− f −1
(if a user has more than one unit, we consider that user to (7400 −i)!e 8000 100 (7400 −i)!e 8000 100
be represented by multiple “subusers” each with one unit of Thus, the probability of failure is upper-bounded by the
currency). For a fixed value of n, at most H − n users join following formula, which can be computed:
set B.
Û For the attacker to succeed, these H − n users must
produce 1370 − j votes for block B in the targeted step of 100 f 7400−i
(8000 100 )7400−i ª
f −1 ∞ f −1 c !
Õ © (8000 100 ) Õ (1600(1 − 100 )
BinaryBA⋆. Let Pk denote the probability that: (1) n = k, and ≤ ­ f
− f −1
® f −1
f =1 « (7400 − i)!e 8000 100 (7400 − i)!e 8000 100 ¬ c =1370−j c!e 1600(1− 100 )
(2) the remaining H −k users in set BÛ produce 1370-j votes
for block B. Pk is given by:
Strategy 2: multiple round/step pairs where i + 3j ≤
3950. We first show that the adversary cannot target 3
Pk = Pr [n = k]Pr [the H-k users in BÛ produce at least 1370-j votes] = round/step pairs, where the final committee has at least i
∞
Pr [the H-k users in BÛ produce exactly c votes] malicious members and the step committee has j malicious
Õ
Pr [n = k]
c=1370−j
members where i + 3j > 3850. This is because the probabil-
ity of targeting one round/step pair where i + 3j > 3850 is
Using the formula in Equation 2 we can compute at most 0.41 · 10−18 , so the probability to target three such
Pr [the H-k users in B produce exactly c votes]. The expected
Û pairs is (0.41 · 10−18 )3 < 10−51 . For each selection seed there
number of honest users selected for the committee in the set are R = 103 rounds and each round has at most 102 steps
H −k
B (which includes H-k users) is h · 2000 · H , so for h = 0.8
Û that the attacker can target (i.e. steps where BinaryBA⋆ can
the expected number of users is 1600 · HH−k . Therefore, the conclude and certify a block). So we have at most 103 · 102
expression in Equation 3 equals to: step committees set for every selection seed, therefore the
number of step/round pairs that the attacker can target is
(1600 HH−k )c 102 ·103

∞
!
Õ
3 < 1015 . The probability of attacker success is thus
Pr [n = k]
1600 H
H −k bounded by 1015 · 10−51 = 10−36 . Thus, the attacker can have
c=1370−j c!e
at most two pairs with i + 3j > 3850, in which case for both
The adversary succeeds with probability kH=0 Pk , which we will have i + 3j < 3950. This allows us to analyze the
Í
is equal to: following two cases (within the above attacker strategy):
H H
(1600 HH−k )c • Two targeted round/step pairs where 3850 < i + 3j ≤
∞
!
Õ Õ Õ
Pk = Pr [n = k] 3950. It can be shown (with similar calculations to the
1600 H −k
k =0 k =0 c=1370−j c!e H
case i + 3j ≤ 4100) that the probability of success for
The inner sum converges and can be evaluated. However, the adversary success is less than 10−9 for one targeted
the outer sum iterates over total number amount of honest round/step pair, and therefore less than 2 · 10−9 in total.

22
 • All round/step pairs have i + 3j ≤ 3850. It can be simi- Lemma 2. Under strong synchrony, if an honest user com-
larly shown that probability of success for the adversary pletes BA⋆ for round r with consensus on value v, then all
is less than 10−20 . Since each round has at most 102 steps honest users complete BA⋆ for round r with the same value.
and there are R = 103 rounds set by the same selection
seed, the attacker’s probability for success is bounded Proof. Under strong synchrony, we assume that all users are
by 102 · 103 · 10−20 = 10−15 . in consensus on the block for round r − 1 (if there was a fork
due to an earlier non-strongly-synchronous period, the fork
In conclusion, strategy 2 provides a lower attacker success resolution protocol in §8 has resolved it). In this case, the
rate than strategy 1, where the attacker’s success rate is Reduction procedure (Algorithm 7) returns for each honest
bounded by 10−7 for every sequence of R = 103 rounds. □ user one of two values: either the empty block’s hash, which
is completely determined by the previous block and therefore
C.2 Liveness with strong synchrony the same for all users, or the Reduction procedure returns
the same block_hash (applying Lemma 1 we observe that
In this section we show that under the strong synchrony
only a single value can cross the threshold for CountVotes in
assumption, Algorand maintains liveness.
the first step of the reduction, and hence only a single value
Theorem 4. Under strong synchrony, all users will eventu- different than the hash of the empty block is possible).
ally reach consensus on a block. If the highest priority block Since BA⋆ returns consensus on what BinaryBA⋆ returns,
proposer is honest, then all honest users reach final consensus it is sufficient to show that if BinaryBA⋆ returns for an honest
on that block. user with a value v, then it does so for all other honest users.
Without loss of generality, let us assume that a user
Proof. The proof of the liveness theorem above follows from completed BinaryBA⋆ with block_hash. Therefore the
several properties of BA⋆ under strong synchrony which CountVotes procedure called by that user with round r and
we next prove. First, in Lemma 1, we show that under weak step 1 (mod 3) returned block_hash. By Lemma 1 other users
synchrony the CountVotes procedure (Algorithm 5) does have either concluded that step with block_hash too, or with
not return two different non timeout values for two users timeout. Therefore, all honest users who did not finish the
in the same round and step. Second, we prove Theorem 2, protocol in that step will next vote for block_hash (since the
which shows that this property of CountVotes guarantees step index was 1 mod 3). The users who completed the pro-
that if a final block exists for an Algorand round, then no tocol will gossip all the votes they received for block_hash.
other block was agreed upon in that round. Third, given In the following step (indexed 2 mod 3), since all honest
this property, we show, in Lemma 2, that if BA⋆ executed users who timed out in the previous step (and therefore did
by an honest user returns that consensus was achieved on not finish) will vote block_hash, the CountVotes procedure
some value for a particular round, then for all other honest called by any honest user will return block_hash. Further-
users BA⋆ indicates consensus on the same value. Fourth, more, honest committee members for this step, who finished
in Lemma 3, we prove that BA⋆ executed by an honest user in the previous step, have also sent their votes. Therefore,
always eventually returns a value. Finally, in Lemma 4, we since we select a committee sufficiently large such that with
show that if all honest users called BA⋆ with the same value high probability #good > Tstep · τstep , CountVotes will return
and round, then they all agree on that value for the round block_hash. This consensus will carry forward until the
and furthermore, the consensus is final. □ next step indexed 1 mod 3, where all users will agree on
block_hash. □
Lemma 1. The probability that CountVotes, called for the
same round and step by two honest users, returns some value Lemma 3. Under strong synchrony, Algorand eventually con-
v 1 , timeout for one honest user, and returns a value v 2 < firms a block in each round.
{timeout,v 1 } for another honest user is negligible.
Proof. Algorand confirms a block when BA⋆ reaches con-
Proof. Under strong synchrony, the two conditions about the sensus. It is sufficient to show that BinaryBA⋆ eventually
committee from §7.5 (analyzed in §B.2) hold with overwhelm- reaches consensus, which implies that BA⋆ also reaches con-
ing probability. Since CountVotes returned v 1 , timeout for sensus, since the rest of BA⋆ has a limited number of steps.
an honest user, that user counted more than Tstep ·τstep votes By Lemma 2, it is sufficient to show that only one honest
for v 1 by committee members in the particular round and user confirms a block (since the rest will finish after that user
step of BA⋆. In order to cross the Tstep · τstep threshold v 1 within at most 3 steps). Let us consider the steps of BA⋆ in
must receive more than half of the honest committee mem- sequences of three, as in one loop iteration in Algorithm 8.
bers’ votes. We select a committee large enough such that So if an honest user finished BinaryBA⋆ in the first two steps,
the safety condition, 12 #good + #bad ≤ Tstep ·τstep , holds with we are done.
overwhelming probability. Since honest committee mem- Let us assume that this is not the case, and therefore,
bers only vote for one value, then when the safety condition all honest users reach the third “common coin” step of
holds, no other value v 2 can receive enough votes. □ BinaryBA⋆. If in that step all honest users receive more

23
than Tstep · τstep votes for value v (one of two possible op- C.3 Efficiency
tions), then they will all vote for that value in the next steps, Theorem 5. Under strong synchrony, BA⋆ reaches final con-
and reach consensus on that value within the next two steps. sensus in 4 steps if the highest priority block proposer was
Let us now assume the complementary case, that at least honest, and otherwise is expected to reach consensus in 13
some honest users change their vote according to the com- steps. The probability BinaryBA⋆ does not complete within
mon coin. Assume further that the user setting the coin MaxSteps = 150 steps even in the worst case is negligible
(according to Algorithm 9) is honest; therefore, all honest (< 3 · 10−9 ).
users who did not observe sufficiently many votes for a value
v in the coin step see the same random coin and change their Proof. The first part of the theorem (reaching fast and final
vote to that coin (since the network is strongly synchronous, consensus when the highest priority block proposer is hon-
all honest users receive messages within a bounded delay). est) was shown in Lemma 4. We focus on the second part,
Therefore, there are only three cases to consider: that BA⋆ is expected to reach consensus within 13 steps in
the worst case.
• Some honest users counted enough votes for Let us analyze the probability that the common coin leads
block_hash and the rest observe the coin. In this to consensus. The binary-agreement phase of BA⋆ consists
case at the end of the coin step, all honest users will of three repeated steps. A malicious highest-priority block
vote for block_hash if the common coin is 0 (that is, with proposer can make the first two steps of BinaryBA⋆ go with-
probability 1/2). out consensus, but after every “common coin” step, the hon-
est users will reach consensus with probability 1/3 in the
• Some honest users counted enough votes for following two steps (see Lemma 3). Therefore, following the
empty_block and the rest observe the coin. In this first 2 steps, every sequence of three steps reaches consensus
case at the end of the coin step, all honest users will with probability 1/3. Thus, in total, binary-agreement re-
vote for empty_hash if the common coin is 1 (that is, quires an expected number of 2 + 3 ∗ 3 = 11 steps in the worst
with probability 1/2). case, and BA⋆ has two extra initial steps for the reduction
to binary-agreement, i.e., expected 13 steps in total.
• All honest users observe the coin. In this case all Since in each sequence of 3 steps of BinaryBA⋆ (except
honest users will vote for the common coin. The agree- the first iteration), it holds that BA⋆ reaches consensus with
150
ment will carry forward until BinaryBA⋆ completes in probability 1/3, then after MaxSteps = 150 steps is 23 3 <
−1
the next two steps. 3 · 10−9 . □

Importantly, the case where some honest users counted

enough votes for empty_block while others counted enough
votes for block_hash has negligible probability. See Lemma 1.
Therefore, if the user setting the coin is honest, we reach
consensus with probability of at least 1/2. Since the user
setting the coin is selected at random out of the committee,
and in the committee at least 2/3 of the members are honest,
then the probability of reaching consensus is at least 12 ·
2 1
3 = 3 . Since the probability of reaching consensus in every
sequence of 3 steps is greater than 0, the protocol eventually
reaches consensus. □

Lemma 4. Under strong synchrony, if all honest users start

BA⋆ with the same value for the same round, then they reach
a final consensus on that value.

Proof. Let us follow the BA⋆ protocol and show that this is
correct. All honest users will call the reduction with the same
hash of the block, call it block_hash. Therefore in the first
step of the reduction all honest users will count more than a
threshold votes for block_hash, and will also vote for it in the
second step of the reduction, where they will again count
more than a threshold of votes for block_hash, and therefore
all honest users will call BinaryBA⋆ with block_hash and
return after exactly one step, and therefore also vote on
block_hash as a final consensus. □

24