ALGORAND

The Efficient Public Ledger

Silvio MicaliCSAIL, MIT

Cambridge, MA 02139, USAsilvio@csail.mit.edu

November 18, 2016

EXTENDED ABSTRACT

Abstract

A public ledger is a tamperproof sequence of data that can be read and augmented by everyone.Public ledgers have innumerable and compelling uses. They can secure, in plain sight, all kindsof transactions —such as titles, sales, and payments— in the exact order in which they occur.Public ledgers not only curb corruption, but also enable very sophisticated applications —such ascryptocurrencies and smart contracts. They stand to revolutionize the way a democratic societyoperates. As currently implemented, however, they scale poorly and cannot achieve their potential.

Algorand is a truly democratic and efficient way to implement a public ledger. Unlike priorimplementations based on proof of work, it requires a negligible amount of computation, andgenerates a transaction history that will not fork with overwhelmingly high probability.

Algorand works with traditional blockchains, but also puts forward alternative and more efficientways to structure blocks of data, which may be of independent interest.

For concreteness, we shall describe Algorand only as a money platform.

Note: This paper is based on the previous one of Gorbunov and Micali, “Democoin: A PubliclyVerifiable and Jointly Serviced Cryptocurrency”, https://eprint.iacr.org/2015/521 May 30, 2015.

These technologies are the object of the following patent applications: US62/117,138 US62/120,916US62/142,318 US62/218,817 US62/314,601 PCT/US2016/018300 US62/326,865 62/331,654 US62/333,340US62/343,369 US62/344,667 US62/346,775 US62/351,011 US62/653,482 US62/352,195 US62/363,970US62/369,447 US62/378,753 US62/383,299 US62/394,091 US62/400,361 US62/410,721

arX

iv:1

607.

0134

1v7

[cs

.CR

] 1

6 N

ov 2

016

1 Introduction

Money is becoming increasingly virtual. It has been estimated that about 80% of United Statesdollars today only exist as ledger entries [2]. Other financial instruments are following suit.

In an ideal world, in which we could count on a universally trusted central entity, immuneto all possible cyber attacks, money and other financial transactions could be solely electronic.Unfortunately, we do not live in such a world. Accordingly, decentralized cryptocurrencies, suchas Bitcoin [7], and “smart contract” systems, such as Ethereum, have been proposed [5]. At theheart of these systems is a shared ledger that reliably records a sequence of transactions, as variedas payments and contracts, in a tamperproof way. The technology of choice to guarantee suchtamperproofness is the blockchain. Blockchains are behind applications such as cryptocurrencies [7],financial applications [5], and the Internet of Things [8]. Several techniques to manage blockchain-based ledgers have been proposed: proof of work [7], proof of stake [6], practical Byzantine fault-tolerance [23], or some combination.

Currently, however, ledgers can be inefficient to manage. For example, Bitcoin’s proof-of-workapproach requires a vast amount of computation, is wasteful and scales poorly. In addition it defacto concentrates power in very few hands.

We therefore wish to put forward a new method to implement a public ledger that offers theconvenience and efficiency of a centralized system run by a trusted and inviolable authority, withoutthe inefficiencies and weaknesses of current decentralized implementations. We call our approachAlgorand, because we use algorithmic randomness to select, based on the ledger constructed so far,a set of verifiers who are in charge of constructing the next block of valid transactions. Naturally,we ensure that such selections are provably immune from manipulations and unpredictable untilthe last minute, but also that they ultimately are universally clear.

Algorand’s approach is quite democratic, in the sense that neither in principle nor de facto itcreates different classes of users (as “miners” and “ordinary users” in Bitcoin). In Algorand “allpower resides with the set of all users”.

One notable property of Algorand is that its transaction history may fork only with very smallprobability (e.g., one in a trillion). Algorand can also address some legal and political concerns.

The Algorand approach applies to blockchains and, more generally, to any method of generatinga tamperproof sequence of blocks. We actually put forward a new method —alternative to, andmore efficient than, blockchains— that may be of independent interest.

2 Bitcoin’s Assumption and Technical Problems

Bitcoin is a very ingenious system and has inspired a great amount of subsequent research. Yet, itis also problematic. Let us summarize its underlying assumption and technical problems —whichare actually shared by essentially all cryptocurrencies that, like Bitcoin, are based on proof-of-work.

For some information about the proof-of-work approach, see the last section of our appendix,Section D. For this summary, it suffices to recall that, in Bitcoin, a user may own multiple publickeys of a digital signature scheme, that money is associated with public keys, and that a payment isa digital signature that transfers some amount of money from one public key to another. Essentially,Bitcoin organizes all processed payments in a chain of blocks, B1, B2, . . ., each consisting of multiplepayments, such that, all payments of B1, taken in any order, followed by those of B2, in any order,etc., constitute a sequence of valid payments. Each block is generated, on average, every 10 minutes.

1

This sequence of blocks is a chain, because it is structured so as to ensure that any change, evenin a single block, percolates into all subsequent blocks, making it easier to spot any alteration ofthe payment history. (As we shall see, this is achieved by including in each block a cryptographichash of the previous one.) Such block structure is referred to as a blockchain.

Assumption: Honest Majority of Computational Power Bitcoin assumes that no maliciousentity (nor a coalition of coordinated malicious entities) controls the majority of the computationalpower devoted to block generation. Such an entity, in fact, would be able to modify the blockchain,and thus re-write the payment history, as it pleases. In particular, it could make a payment ℘,obtain the benefits paid for, and then “erase” any trace of ℘.

Technical Problem 1: Computational Waste Bitcoin’s proof-of-work approach to blockgeneration requires an extraordinary amount of computation. Currently, with just a few hundredthousands public keys in the system, the top 500 most powerful supercomputers can only mustera mere 12.8% percent of the total computational power required from the Bitcoin players. Thisamount of computation would greatly increase, should significantly more users join the system.

Technical Problem 2: Concentration of Power Today, due to the exorbitant amount ofcomputation required, a user, trying to generate a new block using an ordinary desktop (let alone acell phone), expects to lose money. Indeed, for computing a new block with an ordinary computer,the expected cost of the necessary electricity to power the computation exceeds the expected reward.Only using pools of specially built computers (that do nothing other than “mine new blocks”), onemight expect to make a profit by generating new blocks. Accordingly, today there are, de facto, twodisjoint classes of users: ordinary users, who only make payments, and specialized mining pools,that only search for new blocks.

It should therefore not be a surprise that, as of recently, the total computing power for blockgeneration lies within just five pools. In such conditions, the assumption that a majority of thecomputational power is honest becomes less credible.

Technical Problem 3: Ambiguity In Bitcoin, the blockchain is not necessarily unique. Indeedits latest portion often forks: the blockchain may be —say— B1, . . . , Bk, B

′k+1, B

′k+2, according to

one user, and B1, . . . , Bk, B′′k+1, B

′′k+2, B

′′k+3 according another user. Only after several blocks have

been added to the chain, can one be reasonably sure that the first k + 3 blocks will be the samefor all users. Thus, one cannot rely right away on the payments contained in the last block ofthe chain. It is more prudent to wait and see whether the block becomes sufficiently deep in theblockchain and thus sufficiently stable. To see how this may happen see Appendix D

Separately, law-enforcement and monetary-policy concerns have also been raised about Bitcoin.1

1The (pseudo) anonymity offered by Bitcoin payments may be misused for money laundering and/or the financingof criminal individuals or terrorist organizations. Traditional banknotes or gold bars, that in principle offer perfectanonymity, should pose the same challenge, but the physicality of these currencies substantially slows down moneytransfers, so as to permit some degree of monitoring by law-enforcement agencies.

The ability to “print money” is one of the very basic powers of a nation state. In principle, therefore, the massiveadoption of an independently floating currency may curtail this power. Currently, however, Bitcoin is far from beinga threat to governmental monetary policies, and, due to its scalability problems, may never be.

2

3 Algorand, in a Nutshell

Algorand’s Two Pillars. Algorand was put forward, starting last July, in a sequence of ArXivpapers [32]. Its basic approach has two pillars.

1. New Byzantine Agreement. Algorand replaces proof-of-work consensus with a stronger formof Byzantine agreement [15]. Informally, Byzantine agreement (BA) is a communication protocolenabling a set of players, each of which holds a possibly different initial value, to agree on a singlevalue v. Such agreement is reached by all honest players —that is, by those who scrupulously followthe protocol— despite the fact that a minority of the players are malicious and can deviate fromthe protocol in an arbitrary and coordinated manner.

In our case, the initial values are candidate blocks, and the block on which agreement is reachedis certified by the digital signatures of a sufficient number of players, and then propagated throughthe network, so that all users can add it to the blockchain.

As we shall see, we do not just rely on existing Byzantine agreement protocols, but put forwarda new BA protocol that is much faster than all previous ones, and enjoys a novel property, playerreplaceability, that makes it very secure in our very adversarial environment.

2. Cryptographic Sortition. Although very fast, the new BA protocol would still be unwieldyif played by all users in the system. Accordingly, we choose its players to be a much smaller subsetof the set of all users. To avoid a different kind of concentration-of-power problem, each new blockBr will be constructed and agreed upon, via our new BA protocol, by a separate set of selectedverifiers, SV r. In principle, selecting such a set might be as hard as selecting Br directly. Wetraverse this potential problem by an approach that we term, embracing the insightful suggestionof Maurice Herlihy, cryptographic sortition. Sortition is the practice of selecting officials at randomfrom a large set of eligible individuals [33]. Sortition was practiced across centuries: for instance, bythe republics of Athens, Florence, and Venice. In modern judicial systems, random selection is oftenused to choose juries. In our distributed system, however, choosing the random coins necessary torandomly select the members of each verifier set SV r is already problematic. We thus resort tocryptography in order to select each verifier set, from the population of all users, in a way that isguaranteed to be automatic (i.e., requiring no message exchange) and random. In essence, we usea cryptographic function to automatically determine, from the previous block Br−1, the verifier setSV r in charge to choose the next block Br. Since malicious users can affect the composition ofBr−1 (e.g., by choosing some of its payments), we specially construct and use additional inputs soas to prove that the verifier set SV r is indeed randomly chosen.2

Two Main Challenges Our main challenges are that:

(a) Our setting is permissionless.

New users can join Algorand at any time they want.

(b) Our adversary is dynamic and very powerful.

Our adversary can instantaneously corrupt any user he wants, at any time he wants (subjectonly to a total “budget”), and perfectly coordinate all malicious users. In particular, he cancorrupt the entire, randomly selected, verifier set SV r, as soon as it becomes known.

2The idea of cryptographic sortition actually goes back to Democoin the earlier ancestor of this paper [4].

3

A Two-Phase Construction We construct our Algorand system in two phases. First, weassume that the Adversary cannot introduce new corrupted players and can only corrupt up toa 1/3 of the total number of users, where each user owns only one key. Then, we remove theseassumptions, so as to let users own how many keys they want, and the adversary introduce all themalicious users he wants, with the only constraint that at most 1/3 of the money is in malicioushands. (Accordingly, we may reason in terms of numbers of malicious users for most of this paper,including this section.)

Network Setting Our network setting is neither totally synchronous, nor totally asynchronous.We assume that every message sent is received by a fixed percentage of the users within a knownamount of time, which depends on the message size. We actually envisage just two message sizes:1MB (for blocks) and 1KB (for payments and control messages).

This particular choice is in line with Bitcoin, whose blocks are constrained to be at most 1MB-long. (Technically, however, both message sizes are parameters that can be chosen arbitrarily.)Experimentally, Decker and Wattenhofer [31] show that, in Bitcoin, a 1KB-message message takesone second to reach 95% of the users, and a 1MB block consistently reaches the same percentageof the users in less than 1.5 min.

Main Properties Note that the above reported block-transmission latency is much smaller thanBitcoin’s block-generation latency, which is, by design, 10 minutes on average. This is so, becausethe need to avoid forks, that, in Bitcoin, are an unfortunate byproduct of its proof-of-work approachto consensus. Other unfortunate byproducts, as already discussed, are computational waste andinherent ambiguity. Since a block recently added to the blockchain has a reasonable probability ofleaving the chain, typically users wait that a block is at least 3-deep in the chain. Accordingly, thetrue latency of Bitcoin is 30 minutes, rather 10.

The main advantages of Algorand are as follows. Despite the presence of our powerful adversary,provided that a fraction greater than 2/3 of the money is owned by honest users,

• No forks arise, except with negligible probability.

• The amount of computation required is minimal, and

• The block-generation latency is close to the block-propagation latency.

We stress that, due to the absence of forks, the latter latency coincides with the true latency.

In Algorand, a new block is produced in time Λ + (3 + m)λ, if Λ is the time necessary for xdifferent blocks to reach a given fraction of the user (e.g., 95%), λ is the time needed for X 1KB-long messages to reach the same percentage of users, and 2−m is the probability with which weaccept that something may go wrong (e.g., a fork appears). For instance, if 90% of the money is inhonest hands, then x is a handful and X is about 200. Algorand’s performance degrades when the“percentage of money controlled by the Adversary gets closer to 1/3. (For instance, X becomes750 if the Adversary controls 20% of the money).

Simple Honest Majority With Vinod Vaikunthanatan, adapting techniques of Katz and Koo[25], we have developed a version of Algorand that, with acceptable additional complications, workswith a simple majority, and thus relies on much smaller verifier sets for each percentage of honestusers in the general population. We’ll describe these changes in a forthcoming paper.

4

An Additional Property: Lazy Honesty Assuming that at most 1/3 of the players arecontrolled (and perfectly coordinated) by the Adversary is one thing, but assuming that 2/3 ofall users are honest, are always on-line, and continually participate to the protocol is a differentthing. A few “absences” among honest players, as those due to sudden loss of connectivity or theneed of rebooting, are automatically tolerated (because we can always consider such few playersto be malicious), but if honest users went “on vacation en mass”, it would be a great gift to theAdversary. In such a case, in fact, although the majority of the users were honest, the majorityof the users actually participating to the protocol may be malicious. After all, malice never sleeps(and does not go on vacation). Algorand, however, can work safely with “lazy-but-honest” users.Let us explain.

Lazy Honesty. Roughly speaking, a user i is lazy-but-honest if (1) he follows all his prescribedinstructions, when he is asked to participate to the protocol, and (2) he is asked to participate tothe protocol only very rarely —e.g., once a week— with suitable advance notice, and potentiallyreceiving significant rewards when he participates.

With such a relaxed notion of honesty, we may be more confident that honest people will be athand when we need them, and Algorand guarantee that, when this is the case, the system operatessecurely, even if the majority of the participating players is malicious.

Closely related work Bitcoin has inspired a tremendous amount of research. Most of theliterature based on proof-of-work is quite orthogonal to our approach. Our approach, however, isa kind of proof of stake [6], in the sense that users with more money have a proportionally higher“voting power”.

The work closest to ours is that of Bentov, Pass and Shi, which appeared last September inthe e-print archive [?]. They also replace proof of work with Byzantine agreement, and use hashfunctions to select leaders.

In addition, they also tackle the problem of relying on the continual participation of honestusers, by putting forward the “sleepy consensus” model, in which honest people transition frombeing alert (and well connected) and asleep (and unreachable).

There are, however, considerable differences as well. Mainly,

(a′) Their setting is permissioned.

By contrast, in ours, any one can join the system, without any permission, whenever he wants.

(b′) Their adversary is static one: who is honest and malicious is fixed at the start.

By contrast, our adversary is dynamic and can corrupt anyone he wants, when he wants.

However, while our adversary can corrupt less than 1/3 of the players, theirs can corrupt up to1/2 of te players.

Other smaller differences exist, in particular about the level of synchrony allowed. Also, lazyhonesty and sleepy consensus share a common concern, but are very different solutions.3

3The fact that sleepy consensus requires the majority of the alert players to be honest testifies to the difference ofthe two models.

5

4 Specific Challenges and Corresponding Techniques

A First Challenge and The Quantity Qr We use a cryptographic hash function, modelled asa random oracle, so that, without the need to exchange any messages, the past history (in fact, thelast block Br−1) automatically determines the next verifier set, and leader, in charge of determiningthe new block Br.

The challenge with this approach is that, by just choosing a slightly different payment in theprevious round, our powerful Adversary gains a tremendous control over the next leader. Even ifhe only controlled only 1/1000 of the players/money in the system. In fact, he can ensure that allleaders are malicious. (See the Intuition Section 6.)

Similar easy choices also fail to be secure in the presence of our Adversary. To counter thischallenge is not trivial. We purposely construct and continually update, a separate block quantity,Qr, so as to guarantee that it is unpredictable and in fact not even influentiable by our powerfulAdversary.

A Second Challenge and Secret Credentials Randomly and unambiguously choosing theverifier set and the leader in charge of block Br given block is not enough. Since the last builtblock, Br−1, must be known in order to process the next block, the last non-influentiable quantityQr−1 must be known too. Accordingly, so are the verifiers and the leader in charge to computethe block Br. Thus, our powerful Adversary might immediately corrupt all of them, before theyengage in any discussion about Br, so as to get full control over the block they certify.

To prevent this, leaders (and actually verifiers too) secretly learn of their role, but can compute aproper credential, capable of proving to everyone that indeed have that role. When a user privatelyrealizes that he is the leader for the next block, first he secretly assembles the new Br and thendisseminates it so that can be certified, disseminating also his own credential. This way, thoughthe Adversary will immediately realize who the leader of the next block is, and although he cancorrupt him right away, it will be too late for him to influence the choice of Br. Indeed, he cannotcall back the leader’s message no more than a powerful government can put back in the bottle amessage virally spread by WikiLeaks.

As we shall see, we cannot guarantee leader uniqueness, nor that everyone is sure who the leaderis, including the leader himself! But unambiguous progress will be guaranteed.

A Third Challenge and Replaceable-Player Protocols Announcing a block and then “die”(i.e., been corrupted by the Adversary) is fine for the leader of a verifier set SV r, because his jobis done. But for the verifiers in SV r things are less simple. Indeed, being in charge of selecting thenew block Br, they must run Byzantine agreement on the block proposed by the leader (and thencertify the agreed upon block with sufficiently many signatures). The problem is that BA protocolsrequire multiple steps. Our new BA protocol is no exception. This protocol iterates a sub-protocolconsisting of a single step, and each iteration reaches agreement with probability 1/3, assumingthat the >2/3 of the players are honest. This assumption cannot hold in our setting, because theAdversary, although unable to corrupt 1/3 of the all users, can certainly corrupt all members ofSV r, because it consists of a very small subset of the set of all users.

Fortunately our protocol is player-replaceable. This novel property means that, while everyonewatches the messages propagated by the few actual players of the protocol, at each step, a totallynew set of players can take over, and yet the protocol continues to work properly.

6

At each steps, the new set of players will be randomly and independently chosen, and thus haveempty intersection with the players of the previous steps. In addition, it can even have a totallydifferent number of players than the previous sets. Furthermore, the members of each set do notknow who the next set of players will be, and do not secretly pass any internal state.

The replaceable-player property is actually crucial to defeat the dynamic and very powerfulAdversary we envisage. It is not, however, enjoyed by all BA protocols played in our networksand message propagation model. The fact that the notion of a Byzantine agreement does not haveany privacy requirements (but only correctness ones) is certainly fundamental for the possibilityof player-replaceable BA protocols to exist, but is far from being sufficient. For instance, it is notclear whether the famous authenticated Byzantine agreement protocol of Dolev and Strong [18] isplayer-replaceable. Certainly, its original proof fails to apply to this new model.

We believe that replaceable-players protocols are possible for a variety of other tasks. They willbe crucial to execute securely small sub-protocols embedded in a larger universe of players witha dynamic adversary, who being able to corrupt even a small fraction of the total players, has nodifficulty in corrupting all the players in the smaller sub-protocol.

5 Model, Discussion, and New Block Structures

To describe Algorand’s adversarial and communication models, we first recall some basic notions.

5.1 Cryptographic Primitives

Algorand could be based on a single primitive, verifiable random function [34]. We prefer, however,to rely on two, simpler, and more traditional primitives.

Ideal Hashing. We shall rely on an efficiently computable cryptographic hash function, H, thatmaps arbitrarily long strings to binary strings of fixed length. Following a long tradition, we modelH as a random oracle, essentially a function mapping each possible string s to a randomly andindependently selected (and then fixed) binary string, H(s), of the chosen length.

In this paper, H has 256-bit long outputs. Indeed, such length is short enough to make thesystem efficient and long enough to make the system secure. For instance, we want H to be collision-resilient. That is, it should be hard to find two different strings x and y such that H(x) = H(y).When H is a random oracle with 256-bit long outputs, finding any such pair of strings is indeeddifficult. (Trying at random, and relying on the birthday paradox, would require 2256/2 = 2128

trials.)

Digital Signatures. Digital signatures allow users to to authenticate information to each otherwithout sharing any sharing any secret keys. A digital signature scheme consists of three fastalgorithms: a probabilistic key generator G, a signing algorithm S, and a verification algorithm V .

Given a security parameter k, a sufficiently high integer, a user i uses G to produce a pair ofk-bit keys (i.e., strings): a “public” key pki and a matching “secret” signing key ski. Crucially, apublic key does not “betray” its corresponding secret key. That is, even given knowledge of pki, noone other than i is able to compute ski in less than astronomical time.

7

User i uses ski to digitally sign messages. For each possible message (binary string) m, i firsthashes m and then runs algorithm S on inputs H(m) and ski so as to produce the k-bit string

sigpki(m) , S(H(m), ski) .4

The binary string sigpki(m) is referred to as i’s digital signature of m (relative to pki), and can bemore simply denoted by sigi(m), when the public key pki is clear from context.

Everyone knowing pki can use it to verify the digital signatures produced by i. Specifically, oninputs (a) the public key pki of a player i, (b) a message m, and (c) a string s, that is, i’s allegeddigital signature of the message m, the verification algorithm V outputs either YES or NO.

The properties we require from a digital signature scheme are:

1. Legitimate signatures are always verified: If s = sigi(m), then V (pki,m, s) = Y ES; and

2. Digital signatures are hard to forge: Without knowledge of ski the time to find a string s suchthat V (pki,m, s) = Y ES, for a message m never signed by i, is astronomically long.

(Following the strong security requirement of Goldwasser, Micali, and Rivest [14], this is trueeven if one can obtain the signature of any other message.)

3. Uniqueness. It is hard to find strings pk′, m, s, and s′ such that

s 6= s′ and V (pk′,m, s) = V (pk′,m, s′) = 1.

(Note that the uniqueness property holds also for strings pk′ that are not legitimately generatedpublic keys. In particular, however, the uniqueness property implies that, if one used thespecified key generator G to compute a public key pk together with a matching secret key sk,and thus knew sk, it would be essentially impossible also for him to find two different digitalsignatures of a same message relative to pk.)

Accordingly, to prevent anyone else from signing messages on his behalf, a player i must keep hissigning key ski secret (hence the term “secret key”), and to enable anyone to verify the messageshe does sign, i has an interest in publicizing his key pki (hence the term “public key”).

In general, a message m is not retrievable from its signature sigi(m). In order to virtually dealwith digital signatures that satisfy the conceptually convenient “retrievability” property (i.e., toguarantee that the signer and the message are easily computable from a signature, we define

SIGpki(m) = (i,m, sigpki(m)) and SIGi(m) = (i,m, sigi(m)), if pki is clear.

5.2 The Idealized Public Ledger

Algorand tries to mimic the following payment system, based on an idealized public ledger.

1. The Initial Status. Money is associated with individual public keys (privately generated andowned by users). Letting pk1, . . . , pkj be the initial public keys and a1, . . . , aj their respectiveinitial amounts of money units, then the initial status is

S0 = (pk1, a1), . . . , (pkj , aj) ,

which is assumed to be common knowledge in the system.

4Since H is collision-resilient it is practically impossible that, by signing m one “accidentally signs” a differentmessage m′.

8

2. Payments. Let pk be a public key currently having a ≥ 0 money units, pk′ another publickey, and a′ a non-negative number no greater than a. Then, a (valid) payment ℘ is a digitalsignature, relative to pk, specifying the transfer of a′ monetary units from pk to pk′, togetherwith some additional information. In symbols,

℘ = SIGpk(pk, pk′, a′, I,H(I)),

where I represents any additional information deemed useful but not sensitive (e.g., timeinformation and a payment identifier), and I any additional information deemed sensitive (e.g.,the reason for the payment, possibly the identities of the owners of pk and the pk′, and so on).

We refer to pk (or its owner) as the payer, to each pk′ (or its owner) as a payee, and to a′ asthe amount of the payment ℘.

Free Joining Via Payments. Note that users may join the system whenever they want bygenerating their own public/secret key pairs. Accordingly, the public key pk′ that appears inthe payment ℘ above may be a newly generated public key that had never “owned” any moneybefore.

3. The Magic Ledger. In the Idealized System, all payments are valid and appear in a tamper-prooflist L of sets of payments “posted on the sky” for everyone to see:

L = PAY 1, PAY 2, . . . ,

Each block PAY r+1 consists of the set of all payments made since the appearance of blockPAY r. In the ideal system, a new block appears after a fixed (or finite) amount of time.

Discussion.

• More General Payments and Unspent Transaction Output. More generally, if a public keypk owns an amount a, then a valid payment ℘ of pk may transfer the amounts a′1, a

′2, . . .,

respectively to the keys pk′1, pk′2, . . ., so long as

∑j a′j ≤ a.

In Bitcoin and similar systems, the money owned by a public key pk is segregated into separateamounts, and a payment ℘ made by pk must transfer such a segregated amount a in its entirety.If pk wishes to transfer only a fraction a′ < a of a to another key, then it must also transfer thebalance, the unspent transaction output, to another key, possibly pk itself.

Algorand also works with keys having segregated amounts. However, in order to focus on thenovel aspects of Algorand, it is conceptually simpler to stick to our simpler forms of paymentsand keys having a single amount associated to them.

• Current Status. The Idealized Scheme does not directly provide information about the currentstatus of the system (i.e., about how many money units each public key has). This informationis deducible from the Magic Ledger.

In the ideal system, an active user continually stores and updates the latest status information,or he would otherwise have to reconstruct it, either from scratch, or from the last time hecomputed it. In Appendix A.3, however, we shall augment Algorand so as to enable its usersto reconstruct the current status in an efficient manner.

9

• Security and “Privacy”. Digital signatures guarantee that no one can forge a payment byanother user. In a payment ℘, the public keys and the amount are not hidden, but the sensitiveinformation I is. Indeed, only H(I) appears in ℘, and since H is an ideal hash function, H(I)is a random 256-bit value, and thus there is no way to figure out what I was better than bysimply guessing it. Yet, to prove what I was (e.g., to prove the reason for the payment) thepayer may just reveal I. The correctness of the revealed I can be verified by computing H(I)and comparing the resulting value with the last item of ℘. In fact, since H is collision resilient,it is hard to find a second value I ′ such that H(I) = H(I ′).

5.3 Basic Terms and Notations

Keys, Users, and Owners Algorand only deals with public keys (“keys” for short). A publickey i joins the system when another public key j already in the system makes a payment to i.

For color, we personify keys. We refer to a key i as a “he”, say that i is honest, that i sendsand receives messages, etc. User is a synonym for key. When we want to distinguish a key fromthe person to whom it belongs, we respectively use the term “digital key” and “owner”.

Permissionless and Permissioned Systems. A system is permissionless, if a digital key is freeto join at any time and an owner can own multiple digital keys; and its permissioned, otherwise.

Unique Representation Each object in Algorand has a unique representation. In particular,each set {(x, y, z, . . .) : x ∈ X, y ∈ Y, z ∈ Z, . . .} is ordered in a pre-specified manner: e.g., firstlexicographically in x, then in y, etc.

Clocks We assume that there is a global clock, readable by everyone. (It actually suffices toassume each key i reads his own clock that differs differs at most, say, one second from a globalclock.)

Rounds Algorand is organized in logical units, r = 0, 1, . . ., called rounds.We consistently use superscripts to indicate rounds. To indicate that a non-numerical quantityQ

(e.g., a string, a public key, a set, a digital signature, etc.) refers to a round r, we simply write Qr.Only when Q is a genuine number (as opposed to a binary string interpretable as a number), dowe write Q(r), so that the symbol r could not be interpreted as the exponent of Q.

At (the start of a) round r > 0, the set of all public keys is PKr, and the system status is

Sr ={(i, a

(r)i , . . .

): i ∈ PKr

},

where a(r)i is the amount of money available to the public key i. Note that PKr is deducible from

Sr, and that Sr may also specify other components for each public key i.For round 0, PK0 is the set of initial public keys, and S0 is the initial status. Both PK0 and

S0 are assumed to be common knowledge in the system. For simplicity, at the start of round r, soare PK1, . . . , PKr and S1, . . . , Sr.

In a round r, the system status transitions from Sr to Sr+1. Pictorially,

10

Payments In Algorand, the users continually make payments (and disseminate them in the waydescribed in subsection 5.7). A payment ℘ of a user i ∈ PKr has the same format and semanticsas in the Ideal System. Namely,

℘ = SIGi(i, i′, a, I,H(I)) .

Payment ℘ is individually valid at a round r (is a round-r payment, for short) if (1) its amount

a is less than or equal to a(r)i , and (2) it does not appear in any official payset PAY r′ for r′ < r.

(As explained below, the second condition means that ℘ has not already become effective.

A set of round-r payments of i is collectively valid if the sum of their amounts is at most a(r)i .

Paysets A round-r payset P is a set of round-r payments such that, for each user i, the paymentsof i in P (possibly none) are collectively valid. The set of all round-r paysets is PAY(r). A round-rpayset P is maximal if no superset of P is a round-r payset.

Official Paysets For every round r, Algorand publicly selects (in a manner described later on)a single (possibly empty) payset, PAY r, the round’s official payset. (Essentially, PAY r representsthe round-r payments that have “actually” happened.)

As in the Ideal System (and Bitcoin), (1) the only way for a new user j to enter the systemis to be the recipient of a payment belonging to the official payset PAY r of a given round r; and(2) PAY r determines the status of the next round, Sr+1, from that of the current round, Sr.Pictorially,

Specifically,

1. the set of public keys of round r + 1, PKr+1, consists of the union of PKr and the set of allpayee keys that appear, for the first time, in the payments of PAY r; and

2. the amount of money a(r+1)i that a user i owns in round r + 1 is the sum of ai(r) —i.e., the

amount of money i owned in the previous round (0 if i 6∈ PKr)— and the sum of amountspaid to i according to the payments of PAY r.

In sum, as in the Ideal System, each status Sr+1 is deducible from the previous payment history:

PAY 0, . . . , PAY r.

11

Discussion For conceptual simplicity, we may think that each round takes a fixed amount oftime T , so that round r starts at time rT and ends at time (r + 1)T , but such “timeliness” is notnecessary.5

The goal of a round r is, given (a) the (inductively known public key set and the) status Sr,and (b) the “outstanding” payments (i.e., the payments actually made, and circulated, which havenot yet entered an official payset), to select the official payset of round r.

We actually suggest that ℘ also specifies a round ρ, before which it cannot be valid, so as tosimplify “how far back one has to go to go to check whether ℘ had already become effective.”

5.4 Blocks and Proven Blocks

In Algorand0, the block Br corresponding to a round r specifies: r itself; the set of payments ofround r, PAY r; a quantity Qr, to be explained, and the hash of the previous block, H(Br−1).Thus, starting from some fixed block B0, we have a traditional blockchain:

B1 = (1, PAY 1, Q0, H(B0)), B2 = (2, PAY 2, Q1, H(B1)), B3 = (3, PAY 3, Q2, H(B2)), . . .

In Algorand, the authenticity of a block is actually vouched by a separate piece of information,a “block certificate” CERT r, which turns Br into a proven block, Br. The Magic Ledger, therefore,is implemented by the sequence of the proven blocks,

B1, B2, . . .

Discussion As we shall see, CERT r consists of a set of digital signatures for H(Br), those of amajority of the members of SV r, together with a proof that each of those members indeed belongsto SV r. We could, of course, include the certificates CERT r in the blocks themselves, but find itconceptually cleaner to keep it separate.)

In Bitcoin each block must satisfy a special property, that is, must “contain a solution of acrypto puzzle”, which makes block generation computationally intensive and forks both inevitableand not rare. By contrast, Algorand’s blockchain has two main advantages: it is generated withminimal computation, and it will not fork with overwhelmingly high probability. Each block Bi isfinal and safely so.

5.5 Acceptable Failure Probability

To analyze the security of Algorand we specify the probability, F , with which we are willing toaccept that something goes wrong (e.g., that a verifier set SV r does not have an honest majority).As in the case of the output length of the cryptographic hash function H, also F is a parameter.But, as in that case, we find it useful to set F to a concrete value, so as to get a more intuitivegrasp of the fact that it is indeed possible, in Algorand, to enjoy simultaneously sufficient securityand sufficient efficiency. In this paper, we set

F = 10−12 .

5As we shall see in appendix 8, this timeliness can be guaranteed, under suitable assumptions,in the initial protocolAlgorand ′ has fixed length. However, the final protocol Algorand ∗ is actually asynchronous —and different roundscan actually take a different amount of time.

12

Discussion The probability F is actually less than one in a trillion, and we believe it to beadequate in our application. Let us emphasize that 10−12 is not the probability with which theAdversary can forge the payments of an honest user. All payments are digitally signed, and thus, ifthe proper digital signatures are used, the probability of forging a payment is far lower than 10−12,and is, in fact, essentially 0. The bad event that we are willing to tolerate with probability F isthat Algorand’s blockchain forks. Notice that, with our setting of F and one-minute long rounds, afork is expected to occur in Algorand’s blockchain as infrequently as (roughly) once in 1.9 millionyears. By contrast, in Bitcoin, a forks occurs quite often. A reader more demanding than we mayset F to a lower value.

5.6 The Adversarial Model

Honest and Malicious Users A user is honest if he follows all his protocol instructions, andis perfectly capable of sending and receiving messages. A user is malicious (i.e., Byzantine, in theparlance of distributed computing) if he can deviate arbitrarily from his prescribed instructions.

The Adversary The Adversary is an efficient (technically polynomial-time) algorithm, personi-fied for color, who can immediately make malicious any user he wants, at any time he wants (subjectonly to an upperbound to the number of the users he can corrupt).

The Adversary totally controls and perfectly coordinates all malicious users. He takes all actionson their behalf, including receiving and sending all their messages, and can let them deviate fromtheir prescribed instructions in arbitrary ways. Or he can simply isolate a corrupted user sendingand receiving messages. Let us clarify that no one else automatically learns that a user i is malicious,although i’s maliciousness may transpire by the actions the Adversary has him take.

This powerful adversary however,

• Does not have unbounded computational power and cannot successfully forge the digitalsignature of an honest user, except with negligible probability; and

• Cannot interfere in any way with the messages exchanges among honest users.

Furthermore, his ability to attack honest users is bounded by one of the following assumption.

Honesty Majority of Money We consider a continuum of Honest Majority of Money (HMM)assumptions: namely, for each non-negative integer k and real h > 1/2,

HHMk > h: the honest users in every round r owned a fraction greater than h of all money inthe system at round r − k.

Discussion. Assuming that all malicious users perfectly coordinate their actions (as if controlledby a single entity, the Adversary) is a rather pessimistic hypothesis. Perfect coordination among toomany individuals is difficult to achieve. Perhaps coordination only occurs within separate groupsof malicious players. But, since one cannot be sure about the level of coordination malicious usersmay enjoy, we’d better be safe than sorry.

Assuming that the Adversary can secretly, dynamically, and immediately corrupt users is alsopessimistic. After all, realistically, taking full control of a user’s operations should take some time.

13

The assumption HMMk > h implies, for instance, that, if a round (on average) is implementedin one minute, then, the majority of the money at a given round will remain in honest hands forat least two hours, if k = 120, and at least one week, if k = 10, 000.

Note that the HMM assumptions and the previous Honest Majority of Computing Powerassumptions are related in the sense that, since computing power can be bought with money,if malicious users own most of the money, then they can obtain most of the computing power.

5.7 The Communication Model

Abstracting Away Message Propagation Message propagation —i.e., peer-to-peer “gossip”—is the only means of communication envisaged in our protocols.6 We model message propagationas a special communication channel, guaranteeing some simple property, more quantifiable thanjust “Every propagated message eventually reaches every user”. A very simple choice is as follows.

For all ρ ∈ (0, 1] and µ ∈ Z+, there exists λ such that, if a honest user propagates µ-bytemessage m at time t, then, by time t+ λ, at least a fraction ρ of the honest users receive m.

The above property, however, cannot support our Algorand protocol, without explicitly and sep-arately envisaging a mechanism to obtain the latest blockchain —by another user/depository/etc.This is so, because to construct a new block Br not only requires that sufficiently many userstimely receive the messages of a round r, but also know the previous blocks. Else, they could notdetermine whether the payments in Br are valid. Thus, sufficiently many people, must have alsoreceived a set of messages sufficient to learn Br−1. And so on. To avoid separate mechanisms, weadopt a stronger assumption.7

Message Propagation (MP) Assumption: For all honest-user percentage h ∈ (.5, 1],reachability ρ ∈ (0, 1], and message length µ ∈ Z+, there exists a latency constant λ such that, if,for j = 1, 2, . . ., a honest user j propagates a µ-byte message mj at time jλ, then, for all integersk > 1, by time kλ, at least a fraction ρ of the honest users receive the messages m1, . . . ,mk.

The above assumption is actually stronger than needed in our paper.8 However, its simplicityenables us to focus on the algorithmic aspect of our construction, and on our main message: namely,

6Essentially, as in Bitcoin, when a user propagates a message m, every active user i receiving m for the first time,randomly and independently selects a suitably small number of active users, his “neighbors”, to whom he forwards m,possibly until he receives an acknowledgement from them. The propagation of m terminates when no user receivesm for the first time.

7Note that the MP assumption may not be very much stronger than the previous one. Let both m and m′ beµ-byte messages, and that a honest i′ propagates m′ at time t − λ and that another user i propagates m at timet. Then the weaker assumption guarantees that a fraction ρ of the honest users (A) receive m′ by time t, and (B)receive m by time t + λ. The MP assumption certainly guarantees propositions A and B, but also that (C) that afraction ρ of the honest users receive both m and m′ by time t + λ. If, by time t, the propagation of m′ has notterminated and not all users have received m′, then, presumably, plenty of users will forward m′ after time t, whichmakes it realistic that almost all users who will receive m will also receive m′. The MP assumption also implies thata message m′′ propagated by a honest user at time t− 2λ is received, by time t+ λ by almost all users who receivedboth m and m′ (and so on), because m′′ has more time than m′ to reach honest users.

8Indeed, the MP assumption, as stated, holds no matter how many other messages may be propagated alongsidethemj ’s. As we shall see, however, a round of Algorand envisages propagating messages at the start of non-overlappingtime intervals of two different lengths: Λ and λ, where Λ > λ. In an interval of length Λ only a handful of 1MB-longmessages are propagated, and in one of length λ, only 1,000, 1KB-long, messages. Thus, we could restate it in a morecomplex, but also much weaker fashion, so as to reflect our actual needs.

14

even in the presence of a very powerful adversary, to implement a public ledger,the real bottleneck for implementing a public ledger is message latency, not computation.

An Adversarial Approach In analyzing our protocols, we pessimistically assume that, providedhe does not violate the MP assumption, the Adversary totally controls the delivery of all messages.In particular, without being noticed by the honest users, the Adversary he can arbitrarily decidewhich honest player receives which message when, and arbitrarily accelerate the delivery of anymessage he wants.9

5.8 Discussion: The Worst That Can Happen

It is important to realize that the advantages of the Algorand approach are not offset by significantdisadvantages. In this section, we highlight the worst that can happen in Algorand’s approach,both when its assumptions hold and when they do not. We do so in a Q-and-A format.

Q: Why are there no instructions in case of a fork?

A: Because we do not worry about very rare events.

Recall that, with one-minute rounds, a fork is expected to occur once in 1.9 million years. Withsuch a time scale, we probably should worry about what may happen to our species, ratherthan to our payment systems. (If 1.9 million years are too soon, one just lowers the acceptableprobability of failure!)

Q: This is all very nice, but to fully analyze a system, one surely must also consider also such rareevents. So: what will the instructions be in the remote case of a fork?

A: True. We are agnostic about specific instructions, but recommend choosing them so that theAdversary has nothing to gain from controlling a large fraction of the users in order to trytrying to generate a fork. For instance, consider the following option.

Mutually Assured Destruction. No future payments: all money is frozen forever.

This option is less crazy that may appear. Indeed, while in other systems forks naturally occurfor statistical reasons, in Algorand a fork will never occur, unless the Adversary tries hard tomake it occur.

In the above option, the Adversary can only gain the products and service that were immediatelyprovided to him in return of his “fork-erased” payments. At the same time, he looses all hismoney in Algorand, which has to be very substantial. Indeed, Algorand ′ are based on theHonest Majority of Money assumption, and the Adversary cannot realistically hope to generatea fork unless he controls a large fraction of the money such at least 1/3 of the total. In such acase, therefore, the Adversary expects to lose more than he gains.

Different, but also less easily explained, options are also available.

9For instance, he can immediately learn the messages sent by honest players. Thus, a malicious user i′, who isasked to propagate a message simultaneously with a honest user i, can always choose his own message m′ based onthe message m actually propagated by i. This ability is related to rushing, in the parlance of distributed-computationliterature.

15

Q0: Can the Adversary change the past payment history if he, back then, did not control the propermajority of the users/money?

A0: Absolutely not. He cannot do so even if he, from some point onwards controls all theusers/money/computing power. This is in absolute contrast with proof-of-stake/work systems.

Q1: What is the worst that can happen in a round r, if Algorand’s assumptions hold?

A1: That the elected leader `r is malicious and irrational (i.e., neglecting all incentives). In thiscase, leaving on the table all the incentives he stands to gain, he may force PAY r to be emptywithout leaving any incriminating proof of his maliciousness.

Since a leader is randomly and independently selected at each round, however, the next onewill be honest with a probability of at least 1/2. Thus, payments that do not go through in oneround can be “resubmitted” and processed in the next one, together with the new payments.

Q2: What is the worst that can happen in a round r in which Algorand’s assumptions do not hold?

A2: Even if most of selected verifiers were malicious, the worst that could happen is that

(1) a fork occurs in Algorand’s blockchain, but also that

(2) some of the malicious verifiers provably incriminate themselves.10

Q3: That doesn’t sound right. Surely, much worse should happen if the majority of the selectedverifiers are malicious. Isn’t a malicious majority in a BA protocol capable of forcing agreementon any paysets value they please?

A3: Absolutely not! The BA subroutine, even with a malicious super-majority, can only outputvalid paysets.

By totally controlling the BA protocol,the Adversary may, at most, choose which legitimate payments will go through.

5.9 Alternative Block Structures

A blockchain guarantees the tamperproofness of its blocks, but also makes operating on its blocks(e.g., proving whether a given payment is part of a given block) quite cumbersome. Shared publicledgers are not synonyms of blockchains, and will in fact benefit from better ways to structureblocks. Algorand works with traditional blockchains, but also with an alternative, more general,and more efficient way to structure blocks of information, called blocktrees, that we informallyintroduce here, and more formally present in Appendix A.

Essentially, blocktrees enable one to efficiently prove the content of an individual past block,without having to exhibit the entire blockchain.

10Let us see why event 1 cannot occur without event 2 also occurring. Recall that any official payset PAY r mustbe propagated after being digitally signed by a majority of the selected verifiers in SV r. Assume, for concreteness,that SV r consists of 100 selected verifiers. Then, for a fork to occur, there must be (at least) two distinct paysets,PAY r and PAY r, respectively signed by two sets, S and S, consisting of at least 51 selected verifiers. Thus S andS must have non-empty intersection. And for any verifier i in this intersection, i’s signatures of two different paysetshave been disseminated. Accordingly, should a fork occur,

(a) at least one malicious verifier can be punished, and(b) Algorand recovers from a fork in any pre-specified way deemed acceptable.

16

6 Intuition

This section provides some intuition for our Algorand ′ protocol, and can be skipped if so desired.Such intuition is provided by sketching a functionally equivalent protocol, Algorand0, that has thesame underlying logical structure as Algorand ′, but is much simpler, in fact idealized, because basedon very strong assumptions, which will be promptly removed in section 8.

6.1 Temporary Simplifying Assumptions

1. Long Corruption Time: The Adversary needs more than 40 rounds to corrupt honest users.

Recall that in Algorand’s model, the Adversary can instantaneously corrupt any user he targets.Temporary assumption 1 dramatically reduces this ability of the Adversary by ensuring that,if the Adversary attacks a user i in a round r, then i remains honest at least until round r+ 40.

This assumption may be reasonable, as corrupting users is not easy and requires some time.

2. Honest Majority of Users. The majority of the users are honest.

This assumption may be meaningful in permissioned systems, where one can have some abilityto vet the users who joins the system. (We shall soon replace it with the Honest Majority ofMoney, which is instead meaningful both in permissioned and permissionless systems.)

3. No Sybil Attacks: The Adversary cannot introduce malicious users in the system.

Of course, this assumption does not prevent the Adversary from corrupting the already existingusers he wants (as long as he does not exceed his “budget”), but does excludes the possibilitythat he may invalidate the Majority of Users Assumption by bringing in loads of new andalready malicious users.

This assumption is patently false in a permissionless system.

4. Full Reachability: All propagated messages reach all users within time π.

Under this assumption the underlying communication network is totally reliable, making ittrivial to synchronize protocol steps, so as to time-out malicious players who wish to cause timedelay by slowing down protocol progress, etc.

This assumption is certainly false, unless π is “essentially infinite”.

5. Continual Participation: Honest users run the Algorand protocol in the background.

That is, unless he is temporarily disconnected from the Internet (or his laptop temporarilystops working), a honest user participates to the protocol whether or not he wishes to make,receive, or see “the fate of” a payment ℘.

This assumption is actually reasonable. (Since Algorand’ computational burden is essentiallyminimal, one may expect that the computer of a honest user continually runs the protocolin the background, without involving i at a personal level.) Anyway, as we shall see, we canreplace it with “lazy honesty”, a more relaxed notion of behavior for a honest user.

17

6.2 Objectives

Assume, for a moment, that every user is honest. Then, every round could have length π, theupperbound to message propagation of Temporary Assumption 4. Indeed, round r could start attime r ·π, end before time (r+ 1) ·π, and generate the payset PAY r as follows. At time r ·π, everyuser starts propagating all the round-r payments he has received. By time (r + 1) · π, every userreceives all the propagated payments, and thus all round-r payments. Thus every user individuallycomputes PAY r to be the union of all such payments.

In this idyllic setting, the following two crucial properties hold:

1. Perfect Correctness. All honest users agree on PAY r.

2. Completeness 1. With probability 1, PAY r includes all round-r payments of honest users.

In a realistic setting, however, a malicious user µ may try hard to violate either property. To besure, he cannot fake any round-r payment of an honest user i, because he cannot forge i’s digitalsignatures. He certainly could propagate his own invalid payments, but these will not fool honestusers who will be able to recognize and reject them. A better strategy would be for µ to arrangethat only some, but not all, honest users receive a legitimate payment of his, ℘µ. Worse, µ couldchoose two distinct payments, ℘µ and ℘′µ, that are individually valid, but not collectively valid(because the sum of their amounts exceeds the money owned by µ). Algorand thus needs to ensurethat, by so acting, malicious players may not cause dissent about the official payset of a round.

Of course, guaranteeing perfect correctness alone is trivial: everyone always chooses the officialpayset PAY r to be empty. But in this case, the system would have completeness 0. Unfortunately,guaranteeing both perfect correctness and completeness 1 is not easy in the presence of malicioususers. Algorand thus adopts a more realistic objective. Informally, letting h denote the percentageof users who are honest, where h > 1/2, the goal of Algorand is

Guaranteeing, with overwhelming probability, perfect correctness and completeness h.

Privileging correctness over completeness seems a reasonable choice: payments not processed inone round can be processed in the next, but one should avoid forks, if possible.

Reliance on Selected Verifiers At the highest level, Algorand delegates choosing the officialpayset PAY r, among all paysets of round r, to a small subset of PKr, SV r, consisting of the selectedverifiers or the round-r verifiers, who collectively have the power to determine PAY r. Algorandalso specifies other important aspects, such as how to guarantee that the right information reachesthe selected verifiers, the process by which they reach their decisions, and the way in which theirdecisions are communicated to all users in the system. But verifier selection is the first crucialaspect of Algorand’s overall strategy.

The simplest way of selecting the round-r verifiers is, of course, to choose a single outside entity,v, to act always as the sole verifier in each round r. Such a choice, however, constitutes a fullycentralized system, with all its drawbacks. A better, yet still simple solution would be to rely, foreach round r, on a fixed small set of verifiers, v1, . . . , vn. Yet, no matter what mechanism they useto choose and publicize the official paysets, this approach nonetheless continues to suffer from atleast the following two drawbacks:

1. It makes the system vulnerable to cyber attacks. Indeed, a sufficiently resourceful and determinedattacker might eventually gain control of a majority of a small set of verifiers.

18

2. It makes the system subject to internal corruption. It is well-known that “continual powercorrupts”, and an all-powerful and never-changing committee of verifiers would be no exception.

Algorand relies on an ever changing smaller subset SV r of the larger set of users PKr.Before proceeding, let us highlight the properties that we deem important to satisfy for verifier

selection. (We wish to acknowledge that other properties can be deemed sufficient, and in factdescribe some alternative choices of properties and corresponding mechanisms in Appendix C.1.)

Main Desiderata in Verifier Selection At every round r, from a (potentially large) set ofusers, PKr, we wish to select a small subset SV r, at random, and in a way that is unpredictableuntil the very last moment, universally clear, and very efficient.

Selecting SV r so as to have a small number, n, of verifiers is crucial for the efficiency of theoverall system. In particular, it makes it feasible for the selected verifiers to communicate intensivelywith each other —e.g., by having each verifier send a separate message to all other verifiers.

Selecting SV r at random from PKr is also critical. If PKr has a sufficiently large honestmajority (e.g., h = 80%), then SV r can be counted on to have an honest majority too, thoughsmaller (e.g., 2/3). That is, we can count on SV r to have ≥ h′(n) honest verifiers, for a suitablefunction h′ corresponding to h.

Selecting the verifiers of a round while maintaining their unpredictability up to the last momentis also important. Notice that randomly selecting the verifiers does not suffice to guarantee suchunpredictability. If the few verifiers of a given round r were randomly selected, but made knownfar in advance, then there would be plenty of time for the Adversary to attack and gain controlof all of them without violating the Honest Majority of Users assumption. By contrast, selectingthe round-r verifiers only at, say, round r− 1 prevents the Adversary from gaining control of themwith enough time to be harmful. One round later, a totally new random set of verifiers will beselected. (Our first temporary assumption, postulates that the Adversary needs 40 rounds, afterstarting attacking an honest user, to corrupt him. But selecting the verifier set of round r only atround r − 1 would certainly be preferable.)

Selecting SV r in a universally clear way is also important. If it is desirable that the round-rverifiers remain unpredictable until very close to round r, then, since they must collectively decidethe official payset PAY r, it is crucial for SV r to become known at least by round r.

Finally, none of these desiderata would matter if the verifier selection process were too slow.Fortunately, in Algorand, this process requires no interaction and is computationally very efficient.

6.3 The Idealized Protocol Algorand0

Verifier Selection at a High Level Let R be a sufficiently long string, randomly andindependently chosen during round r, so as to become immediately known to all users. Then,in accordance with the above desiderata, we can select a set of n verifiers, SV r, from the set of allusers, PKr, by means of the following process.

Let i1, i2, . . . , ix be the lexicographically ordered sequence of all keys in PKr (which, by thetemporary One-Key-Per-Owner assumption, coincides with the set of all owners of public keys atthe start of round r). Then, dlog xe bits suffice to uniquely identify a key in PKr. Accordingly, thefirst dlog xe bits of R identify the first verifier in SV r. (If these bits identify a number higher thanu, then they are discarded, and the next dlog xe bits are considered instead.) The following dlog xe

19

bits of R identify the second chosen verifier (if different from the one already chosen, or else thesebits, too, are discarded). And so on, until all n verifiers of SV r have been selected.

We refer to this process as the natural mechanism (with string R and set PKr). In symbols,

SV r R←− PKr .

Actually, the natural mechanism not only randomly selects SV r from PKr, but also selects arandom ordering ρr of SV r: in symbols,

(ρr, SV r)R←− PKr .

But: Who chooses R?Algorand’s answer is simple: no one. Each string R is algorithmically generated by applying

the cryptographic hash function H to an unambiguously defined input relative to round r. In thesimplest instance, this input would be r itself. Namely, we could consider selecting the verifier setSV r and a random ordering ρr of SV r as follows:

(ρr, SV r)H(r)←− PKr .

Indeed, in our model, H (r) is a 256-bit random string.11 Furthermore, H (1) , . . . ,H (r) , . . ., areindependent random strings.

A problem with running the natural algorithm with string H (r) to select the verifier set SV r

is that the sequence SV r, SV r+1, . . ., is, yes, randomly selected, but also easy to predict, becauseit can be computed in its entirety at the start of the system, that is, in round 0.

To guarantee the unpredictability of future verifiers, we may choose

(ρr, SV r)H(Qr−1)←− PKr ,

where Qr−1 is a quantity known at round r − 1, because part of the block Br−1 of the previousround, but hard to predict in advance.

On Finding a Suitable Quantity Qr At a first glance, we could choose Qr−1 to coincide withPAY r−1 (and thus avoid to specify Qr−1 explicitly in Br−1). After all, it should be hard in, say,round r−10 to predict what the official payset of round r−1 will be. Accordingly, we might considerselecting ρr and SV r via the natural mechanism, but with a different random string: namely,

(ρr, SV r)H(PAY r−1)←− PKr .

A little effort reveals, however, that malicious users may take advantage of this selectionmechanism.12 Some additional effort shows that choosing Qr to coincide with PKr, Sr−1, Br−1,H(Br−1), and myriads of combinations thereof, is also insecure. But secure choices for Qr do exist.

One such a choice will be detailed and analyzed in Section 8.4.

11The natural algorithm may need more than 256 bits to select a set of verifiers, but one could always stretch H (r)into a much longer pseudo-random bit sequence of high quality. In fact, the natural algorithm may take all the blocksof bits it needs from the sequence H (r) ◦H (r, 1) ◦H (r, 2) ◦ · · · , where “◦” denotes the concatenation operator.

12Assume that the leader of round r − 1, `r−1, is malicious. Accordingly, he could select PAY r−1 in any way hewants. In particular, among all payments of round r − 1 that he sees (or can generate himself), `r−1 selects one,

℘′, such that, computing (`r, SV r)H({℘′})←− PKr, `r is also a malicious user. If the malicious users are —say— 10%

of all users, then after a mere 10 trials such a payment ℘′ will be found. Thus, by setting PAY r−1`r−1 = {℘′} and

propagating SIG`r−1(PAY r−1`r−1), `r−1 ensures that PAY r−1 = {℘′}, and thus that the leader of the next round, `r,

is also malicious. If all malicious leaders operate this way, the completeness of the system would be 0.

20

Essential Round Structure At the start of round r, all users know the system status Sr, theset of public keys PKr, the (yet to be discussed) quantity Qr−1, and thus the verifier set SV r

(since we have promised that SV r is algorithmically computed from Qr−1).The goal of round r is to establish, with the help of the round-r verifiers and in a way that is

clear to all users, the new official payset PAY r and the new quantity Qr.In fact, from these two pieces of data, every user computes, on his own, the new status Sr+1

(from Sr and PAY r), the new set of verifiers SV r+1 (from Qr), and the new set of public keysPKr+1 from PKr and PAY r.13

Users who wish to make payments continually propagate them in the background, waiting forthem to become part of a round’s official payset. Assuming that the percentage of honest users is hand that the round starts at time 0, by our message propagation assumption, this propagation canbe completed by time Λh, after which time every one is instructed to ignore all round-r payments.By time π, our only guarantee is that all users have received the round-r payments made by honestusers. As discussed above, however, the malicious users may ensure, in order to generate dissentamong the honest users, that their propagated round-r payments are received by some, but not all,honest users.14

To cope with this possibility, each round-r verifier i ∈ SV r compiles his own list of validround-r payments, PAY r

i , comprising, for each user y from which he has received at least oneround-r payment (by time π), a maximal set of valid round-r payments of y. Of course, such amaximal set of valid payments coincides with all round-r payments of y, if user y is honest, and,due to the discussed behavior of the malicious users, PAY r

i and PAY rj may differ for different

round-r verifiers i and j.To reconcile their possibly different paysets PAY r

i with the single official payset PAY r, theround-r verifiers rely on a well-known type of protocol.

Byzantine Agreement A protocol is a —deterministic or probabilistic— program run bymultiple parties, traditionally called players, each of which knows the others and can exchangemessages with them. In a protocol, players can be honest or malicious, as previously defined.

A protocol P is a (n, t)-Byzantine agreement (BA, for short)protocol, if, in an execution of P inwhich at most t of the n players are malicious and each player i has an initial value vi, each honestplayer halts with probability 1, outputting a value outi, so as to satisfy the following two conditions:

1. Agreement. There is a single value v (possibly the null value ⊥) such that outi = v for allhonest players i. We refer to such a value v as the (global) output of P.

2. Consistency. If, for some value v, vi = v for all honest players i, then outi = v.

Byzantine Agreement: REALLY? Byzantine agreement may appear to be a purely theo-retical solution in a system, like Algorand, that should efficiently handle millions and millions ofplayers. In fact, BA protocols require intense communication among players. In each of their steps,a player i is asked to send a single individual message, mi, to all other players.

Yet, in our case, this amount of communication is not a problem, for three main reasons.

13Indeed, recall that PKr+1 comprises all the keys already in PKr together with the new public keys that appearfor the first time, as payees, in at least one payment in PAY r.

14E.g., malicious users may purposely start propagating their round-r payments at a time t ∈ (0, π) which is veryclose to π. Accordingly, such payments cannot reach all honest users by time π.

21

1. Algorand does not run a BA protocol among all its users. Rather, it randomly selects a smallset of verifiers, who then run a BA protocol among them.

2. We construct a new cryptographic BA protocol, which is mush faster than all previously knownones. In fact, this new protocol may be of independent interest.

3. In the Algorand application, communicating by propagating messages, the new BA protocol isexecuted in a few seconds and only once per block. Requiring a few seconds to produce a blockthat can immediately be relied upon (i.e., with any fears of forking) is acceptable.

Choosing and Using the BA Protocol Based on the honest-user percentage h, Algorand (1)chooses n and t < n so that the probability that, among the n randomly chosen verifiers in SV r,more than t of them are malicious is less than the acceptable probability of failure F = 10−12; and(2) chooses BA to be a (n, t)-BA protocol. The protocol BA is used as follows.

In a round r, after the set SV r of n verifiers has been chosen, each verifier i collects, from allthe round-r payment he has personally seen, a round-r payset PAY r

i .At this point, since their paysets may be different, the verifiers in SV r run protocol BA, using

their PAY ri as their initial values. Since, with overwhelming probability (i.e., with probability

greater than 1−F ) at most t of the verifiers playing BA are malicious, all honest verifiers computea common output, out: either a round-r payset or the value ⊥. Either way, each of them digitallysigns out and propagates it.

Since n− t of the verifiers in SV r are honest, all users, including those outside the verifier set,can easily identify out as the only propagated value digitally signed by at least n− t of the verifiersin SV r. Finally, the official payset PAY r is determined to be out, if out is a round-r payset, andthe empty payset otherwise.

A Completeness Problem The problem with the approach so far is that, although at the end ofprotocol, BA all honest round-r verifiers will output the same value out, this value may be the nullvalue ⊥, rather than a set of valid round-r payments. In fact, in a BA protocol, all honest playersmay output ⊥ when they start with initial values that are all different. Thus, in our application,even a single malicious verifier can ensure that the initial values PAY r

i are different, and can forcethe final output of the BA protocol to be ⊥, rather than a round-r payments PAY r, causing thesystem described so far to have completeness 0.

Round Leaders To avoid the above described problem, we rely, for each round r, on the roundleader, `r, a clearly and randomly selected user in PKr. Since the round-r verifiers are themselvesrandomly selected in PKr, we might as well select `r at random in SV r. Accordingly, afterdetermining a proper quantity Qr−1, we could first compute

(ρr, SV r)H(Qr−1)←− PKr ,

and then set `r to be the first verifier in SV r according to ρr. That is, augmenting our notation,

(`r, SV r)H(Qr−1)←− PKr .

The role of the round leader is the following. After all users propagate their round-r payments, `r

individually computes his own list PAY r`r of valid payments. If `r is honest, PAY r

`r includes, for

22

each round-r payer Y , a maximal set of valid round-r payments of Y (and thus all valid payments ofY , if Y is honest). After computing PAY r

`r , `r prepares, digitally signs, and propagate the proposedblock:

Br`r =

(r, PAY r

`r , Qr−1, H

(Br−1)) .

Then all round-r verifiers run the pre-specified BA protocol BA using, as their respective initialvalues, the proposed blocks they actually received from `r.

The New Block and Proved Block The output of BA is guaranteed to be the proposed blockBr`r , if the leader `r is honest. Else, it will be ⊥ or, as we shall see, a valid round-r block. When

the output is ⊥, then it will be interpreted as(r, ∅, Qr−1, H

(Br−1)), that is, the round-r block

whose official payset is empty. In any case, each honest verifiers will digitally sign and propagatethe output, OUT , of BA. (Note that this propagation essentially coincides the propagation of asingle long message, OUT , and the propagation of a set of short signatures.15)

Thus, all users will recognize the new block Br to be the round-r block that has been signed byat least ν of the n of round-r verifiers. A corresponding new proven block will thus be (Br, CERT r),where CERT r is any set containing the digital signatures of at least ν round-r verifiers.

In sum, when the round leader is honest, the new block will coincide with that proposed byhim, and the payset of the new block will contain all the payments of the honest users. Thus,

If each round leader is selected at random among all users, andif the honest users are a fraction h of all users,

then the system has completeness h.

Ephemeral Keys With the rules so far, Algorand0 in particular guarantees that, under thestrong temporary assumptions of section 6.1, during the execution of a round r, the Adversarycannot make a fork with probability greater than F = 10−12.

We would like, however, also to guarantee that the Adversary cannot generate a fork in a pastround, if during that round he did not control a sufficient percentage of the users. We do so bymeans of a new rule. Essentially, the members of the verifier set SV r,s of a step s of round r useephemeral public keys pkr,si to digitally sign their messages. These keys are single-use-only andtheir secret keys are destroyed once used. This way, if a verifier of a given step is corrupted lateron, he will not be able to digitally sign anything else that he did not originally sign.

Naturally, since the uniqueness property of digital signatures is very important in Algorand’sstructure, we must ensure that a user cannot shop around for which public key to use in a givenround.

The Final Round Structure of Algorand0 To summarize, the structure of a round inAlgorand0 is as follows. The users constantly propagate, in the background, the payments theywish to make. At each round r, Algorand0 selects some round-r payments to be included in theofficial payment set PAY r by a 5-stage process:

15We would like to point out that some efficiency can be guaranteed in this propagation, because, while theoutput OUT may be long, it is the same for all honest verifiers. Assume that a user, helping out with messagepropagation, has already forwarded SIGi(OUT ), for some i ∈ SV r, to his neighbors. Then, when the same userreceives SIGj(OUT ), where i 6= j ∈ SV r, he will forward to his neighbors only sigj(PAY

r).

23

(a) The verifiers and the leader of round r are selected from PKr, based on the previousquantity Qr−1, ensuring that a suitable majority of the verifiers are honest with extremelyhigh probability, and that the round leader is honest with reasonable probability.

(b) The round leader propagates a pair (x, y), where x is a list of valid round-r payments chosenand authenticated by him, and y is his digital signature of Qr−1.

(c) The selected verifiers run a Byzantine agreement protocol on the received pair and all honestones output a common value OUT r, which coincides with the original pair sent by the roundleader, if he was honest.

(d) All honest selected verifiers of round r digitally sign and disseminate OUT r, so that every usercan identify OUT r and compute from it the official payset PAY r and the new quantity Qr.Finally,

(e) All verifiers and the leader propagate payments transferring all the money (in their verifierkeys) to no new keys, and then delete the old secret keys.

Since PAY r is a maximal set of valid round-r payments, whenever the round-r leader is honest, andsince this leader is honest with reasonable probability, Algorand0 has essentially perfect correctnessand reasonable completeness, although under our three temporary assumptions.

Let us now summarize a round in the real version of Algorand.

7 New Byzantine Agreement Protocols

Byzantine agreement protocols were originally developed to be executed in an synchronous networkwith an Adversary, both quickly recalled below, by agents traditionally called players. Accordingly,in this section, we describe BA protocol for such networks, using the term players.

(In Section 8, we adapt BBA∗ so as to run it in Algorand’s communication model.)

7.1 Synchronous Networks and Matching Adversaries

In a synchronous network, there is a common clock, ticking at each integral times r = 1, 2, . . ..At each even time click r, each player i instantaneously and simultaneously sends a single

message mri,j (possibly the empty message) to each player j, including himself. Each mr

i,j is receivedat time click r + 1 by player j, together with the identity of the sender i.

Again, in a communication protocol, a player is honest if he follows all his prescribedinstructions, and malicious otherwise. All malicious players are totally controlled and perfectlycoordinated by the Adversary, who, in particular, immediately receives all messages addressed tomalicious players, and chooses the messages they send.

The Adversary can immediately make malicious any honest user he wants at any odd time clickhe wants, subject only to a possible upperbound t to the number of malicious players. That is,the Adversary “cannot interfere with the messages already sent by an honest user i”, which will bedelivered as usual.

The Adversary also has the additional ability to see instantaneously, at each even round, themessages that the currently honest players send, and instantaneously use this information to choosethe messages the malicious players send at the same time tick.

24

Remark The above setting is very adversarial. In the literature, many less adversarial settingshave been considered, but also some more adversarial ones, wherein the Adversary, after seeingthe messages sent by an honest player i at a given time click r, has the ability to erase all thesemessages from the network, immediately corrupt i, choose the message that the now malicious isends at time click r, and have them delivered as usual.

7.2 The Notion of a Byzantine Agreement

The notion of Byzantine agreement was introduced (for synchronous, point-to-point, communica-tion networks16) by Pease Shostak and Lamport [15] for the binary case, that is, when every initialvalue consists of a bit. However, it was quickly extended to arbitrary initial values. (See the surveysof Fischer [16] and Chor and Dwork [17].) By a BA protocol, we mean an arbitrary-value one.

Definition 7.1. In a synchronous network, let P be a n-player protocol, whose player set is commonknowledge among the players, t a positive integer such that n ≥ 2t + 1. We say that P is anarbitrary-value (respectively, binary) (n, t)-Byzantine agreement protocol with soundness σ ∈ (0, 1)if, for every set of values V not containing the special symbol ⊥ (respectively, for V = {0, 1}), in anexecution in which at most t of the players are malicious and in which every player i starts with aninitial value vi ∈ V , every honest player j halts with probability 1, outputting a value outi ∈ V ∪{⊥}so as to satisfy, with probability at least σ, the following two conditions:

1. Agreement: There exists out ∈ V ∪ {⊥} such that outi = out for all honest players i.

2. Consistency: if, for some value v ∈ V , vi = v for all honest players, then out = v.

We refer to out as P’s output, and to each outi as player i’s output.

Historical Note Turpin and Coan have shown that, for n ≥ 3t+1, any binary (n, t)-BA protocolcan be converted, by just adding two more steps, to an arbitrary-value (n, t)-BA protocol.

7.3 The BA Notation #

In our BA protocols, a player is required to count how many players sent him a given message ina given step. Accordingly, for each possible value v that might be sent,

#si (v)

(or just #i(v) when s is clear) is the number of players j from which i has received v in step s.Recalling that a player i receives exactly one message from each player j, if the number of

players is n, then, for all i and s,∑

v #si (v) = n.

16In such networks players communicate in stages. At the start of each stage, each player i sends a message to eachplayer j over private i-j line, in which no other player can interject messages. All such messages are received by theend of the phase. In such networks, therefore, message privacy and authentication are guaranteed by assumption.

In our communication network, messages are propagated, authentication is guaranteed by digital signatures(although often omitted in the description of our protocols), and privacy is non-existent. Fortunately, the BAprotocols that we consider using in Algorand do not require message privacy.

25

7.4 The Binary BA Protocol BBA?m

In this section we present a new binary BA protocol, BBA?m, which

• Relies on the honesty of more than two thirds of the players are honest.

• Is super fast: it consists of k repeated executions of a single step, each of which brings theplayers into agreement with probability 1/3.

• Is digital-signature based: each player has his own public key.

• Requires minimal set-up: a common random string r, independent of the players’ keys.

The string r can be used to reach an essentially unbounded number of agreements. (In Algorand,r is actually replaced by the block quantity Qr.)

Historical Remark Probabilistic binary BA protocols were first proposed by Ben-Or inasynchronous settings [21]. Protocol BBA?m is a novel adaptation, to our public-key setting, ofthe binary BA protocol of Feldman and Micali [24]. Their protocol was the first to work in anexpected constant number of steps. It worked by having the players themselves implement acommon coin, a notion proposed by Rabin, who implemented it via an external trusted party [22].

Below, t upperbounds the number of malicious players in an execution; r is the common randomstring; a binary string x is identified with the integer whose binary representation (with possibleleadings 0s) is x; and lsb(x) denotes the least significant bit of x.

Protocol BBA?m

For s = 1 to m Do:

(Propagation) Step s. Each player i sends bi and SIGi(r, s) to all players, including himself.

s.1 If #si (0) ≥ 2t+ 1, then i sets bi = 0.

s.2 If #si (1) ≥ 2t+ 1, then i sets bi = 1.

s.3 Else, letting Si be the set of all players j from which i has received SIGj(r, s), i sets

bi = lsb(minj∈Si

H(SIGi(s))) .

Theorem 7.1. If n ≥ 3t+ 1, BBA?m is a binary (n, t)-BA protocol with soundness ≥ 1−(n−t2n

)m.

Proof. We start by proving, that

if at the start of a step s, agreement has not yet been reached,then, with probability at least n−t

2n , it will be reached at the end of the step.

26

By the uniqueness property of the underlying digital signature scheme, being H a random oracle,the n values H(SIG1(r, s)), . . . H(SIGn(r, s)) are independent, 256-bit long, random strings.Ignoring the remote possibility of ties, letting H(SIGm(r, s)) be the minimum of these strings,in lexicographical order. Then, with probability at least 2/3, m is a honest player. Accordingly, atthe start of step s, m sends SIGm(r, s) to all players. Thus, whether or not the malicious playerssend or withhold their signatures of (r, s), for all honest players i,

H(SIGm(r, s)) = minj∈Si

H(SIGi(r, s)).

Definec , lsb(H(SIGm(r, s))).

Then, (1) c, ignoring exponentially small biases, is a random bit, because it is the last bit of arandom string, and (2) c is computed by all honest players in step s.

Note that a honest player, in every step of in BBA?m, sends the same bit to all players.Accordingly, since the number of malicious playes is at most t, at the end of step s, for all honestplayers i and j and all bits b, |#i(b)−#j(b)| ≤ t. Accordingly, there are only four exhaustive casesto consider: namely,

(i) All honest players i update their binary variables bi according to s.1 or s.2.

In this case, if all honest i update their bi according to s.1, then, at the end of step s, Agreementholds on 0; else, Agreement holds on 1.

(ii) All honest i update their binary variables bi according to s.3.

In this case, at the end of Step s, Agreement holds on c.

(iii) Some honest i update their binary variables bi according to s.1, and all others according to s.3.

Let H1 (respectively, H3) be the set of honest players updating their bits according to s.1(respectively, s.3). If c = 0, and it has been set by an honest player, then all players i in H1

reset their binary variables bi to 0, while all those in H3 reset theirs to c, which is 0. Sincec = 0 with probability 1/2 and it has been set by an honest player with probability n−t

n , in case(iii) Agreement on 0 is reached with probability n−t

2n .

(iv) Some honest i update their binary variables bi according to s.2, and all others according to s.3.

In this case, a symmetric argument shows that Agreement on 1 is reached with probabilityn−t2n .

In sum, at the end of step s, no matter what malicious players might do, agreement is reached withprobability at least n−t

2n , as claimed.Assume now that, at some step x < m, agreement holds on some bit b. Then, it is easy to

see that it will continues to hold on the same bit b at the end of step x + 1. Indeed, at the startof step x + 1, all honest players propagate b, so that, for every honest i, #i(b) ≥ 2t + 1 and thusi sets bi = b at the end of the step. Applied to steps x + 2, x + 3, . . ., the same argument showsthat agreement of b continues to hold at the end of step m. Thus, if the players start protocolBBA?m in agreement, they will remain in agreement at the end of the protocol. Else, they willreach agreement with probability 1− (n−t2n )m, and then they will remain n agreement at the end ofstep m.

27

7.5 The “Graded-Consensus” Protocol GC

Definition 7.2. Let P be a protocol in which the set of all players is common knowledge, and eachplayer i privately knows an arbitrary initial value v′i.

We say that P is an (n, t)-graded consensus protocol if, in every execution with n players, atmost t of which are malicious, every honest player i halts outputting a value-grade pair (vi, gi),where gi ∈ {0, 1, 2}, so as to satisfy the following three conditions:

1. For all honest players i and j, |gi − gj | ≤ 1.

2. For all honest players i and j, gi, gj > 0⇒ vi = vj.

3. If v′i = · · · = v′n = v for some value v, then vi = v and gi = 2 for all honest players i.

Historical Note The notion of a graded consensus is simply derived from that of a gradedbroadcast, put forward by Feldman and Micali in [24], by strengthening the notion of a crusaderagreement, as introduced by Dolev [19], and refined by Turpin and Coan [20].17

In [24], the authors also provided a 3-step (n, t)-graded broadcasting protocol, gradecast, forn ≥ 3t+1. A more complex (n, t)-graded-broadcasting protocol for n > 2t+1 has later been foundby Katz and Koo [25].

The following two-step protocol GC consists of the last two steps of gradecast, expressed in ournotation. To emphasize this fact, and to match the steps of protocol Algorand ′ of section 6, werespectively name 2 and 3 the steps of GC.

Protocol GC

Step 2. Each player i sends v′i to all players.

Step 3. Each player i sends to all players the string x if and only if #2i (x) ≥ 2t+ 1.

Output Determination. Each player i outputs the pair (vi, gi) computed as follows:

• If, for some x, #3i (x) ≥ 2t+ 1, then vi = x and gi = 2.

• If, for some x, #3i (x) ≥ t+ 1, then vi = x and gi = 1.

• Else, vi = ⊥ and gi = 0.

Theorem 7.2. If n ≥ 3t+ 1, then GC is a (n, t)-graded broadcast protocol.

The proof immediately follows from that of the protocol gradecast in [24], and is thus omitted.18

We only remark that the following property trivially holds:

If an honest player i outputs (x, 2), then x is the initial value of at least t+ 1 honest players.

17In essence, in a graded-broadcasting protocol, (a) the input of every player is the identity of a distinguishedplayer, the sender, who has an arbitrary value v as an additional private input, and (b) the outputs must satisfy thesame properties 1 and 2 of graded consensus, plus the following property 3′: if the sender is honest, then vi = v andgi = 2 for all honest player i.

18Indeed, in their protocol, in step 1, the sender sends his own priavte value v to all players, and each player i letsv′i consist of the value he has actually received from the sender in step 1.

28

8 Structure and Building Blocks of Algorand ′

We present protocol Algorand ′ in the next section. In this one, we just specify how it structuresof a round r, and its building blocks: namely, how it selects the leader of round r from its verifier-selection mechanism, its leader-selection mechanism, its special way to determine the quantitiesQr, and its use of ephemeral keys. The other building block, the binary BA protocol BBA?m, hasalready been specified.

Recall Algorand proceeds in rounds. The goal of a round r is to construct, based on the blocksequence so far, B0, . . . , Br−1, and the payments that the users continually make and propagatein the background, a new block Br. Each block Br comprises: the number r, the official paysetPAY r, a special quantity Qr, and the hash of the previous block, H

(Br−1).

The quantity Qr−1 determines the leader of round r, and the verifiers of each step s of r.

8.1 Conceptual Round Structure

In Algorand ′, round r has 3 +m steps and the following conceptual (not literal!) structure.

Step 1. In step 1, based on the round-r payments he has seen so far, the leader of round r computesand propagates a block B, whose payset, PAY r, is a maximal one for round r.

Steps 2 and 3. In steps 2 and 2, the users execute the two-step graded-consensus protocol GC.In such an execution, each user i sets his initial value v′i to be the block he received from theleader, if he indeed received a valid block from him, and the default block otherwise. Upontermination, each user outputs a value-grade pair (vi, gi).

(Comment: If the leader is honest, then, for each honest user i, vi = B and gi = 2.)

The next m steps. In the steps, the users execute the m-step binary BA protocol BBA?m. Insuch an execution, the initial bit bi of user i is 0, if his output of the graded consensus protocolwas 2, and 1 otherwise.

Upon terminating BBA?m, if his output is 0, then a honest user i sets the new block Br to bevi, that is the first component of the value-grade pair (vi, gi) he output in Step 3.

In this conceptual structure, therefore, in a round r of Algorand ′, the users reach Byzantineagreement on the block proposed by the round leader, and adopt the agreed upon block (possiblythe default one) as the next block Br. The challenge is to enforce this structure even when theabove conceptual steps are executed by only the proper verifiers, rather than all users.

8.2 Verifier Selection

Algorand ′ independently chooses a set of verifiers, SV r,s, for each step s of a round r, among theusers of a previous round, round r−k. Each verifier set SV r,s is not easily computable by all users.Rather, a secretive verifier selection (SVS) mechanism privately lets each user i know whether ornot he belongs to SV r,s, and gives him the means to prove which is the case. For simplicity, we donot define SVS mechanisms in general, but only the one Algorand ′ actually uses, SVS−k,p. Thismechanism determines SV r,s via a quantity, Qr−1, uniquely associated to round r − 1 and definedin subsection 8.4.

29

Definition 8.1 (Mechanism SVS−k,p). Let k be a positive integer and p a real in [0, 1]. The verifierset of a step s in a round r, with look-back parameter k and probability p, is

SVS−k,p(r, s) , SV r,s ,{i ∈ PKr−k : .H

(SIGi

(r, s,Qr−1

))≤ p}

.

If i ∈ SV r,s, then SIGi(r, s,Qr−1

)is i’s r-s credential, and is compactly denoted by σr,si .

Note The symbol “.” that precedes “H(SIGi

(r, s,Qr−1

))” in the above definition is the decimal

point used to mark the start of the (in our case) binary expansion of a number between 0 and 1.More precisely, .H(σr,si ) is a 256-bit number in [0, 1].

As we shall see, properly setting the parameter k is crucial to achieve the full security of theAlgorand scheme, and to replace Continual Participation with “Lazy Honesty” (see Section 9.9).

Theorem 8.1. For all k, p, r, s, and users i,

1. A fraction p of the users in PKr−k belongs to SV r,s.

2. i can easily determine whether he belongs to SV r,s.

3. Each H (σr,si ) is independent and random, easily computable by i, but computationallyindistinguishable from a random 256-bit number to all users other than i even with oracle H.

Proof. Property 1 holds because the uniqueness property of digital signatures guarantees thatSIGi(r, s,Q

r−1) is uniquely defined. Thus .H(SIGi(r, s,Qr−1)) is the binary representation of a

uniquely defined 256-bit number in [0, 1]. Furthermore, since H is a random oracle, this number israndomly and independently chosen in [0, 1]. Thus, the probability that it is less than or equal top is (practically speaking) p. Thus Property 1 holds.

Property 2 trivially follows from the fact that every user i can easily compute his signature ofany given (short) string.

Property 3 trivially follows from the fact that i, r and s are retrievable from SIGi(r, s,Qr−1),19

that H is a random oracle, and that i’s digital signature is hard to compute without i’s secretkey.

Mechanism SVS−k,p has been inspired by the micro-payment scheme of Micali and Rivest [29].

8.3 Leader Selection

Protocol Algorand ′ does not guarantee the existence of a unique round leader, nor that, when suchleader exists unique, that he is aware of it. It only guarantees that a user secretly learns to be apotential leader, and that, when the set of such leaders is not empty, then a unique leader implicitlyexists. As we shall see, however, even these weaker guarantees suffice for our purposes.

In Algorand ′, the potential leaders of a round r are also defined via the quantity Qr−1.Recall that the credential of a verifier i ∈ SV r,s is SIGi

(Qr−1

), and is compactly denoted by σr,si .

19Without this retrievability, property 3 might not hold, or might need a more careful proof. For instance, amalicious i might not choose his public key by honestly running the key generator G, but in a way guaranteeing thatSIGi(x) = SIGi(y) for all strings x and y. If i succeeded in so choosing his public key, then his belonging to differentverifier sets would be correlated. Of course, i’s signatures would be easily forgeable in this case, but this is a differentmatter. Note that such an ability of i is not ruled out by the uniqueness property of digital signatures.

30

Definition 8.2. A user i ∈ PKr−k is

• a potential leader of round r, if .H(SIGi

(r, 1, Qr−1

))≤ 1/|PKr−k| and

• a leader of round r if .H(SIGi

(r, 1, Qr−1

))≤ .H

(SIGj

(r, 1, Qr−1

))for all potential leaders j.

A round r is leaderless, if its has no potential leaders. Else, disregarding improbable ties, it has aunique leader, `r. We refer to SIG`r(r, 1, Qr−1) as the leader’s credential, and compactly denote itas τ r`r , or, more simply, by τ r.

Note Although the verifiers in SV r,1 are well defined, Algorand ′ does not give them any duties.However, this is not true for the potential leaders of round r, who essentially are step-1 verifierswhose hashed credential is particulary small.

Let us now clarify the properties enjoyed by the so defined leader `r.Recall that (in every round) h is the percentage of honest users.

Theorem 8.2. In Algorand ′, for all rounds r, look-back parameters k (and probability p),

1. `r exists with probability (roughly equal to) 1− 1/e.

2. `r, when he exists, is a randomly selected user in PKr−k.

3. `r exists and is honest with probability (roughly equal to) h(1− 1/e).

Proof. Trivial and omitted.

8.4 The Quantity Qr

Relying on Qr−1, when choosing the verifier set SV r,s, is necessary, because Algorand ispermissionless. Assume for a moment that we defined SV r,s =

{i ∈ PKr−k : .H (SIGi(r, s)) ≤ p

}.

Then, at round r−k, the Adversary could ensure that the verifier set SV r,s has a malicious majorityby iterating the following two-stage process. First, he chooses i at random, together with his secretsigning key ski; then, he computes x = H(SIGi(r, s)), until he finds an i such that .x ≤ p. At thispoint, he generates a payment ℘, from a malicious user in PKr−k−1, and acts so that ℘ appears inthe payset PAY r−k.20 Thus, i immediately belongs to PKr−k, and, k rounds later, to SV r,s.

It is to prevent that the Adversary may ensure that a verifier set SV r,s has a malicious majority,that we introduce the quantity Qr−1 and define

SV r,s ={i ∈ PKr−k : .H (SIGi(r, s)) ≤ p

}.

Desiderata in Choosing Qr Ideally, the quantity Qr should satisfy the following requirements:

R1 : Qr should be uniquely determined by r and universally known at the end of round r;

R2 : Qr should be a (short) randomly and independently selected value;

R3 : Qr should be totally unpredictable before the end of round r to any user, except `r (who shouldbe able to compute `r at the start of round r, but not before then).

20For those who have decided to skip the intuition section, section 6, as we shall see, ℘ will naturally belong toPAY r−k if the leader of round r− k is honest. Else, the Adversary instruct `r−k to propose any block that includespayment ℘.

31

Intuition To satisfy requirement R1, we plan to include Qr in block Br. Note that, by doing so,Qr does not depend on s, but does not need to. The Adversary cannot introduce a new user inthe middle of a round for the simple reason that a user enters the system as a payee of a paymentincluded in the final official payset of a round, which is “sealed” in the block of that round.

To satisfy requirement R2, we plan for Qr itself to be the output of the ideal hash function H,with a properly chosen input. (Notice that setting Qr = H(r) satisfies both requirements R1, andR2, but not R3, since anyone can evaluate the hash function H.)

Satisfying requirement R3, simultaneously with the previous two ones, appears to be hard. Sowe shall satisfy a weaker version of it, which is sufficient for our purposes.

Definition In block Br, the quantity Qr is determined inductively as follows. Initially, Q0 is arandom number, part of the system description, and thus publicly known. Recall that τ r`r is thecredential of the leader of round r.

Q1 = H(SIG`1

(Q0), 0)

if `1 exists and timely reveals τ11 and SIG`1(Q0). Else, Q1 = H

(Q0, 0

)Q2 = H

(SIG`2

(Q1), 1)

if `2 exists and timely reveals τ22 and SIG`1(Q1). Else, Q2 = H

(Q1, 1

)Q3 = H

(SIG`3

(Q2), 2)

if `3 exists and timely reveals τ33 and SIG`3(Q2). Else, Q3 = H

(Q2, 2

)Etc.

As we shall see, for each round r, there is a prescribed time tr by which the leader, if any, issupposed to announce his credential τ r`r and his signature SIG`r

(Qr−1

).

Theorem 8.3. For each round r, the 20B-long string Qr of block Br is randomly and independentlyselected, and unpredictable, before round r, by any user other than `r, if `r is honest.

Proof Sketch. Assume first that each round r has a leader and that each leader `r, malicious ornot, always computes and timely reveals his credential τ r`r and SIG`r(Qr−1). In this case,

Qr = H(SIG`r

(Qr−1

), r − 1

).

Note that, due to the guaranteed uniqueness property of the underlying digital signature scheme,the signature SIG`r

(Qr−1

)is uniquely determined by Qr−1. Thus, even if the leader `r existed

and were malicious, he could not “shop around”, among a set of multiple valid signatures for Qr−1,for one that lets him de facto choose the quantity Qr in a way that is convenient to him.

Also note that, to generate each quantity Qr, the input provided to the random oracle H hasnever been provided to H to generate another quantity Qj . In fact, each input provided to therandom oracle H is a pair, whose second entry is an ever increasing counter. Thus, Qr is a randomlyand independently chosen 256-bit string no matter how a malicious `r might choose his public key.21

Thanks to Theorem 8.2, we know that `r exists and is honest with probability h/e. However,conditioned to the fact that (as we are temporarily assuming) each round r has a leader, eachleader `r is honest with probability h, because he is a random user in PKr−k. Thus, since anhonest leader `r will not divulge his signature SIG`r(Qr−1) before the end of round r, we concludethat the malicious users can predict Qr in round r − 1 essentially with probability at most 1− h.

Extending this reasoning, one can see that the malicious players cannot, at a round r, predictthe quantity Qr+k with probability substantially greater than (1−h)k. In fact, for their prediction

21Without the second, ever-increasing entry, this property might not hold or might need a more careful proof, evenin light of the uniqueness of digital signatures. (See Footnote 19.)

32

to be correct, they must either correctly predict a random 256-bit string (which will happen withabsolutely negligible probability), or be so lucky that all k leaders `r+1, . . . , `r+k are malicious,which will happen with probability (1 − h)k. In the second case, in fact, the Adversary could, atround r, ask them, one at a time and in the proper order, for their signatures of the proper Q-valuesso as to reconstruct the value Qr+k.

To make sure that this probability is lower than F , our acceptable probability of failure, the look-back parameter k of the private verifier selection mechanism SV S−k,p is chosen to be sufficientlylarge. Thus, at round r−k, although the Adversary could introduce new users, he could do so onlyin a totally “blind” fashion.

So far, we have assumed that each round r has a leader, and that each leader `r timely revealshis credential and the signature SIG`r

(Qr−1

)required to compute Qr. However, a round r may

be leaderless, or its leader `r may be malicious, may be the only potential verifier, and may refuseto reveal SIG`r

(Qr−1

)altogether. (In fact, he may also refuse to reveal his leader credential, so

as to avoid any punishments that may be imposed on him for his behaviour.)In this case, the generation of the sequence of quantities Q would get “stuck”, and with it the

entire payment system. To prevent this possibility, when no proper leader credential and signatureappear by a prescribed time, Qr is defined to be H

(Qr−1, r − 1

). Let us quickly analyze what

happens when this alternative setting of Qr is invoked.A malicious leader `r always has the opportunity (ignoring all possible financial incen-

tives/disincentives provided by the system) to cause the official payset PAY r to be empty. Inaddition, by revealing the required signature SIG`r

(Qr−1

)or allowing it to be replaced by the

value Qr−1, he essentially has two separate opportunities (to slightly influence the next verifierset SV r+1 and) to select the next leader `r+1. That is, he has a second chance of forcing `r+1

to be a malicious player. Under both chances available to him, however, (SV r+1 and) `r+1 willbe randomly selected. Thus, if in both of these “independent trials” the new leader exists and ishonest —which, by Theorem 8.2, will occur with probability h2/e— then there is nothing that`r could do to prevent `r+1 from existing and being honest, and thus for Qr+1 to be totallyunpredictable in round r. We conclude that, when the look-back parameter k is sufficiently large,the Adversary has only a negligible chance of significantly influencing the choice of the round leaders.Accordingly, each Qr is randomly and independently selected. Moreover, if the leader `r of roundr is honest, then he will propagate SIG`r

(Qr−1

)at the proper time of round r, but not before.

Thus, Qr = H(SIG`r

(Qr−1

), r − 1

)will be not only random, but also totally unpredictable to

any one else before `r divulges SIG`r(Qr−1

).

Thus, since a honest `r is instructed to reveal and that, since an honest leader `r ensures thatPAY r contains all the round-r payments he observes,

the verifier-selection mechanism SV S−k,p has completeness at least h2/e.22

For instance, if h > .9 (and without bothering to allow for multiple potential leaders), then thecorresponding completeness is roughly .3.

Let us now clarify how exactly the round-r leader `r “reveals” SIG`r(Qr−1

). Of course,

propagating SIG`r(Qr−1

)does not work. (Indeed, once again, a malicious `r may start propagating

it so late that only some of the honest users will see it. Accordingly, different honest users will holddifferent views about the quantity Qr+1, and thus about the next selected verifier set, leader, etc.)

22This lowerbound is quite conservative, because the malicious leader cannot compute the signatures of the honestusers, thus cannot compute who the next leader is in either trial.

33

To avoid that a malicious leader `r may “tamper” with revealing SIG`r(Qr−1

), we again rely

on Byzantine agreement. For the sake of efficiency, we choose to leverage the same execution ofthe BA protocol, used to determine PAY r, to determine also SIG`r

(Qr−1

). Specifically, after the

verifier set SV r and the leader `r have been selected, and after `r has already compiled his own setof valid round-r payments PAY r

`r , `r does not just propagate PAY r`r , but the pair(

PAY r`r , SIG`r

(Qr−1

)).

The round-r verifiers then run the BA protocol, each verifier using as his initial value the pairhe actually received from `r. Upon termination, an honest verifier i ∈ SV r digitally signs andpropagates the computed result OUT . Since OUT is the same for all honest verifiers, it is theonly propagated value that is signed by a sufficient number of verifiers of round r, and thus easilyidentified by all users. Accordingly, if OUT is a pair whose second component is SIG`r(Qr−1),then all users set

Qr = H(SIG`r

(Qr−1

), r − 1

);

else, all users setQr = H

(Qr−1, r − 1

).

In particular, therefore, Qr = H(Qr−1, r − 1

)when OUT = ⊥. The first component of OUT is

used as previously discussed in order to determine PAY r.

8.5 Ephemeral Keys

In Algorand ′, users rely on digital signatures for a variety of tasks: namely, to authenticatethe payments they want to make, and to authenticate the messages they propagate as part ofthe protocol. The latter use is essential. In network in which there is a dedicated and securecommunication line between every two users i and j, i is sure that a message received on that linehas been sent by j, and viceversa. In a propagatin network, however, a user i must digitally signthe messages he propagates, else there is no way to attribute them to him.

We wish to restrict the digital key pki, belonging to a key owner i in the system, to be used onlyfor (a) authenticating i’s payments, (b) generating i’s credentials, and (c) authenticating separate,and ephemeral, keys, which i uses to digitally sign the messages he must send in the protocolwhenever he belongs a verifier set SV r,s.

Specifically, in the protocol proper (i.e. letting aside the payments he wishes to make, in a steps of a round r, a owner i uses his digital key pki to (1) check whether he belongs to the verifierset SV r,s, and to compute the corresponding credential σr,si , if this is the case; (2) authenticatepkr,si , the public key of the public-secret key pair that he uses to sign only one message, the singlemessage mr,s

i that he is asked to send as a member of SV r,s.When his time to act as a member of SV r,s arrives, an honest i acts as follows. First, he

computes sigr,si , his own signature of mr,si relative to pkr,si . Second, he destroys the secret key skr,si .

Third, he propagates σr,si , sigr,si , and auth(pkr,si ) a a string authenticating that pkr,si indeed his hispublic key for step s of round r.

In other word, not only is the key pkr,si ephemeral, it is actually single use! This is necessaryto prevent that the Adversary, although ex post, may corrupt the majority of SV r,s. In fact, afterlearning —via their propagated credentials— who the members of a verifier set SV r,s are, theAdversary cannot stop the messages they propagate with their credentials, but can corrupt them

34

immediately and ask them to propagate in in authenticated manner, immediately or at a futuretime, new messages of his choice, so as to generate confusion about what has been said.

Use of ephemeral keys are common place in the cryptographic literature. But in our applicationwe must also be careful that each public key pkr,si not only is a public key of i that has never beenused before (and part of a unique-signature scheme), but also that i will not have any other publickey associated to step s of round r, so as to deprive a user i of the ability to shop around fordifferent public keys to use as a member of SV r,s.

A New Status Quantity So far, the Status Sr at a given round r specified, for each user

i ∈ PKr, a single quantity: the amount of money a(r)i associated to i in round r. We now specify

a new quantity, COM(r)i , as follows.

Let R be a fixed and sufficiently large positive integer. There are m steps in each round, and cRrounds in each interval [cR, (c + 1)R), where c is a non-negative integer. Thus, a user i generatesa 20B-long commitmrnt CcRi to mcR public keys. Specifically, for each step s and each roundr ∈ [cR, (c + 1)R), user i generates independently a public key pkr,si , together with its secret keyskr,si . Then, he generates the commitment CcRi to the vector mapping each (r, s) to pkr,si . Relativeto CcR, if he is a verifier in SV r,s, i uses the key pkr,si to sign the message mr,s

i , and proves thatpkr,si really is the public key corresponding to step s of round r ∈ [cR, (c + 1)R), by producing ade-commitment (proof), denoted auth(pkr,si ).

When the current round r is getting close to (c+ 1)R, then i, in a similar manner, generates asecond commitment C(c+1)R, and computes and propagates SIGi(cR,C

(c+1)R). This signature istreated as a payment of i, enters PAY r (if the round leader is honest), and causes the updating ofthe quantity COMi(r).

In sum, therefore, the new status quantity COMi(r) consists either of (cR,CcR) or of{(cR,CcR), ((c+ 1)R,C(c+1)R)}.

Implementation Details and Efficiency If the look-back parameter is k, then the quantity((c+ 1)R,C(c+1)R) enters the status of i at a round that is at least k less than (c+ 1)R.

There are several ways to implement the commitment CcR. For instance, one may use Merkletrees. For instance, one may

(1) construct a tree whose leaves are in correspondence with the possible pairs (r, s),(2) store public key pkr,si in leaf (r, s),(3) “Merklefy” the tree, and(4) let CcRi be the content the root.

Let us now argue, that, disregarding an initial set-up cost, a user i essentially generates one publickey for each round in which he is a potential leader, and each step in which he is a verifier. In fact,although the number of public keys pkr,si that are commitment by each CcR may be large, onlythose that are actually used, because corresponding to a step in which i has actually been selectedas a verifiers, are made useless by having destroyed the corresponding secret key. Thus, when ineeds to compute the new commitment C(c+1)R, he can freely use all public keys, committed inCcR, that, corresponding to rounds and step already past in which i did not act as a verifier, havetheir secret key intact.

35

9 Protocol Algorand ′ with Majority of Honest Users

In this section, we construct a version of Algorand ′ working under the following assumption.

Honest Majority of Users Assumption: More than 2/3 of the users in each PKr are honest.

In the next section, we show how to replace the above assumption with the desired HMM one.

A General Reduction We actually provide a general algorithm, Algorand ′(·), that, given anarbitrary-value sender-BA protocol BA, satisfying the additional obliviousness requirement, returnsan Algorand protocol based on the HMM assumption.

For simplicity only, rather than emphasizing the general nature of our construction, we shalldirectly present the protocol

Algorand ′ , Algorand ′(BA?m) .

In fact, we shall argue that BA?m satisfies the desired obliviousness property. Since, BA? requiresthat >2/3 of the players are honest, it must be that the honest percentage of Algorand ′ is h > 2/3.

Parameter Choices The percentage of honest users, h > 1/2, is given a priori. The acceptableprobability of failure has already been chosen to be F = 10−12. To ensure that Qr is sufficientlyunpredictable at around r−k, the look-back parameter can be chosen to be k ≥ 100. The selectionprobability p, the reachability ρ, and the upperbound t to the number of possible malicious playersin a verifier set, so that, in a random execution of Algorand ′, with probability greater than 1− F ,for each step s of a round r,

ρ(n− t) > 2t+ 1

where n is the actual number of users in the verifier set SV r,s and t the number of malicious usersin SV r,s during the execution of step s.23

The latency parameters Λ and λ are those determined by the message propagation respectivelyfor (a) the maximum allowed size of a block —i.e., the maximum possible size for a step-1 message—and (b) the maximum number of bytes needed a step-s message, s > 1.

Tight Scheduling As per its previously discussed conceptual structure, a round in Algorand ′

indeed consists of 3 + m steps, and each one of them has a precise time length. The time lengthof Step 1 is Λ, because this step involves the propagation of a block. The time length of all othersteps is λ. Thus, each round precisely takes time T = Λ + (2 +m)λ.

Actually, Algorand ′ execute each round in a tightly scheduled way: that is, each step s of around r starts at time ar,s and ends by time br,s,.

Assuming that the execution of round 1 starts at time T , the execution of step 1 of round rstarts at time ar,1 = rT and ends by time br,1 = rT + Λ, and that of any other step s starts at timear,s = rT + Λ + (s− 1)λ and ends by time br,s = rT + Λ + sλ.

23As we shall see, during the execution of each step s, the Adversary only knows the members of SV r,s who arealready malicious at the start of step s, and thus, given its limited budget of corruptions, he cannot make maliciousa large fraction of SV r,s.

36

Notation In a round r of Algorand ′,

• The instruction “If i ∈ X, then . . .” is short hand for“Every user i determines whether he belongs to set X, and, if this is the case, then . . .”For instance, “If i ∈ SV r,s, then . . .” means “Every user i checks whether i ∈ PKr−k and.H(SIGi

(r, s,Qr−1

)))< p, and, if this is the case, . . .”

• Knowr is the set of all users who know the entire block chain so far, B0, . . . , Br−1.

• Brε denotes the empty block for round r: that is, Br

ε ,(r, ∅, H

(Qr−1, r − 1

), H(Br−1)

).

• For all users i and j, and all steps s, i receives exactly one message (possibly empty) from j,denoted by mr,s

j,i .

• For all users i, steps s, and values xSV r,s

i , {j ∈ SV r,s : i has received the credential σr,sj as part of mr,sj,i }; and

#si (x) is redefined to be the number of j ∈ SV r,s

i from which i receives x as part of mr,sj,i .

Remark Because the certificate CERT j of each block Bj includes the digital signatures of atleast d verifiers of the last step of round r, together with their credentials, and because Algorand ′

is tightly scheduled, a user can determined, based on his own clock, whether he belongs to knowr.Also note that Knowr includes a fraction ρ of verifiers in SV r,s, and that such verifiers can

compute the status Sr and the quantity Qr.

Forwarding Instructions Unless otherwise specified, a user u does not forward a round-r-step-smessage m of a user i, unless

(1) u receives m, according to his onw local clock, in the time interval (ars,, br,s),(2) m includes a credential of i vouching that i is called to act in step s of round r,(3) u receives m for the first time, and(4) u has already forwarded another round-r-step-s message of i.

Storing Instructions Every user j stores all round-r messages received, until he computes theblock Br.

9.1 Step 1

If i ∈ Knowr is a round-r potential leader, then he computes

1. a maximal round-r payset PAY ri (based on the payments he has seen so far);

2. the candidate block Bri =

(r, PAY r

i , SIGi(Qr−1

), H(Br−1)); and

3. sigpkr,1i

(H (Bri )), that is, his digital signature proper of Br

i , with his ephemeral key pkr,1i .

Then, i destroys the ephemeral secret key skr,1i and, then propagates the message mr,1i comprising

a. his own potential-leader credential τ ri ;

b. the public key pkr,1i ;

c. the authenticating string auth(pkr,1i

), relative to COM

(r)i ;

d. Bri ; and

e. sigpkr,1i

(H (Bri )).

37

9.2 Step 2

If i ∈ SV r,2 ∩Knowr, then he computes Lri , `ri , v′i, and sig

pkr,2i(v′i) as follows

1. Lri is the set of all potential leaders j from which he has received a proper message mr,1`ri ,i

; 24

2. `ri is the lexicographically first ` ∈ Lri such that H (τ`r) ≤ H

(τ rj

)for all j ∈ Lri ;

3. v′i = H(B), if B is a round-r block and sigpkr,1

`ri

(H (B)) is component e of mr,1`ri ,i

,

and v′i = H(Brε) otherwise; and

4. sigpkr,2i

(v′i) is i’s digital signature of H(B), relative to i’s ephemeral key pkr,2i .

Then, i destroys the ephemeral secret key skr,2i , and then propagates the message mr,2i comprising

a. his own verifier credential σr,2i ;

b. the public key pkr,2i ;

c. the authenticating string auth(pkr,2i

), relative to COM

(r)i ;

d. v′i;

e. sigpkr,2i

(v′i); and

f . components a, b, c, and e of mr,1`ri ,i

.

Remarks.

• Step 2 indeed corresponds to the literal Step 2 (as opposed to the second step) of the graded-consensus protocol GC, but “with the initial value v′i = H(B) instead of vi = B”. The reasonis time efficiency: we want the duration of Step 2 to be λ, rather than Λ.

This gained efficiency, however, will cause the final agreed upon value to be an hashed blockat best (if not ⊥). Thus, we will need to argue that the final block Br is always be easilycomputable.

• As we shall argue, by including the components a, b, c, and e of mr,1`ri

in his propagated message,

verifier i prevents `ri , if malicious, to flood the network with legitimate messages.

In fact, by having the right credential, a malicious potential leader has the ability to send everymessage he wants in Step 1, although an honest user will forward at most one of them.

9.3 Step 3

If i ∈ Knowr ∩ SV r,3 and, for some x, #2i (x) ≥ 2t+ 1, then i computes

SIGpkr,3i

(x), his digital signature of x with his ephemeral key pkr,3i .

Then, i destroys the ephemeral secret key skr,3i , and then propagates the message mr,3i comprising

24Note that Lri is a subset of the set of all potential leader os round r, but may fail to coincide with it for a variety of

reasons. For instance, malicious potential leaders may opt not to send their credentials, a valid block, or both. Also,honest potential leaders of round r may not belong to knowr, and thus may lack sufficient information to compute ameaningful candidate block. As for a third example, some honest round-r leaders may have timely transmitted theircredentials, but these have not yet reached i in time.

38

a. his own verifier credential σr,3i ;

b. the public key pkr,3i ;

c. the authenticating string auth(pkr,3i

), relative to COM

(r)i ; and

d. SIGpkr,3i

(x).

For All Other Verifiers All other j ∈ Knowr∩SV r compute #2i (x) for all 20B-value x received.

Remark. Step 3 of Algorand ′ corresponds to (the literal) Step 3 of GC.

9.4 Step 4

If i ∈ Knowr ∩ SV r,4, then he computes the value vi, the grade gi ∈ {0, 1, 2}, and the bit bi asfollows, and his signature of bi as follows.

1. If, for some x, #3i (x) ≥ 2t+ 1, then vi = x and gi = 2.

2. If, for some x, #3i (x) ≥ t+ 1, then vi = x and gi = 1.

3. Else, vi = ⊥ and gi = 0.

4. bi = 0, if gi = 2, and bi = 1 otherwise.

5. SIGpkr,4i

(bi) is his digital signature of bi with his ephemeral key pkr,4i .

Then, i destroys the ephemeral secret key skr,4i and then propagates the message mr,4i comprising

a. his own verifier credential σr,4i ;

b. the public key pkr,4i ;

c. the authenticating string auth(pkr,4i

), relative to COM

(r)i ; and

d. SIGpkr,4i

(bi).

For All Other Verifiers All other j ∈ Knowr ∩ SV r use the same steps 1 through 4 above tocompute their own values vj , grades gj , and and bits bj .

Remark. This Step and the next m − 1 correspond to those of an execution of the binary BAprotocol BBA?m on the initial bits bi, representing whether or not the previous execution of thegraded-broadcast protocol GC ended with a grade of 2.

9.5 Step s = 5 through 2 + m

If i ∈ Knowr ∩ SV r,s, then he computes and signs the bit bi as follows.

1. If #s−1i (0) ≥ 2t+ 1, then i sets bi = 0.

2. If #s−1i (1) ≥ 2t+ 1, then i sets bi = 1.

3. Else, i sets bi = c(s)i , lsb

(min

j∈SV r,si

H(SIGpkr,sj

(s)))

.

4. SIGpkr,si(bi) is his digital signature of bi with his ephemeral key pkr,si .

39

Then, i destroys the ephemeral secret key skr,si and then propagates the message mr,si comprising

a. his own verifier credential σr,si ;

b. the public key pkr,si ;

c. the authenticating string auth (pkr,si ), relative to COM(r)i ; and

d. SIGpkr,si(bi).

For All Other Verifiers All other j ∈ Knowr ∩ SV r use the same steps 1 through 3 above tocompute their own bits bj .

9.5.1 Step 3 + m (“Block-Signing” Step)

If i ∈ Knowr ∩ SV r,3+m, then i computes the bit outi and the block Br as follows.

1. outi = 0, if #s−1i (0) ≥ 2t+ 1, and outi = 1 otherwise.

2. Br = Brε , if outi = 1; else,

3. Br = B, where B is a block, stored in Step 1, such that H(B) = v′, for some 20B-value v′

stored in Step 2.

4. sigpkr,3+m

i(H(Br)), his digital signature proper of H(Br) with his ephemeral key pkr,3+mi .

This done, i destroys the ephemeral secret key skr,3+mi and then propagates the message mr,3+mi

comprising

a. his own verifier credential σr,3+mi ;

b. the public key pkr,3+mi ;

c. the authenticating string auth(pkr,3+mi

), relative to COM

(r)i ; and

d. SIGpkr,3+m

i(H(Br)).

Remark. Most other users —i.e., all users in Knowr who have received the proper messages ofStep 1 and Step 3+m— are also capable, by the ned of Step 3+m, of computing the official newblock Br, as well as a certificate CERT r. Let us know see how all users will eventually be ableto do the same, after reconstructing the block chain up to block Br−1, included, and receivingsufficiently many proper messages of the first and last step of a round r of Algorand ′.

9.6 Reconstruction of the Round-r Block

Whenever i ∈ Knowr and, for some x, block B, and user set X, where

• x is a 20B-value,

• B is a round-r block, either empty or received as part of a message mr,1j,i , such that H(B) = x,

and

• X is a subset of SV r,3+mi of cardinality at least 2t+ 1,

i receives, from each j ∈ X a proper message mr,3+mj,i such that mr,3+m

j,i (d) = x, then i sets

Br = B CERT r = {mr,3+mj,i : j ∈ X}; and Br = (Br, CERT r).

40

9.7 Quick Analysis

.Consider the case that the leader `r of round r exists and is honest. As stated in Theorem

8.2, this case occurs with probability h(1− 1/e). By the message propagation assumption, `r alsobelongs to Knowr with probability at least ρ. Thus, `r exists, is honest, and belongs to Knowr

with probability at least ρh(1 − 1/e). This being the case, at time rT , `r computes his credentialτ r`r , realizes that he is a potential round-r leader, and chooses a maximal block Br

`r , based onall the payments he sees. Since honest users “do not spend more than they own”, Br

`r containsall payments of honest users `r has received by by time rT .25 Thus, at time rT , `r propagatesthe message mr,1

`r consisting of his own credential τ r`r , the block Br`r containing ℘, signed with his

ephemeral round-r-step-1 keys pkr,1`r , and the authenticating string auth(pkr,1`r

)for pkr,1`r .

Let us now argue that Br`r , with probability at least 1 − 10−12, will be certified to be the new

official block Br no matter what the Adversary might do.First of all, notice that the Adversary receives instantaneously (i.e., at time rT ) all Step-1

messages sent by the honest users, and thus immediately realizes that user `r will be identifiedas the round-r leader.26 However, although, he may corrupt `r right away, he cannot stop theproper Step-1 message mr,1

`r . (This is guaranteed by our message propagation assumption, since

`r is honest when he sends mr,1`r . Indeed, no one can stop a message virally propagated message

over the Internet, or any other suitable network.) Accordingly, by time rT +λ, by the propagationassumption and our choice of parameters, with overwhelming probability,27 at least 2t + 1 Step-2honest verifiers i receive all proper potential-leader messages, and thus individually identify `r

as the leader of round r. Indeed, such verifiers are in Knowr, and thus know Qr−1, can verifypotential-leader credential, and will identify `r as the user who hashed credential is smaller. (Atthe same time, malicious users cannot “manufacture” new credentials, due the uniqueness of digitalsignatures, nor alter the ones they legitimately may have.) Accordingly, all honest Step-2 verifierswill authenticate and propagate the same hashed value v′ = H (Br

`r) at time rT + Λ. Again, theAdversary may corrupt these Step-2 verifiers, but cannot block their messages.

Thus, (the properly authenticated) v′ will be received, by time rT + Λ +λ by at least a fractionρ of all honest users, and thus by a fraction ρ of the Step-3 honest verifiers who belong to Knowr.By the message propagation assumption and our choice of parameters, also these verifiers are, withoverwhelming probability, at least 2t + 1. Moreover, for each such verifier i, #2

i (v′) ≥ 2t + 1. In

sum, therefore, at least 2t + 1 honest Step-3 verifiers i will propagate their own credentials, andthe properly authenticate value v′ = H (Br

`r), no matter what the Adversary might do.Accordingly, by time rT + Λ + 2λ, by reasons similar to those already discussed, all above

messages, will be received by at least 2t + 1 Step-4 honest verifiers. Thus, each of these verifier icomputes gi = 2 and vi = v′ = H (Br

`r).At this point, a strange execution of the m-step binary protocol BBA?m ensues. Conceptually,

BBA?m is executed on the initial bits bi, where bi = 0 if and only if gi = 2. What makes thisexecution “strange” is that, at each of its steps, the player set consists of totally different —indeed,

25Our propagation assumption also guarantees that every honest payment ℘, propagated before time rT − λ, andnot yet included in an official payset, will by time rT , be received by a fraction ρ of all honest users. Since, again byTheorem 8.2, `r is a random honest user, we conclude that ℘ ∈ Br

`r with probability at least ρ.26

27Note that this probability is actually strictly greater than 1− 10−12. In fact, 10−12 upperbounds the probabilitythat any of the 2 +m verifiers sets of Steps 2 through 3 +m does not have at least 2t+ 1 honest users.

41

randomly selected— users. Not even the cardinalities of these sets need to be the same. Yet, let usargue that the computation proceeds very much as one of BBA?m with a fixed set of users, morethan 2/3 of which are honest. Rather then analyzing each Step s > 3 separately, as we have done sofar, we give a holistic explanation, so as to provide intuition for future replaceable-player protocolsfor different tasks.

Individuals are not interchangeable. This applies as well to the players of most protocols, whotypically keep private internal states, from one step to the next, that are not deducible from themessages exchanged, that are visible to all. Protocol BBA?m is a remarkable exception, whenexecuted in a propagation network. (Let us stress again, that this is not automatically guaranteedby the propagation method. Indeed, the famous authenticated Byzantine agreement of Dolev andStrong [18] does not appear to be player-interchangeable.)

A close look at the steps of BBA?m reveals that it does not rely on “individual” players. Rather,its players fall into 3 broad classes of users:

C0, the class of all users who have heard 0 from at least 2t+ 1 players in the previous step;C1, the class of all users who have heard 1 from at least 2t+ 1 players in the previous step; andC?, the class of all other users.

Moreover, honest members of the same class are quite indistinguishable from one another. As wehave seen, the parameter p and ρ in Algorand ′ are chosen so that n and t are essentially the samein each verifier set, and so are the fraction of honest users. Now, the only thing that affects theexecution of a step is the number, or better said, the percentage, of the honest users in each of theabove 3 classes. Let us thus argue that this percentage too must be the same.

We have already seen that the Adversary cannot control more than t users in each verifier set,since each such set is selected at random and never relied upon again.

However, at a Step s, the Adversary can instruct each malicious user in the verifier set SV r,s,to propagate

(0) exactly 0 (proper) messages;(1) exactly 1 (proper) message to some of the users (and nothing to the others);(2) exactly 2 (proper) messages to two separate subsets of the users (and none to all others);and so on.

Moreover, in each of these cases, the Adversary can choose the value of each propagated message.However,

The honest users are indistinguishable to him, because he does not know their secret keys,and thus cannot predict their credentials. In fact, by Theorem 8.1, since the selection probabilityis always p, for every round r and step s, the probability that he can predict whether a givenuser i will belong to the verifier set SV r,s is exactly p, and thus independent of i.

Accordingly,

the percentages of verifiers in SV r,s that belong to class C0, C1, and C? respectively coincidewith the percentages of users in the general population who receive/see (a) at least 2t + 1 0s,(b) 2t+ 1 1s, and (c) no do receive at least 2t+ 1 bits equal to each other, from the verifiers inSV r,s−1 by time (r − 1)(Λ +mλ) + (s− 1)λ.

Therefore,

since these users from the general population will randomly be selected with the same probabilityp to belong to the verifier set of each subsequent verifier set,

protocol BA? is executed as if the player set were the same at each step.

42

9.8 Discussion (and Variants)

Different Selection Strategies For Different Applications Protocol Algorand ′ relies a“sufficiently common random selection” for two main applications:

(1) selecting a (potential) round leader in Step 1, and

(2) selecting the coin c(s)i in each Step s.3, for s = 5 through 2 +m.

In both applications, Algorand ′ relies on the generation and propagations of proper credentials,which are then hashed to determine the desired selection. Note, however, that Algorand ′ relieson different strategies in these two applications. In the first one, with good probability, a singlecredential may be propagated. However, with the same probability, no credential may exist. In thesecond application, Algorand ′ essentially calls for the propagation of n credentials, of which onlyone (i.e., the one whose hashed value is smallest) will be selected.

These different strategies ensure that the following invariant, touched upon in Footnote 5.7, iskept: namely, at each step either

(A) each of at most a handful of users is called to propagate a long message, or(B) each of at most a few hundred users is called to propagate a short message.

Case A occurs in application 1. Indeed, in that application, each credential is accompanied bya proposed new block. Thus, at most a handful of different blocks are called to be propagated.This ensures that the time upperbound Λ, guaranteeing that all “properly credentialed” blocks willreach the desired percentage of the users, is sufficiently small.

Note, however, that Algorand ′ could employ the same strategy of application 2 for the leader-selection application. For instance, it could have n potential leaders propagate their ordinarycredentials and proposed blocks, and then select the block whose accompanying credential, oncehashed, is smallest. This approach, would call for the propagation of n blocks. However, the messagetraffic can be kept low by changing the standard message protocol as follows. For instance, a user imay be asked to forward a credential C and the corresponding block B not just if he receives themfrom the first time, but also if he has not received (in the same step) another credential C ′ andcorresponding block B′ such that H(C ′) ≤ H(C). This way, the same credential and block will beultimately selected, but with a smaller message traffic.

From Tightly Scheduled to Asynchronous Algorand ′ Forthcoming.

9.9 From Continual Participation to Lazy Honesty

As we saw, Algorand ′ chooses the look-back parameter k to be at least 100. Let us now show thatchoosing k properly large enables one to remove the Continual Participation assumption.

Continual Participation, that is, Temporary Assumption 2, is a taxing requirement. Yet, it isimportant to ensure that the underlying BA protocol BA? has a proper honest majority. Of course,a honest user may occasionally be absent because he needs to “reboot”, or because he momentarilylooses Internet connection. Such mishaps are not a problem. (If we generously budgeted thepercentage of users the Adversary may corrupt, we might as well absorb occasional “honestabsenteeism”, and treat it as temporary maliciousness.) However, massive honest absenteeismis dangerous. What can be done? One possibility is reinterpreting the Honest Majority of Usersassumption to apply only to the “currently active” rather than “currently existing” users. Thispossibility, however, continues to be dangerous. Since “malice never sleeps” one may find himself inthe unpleasant situation in which the majority of the active users are malicious, rather than honest.

43

This possibility may be addressed via incentives. We prefer to address it by allowing Algorand towork safely with “lazy-but-honest” users. Let us explain.

Lazy Honesty. Roughly speaking, a user i is lazy-but-honest if (1) he follows all his prescribedinstructions, when he is asked to participate to the protocol, and (2) he is asked to participate tothe protocol only very rarely —e.g., once a week— with suitable advance notice, and potentiallyreceiving significant rewards when he participates.

With such a relaxed notion of honesty, we can confidently count on a continual honest majority.Fortunately, to allow for lazy honesty it just suffices to choose the look-back parameter k to belarge enough. Recall that a week consists of roughly 10,000 minutes, and assume that a roundtakes roughly one minute (e.g., on average), and that, at a round r, a user i wishes to plan histime and know if he is going to be a verifier in the coming week. He already knows the valuesQr−10,000, . . . , Qr, since they are actually part of the blockchain. Then, for each m between 1 and10,000, i is a verifier in round r +m if and only if

.H(SIGi

(Qr−10,000+m

))≤ p .

Indeed, (r+m)−(r−10, 000+m) = 10, 000. Thus, to check whether he is going to be called to act asa verifier in the next 10,000 rounds, imust, form = 1 to 10,000, compute σm = SIGi

((Qr−10,000+m

)and check whether .H(σm) ≤ p for some m. If computing a digital signature takes a millisecond,then this entire operation will take him 10 seconds of computing time. If he is not selected asa verifier in any of these rounds, then he can go off-line with an “honest conscience”. Had hecontinuously participated, he would have essentially taken 0 steps in the next 10,000 rounds anyway!If, instead, he is selected to be a verifier in one of these rounds, then he readies himself (e.g., byobtaining all the information necessary) to act as a honest verifier at the proper round.

By so acting, a lazy-but-honest potential verifier i only misses participating to the thepropagation protocol. But a propagation protocol is typically robust. Moreover, the payer andthe payee of recently propagated payments are probably on-line to watch what happens to theirpayments.

Remark. Assuming that one wants to retain all benefits of the previous versions of Algorand,including lazy honesty, k must be chosen to be very large. It should be realized, however, thatk is a genuine parameter, that can be set at will. Notice that, if unpredictability were not adesideratum, then one could implement “lazy honesty” by means of simpler and and non-secretiveselection mechanisms (but of the same spirit).28

10 Protocol Algorand ′ with Honest Majority of Money

We now, finally, show how to replace the Honest MAjority of Users assumption with the much moremeaningful Honest Majority of Money assumption. The basic idea is (in a proof-of-stake flavor)“to select i to belong to SV r,s with a weight (i.e., decision power) proportional to the money ownedby a user i in PKr−100.

28E.g., by the following one: A public key i ∈ PKr−100−K is selected as a verifier for round r if and only if.H

(r, i, Qr−K

)≤ p. Algorand could also work with such “Open Self Selection” mechanisms.

44

Note: We should say PKr−k, so as to be able to choose k large enough to replace continualparticipation. For simplicity, since, one may wish to require continual participation anyway, wechoose k = 100 as before, so as to carry one less parameter.

By our HMM assumption we can choose whether that amount should be owned at round r−100or at (the start of) round r. Assuming that we do not mind continual participation, we opt forthe latter choice. (To remove continual participation, we would have opted for the former choice.Better said, for the money owned at round r− k, whatever the parameter k has been chosen to be)

The are many ways to implement this idea. The simplest way would be to have each key hold

at most 1 unit of money and then select at random n users i from PKr−100 such that a(r)i = 1.

The Next Simplest Implementation

The next simplest implementation may be to demand that each public key owns a fixed, maximumamount of money M , where the value M is such that the probability that a key belongs to theverifier set of more than one step in —say— 100 rounds is negligible. Then, a key i ∈ PKr−100,

owning an amount of money a(r)i in round r, is chosen to belong to SV r,s if

.H(SIGi

(r, s,Qr−1

))≤ p ·

a(r)i

M.

And all proceeds as before.

A More Complex Implementation

The last implemetation “forced a rich participant in the system to own many keys”.An alternative implementation, described below, generalizes the notion of status and consider

each user i to consist of k + 1 copies (i, v), each of which is independently selected to be a verifier,and will own his own ephemeral key pkj,si,v , in a step s of a round r. Above the value k depends on

the amount of money a(r)i owned by i in round r.

Let us now see such a system works in greater detail.

A More general Quantity H(r)i Now the quantity H

(r)i is i’s cryptographic commitment that

pins down a public key pkj,si,v for each copy (i, v) and step s of round r + 100 + j, for at leasta few j = 0, 1, 2, . . . Again, to prove that this is the case, i may easily compute and release an

authenticating string auth(pkj,si,v

).

Number of Copies Let n be the targeted expected cardinality of each verifier set, and let a(r)j

the amount of money owned by a user j at round r. Let Ar be the total amount of money ownedby the users in PKr−100 at round r, that is,

Ar =∑

i∈PKr−100

a(r)i .

If i is an user in PKr−100 ∩Knowr, then i’s copies are (i, 1), . . . , (i, k + 1), where

k =

⌊n · a(r)iAr

⌋.

45

Example. Let n = 1, 000, Ar = 109, and a(r)i = 3.7 millions. Then,

k =

⌊103 · (3.7 · 106)

109

⌋= b3.7c = 3 .

Verifiers and Credentials Let i be a user in PKr−100 ∩Knowr with k + 1 copies.For each v = 1, . . . , k, copy (i, v) belongs to SV r,s automatically. Accordingly, i needs only to

propagate the copy’s ephemeral key pkj,si,v and the authenticating string auth(pkj,si,v

).

For copy (i, k + 1), for each Step s of round r, i checks whether

.H(SIGi

((i, k + 1), r, s,Qr−1

))≤ a(r)i

n

Ar− k .

If so, copy (i, k + 1) belongs to SV r,s. To prove it, i propagates the credential

σr,1ik+1= SIGi

((i, k + 1), r, s,Qr−1

).

In addition, to enable copy (i, k + 1) to act in Step s of round r, i also propagates the copy’s

public key pkj,si,v and its corresponding authenticating string auth(pkj,si,v

).

Example. As in the previous example, let n = 1K, a(r)i = 3.7M , Ar = 1B, and i have 4

copies: (i, 1), . . . , (i, 4). Then, the first 3 copies belong to SV r,s automatically. For the 4th one,conceptually, Algorand ′ independently rolls a biased coin, whose probability of Heads is 0.7. Copy(i, 4) is selected if and only if the coin toss is Heads.

(Of course, this biased coin flip is implemented by hashing, signing, and comparing —as wehave done all along in this paper— so as to enable i to prove its result.)

Business as Usual Having explained how verifiers are selected and their credentials computed,at each step of a round r, the execution of a round goes on in manner similar to that alreadyexplained.

46

APPENDIX

A New Ways to Structure and Compute on Blocks

This section is quite independent of Algorand. It proposes a better way to structure blocks, thatcontinues to guarantee the tamperproofness of all blocks, but also enables more efficient way toprove the content of an individual block, and more generally, more efficient ways to use blocks tocompute specific quantities of interest without having to examine the entire blockchain.

The Tamperproofness of Blockchains Recall that, to form a block chain, a block Br has thefollowing high-level structure:

Br = (r, INFOr, H(Br−1)) .29

Above, INFOr is the information that one wishes to secure within the rth block: in the case ofAlgorand, INFOr = PAY r.

A well-known fundamental property of a blockchain is that it makes the content of each of itsblocks tamperproof. That is, no one can alter a past block without also changing the last block.We quickly recall this property below.

Let the latest block be Blast, and assume that one replaces Br with a different (“crooked”)

block B̃r. Then, since H is collision resilient, H(B̃r) is, with overwhelming probability, different

from H(Br). Accordingly, no matter how one chooses the information ˜INFOr+1 in the block in the

blockchain, namely B̃r+1 = (r+ 1, ˜INFOr+1, H(B̃r)), it is the case that, due again to the collisionresiliency of H,

B̃r+1 6= Br+1 .

This inequality propagates. That is, B̃r+2 differs from Br+2; and so on; so that, ultimately,

B̃last 6= Blast .

Inefficient Verifiability of Individual Blocks in Blockchains Consider a person X whodoes not know the entire blockchain, but knows that Bz is a correct block in it. Then, the abovefundamental property enables one to prove to such a person that any individual block Br, where ris smaller than z, is also correct. Namely, one provides, as a “proof”, all the intermediate blocksBr+1, . . . , Bz−1 to X, who then uses H to regenerate the blockchain from r onwards, until hereconstructs the zth block and checks whether or not it coincides with the block Bz that he knows.

29Recall that we use superscripts to indicate rounds in Algorand. This section, however, is dedicated to blockchainsin general, and thus the rth block may not correspond to the rth round in the sense of Algorand. That is, above “r”is just the block number, and it is included in block Br for clarity.

Also note that the above general structure of a block is conceptual. For instance, in Bitcoin, Br may include thedigital signature of the block constructor, the one who has solved the corresponding computational riddle. In Algorand, the authentication of Br —that is, a matching certificate CERTX— may be separately provided . However, it couldalso be provided as an integral part of Br. In this latter case, since there may be many valid certificates, the leader`r of round r may also include, in its message to all round-r verifiers, a valid certificate for the output of the previousround, so that agreement will also be reached on what the certificate of each round r is.

47

If this is the case, then X is convinced of the correctness of Br. Indeed, anyone capable of findingsuch a seemingly legitimate proof must also have found a collision in the hash function H, whichis practically impossible to find.

To see the usefulness of such verifiability, consider the following example. Assume that theblockchain is generated by a payment system, such as Bitcoin or Algorand, and let X be a judgein a court case in which the defendant wishes to prove to X that he had indeed made a disputedpayment P to the plaintiff two years earlier. Since it it reasonable to assume that the judge canobtain the correct last block in the chain, or at least a sufficiently recent correct block, Bz, “all”the defendant has to do is to provide the proof Br+1, . . . , Bz−1 to the judge, who then verifies it asexplained. The problem, of course, is that such a proof may be quite long.

Blocktrees Since the ability to prove efficiently the exact content of a past individual block isquite fundamental, we develop new block structures. In these structures, like in blockchains, theintegrity of an entire block sequence is compactly guaranteed by a much shorter value v. This valueis not the last block in the sequence. Yet, the fundamental property of blockchains is maintained:any change in one of the blocks will cause a change in v.

The advantage of the new structures is that, given v, and letting n be the number of blockscurrently in the sequence, the content of each individual block can be proved very efficiently. Forinstance, in blocktrees, a specific embodiment of our new block structures, if the total number ofblocks ever produced is n, then each block can be proved by providing just 32 · dlog ne bytes ofinformation.

This is indeed a very compact proof. In a system generating one block per minute, then, after2 millennia of operations, dlog ne < 30. Thus, less than 1KB —1,000 bytes— suffice to prove thecontent of each individual block. (Less than 2KB suffice after two billion years, and 4KB sufficeessentially forever.) Moreover, such a proof is very efficiently verified.

Details about blocktrees can be found in Appendix A.

Efficient Status A different efficiency problem affects Bitcoin and, more generally, paymentsystems based on blockchains. Namely, to reconstruct the status of the system (i.e., which keysowns what at a given time), one has to obtain the entire payment history (up to that time),something that may be hard to do when the numbers of payments made is very high.

We shall use blocktrees in order to attain also such desiderata

We construct blocktrees by properly modifying a much older notion recalled below.

A.1 Merkle Trees

Merkle trees are a way to authenticate n already known values, v0, . . . , vn−1, by means of a singlevalue v, so that the authenticity of each value vi can be individually and efficiently verified.

For simplicity, assume that n is a power of 2, n = 2k, so that each value is uniquely identifiedby a separate k-bit string, s. Then, a Merkle tree T is conceptually constructed by storing specificvalues in a full binary tree of depth k, whose nodes have been uniquely named using the binarystrings of length ≤ k.

The root is named ε, the empty string. If an internal node is named s, then the left child ofs is named s0 (i.e., the string obtaining by concatenating s with 0), and the right child is named

48

s1. Then, identifying each integer i ∈ {0, . . . , n− 1}, with its binary k-bit expansion, with possibleleading 0s, to construct the Merkle tree T , one stores each value vi in leaf i. After this, he choosesthe contents of all other nodes in a bottom up fashion (i.e., he chooses first the contents of all nodesof depth k − 1, then those of all nodes of depth k − 2, and so on). If vs0 and vs1 are respectivelycontained in the left and right child of node s, then he stores the 256-bit value vs , H(vs0, vs1) innode s. At the end of this process, the root will contain the 256-bit value vε.

A Merkle tree of depth 3 is shown in Figure 1.A, at the end of this paper.Assume now that vε is known or digitally signed, and let us show how each original value vi

can be authenticated relative to vε.Consider the (shortest) path P that, starting from a node x, reaches the root. Then, the

authenticating path of the content vx of x is the sequence of the contents of the siblings of the nodesin P , where the sibling of a node s0 is node s1, and viceversa. Accordingly, an authenticating pathof a leaf value in a tree of depth k consists of k − 1 values. For example, in a Merkle tree of depth3, the path from leaf 010 to the root is P = 010, 01, 0, ε, and the authenticating path of v010 isv011, v00, v1, since the root has no sibling. See Figure 1.B at the end of this paper.

To verify (the authenticity of) vi, given its authenticating path, relative to the root value vε, onereconstructs the contents of the nodes in the path from leaf i to the root, and then checks whetherthe last reconstructed value is indeed vε. That is, if the authenticating path is x1, . . . , xk−1, thenone first H-hashes together vi and x1, in the right order —i.e., computes y2 = H(vi, x1), if thelast bit of i is 0, and y2 = H(x1, vi) otherwise. Then, one H-hashes together y2 and x2, in theright order. And so on, until one computes a value yk and compares it with vε. The value vi isauthenticated if and only if yk = vε.

The reason why such verification works is, once again, that H is collision resilient. Indeed,changing even a single bit of the value originally stored in a leaf or a node also changes, withoverwhelming probability, the value stored in the parent. This change percolates all the way up,causing the value at the root to be different from the known value vε.

A.2 Blocktrees

As we have seen, Merkle trees efficiently authenticate arbitrary, and arbitrarily many, known valuesby means of a single value. Indeed, in order to authenticate k values v0, . . . , vk−1 by the singleroot content of a Merkle tree, one must first know v0, . . . , vk−1 in order to store them in the first kleaves of the tree, store e in other proper nodes, and then compute the content of all other nodesin the tree, including the root value. Merkle trees have been used in Bitcoin to authenticate thepayments of a given block. Indeed, when constructing (or attempting to construct) a given block,one has already chosen the payments to put in the block.

However, using Merkle trees to authenticate the block sequence as it grows is more challenging,because one does not know in advance what blocks to authenticate. Nonetheless, let us show thatMerkle trees can, used in a novel way, yield new block structures enabling the efficient provabilityof individual blocks.

Conceptually, in our alternative structures, a block Bi has the following form:

Br = (r, INFOr,Sr) ,

where the structural information Sr is a sequence of dlog re 256-bit strings, that is, dlog re stringsof 32 bytes each. Below, we provide just a specific example of a suitable structural information Sr,

49

but it will be clear that our techniques enable myriads of efficient block structures alternatives toblockchains. Those corresponding to our specific choice of Sr are block trees.

Blocks in Blocktrees For brevity, let us set INFOr = vr. Conceptually speaking again, westart with a full binary tree T of depth k such that 2k upper-bounds the number of possible valuesvr. The values v0, v1, . . . are produced in order. When a new value vi is generated, it is, againfiguratively speaking, stored in leaf i of T , and then various strings are computed and stored in thenodes of T , so as to construct a Merkle tree Ti. One of these strings is the distinguished string e.When appearing in a node x of Ti, string e signifies that no descendant of x belongs to Ti.

When the first value, v0, is generated and stored in leaf 0, T0 coincides with (the so filled) node0 of T . In fact, such T0 is an elementary Merkle tree. Its depth is dlog(0 + 1)e = 0, its root isR0 = 0, and it stores v0 in its first depth-0 leaf (and in fact in its only leaf and node).

When the i+ 1st value, vi, has been generated and stored in leaf i of T (possibly replacing thestring e already there), the Merkle tree Ti is constructed as follows from the previous Merkle treeTi−1. (By inductive hypothesis, Ti−1 has depth is dlog ie; root Ri−1; and i depth-dlog(i+1)e leaves,respectively storing the values v0, . . . , vi−1.)

Let Ri = Ri−1, if leaf i is a descendant of Ri−1, and let Ri be the parent of Ri−1 otherwise.Let P be the (shortest) path, in T , from leaf i to node Ri. For every node j in P , store the specialstring e in its sibling j′, if j′ is empty. Finally, for each node s in P , in order from leaf i (excluded)to node Ri (included), store in s the value vs = H(vs0, vs1), if vs0 and vs1 respectively are the valuesstored in the left and right child of s. It is easy to see that the subtree of T rooted at Ri, storingthe so computed values in its nodes, is a Merkle tree. This Merkle tree is Ti.

The construction of the first 8 consecutive Merkle trees, when the initially empty full binarytree T has depth 3, is synthesized in Figure 2, at the end of the paper. Specifically, each sub-figure 2.i highlights the Merkle tree Ti by marking each of its nodes either with the special stringe (signifying that “Ti is empty below that node”), or with a number j ∈ {0, . . . , i − 1} (signifyingthat the content of the node was last changed when constructing the Merkle tree Tj). To highlightthat the content of a node, lastly changed in Tj , will no longer change, no matter how many moreMerkle trees we may construct, we write j in bold font.

With this in mind, we generate our block-tree structure as follows. After choosing theinformation INFOi that we want to secure in the ith block, we store the value vi = INFOiinto leaf i of T ; construct the Merkle tree Ti; and set

Si = (Ri, authi) ,

where Ri is the root of Ti and authi is the authenticating path of vi in Ti. Then, the block is

Bi = (i, INFOi,Si) .

Notice that Si indeed consists of dlog ie strings. To ensure that each string in authi, and thus everystring in Si, is actually 256-bit long, rather than storing vi in leaf i, we may store H(vi) instead.

Efficient Block Constructibility To construct the structural information Si that is part ofblock Bi, it would seem that one would need information from all over the Merkle tree Ti. Afterall, INFOi and thus the value vi stored in leaf i, are readily available, but the authenticating pathof vi, authi, comprises contents of nodes of previous trees, which in principle may not be readily

50

available. If one had to obtain the entire Ti−1 in order to construct Si, then constructing a newblock Bi might not be too efficient.

However, note that, very much in the spirit of block chains, each Bi is trivially computable fromthe previous block Bi−1 and the chosen information INFOi. Indeed, each string in Si is one of

(a) H(INFOi),

(b) the fixed string e,

(c) a string in Si−1, and

(d) a string obtained by hashing in a predetermined manner strings of the above types.

Figure 3, at the end of this paper, highlights —via a thick border— the nodes whose contentssuffice to compute Si = (Ri, authi) for the construction of the first 8 blocks in a blocktree.Specifically, each subfigure 3.i highlights the nodes whose contents suffice for generating Si. Eachhighlighted node is further marked a, b, or c, to indicate that it is of type (a), (b), or (c). Nodes oftype (d), including the root Ri, are left unmarked.

In sum, in a blocktree-based system, block generation is very efficient.

Efficient Block Provability Let us now analyze proving the content of an arbitrary individualblock Br to someone knowing a subsequent block (e.g., the current last block).

Let Bz = (z, INFOz,Sz) be a block, where Sz = (Rz, authz) and z > r. Then, to prove thatBi is the correct ith block relative to Bz, it suffices to provide the authenticating path of INFOiin the Merkle tree Tz.

30 Thus, such a proof comprises only dlog ze 32-bit strings.As already pointed out in Section ??, log n is at most 30 in most applications (and at most 100

in essentially all human applications). Thus, quite differently from the case of blockchains provingthe content of an individual block is very efficient with blocktrees.

A.3 Efficient Status Computation

Having improved the organization of payment information, let us now turn our attention toimproving that of status information.

Recall that the official status at round r, Sr, consists of a list of tuples, specifying, foreach current public key X, the amount owned by X, and possibly additional information:

Sr = . . . ,(X, a

(r)X , . . .

), . . . The amount of money owned by the keys in the system changes

dynamically, and we need to keep track of it as efficiently as possible.So far, as in Bitcoin (although its status information is quite different), the current status is

not authenticated, but deduced from the authenticated history of payments. There are, however,significant advantages to authenticating each Sr as well, rather than only PAY r. Indeed, thiswould make it easier and more secure, for a new user, or a user who has been off-line for a while,to catch up with the current system status. In particular, such a user X may have been chosento be a round-r verifier, and thus needs to learn Sr−1 in order to perform his duties in round r.Accordingly, X might ask and obtain the status Sr−1 from another user, but then may worry about

30Notice that this path is actually the concatenation of the authenticating path of INFOi in Ti and the“authenticating path” of Ri in Tz. Indeed, the notion of an authenticating path, defined for (the contents of)leafs, is readily extended to arbitrary nodes.

51

the accuracy of the information received. This worry could dissipate if Sr−1 were authenticated.But: who should authenticate the status at the end of a round?

In Algorand, there is a natural choice: namely, (a given majority of) the verifiers of that round.31

Indeed such verifiers, in order to perform their duties, presumably already know the previous status,and thus it is easy for them, after computing the current official payset, to compute and authenticatealso the corresponding new status.

In sum, the round-r verifiers may conceptually operate as follows:

(a) Obtain the authenticated status Sr−1;

(b) Compute, authenticate, and propagate PAY r; and

(c) Compute, authenticate, and propagate Sr.

This way of operating presupposes that (at least a given majority of) the verifiers in SV r alreadyknow, or can correctly obtain, SV r−1. But obtaining SV r−1 is easier than correctly obtainingSr−1. In particular, under all improved verifier-selection mechanisms of Section ??, each verifierY in SV r−1 provides a proof of his belonging to SV r−1, and this proof may be easily requested,obtained, and verified.32

The above organization of a round may already be very beneficial. Indeed, it avoids that onemust obtain the entire payment history in order to be sure about how much money each usercurrently owns. Yet, there is room for efficiency improvements.

Indeed, note that propagating an authenticated version of PAY r can be done reasonablyefficiently, because, although the number of users may be very large, the number of paymentsmade in a single one-minute round, can be expected to be reasonably small. However, if there were—say— 100 million users in the system, and the status of each of them comprises —say— 100bytes, then Sr would comprise 10 gigabytes.

Propagating such a large file is not trivial. Even authenticating it is not trivial. Indeed,computing H(Sr) by hash-chaining, and then digitally signing the 32-byte result, would requirecomputing one digital signature, which is trivial, but computing 100 million hashings (at about amicrosecond per hash) would require 100 seconds. Only propagating the verifiers’ digital signaturesof Sr is trivial, because they are relatively few and short.

Accordingly, let us put forward a better status structure.

Efficient Status from Blocktree Technology

Recall that, to generate a new block Br at round r, we generated a Merkle tree Tr from the previousMerkle tree Tr−1 and its associated short structural information Sr−1, by

(a) storing the information of a new block, INFOr = vr, into empty leaf r of the underlying bigbinary tree T ;

31Equivalently, the leader of that round may authenticate the resulting status together with his proposed paysetfor the round, and then the verifiers may verify both, and agree and certify the official payset and the resulting statustogether.

32Recall that such a proof consists of a digital signature of Y , where Y was a key already existing a few roundsbefore r − 1. But then, for most Y ∈ SV r−1, Y is a much older key, and thus may be already known to a verifierX in SV r, who at least learned some prior status. In any case, at least some information is necessary to verify anyauthenticated information. The point is to ensure that such necessary information is minimal, and easily known oreasy to learn.

52

(b) using Sr−1 in order to compute the contents of the nodes in the (shortest) path from leaf r tothe (possibly new) root Rr of the new Merkle tree Tr; and

(c) computing the new structural information Sr to facilitate the construction of the next Merkletree.

Note that Tr is the smallest Merkle tree that contains the first r leaves of T . In principle, toconstruct Tr one would have to compute, by hashing, the contents of all its nodes, in the typicalbottom-up fashion, starting from its leaves. This would take a long time. It is having available theproperly constructed structural information Sr−1 that prevents us from having to handle all leavesand indeed all nodes of Tr.

In our new application, we plan a similar strategy. Namely,

Game Plan We plan to start with a big, underlying, and initially empty, binary tree T ′;to progressively store status information in its leaves; to construct a sequence of Merkle trees,T ′1, T

′2, . . ., where the leaves of T ′r collectively store the entire status information Sr; and to construct

a matching sequence of structural information, S ′1,S ′2, . . ., in order to facilitate the construction offuture trees. 4

This is a simple enough plan. But: How to choose S ′r?Before answering this question, we should decide what status information is stored in a leaf. We

could certainly store status information about multiple keys, but prefer, for conceptual simplicity,to store just the status information of a single key. Specifically, the ith leaf of T ′ stores only thetuple corresponding to ith key in the system, in order of appearance. (Recall that, in a round r,multiple keys may appear for the first time as payees in payset PAY r. But since all sets in Algorandare ordered, including all paysets PAY r, the ith key in order of appearance is well defined.) Havingclarified this, we now construct the structural information S ′r in two stages. Better said, we letS ′i consist of two components, each corresponding to a difference between the Merkle tree Tr, ofour previous block-structure application, and the Merkle tree T ′r, of our current status-structureapplication.

A First Difference, A First component of S ′r A first difference between the Merkle treesT1, T2, . . . and the Merkle trees T ′1, T

′2, . . . is the following. Each Tr had only one more (non-empty)

leaf than Tr−1. However, T ′r may have many more leaves than T ′r−1.More precisely, let nr be the cardinality of PKr, that is, the number of users at the start of

round r, and qr the cardinality of PKr \ PKr−1, that is, the number of new keys appearing aspayees in PAY r.

Then

• nr+1 = nr + qr;

• T ′r has nr+1 non-empty leaves, each storing the tuple corresponding to a key in PKr+1;

• the old leaves of T ′r (i.e., its first nr leaves) continue to store the tuples corresponding to theold keys (i.e., the keys in PKr);

• the new leaves of T ′r (i.e., its next qr leaves) store the tuples corresponding to the new keys(i.e., the keys in PKr \ PKr−1); and

• the depth of T ′r is dlog nr+ie.

53

Despite the fact that there may be qr > 1 new leaves in T ′r, it is easy to see that the same type ofstructural information as in our block application suffices to enable the “efficient addition to Tr−1”of the new qr leaves.

Recall that, in our previous application, Sr = (Ri, authr). Then, in our current appli-cation, let Sr consist of Rr and the authenticating paths of all new leaves: that is, Sr ,(Rr,

{authr : vr ∈ PKr \ PKr−1}). Then,

The first component of S ′r is Sr.

The structural information Sr suffices to “handle the inclusion in T ′r+1” of all new leaves, withouthaving full knowledge of T ′i . Better said, Si suffices to efficiently construct a Merkle tree, T ′′r , that(1) contains T ′r−1 as a subtree, and (2) includes the new qr leaves. (In fact, since the authenticatingpaths of the new leaves overlap, one may define Sr more succinctly. We omit to do so since it isnot going to yield significant improvements in efficiency.)

However, a second difference between our block-structure and status-structure applicationsprevents T ′′r from being the Merkle tree T ′r we want.

The Second Difference, and the Second Conceptual Component of S ′r The seconddifference is that, while the old leaves of Tr have the same contents they had in Tr−1, the oldleaves of T ′r may have different contents in T ′r than in T ′r−1. This is so because the payments ofround r cause the amounts owned by some old keys to change. More precisely, letting tr be the totalnumber of payers and payees in PAY r, then up to tr old leaves of T ′r can have contents differentfrom those they had in Tr−1. What makes it easy to “efficiently add to T ′r ” the contents of thenew leaves is that the new leaves are “neatly” positioned in T ′r. Namely they consecutively appearafter the last old leaf. Thus, conceptually speaking, to add them in T ′r we need not know the entiretree T ′r−1, but only the information stored at its “frontier” (which, in a tree of logarithmic depthis not much information at all).

By contrast, in the official payset PAY r−1, the old payer and payee keys may appear anywherein the old leaves of T ′r. But this is far from implying that we need the whole Tr−1 in order toconstruct T ′r correctly. Indeed whenever, due to a payment in PAY r−1, the content of an old leafi changes, only the contents of the path Pi, that is, the (shortest) path from leaf i to the root,need to be updated, and this path is short (indeed logarithmic in nr). Moreover, the number ofpayments in PAY r−1, and more generally the number of payments in any one-minute round, shouldbe small relative to the total number of public keys in the system. This leads to a hypotheticalsecond component of S ′r as follows.

Let X be an old key whose content, due to the payments in PAY r−1, has changed. That is,(X, a

(r−1)X , . . .

)6=(X, a

(r)X , . . .

). If X is the ith key, then, to reconstruct the contents of the nodes

of Pi in T ′r, it suffices to have the authenticating path of leaf i in the Merkle tree T ′r−1. Identifyingeach key with its number of appearance, we may denote this authenticating path by authr−1(X),and refer to leaf i as leaf X.

As we said, such an authenticating path is very short. More precisely, it consists of dlog nrevalues of 32-bytes each. Since log 109 < 30, in a system with a billion users authr−1(X) is at most

one kilo-byte of information. Moreover, given authr−1(X) and the new content(X, a

(r)X , . . .

)of leaf

X, computing the contents of all nodes in the path from leaf X to the root of T ′r only requires, againin a system with one billion users, at most 30 hashings, which is a trivial amount of computation.

54

Thus, conceptually, the second component of S ′r−1 we need to finish the construction of T ′r consistsof all such authenticating paths:

The conceptual second component of S ′r−1 is S̃ ′r−1 = {authr−1(X) : X old }.

The problem, of course, is that no matter how helpful the previous-round verifiers want to be,

they cannot provide S̃ ′r−1, because they cannot predict what payments the users will make in thenext round. Thus: how can the round-r verifiers obtain authr−1(X)?

A New Requirement In a payment system, each user X has a personal interest in keeping—and in fact safekeeping— a proof of the current amount he owns. (In addition, other users mayask X for such a proof. For instance, if X wishes to make a payment P to a payee Y in a roundr, then Y may demand to see a proof that X indeed has enough money to make at least thatpayment.)

More generally, a user X may wish to have a proof of his own full status, SrX , that is, at a round

r, of the tuple SrX =(X, a

(r)X , . . .

).

In the envisaged status structure, a proof of Sr−1X , the status of X at the start of round r,precisely consists of the authenticating path authr−1(X) in tree T ′r−1.

Thus, assuming for a moment that each user X can easily obtain such a proof, we may requirethat, for a round-r payment P with payer X and payee Y , also the proofs authr−1(X) andauthr−1(Y ) be presented. For simplicity, let us assume that they are actually explicitly included inP itself (e.g., as part of P ’s information field I) and that they must be properly verified for P to bevalid. To emphasize that the payments are now so enriched, we shall denote the official payset of around r by PAY r. (Let us stress again that PAY r is essentially comparable in length to PAY r.)

Then, the second component of S ′r consists of the authenticating paths, in the Merkle tree T ′r!,for each X ∈ OldKeys (PAY r), that is for each key X whose content changes due to the paymentsin PAY r:

S̃ ′r = {authr(X) : X ∈ OldKeys(PAY r)} .

We now make two claims:

(a) The verifiers of a round r, given PAY r−1, Sr−1 and S̃r−1, can determine PAY r, Sr and S̃r.

(b) Every user Z, whether or not being a payer or a payee in round r, can, from PAY r, Sr, S̃r,and authr−1(Z), efficiently compute authr(Z), that is a proof of his status SrX .

(In fact it is because of this ability of the users that the round-r verifiers can receive the enrichedofficial payset PAY r−1 instead of the old PAY r−1.)

Let us first informally prove the first claim.First of all, once the users propagate the payments of round r, the round-r verifiers, and the

round leader construct PAY r as usual (e.g., as in the preferred version of Algorand).Second, the round-r verifiers can construct (and then authenticate) Sr from Sr−1 as explained

above.Third, the round-r verifiers retrieve, from the enriched payments in PAY r, the authenticating

paths authr−1(X) T ′r−1 for any X ∈ OldKeys(PAY r), and, from these authenticating paths and Sr,they finally produce the new authenticating paths in T ′r that constitute S̃r.

55

Let us now informally argue the second claim.A user Z can compute authr(Z) by the following three steps.

1. For each old key X ∈ OLdKeys(PAY r), Z uses the new content of leaf X and authr(X)to compute both pathr(X) and contentr(X): respectively (a) the sequence of nodes in the(shortest) path from leaf X to the root of T ′r (in that order) and (b) the sequence of thecontents of the nodes in pathr(Z) (in the same order).

2. If one node in pathr(X) coincides with the sibling of a node in the path, in T ′r−1, from leaf Zto the root of T ′r−1, then Z replaces in authr−1(Z) the content of that node with the contentof the same node in contentr(X).

Let authr−1(Z)′ be the resulting sequence after all such replacements.

3. From the structural information Sr, Z computes the authenticating path of the root of T ′r−1 inthe new tree T ′r, authr(Rr−1), and then appends this authenticating path to authr−1(Z)′.

It is easy to see that the resulting sequence is Z’s new authenticating path authr(Z) in T ′r.

Summarizing In sum, we have organized the status information in a Merkle-tree fashion, so that(1) each user has a short proof of his own status at each round; (2) each payment at a round ris enriched so as to include a proof of round-(r − 1) status of the payers and the payee; (3) it ispossible for the verifiers of a round r to process all payments and produce the (enriched) officialpayset, using only a very small amount of information from the previous round (rather than theentire status of the previous round); and (4) it is possible for every user, possessing a proof of hisown status in the previous round, to efficiently compute a proof of his status in the current round,whether he has made any payments or not.

Notice that this organization puts some burden on the users who want to make a payment, but(a) putting one’s financial status in order when making a payment may not be an unreasonablerequirement; (b) a user is not required to update the entire status information, but only his ownsmall piece of it; (c) if a user does not keep updating his own status, then he does not need torecompute it, round-by-round, from the last time in which he did: all he has to do is to request fromsomeone else just his own current and short proof of his current status, a proof whose correctnesshe can verify based on the same short structural information used by the verifiers; and (d) theverifiers need only obtain a short amount of information, if they have been off-line for a long time,in order to be fully prepared to perform their duties.

Finally, (f) if so desired, as in our block application, one can efficiently prove the amount ownedby the users at a given round.

One Important Protection As we have said, the status of a player X at a round r, SrX =(X, a

(r)X , . . .

), may possess several fields in addition to “his own name” and “the amount he owns”.

Let us suggest that one of these fields, say the third, be a self-certified declaration of how much X

owns at a round q ≤ r: for example, SIGX

(X, q, a

(q)X

). Thus, the round-r status of X is of the

formSrX =

(X, a

(r)X , SIGX

(X, q, a

(q)X

). . .).

When X is the payer or the payee of a payment P in a round r, P should include, as already said,the proof of his status at round r−1, authr−1(X), which of course authenticates also the third field.

56

But for P to be a valid round-r payment, not only should auth(r−1)X be correct, but the third field

should actually be “up-to-date”: that is, it must indicate the last round, SIGX

(X, r − 1, a

(r−1)X

),

and must correctly report the amount X actually ownwed at the end of round r − 1.There are several clear advantages in so enriching the status information.

B Permissioned Algorand, Banks, and Law Enforce-

ment

In this section we discuss a permissioned version of Algorand that balances privacy and traceability,enables a new class of incentives, and provides a new, and non-controlling, role for banks or otherexternal entities. This permissioned version relies on the classical notion recalled below.

B.1 Digital Certificates

Assume that the public key pk of a party R, who has the authority to register users in the system,is publicly known. Then, after identifying a user i and verifying that a public key pki really belongsto i, R may issue a digital certificate, Ci, guaranteeing that, not only is pki a legitimate public keyin the system, but also that some suitable additional information infoi holds about i. In this casea certificate has essentially the following form:

Ci = SIGR(R, pki, infoi).

The information specified in infoi may be quite varied. For instance, it may specify i’s role in thesystem and/or the date of issuance of the certificate. It might also specify an expiration date, thatis, the date after which one should no longer rely on Ci. If no such a date is specified, then Ci isnon-expiring. Certificates have long been used, in different applications and in different ways.

B.2 Algorand with (Non-Expiring) Certificates

In Algorand, one may require that each user i ∈ PKr has digital certificate Ci issued by a suitableentity R (e.g., by a bank in a pre-specified set). When making a round-r payment ℘ to anotheruser j, i may forward Ci and/or Cj along with ℘, or include one or both of them in ℘ itself: thatis, symbolically,

℘ = SIGi(r, r′, i, j, a, Ci, Cj , I,H(I)) .

Assuming the latter practice,

• A payment ℘ is considered valid at a round, and thus may enter PAY r, only if it also includesthe certificates of both its payer and its payee.

Moreover, if the certificates have expiration dates r = [t1, t2], then t2 must be smaller than theearliest expiration date.

• At the same time, if such a payment belongs to PAY r, then its corresponding money transferis executed unconditionally.

57

A Role for Non-Expiring Certificates Once the certificate Ci of a user i expires, or prior toits expiration, as long as i is “in good standing”, R may issue a new certificate C ′i with a laterexpiration date.

In this case, therefore, R has significant control over i’s money. It cannot confiscate it for itspersonal use (because doing so would require being able to forge i’s digital signature), but he canprevent i from spending it. In fact, in a round r following the expiration date of Ci, no payment ofi may enter PAY r.

Note that this power of R corresponds to the power of a proper entity E —e.g., the government—to freeze a user’s traditional bank account. In fact, in a traditional setting, such E might evenappropriate i’s money.

A main attraction of cryptocurrencies is exactly the impossibility, for any entity E, to separate auser from his money. Let us thus emphasize that this impossibility continues to hold in a certificate-based version of Algorand in which all certificates are non-expiring. Indeed, a user i wishing tomake a payment to another user j in a round r can always include the non-expiring certificates Ciand Cj in a round-r payment ℘ to j, and ℘ will appear in PAY r, if the leader `r of the round ishonest. In sum,

non-expiring certificates cannot be used to separate a user from his money,but may actually be very valuable to achieve other goals.

B.3 Preventing Illegal Activities Via (Non-Expiring) Certificates

The payer and the payee of a payment made via a traditional check are readily identifiable byevery one holding the check. Accordingly, checks are not ideal for money laundering or other illegalactivities. Digital certificates, issued by a proper registration agent, could be used in Algorand toensure that only some given entities can identify the owner i of a given public key pki, and onlyunder proper circumstances, without preventing i from making the payments he wants. Let us givejust a quick example.

There may be multiple registration authorities in the system. For concreteness only, let thembe approved banks, whose public keys are universally known (or have been certified, possibly via acertificate chain) by another higher authority whose public key is universally known, and let G bea special entity, referred to as the government.

To join the system as the owner of a digital public key, i needs to obtain a certificate Ci from oneof the approved banks. To obtain it, after generating a public-secret signature pair (pki, ski), i asksan approved bank B to issue a certificate for pki. In order to issue such a certificate, B is requiredto identify i, so as to produce some identifying information IDi.

33 Then, B computes H(IDi),and (preferably) makes it a separate field of the certificate. For instance, ignoring additionalinformation, B computes and gives i

Ci = SIGB(B, pki, H(IDi)).

Since H is a random oracle, no one can recover the owner’s identity from Ci. Only the bank knowsthat pki’s owner is i. However, if the government wishes to investigate —say— the payer of a

33Going “overboard”, such Ii may include i’s name and address, a picture of i, the digital signature of i’s consent—if it was digital—, or i can be photographed together with his signed consent, and the photo digitized for inclusionin Ii. For its own protection and that of i as well, the bank may also obtain and keep a signature of i testifying thatIi is indeed correct.

58

payment ℘ = SIGpki(r, pki, pki′ , a, Ci, Ci′ , I,H(I)), it retrieves from ℘ both the relevant certificateCi and the bank B that has issued Ci, and then asks or compels B, with proper authorization (e.g.,a court order), to produce the correct identifying information IDi of i.

Note that the bank cannot reveal an identifying piece of information ID′i that is different fromthat originally inserted in the certificate, because H is collision-resilient. Alternatively, instead ofH(IDi, it suffices to use any “commitment” to IDi, in the parlance of cryptography.

One particular alternative to store, in Ci, an encryption of IDi, E(IDi, preferably using aprivate- or public-key encryption scheme E, that is uniquely decodable. In particular, IDi may beencrypted with a key known only to the bank B: in symbols, E(IDi) = EB(IDi). This way, thegovernment needs B’s help to recover the identifying information IDi.

Alternatively, E may be a public-key encryption scheme, and IDi may be encrypted with apublic key of the government, who is the only one to know the corresponding decryption key. Insymbols, E(IDi) = EG(IDi). In this case the goverment needs not to have B’s help to recoverIDi. In fact, the identities of the payers and the payees of all payments are transparent to G.However, no one else may learn IDi from EG(IDi), besides the government and the bank be thathas compute EG(IDi) from IDi. Moreover, if the encryption EG(IDi) is probabilistic, then evensomeone who has correctly guessed who the owner i of pki may be would be unable to confirm hisguess.

Let us stress that neither B nor G, once the certificate Ci has been issued, has any control overi’s digital signatures, because only i knows the secret key ski corresponding to pki. In addition,neither B or G can understand the sensitive information I of the payment ℘ of i, because onlyH(I) is part of ℘. Finally, neither B nor G is involved in processing the payment ℘, only therandomly selected verifiers are.

In sum, the discussed law-enforcement concern about Bitcoin-like systems is put to rest, withouttotally sacrificing the privacy of the users. In fact, except for B and G, i continues to enjoy thesame (pseudo) anonymity he enjoys in Bitcoin, and similar systems, relative to any one else: banks,merchants, users, etc.

Finally, by using more sophisticated cryptographic techniques, it is also possible to increaseuser privacy while maintaining his traceability under the appropriate circumstances.34

B.4 New Roles for Banks

Key certification in Algorand is a new role for the banks. A role that a bank B can easily performfor its customers. Indeed, B already knows them very well, and typically interacts with them fromtime to time. By certifying a key i of one of its customers, B performs a simple but valuable (andpossibly financially rewarded) service.

Another role a bank B may have in Algorand is that, properly authorized by a customer i, Bcan transfer money from i’s traditional bank accounts to a digital key the digital pki that i ownsin Algorand. (In fact, B and all other banks do so “at the same exchange rate”, Algorand maybe used as a very distributed, convenient, and self-regulated payment system, based on a nationalcurrency.) One way for a bank B to transfer money to pki is to make a payment to pki from adigital key pkB that B owns in Algorand. In fact, banks may, more easily than their customers,

34For instance, focusing on the last scenario, once i has obtained from bank B a certificate Ci =SIGB(B, pki, EG(IDi)) , it is also possible for i to obtain another certificate C′i = SIGB(B, pk′i, E

′G(IDi)) , for

a different public pk′i, for which B no longer knows that IDi is the decryption of E′G(IDi).

59

convert national currency into Algorand at a public exchange.35

Finally, since banks are often trusted, a user i, retaining full control of the payments he makes,may wish to delegate a bank B to act on his behalf as a verifier, sharing with B his verificationincentives.36

B.5 Rewards from Retailers Only

Whether or not the registration authorities are banks, and whether or not law-enforcement concernsare addressed, a permissioned deployment of Algorand enables one to identify (e.g., within itscertificate Ci) that a given key pki belongs to a merchant.

A merchant, who currently accepts credit card payments, has already accepted his having topay transaction fees to the credit card companies. Thus, he may prefer paying a 1% fee in Algorandto paying the typically higher transaction fee in a credit card system (in addition to preferring tobe paid within minutes, rather than days, and in much less disputable ways.)

Accordingly, a certificate-based Algorand may ensure that(1) all rewards a small percentage of the payments made to merchants only, and yet(2) the verifiers are incentivized to process all other payments as well.

For instance, letting A′ be the total amount paid to retails in the payments of PAY r, one couldcompute a maximum potential reward R′ (e.g., R′ = 1%A′). The leader and the verifiers, however,will not collectively receive the entire amount R′, but only a fraction of R′ that grows with the totalnumber (or the total amount, or a combination thereof) of all payments in PAY r. For example,keeping things very simple, if the total number of payments in PAY r is m, then the actual rewardthat will be distributed will be R′(1−1/m). As before, this can be done automatically by deductinga fraction 1%(1−1/m) from the amount paid to each retailer, and partitioning this deducted amountamong the leader and verifiers according to a chosen formula.

C Variants

Let us discuss some possible variants to Algorand.

C.1 Alternative Verifier-Selection Mechanisms

So far, Algorand selects the leader `r and the verifier set SV r of a round r automatically, fromquantities depending on previous rounds, making sure that SV r has a prescribed honest majority.We wish to point out, however, alternative ways to select the verifiers and the leader.

One such way, of course, is via a cryptographic protocol (e.g., a multi-party function evaluationprotocol in the sense of Goldreich, Micali, and Wigderson [?]) run by all users. This approach,however, may be slow when the number of users in the system is high. Let us thus consider twoclasses of alternative mechanisms: chained , nature-based , and trusted-party. (One may also mixthese mechanisms with those already discussed.)

35Going a step further, the Government may also be allowed to print money in Algorand, and may transfer it, inparticular, to banks, or, if the banks are sufficiently regulated, it may allow them to generate Algorand money withincertain parameters.

36“Representative” mechanisms for doing just that are described in Appendix C.3. That section is devotedto implementations of Algornand with a specially constructed communication network. However, the delegationmechanisms described there may be adopted no matter what the underlying network may be.

60

Chained Mechanisms

Inductively assuming that each SV r has an honest majority, we could have SV r itself (or moregenerally some of the verifiers of the rounds up to r) select the verifier set and/or the leader ofround r. For instance, they could do so via multi-party secure computation. Assuming that theinitial verifier set is chosen so as to have an honest majority, we rely on boot-strapping: that is, thehonest majority of each verifier set implies the honest majority of the next one. Since a verifier setis small with respect to the set of all users, his members can implement this selection very quickly.

Again, it suffices for each round to select a sufficiently long random string, from which theverifier set and the leader are deterministically derived.

Nature-Based Mechanisms

The verifier set SV r and the leader `r of a given round r can be selected, from a prescribed set ofusers PV r−k, in a pre-determined manner from a random value vr associated to the round r. Inparticular, vr may be a natural and public random value. By this we mean that it is the widelyavailable result of a random process that is hardly controllable by any given individual. For instance,vr may consist of the temperatures of various cities at a given time (e.g., at the start of round r, orat a given time of the previous round), or the numbers of stock of given security traded at a giventime at a given stock exchange, and so on.

Since natural and public random value may not be sufficiently long, rather than setting

SV r vr← PV r−k ,

we may instead set

SV r H(vr)← PV r−k ,

elongating H(vr) in a suitable peseudo-random fashion, is needed, as already discussed.

Trustee-Based Mechanisms

An alternative approach to selecting SV r involves one or more distinguished entities, the trustees,selected so as to guarantee that at least one of them is honest. The trustees may not get involvedwith building the payset PAY r, but may choose the verifier set SV r and/or the leader `r.

The simplest trustee-based mechanisms, of course, are the single-trustee ones. When there isonly one trustee, T , he is necessarily honest. Accordingly, he can trivially select, digitally sign, andmake available SV r (or a sufficiently random string sr from which SV r is derived) at round r.

This a simple mechanism, however, puts so much trust on T . To trust him to a lesser extent,T may make available a single string, sr, uniquely determined by the round r, that only hecan produce: for instance, sr = SIGT (r). Then, every user can compute the random stringH(SIGT (vr)), from which SV r is derived.

This way, T does not have the power to control the set SV r. Essentially, he has a single strategicdecision at his disposal: making SIGT (r) available or not. Accordingly, it is easier to check whetherT is acting honestly, and thus to ensure that he does so, with proper incentives or punishments.

The problem of this approach is (the lack of) unpredictability. Indeed, T may compute SIGT (r)way in advance, and secretly reveal it to someone, who thus knows the verifier set of a future round,and has sufficient time to attack or corrupt its members.

61

To avoid this problem, we may rely on secure hardware. Essentially, we may have T be a tamper-proof device, having a public key posted “outside” and a matching secret key locked “inside”,together with the program that outputs the proper digital signatures at the proper rounds. Thisapproach, of course, requires trusting that the program deployed inside the secure hardware has nosecret instructions to divulge future signatures in advance.

A different approach is using a natural public random value vr associated to each round r. Forinstance, T may be asked to make available SIGT (vr). This way, since the value vr of future roundsr is not known to anyone, T has no digital signature to divulge in advance.

The only thing that T may still divulge, however, is its own secret signing key. To counterthis potential problem we can rely on k trustees. If they could be chosen so as to ensure that asuitable majority of them are honest, then they can certainly use multi-party secure computationto choose SV r at each round r. More simply, and with less trust, at each round r, we may haveeach trustee i make available a single string, uniquely associated to r and that only i can produce,and then compute SV r for all such strings. For instance, each trustee i could make available thestring SIGi(r), so that one can compute the random string sr = H(SIG1(r), . . . , SIGk(r)), fromwhich the verifier set SV r is derived. In this approach we might rely on incentives and punishmentsto ensure that each digital signature SIGi(r) is produced, and rely on the honesty of even a singletrustee i to ensure that the sequence s1, s2, . . . remains unpredictable.

The tricky part, of course, is making a required string “available”. If we relied on propagationprotocols then a malicious trustee may start propagating it deliberately late in order to generateconfusion. So, trustee-based mechanisms must rely on the existence of a “guaranteed broadcastchannel”, that is, a way to send messages so that, if one user receives a message m, then he isguaranteed that everyone else receives the same m.

Finally, rather than using secure computation at each round, one can use a secure computationpre-processing step. This step is taken at the start of the system, by a set of trustees, selected soas to have an honest majority. This step, possibly by multiple stages of computation, produces apublic value pv and a secret value vi for each trustee i. While this initial computation may takesome time, the computation required at each round r could be trivial. For instance, for each roundr, each trustee i, using his secret value vi, produces and propagates a (preferably digitally signed)single reconstruction string sri , such that, given any set of strings Sr that contains a majority ofthe correct reconstruction strings, anyone can unambiguously construct SV r (or a random valuefrom which SV r is derived). The danger of this approach, of course, is that a fixed set of trusteescan be more easily attacked or corrupted.

C.2 More Sophisticated Cryptographic Tools

Algorand can also benefit from more sophisticated cryptographic tools. In particular,

1. Combinable Signatures. Often, in Algorand , some piece of data D must be digitally signed bymultiple parties. To generate a more compact authenticated record, one can use combinabledigital signatures. In such signatures, multiple public keys —e.g., PK1, PK2 and PK3 could becombined into a single public key PK = PK1,2,3— and signatures of the same data D relativeto different public keys can be combined into a single signature relative to the correspondingcombined public key. For instance, SIG1(D), SIG2(D) and SIG3(D) could be transformed intoa single digital signature s = SIG1,2,3(D), which can be verified by anyone relative to publickey PK1,2,3. A compact record of the identifiers of the relevant public key, in our example the

62

set {1, 2, 3}, can accompany s, so that anyone can quickly gather PK1, PK2 and PK3, computePK = PK1,2,3, and verify the signature s of D based on PK.

This allows to turn multiple related propagations into a single propagation. In essence, assumethat, during a propagation protocol, a user has received SIG1,2,3(D) together with a record{1, 2, 3} as well as SIG4,5(D) together with a record {4, 5}. Then he might as well propagateSIG1,2,3,4,5(D) and the record {1, 2, 3, 4, 5}.

2. Tree-Hash-and-Sign. When a signature authenticates multiple pieces of data, it may be usefulto be able to extract just a signature of a single piece of data, rather than having to keep orsend the entire list of signed items. For instance, a player may wish to keep an authenticatedrecord of a given payment P ∈ PAY r rather than the entire authenticated PAY r. To this end,we can first generate a Merkle tree storing each payment P ∈ PAY r in a separate leaf, andthen digitally sign the root. This signature, together with item P and its authenticating path,is an alternative signature of essentially P alone.

3. Certified Email. One advantage of the latter way of proceeding is that a player can send hispayment to ` by certified email,37 preferably in a sender-anonymous way, so as to obtain areceipt that may help punish ` if it purposely decides not to include some of those payments inPAY r

` .

C.3 Hardware-Based Removal of the No Isolation Assumption

There is only the fourth and last temporary assumptions to be removed: that is, the No Isolationassumption. In this section we show how to remove it via a specially engineered communicationsub-network. In a sense, we present a “hardware-based” approach. Yet, as we shall argue at theend of this section, this approach may quite attractive.

In the next section we show how to remove the No Isolation assumption by means of a purely“software-based” approach. That is, we remove it by a more sophisticated version of Algorand ′3,indeed, our last version of Algorand: Algorand ′4.

Let us first highlight a property sufficient for our purposes.

The Property IP To protect Algorand ′3 from isolation attacks, we do not need to preventisolation altogether. It suffices that, as for a corruption attack, after the Adversary chooses anhonest user to isolate, he takes at least a round to actually isolate him. Better said, we need thatthe following isolation assumption IA holds.

IP: For each round r, there exists a set ISr, comprising a given minority of the users, such thatduring r the Adversary can only isolate users in ISr.

(Notice that Property IP allows the Adversary to choose ISr arbitrarily at every round r. Inparticular, ISr+1 need not contain or have a large intersection with ISr.) Indeed, as long as themajority of the users are neither malicious nor honest-but-isolated, Algorand ′3 works correctly.

If the Adversary were obliged to attack the physical components of the underlying network(gates, routers, switches, fiber lines, etc.), simply securely hosting key components might ensure

37E.g., by the light-weight certified email of US Patent 5,666,420.

63

that ISr stays the same during at least round r. After all, altering secure routers or digging holesto cut lines takes time.

Unfortunately, no such physical attacks are needed in networks like the Internet. The Adversarycan simply and very quickly isolate any honest user i he wants by means of a denial-of-service attack.That is, the Adversary may inundate him with useless messages generated by the malicious usershe controls. The Internet is prone to such attacks. As an all-purpose network used by innumerableapplications, the Internet may be incapable of stopping malicious message traffic aimed at disruptingAlgorand’s smooth running. In principle, and perhaps in practice too, once the Adversary learnswho the verifier set of round r is, he can conduct a successful denial-of-service attack against all ofthe verifiers in SV r who are honest, even if they are 1000 or so.

Moreover, one cannot rely on auditability in order to effectively curb denial-of-service attacksover the Internet. The Internet has quite limited auditability.

A Special Sub-Network (and Two Classes of Users) Notice that isolation attacks areeffective against the relatively few verifiers who try to agree on the official payset of a given round,not against the user who propagate their own desired payments for the round.

Accordingly, as Bitcoin de facto makes a sharp distinction between ordinary users and miners,Algorand could distinguish ordinary users and potential verifiers. As miners need to have farms ofdedicated, riddle-solving, computers to be in business, potential verifiers need to have access to aa network, the PV-Network, properly engineered to prevent isolation attacks.

The set of potential verifiers at a given round r, PV r, could be very large, but the set ofselected verifiers of round r, SV r, continues to be suitably small, but is now selected, as in —say— Algorand ′3 from PV r−k, for a suitably chosen k, rather than from PKr−k. After the userscommunicate to the potential verifiers the payments they wish to make in a round r, SV r is selectedand its members run —say— Algorand ′3 over the PV-Network to choose the final payset PAY r.

Notice that

1. Access to the separate PV-Network makes membership in PV r de facto permissioned.38

2. We are agnostic about the type of permission enabling a user i to become a potential verifier.39

3. We are also agnostic about the specific way chosen to publicize PV r.40

4. Finally we are agnostic about how ordinary users communicate their payments to the potentialverifiers, and how the latter communicate the official paysets to ordinary users.41

38But, though in a permissioned fashion, we allow (and in fact find it important for) PV r to grow dynamically.39Perhaps, it may suffice for i to exhibit a digital certificate attesting that he has rented a server in the PV-Network.

Alternatively, his digital certificate may attest that i has rented a few dedicated links to a randomly selected subsetof PV (e.g., a subset of PV selected via the hash function H). Indeed, “random attachment” is a good way to ensurethe reliability of a network by preventing the forming of small “bottlenecks” that might disconnect the network graph.

40Preferably, however, PV r is publicized in authenticated form. We note that Algorand works even if PV r is notpublicized in its entirety at every round. In particular, as we shall see, every potential verifier i may be given a digitalsignature σi, relative to a universally known “Algorand Master Key”, attesting that i is indeed a potential verifier(e.g., from some round onwards). Then, an honest potential verifier i may send σi together with any message hesends as a potential verifier. Of course, therefore, a malicious i may trivially withhold sending σi, if he so wants. Yet,Algorand will continue to work properly.

41Perhaps, in either case, one can rely on propagation over the Internet.

64

Constructing the Special PV-Network We discuss, in order of increasing scalability, threetypes of PV-Networks.

1. Totally Redundant Networks. A totally redundant network has a separate secure fiberconnection `i,j between any two potential verifiers i and j (and a separate message buffer for eachincoming line). Such networks are by definition “switchless”, as they do not require routing.

If the PV-Network is totally redundant, then the Adversary cannot isolate any honest potentialverifier i. If a malicious j flooded i with messages, i could simply “turn off” its `i,j line.

Totally redundant networks, however, are not cheap and do not scale well, although one mightbe creative in realizing them.42

2. Sparse Random Networks. When the number n of potential verifiers is large, one maydirectly link each potential verifier i with k, k << (n − 1), randomly chosen other potentialverifiers. Such a sparse random PV-Network is again switch-less. (For instance, all communicationcould occur via message propagation, where the neighbors of each node i are the ones with whichhe shares a dedicated line.)

In such a PV-Network, the Adversary might, of course, be able to corrupt some potentialverifiers and coordinate them so as to isolate a set SI of honest ones. This set is solely determined,at any point in time, by the currently malicious verifiers and the actual choice of the dedicatedlinks. Importantly, the size of SI cannot be large if the number of malicious players is small.The mathematical reason for this is that such randomly linked networks, with overwhelmingprobabilities, do not have “small cuts”, that is, few vertices whose removal disconnects the network.This implies that, if the Adversary controls a small percentage (e.g., 10%) of the potential verifiers,he could not isolate a much larger percentage (e.g., 20%) of honest ones.

Sparse random networks are clearly cheaper to build and much more scalable than totallyredundant ones. They also easily allow adding a new potential verifier i to the network. To do so,it suffices to instal (or rent) dedicates links from i to a proper number of randomly selected nodesalready in the network, and a few other links as well.

3. Algorand-Primed Networks. More scalable yet are PV-Network, with Algorand-dedicateddevices —switches, routers, etc.— so as to use much fewer Algorand-dedicated links (from user touser; device to device, or device to user). We envisage such devices D to be securely hosted, tohave a suitable clock, and to be preferably “Algorand-primed” in the following sense.

As we shall see, Algorand ensures that, in each time interval TI of a proper length, only asmall and clearly identified set selected potential verifiers need to send a message. More precisely,

42First, one may actually be content to build a totally redundant PV-Network by renting all necessary fiber lines—e.g., from companies such as Hurricane Electric. Assume that there are 10 potential verifiers, and that, on average,a dedicated fiber connection costs —say— $1K/month to rent. Then, each potential verifier would have to share(e.g., 50-50) the cost of each of his 99 separate lines with the potential verifier on the other end, so as to incur a costof roughly $60K per year, perhaps not a prohibitive expenditure. In a totally redundant network of 100 potentialverifiers, the above yearly cost would, of course, be $600K. (Possibly an affordable amount, if the yearly financialrewards that a potential verifier expects to receive for his services —see Section i— are significant.) More than thiscost, however, the limiting factor may be that, in order to rent existing fiber connections (rather than installingnew ones), the potential verifiers must be located where the fibers already are. But several alternatives could beconsidered. For instance, rather than building a totally redundant network for 100 potential verifiers, one mightlocate them, in IiP style, in the same “cluster”. Then, to ensure geographical redundancy, one might build —say—10 such clusters across the Country, and connect the “copy” of potential verifier i in the first cluster to the othercopy of i in each of the other 9 clusters.

65

in TI each such a selected verifier i needs to send exactly one, digitally signed, message, whosesize is clearly bounded. Thus, in addition to every potential verifier, also every network device D,may prevent the propagation of messages m from non-selected potential verifiers, by checking that(a) m is digitally signed by a proper selected verifier i, (b) m is the first message sent by i in theinterval TI, and (c) m has the expected length.

As in the case of users, corrupting secure network devices is hard, corrupted honest devices mayrestore honest functionality, and it is harder to simultaneously corrupt many of them. Accordingly,at a given point in time, the Adversary may control only a given small set Sc of potential verifiersand only a given small set of devices, Dc, including fiber connections. Thus, if the PV-Network hasbeen designed properly, the Adversary cannot use Sc and Dc in order to isolate a large fraction ofhonest potential verifiers in an Algorand-primed PV-Network.

Conclusions. We note that the expenses of setting up and running a proper PV-Network, thoughnot trivial, are not prohibitive, and can in fact be borne by the potential verifiers themselves, whocollect substantial financial rewards for their services.

We also would like to remind that, if the Adversary, with much cost, succeeds to corrupt evena majority of the potential verifiers, then he cannot manufacture any payments to himself. Rather,he can only

• cause the payset PAY r of a given round r to be empty, or

• cause a fork in Algorand’s public ledger and, in so doing, provably incriminate some maliciouspotential verifiers.

Accordingly, running Algorand ′3 with the help of a PV-Network might be simple and attractive.The users need only to protect their own secret signing key, and enjoy a very fast, secure, convenient,and reasonably distributed system, in which they can choose a potential verifier to partner with inorder to participate in the rewards. The potential verifiers may appreciate operating in a controllednetwork, and unlike in —say— a credit-card system— not be responsible for protecting any sensitivedata of someone else.

D The Proof-Of-Work Approach to Block Generation

The notion of a proof-of-work goes back to Dwork and Naor, who proposed using it as an anti-spammechanism [35]. Bitcoin and similar systems use it in order to reach a form of distributed consensuson the payment history. Let us sketch the latter use and explain why it is intrinsically linked tothe formation of forks.43

In all these systems (as in ours) payments are continually made and propagated in a peer-to-peer fashion. Accordingly, at every point in time, different users inevitably see different payments.A form of consensus is thus needed to reconcile their views of the payment hystory.

As discussed, payments are organized in blocks, nested so as to form a blockchain: B1, B2, . . .The generation of a new block is delegated to all users, but in a way that ensures that, no matterhow many users try to do so, only one of them is expected to succeed in a ten-minute period. The

43For this limited purpose, significant details of Bitcoin and other cryptocurrencies (such as the organization ofmoney in “individual coins”, the incentive structure, etc.) are not relevant, and will be ignored.

66

purpose of this 10-minute delay, on average, between successive blocks is preventing the confusionthat would arise from having multiple alternative blocks being generated almost simultaneously.

At the highest level, such a delay is enforced as follows. To be valid, a block must include thesolution to a separate (indeed, block-specific) cryptographic riddle. The level of difficulty of sucha riddle is empirically chosen so that only one solution is expected to be found, by anyone in theworld who tries to find it, in a ten-minute interval.

A bit more specifically, blocks must satisfy a special property, defined via a cryptographic hashfunction recall that H, again modeled as an oracle mapping every input to an independent andrandomly chosen 256-bit long string. To be valid, each block Bi, in addition to its valid payments,contains an arbitrarily chosen value vi, and must be such that H(Bi) ends in k 0s, for some integerparameter k less than 256. Since H is a random oracle, for each chosen set of valid new paymentsand value vi, the probability that H(Bi) ends in k 0s is 2−k.

Consider a user who tries to generate a new block, for instance, the ith block. First, he preparesa set of new and valid payment; second, he chooses a random value vi; third, calling Bi the candidateblock he computes H(Bi) and checks whether the last k bits of H(Bi) indeed are all 0s. If this isnot the case, the user may keep the same set of payments in the candidate block (or may add afew more that he has recently seen), change the value vi, and hash the so changed Bi again, untilhe eventually succeeds, in which case he propagates the valid block Bi.

For instance, if k = 40, then roughly a quadrillion attempts are expected before succeeding atforming a new valid block. The value k is actually chosen so that the expected time to generatea new block is 10 minutes. This latency of course depends on the number of users who tries togenerate a new block, since each othem has a probability 2−k of succeeding. Thus, the value of kmust be adjusted from time to time.44

Proof-Of-Work and Forks This approach to block generation (and consensus) ushers in forks.Let X and Y be two different users who, seeing the same longest blockchain B = B1, . . . , Bi−1,

almost simultaneously succeed to generate and append to it a new block. Since, however, the recentpayments they see need not be the same, the new blocks they generate, respectively BX

i and BYi ,

may be different. So, for the moment, at least X and Y hold different opinions about the last blockof “their own” public ledger.

At this point, each of X and Y propagates his own new block, while other users make andpropagate their own new payments. During all this propagation, many (or even most) other usersmay thus see both the chain BX = B1, . . . , Bi−1, B

Xi and the chain BY = B1, . . . , Bi−1, B

Yi . Let Z

be such a user. Accordingly, when trying to create a new block, Z must choose which of the twochains to elongate. That is, when constructing a new candidate block, Z must choose whether toinclude in it H

(BXi

)or H

(BYi

). Assume that Z generates and starts disseminating a new block,

BZi+1, elongating the chain BY , while the blocks BX

i and BYi are still being propagated. (Indeed,

although a new block is expected to be produced in 10 minutes, it is possible to produce it in amuch shorter time.) Then, for a while, it may happen that, in the eyes of at least some users, fourpublic ledgers exist: namely, the (i − 1)-block blockchain B, the i-block blockchains BX and BY ,and the (i+ 1)-block blockchain BZ .

44For instance, if, while k stays the same, the number of users trying to generate a new block dramaticallyincreases, then one notes that a new block may arise in 2 rather than 10 minutes. But as this fact is noticed, Bitcoinautomatically re-adjusts k. This fact, based on our description so far, of course makes it more complex to verifywhether a sequence of blocks is a legitimate block chain. But we do not need to delve in these complications.

67

Because users are asked to elongate the longest blockchain they see, we expect that, from somepoint in time onwards, only one of BX and BY will be a sub-chain of every user’s public ledger.That is, we expect that the ith block of the public ledger will eventually stabilize. Although it ishard to predict when such stabilization may occur, in practice some users may choose to rely on thepayments appearing in the ith block of a blockchain only when they see the blockchain comprisesat least i + 6 blocks. Accordingly, for such users, the expected true “time to payment” is not tenminutes, but one hour.

Acknowledgements

I would like to first acknowledge Sergey Gorbunov, my coauthor of the cited Democoin system,which provided the foundation of Algorand: relying on a cryptographically chosen and ever-changing committee of verifiers.

My most sincere thanks go to Maurice Herlihy, for many enlightening discussions, for pointingout that pipelining will improve Algorand’s throughput performance, and for greatly improving theexposition of an earlier version of this paper. (Unfortunately for the reader, I have further revisedit, so I am solely to blame for its current deficiencies.)

Thanks to Ron Rivest for innumerable discussions and guidance in cryptographic research overmore than 3 decades, for coauthoring the cited micropayment system that has inspired one of theverifier selection mechanisms of Algorand, and for informing me that he and David Karger hadalready thought of a similar way of structuring payments in a public ledger.

Thanks to Jing Chen, for several helpful discussions and her usual patience, kindness, andunfailing wisdom.

Thanks to my colleagues Arvind, Hari Balakrishnan, Frans Kaashoek, Robert Morris, MartinRinard, and particularly to Nikolai Zeldovich for trying to explain to a naive theoretician (to putit mercifully) how modern Internet communication protocols work.

Thanks again to Nickolai, as well as Yossi Gilad and Rotem Hamo, for many inspiringdiscussions, and for starting to test these ideas.

Last, but not least, many thanks to my colleague, friend, and fellow cryptographer VinodVaikuntanathan, for several deep discussions and insights, which I hope will bring this technologyto the next level. Meanwhile the travel and companionship are great fun.

References

[1] Bitcoin Block Chain Info, https://blockchain.info, Feb 2015.

[2] HowStuffWorks.com. How much actual money is there in the world?, https://money.

howstuffworks.com/how-much-money-is-in-the-world.htm As of 5 June 2016.

[3] Wikiquote.org. William F. Buckley Jr., https://en.wikiquote.org/wiki/William_F.

_Buckley,_Jr. As of 5 June 2016.

[4] S. Gorbunov and S. Micali. Democoin: A Publicly Verifiable and Jointly Serviced Cryptocurrencyhttps://eprint.iacr.org/2015/521 May 30, 2015.

[5] Ethereum. Ethereum https://github.com/ethereum/ As of 12 June 2016.

68

[6] Bitcoinwiki. Proof of Stake http://www.blockchaintechnologies.com/

blockchain-applications As of 5 June 2016.

[7] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System http://www.bitcoin.org/

bitcoin.pdf May 2009.

[8] Coindesk.com. Bitcoin: A Peer-to-Peer Electronic Cash System http://www.coindesk.com/

ibm-reveals-proof-concept-blockchain-powered-internet-things/ As of June 2016.

[9] Wikipedia. Numbers Game https://en.wikipedia.org/wiki/Numbers_game As of 5 June2016.

[10] D. L. Chaum, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms,Commun. ACM, Volume 24, Number 2, Pages 84–90, 1981.

[11] Bitcoin Computation Waste, http://gizmodo.com/the-worlds-most-powerful-computer-network-is-being-was-504503726, 2013.

[12] S. King, S. Nadal, PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake, 2012.

[13] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008.

[14] S. Goldwasser, S. Micali, and R. Rivest. A Digital Signature Scheme Secure Against AdaptiveChosen-Message Attack. SIAM Journal of Computing, 17 no 2, April 1988, pp. 281-308

[15] M. Pease, R. Shostak, and L. Lamport. Reaching agreement in the presence of faults. J. Assoc.Comput. Mach., 27 (1980), pp. 228-234.

[16] M. Fischer. The consensus problem in unreliable distributed systems (a brief survey). Proc.International Conference on Foundations of Computation, 1983.

[17] B. Chor and C. Dwork. Randomization in Byzantine agreement, in Randomness andComputation. S. Micali, ed., JAI Press, Greenwich, CT, 1989, pp. 433-498.

[18] D. Dolev and H.R. Strong. Authenticated algorithms for Byzantine agreement. SIAM Journalon Computing 12 (4), 656-666.

[19] D. Dolev. The Byzantine Generals Strike Again. J. Algorithms, 3, (1982), pp. 14-30.

[20] R. Turpin and B. Coan. Extending binary Byzantine agreement to multivalued Byzantineagreement. Inform. Process. Lett., 18 (1984), pp. 73-76.

[21] M. Ben-Or. Another advantage of free choice: Completely asynchronous agreement protocols.Proc. 2nd Annual Symposium on Principles of Distributed Computing, ACM, New York, 1983,pp. 27-30.

[22] M. Rabin. Randomized Byzantine generals. Proc. 24th Annual IEEE Symposium onFoundations of Computer Science, IEEE Computer Society Press, Los Alamitos, CA, 1983.pp. 403-409.

69

[23] M. Castro and B. Liskov. Practical Byzantine Fault Tolerance, Proceedings of the ThirdSymposium on Operating Systems Design and Implementation. New Orleans, Louisiana, USA,1999, pp. 173–186.

[24] P. Feldman and S. Micali. 18. An Optimal Probabilistic Algorithm for Synchronous ByzantineAgreement. (Preliminary version in STOC 88.) SIAM J. on Computing, 1997.

[25] J. Katz and C-Y Koo On Expected Constant-Round Protocols for Byzantine Agreementhttps://www.cs.umd.edu/ jkatz/papers/BA.pdf

[26] N. Lynch. Distributed Algorithms. Morgan Kaufmann Publishers, 1996.

[27] Litecoin, https://litecoin.org/, 2011.

[28] D. Lazar and Y. Gilad. Personal Communication.

[29] S. Micali and R. L. Rivest. em Micropayments Revisited. Lecture Notes in Computer Science,Vol. 2271, pp 149-163, Springer Verlag, 2002

[30] I. Bentov, R. Pass, and E. Shi. The Sleepy Model of Consensus. Cryptology ePrint Archive:Report 2016/918

[31] C. Decker and R. Wattenhofer. Information Propagation in the Bitcoin Network. 13-th IEEEConference on Peer-to-Peer Computing, 2013.

[32] S. Micali. Algorand: The Efficient Public Ledger. https://arxiv.org/abs/1607.01341.

[33] en.wikipedia.org/wiki/Sortition.

[34] S. Micali, M. Rabin and S. Vadhan. Verifiable Random Functions. 40th Foundations ofComputer Science (FOCS), New York, Oct 1999

[35] C. Dwork and M. Naor. Pricing via Processing, Or, Combatting Junk Mail. Advances inCryptology, CRYPTO92: Lecture Notes in Computer Science No. 740. Springer: 139147.

70

Fig. 1.A A Full Merkle Tree of Depth 3

𝑣𝑠 = 𝐻 𝑣𝑠0, 𝑣𝑠1 for all binary string 𝑠 ∈ 0,1 ≤3

𝑣ϵ

𝑣0 𝑣1

𝑣00 𝑣01 𝑣10 𝑣11

𝑣000 𝑣010𝑣001 𝑣011 𝑣010 𝑣101 𝑣110 𝑣111

𝒗𝟏

𝒗𝟎𝟎

𝑣010 𝒗𝟎𝟏𝟏

Fig. 1.B The Authenticating Path of Value 𝑣010

The path from 𝑣010 to the root can be found by following the arrows.The contents of the siblings of the nodes in the path are shown in bold font. The authenticating path of 𝑣010 is the (bottom-up) sequence of the siblings’ contents: 𝑣011, 𝑣00, 𝑣1.The contents of all nodes in the path can be computed from 𝑣010 and its authenticating path via 𝐻. All other nodes are ignored.

71

𝟎 𝟎

𝟏

𝟏

𝟎

𝟏

𝟏 𝟐 𝑒

2

2

𝟎

𝟏

𝟏 𝟐 𝟑

𝟑

𝟑

𝟎

𝟏

𝟏 𝟐 𝟑

𝟑

𝟑

𝟒

4

4

4

𝑒

𝑒

𝟎

𝟏

𝟏 𝟐 𝟑

𝟑

𝟑

𝟒

𝟓

5

5

𝟓

𝑒

𝟎

𝟏

𝟏 𝟐 𝟑

𝟑

𝟑

𝟒

𝟓

6

6

𝟓 𝑒𝟔

6

𝟎

𝟏

𝟏 𝟐 𝟑

𝟑

𝟑

𝟒

𝟓

𝟕

𝟕

𝟓 𝟔

𝟕

𝟕

Fig. 2 The First 8 Merkle trees constructed within a full binary tree of depth 3.

In Fig 2.𝑖, nodes marked by an integer belong to Merkle Tree 𝑇𝑖.Contents of nodes marked by 𝑖 (respectively, by 𝒊) are temporary (respectively, permanent).

2.0 2.1

2.32.2

2.7

2.52.4

2.6

72

Fig. 3 The Items sufficient to construct the structural information of the first 8 blocks in a blocktree.

In Fig 3.𝑖, the contents of the boldly circled nodes suffice to construct the structural information of block 𝐵𝑖.For instance, the node marked 𝑐 in 2.2 is the root 𝑅1 of tree 𝑇1, which is explicitly part of block 𝐵1.

3.0 3.1

3.33.2

3.7

3.53.4

3.6

𝒂 𝒂𝒄

𝒄

𝒆𝒂

𝒄

𝒂𝒄

𝒄

𝒄

𝒄

𝒄

𝒄

𝒄

𝒂

𝒂 𝒂

𝒆

𝒆

𝒆

𝒄

𝒄 𝒂

𝒆

73