Efficient and Egalitarian Consensus by Ling Ren B.Eng., Tsinghua University (2012) S.M., Massachusetts Institute of Technology (2014) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of

Doctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY

September 2018 ○c Massachusetts Institute of Technology 2018. All rights reserved.

Author...... Department of Electrical Engineering and Computer Science August 10, 2018

Certified by...... Srinivas Devadas Professor of Electrical Engineering and Computer Science Thesis Supervisor

Accepted by...... Leslie A. Kolodziejski Professor of Electrical Engineering and Computer Science Chair, Committee on Graduate Students 2 Efficient and Egalitarian Consensus by Ling Ren

Submitted to the Department of Electrical Engineering and Computer Science on August 10, 2018, in partial fulfillment of the requirements for the degree of Doctor of Philosophy

Abstract Consensus is a classic problem in distributed computing. Research on consensus has traditionally focused on the permissioned setting where participants are fixed and know each other beforehand. Recently, the digital currency Bitcoin has popularized a new line of research on consensus in a permissionless environment, where participants may join or leave at any time and need not know how many other participants exist or who they are. Bitcoin’s solution, now known as the Nakamoto consensus, is to build a proof-of-work chain and treat the longest proof-of-work chain as consensus decisions. However, this elegant solution does have limitations. First, it has long latency: under current parameters, it can take hours for a Bitcoin transaction to go through. Second, its use of hash-based proof-of-work has raised concerns about fairness and energy consumption. This thesis presents distributed algorithms and cryptographic primitives to address these limitations. I will first describe Solida, a permissionless consensus protocol with low latency. It hasbeen observed that traditional Byzantine consensus protocols have much lower latency than Nakamoto consensus. Following this observation, Solida adapts traditional Byzantine consensus protocols from the permissioned setting to the permissionless setting by combining them with proof-of-work. I also design improved protocols for permissioned synchronous Byzantine consensus. I then turn to potential replacements for hash-based proof-of-work. I construct a proof-of-space protocol with tight security bounds as an energy-efficient alternative. Finally, I revisit the concept of memory-hard functions, the standard approach to improve fairness in proof-of-work. I argue that the memory-hardness approach overlooks energy efficiency fairness and suggest bandwidth-hard functions as egalitarian alternatives.

3 Thesis Supervisor: Srinivas Devadas Title: Professor of Electrical Engineering and Computer Science

4 Acknowledgments

I am grateful to many people who have helped me during my PhD. First and foremost, I would like to thank my advisor Srini Devadas. I have enjoyed unlimited academic freedom at MIT thanks to Srini. I remember distinctively a meeting with him before my PhD. In that meeting, he said “work on something that interests you here; if you don’t, I will force you to.” His passion and approach to research and have had a great impact on me. I also very much appreciate his guidance during my academic job search and his advice on many other aspects of life. Next, I would like to thank Marten van Dijk, Elaine Shi, Dahlia Malkhi and Ittai Abraham. It was Ittai and Dahlia who led me into consensus research. A lot of work in this thesis started while I was an intern at VMware Research under their mentorship. Marten and Elaine have effectively served as my unofficial advisors and have been sources of inspiration on many research projects. This thesis is based on joint works with Ittai Abraham, Srinivas Devadas, Dahlia Malkhi, Kartik Nayak and Alexander Spiegelman. This thesis would not have been possible without their contributions. Many others have provided valuable insights and discussions. Vinod Vaikuntanathan, Bryan Ford, and Eleftherios Kokoris-Kogias helped clarify comparisons with their works and shared other inspiring ideas. Alin Tomescu pointed me to efficient libraries for pairing-based cryptography. Joël Alwen, Jeremiah Blocki, Henry Corrigan-Gibbs, Ilia Lebedev, Quanquan Liu, Krzysztof Pietrzak, Daniel Sanchez, Daniel Wichs, and Samson Zhou provided helpful feedback and discussions on various aspects of proof-of-space, bandwidth-hard functions, and graph pebbling. I also had the pleasure to work with many wonderful collaborators on topics outside this thesis: Christopher Fletcher, Xiangyao Yu, Albert Kwon, Emil Stefanov, Charles Herder, Meng-Day Yu, Daniel Wichs, Hubert Chan, Omer Khan, Benny Pinkas, and Hanshen Xiao. Especially to Chris, my closest collaborator, you wrote in your thesis acknowledgment that we would collaborate again in the future and now we are to become colleagues. It is great pleasure to work with David Wentzlaff’s group on a chip tape-out. Special thanks to Mike McKeown, who has spent a considerable amount of time helping us test the chip. I have been fortunate to teach 6.046 Design and Analysis of Algorithms with Erik Demaine, Srini Devadas, Nancy Lynch, Debayan Gutpa, Virginia Williams and other amazing staff members. I learned a lot from them missed those fun staff meetings. Thanks to Nancy Lynch for her trust. I am deeply grateful to my family and friends. The friends I met at MIT have brought so much fun and laughter to the PhD journey. Finally, as always, I am thankful to my parents for their continuous support.

5 6 Contents

1 Introduction 9 1.1 Overview of Contributions ...... 10

2 Background 13 2.1 Byzantine Broadcast and Byzantine Agreement ...... 13 2.2 Byzantine Fault Tolerant State Machine Replication ...... 15 2.3 Nakamoto Consensus ...... 17 2.4 Cryptographic Primitives ...... 19 2.4.1 Aggregate Signature ...... 19 2.4.2 Verifiable Random Function ...... 20

3 Solida: Permissionless Consensus from Reconfigurable Byzantine Consensus 21 3.1 Introduction ...... 21 3.1.1 Overview of the Protocol ...... 23 3.2 Model ...... 25 3.3 The Solida Protocol ...... 27 3.3.1 Structure of Views and Leaders ...... 28 3.3.2 Steady State ...... 29 3.3.3 View Change ...... 30 3.3.4 Reconfiguration ...... 32 3.3.5 Improvement with Aggregate Signatures ...... 33 3.3.6 Puzzles and Defense against Selfish Mining ...... 34 3.4 Proof of Safety and Liveness ...... 34 3.5 Implementation and Evaluation ...... 38 3.6 Related Work ...... 41

4 Efficient Synchronous Byzantine Consensus 43 4.1 Introduction ...... 43 4.2 A Synchronous Byzantine Synod Protocol ...... 45 4.2.1 Model and Overview ...... 45 4.2.2 Detailed Protocol ...... 46 4.2.3 Safety and Liveness ...... 50 4.3 Byzantine Broadcast and Agreement ...... 53 4.4 Byzantine Fault Tolerant State Machine Replication ...... 56 4.4.1 Warm-up: A Basic Protocol ...... 56

7 4.4.2 Towards Stable Leaders ...... 58 4.4.3 Common Case ...... 59 4.4.4 View Change ...... 61 4.4.5 Safety and Liveness ...... 63 4.4.6 Message Complexity ...... 64 4.4.7 Comparison with Prior Work ...... 65

5 Proof-of-Space from Stacked Expanders 67 5.1 Introduction ...... 67 5.2 Preliminaries ...... 69 5.2.1 Proof-of-Space ...... 69 5.2.2 Graph Labeling and Pebbling ...... 70 5.2.3 Bipartite and Stacked Expanders ...... 71 5.3 Pebble Games on Stacked Expanders ...... 73 5.3.1 Localization of Expanders ...... 74 5.4 Proof-of-Space from Stacked Expanders ...... 77

6 Bandwidth-Hard Functions 81 6.1 Introduction ...... 81 6.2 Bandwidth-Hard Functions: Definition and Limit ...... 84 6.2.1 Model ...... 84 6.2.2 Definition: Energy Fairness ...... 85 6.2.3 Red-Blue Pebble Games ...... 86 6.2.4 Limit of Energy Fairness ...... 87 6.3 Bandwidth-Hardness of Candidate Constructions ...... 89 6.3.1 Scrypt ...... 90 6.3.2 Bit-Reversal Graphs ...... 91 6.3.3 Stacked Expanders ...... 93 6.3.4 Stacked Butterfly Graphs Are Not Bandwidth-Hard ...... 95 6.3.5 Summary ...... 96 6.4 Related Work ...... 97

7 Conclusion 99

8 Chapter 1

Introduction

Consensus is a classic problem in distributed computing. Informally, the problem is to ensure that a set of parties agree on a common value despite some parties being faulty. The consensus problem has been studied under various combinations of models and assumptions on communication channels, timings, faults, etc.. This thesis considers consensus in the presence of Byzantine faults [126, 100], meaning that faulty parties may deviate from the protocol arbitrarily in an adversarial and coordinated manner. Studies on Byzantine consensus in academia have traditionally focused on the permissioned setting where participants are fixed and know each other a priori. Recently, the digital currency Bitcoin [114] explored and popularized a new setting of consensus. Bitcoin is a payment system that does not rely on a single authority (like a central bank) but instead runs on a decentralized peer-to-peer network. While consensus has no obvious connection to a centrally controlled fiat currency, it is at the heart of a decentralized digital currency. A key insight of Bitcoin is that, if all non-faulty parties in a peer-to-peer network reach consensus on every transaction (hence on every account’s balance), then we have obtained a payment system or a currency. Bitcoin achieves consensus in a permissionless setting. Participants may join or leave the Bitcoin protocol at will and need not know how many other participants exist or who they are. There is supposed to be no identity verification or barrier to entry. Because there is no identity verification, permissionless consensus faces a threat called the Sybil attack [58]: the attacker can easily create a large number of pseudonymous identities to participate in the protocol. Conventional permissioned consensus protocols usually rely on some form of majority

9 voting, so they will fall victim to the Sybil attack. A key component of Bitcoin is a defense to the Sybil attack: proof-of-work (PoW). A PoW is a short piece of data that requires a lot of computation (i.e., “work”) to produce, but can be efficiently verified [61]. At a high level, every participant in the Bitcoin network keeps performing computation to find PoWs and use these PoWs to vote on proposed transactions. The more votes a transaction accumulates, the harder for it to be reversed (either accidentally or by a deliberate attack). PoW defeats the Sybil attack because a participant’s voting power is now determined by its computational power rather than the number of identities in its control. The Bitcoin paper [114] explains that “proof-of-work is essentially one-CPU-one-vote.” Bitcoin’s consensus protocol is now referred to as the Nakamoto consensus protocol, named after the pseudonym of its inventor. Nakamoto consensus provides an elegant solution to permissionless Byzantine consensus and forms the foundations of a vast majority of digital currencies to date. But Nakamoto consensus also has severe drawbacks. A primary one is its long latency in confirming transactions. Confidence in a transaction builds up slowly and gradually, as it gathers moreand more votes. Under current parameters, it takes about 1 hour for a transaction to “go through”. In addition, the use of PoW raises concerns about fairness and energy consumption. In August 2018, it is estimated that the Bitcoin network consumes about 70TWh (trillion Watt-hour) of electricity per year [53], which is comparable to Austria, the 39th largest country by electricity consumption [147]. The fairness issue surfaced with the advent of Application Specific Integrated Circuit (ASIC) Bitcoin mining hardware. These specialized chips are orders of magnitude faster and more energy efficient at Bitcoin mining than commodity CPUs, thereby compromising Bitcoin’s egalitarian visions of “no-barrier-to-entry” and “one-CPU-one-vote”. This thesis presents distributed algorithms and cryptographic primitives to address the above problems. Although I will discuss these techniques in the context of permissionless consensus, they also have applications in permissioned consensus and outside the consensus problem.

1.1 Overview of Contributions

Solida: permissionless consensus from reconfigurable Byzantine consensus. In contrast to Bitcoin’s long latency in confirming transactions, conventional permissioned Byzantine consensus protocols have much lower latency. Thus, researchers envisioned using Nakamoto consensus to elect a rolling committee and running a permissioned Byzantine consensus protocol among committee

10 members to approve transactions quickly [51, 92, 121]. Chapter 3 presents Solida, a protocol inspired by the above framework. Unlike prior committee-based solutions, Solida uses permissioned Byzantine consensus not just for transaction processing, but also for committee member election, thus eliminating the need for Nakamoto consensus. Crucially, PoW still plays a central role in Solida, but is used as a Sybil-proof leader election oracle instead.

Which permissioned Byzantine consensus protocol should we use in Solida? Following most prior work, a natural choice would be the Practical Byzantine Fault Tolerance (PBFT) protocol [42]. But a disadvantage of PBFT is that it only tolerates 33% Byzantine participants, while Nakamoto consensus tolerates up to 49%. Can we get the best of both worlds, i.e., design an efficient permissionless consensus protocol that can commit transactions with low latency and tolerate 49% Byzantine participants? To this end, we need the underlying permissioned protocol to tolerate 49% Byzantine faults.

Efficient synchronous Byzantine consensus. It is well known that 49% Byzantine fault toler- ance is only possible in the authenticated (i.e., using digital signatures) and synchronous setting. Lacking either condition, 33% fault tolerance is the best we can hope for [100, 60]. Somewhat surprisingly, no practical protocol seems to exist in the synchronous and authenticated setting. The best protocol to date requires 24 rounds of communication in expectation [89]. Chapter 4 presents more efficient Byzantine consensus protocols in the above setting.

ASIC resistance and proof-of-space. In response to the growing gap in mining powers between CPUs and ASICs, memory-hard functions have been suggested for ASIC resistance. While prior work focused on the size of memory, I argue that the more relevant metric for ASIC resistance should be memory bandwidth. Chapter 6 proposes the notion and model of bandwidth-hard functions and shows bandwidth-hardness (or lack thereof) for popular constructions. Another promising alternative is Proof-of-space (PoSpace) [63], which attempts to address both the fairness and energy issues. Essentially, PoW defeats the Sybil attack by requiring proof of expenditure of physical resources. The physical resource does not have to be computation. In PoSpace, the physical resource is storage space (e.g., hard drives). The first PoSpace construction [63], however, is impractical. Chapter 5 gives a simpler and more efficient PoSpace scheme with tighter security bounds.

11 12 Chapter 2

Background

There exist a few variant formulations of the Byzantine consensus problem. In this thesis, I use the word “consensus” as a collective term for all those variants; other papers have different conventions.

2.1 Byzantine Broadcast and Byzantine Agreement

Two theoretical formulations are Byzantine broadcast and Byzantine agreement, introduced by Lamport, Shostak and Pease [100, 126]. In Byzantine broadcast, there is a designated sender who tries to broadcast a value to 푛 parties. Up to 푓 of the 푛 parties, including the sender, can have Byzantine faults and deviate from the protocol arbitrarily. Non-faulty parties are also said to be honest. As expected, a solution to the Byzantine broadcast problem needs to ensure that all honest parties eventually commit on the same value. However, the above requirements alone would allow a trivial solution, that is, all honest parties always commit on a default value (e.g., 0) regardless of what the sender tries to broadcast. A validity requirement is introduced to rule out this trivial solution. More formally, the Byzantine broadcast problem is defined as follows.

Definition 2.1 (Byzantine broadcast). A sender tries to broadcast a value to 푛 parties, up to 푓 of which can have Byzantine faults. A solution needs to satisfy the following requirements:

(termination) all honest parties eventually commit,

(agreement) all honest parties commit on the same value, and

(validity) if the sender is honest, then all honest parties commit on the value it broadcasts.

13 The Byzantine agreement variant similarly considers 푛 parties, up to 푓 of which can have Byzantine faults. There is no designated sender in this variant; instead, every party holds an initial input value. A solution to the Byzantine agreement problem needs to satisfy the same termination and agreement requirements as in Byzantine broadcast. A number of validity requirements have been suggested to rule out trivial solutions. A commonly adopted one is strong unanimity [60].

Definition 2.2 (Byzantine agreement). There are 푛 parties each with an input value. Up to 푓 of them can have Byzantine faults. A solution needs to satisfy the following requirements:

(termination) all honest parties eventually commit,

(agreement) all honest parties commit on the same value, and

(validity) if all honest parties hold the same input value 푣, then they all commit on 푣.

Lamport, Shostak and Pease presented protocols and fault tolerance bounds in synchronous settings [100, 126]. In synchronous settings, participants of the protocol proceed in synchronized rounds and it is guaranteed that a message sent at the beginning of a round will be received by the end of that round. Without cryptographic assumptions (the unauthenticated setting), Byzantine broadcast and agreement can be solved if and only if 푓 < 푛/3. Assuming digital signatures (the authenticated setting), Byzantine broadcast can be solved if 푓 < 푛 and Byzantine agreement can be solved if and only if 푓 < 푛/2. They also showed the following reduction from Byzantine agreement to Byzantine broadcast in synchronous settings. To solve Byzantine agreement, let each party initiate a Byzantine broadcast in parallel to broadcast its value. After the broadcast, all honest parties will share the same vector of values 푉 = {푣1, 푣2, ··· , 푣푛}. Each party can then just output the most frequent value in the vector 푉 . Agreement is reached since all honest parties share the same vector 푉 . If 푓 < 푛/2 and all honest parties start with the same input value, then that value will be the most frequent in 푉 , achieving validity. The initial protocols had exponential message complexities [126, 100]. Fully polynomial protocols were later shown for both the authenticated (푓 < 푛/2)[57] and the unauthenticated (푓 < 푛/3)[76] settings. Both protocols require 푓 + 1 rounds of communication, which matches the lower bound on round complexity for deterministic protocols [69]. To circumvent the 푓 + 1 round lower bound, a line of work explored the use of randomization [133, 23] which eventually led to expected constant-round

14 protocols [68, 89]. In the asynchronous setting, the FLP impossibility [70] rules out any deterministic solution. Randomization [23, 133, 36] and partial synchrony [56, 60] have been introduced to circumvent the impossibility.

2.2 Byzantine Fault Tolerant State Machine Replication

The Byzantine broadcast/agreement formulations and their solutions typically aim to study theoretical limits. In fact, their problem definitions are often inconvenient to work with in practice. First, they only consider one consensus instance (i.e., consensus on a single value), whereas a practical application typically requires consensus on an ever-growing sequence of values. Second, the “parties” participating in the consensus protocol are typically passive witnesses or validators in practice, and are not the entities that generate or suggest what values should be committed. A more practical formulation of consensus is state machine replication [98, 137], and it fixes the above issues. The state machine replication formulation considers consensus on an ever-growing sequence of values. It also distinguishes clients, who produce values, and servers, who commit those values. Clients submit requests to a service consisting of replicated servers, also called replicas. The service should provide safety and liveness even when some replicas are faulty. Safety means the service behaves like a single non-faulty server, which requires honest replicas to agree on a sequence of values and their order. Liveness means the service keeps processing new client requests and eventually commits every request. State machine replication protocol are not concerned with the validity of client requests, but rather leave them to higher-level protocols or applications. The core of state machine replication is to reach agreement on a totally-ordered sequence of values. This part is also commonly referred to as atomic broadcast in the literature [49, 44, 134, 78, 52, 47], in which case state machine replication would refer to the approach of replicating a service using totally- ordered consensus values. I will not make this distinction and will use the two terms interchangeably in this thesis. This thesis focuses on Byzantine Fault Tolerant (BFT) state machine replication. While BFT state machine replication and Byzantine broadcast look similar at first glance, a crucial distinction leads to their different fault tolerance bounds. BFT state machine replication requires anhonest majority (i.e., 푛 ≥ 2푓 + 1) even in the synchronous and authenticated setting [137], whereas Byzantine broadcast which can be solved even for 푛 = 푓 + 2. The key difference is that honest

15 parties in Byzantine broadcast just need to stay in agreement with each other, while replicas in state machine replication additionally have to convince external entities (i.e., clients) of the correct system states. This distinction between BFT state machine replication and Byzantine broadcast becomes unimportant in the asynchronous setting where both problems require 푛 ≥ 3푓 + 1. The most well-known state machine replication protocol that tolerates Byzantine faults is perhaps the Practical Byzantine Fault Tolerance (PBFT) protocol by Castro and Liskov [42]. PBFT tolerates 푓 Byzantine faults using 푛 ≥ 3푓 + 1 replicas. It preserves safety under asynchrony and provides liveness under partial synchrony. As the first BFT protocol designed for practical efficiency, PBFT has since inspired numerous follow-up works including some practical systems [136, 4, 96, 151, 116, 150, 95, 2, 48, 109, 94]. We now give a quick overview of the PBFT protocol. For simplicity, our description below assumes 푛 = 3푓 + 1. One replica serves as a stable leader during normal operations (also called common case). We say the protocol operates in this leader’s view. Consensus decisions form a totally-order sequence. We say each decision occupies a slot. Views and slots are both numbered with consecutive integers. In the common case, for each slot, the leader makes a proposal and replicas vote on the proposal in two steps to commit it. Replicas use time-outs to monitor the leader. If a leader stops making progress for too long, replicas endorse the next leader in a round robin order. The newly elected leader initiates a view-change procedure to replace the previous (faulty) leader and start a new view. PBFT uses message authentication codes (MAC) in the common case and digital signatures during view changes [41]. For simplicity, we will describe PBFT without its MAC optimization, i.e., we will use digital signatures even under a stable leader. Adopting the notation from PBFT, we use

⟨푥⟩푖 to denote a message 푥 signed by replica 푖, i.e., ⟨푥⟩푖 = (푥, 휎) where 휎 is a signature of message 푥 produced by replica 푖 using its private signing key. For better efficiency, it is customary to sign the hash digest of a message. A message can be signed by multiple replicas (or the same replica) in layers, i.e., ⟨⟨푥⟩푖⟩푗 = ⟨푥, 휎푖⟩푗 = (푥, 휎푖, 휎푗) where 휎푖 is a signature of 푥 and 휎푗 is a signature of 푥 || 휎푖 (|| denotes concatenation). When the context is clear, we omit the signer and simply write ⟨푥⟩ or ⟨⟨푥⟩⟩. The common case consists of three phases for each slot. When we say a replica broadcasts a message, we mean it sends the message to all 푛 replicas including itself.

16 ∙ (Propose) The leader 퐿 picks a client request 푟푒푞 that has not been processed. 퐿 broadcasts

푟푒푞 and ⟨propose, 푣, 푠, ℎ⟩퐿 where 푣 is the current view number, 푠 is the slot number and ℎ is the hash digest of 푟푒푞. (This message is named “pre-prepare” in PBFT.)

After receiving 푟푒푞 and ⟨propose, 푣, 푠, ℎ⟩퐿, a replica 푖 checks

– ℎ is a digest of 푟푒푞 and the signature is valid,

– it is in view 푣,

– 퐿 has not sent a different proposal for slot 푠 in view 푣,

∙ (Prepare) If all the above checks pass, replica 푖 broadcasts ⟨prepare, 푣, 푠, ℎ⟩푖.

After receiving 2푓 + 1 matching prepare messages, a replica accepts the proposal (represented by its digest ℎ). (PBFT says the value becomes prepared at replica 푖 at this point.)

∙ (Commit) Upon accepting ℎ, a replica 푖 broadcasts ⟨commit, 푣, 푠, ℎ⟩푖.

After receiving 2푓 + 1 matching commit messages, a replica commits 푟푒푞 into slot 푠.

We will not cover the exact details of PBFT’s view-change procedure because later chapters will simplify it through non-pipelined execution and/or synchrony. At a high level, when a replica detects lack of progress in the current view, it sends a view-change request to the next leader in a round robin order. A view-change request from replica 푖 also reports the current status from replica 푖’s perspective to the new leader. When the new leader gathers 2푓 + 1 view-change requests, it learns the status from 2푓 + 1 members and may have to redo consensus for previous slots before continuing on to future empty slots. For more details, refer to the original PBFT papers [42, 41, 43].

2.3 Nakamoto Consensus

The Nakamoto consensus protocol produces a totally-ordered sequence of consensus decisions that are publicly verifiable. Thus, it can be seen as a BFT state machine replication (or atomic broadcast) protocol in the permissionless setting. The Nakamoto consensus protocol builds on two key ideas. One is the aforementioned proof- of-work (PoW). Finding a PoW involves solving a computational puzzle. The process of solving these puzzles is called mining and a participant that engages in mining is called a miner. Bitcoin’s

17 puzzles are based on a cryptographic hash function like SHA-256, modeled as a random oracle ℋ [22]. Solutions to a puzzle are in the form of (pk, nonce). pk is a miner’s public key. A miner keeps trying different values of nonce until it finds a valid solution such that ℋ(puzzle, pk, nonce) is smaller than some threshold. The threshold is also called the difficulty and is periodically adjusted so that the expected time for the entire network to produce a puzzle solution is kept stable at 퐷. The other key idea is the “longest chain” rule. Nakamoto consensus builds a totally-ordered chain of PoWs. Each PoW binds to the predecessor PoW in the chain as well as a block (of transactions) through a cryptographic hash function like SHA-256. Every participant treats the longest chain of PoWs1 as consensus outcomes: the corresponding blocks are consensus decisions, totally-ordered according to the PoW chain. Furthermore, participants actively contribute to the longest PoW chain by trying to extend it with new PoWs. Each participant picks the longest PoW chain he/she is aware of and constructs a new block of transactions. He/she then tries to find a new PoW that binds to the last PoW in the chain and a hash digest of the new block. It is possible that two valid PoWs are found at approximately the same time, causing participants to temporarily disagree on the longest chain as there are now two forks with equal length. But due to the random nature of PoW, one fork will most likely be extended earlier than the other so that a unique longest chain re-emerges. It is possible that the two forks are extended at about the same time once again, but such a coincidence is unlikely to happen many times in a row. Thus, each PoW serves as a “confirmation” to all its predecessor PoWs and their corresponding blocks. Once ablock has sufficiently many confirmations, it is unlikely to be reversed by accident. It would alsobehard to revert the block through a deliberate attack unless the attacker possesses more computational power than the rest of the network combined. It is usually recommended that a payee waits for six confirmations before considering a transaction to have “gone through”. The entire Bitcoin network is parameterized to produce one PoW (confirmation) every 퐷 = 10 minutes in expectation. This translates to the 1-hour latency mentioned in Chapter 1.

A note on terminology. We have explained that Bitcoin at its core is a permissionless consensus protocol, and to be more precise, a permissionless BFT state machine replication (or atomic broadcast) protocol. Bitcoin has been given other names such as a decentralized cryptocurrency and a public ledger. An even more popular name is perhaps a “blockchain”, which likely arises from the observation

1To be accurate, it should be the chain that represents the greatest amount of work.

18 that blocks in Bitcoin form a chain. It has since been used to mean “an immutable data structure”, with “public blockchain” and “private blockchain” referring to the permissionless and permissioned settings, respectively. I will avoid using the term “blockchain” in this thesis because it fails to capture the key ideas of Bitcoin. The Bitcoin paper [114] did not coin this term and stated repeatedly that its key mechanism is the longest proof-of-work chain. The term “blockchain” mixes Bitcoin’s abstraction, a totally-ordered block sequence, with its inner-working, a PoW chain, and describes neither accurately. This can cause confusion. For example, PBFT is a permissioned state machine replication protocol and should qualify as a “private blockchain”, but it does not build any chain. Worse yet, the term “blockchain” may mislead protocol designers to chain blocks using hashes (as opposed to PoWs). This can give a false sense of security as a hash chain can be easily forged and has little contribution to consensus or immutability.

2.4 Cryptographic Primitives

2.4.1 Aggregate Signature

In PBFT and many other Byzantine consensus protocols, some messages are Θ(푛) in size as they contain 푛 − 푓 matching signatures from distinct replicas. Aggregate signatures give a method to combine many signatures into a single one. We review Boneh-Lynn-Shacham (BLS) aggregate signatures [35, 34].

Let 퐺1, 퐺2 and 퐺푡 be cyclic groups of the same order. A bilinear map is a function 푒 : 퐺1 ×퐺2 →

퐺푡 such that ∀푢 ∈ 퐺1, 푣 ∈ 퐺2, 푎, 푏 ∈ Z,

푒(푢푎, 푣푏) = 푒(푢, 푣)푎푏.

The BLS signature requires an efficiently computable, non-degenerate bilinear map of prime order. Some elliptic curves are specifically designed to support efficient bilinear map (pairing) operations18 [ ]. 푥 In BLS, a secret signing key is a random integer 푥, and the public verification key is 푦 = 푔 ∈ 퐺2 where 푔 is a generator of 퐺2. Let ℋ(·) be a hash function that maps a message 푚 to an element in 퐺1. The signature for a message 푚 is 휎 = ℋ(푚)푥. To verify a signature 휎, check if 푒(휎, 푔) = 푒(ℋ(푚), 푦).

19 We now turn to BLS aggregate signatures. Let (푥푖, 푦푖) be the secret/public key pair of signer 푖. 푥 Suppose signer 푖 signs 푚푖, i.e., 휎푖 = ℋ(푚푖) 푖 . The aggregate signature is simply 휎 = Π푖휎푖. To verify the aggregate signature, check if 푒(휎, 푔) = Π푖푒(ℋ(푚푖), 푦푖).

In the special case where all the messages 푚푖 are identical, the signature 휎 is called a multisigna- ture [85, 117]. A multisignature can be verified using a single pairing operations: first aggregate the verification key into 푦 = Π푖푦푖 and then check if 푒(휎, 푔) = 푒(ℋ(푚), 푦). It is worth noting that there exist more efficient multisignature schemes21 [ ] based on the Schnorr signature [138], and they have been adopted in prior work [92]. However, Schnorr-based multisignature schemes may allow Byzantine signer to cause significant slowdowns. A Schnorr multisignature is interactive, i.e., it requires a “commitment” step before the actual signing step. A Byzantine signer may participate in the commitment step but later refuse to sign in the signing step. The leader then has to initiate a new instance of Schnorr multisignature up to 푓 = 푂(푛) times. Similarly, a malicious leader can also use it as an excuse to abort up to 푓 times without being accused of stalling. The BLS multisignature and aggregate signature schemes are non-interactive and are thus Byzantine fault tolerant. Another related notion is a threshold signature, which verifies if any 푡 out of 푛 signers participate in the signing process. A multisignature can thus be seen as an 푛-out-of-푛 threshold signature. Non-interactive threshold signatures have been used in Byzantine consensus protocols [39, 40, 113].

2.4.2 Verifiable Random Function

A verifiable random function (VRF) 퐹 is a pseudorandom function that provides a proof of its correct computation [112]. Given a secret key 푠푘, one can evaluate 퐹 on any input 푥 and obtain a pseudorandom output 푦 = 퐹푠푘(푥) together with a proof 휋. From 휋 and the corresponding public key

푝푘, anyone can verify that 푦 is correctly computed from 푥 and 푠푘, in which case Ver푝푘(푥, 푦, 휋) = 1.

Additionally, a VRF needs to satisfy uniqueness: there do not exist 푥, 푦1, 푦2, 휋1, 휋2 such that 푦1 ̸= 푦2 but Ver푝푘(푥, 푦2, 휋1) = Ver푝푘(푥, 푦2, 휋2) = 1. Hence, a VRF is also called a unique signature. Efficient constructions have been described [55, 74].

20 Chapter 3

Solida: Permissionless Consensus from Reconfigurable Byzantine Consensus

This chapter presents Solida, a permissionless consensus protocol based on reconfigurable Byzantine consensus augmented by proof-of-work (PoW). Solida provides safety and liveness assuming the adversary controls less than (roughly) one-third of the network’s total mining power. The main goal of Solida is to improve on Nakamoto consensus in transaction confirmation latency, while a side benefit is to provide a simple defense to selfish mining [67].

3.1 Introduction

A number of attempts were made to improve the throughput and latency of Nakamoto consensus. These fall into two broad categories. One category [143, 102, 66, 142] tries to improve Nakamoto consensus. The other category [51, 92, 121] hopes to replace Nakamoto consensus with classic permissioned Byzantine consensus. This second category has potential for significant performance improvements over Nakamoto consensus, especially in transaction latency, since decisions in permis- sioned Byzantine consensus are final once committed. Most of these proposals envision a rolling committee that approves transactions efficiently using a conventional Byzantine consensus protocol such as PBFT [42]. A central challenge of this framework is to reconcile the permissioned nature of traditional Byzantine consensus protocols and the permissionless requirement of decentralized cryptocurrencies. Permissioned protocols like PBFT assume a static group of committee members,

21 but to be permissionless and decentralized, committee members must change over time — a step commonly referred to as reconfiguration. In this chapter, we present Solida1, a permissionless consensus protocol based on permissioned reconfigurable Byzantine consensus. We were indeed inspired by the aforementioned works; yet, Solida is conceptually very different as it does not rely on Nakamoto consensus for any partofthe protocol. The hybrid consensus protocol by Pass and Shi [121] suggests using a Nakamoto PoW chain to determine the identities of committee members, which then approve transactions using PBFT. However, while the length of a Nakamoto chain gives a suggestion on when reconfiguration should happen, it does not dictate when reconfiguration actually happens. In Solida, committee election and transaction processing are both done through permissioned Byzantine consensus. We follow the standard reconfiguration technique in the literature [99, 106, 87, 104, 118, 146, 26], that is, to drive a consensus decision on the new configuration as well as the closing state, the latter of which implicitly dictates the time of reconfiguration. We remark that PoW still plays a central role in Solida, but use of PoW does not equate to Nakamoto consensus. The heart of Nakamoto consensus is the idea that “the longest PoW chain wins”. This creates the possibility of temporary “chain forks” and also results in long latency as transactions have to be “buried” sufficiently deep in the PoW chain. Looking from a different angle, we can think of PoW as a leader election oracle that is Sybil-proof in the permissionless setting. But this oracle is imperfect as leader contention can occur when multiple miners find PoWs around the same time. Nakamoto consensus can be thought of as a way to resolve leader contention in which miners “vote on” contending leaders using their mining power. A leader (or its block) “wins” the contest gradually and probabilistically, until an overwhelming majority of miners “adopt” it by mining on top of it. In Solida, PoW again serves as an imperfect Sybil-proof leader election oracle. But instead of using the probabilistic Nakamoto consensus, Solida uses traditional Byzantine consensus to resolve leader contention with certainty. Not relying on Nakamoto consensus gives a few additional advantages. First, defending selfish mining [67, 115] is much easier with the help of a committee (cf. Section 3.3.4). In contrast, defending selfish mining in Nakamoto’s framework requires the fairly complex FruitChain protocol122 [ ]. Second, it significantly simplifies analysis. Although Nakamoto consensus is simple and elegant, itsformal

1Solidus was a gold coin used in the Byzantine Empire. Solida is our way of (mis-)spelling Solidus.

22 modeling and analysis turn out to be highly complex [75, 120]. FruitChain and the interaction between Nakamoto and permissioned consensus further complicate the analysis [121]. We remark that an earlier version of the manuscript additionally aimed at making the protocol incentive compatible. Rigorous analysis on incentives turn out to be difficult and this thesis does not attempt it. We present and analyze Solida without incentives as an important first step. The rest of the chapter is organized as follows. Section 3.3 presents full details of the Solida protocol, and in particular, the reconfiguration step. Reconfiguration is perhaps the step that deserves the most detailed treatment since the protocol between two reconfiguration events is just conventional Byzantine consensus. Section 3.4 shows that Solida achieves safety and liveness if the adversary’s ratio of mining power does not exceed (roughly) 1/3. Section 3.5 presents implementation details and experimental results on performance. With a 0.1s network latency and 75 Mbps network bandwidth, Solida with committees of 1000 members can commit a consensus decision in 23.6 seconds.

3.1.1 Overview of the Protocol

At a high level, Solida runs a Byzantine consensus protocol among a set of participants, called a committee, that dynamically changes over time. We denote the 푖-th member in chronological order as 푀푖. The committee size is 푛 = 3푓 + 1 where 푓 is the maximum number of Byzantine faults allowed on any given committee. The 푖-th committee 퐶푖 consists of (푀푖, 푀푖+1, 푀푖+2, ··· , 푀푖+푛−1).

The first committee 퐶1 is known as the Genesis committee, and its 푛 members are hard coded. After that, each new member is elected to the committee one at a time by the acting committee. Besides electing new members, the acting committee is also responsble for approving transactisons using Byzantine consensus. This chapter will use a modified version of PBFT, but we can plug in other Byzantine consensus protocols like the one in Chapter 4. Consensus decisions will form a totally-ordered sequence, also known as a ledger. We say each consensus decision fills a slot in the ledger. A consensus decision can be either (1) a batch of transactions or (2) a reconfiguration event. The first type of decision is analogous to a block in Bitcoin. The second type records membership changes to the committee. At any time, one committee member serves as the leader. The leader proposes a batch of transactions into the next empty slot in the ledger. Other members validate proposed transactions

23 (no double spending, etc.) and commit them in two phases. A Byzantine leader cannot violate safety but may prevent progress. If members detect lack of progress, they elect the next member in the round robin order as the new leader, similar to PBFT view changes. The more interesting part of the protocol is reconfiguration. To be elected onto the committee, a miner needs to present a PoW, i.e., a solution to a moderately hard computational puzzle. Upon seeing this PoW, the current committee tries to reach a special reconfiguration consensus decision (the second type of consensus decision as mentioned earlier), which commits (1) the identity of the new member, i.e., a public key associated with the PoW, and (2) the closing state before the reconfiguration. Once this reconfiguration consensus decision is committed, the system transitions into the new configuration 퐶푖+1. Starting from the next slot, the PoW finder becomes the newest committee member 푀푖+푛, and the oldest committee member 푀푖 loses its committee membership (hence the committee size stays constant). Here, a crucial design choice is: who should be the leader that drives reconfiguration? The first idea that comes to mind is to keep relying on the round robin leaders. But this approach presents a challenge to the analysis. The current leader may be Byzantine and refuse to reconfigure when it should. By doing so, it tries to buy time for Byzantine miners to find competing PoWs so that it can nominate a Byzantine new member instead. Although we can conceive mechanisms to replace this leader, subsequent leaders may also be Byzantine. The probability of taking in an honest new member now depends on the pattern of consecutive Byzantine leaders on the current committee. This means we will not be able to apply the Chernoff inequality to bound the number of Byzantine members on a committee. It is unclear whether this is merely an analysis hurdle or the adversary really has some way to increase its representation on the committee gradually and eventually exceed 33% of the committee. Therefore, we will switch to external leaders for reconfiguration. In particular, the successful miner would act as the leader 퐿 for reconfiguration and try to elect itself onto the committee. When 퐿’s reconfiguration proposal is committed (becomes a consensus decision), reconfiguration is finished, and the system starts processing transactions under the new committee with 퐿 being the leader. Note that at this point 퐿 becomes a committee member, so the system has seamlessly transitioned back to internal leaders.

24 By giving all external miners opportunities to become leaders, we introduce a new leader contention problem. It is possible that before 퐿 can finish reconfiguration, another miner 퐿′ also finds a PoW. Moreover, there may be concurrent internal leaders who are still trying topropose transactions. Solida resolves this type of contention through a Paxos-style leader election [99] with ranks. Only a higher ranked leader can interrupt a lower ranked one. To ensure safety, the higher ranked leader may have to honor the proposals from lower ranked leaders by re-proposing them. Now the key challenge is to figure out how leaders (internal or external) should be ranked. One idea is to rank external leaders by the output hash of their PoW and stipulate that external leaders are higher ranked than all internal leaders in that configuration. This approach, however, allows the adversary to prevent progress once in a while. If a Byzantine miner submits a “highly ranked” PoW but does not drive reconfiguration, the system temporarily stalls until some honest miner findsan even higher ranked PoW. No transactions can be approved in the meantime because internal leaders are all lower ranked than the Byzantine PoW finder. Our solution to this problem is to “expire” stalling external leaders, and give the leader role back to current committee members so that the committee can resume processing transactions under internal leaders until the next external leader emerges. Crucially, during this process, we must enforce a total order among all leaders, internal or external, to ensure safety. The details are presented in Section 3.3.

3.2 Model

Network and participants. We consider a permissionless setting in which participants use their public keys as pseudonyms and can join or leave the system at will. Participants are connected to each other via a peer-to-peer network with a small diameter, e.g., logarithmic in the number of total participants and < 10 in practice. Participants are either honest or Byzantine. Honest participants always follow the prescribed protocol and are capable of delivering a message to other honest participants within ∆ time. Byzantine participants are controlled by a single adversary and can thus coordinate their actions. At any time, Byzantine participants collectively control no more than 휌 fraction of the total computation power. The 푛 members in the Genesis committee 퐶1 are known to all participants, and that the number of Byzantine participants on 퐶1 is less than 푛/3. When we say a member “broadcasts” a message, we mean the member sends the message to all

25 current committee members including itself, but not to all participants in the network. We assume digital signatures and use ⟨·⟩ to denote signed messages; refer to Section 2.2 for details.

Delayed adaptive adversary. We assume it takes time for the adversary to corrupt an honest participant. It captures the idea that it takes time to bribe a miner or infect a clean host. Most committee-based designs [51, 92, 121] require this assumption. Otherwise, an adversary can easily violate safety by corrupting the entire committee, which may be small compared to the whole miner population. This is formalized as a delayed adaptive adversary by Pass and Shi [121]. Specifically, we assume that even if the adversary starts corrupting a member as soon as it emerges with a PoW, by the time of corruption, the member would have already left the committee. Whether this assumption holds in practice remains to be examined. Algorand [111] introduces techniques to hide the identities of the committee members, and can thus tolerate instant corruption. Its core technique, however, seems to be tied to the less estalished proof-of-stake.

Bounded message delay. We adopt the network model of Pass et al. [120]: a bounded message delay of ∆ that is known apriori to all participants. Whenever an honest participant sends a message to another honest participant, the message is guaranteed to reach the recipient within ∆ time. For convenience, we define ∆ to be the end-to-end message delay bound. If there are multiple hops from the sender to the recipient, ∆ is the time upper bound for traveling all those hops. Note that this is the standard synchronous network model in distributed computing, though Pass et al. [120] call it “asynchronous”. What they really meant was that Bitcoin does not behave like a conventional synchronous protocol. In a conventional synchronous protocol, participants move forward in synchronized rounds of duration ∆. Bitcoin does nothing of this sort and has no clear notion of rounds. Our adoption of a synchronous network model may raise a few immediate questions, which we discuss below.

Is the bounded message delay assumption realistic for the Internet? How realistic this assumption is depends a lot on the parameter ∆. With a conservative estimate, say ∆ = 5 seconds, and Byzantine fault tolerance, the assumption may be believable. Participants experiencing slow networks and unable to deliver messages within ∆ are considered Byzantine. So the assumption we

26 require in Solida is that adversarial participants and “slow” participants collectively control no more than (roughly) 1/3 of the mining power. More importantly, the bounded message delay assumption seems necessary for all PoW-based protocols. Otherwise, imagine that whenever an honest member finds a PoW, its messages are arbitrarily delayed due to asynchrony. Then, it is as if the adversary controls 100% of the mining power. In this case, the adversary can create forks of arbitrary lengths in Bitcoin or completely take over the committee in Solida and other committee-based protocols [51, 92, 121]. Pass et al. formalized the above intuition and showed that Bitcoin’s security fundamentally relies on the bounded message delay [120]. The larger ∆ is, the smaller percentage of Byzantine participants Bitcoin can tolerate; if ∆ is unbounded (an asynchronous network), then even an adversary with minuscule mining power can break Bitcoin.

Why do we use PBFT if the network is synchronous? It is well known that there exist Byzantine consensus protocols that tolerate 푓 < 푛/2 Byzantine faults in a synchronous network [57, 89]. By requiring 푓 < 푛/3, PBFT preserves safety under asynchrony. But this seems unnecessary given that we assume synchrony. The argument for using PBFT (with modifications) is that it runs at the actual speed of the network. Most protocols that tolerate 푓 < 푛/2 are synchronous and must advance in rounds of predefined duration ∆. If the actual latency of the network is better than ∆ — either because the ∆ estimate is too pessimistic, the network is faster in the common case, or the network speed has improved as technology advances — PBFT would offer better performance than a synchronous one. In other words, in this chapter, we opt to use an asynchronous protocol in a synchronous network, essentially giving up the strength of synchrony in favor of better performance in the optimistic case. But like all PoW-based consensus protocols, we rely on synchrony for safety in the worst case. Chapter 4 will explore the other design choice, that is, to provide stronger fault tolerance at the cost of running at a prescribed speed.

3.3 The Solida Protocol

Solida has a rolling committee running a Byzantine consensus protocol to commit (batches of) transactions and reconfiguration events into a ledger. We say each committed decision fillsa slot in

27 a linearizable ledger. The protocol should guarantee all honest members commit the same value for each slot (safety) and keeps moving to future slots (liveness). We first describe the protocol outside reconfiguration, i.e., when no miner has found a PoW for the current puzzle. This partfurther consists of two sub-protocols: steady state under a stable leader (Section 3.3.2), and a view-change procedure to replace the leader (Section 3.3.3). Members monitor the current leader, and if the leader does not make progress after some time, members support the next leader. This part of the protocol is very similar to PBFT [42] except that the views in our protocol will have more structures to support external leaders for reconfiguration (Section 3.3.4).

3.3.1 Structure of Views and Leaders

Each configuration can have multiple lifespans, and each lifespan can have many views. Weuse consecutive integers to number configurations, lifespans within a configuration, and views withina lifespan. The lifespan number is the number of PoWs (honest) committee members have seen so far in the current configuration. Intuitively, when a new PoW is found, the lifespan of the previous PoW ends. As explained in Section 3.1.1, our protocol can switch back and forth between internal and external leaders and we must enforce a total order among all leaders. To this end, we will associate each leader with a configuration-lifespan-view tuple (푐, 푒, 푣), and rank leaders by 푐 first, and then 푒, and then 푣. Each (푐, 푒, 푣) tuple also defines a steady state, in which the leader ofthat view, denoted as 퐿(푐, 푒, 푣), proposes values for members to commit. The view tuple and the leader role are managed as follows.

∙ Upon learning that a reconfiguration event is committed into the ledger, a member 푀 increases its configuration number 푐 by 1, and resets 푒 and 푣 to 0. 퐿(푐, 0, 0) is the newly added member by the reconfiguration consensus decision.

∙ Upon receiving a new PoW for the current configuration, a member 푀 increases its lifespan number 푒 by 1, and resets 푣 to 0. 푀 now supports the new PoW finder as 퐿(푐, 푒, 0) (푒 ≥ 1).

∙ Upon detecting lack of progress from the current leader, a member 푀 increases its view number 푣 by 1. 퐿(푐, 푒, 푣) (푣 ≥ 1) is the 푙-th member on the current committee, by the order they join the committee, where 푙 = ℋ(푐, 푒) + 푣 mod 푛 and ℋ is a random oracle (hash function).

28 To summarize, the 0-th leader of a lifespan is the newly added member (for 푒 = 0) or the new PoW finder푒 ( ≥ 1). After that, leaders in that lifespan are selected in a round robin manner, with a pre-defined starting point. We chose a pseudorandom starting point using ℋ but other choices also work. Now let us consider whether honest members agree on the identity of the leader in each view. For a view (푐, 푒, 푣) with 푒 = 0 or 푣 ≥ 1, the leader identity is derived from a deterministic function on the tuple and the current committee member identities (i.e., previous reconfiguration decisions). As long as the protocol ensures safety so far, members agree on the identities of these leaders. For views of the form (푐, 푒, 0) with 푒 ≥ 1, members may not agree on the leader’s identity if they receive multiple PoWs out of order. This is not a problem for safety because it is similar to having an equivocating leader and a Byzantine consensus protocol can tolerate leader equivocation. However, contending leaders in a view may prevent progress. Luckily, members will detect lack of progress (time out) and move on to views (푐, 푒, 푣) with 푣 ≥ 1. Unique leaders in those views will ensure liveness. Crucially, our protocol forbids pipelining to simplify reconfiguration: a member 푀 sends messages for slot 푠 only if it has committed all slots up to 푠 − 1. In other words, a member is not allowed to work on multiple slots simultaneously. Let ℳ(푐, 푒, 푣, 푠) be the set of members currently in view (푐, 푒, 푣) working on slot 푠. Each honest member 푀 can only belong to one such set at any point in time. To the best of our knowledge, reconfiguration with pipelining has not been worked out inBFT protocols, and remains an interesting future direction. The main challenge is that, when a slot is being worked on, the exact configuration (i.e., identities of committee members) for that slot would not be known if previous slots have not been committed.

3.3.2 Steady State

∙ (Propose) The leader 퐿 picks a batch of valid transactions {tx} and then broadcasts {tx} and

⟨propose, 푐, 푒, 푣, 푠, ℎ⟩퐿 where ℎ is the hash digest of {tx}.

After receiving {tx} and ⟨propose, 푐, 푒, 푣, 푠, ℎ⟩퐿, a member 푀 ∈ ℳ(푐, 푒, 푣, 푠) checks

– 퐿 = 퐿(푐, 푒, 푣) and 퐿 has not sent a different proposal,

– 푠 is a fresh slot, i.e., no value could have been committed in slot 푠 (details in Section 3.3.4),

– {tx} is a set of valid transactions whose digest is ℎ.

29 ∙ (Prepare) If all the above checks pass, 푀 broadcasts ⟨prepare, 푐, 푒, 푣, 푠, ℎ⟩.

After receiving 2푓 + 1 matching prepare messages, a member 푀 ∈ ℳ(푐, 푒, 푣, 푠) accepts the proposal (represented by its digest ℎ), and concatenates the 2푓 + 1 matching prepare messages into an accept certificate 풜.

∙ (Commit) Upon accepting ℎ, 푀 broadcasts ⟨commit, 푐, 푒, 푣, 푠, ℎ⟩.

After receiving 2푓 + 1 matching commit messages, a member 푀 ∈ ℳ(푐, 푒, 푣, 푠) commits {tx} into slot 푠, and concatenates the 2푓 + 1 matching commit messages into a commit certificate 풞.

The above is standard PBFT. We now add an extra propagation step to the steady state.

∙ (Notify) Upon committing ℎ, 푀 sends ⟨⟨notify, 푐, 푒, 푣, 푠, ℎ⟩ , 풞⟩푀 to all other members to notify them about the decision. 푀 also starts propagating this decision on the peer-to-peer network to miners, users, merchants, etc.. 푀 then moves to slot 푠 + 1.

Upon receiving a notify message like the above, a member commits ℎ, sends and propagates its own notify message if it has not already done so, and then moves to slot 푠 + 1.

3.3.3 View Change

A Byzantine leader cannot violate safety, but it can prevent progress by simply not proposing. Thus, in PBFT, every honest member 푀 monitors the current leader, and if no new slot is committed after some time, 푀 abandons the current leader and supports the next leader. Since we have assumed a worst-case message delay of ∆, it is natural to set a timeout based on ∆. The concrete timeout values (4∆ and 8∆) will be justified in the proof of Theorem 3.2.

∙ (View-change) Whenever a member 푀 moves to a new slot 푠 in a steady state, it starts a timer 푇 . If 푇 reaches 4∆ and 푀 still has not committed slot 푠, then 푀 abandons the current leader and broadcasts ⟨view-change, 푐, 푒, 푣⟩.

Upon receiving 2푓 + 1 matching view-change messages for (푐, 푒, 푣), if a member 푀 is not in a view higher than (푐, 푒, 푣), it forwards the 2푓 + 1 view-change messages to the new leader 퐿′ = 퐿(푐, 푒, 푣 + 1). After that, if 푀 does not receive a new-view message from 퐿′ within 2∆, then 푀 abandons 퐿′ and broadcasts ⟨view-change, 푐, 푒, 푣 + 1⟩.

30 ∙ (New-view) Upon receiving 2푓 + 1 matching view-change messages for (푐, 푒, 푣), the new leader 퐿′ = 퐿(푐, 푒, 푣 + 1) concatenates them into a view-change certificate 풱, broadcasts

⟨new-view, 푐, 푒, 푣 + 1, 풱⟩퐿′ , and enters view (푐, 푒, 푣 + 1).

Upon receiving a ⟨new-view, 푐, 푒, 푣, 풱⟩퐿′ message, if a member 푀 is not in a view higher than (푐, 푒, 푣), it enters view (푐, 푒, 푣) and starts a timer 푇 . If 푇 reaches 8∆ and still no new slot is committed, then 푀 abandons 퐿′ and broadcasts ⟨view-change, 푐, 푒, 푣⟩.

∙ (Status) Upon entering a new view (푐, 푒, 푣), 푀 sends ⟨⟨status, 푐, 푒, 푣, 푠 − 1, ℎ, 푠, ℎ′⟩ , 풞, 풜⟩ to the new leader 퐿′ = 퐿(푐, 푒, 푣). In the above message, ℎ is the value committed in slot 푠 − 1 and 풞 is the corresponding commit certificate; ℎ′ is the value accepted by 푀 in slot 푠 and 풜 is the corresponding accept certificate (ℎ′ = 풜 = ⊥ if 푀 has not accepted any value for slot 푠). We call the inner part of the message (i.e., excluding 풞, 풜) its summary.

Upon receiving 2푓 + 1 status messages, 퐿′ concatenates the 2푓 + 1 status summaries to form a status certificate 풮. 퐿′ then picks a status message that reports the highest last-committed slot 푠*; if there is a tie, 퐿′ picks the one that reports the highest ranked accepted value in slot 푠* + 1 . Let the two certificates in this message be 풞* and 풜* (풜* might be ⊥).

′ * ′ * * ∙ (Re-propose) The new leader 퐿 broadcasts ⟨repropose, 푐, 푒, 푣, 푠 + 1, ℎ , 풮, 풞 , 풜 ⟩퐿′ . In the above message, 푠* should be the highest last-committed slot reported in 풮. ℎ′ should match the value in 풜* if 풜* ̸= ⊥; If 풜* = ⊥, then 퐿′ can choose ℎ′ freely. 2

The repropose message serves two purposes. First, 풞* allows everyone to commit slot 푠*. Second, it re-proposes ℎ′ for slot 푠* + 1, showing a proof (풮, 풜*) that ℎ′ is safe for slot 푠* + 1. The repropose message is invalid if any of the aforementioned conditions is violated: 푠* is not the highest committed slot, 풞 is not for slot 푠*, 풜 is not for the highest ranked accepted value for 푠* + 1, or ℎ′ is not the value certified by 풜.

Upon receiving a valid repropose message, a member 푀 commits slot 푠* if it has not already; 푀 then executes the prepare/commit/notify steps as in the steady state for slot 푠* + 1, and marks all slots > 푠* + 1 fresh for view (푐, 푒, 푣). At this point, the system transitions into a new steady state.

2 Strictly speaking, in this case, 퐿′ is proposing a new value rather than re-proposing. But we keep the message name as repropose for convenience. A similar situation exists in reconfiguration.

31 A practical implementation of our protocol can piggyback status messages on view-change messages and repropose messages on new-view messages to save two steps. We choose to separate them in the above description because the reconfiguration sub-protocol can reuse the status step.

3.3.4 Reconfiguration

In order to join the committee, a new member must show a PoW, i.e., a puzzle solution (cf. Section 2.3). The details of the puzzle will be discussed later in Section 3.3.6. For now, it is sufficient to know that each configuration defines a new puzzle. Let the puzzle for configuration 푐 be puzzle(푐). The difficulty of the puzzle is periodically adjusted like in Bitcoin and the expected solution interval 퐷 should be kept significantly larger than ∆ as will be illustrated in Section 3.4. Upon finding a PoW, the miner tries to join the committee by driving a reconfiguration consensus as an external leader.

∙ (New-lifespan) Upon finding a PoW, the miner broadcasts it to the committee members.

Upon receiving a new valid PoW for the current configuration (that 푀 has not seen before), 푀 forwards the PoW to other members, enters view (푐, 푒 + 1, 0), sets the PoW finder as its 0-th leader 퐿′ = 퐿(푐, 푒 + 1, 0) of the new lifespan, and starts a timer 푇 . If 푇 reaches 8∆ and still no new slot is committed, then 푀 abandons 퐿′ and broadcasts ⟨view-change, 푐, 푒 + 1, 0⟩.

∙ (Status) Upon entering a new lifespan, 푀 sends 퐿′ ⟨⟨status, 푐, 푒, 0, 푠 − 1, ℎ, 푠, ℎ′⟩ , 풞, 풜⟩, where 푠, ℎ, 풞, 풜 are defined the same way as in the view-change procedure.

Upon receiving 2푓 + 1 status, 퐿′ constructs 푠*, 풮, 풞* and 풜* as in a view change.

∙ (Re-propose and Reconfigure) Let ℎ* be the committed value in the highest committed slot 푠* among 풮. Let ℎ′ be the highest ranked accepted value (could be ⊥) into slot 푠* + 1 among 풮. Note that ℎ* and ℎ′ are certified by 풮, 풞* and 풜*. Now depending on whether ℎ* and ℎ′ are transactions or reconfiguration events, the new external leader 퐿′ takes different actions.

– If ℎ* is a reconfiguration event to configuration 푐 + 1, then 퐿′ simply broadcasts 풞 and terminates. Terminating means 퐿′ gives up its endeavor to join the committee (it is too late and some other leader has already finished reconfiguration) and starts working on puzzle(푐 + 1).

32 – If ℎ* is a batch of transactions, and ℎ′ is a reconfiguration event to configuration 푐 + 1, ′ * ′ * * then 퐿 broadcasts ⟨repropose, 푐, 푒, 0, 푠 + 1, ℎ , 풮, 풞 , 풜 ⟩퐿′ and then terminates. – If ℎ* is a batch of transactions, and ℎ′ = ⊥, then 퐿′ tries to drive the reconfiguration * * * * consensus into slot 푠 + 1 by broadcasting ⟨repropose, 푐, 푒, 0, 푠 + 1, ℎ, 풮, 풞 , 풜 ⟩퐿′ where ℎ is a reconfiguration event that lets 퐿′ join the committee. If this proposal becomes committed, then starting from slot 푠* +2, the system reconfigures to the next configuration and 퐿′ joins the committee replacing the oldest member.

– If ℎ* and ℎ′ are both batches of transactions, then 퐿’ first re-proposes ℎ′ for slot 푠* + 1 * ′ * * ′ by broadcasting ⟨repropose, 푐, 푒, 0, 푠 + 1, ℎ , 풮, 풞 , 풜 ⟩퐿′ . After that, 퐿 tries to drive a * * reconfiguration consensus into slot 푠 + 2 by broadcasting ⟨propose, 푐, 푒, 0, 푠 + 2, ℎ⟩퐿′ where ℎ is a reconfiguration event that lets 퐿′ join the committee. If this proposal becomes committed, then starting from slot 푠* + 3, the system reconfigures to the next configuration and 퐿′ joins the committee replacing the oldest member.

In the latter three cases, members react to the repropose message in the same way as in a view change: check its validity and execute prepare/commit/notify. Note that the reconfiguration proposal in the last case is a steady state propose message instead of a repropose message, and it does not need to carry certificates as proofs. This is because after members commit the re-proposed value into slot 푠* + 1, the system enters a special steady state under leader 퐿′. Slot 푠* + 2 will be marked as a fresh slot in this steady state. This steady state is special in the sense that, if 퐿′ is not faulty and is not interrupted by another PoW finder, members will experience a configuration change, but the leader remains unchanged as we have defined 퐿(푐 + 1, 0, 0) to be the newly added member. After reconfiguration, it becomes a normal steady state inview (푐 + 1, 0, 0).

3.3.5 Improvement with Aggregate Signatures

During view changes and reconfigurations, leaders and members need to send certificates, which typically are 2푓 + 1 matching signed messages. These Θ(푛)-sized messages consume a large amount of network bandwidth as well as computation (due to signature verification). We can use BLS multisignatures and aggregate signatures [35, 34] discussed in Section 2.4 to reduce them to 푂(1) size. In the Solida protocol, the view-change certificate 풱, accept certificate 풜 and commit certificate 풞 can use multisignatures since they consist of matching messages from committee members. Such a

33 certificate would carry the common message 푚, a bit vector indicating which members signed, and the multisignature. A status certificate 풮 needs to be an aggregate signature in the most general case, but more often than not, it can also utilize multisignatures if subsets of members report the same accepted value.

3.3.6 Puzzles and Defense against Selfish Mining

We now discuss the exact form of the puzzle. A natural idea is to make the puzzle the previous reconfiguration decision. However, this allows withholding attacks similar to selfish mining [67]. To favor the adversary, we assume that if the adversary and an honest miner both find PoWs, the adversary wins the contest and joins the committee. Then, when the adversary finds a PoW first, its best strategy is to temporarily withhold it. At this point, the adversary already knows the next puzzle, which is its own reconfiguration proposal. Meanwhile, honest miners are wasting their mining power on the current puzzle, not knowing that they are doomed to lose to the adversary in the upcoming reconfiguration. This gives the adversary a head start on the next puzzle. Its chance of taking the next seat on the committee will hence be higher than its fair share of mining power. The authors of ByzCoin suggested an idea to thwart the above attack: let the puzzle include 2푓 + 1 committee member signatures. This way, a PoW finder cannot determine the puzzle on its own and thus gains nothing from withholding its PoW. For concreteness, we let puzzle(푐 + 1) be any set of 푓 + 1 notify summaries for the last reconfiguration decision ⟨notify, 푐, 푒, 푣, 푠, ℎ⟩. This ensures the following:

Lemma 3.1. The adversary learns a puzzle at most 2∆ time earlier than honest miners.

Proof. For the adversary to learn the puzzle, at least one honest committee member must broadcast its notify message, which will cause all other honest members to broadcast their notify messages within ∆ time. After another ∆ time, all honest miners receive enough notify messages to learn the puzzle.

3.4 Proof of Safety and Liveness

We first prove safety and liveness assuming each committee has no more than 푓 < 푛/3 Byzantine members. This part of the proof mostly follows PBFT. Essentially, the biggest change we made to

34 PBFT at an algorithmic level is to replace its round-robin leader schedule with one that potentially interleaves internal and external leaders. But crucially, we still have a total order among leaders to ensure safety and liveness.

Theorem 3.2. The protocol achieves safety and liveness if each committee has no more than 푓 < 푛/3 Byzantine members.

Proof. We first consider safety. Let 푀 be the member to commit slot 푠 in the lowest ranked view. Say 푀 commits value ℎ and it does so in view (푐, 푒, 푣). We need to show that no other value ℎ′ ̸= ℎ can be committed into slot 푠 in that view and all future views. In fact, we will show by induction that there cannot exist an accept certificate 풜′ for ℎ′ in that view and all future views, which means no honest member would have accepted ℎ′, let alone committing it. Since 푀 commits in view (푐, 푒, 푣), there must be 2푓 + 1 members that have accepted ℎ in that view, and 2푓 + 1 members that have sent ⟨prepare, 푐, 푒, 푣, ℎ⟩. For the base case, suppose for contradiction that 풜′ exists for ℎ′ in view (푐, 푒, 푣). Then, 2푓 + 1 members must send ⟨prepare, 푐, 푒, 푣, ℎ′⟩. This means at least one honest member has sent prepare messages for two different proposals in view (푐, 푒, 푣), which is a contradiction. For the inductive step, suppose that no accept certificate exists for ℎ′ from view (푐, 푒, 푣) up to (excluding) view (푐′, 푒′, 푣′). Since 푀 has committed slot 푠, then at least 2푓 + 1 members must have committed slot 푠 − 1 due to no pipelining (they send prepare for slot 푠 only after committing slot 푠 − 1). So in the status certificate 풮 of a repropose message for view (푐′, 푒′, 푣′), the largest last-committed slot 푠* ≥ 푠 − 1. Therefore, slot 푠 is either already committed to ℎ, or has to be re-proposed. If slot 푠 needs to be re-proposed, which means 푠* = 푠 − 1, then 풮 must contain at least one status summary reporting that ℎ has been accepted into slot 푠 with a rank no lower than (푐, 푒, 푣). Due to the inductive hypothesis, no accept certificate can exist for ℎ′ with a rank equal to or higher than (푐, 푒, 푣). ℎ is, therefore, the unique highest ranked accepted value for slot 푠, and it is the only value that can be legally re-proposed in view (푐′, 푒′, 푣′). Hence, no accept certificate for ℎ′ can exist in view (푐′, 푒′, 푣′), completing the inductive step. Now we consider liveness. According to the protocol, if a Byzantine leader does not commit any slot for too long, it will be replaced shortly. But here is a liveness threat unique to the cryptocurrency setting. The Byzantine leader can simply construct transactions that transfer funds between its own accounts and keep proposing/committing these transactions. It is hard for honest members to detect such an attack. Fortunately, we have shown that honest miners win at least 2/3 of the

35 reconfiguration races. After a reconfiguration, the newly added member becomes the leader, so2/3 of the time, an honest leader is in control to provide liveness. It remains to check that an honest leader will not be replaced until the next lifespan. It is sufficient to show that an honest leader will never be accused by an honest member. This is guaranteed by our timeout values. The notify step ensures two honest members commit a slot at most ∆ time apart. In the steady state, each member gives the leader 4∆ time to commit each slot: one ∆ to account for the possibility that other members come to this slot (i.e., finish the previous slot) ∆ time later and 3∆ for the three phases in the steady state. At the beginning of a new view or a new lifespan, each member gives the leader 8∆ time, because the status and repropose steps take extra 4∆ time. The last case to consider is when a member abandons a future leader because it does not send new-view when it should. Before accusing a future leader, a member allows 2∆ time after forwarding it a view-change certificate, which is sufficient for an honest leader to broadcast new-view.

Next, we show 푓 < 푛/3 indeed holds. Let 휌 be the adversary’s ratio of mining power. Honest miners thus collectively control 1 − 휌 of the total network mining power. Ideally, we would hope that reconfiguration is a “fair game”, i.e., the adversary takes the next committee seat with probability 휌, and an honest miner takes the next seat with probability 1 − 휌. This is simply assumed to be the case in PeerCensus [51] and ByzCoin [92]. However, we show that due to network latency, it is as if the adversary has an effective mining power 휌′ = 1 − (1 − 휌)푒−(2휌+8)Δ/퐷 > 휌. (Recall that 퐷 is the expected time for the entire network to find a PoW.) We need 퐷 ≫ ∆ so that 휌′ is not too much larger than 휌.

Theorem 3.3. Assuming 푓 < 푛/3 holds for 퐶1, then 푓 < 푛/3 holds for each subsequent committee except for a probability exponentially small in 푛 if 휌′ = 1 − (1 − 휌)푒−(2휌+8)Δ/퐷 < 1/3.

Proof. The increase in the adversary’s effective mining power comes from three sources. First, as Lemma 3.1 shows, the adversary may learn a puzzle up to 2∆ earlier than honest miners. Second, if the adversary finds a PoW while an honest external leader is reconfiguring, which cantake up to 8∆ time, the adversary can interrupt the honest leader and win the reconfiguration race. Lastly, two honest leaders may interrupt each other if they find PoWs within 8∆ time apart, while the adversary-controlled miners can coordinate their actions. Therefore, an honest miner wins a reconfiguration if all three events below happen:

36 ∙ (event 푋) the adversary finds no PoW in its 2∆ head start,

∙ (event 푌 ) some honest miner finds a PoW earlier than the adversary given 푋, and

∙ (event 푍) no miner, honest or adversarial, finds a PoW in the next 8∆ time given 푌 .

PoW mining is a memory-less process modeled by a Poisson distribution: the probability 휆푘푒−휆 for a miner to find 푘 PoWs in a period is 푝(푘, 휆) = 푘! , where 휆 is the expected number of PoWs to be found in this period. Recall that the expected time for all miners combined to find a PoW is 퐷. In the 2∆ head start, the adversary expects to find 휆푋 = 2∆휌/퐷 PoWs. Thus, −2Δ휌/퐷 −8Δ/퐷 Pr(푋) = 푝(0, 휆푋 ) = 푒 . Similarly, Pr(푍) = 푒 . Event 푌 is a “fair race” between the adversary and honest miners, so Pr(푌 ) = 1 − 휌. The memory-less nature of PoW also means that the above events 푋, 푌 and 푍 are independent. Thus, the probability that an honest miner wins a reconfiguration is

Pr(푋 ∩ 푌 ∩ 푍) = Pr(푋) Pr(푌 ) Pr(푍) = (1 − 휌)푒−(2휌+8)Δ/퐷 := 1 − 휌′.

We define the above probability to be 1 − 휌′, which can be thought of as the honest miners’ effective mining power once we take message delays into account. 휌′ is then the adversary’s effective mining power. This matches our intuition: as 퐷 → ∞, the adversary’s advantage from message delay decreases, and (1 − 휌′) → (1 − 휌).

Conditioned on all committees up to 퐶푖 having no more than 푛/3 Byzantine members, the adversary wins each reconfiguration race with probability at most 휌′, independent of the results of other reconfiguration races. We can then use the Chernoff inequality to bound the probability of Byzantine members exceeding 푛/3 on any committee up to 퐶푖+1. Let 푄 denote the number of Byzantine members on a committee. We have 퐸(푄) := 휇 = 휌′푛. Due to the Chernoff bound,

−훿휇 log(1+훿) Pr(푄 ≥ (1 + 훿)휇) ≤ 푒 2 .

1 Select 훿 = 3휌′ − 1, we have 푛(1−3휌′) log(3휌′) Pr(푄 ≥ 푛/3) ≤ 푒 6 .

If 휌′ < 1/3, then (1 − 3휌′) log(3휌′) < 0, and the above probability is exponentially small in 푛 as required.

37 푘 20 25 30 35 40 휌 = 14% 휌′ = 20% 232 298 367 439 508 휌 = 20% 휌′ = 25% 649 841 1036 1231 1423 휌 = 23% 휌′ = 28% 1657 2149 2644 3142 3580 휌 = 25% 휌′ = 30% 4366 5650 6949 8248 9256

Table 3.1: The required committee size under different adversarial miner ratios 휌 and desired security levels 푘, assuming ∆/퐷 = 1/120.

Concrete committee size. We calculate the required committee size under typical values. We can calculate 휌′ from 휌 given the value of ∆/퐷. If ∆ is 5 seconds and 퐷 is 10 minutes, then ∆/퐷 = 1/120. Then, for a desired security level, a simple calculation of binomial distribution yields the required committee size 푛. The results are listed in Table 3.4. A security parameter 푘 means there is a 2−푘 probability that, after a reconfiguration, the adversary controls more than 푛/3 seats on the committee. 푘 = 25 or 푘 = 30 should be sufficient in practice. Assuming we reconfigure every 10 minutes, 225 reconfigurations take more than 600 years and 230 reconfigurations take more than 20,000 years. With 휌′ = 25%, the required committee size is around 1000. It is worth noting that as 휌′ approaches 33%, the required committee size increases rapidly and the committee-based approach becomes impractical. This gap between theory and practice is expected. Similarly, Nakamoto consensus, in theory, can tolerate an adversary with up to 49% mining power. But the recommended “six confirmation” is calculated assuming a 10% adversary and a rather low security level 푘 ≈ 10. If the adversary really controls close to 50% mining power, then thousands of confirmations would be required for each block.

3.5 Implementation and Evaluation

Implementation details. We implement the Solida consensus protocol in Python and measure its performance. We implement the non-pipelined 6-round PBFT-style protocol in which committee members agree on a proposal digest from a successful miner. For digital signatures, we test two schemes and implementations: (1) ECDSA with the ed25519 curve [25], and (2) BLS aggregate signatures [35, 34] using the Relic toolkit [16]. We test Solida on 16 m4.16xlarge machines on Amazon EC2. The CPUs are Intel Xeon E5-2686 v4 @ 2.3 GHz. Each machine has 64 cores, giving a total of 1024 cores. We use one CPU core for each committee member, testing committee size up to 1000.

38 60 10 Mbps 50 35 Mbps 75 Mbps 40 4 30 3 2 20 1 0 Consensus time (s) 100 400 10

0 100 400 1000 Committee size

Figure 3-1: Time to achieve reconfiguration consensus in Solida with ECDSA. 1.8 10 Mbps 1.6 35 Mbps 1.4 75 Mbps

1.2

1.0

0.8 Consensus time (s)

0.6 100 400 700 1000 Committee size

Figure 3-2: Time to achieve reconfiguration consensus in Solida with BLS.

To emulate Internet latency and bandwidth, we add a delay of 0.1 seconds (unless otherwise stated) to each message and throttle the bandwidth of each committee member. While our experiments are not RAM bound, we mention for completeness that each machine has 256 GB RAM.

Experimental results. We report the time it takes for committee members to commit a recon- figuration consensus decision (committing a decision in the steady state takes strictly lesstime). We report the consensus time (averaged over 10 slots) from the leader’s perspective, i.e., the time between when the leader sends its PoW and when the leader receives the first notify message, which is the earliest point at which the leader knows its proposal is committed. We test different committee sizes and per-node network bandwidth limits to study scalability.

39 Figure 3-1 gives the results using ECDSA. As shown in the zoom-in part, with a small committee of 100 members, a decision takes less than 1 second. The bottleneck here is network latency. Recall that there are 6 sequential messages from the leader’s perspective, each adding 0.1s latency. With larger committees, network bandwidth becomes the bottleneck. As expected, consensus time is roughly quadratic in committee size and inversely proportional to network bandwidth. With 1000 committee members, consensus time is manageable given ample bandwidth (8.4 seconds with 75 Mbps) but increases to over 50 seconds under low bandwidth (10 Mbps). Figure 3-2 gives the results using BLS aggregate signatures. BLS aggregate signatures effectively eliminate the network bandwidth bottleneck and significantly improve performance. Even with 10 Mbps bandwidth, it takes about 0.8 seconds for a committee of size 400 to reach consensus and about 1.6 seconds for a committee of size 1000. The protocol still scales quadratically with committee size as signature verification becomes the new bottleneck. To study the effect of network latency, we rerun some experiments with a 0.5s latency (results not shown). In each experiment, consensus time increases by about 2.5s, which is as expected given the 6 sequential messages and a 0.4s latency increase for each.

Comparison to ByzCoin evaluation results. We would like to explain an apparent contradic- tion between our experimental results and those of ByzCoin [92]. Under the same parameter settings (0.1s latency, 35 Mbps bandwidth, plain ECDSA, and 100 committee members), our implementation of PBFT takes less than 1 second per consensus decision, while ByzCoin concludes that PBFT has unacceptable performance. On a closer look, our results and theirs actually corroborate each other. ByzCoin finds PBFT performance to be unacceptable only when the block is large. With a small block size, their results confirm that PBFT is very fast and indeed takes about 1second per consensus decision. Therefore, the unacceptable performance they see in PBFT solely results from the leader broadcasting the entire batch (block) of transactions {tx}. To improve scalability, ByzCoin suggests sending not just transaction batches, but also PBFT consensus messages, in a tree rooted at the leader. While it is important to reduce the leader’s burden, using a tree as the communication graph is not Byzantine fault tolerant. A Byzantine node in the tree can make its entire subtree unreachable. Instead, transaction batches and consensus messages should be gossiped through the peer-to-peer network much like in Bitcoin. The other major technique ByzCoin employs to improve scalability is Schnorr-based multisignature, which is also not Byzantine fault tolerant

40 Consensus for Defend Design Latency committee election transactions selfish mining

Bitcoin [114] Nakamoto High No Bitcoin-NG [66] Nakamoto Nakamoto High No PeerCensus [51] Byzantine* Byzantine Low No ByzCoin [92] Nakamoto/Byzantine Byzantine Low Yes Hybrid consensus [121] Nakamoto Byzantine Low Yes Solida Byzantine Byzantine Low Yes

Table 3.2: Comparison of consensus protocols in Solida and related designs. Bitcoin and Solida combine committee election and transactions into a single step. Other protocols decouple the two, which we reflect with two separate columns in the table. as discussed in Section 3.3.5. Therefore, the results reported in ByzCoin are only for the best case where there is no adversary.

3.6 Related Work

A comparison between Solida and related designs. Table 3.6 compares Solida and related designs. To start, we have Bitcoin that pioneered the study of permissionless consensus (though not using the term). Bitcoin uses Nakamoto consensus, i.e., PoW and the longest-chain-win rule, and does not separate leader election and transaction processing. There have been numerous follow-up works in the Nakamoto framework. Some “altcoins” simply increase the block creation rate without other major changes to the Bitcoin protocol. A few proposals relax the “chain” design and instead utilize other graph structures to allow for faster block creation rate [143, 102]. Some proposals [132] aim to improve throughput with off-chain transactions. Bitcoin-NG suggests decoupling transactions processing and leader election [66]. A miner is elected as a leader if it mines a (key) block in a PoW chain. This miner/leader is then responsible for signing transactions in small batches (microblocks) until a new leader emerges. Since (key) blocks in the PoW chain are small, Bitcoin-NG reduces the likelihood of forks. One can think of each leader in Bitcoin-NG to be a single-member committee. Since a single leader cannot be trusted, any

41 transactions it approves still have to be buried in a Nakamoto PoW chain. Thus, Bitcoin-NG does not significantly improve transaction latency. To our knowledge, Tendermint [97] is the first cryptocurrency proposal that uses conventional Byzantine consensus and PeerCensus [51] is the first to combine conventional Byzantine consensus with PoW. Both proposals were described at a high level with no details on reconfiguration. Hybrid consensus [121] relies on Nakamoto consensus (a PoW chain) to elect committees which then process transactions using conventional Byzantine consensus. We have compared to this approach in detail in Section 3.1. ByzCoin [92] employs multi-signatures to improve the scalability of PBFT. Reconfiguration in ByzCoin seems to be left open with options. A blogpost[71] suggests adopting hybrid consensus [121], in which case our comparison to hybrid consensus applies to ByzCoin as well. Through private communication, we learned that ByzCoin designers also had in mind a PBFT-style reconfiguration protocol. We will then have to wait to see a detailed protocol for aproper comparison. A number of proposals combine conventional Byzantine consensus with proof-of-stake (cf. Chapter 5) [97, 111, 38]. Elastico [107] and Omniledger [93] use conventional Byzantine consensus to build sharding protocols.

Bitcoin analysis. While the Bitcoin (Nakamoto consensus) protocol is quite simple and elegant, proving its security rigorously turns out to be highly nontrivial. The original Bitcoin paper [114] and a few early works [67, 143] considered specific attacks. Garay et75 al.[ ] provided the first rigorous security analysis for Nakamoto consensus, by modeling it as a synchronous protocol running in a synchronous network. Pass et al. [120] refined the analysis after observing that Nakamoto consensus, while relying on a synchronous assumption, does not require participants to move in lock-step rounds. Garay et al. [75] laid out three desired properties for a public ledger: common prefix, chain quality, and chain growth. We note that these properties are more applicable to Nakamoto-style protocols that do not satisfy traditional safety and liveness. Common prefix is strictly weaker than safety. Chain growth is the Nakamoto consensus counterpart of liveness. If chain quality is interpreted as “the ratio of honest committee members” in the committee-based approach, then we have proved it in Theorem 3.3. If it is instead interpreted as “the ratio of slots committed under honest leaders”, then it is not very meaningful in our model. We cannot prevent Byzantine leaders from making progress really fast, thereby decreasing the ratio of slots committed under honest leaders, but that does not hurt honest leaders’ ability to commit slots at their own pace in their own views.

42 Chapter 4

Efficient Synchronous Byzantine Consensus

This chapter presents new protocols for Byzantine agreement and BFT state machine replication in the synchronous and authenticated setting. We give a Byzantine agreement protocol that halts in expected 9 rounds and a state machine replication protocol that commits a decision every 3 rounds in the common case. Both protocols tolerate 푓 Byzantine faults with 2푓 + 1 replicas. The protocols will be described in the permissioned setting, but can be adapted to the permissionless setting using the Solida framework.

4.1 Introduction

Broadly speaking, Byzantine consensus considers the problem of reaching agreement among a group of 푛 parties, among which up to 푓 can have Byzantine faults and deviate from the protocol arbitrarily. Chapter 2 has reviewed variants of Byzantine consensus problem formulations: the more theoretical Byzantine broadcast and agreement, and the more practical state machine replication. The PBFT protocol provides a practical solution to state machine replication in the asynchronous setting (it relies on partial synchrony for liveness but not for safety) and achieves the optimal 푓 < 푛/3 Byzantine fault tolerance in that setting. Perhaps somewhat surprisingly, we do not yet have a practical solution for Byzantine consensus with optimal fault tolerance in the seemingly easier synchronous setting. To the best of our knowledge,

43 the most efficient Byzantine agreement protocol with the optimal 푓 < 푛/2 fault tolerance in this setting is due to Katz and Koo [89], which requires in expectation 24 rounds of communication (not counting their random leader election subroutine). To agree on many messages sequentially, it requires additional generic transformations [103, 89] that further increase the expected round complexity by a factor of 3! This chapter presents efficient Byzantine consensus protocols for the synchronous and authenti- cated (i.e., using digital signatures) setting tolerating 푓 < 푛/2 faults. Our protocols draw inspiration from Paxos [99] and PBFT [42]. Section 4.2 presents a core protocol that resembles the synod algorithm in Paxos but is adapted to the synchronous and Byzantine setting. Since the main focus of this chapter is state machine replication, I will describe the core protocol with “replicas” instead of “parties/participants”. In a nutshell, it runs in iterations with a unique leader in each iteration (how to elect leaders is left to higher level protocols). Each new leader picks up the states left by previous leaders and drives agreement in its iteration. A Byzantine leader can prevent progress but cannot violate safety. As soon as an honest leader emerges, all honest replicas reach agreement and terminate at the end of that iteration. The major challenge to adapt the synod algorithm to the synchronous, Byzantine and 푓 < 푛/2 setting is to ensure quorum intersection [99] at one honest replica. The core idea of Paxos is to form a quorum of size 푓 + 1 before committing a value. With 푛 = 2푓 + 1, two quorums always intersect at one replica, which is honest in Paxos. This honest replica in the intersection will force a future leader to respect the committed value. In order to tolerate 푓 Byzantine faults, PBFT uses quorums of size 2푓 + 1 out of 푛 = 3푓 + 1, so that two quorums intersect at 푓 + 1 replicas, among which one is guaranteed to be honest. However, with 푛 = 2푓 + 1 replicas in total, an intersection of size 푓 + 1 seems to require quorums of size 1.5푓 + 1. On the other hand, a quorum size larger than 푓 + 1 (the number of honest replicas) seems to require participation from Byzantine replicas and thus loses liveness. (An independent work called Thunderella [123] uses quorums of size 1.5푓 + 1 only to improve the optimistic case.) Our solution is to utilize the synchrony assumption to form a post-commit quorum of size 2푓 + 1, namely, all replicas. A post-commit quorum does not affect liveness and intersects with any pre-commit quorum (of size 푓 + 1) at 푓 + 1 replicas. This satisfies the requirement of one honest replica in intersection. With some additional checks and optimizations, we obtain the core protocol in Section 4.2: a 4-round synchronous Byzantine synod protocol (three

44 Paxos-like rounds plus a notification round). It preserves safety under Byzantine leaders and ensures termination once an honest leader emerges. Section 4.3 applies the core protocol to solve multi-valued Byzantine broadcast and agreement. At a high level, we elect a random leader after each iteration. The first honest leader will ensure agreement and termination for all honest parties. Using a (piggybacked) random leader election process, there is a (푓 + 1)/(2푓 + 1) > 1/2 probability that each leader is honest, so the protocol terminates in expected 2 iterations (9 rounds). Section 4.4 applies the core protocol to state machine replication. We could again change the leader after iteration, but a better strategy is to keep a stable leader in control and only replace the leader if it is not making progress. The improved protocol commits a decision in 3 rounds in the common case. We remark that in the synchronous and authenticated setting, 푛 = 2푓 + 1 is optimal for Byzantine agreement and BFT state machine replication, but not for Byzantine broadcast. Our quorum-based approach cannot solve Byzantine broadcast in the dishonest majority case (푛/2 ≤ 푓 < 푛).

4.2 A Synchronous Byzantine Synod Protocol

4.2.1 Model and Overview

Our core protocol is a synchronous Byzantine synod protocol with 푛 = 2푓 + 1 replicas. We consider a static corruption adversary, i.e., the adversary needs to decide which replicas are Byzantine before the protocol starts. The goal of the core synod protocol is to guarantee that all honest replicas eventually commit (liveness) and commit on the same value (safety). We assume synchrony. If an honest replica 푖 sends a message to another honest replica 푗 at the beginning of a round, the message is guaranteed to reach by the end of that round. We describe the protocol assuming all replicas have perfectly synchronized clocks. Hence, they enter and exit each round simultaneously. How to keep clocks synchronized in practice is important future work. We assume public key cryptography. Every replica knows the public (verification) key of every other replica, and they use digital signatures when communicating with each other. Byzantine replicas cannot forge honest replicas’ signatures, which means messages in our model enjoy authenticity as well as non-repudiation. We use ⟨·⟩ to denote signed messages; refer to Section 2.2 for details.

45 The core synod protocol runs in iterations. Each iteration has a unique leader that is known to every replica. An iteration leader can be one of the replicas but can also be an external entity. Similar to Paxos, we decouple leader election from the core protocol and leave it to higher level protocols (e.g., Section 4.3 and 4.4). For example, a cryptocurrency may elect leaders based on proof of work. Each iteration consists of 4 rounds. The first three rounds are conceptually similar to Paxos: (1) the leader learns the states of the system, (2) the leader proposes a safe value, and (3) every replica sends a commit request to every other replica. If a replica receives 푓 + 1 commit requests for the same value, it commits on that value. We then add another round: (4) if a replica commits, it notifies all other replicas about the commit; upon receiving a notification, other replicas accept the committed value and will vouch for that value to future leaders. To tolerate Byzantine faults, we need to add equivocation checks and other proofs of honest behaviors at various steps. We now describe the protocol in detail.

4.2.2 Detailed Protocol

Each replica 푖 internally maintains some long-term states accepted푖 = (푣푖, 푘푖, 풞푖) across iterations to record its accepted value. Initially, each replica 푖 initializes accepted푖 := (⊥, 0, ⊥). If replica 푖 later accepts a value 푣 in iteration 푘, it sets accepted푖 := (푣, 푘, 풞) such that 풞 certifies that 푣 is legally accepted in iteration 푘 (see Table 4.2.2). Due to synchrony, replicas have the same view on the current iteration number 푘 (the first iteration has 푘 = 1). In the protocol, honest replicas will only react to valid messages. Invalid messages are simply discarded. To keep the presentation simple, we defer the validity definitions of all types of messages to Table 4.2.2. We first describe the protocol assuming no replica has terminated, and lateramend the protocol to deal with non-simultaneous termination. When we say a replica “broadcasts” a message, we mean it sends the message to all replicas including itself.

Round 0 (status) Each replica 푖 sends a ⟨⟨푘, status, 푣푖, 푘푖⟩푖 , 풞푖⟩푖 message to the leader 퐿푘 of the

current iteration 푘, informing 퐿푘 of its current accepted value. We henceforth write 퐿푘 as 퐿 for simplicity.

At the end of this round, the leader 퐿 picks 푓 + 1 valid status messages to form a status certificate 풮.

46 Round 1 (propose) The leader 퐿 picks a value 푣 that is safe to propose under 풮: 푣 should match the value that is accepted in the most recent iteration in 풮, or any 푣 is safe to propose if no value has been accepted in 풮 (see Table 4.2.2 for more details). 퐿 then broadcasts a signed

proposal ⟨⟨푘, propose, 푣⟩퐿 , 풮⟩퐿.

At the end of this round, if replica 푖 receives a valid proposal ⟨⟨푘, propose, 푣⟩퐿 , 풮⟩퐿 from the

leader, it sets 푣퐿→푖 := 푣. Otherwise (leader is faulty), it sets 푣퐿→푖 := ⊥.

Round 2 (commit) If 푣 := 푣퐿→푖 ̸= ⊥, replica 푖 forwards the proposal ⟨푘, propose, 푣⟩퐿 (excluding

풮) to all other replicas and broadcasts a ⟨푘, commit, 푣⟩푖 request.

′ At the end of this round, if replica 푖 is forwarded a valid proposal ⟨푘, propose, 푣 ⟩퐿 in which ′ 푣 ̸= 푣퐿→푖, it does not commit in this iteration (leader has equivocated). Else, if replica 푖

receives 푓 + 1 valid ⟨푘, commit, 푣⟩푗 requests in all of which 푣 = 푣퐿→푖, it commits on 푣 and sets

its long-term state 풞푖 to be these 푓 + 1 commit requests concatenated. In other words, replica 푖 commits if and only if it receives 푓 + 1 valid and matching commit requests and does not detect leader equivocation.

Round 3 (notify) If replica 푖 has committed on 푣 at the end of Round 2, it sends a notification

⟨⟨푘, notify, 푣⟩푖 , 풞푖⟩푖 to every other replica, and terminates. At the end of this round, if replica 푖 receives a valid ⟨⟨푘, notify, 푣⟩ , 풞⟩ message, it accepts 푣 푗 푗

by setting its long-term states accepted푖 = (푣푖, 푘푖, 풞푖) := (푣, 푘, 풞). If replica 푖 receives multiple valid notify messages with different values (when this can happen is explained at the endof Section 4.2.3), it is free to accept any one or none. Lastly, replica 푖 increments the iteration counter 푘 and enters the next iteration.

Summaries and certificates. In a ⟨⟨푘, status, 푣푖, 푘푖⟩푖 , 풞푖⟩푖 message, we call the ⟨푘, status, 푣푖, 푘푖⟩푖 component a status summary, and the 풞푖 component a commit certificate. Similarly, in a

⟨⟨푘, notify, 푣⟩푖 , 풞푖⟩푖 message, we call the ⟨푘, notify, 푣⟩푖 component a notify summary, and 풞푖 is again a commit certificate. This distinction will soon be important for handling non-simultaneous termina- tion.

A shorter status certificate 풮. In the above basic protocol, 풮 consists of 푓 + 1 valid status messages, each of which contains a commit certificate. This yields a length of |풮| = 푂(푛2). We

47 Message Validity requirements

⟨⟨푘, status, 푣푖, 푘푖⟩푖 , 풞푖⟩푖 푘푖 = 0 (initial state) or 풞푖 certifies (푣푖, 푘푖) if 푘0 > 0.

⟨⟨푘, propose, 푣⟩퐿 , 풮⟩퐿 푣 is safe to propose under 풮 in iteration 푘. 퐿 is the leader of iteration 푘.

⟨푘, commit, 푣⟩푖 No extra requirement.

⟨⟨푘, notify, 푣⟩푖 , 풞⟩푖 풞 certifies (푣, 푘). 풮 consists of 푓 + 1 status or notify summaries, plus a commit certifi- cate for a summary that claims the highest non-zero iteration number. Each status summary in 풮 must carry the current iteration number 푘. If multiple summaries claim the same highest iteration number, the commit certificate can be for any of them. Without loss of generality, 푣 is safe to propose suppose 풮 = (푠1, 푠2, ··· , 푠푓+1, 풞) in which 푠푗 = ⟨푘, status, 푣푗, 푘푗⟩푗 or under 풮 in iteration 푘 * * 푠푗 = ⟨푘푗, notify, 푣푗⟩. Let 푘 = max(푘1, 푘2, ··· , 푘푓+1). If 푘 = 0, then 풞 = ⊥ and any 푣 is safe to propose under 풮. If 푘* > 0, then 푣 must * match some 푣푗 such that 푘푗 = 푘 and 풞 certifies (푣푗, 푘푗). There may be additional requirements on 푣 at the application level that replicas should verify. 풞 consists of 푓 + 1 commit requests or notify summaries for value 푣. Each 풞 certifies (푣, 푘) commit request in 풞 must carry the current iteration number 푘.

Table 4.1: Validity requirements of messages. Every message must carry the current iteration number 푘 and be signed by the sender. Additional validity requirements are listed in the table. A message’s validity may depend on the validity of its components and other conditions defined in the table. observe that 풮 can be optimized to have length 푂(푛). 풮 can consist of 푓 + 1 valid status summaries plus a commit certificate for a summary that claims the highest iteration number. Table 4.2.2 presents more details.

Non-simultaneous termination. We need to ensure that all honest replicas eventually commit and terminate. However, in the protocol above, it is possible that some honest replicas terminate in an iteration while other honest replicas enter the next iteration. Without special treatment, the honest replicas who enter the new iteration will never be able to terminate (unable to gather 푓 + 1 matching commit requests) if Byzantine replicas simply stop participating. To solve this problem, we use a standard idea: honest replicas continue participating “virtually” after termination.

If replica 푡 has committed on 푣푡 and terminated in iteration 푘푡, it is supposed to send a valid notification ⟨⟨푘푡, notify, 푣푡⟩푡 , 풞푡⟩푡 to all other replicas. Upon receiving this notification, replica 푖

48 becomes aware that replica 푡 has terminated, and does not expect any messages from replica 푡 in future iterations. Of course, it is also possible that replica 푡 is Byzantine and sends notifications only to a subset of replicas. We need to ensure that such a fake termination does not violate safety or liveness.

Assuming that replica 푖 has received a valid notification ⟨⟨푘푡, notify, 푣푡⟩푡 , 풞푡⟩푡 from replica 푡, we now amend the protocol such that in all future iterations 푘 > 푘푡, replica 푖 “pretends” that it keeps receiving virtual messages from replica 푡 in the follow ways:

– In Round 0, if replica 푖 is the current iteration leader, it treats the notification

⟨⟨푘푡, notify, 푣푡⟩푡 , 풞푡⟩푡 as a valid ⟨⟨푘, status, 푣푡, 푘푡⟩푡 , 풞푡⟩푡 message from replica 푡. In particu-

lar, a status certificate 풮 is allowed to include the notify summary ⟨푘푡, notify, 푣푡⟩푡 in place of a status summary.

– In Round 1, if replica 푡 is the current iteration leader 퐿, then replica 푖 treats the notify

summary ⟨푘푡, notify, 푣푡⟩푡 as a virtual proposal for 푣푡. If 푣푡 = 푣푖 (the value replica 푖 accepts),

then replica 푖 considers the virtual proposal valid and sets 푣퐿→푖 = 푣푡. Later in Round 2, replica 푖 forwards the virtual proposal to all replicas for equivocation checking.

– In Round 2, replica 푖 treats the notify summary ⟨푘푡, notify, 푣푡⟩푡 as a valid commit request

for 푣푡 from replica 푡. In particular, a commit certificate 풞푖 is allowed to include this notify summary in place of a commit request.

Figure 4-1 gives an illustration of the core synod protocol in Section 4.2.2. In this example, 푓 = 2, 푛 = 2푓 + 1 = 5, replicas 3 and 4 are Byzantine and replica 3 is the leader 퐿 in iteration 푘.

0. (status) Each replica sends its current states to 퐿 = 3. 1. (propose) No replica has committed or accepted any value, so 퐿 can propose any value of its choice. 퐿 equivocates and sends one proposal to replica 4 (shown by dashed red arrow) and a different proposal to honest replicas. 2. (commit) Honest replicas forward 퐿’s proposal and send commit requests to all replicas. Replica 4 only sends to replicas {3, 4, 5}. Replicas 1 and 2 receive 푓 + 1 commit requests for the blue value and do not detect equivocation, so they commit. Replica 5 detects leader equivocation and does not commit despite also receiving 푓 + 1 commit requests for the blue value.

49 Forward L’s Commit & send notify iff Send status L proposes Send status to proposal & send 1. Receive f+1 commit to leader L a safe value new leader L’ commit request 2. No equivocation detected

1

2

3

4

5

status propose commit notify status

Iteration k Iteration k+1 Leader L = 3 Leader L’ = 5

Figure 4-1: An example iteration of the synchronous Byzantine synod protocol.

3. (notify) Replicas 1 and 2 notify all other replicas and terminate. On receiving a valid notification, replica 5 accepts the blue value. 4. (status) The replicas send status messages to the new leader 퐿′ = 5 for iteration 푘 + 1. status messages from terminated replicas 1 and 2 are virtual (shown by dotted green arrows).

4.2.3 Safety and Liveness

In this section, we prove that the protocol in Section 4.2.2 provides safety and liveness. We first give some intuition to aid understanding. The scenario to consider for safety iswhenan honest replica ℎ commits on a value 푣* in iteration 푘*. We show that, in all subsequent iterations, no leader can construct a valid proposal for a value other than 푣*. We first show that Byzantine replicas cannot commit or accept a value other than 푣* in iteration 푘*. Thus, all other honest replicas accept 푣* at the end of iteration 푘* upon receiving notify from the honest replica ℎ. The leader in iteration 푘* + 1 needs to show 푓 + 1 status messages and pick a value with the highest iteration number (cf. Table 4.2.2). One of these status messages must be from an honest replica and contain 푣*. This implies that a value other than 푣* cannot be proposed in iteration 푘* + 1, and hence cannot be

50 committed or accepted in iteration 푘* + 1, and hence cannot be proposed in iteration 푘* + 2, and so on. Safety then holds by induction. We now formalize the above intuition through an analysis of commit certificates. A commit certificate 풞 for (푣, 푘) certifies that 푣 has been legally committed and/or accepted in iteration 푘 (it has to meet the requirements in Table 4.2.2). We prove the following lemma about commit certificates: once an honest replica commits, all commit certificates in that iteration and future iterations can only certify its committed value.

Lemma 4.1. Suppose replica ℎ is the first honest replica to commit and it commits on 푣* in iteration 푘*. If a certificate 풞 for (푣, 푘*) is valid, then 푣 = 푣*.

Proof. 풞 must consist of 푓 + 1 valid commit requests or notify summaries for 푣. At least one of these comes from an honest replica (call it ℎ1). Since no honest replica has terminated so far, replica

ℎ1 must have sent a normal commit request rather than a virtual one. Thus, replica ℎ1 must have received a valid proposal (could be virtual) for 푣 from the leader, and must have forwarded the proposal to all other replicas. If 푣 ̸= 푣*, replica ℎ would have detected leader equivocation, and would not have committed on 푣* in this iteration. So we have 푣 = 푣*.

Lemma 4.2. Suppose replica ℎ is the first honest replica to commit and it commits on 푣* in iteration 푘*. If a certificate 풞 for (푣, 푘) where 푘 ≥ 푘* is valid, then 푣 = 푣*.

Proof. We prove by induction on 푘. Lemma 4.1 proves the base case. Before proceeding to the inductive case, it is important to observe that all honest replicas will accept 푣* at the end of iteration 푘*. This is because, in iteration 푘*, the honest replica ℎ must have sent a notify message (with a commit certificate for 푣*) to all replicas and commit certificates for other values cannot exist. Now for the inductive case, suppose the lemma holds up to iteration 푘. We need to prove that 풞 is a valid certificate for (푣, 푘 + 1), then 푣 = 푣*. The inductive hypothesis says between iteration 푘* to iteration 푘, all commit certificates certify 푣*. So at the beginning of iteration 푘 + 1, all honest replicas either have committed on 푣* or still accept 푣*. If 풞 certifies (푣, 푘 + 1), it must consist of 푓 + 1 valid commit requests or notify summaries for 푣. At least one of these is from an honest replica (call it ℎ2).

1. If replica ℎ2 has terminated before iteration 푘 + 1, its notify summary (virtual commit request) is for 푣* and we have 푣 = 푣*.

51 2. Otherwise, replica ℎ2 must have received from the leader a valid proposal (could be virtual) for 푣 in iteration 푘 + 1. Note again that all honest replicas either have committed on 푣* or still accept 푣* at the beginning of iteration 푘 + 1.

(a) If the proposal is a virtual one, in order for replica ℎ2 to consider it valid, 푣 must match * 푣ℎ2 (the value replica ℎ2 accepts), which is 푣 . (b) If the proposal is a normal one, then it must contain a status certificate 풮 for 푣. Since replica ℎ committed on 푣* in iteration 푘*, 풮 includes at least one honest replica’s status or notify summary for (푣*, 푘*) (or an even higher iteration number). Due to the inductive hypothesis, no commit certificate for (푣′, 푘′) where 푘′ ≥ 푘* and 푣′ ̸= 푣* can be valid. Recall that 푣 must match the value in a summary that claims the highest iteration number. Therefore, the only value that is safe to propose under 풮 is 푣 = 푣*.

Therefore, we have 푣 = 푣′ in all cases in the inductive step, completing the proof.

Theorem 4.3 (Safety). If two honest replicas commit on 푣 and 푣′ respectively, then 푣 = 푣′.

Proof. Suppose replica ℎ is the first honest replica to commit, and it commits on 푣* in iteration 푘*. In order for another honest replica to commit on 푣, there must be a valid commit certificate 풞 for (푣, 푘) where 푘 ≥ 푘*. Due to Lemma 4.2, 푣 = 푣*. Similarly, 푣′ = 푣*, and we have 푣 = 푣′.

We now move on to liveness and show that an honest leader will guarantee all honest replicas terminate by the end of that iteration.

Theorem 4.4 (Liveness). If the leader 퐿 in iteration 푘 is honest, then every honest replica terminates at the end of iteration 푘 (if it has not already terminated before iteration 푘).

Proof. The honest leader 퐿 will send a proposal (could be virtual) to all replicas. If 퐿 has not terminated, it will send a valid proposal for a value 푣 that is safe to propose, and attach a valid 풮. If 퐿 has committed on 푣 and terminated, then all honest replicas have either committed on 푣 or accept 푣 at the beginning of iteration 푘 (cf. proof of Lemma 4.2), so they all consider 퐿’s virtual proposal valid. Additionally, the unforgeability of digital signatures prevents Byzantine replicas from falsely accusing 퐿 of equivocating. Therefore, all honest replicas (terminated or otherwise) will send commit requests (could be virtual) for 푣, receive 푓 + 1 commit requests for 푣 and terminate at the end of the iteration.

52 Finally, we mention an interesting scenario that does not have to be explicitly addressed in the proofs. Before any honest replica commits, Byzantine replicas may obtain commit certificates for multiple values in the same iteration. In particular, the Byzantine leader proposes two values 푣 and 푣′ to all the 푓 Byzantine replicas. (An example with more than two values is similar.) Byzantine replicas then exchange 푓 commit requests for both values among them. Additionally, the Byzantine leader proposes 푣 and 푣′ to different honest replicas. Now with one more commit request for each value from honest replicas, Byzantine replicas can obtain commit certificates for both 푣 and 푣′, and can make honest replicas accept different values by showing them different commit certificatesnotify ( messages). However, this will not lead to a safety violation because no honest replica would have committed in this iteration: the leader has equivocated to honest replicas, so all honest replicas will detect equivocation from forwarded proposals and thus refuse to commit. This scenario showcases the necessity of both the synchrony assumption and the use of digital signatures for our protocol. Lacking either one, equivocation cannot be reliably detected and any protocol will be subject to the 푓 < 푛/3 bound. For completeness, we note that the above scenario will not lead to a liveness violation, either. In the next iteration, honest replicas consider a proposal for any value (including but not limited to 푣 and 푣′) to be valid as long as it contains a valid status certificate 풮 for that value.

4.3 Byzantine Broadcast and Agreement

In this section, we describe protocols that solve synchronous authenticated Byzantine broadcast and agreement for the 푓 < 푛/2 case. We first present a protocol for Byzantine broadcast. Then, wecan use the well-known reduction in Section 2.1 to solve Byzantine agreement. Recall the problem definition of Byzantine broadcast from Section 2.1. A designated sender tries to broadcast a value to 푛 parties. A solution needs to satisfy three requirements:

(termination) all honest parties eventually commit,

(agreement) all honest parties commit on the same value, and

(validity) if the sender is honest, then all honest parties commit on the value it broadcasts.

A “pre-round”. Before running the core protocol in Section 4.2.2, we prepend an extra pre-round to allow the designated sender to broadcast its value. Let replica 퐿푠 be the designated sender. In

53 the pre-round, 퐿 broadcasts a signed value ⟨푣 ⟩ to every replica. At the end of the pre-round, if 푠 푠 퐿푠 replica 푖 receives ⟨푣 ⟩ from 퐿 , then replica 푖 accepts 푣 by setting its states (푣 , 푘 ) := (푣 , 0) and 푠 퐿푠 푠 푠 푖 푖 푠 풞 := ⟨푣 ⟩ . Note that the certificate for accepting 푣 is simply a valid signature from 퐿 . 푖 푠 퐿푠 푠 푠

Main loop. After the pre-round, we enter the main loop of the core protocol in Section 4.2.2. The first iteration of the main loop is now slightly different. Before, the leader 퐿1 of the first iteration will certainly find in its status round that “no replica has accepted anything”, and is hence free to propose any value. But now, replicas may have accepted values from 퐿푠.

Random leader election. We adopt the verifiable random function (VRF) approach from

Algorand [111] to elect random leaders. Let 퐹푠푘(·) be a verifiable random function discussed in Section 2.4. In iteration 푘, party 푖 evaluates the VRF on the iteration number and uses the output

푦푖 = 퐹푠푘푖 (푘) as a rank. The party with the highest rank is the leader of this iteration. Adapting the idea to our protocol, every party should act as a leader in the status round and the propose round of each iteration to collect states and make a proposal. 푦푖 and its corresponding proof 휋푖 are part of the proposal. In the commit round, each party forwards the highest ranked proposal. If an honest party has the highest rank in an iteration, every honest party will receive its VRF rank and will consider it the leader. However, if a Byzantine party has the highest rank, it can selectively withhold its VRF rank to other parties. This may cause honest parties to have different views on the identity of the leader. We need to make sure such a misbehavior does not affect safety. (It can prevent termination in this iteration, which a Byzantine leader can always do.) To this end, several modifications to the synod protocol are in place as underlined below. At the end of commit round, a party commits if it receives 2푓 + 1 matching commit messages (can be virtual) and is not forwarded an equivocating proposal or a proposal from a leader with a higher rank. commit messages and notify summaries now additionally include a leader’s identity 퐿, i.e., ⟨푘, commit, 퐿, 푣⟩ and ⟨⟨푘, notify, 퐿, 푣⟩ , 풞⟩ where as before, 푘 is the iteration number, 푣 is the leader’s proposal and 풞 certifies (푣, 푘). Since parties may now have different views on the leader’s identity, they may also have different opinions on the validity of the above messages. For replica 푖 to consider ⟨푘, commit, 퐿, 푣⟩ and ⟨⟨푘, notify, 퐿, 푣⟩ , 풞⟩ valid, 퐿 must have the highest rank in iteration 푘 to replica 푖’s knowledge.

54 We next prove the above protocol satisfies Byzantine broadcast’s agreement, validity and termination requirements.

Agreement. Agreement closely follows the proofs in Section 4.2.3. Most changes apply to the base case as underlined below.

Lemma 4.5 (cf. Lemma 4.1). Suppose replica ℎ is the first honest replica to commit and it commits on 푣* in iteration 푘*. If a certificate 풞 for (푣, 푘*) is valid to an honest replica, then 푣 = 푣*.

Proof. 풞 must consist of 푓 + 1 valid commit requests or notify summaries for 푣. At least one of these comes from an honest replica (call it ℎ1). Since no honest replica has terminated so far, replica

ℎ1 must have sent a normal commit request rather than a virtual one. Thus, replica ℎ1 must have received a valid proposal (could be virtual) for 푣. Suppose this proposal for 푣 comes from a leader * * with a VRF rank 푦1. Suppose ℎ receives a proposal for 푣 from a leader with a VRF rank 푦 . ℎ and

ℎ1 must have forwarded the respective proposals they receive to all other replicas, including each * other. We have 푦 ≥ 푦1; otherwise, ℎ would have learned about the higher ranked leader with 푦1 and * * would not have committed on 푣 in this iteration; We also have 푦1 ≥ 푦 ; otherwise, ℎ1 knows about * * * the higher ranked leader with 푦 and would not consider 풞 valid. Thus, 푦 = 푦1. If 푣 ̸= 푣 , replica ℎ would have detected leader equivocation, and would not have committed on 푣* in this iteration. So we have 푣 = 푣*.

The statement and proof of Lemma 4.2 remain unchanged except for replacing every occurrence of “valid certificate” with “valid certificate to an honest replica”. The statement and proof of the safety theorem remain unchanged. We do not repeat them.

Validity. If the designated sender 퐿푠 is honest, then all honest replicas will accept its value before entering the main loop. Thus, any status certificate 풮 that 퐿1 can construct will contain at least one status message vouching for the designated sender’s value 푣푠. There will not be a status message vouching for another legally accepted value. Thus, 푣푠 is the only value that can be proposed in iteration 1 (define “pre-round” to have iteration number 0). Following an inductive proof similar to

Theorem 4.3, no value other than 푣푠 can have a certificate or be proposed in any iteration, satisfying validity. On the contrary, if 퐿푠 is Byzantine, then it is up to future leaders to pick (or propose) a value for the replicas to agree on.

55 Termination and round complexity. As with the core synod protocol, the first honest leader in the main loop will ensure termination. The random leader election process piggybacks on the proposal, so it does not increase the round complexity. There is a (푓 + 1)/(2푓 + 1) > 1/2 probability that each leader after the first iteration is honest, so the protocol terminates in expected 2 iterations after the pre-round, i.e., 9 rounds in expectation. Since honest replicas terminate without waiting for the notify messages in the last iteration, the expected latency of the protocol (from when the protocol starts to when all honest parties commit) is 8 rounds.

From Byzantine broadcast to Byzantine agreement. To solve Byzantine agreement, we can use the classic transformation [126, 100] discussed in Section 2.1. After the first iteration, we can elect a single leader for all the parallel broadcast instances. Thus, the agreement protocol will have the same round complexity as the broadcast protocol.

4.4 Byzantine Fault Tolerant State Machine Replication

In this section, we show how to extend the core protocol to achieve state machine replication, i.e., to reach consensus on a sequence of values and their order. We say each value in the sequence occupies a slot. We start with a basic protocol, which extends the synod protocol with minimum modifications and requires amortized 2 iterations (8 rounds) per slot. We then present animproved protocol that achieves 1 iteration (3 rounds) per slot in the common case (under a stable leader) at the cost of a more expensive view (leader) change procedure.

4.4.1 Warm-up: A Basic Protocol

The basic protocol essentially runs a series of synod instances sequentially. To start, the following modifications are natural.

1. Each replica 푖 internally maintains an additional long-term state 푠푖 to denote which slot it is

currently working on. 푠푖 = 푠 means replica 푖 has committed for slots {1, 2, ··· , 푠 − 1}, and has not committed for slots 푠, 푠 + 1, 푠 + 2, ··· .

2. All messages in Section 4.2.2 and Table 4.2.2 contain an additional slot number 푠. The

four types of messages now have the form: ⟨⟨푠, 푘, status, 푣푖, 푘푖⟩푖 , 풞푖⟩푖, ⟨⟨푠, 푘, propose, 푣⟩퐿 , 풮⟩퐿,

56 ⟨푠, 푘, commit, 푣⟩푖, and ⟨⟨푠, 푘, notify, 푣⟩푖 , 풞⟩푖.A commit certificate 풞 now certifies a triplet (푠, 푣, 푘) and must contain 푓 + 1 commit requests (could be virtual) for the same slot 푠. Similarly, a status certificate 풮 must now contain 푓 + 1 status summaries (could be virtual) for the same slot 푠.

Replica 푖 follows the protocol in Section 4.2.2 to send and react to messages for the slot 푠푖 it is currently working on. If replica 푖 receives messages for a past slot 푠 < 푠푖, it can safely ignore them because its virtual messages (notify messages) for slot 푠 will suffice to help any honest replicas terminate for that slot. The more interesting question is how to react to messages for future slots. We observe that it is vital that all honest replicas accept values for future slots upon receiving valid notify messages. If the sender of the notify message is an honest replica, then all other honest replicas must accept that value to prevent any other value from being proposed for that slot. However, apart from notify messages, honest replicas can ignore all other messages for future slots without violating safety. The proof for safety from Section 4.2.3 still holds since it only relies on honest replicas not sending improper messages. This implies the following changes:

3. The accepted states of a replica 푖 are now per slot: accepted푖[푠] = (푣푖[푠], 푘푖[푠], 풞푖[푠]). Upon receiving a valid notify message ⟨⟨푠, 푘, notify, 푣⟩ , 풞⟩ for a future slot 푠 > 푠 , replica 푖 sets 푗 푗 푖

accepted푖[푠] := (푣, 푘, 풞). Replica 푖 ignores messages other than notify for future slots.

We next analyze the round complexity of the above protocol. Note that now an honest leader may not be able to ensure termination for the slot it is working on because some honest replicas may be lagging behind. They may not react to its proposal; in fact, the leader may not even gather enough status messages to construct a valid proposal. However, each honest leader can still guarantee termination for at least one slot: the lowest numbered slot 푠* that any honest replica is working on. After this iteration, all honest replicas will at least be working on slot 푠* + 1. Therefore, if we simply rotate the leader in a round robin fashion, we can fill at least 푓 + 1 slots in a full rotation of 2푓 + 1 iterations, thereby achieving amortized 2 iterations (8 rounds) per slot.

Reply to clients. In our protocol, a single replica’s notify message is insufficient to convince a client that a value is committed. The reason is that a Byzantine replica may not send notify message to all other replicas, in which case a different value may be committed later. Instead, a client needs to see 푓 + 1 notify messages (summaries suffice) from distinct replicas to be confident of a committed

57 value. When 푛 is large, it may be costly for a client to maintain connections to all 푛 replicas. An alternative solution is to let a replica gather 푓 + 1 notify summaries at the end of Round 3, and send them to a client in a single message. We call these 푓 + 1 notify summaries a notify certificate 풩 .A client can be assured of a committed value by receiving 풩 from a single replica at the cost of one extra round of latency.

4.4.2 Towards Stable Leaders

The previous protocol replaces the leader after every iteration. This is not ideal since faulty leaders may prevent progress in their iterations. As a result, the previous protocol may only make progress every one out of two iterations on average. A better design, which is common in PBFT-style protocols, is to keep a stable leader in charge and replace the leader only if it is detected to be faulty. This way, once an honest leader is in control, a slot can be committed after every iteration. Following PBFT’s terminology, we say a protocol proceeds in a series of views. Each view has a unique leader and we again rotate the leader in a round robin fashion. A view can last many iterations, potentially indefinitely as long as the leader keeps making progress. Suppose thecurrent view is view 푙 and its leader is 퐿푙. (Note that 퐿푙 has been redefined to be the leader of a view as against an iteration.) At a high level, if an honest replica 푖 detects that 퐿푙 is faulty, it broadcasts a

⟨view-change, 푙 + 1⟩푖 message, which can be thought of as an accusation against 퐿푙. If the next leader

퐿푙+1 gathers 푓 + 1 ⟨view-change, 푙 + 1⟩푖 messages from distinct replicas, it broadcasts a new-view message to become the new leader and the system enters view 푙 + 1. Though the above idea seems simple and similar to PBFT at a high level, the details involved are quite intricate. First, note that a faulty leader can always cause honest replicas to disagree on whether or not it is faulty. To do so, the faulty leader and all Byzantine replicas simply behave normally to some honest replicas (call them group 1) and remain silent to other honest replicas (call them group 2). In this case, replicas in group 2 will accuse the leader, but they cannot convince group 1 because, from group 1’s perspective, it is entirely possible that replicas in group 2 are malicious and are falsely accusing an innocent leader. Fortunately, we can still ensure progress by utilizing the following property of our synod protocol: If 퐿푙 is honest, then a replica expects to not only to commit but also receive at least 푓 + 1 notify messages from distinct replicas (including itself) at the end of Round 3 of each iteration. These 푓 + 1 notify messages form a notify certificate 풩 and convince any other

58 replica to commit. If replica 푖 does not receive 푓 + 1 notify messages at the end of Round 3, then it knows the current leader is faulty and broadcasts view-change. Therefore, after each iteration, either some honest replica obtains the ability to convince other replicas to commit, or all honest replica accuse the current leader and the next leader can start a new view. However, to complicate the matter, the new leader may also be Byzantine. It may not send new-view when it is supposed to, or send it only to a subset of honest replicas. We need to ensure such behaviors do not violate safety or liveness. Here, the increased fault threshold 푓 < 푛/2 again creates challenges. In particular, two views in PBFT cannot make progress concurrently: 푓 + 1 honest replicas need to enter the new view to make progress there, leaving not enough replicas for a quorum in the old view. In contrast, with a quorum size of 푓 + 1 and 푛 = 2푓 + 1 in our protocol, if a single honest replica is left behind in the old view, the 푓 Byzantine replicas can exploit it to form a quorum. Thus, for safety, our view-change procedure needs to ensure that two honest replicas are never in different views. Concretely, our view-change procedure guarantees the following: ifan honest replica enters view 푙 + 1, then all other honest replicas exit view 푙 — they may not enter view 푙 + 1, which means they temporarily may not be in any view. To guarantee liveness, these “out-of-view” replicas must eventually enter a future view. Meanwhile, we also need to ensure that an honest replica will not be tricked into accusing an honest future leader. Thus, before accusing

퐿푙+1, an honest replica 푖 sends the 푓 + 1 view-change messages (a view-change certificate) to 퐿푙+1; if

퐿푙+1 still does not step up in the round after, then replica 푖 can be certain that 퐿푙+1 is faulty. The remainder of this section presents in detail the protocol with stable leaders, prove its safety and liveness, and analyzes its complexity. The protocol now distinguishes the common case (with a stable leader) and the view-change procedure (to replace the leader). The common case consists of the propose round, the commit round and a “lightweight” notify round in iterations. The status round and the full notify round will be pushed to the view-change procedure. Concurrent to the common case and view changes, each replica additionally runs a checkpoint procedure and a leader monitoring procedure.

4.4.3 Common Case

Suppose an honest replica 푖 is currently in view 푙 and is working on slot 푠, and the current iteration is 푘.

59 Round 1 (propose) Same as before, except that for slots that have not been worked on in prior views, the leader does not need to include status certificates (see view-change).

Round 2 (commit) Same as before.

Round 3 (notify-light) If replica 푖 has committed on 푣 at the end of Round 2, it broadcasts a

notification summary ⟨푠, 푘, notify, 푣⟩푖.

At the end of this round, if replica 푖 receives 푓 + 1 valid ⟨푠, 푘, notify, 푣⟩푗 summaries for the same 푣, it concatenates them to form a notify certificate 풩 ; otherwise, it locally marks the

current leader 퐿푙 as faulty.

A single notify-light message does not make a replica accept a committed value since it does not contain a commit certificate 풞. But 푓 + 1 of them, forming a notify certificate 풩 , prove the correctness of the committed value to other replicas or to external clients. As in Section 4.4.1, a client can be convinced about a committed decision if it receives 푓 + 1 notify summaries at the end of Round 3, or wait for one extra round to avoid talking to 푓 + 1 replicas.

Checkpoint. Before presenting the view-change procedure, we need to introduce checkpoints. We say slot 푠 is a stable checkpoint for replica 푖, if replica 푖 knows for sure that every honest replica has committed for slot 푠. An easy way to create a stable checkpoint is to broadcast a valid notify certificate 풩 (obtained in Round 3) to every replica. If another replica receives a valid 풩 for slot 푠, it can safely commit and move on to the next slot. Thus, if replica 푖 broadcasts 풩 for slot 푠, then it knows for sure every other honest replica will commit for slot 푠 at the end of that round, and slot 푠 now becomes a stable checkpoint for replica 푖. This requires a round of all-to-all communication per slot, but following PBFT, we can create a checkpoint for a batch of slots to amortize the cost of checkpointing. This involves every replica broadcasting a notify-light message and then a notify certificate 풩 for a digest of a slot batch, e.g., of size 푐 = 100. If a scheduled checkpoint does not become stable in time, a replica accuses the leader.

60 4.4.4 View Change

The view-change procedure is initiated by the new leader 퐿푙+1 once it obtains a view-change certificate ′ 풱, i.e., 푓 + 1 ⟨view-change, 푙 + 1⟩푖 messages from distinct replicas. We henceforth write 퐿푙+1 as 퐿 for short.

′ ′ ′ Round VC1 퐿 broadcasts a ⟨new-view, 푙 + 1, 풱, 푠 , 풩 ⟩퐿′ message. 푠 is the last stable checkpoint known to 퐿′, and 풩 is a proof for that checkpoint.

At the end of this round, if replica 푖 receives a valid new-view message, it exits view 푙 and sets

enter푖 := true. The enter푖 variable will decide if replica 푖 enters view 푙 + 1 at the end of the view-change procedure.

Round VC2 If enter푖 = true, replica 푖 forwards the new-view message it receives in Round VC1 to every other replica.

At the end of this round, if replica 푖 is forwarded a valid new-view message but did not directly receive one from 퐿′ in the previous round, or if replica 푖 detects equivocation about 푠′ by 퐿′, ′ then replica 푖 exits view 푙, sets enter푖 := false, and marks 퐿 as faulty.

Round VC3 (notify) For every committed slot since the last stable checkpoint, replica 푖 broadcasts the full notify message, which includes the corresponding 풞.

At the end of this round, for every uncommitted slot, if replica 푖 receives a valid notify message for that slot, it accepts the value in the notify message.

Round VC4 (status) Let 푇 be the largest slot that replica 푖 has committed or has accepted a value. For every slot since the last stable checkpoint up to 푇 , replica 푖 sends a status message, which includes the corresponding 풞, to the new leader 퐿′. Replica 푖 also sends 퐿′ a

⟨푇, 푙 + 1, status-max⟩푖 message, indicating that it has not committed or accepted any value for any slot numbered greater than 푇 . 퐿′ will use these status-max messages to prove that certain slots have not been worked on in prior views.

At the end of this round, if enter푖 = true, then replica 푖 increments its view number 푙 and enters the new view. From the next round, replica 푖 returns to the common case and works on ′ slot 푠 + 1. If enter푖 = false, replica 푖 increments 푙 but does not enter the new view.

61 It is crucial to note that we distinguish “having a view number 푙” and “being in view 푙”. A replica only enters a new view (and stay in that view) upon receiving a new-view message directly from the new leader. A forwarded new-view message will only make a replica exit its current view, but not enter the new view. This ensures the following.

Lemma 4.6. Honest replicas will not be in different views.

Proof. If an honest replica ℎ1 is in view 푙, according to the protocol, it must have received a valid new-view message from 퐿푙. Then, it must have forwarded the new-view message to all other replicas. Thus, all other honest replicas must have exited view 푙 − 1 in Round VC2 of that view change.

Lemma 4.6 states that honest replicas will never be in different views. But some honest replicas may not be in any view. If a replica is not in any view, it does not participate in the common case. In particular, it ignores any proposal and does not send any commit request or notify summary.

Leader monitoring. In the view-change procedure, if replica 푖 is forwarded a new-view message but does not directly receive one from 퐿′, it knows 퐿′ is faulty. Another situation where replica 푖 detects 퐿′ as faulty is when replica 푖 has sent 풱 to 퐿′ but 퐿′ does not initiate a view change. In both cases, replica 푖 will skip 퐿′ and wait for the next view change. In more detail, replica 푖 keeps monitoring its current leader 퐿푙 and future leaders as follows.

– At the beginning of any round, if replica 푖 has marked 퐿푙 faulty, it broadcasts a

⟨view-change, 푙 + 1⟩푖 message.

– At the end of any round, if replica 푖 has gathered 푓 + 1 ⟨view-change, 푙 + 1⟩푗 messages, it concatenates them to form a view-change certificate 풱 (else 풱 := ⊥).

– At the beginning of any round, if a replica 푖 has 풱= ̸ ⊥, it sends 풱 to the next leader 퐿′.

– At the end of any round, if replica 푖 has sent 풱 to 퐿′ in the previous round but does not receive a new-view message from 퐿′ in this round, then replica 푖 marks 퐿′ as faulty and increments the view number 푙.

We remark that we have only pointed out the necessary conditions for an honest replica to accuse a faulty leader. Honest replicas may detect a faulty leader through other means (e.g., equivocation

62 and invalid messages). They can accuse the leader in those situations as well, but safety and liveness of the protocol do not depend on those accusations.

4.4.5 Safety and Liveness

The proof for safety remains largely unchanged from Section 4.2.3 except for a small modification to the base case.

Lemma 4.7 (Lemma 4.1 restated with slots). Suppose replica ℎ is the first honest replica to commit for slot 푠 and it commits on 푣* in iteration 푘*. If a certificate 풞 for (푠, 푣, 푘*) is valid, then 푣 = 푣*.

Proof. An honest replica ℎ1 must have sent a commit request for 푣. Replica ℎ1 must then be in some view; otherwise, it would not have participated in the commit round at all. Due to Lemma 4.6, replica ℎ1 must be in the same view as replica ℎ. Thus, ℎ1 must have detected leader equivocation and would not have committed.

Lemma 4.8 (Lemma 4.2 restated with slots). Suppose replica ℎ is the first honest replica to commit for slot 푠 and it commits on 푣* in iteration 푘*. If a certificate 풞 for (푠, 푣, 푘) where 푘 ≥ 푘* is valid, then 푣 = 푣*.

Theorem 4.9 (Safety restated with slots). If two honest replicas commit on 푣 and 푣′ respectively for slot 푠, then 푣 = 푣′.

Proof of Lemma 4.8 and Theorem 4.9 remain unchanged from Lemma 4.2 and Theorem 4.3 other than considering slots. We do not repeat them.

Theorem 4.10 (Liveness). The protocol commits 푠 slots in at most 3푠 + 푂(푐푓) rounds, where 푐 is the checkpoint batch size.

Proof. The proof observes two crucial properties of the protocol: (1) an honest leader will not lose its leader role, and (2) each Byzantine leader can prevent progress for at most 푂(푐) rounds. The theorem then follows from the above properties. Once an honest leader takes control, it will not be replaced and a new slot is committed in its view every iteration (3 rounds) in its view in the common case. For part (1), it suffices to show that an honest replica will not accuse an honest leader. Inthe protocol, there are two situations in which a replica accuses a leader: not stepping up for its view

63 and not making progress in its view. Neither will happen to an honest leader. Before accusing a future leader of not stepping up, an honest replica will send a view-change certificate to the leader. At this point, an honest leader will broadcast new-view and make all honest replicas enter its view. Once all honest replicas enter its view, they will all make progress, receive 푓 + 1 notify summaries, and move to the next slot after every iteration. For part (2), we first show that the last stable checkpoints of any two honest replicas can atmost be off by 1 (i.e., 푐 slots apart). Let 푠푖 be the last stable checkpoint known to replica 푖. Suppose for contradiction that two honest replicas 푖 and 푗 have 푠푖 > 푠푗 + 2푐. This means at checkpoint 푠푗 + 푐, no honest replica has broadcast 풩 . Then, all honest replicas should have accused the leader and replica

푖 should not have advanced to slot 푠푖 > 푠푗 + 2푐, a contradiction. Therefore, a Byzantine leader can disrupt progress by at most 푐 iterations when its view begins (by starting from a checkpoint 푐 slots behind), and waste another 푐 iterations (by leading the common case normally until the next checkpoint) before getting accused and replaced.

The liveness theorem also illustrates that the checkpoint batch size 푐 is a trade-off between common case efficiency and worst-case efficiency. Alarger 푐 allows Byzantine leaders/replicas to prevent progress for longer with some carefully planned malicious actions; but in the best case where there is no such malicious behavior, a larger 푐 means less frequent checkpoints and hence less work in the common case.

4.4.6 Message Complexity

After pushing the status round and the full notify to the view-change procedure, our protocol has a very similar complexity to the Practical Byzantine Fault Tolerance (PBFT) protocol. Like PBFT, in the common case (i.e., under a stable leader), our protocol has three rounds, and two of them involve all-to-all communication of 푂(1)-sized messages. Θ(푛)-sized messages are needed only for view changes and checkpointing, and they can be reduced to 푂(1) using BLS aggregate signatures [35, 34] as discussed in Section 3.3.5. System-level optimizations like parallel slots and garbage collection can also be added. It is worth noting that we require digital signatures even in the common case, whereas PBFT uses digital signatures only for view changes [41]. This was a major contribution of PBFT two decades ago as digital signatures were very slow back then. But with computation becoming cheaper and the

64 development of more efficient signature schemes86 [ , 25, 35, 34], we believe the use of signatures is less of a concern today.

4.4.7 Comparison with Prior Work

To the best of our knowledge, the only work on state machine replication that considers the exact same setting as ours (Byzantine faults, 푛 ≥ 2푓 + 1, synchrony, digital signatures and no trusted component) is XFT [105]. We remark that the main goal of XFT is to tolerate either Byzantine faults under synchrony or crash faults under asynchrony, but we can still compare to its synchronous Byzantine version. Relying on an active group of 푓 + 1 honest replicas to make progress, XFT is very efficient for small 푛 and 푓 (e.g., 푓 = 1). But its performance degrades as 푛 and 푓 increase, 푛−1 (︀ 푛 )︀ especially when the number of faults 푓 approaches the ⌊ 2 ⌋ limit. In that case, among the 푓+1 groups in total, only one is all-honest. The XFT paper [105] mentions the simple scheme of trying out all groups, and also acknowledges that this simple scheme does not scale with 푛 and 푓 as it would require a super-exponential number of trials to find the only all-honest group. The XFT paper briefly mentions the idea of selecting the group members (also called followers) using a verifiable pseudorandom function. We do not see why this idea might lead to improvements, as it also seems to require a super-exponential number of trials. The best XFT variant we can think of requires a quadratic number of trials to find the all-honest group, and we describe it below. The following description assumes the reader is familiar with the XFT protocol and terminology. We will rotate the leader of the active group in a round robin fashion, and let the leader pick its own 푓 followers. Furthermore, we give each leader 푓 + 1 views, i.e., let it re-pick its followers 푓 times before replacing the leader. We refer to all views under a leader as that leader’s reign. If a leader is honest, in each view during its reign, it either makes progress (if all followers respond to its proposal correctly) or it detects at least one faulty follower that does not respond correctly. In the latter case, the leader can locally mark that follower as faulty and replaces it with a new replica that has not been marked faulty. During an honest leader’s reign, there can be at most 푓 views without progress. After that, the leader should have locally detected all 푓 faulty replicas and found the all-honest active group. Thus, if there have been 푓 + 1 views without progress during a leader’s reign, the leader must be faulty and should be replaced. Each faulty leader can cause at most 푓 + 1 view changes, and the 푓 Byzantine replicas combined can cause at most (푓 + 1)푓 = 푂(푛2) view changes.

65 66 Chapter 5

Proof-of-Space from Stacked Expanders

We have seen in previous chapters how proof-of-work (PoW) plays a central role in defeating Sybil attacks in permissionless consensus protocols. However, the use of PoW also raises concerns about fairness and energy consumption. The rest of this thesis studies alternatives to PoW to alleviate these issues. This chapter presents a proof-of-space protocol. The next chapter will be dedicated to ASIC resistance.

5.1 Introduction

Dwork and Naor proposed proof-of-work (PoW) [61] as a countermeasure to spam and denial-of- service attacks. More recently, PoW has seen wide adoption in permissionless cryptocurrencies, following the blueprint of Bitcoin [114]. But a few drawbacks of PoW have since surfaced. The first issue involves fairness of mining equipment. Driven by immense economic incentives, Bitcoin miners soon realized that Application Specific Integrated Circuits (ASICs) can compute (SHA-256) hashes orders of magnitude faster and more efficiently than commodity CPUs/GPUs. At the timeof writing, AntMiner S9, a state-of-the-art ASIC Bitcoin miner, computes 13 trillion SHA-256 hashes per second at about 0.1 nJ energy cost per hash. This is roughly 200,000× faster and 40,000× more energy efficiently than a state-of-the-art multi-core CPU. The concentration of mining power to ASIC-equipped miners compromises the egalitarian vision of one-CPU-one-vote laid out in the original Bitcoin paper [114], and calls into question its decentralization promise. Another concern is Bitcoin’s massive energy consumption. In August 2018, it is estimated that the Bitcoin network

67 consumes about 70TWh (trillion Watt-hour) of electricity per year [53], which is comparable to Austria, the 39th largest country by electricity consumption [147]. A number of alternatives have been suggested in response to the fairness and energy consumption issues. A first idea that comes to mind is to design functions or PoW schemes to be “ASIC-resistant”, schemes that limit ASICs’ advantages over CPUs. Note that an ASIC-resistant PoW is still a PoW scheme. Thus, it only addresses the fairness issue and does not attempt to reduce energy consumption. In order to address the energy consumption problem, some proposals suggest moving away from PoW. The most sought-after framework is proof-of-stake (PoStake). If we again think of PoW as a Sybil-proof leader election oracle based on physical resource (computation) expenditure, then the idea behind PoStake is instead to elect leaders based on virtual resources, such as how many coins one holds. The earliest document on PoStake to my knowledge is King and Nadal [91]. It has since been adopted or considered by a number of other proposals [24, 90, 50, 111, 77, 38]. There also exist “proof-of-X” proposals based on other virtual resources. This thesis will not study PoStake schemes or its variants. Another alternative is proof-of-space (PoSpace), first introduced by Dziembowski et63 al.[ ]. PoSpace still follows the paradigm of physical resource expenditure but the resource involved is storage as opposed to computation. Analogous to a PoW, a PoSpace is a piece of data that requires a significant amount of memory or disk space to generate, but can be verified with a small amountof space and time. Since PoSpace aims at saving energy, generating a PoSpace is supposed to consume little computation effort for a party that faithfully stores the specified data. A cryptocurrency based on PoSpace is projected to spend a tiny fraction of energy of the Bitcoin network since storing data does not actively consume energy [119]. Meanwhile, since storage is inherently general purpose, PoSpace will not be affected by ASICs. This chapter presents a PoSpace protocol based on a type of graph called stacked expanders. The new construction is conceptually simpler, and has better efficiency or tighter security guarantees than prior works [63]. Along the way, I improve a classic pebbling lower bound on stacked expanders by Paul and Tarjan [124].

68 5.2 Preliminaries

5.2.1 Proof-of-Space

′ Definition 5.1 (PoSpace). Let 푘 be a security parameter, 푁 be the space requirement, 푁0 and ′ 푁1 be two space lower bound parameters. A PoSpace protocol is a pair of interactive protocols

(퐶, 푦) ← ⟨V0, P0⟩ and {0, 1} ← ⟨V1(퐶), P1(푦)⟩ that have the following properties:

(succinctness) all messages between P and V have size poly(푘, log 푁),

(efficient verifiability) V0 and V1 use poly(푘, log 푁) space and time,

(completeness) P0 and P1 satisfy the following

– P0 uses 푁 space, runs in poly(푘, 푁) time, and outputs 푦 of size 푁,

′ – P1 uses 푁 space, runs in poly(푘, log 푁) time, and ⟨V1(퐶), P1(푦 )⟩ = 1,

(space-hardness) there do not exist A0 and A1 such that

′ ′ ′ – A0 uses poly(푘, 푁) space, runs in poly(푘, 푁) time, and ⟨V0, A0⟩ = (퐶, 푦 ) where |푦 | < 푁0,

′ ′ 푘 ′ – A1 takes 푦 as input, uses 푁1 space, runs in 2 time, and makes ⟨V1(퐶), A1(푦 )⟩ = 1 with non-negligible probability.

(퐶, 푦) ← ⟨V0, P0⟩ represents the setup stage. P0 outputs 푦 of size 푁, which is supposed to be stored persistently. P0’s output 푦 is also referred to as advice in the literature. V0 (through interaction with P0) outputs a verified commitment 퐶. {0, 1} ← ⟨V1(퐶), P1(푦)⟩ represents one audit.

Inputs of the two parties are their respective output from the setup stage. In the end, V1 either accepts or rejects. Efficiency metrics include message size, prover runtime and verifier space/runtime in bothstages of the protocol. The space-hardness definition and metric become a little tricky. Since the focus here is advicesize, ′ ′ one natural definition is to require that no polynomial adversary A1 with advice size |푦 | < 푁0 can convince V with non-negligible probability. Unfortunately, the ideal space-hardness is not achievable.

In the setup phase, an adversary can output the entire communication transcript with V0 as the cheating advice 푦′. Due to succinctness, the transcript size |푦′| = poly(푘, log 푁) is much smaller than

69 ′ any reasonable 푁0. In an audit, the adversary can rerun P0 by simulating V0 using the recorded ′ transcript 푦 , obtain the advice 푦 that an honest P0 would have produced, and then go on to run an honest P1 to pass the audit. Given the impossibility of ideal space-hardness, Dziembowski et al. [63] proposed two alternative definitions. The first one requires A1 to use 푂(푁) space. The second one requires A1 to use 푂(푁) runtime, We adopt their first definition, which is the stronger than the second one because 푂(푁) space implies 푂(푁) runtime. Under this space-hardness definition, if a cheating prover discards ′ ′ part of the advice, it will find itself repeatedly refilling that space it attempts to save.If (푁0, 푁1) are close to (푁, 푁) and audits are fairly frequent, a rational prover will choose to store the advice faithfully.

5.2.2 Graph Labeling and Pebbling

To construct PoSpace protocols, we adopt the graph labeling framework following Dziembowski et al. [63]. Graph labeling is a computational problem that evaluates a random oracle ℋ in a directed acyclic graph (DAG) 퐺. A vertex with no incoming edges is called a source and a vertex with no outgoing edges is called a sink. Vertices in 퐺 are numbered, and each vertex 푣푖 is associated with a label 푙(푣푖), computed as:

⎧ ⎨⎪ℋ(푖, 푥) if 푣푖 is a source 푙(푣푖) = ⎪ ⎩ℋ(푖, 푙(푢1), ··· , 푙(푢푑)) otherwise, 푢1 to 푢푑 are 푣푖’s predecessors

The output of the graph labeling problem are the labels of the sinks. Graph labeling is often abstracted as a pebble game, also known as graph pebbling. Graph pebbling is a powerful tool in computer science, dating back at least to 1970s in studying Turing machines [46, 80] and register allocation [140]. More recently, graph pebbling has found applications in various areas of cryptography [62, 64, 141, 108, 73, 17, 63, 33]. A pebble game is a single-player game where the player’s goal is to put pebbles on the sinks of a DAG 퐺 using a sequence of moves. Placing a pebble on vertex 푣 represents computing 푙(푣). There exist several variants of pebble games. The simplest one, which suffices to study PoSpace, is the black pebble game where there is only one type of pebbles. In each move, the player can place one pebble and remove an arbitrary number of pebbles (removing pebbles is free). The player’s

70 moves can be represented as a sequence of transitions between pebble placement configurations on the DAG, P = (푃0, 푃1, 푃2 ··· , 푃푇 ). If a pebble exists on a vertex 푣 in a configuration 푃푖, we say 푣 is pebbled in 푃푖. The starting configuration 푃0 usually is but does not have to be empty (vertices may be pebbled in 푃0). The black pebble game rule is as follows: to transition from 푃푖 to 푃푖+1, the player can pebble (i.e., place a pebble on) one vertex 푣 if 푣 is a source or if all predecessors of 푣 are pebbled in 푃푖, and then unpebble (i.e., remove pebbles from) any subset of vertices. We say a sequence P pebbles a vertex 푣 if there exists 푃푖 ∈ P such that 푣 is pebbled in 푃푖. We say a sequence P pebbles a set of vertices if P pebbles every vertex in the set. Black pebble games aim to capture the space and time complexity. Consider a pebble sequence

P = (푃0, 푃1, 푃2 ··· , 푃푇 ). Let |푃푖| be the number of pebbles on the graph in configuration 푃푖. The space complexity 푆(P) of a pebbling sequence is defined to be max푖(|푃푖|), i.e., the maximum number of pebbles on the graph at any step. The time complexity 푇 (P) of a pebbling sequence is defined to be the number of transitions in P. Clearly, a legal black pebbling sequence gives a graph labeling algorithm using the same amount of space. The reverse has also been shown to hold for data-independent graphs via a now standard “ex post facto” argument [62, 64, 13]. A reduction has not been shown for PoSpace but there has been recent progress in this direction [10].

5.2.3 Bipartite and Stacked Expanders

Definition 5.2. An (푛, 훼, 훽) bipartite expander (0 < 훼 < 훽 < 1) is a directed bipartite graph with 푛 sources and 푛 sinks such that any subset of 훼푛 sinks are connected to at least 훽푛 sources.

Prior work has shown that bipartite expanders for any 0 < 훼 < 훽 < 1 exist given sufficiently many edges. We adopt the randomized construction by Chung [45], which gives a 푑-regular bipartite graph, i.e., there are 푑 outgoing edges from each source and 푑 incoming edges to each sink. It simply connects the 푑푛 outgoing edges of the sources and the 푑푛 incoming edges of the sinks according to a random permutation. Given a permutation Π on {0, 1, 2, ··· , 푑푛 − 1}, if Π(푖) = 푗, add an edge from source (푖 mod 푛) to sink (푗 mod 푛).

Theorem 5.3. Chung’s construction yields an (푛, 훼, 훽) bipartite expander (0 < 훼 < 훽 < 1) for sufficiently large 푛 with overwhelming probability if

Hb(훼) + Hb(훽) 푑 > 훼 Hb(훼) − 훽Hb( 훽 )

71 where Hb(훼) = −훼 log2 훼 − (1 − 훼) log2(1 − 훼) is the binary entropy function.

The theorem has been proven by Bassalygo [19] and Schöning [139], but both proofs were quite involved. We give a proof using a simple counting argument.

Proof. There are (푑푛)! permutations in total. We analyze how many permutations are “bad”, i.e., do not yield an expander. A bad permutation must connect some subset 푈 of 훼푛 sinks to a subset 푉 of (︀ 푛 )︀(︀ 푛 )︀ (︀푑훽푛)︀ 훽푛 sources. There are 훼푛 훽푛 combinations. Within each combination, there are 푑훼푛 (푑훼푛)! ways to connect 푈 to 푉 . There are (푑푛 − 푑훼푛)! ways to connect the rest of edges (those not incident to 푈). The probability that we hit a bad permutation is

(︂ 푛 )︂(︂ 푛 )︂(︂푑훽푛)︂ Pr(Π is bad) = (푑훼푛)!(푑푛 − 푑훼푛)!/(푑푛)! 훼푛 훽푛 푑훼푛 (︂ 푛 )︂(︂ 푛 )︂(︂푑훽푛)︂ (︂ 푑푛 )︂ = / 훼푛 훽푛 푑훼푛 푑훼푛

√ 1 Using Robbins’ inequality for Stirling’s approximation 2휋푛(푛/푒)푛푒 12푛+1 < 푛! < √ 1 푛 푛 12푛 (︀ )︀ 1 2휋푛(푛/푒) 푒 [135], we have log2 훼푛 = 푛Hb(훼) − 2 log2 푛 + 표(1). Thus,

log2 Pr(Π is bad) = 푛[Hb(훼) + Hb(훽) + 푑훽Hb(훼/훽) − 푑Hb(훼)] − log2 푛 + 표(1).

If Hb(훼) + Hb(훽) + 푑훽Hb(훼/훽) − 푑Hb(훼) < 0, or equivalently the bound on 푑 in the theorem statement holds, then Pr(Π is bad) decreases exponentially as 푛 increases.

Pinsker [131] used a different randomized construction, which independently selects 푑 predecessors for each sink. Pinsker’s construction requires 푑 > Hb(훼)+Hb(훽) [33], which is a slightly worse bound −훼 log2 훽 than Theorem 5.3. But Pinsker’s construction is arguably simpler than Chung’s because it only needs a random function as opposed to a random permutation. A large in-degree can be problematic for the pebbling abstraction since the random oracle in graph labeling cannot be based on a Merkle-Damgård construction [33]. In the case of stacked expanders, we can apply a transformation to make the in-degree two and preserve the expanding property: simply replace each 푑-to-1 connection with a binary tree where the 푑 predecessors are at the leaf level, the successor is the root and each edge in the tree points from a child to its parent. This means the in-degree of the original expander has a linear contribution to runtime.

72 Definition 5.4. A (푛, 푘, 훼, 훽) stacked expander is constructed by stacking 푘 copies of (푛, 훼, 훽) bipartite expanders back to back. A (푛, 푘, 훼, 훽) stacked expander has 푛(푘 + 1) vertices, partitioned into 푘 + 1 sets each of size 푛, 푉 = {푉0, 푉1, 푉2, ··· , 푉푘}. All edges in go from 푉푖−1 to 푉푖 for some

푖 from 1 to 푘. For each 푖 from 1 to 푘, 푉푖−1 and 푉푖 plus all edges between them form an (푛, 훼, 훽) bipartite expander.

Let 퐺(푛,푘,훼,훽) be a (푛, 푘, 훼, 훽) stacked expander. 퐺(푛,푘,훼,훽) has 푛 sources, 푛 sinks, and the same maximum in-degree as the underlying (푛, 훼, 훽) bipartite expanders. The bipartite expanders at 1 1 different layers can, but do not have to, be the same. Figure 5-1 is anexampleof (4, 4, 4 , 2 ) stacked expander with in-degree 2.

푣0,1 푣1,1 푣2,1 푣3,1 푣4,1

푣0,2 푣1,2 푣2,2 푣3,2 푣4,2

푣0,3 푣1,3 푣2,3 푣3,3 푣4,3

푣0,4 푣1,4 푣2,4 푣3,4 푣4,4

푉0 푉1 푉2 푉3 푉4

1 1 Figure 5-1: A (4, 4, 4 , 2 ) stacked expander.

5.3 Pebble Games on Stacked Expanders

The space-hardness of our construction relies on pebbling lower bounds on stacked expanders. Paul and Tarjan [124] showed that 퐺 1 1 has an exponentially sharp space-time trade-off. Generalized (푛,푘, 8 , 2 ) to (푛, 훼, 훽) expanders, their result was the following:

Theorem 5.5 (Paul and Tarjan [124]). If P pebbles any subset of 2훼푛 sinks of 퐺(푛,푘,훼,훽), starting 훽 푘 with |푃0| ≤ 훼푛 and using 푆(P) ≤ 훼푛 space, then 푇 (P) ≥ ⌊ 2훼 ⌋ . We could base our PoSpace protocol on it, but the space-hardness guarantee we get will be at 훽 most 푛/4: we need 2훼 ≥ 2 to get an exponential time penalty, so 훼푛 < 훽푛/4 < 푛/4. Through a more careful analysis, we show a tighter space-time trade-off for stacked bipartite expanders by considering only initially unpebbled sinks. Let 훾 = 훽 − 2훼 > 0 for the rest of the chapter.

73 Theorem 5.6. If P pebbles any subset of 훼푛 initially unpebbled sinks of 퐺(푛,푘,훼,훽), starting with 푘 |푃0| ≤ 훾푛 and using 푆(P) ≤ 훾푛 space, then 푇 (P) ≥ 2 훼푛.

Proof. For the base case 푘 = 0, 퐺(푛,0,훼,훽) is simply a collection of 푛 isolated vertices with no edges. Each vertex is both a source and a sink. The theorem is trivially true since the 훼푛 initially unpebbled sinks have to be pebbled.

Now we show the inductive step for 푘 ≥ 1 assuming the theorem holds for 푘 − 1. In 퐺(푛,푘,훼,훽), sinks are in 푉푘. The 훼푛 to-be-pebbled sinks in 푉푘 are connected to at least 훽푛 vertices in 푉푘−1 due to the (푛, 훼, 훽) expander property. Out of these 훽푛 vertices in 푉푘−1, at least 훽푛 − 훾푛 = 2훼푛 of them are unpebbled initially in 푃0 since |푃0| ≤ 훾푛. These 2훼푛 vertices in 푉푘−1 are unpebbled sinks of

퐺(푛,푘−1,훼,훽). Divide them into two groups of 훼푛 each in the order they are pebbled in P for the first time. P can be then divided into two parts P = (P1, P2) where P1 pebbles the first group (P1 does not pebble any vertex in the second group) and P2 pebbles the second group. Due to the inductive 푘−1 hypothesis, 푇 (P1) ≥ 2 훼푛. The starting configuration of P2 is the ending configuration of P1.

At the end of P1, there are at most 훾푛 pebbles on the graph, and the second group of 훼푛 vertices 푘−1 are all unpebbled. So we can invoke the inductive hypothesis again, and have 푇 (P2) ≥ 2 훼푛. 푘 Therefore, 푇 (P) = 푇 (P1) + 푇 (P2) ≥ 2 훼푛.

Theorem 5.6 lower bounds the space complexity of any feasible pebbling strategy for stacked bipartite expanders to 훾푛, where 훾 = 훽 − 2훼. If we increase 훽 or decrease 훼, 훾 improves but the in-degree 푑 also increases due to Theorem 5.3. For each 훾, we find the 훼 and 훽 that minimize 푑, and plot it in Figure 5-2. The curves show the efficiency vs. space-hardness trade-offs. For 훾 < 0.7, 푑 is reasonably small. Beyond 훾 = 0.9, 푑 increases rapidly. We recommend parameterizing our constructions around 0.7 ≤ 훾 ≤ 0.9.

5.3.1 Localization of Expanders

Obviously, simply pebbling 퐺(푛,푘,훼,훽) layer by layer uses 푆(P) = 2푛 space and 푇 (P) = 푛(푘 + 1) moves. Theorem 5.6 shows that an adversary needs almost 푛 space. But this still leaves a gap of 2 in space-hardness. The localization technique in Balloon hash [33] addresses this gap. Consider an (푛, 훼, 훽) bipartite expander with sources 푉 = {푣1, 푣2, ··· 푣푛} and sinks 푈 = {푢1, 푢2, ··· 푢푛}. The localization transformation adds an edge (푣푖, 푢푖) for all 푖 (if it does not already exist), and then replaces each edge (푣푖, 푢푗) where 푖 < 푗 with (푢푖, 푢푗). Figure 5-3 highlights the removed and the

74 100 104 90 Chung Chung 80 Pinsker Pinsker 70 103 60 50 40 2 in−degree d 30 in−degree d 10 20 10 1 0 10 0 0.2 0.4 0.6 0.8 0.8 0.85 0.9 0.95 1 γ = β − 2α γ = β − 2α

Figure 5-2: Minimum in-degree 푑 to achieve a given 훾 = 훽 − 2훼 in expanders.

푣1 푢1 푣1 푢1

푣2 푢2 localization 푣2 푢2

푣3 푢3 푣3 푢3

푣4 푢4 푣4 푢4

푉 푈 푉 푈

Figure 5-3: Localization for a bipartite expander. added edges in red. Pictorially, it adds an edge for each horizontal source-sink pair, and replaces each “downward diagonal” edge with a corresponding “downward vertical” edge. This adds at most one incoming edge for each vertex in 푈.

Let 퐿퐺(푛,푘,훼,훽) be a stack of localized expanders, i.e., the resulting graph after localizing the bipartite expander at every layer of 퐺(푛,푘,훼,훽). 퐿퐺(푛,푘,훼,훽) can be efficiently pebbled using 푛 space, by simply pebbling each layer in order and within each layer from top to bottom. Once 푣푘,푖 is pebbled, 푣푘−1,푖 can be unpebbled because no subsequent vertices depend on it. A vertex 푣푘,푗 ∈ 푉푘 that originally depended on 푣푘−1,푖 is either already pebbled (if 푗 ≤ 푖), or has its dependency changed to 푣푘,푖 by the localization transformation. We now show Theorem 5.6 holds after localization as well. When we localize a bipartite expander, the resulting graph is no longer bipartite. The expanding property, however, is preserved under a modified definition. After localization, the graph has 푛 sources and 푛 non-sources (the original

75 sinks). Any subset 푈 ′ of 훼푛 non-sources collectively have 훽푛 sources as ancestors (푣 is an ancestor of 푢 if there is a path from 푣 to 푢). Crucially, the paths between them are vertex-disjoint outside 푈 ′. This allows us to prove the same space bound for stacked localized expanders as follows.

Lemma 5.7. Let 푈 ′ be any subset of 훼푛 sinks of an (푛, 훼, 훽) bipartite expander, and 푉 ′ be the set of sources connected to 푈 ′ (we have |푉 ′| ≥ 훽푛). After localization, there exist 훽푛 paths from 푉 ′ to 푈 ′ that are vertex-disjoint outside 푈 ′.

′ ′ Proof. After localization, vertices in 푉 fall into two categories. A vertex 푣푖 ∈ 푉 may still be an immediate predecessor to some 푢 ∈ 푈 ′, which obviously does not share any vertex outside 푈 ′ with a path starting from any 푣푗 (푗 ̸= 푖). If 푣푖 is not an immediate predecessor, then the path 푣푖 → 푢푖 → 푢 ′ must exist for some 푢 ∈ 푈 , because there was an edge (푣푖, 푢) in the original bipartite expander. Any ′ other 푣푗 ∈ 푉 (푗 ̸= 푖) is either an immediate predecessor or uses 푢푗 as the intermediate hop in its ′ path to 푈 . In either case, 푣푖 does not share any source or intermediate-hop with any other 푣푗.

Theorem 5.8. Let 훾 = 훽−2훼 > 0. If P pebbles any subset 푈 ′ of 훼푛 initially unpebbled vertices in the 푘 last layer 푉푘 of 퐿퐺(푛,푘,훼,훽), starting with |푃0| ≤ 훾푛 and using 푆(P) ≤ 훾푛 space, then 푇 (P) ≥ 2 훼푛.

Proof. The proof remains unchanged from Theorem 5.6 as long as we show that P still needs to pebble 2훼푛 initially unpebbled vertices in 푉푘−1. A path from 푣 to 푢 is “initially pebble-free”, if no vertex on the path, including 푣 and 푢, is pebbled in 푃0. Due to the pebble game rule, if a vertex ′ 푣 ∈ 푉푘−1 has an initially pebble-free path to some 푢 ∈ 푈 , then it needs to be pebbled before 푢 can be pebbled. Since 푉푘−1 and 푉푘 form a localized expander, due to Lemma 5.7, there exist at ′ ′ ′ least 훽푛 ancestors in 푉푘−1 whose paths to 푈 are vertex-disjoint outside 푈 . Since vertices in 푈 are initially unpebbled, pebbles in 푃0 can only be placed on the vertex-disjoint parts of these paths.

Therefore, each pebble can block at most one of these paths. Since |푃0| ≤ 훾푛, there must be at least ′ 훽푛 − 훾푛 = 2훼푛 vertices in 푉푘−1 that have initially pebble-free paths to 푈 , and they have to be pebbled by P.

We now have tight space bounds for pebble games on stacked localized expanders. 퐿퐺(푛,푘,훼,훽) can be efficiently pebbled with 푛 space but not with < 훾푛 space, where 훾 can be set close to 1.

76 5.4 Proof-of-Space from Stacked Expanders

We adopt the Merkle commitment framework from prior work [17, 63]. At a high level, P computes a

Merkle commitment 퐶 that commits the labels of all vertices in 퐿퐺(푛,푘,훼,훽). V checks if 퐶 is “mostly correct” by asking P to open the labels of some vertices. The opening of label 푙(푣) is the path from the root to the leaf corresponding to 푣 in the Merkle tree. We say “a vertex” instead of “the label of a vertex” for short for the remainder of the section. For example, “commit/open a vertex” means “commit/open the label of a vertex”. Computing a Merkle tree can be modeled as a black pebble game on a binary tree. A complete binary tree with 푛 leaves can be efficiently pebbled with roughly log2 푛 space (⌈log2 푛⌉ + 1 to be precise) in 푛 moves. So P0 can compute the commitment 퐶 using 푁 = 푛 + log2 푛 + 푘 ≈ 푛 space.

The strategy is as follows: pebble 푉0 using 푛 space, compute Merkle commitment 퐶0 for all vertices in 푉0 using additional log2 푛 space, discard the Merkle tree except the root, and then pebble 푉1 rewriting 푉0, compute 퐶1, discard the rest of the Merkle tree, and continue like this. Lastly, 퐶1 to

퐶푘 are committed into a single Merkle root 퐶.

After receiving 퐶, V randomly selects 푙0 vertices, and for each vertex 푣 asks P0 to open 푣, and all predecessors of 푣 if 푣 is not a source. Note that P0 did not store the entire Merkle tree but was constantly rewriting parts of it because the entire tree has size 푛푘 ≫ 푛. So P0 has to pebble the graph for a second time to reconstruct the 푙0(푑 + 1) paths/openings V0 asked for. This is a factor of 2 overhead in P’s runtime.

Given all the predecessors of 푣 (or if 푣 is a source), V0 can check if 푙(푣) is correctly computed. If any opening or 푙(푣) is incorrect, V rejects. If no error is found, then 퐶 is “mostly correct”. At the end of the setup phase, an honest P stores the labels of all sinks 푉푘 and the Merkle subtree for

푉푘 as advice. Any vertices in 푉푖 for 푖 < 푘 are no longer needed. V now can also discard 퐶 and use

퐶푘 which commits 푉푘 from this point onward. In the audit phase, V asks P to open 푙1 randomly selected sinks under 퐶푘.

Space-hardness. Space-hardness of our construction mostly follows from Theorem 5.8, though a few adjustments are needed. First, Theorem 5.8 states that any subset of 훼푛 initially unpebbled sinks are hard to pebble, but we would hope to challenge P on 푙1 ≪ 훼푛 sinks. Therefore, we need to show that a significant fraction of sinks are hard to pebble individually.

77 1 Theorem 5.9. Let 훾 = 훽 − 2훼. Starting from any initial configuration 푃0 of size |푃0| ≤ 3 훾푛, less 2 푘 than 훼푛 initially unpebbled sinks of 퐺(푛,푘,훼,훽) can be pebbled individually using 3 훾푛 space in 2 moves.

Proof. Suppose for contradiction that there are at least 훼푛 such sinks. Consider a strategy that pebbles these sinks one by one, never unpebbles 푃0, and restarts from 푃0 after pebbling each sink. 1 This strategy pebbles a subset of 훼푛 initially unpebbled sinks, starting with |푃0| < 3 훾푛 < 훾푛, using 1 2 푘 at most 3 훾푛 + 3 훾푛 = 훾푛 pebbles in at most 2 훼푛 moves. This contradicts Theorem 5.8.

1 1 1 At most 3 훾푛 pebbles may be initially pebbled in 푃0, so no more than ( 3 훾 + 훼)푛 < 2 푛 individual 2 푘 sinks can be pebbled using 3 훾푛 space in 2 moves by Theorem 5.9. With more than half of the sinks being hard to pebble individually, we can set 푙1 = 푘 where 푘 is the number of layers in the graph and also the security parameter. The probability that no hard-to-pebble sink is included in the challenge is at most 2−푘. The second adjustment to consider is that a cheating P may get an advantage because the commitment 퐶 is only verified to be “mostly correct”. We say a label 푙(푣푖) is a “fault” under 퐶 if it is not correctly computed from the input 푥 or from 푣푖’s predecessors’ labels under 퐶. A cheating prover is motivated to create faults using pseudorandom values because these are essentially free pebbles that are always available but take no space. Dziembowski et al. [63] pointed out that a fault is no more useful than a free (black) pebble because a pebble can be removed and later placed somewhere else. In other words, any sequence P that starts with |푃0| = 푠0 initial pebbles and uses ′ ′ 푓 faults and 푠 pebbles can be achieved by some sequence P that starts with |푃0| = 푠0 + 푓 initial pebbles and uses 0 fault and 푠 + 푓 pebbles. If we want to lower bound the number of faults to 훿푛 푘|푉 | −1 2 (훿 < 1) with overwhelming probability, we can set 푙0 = 훿푛 = 훿 푘 . Then, any commitment 퐶

훿푛 푙0 −푘 with 훿푛 faults passes the probabilistic checking with at most (1 − |푉 | ) < 푒 probability. ′ 1 Accounting for faults in Theorem 5.8, no computationally bounded P using 푁0 = ( 3 훾 − 훿)푛 ′ 2 1 2 advice and 푁1 = ( 3 훾 − 훿)푛 space can pass an audit. The choice of constants 3 and 3 are arbitrary. The theorem holds for any pair of constants that sum to 1. Lastly, we note that since P has to store the Merkle tree, it makes sense to use a different random oracle ℋ1 with smaller output size for the Merkle commitment. If |ℋ(·)| is reasonably larger than

|ℋ1(·)|, then the labels in the graph dominate, and the advice size is thus roughly 푛. Using the same random oracle results in an additional factor of 2 loss in space-hardness.

78 ′ prover verifier space/runtime 푁0 ′ runtime and message size 푁1 −1 2 1 1 푁 setup 3푁 3훿 푘(log2 푁) ( × − 훿) DFKP [63] 3 256×25.3 log2 푁 audit 0 푘 log 푁 ( 2 × 1 − 훿) 푁 2 3 256×25.3 log2 푁 setup 2(푑 + 1)푘푁 (푑 + 1)훿−1푘2 log 푁 ( 1 훾 − 훿)푁 This work 2 3 2 audit 0 푘 log2 푁 ( 3 훾 − 훿)푁 Table 5.1: Efficiency and space-hardness of PoSpace based on stacked expanders.

Efficiency. In the setup phase, our prover runtime is 2(푑 + 1)푁푘, where 2 is due to pebbling the graph twice and 푑 + 1 is due to the in-degree of our graph plus hashing in the Merkle tree. Message −1 2 size includes Merkle openings for the 푙0 = 훿 푘 challenges and their predecessors. V has to check all these Merkle openings, so its space/time complexities are the same as the message size. In the audit phase, P sends Merkle openings for 푘 sinks to V.

Comparison. We compare with the Dziembowski et al. [63] (DFKP) construction [63] based on recursively stacked linear superconcentrators [125] in Table 5.4. Their construction treats the labels of all vertices as advice. This optimizes runtime but leaves an asymptotic gap in space-hardness (hence, it does not meet Definition 5.1). It is possible for them to run audits only on the sinks, essentially generating less advice using the same graph and runtime. This will improve their space-hardness up ′ ′ 1 1 to 푁0 = 푁1 = ( 2 × 256 − 훿)푁 and increase runtime by a factor of 25.3 log 푁. There is currently no known way to remove the remaining gap of 512 × 25.3 (from linear superconcentrators). We did not count the cost of including vertex ID in random oracle calls (for both our construction and theirs) since vertex ID is small compared to labels. This explains the difference in prover runtime we report in Table 5.4 from [63]. A subsequent construction [3] deviates from the graph pebbling framework and achieves remark- ably better efficiency: 푂(1) message size, prover runtime and verifier space/runtime for audits. But its space-hardness proof currently has a Θ(푁 1/3) asymptotic gap.

79 80 Chapter 6

Bandwidth-Hard Functions

The standard approach towards ASIC resistance thus far has been memory-hard functions or memory- hard proof-of-work schemes. In this chapter, I argue that the memory-hardness approach provides only a partial solution to ASIC resistance. It only attempts to provide resistance to an ASIC’s area advantage but overlooks the more important energy advantage. I suggest using bandwidth-hardness to reduce the energy efficiency gap between ASICs and CPUs.

6.1 Introduction

An ASIC-resistant function hopes to limit ASICs’ advantages over CPUs at computing the function. Many “altcoins”, including Ethereum, Litecoin, Monero, Zcash, hope to achieve ASIC resistance in order to stay decentralized and egalitarian. ASIC resistance also has value outside the cryptocurrency context. It is becoming standard in password protection. It is well known that service providers should store hashes of user passwords. This way, when a password hash database is breached, an adversary still has to invert the hash function to obtain user passwords. However, for ASIC-equipped adversaries, brute-forcing a password database seems quite feasible. In the recent Password Hashing Competition [72], the winner Argon2 [27] and three of the four “special recognitions” — Catena [73], Lyra2 [5] and yescrypt [130] — claimed ASIC resistance. ASIC-resistant PoWs may also serve as “pricing functions” [61] to defend against email spam and denial-of-service attacks. In contrast, pricing functions based on conventional hashing schemes (e.g., SHA-256) will be nowhere near deterrent to ASIC-equipped adversaries if they are to stay manageable for honest CPU users.

81 The standard approach towards ASIC resistance thus far has been memory-hard functions, which, roughly speaking, are functions that require a large amount memory space to evaluate. However, it is seldom questioned why memory-hardness is believed to give ASIC resistance . This chapter will first go over the basic concepts and reasoning of ASIC resistance from a hardware perspective to search for a better understanding. The first and foremost question we should ask is: what advantages of ASICs are we trying to resist? The most strongly perceived advantage of ASIC miners may be their incredible speed. But if speed were the sole metric, one could just deploy a million CPUs in parallel to catch up on speed. Obviously, using a million CPUs would be at a huge disadvantage in two aspects: capital cost (or manufacturing cost) and power consumption. The manufacturing cost of a chip is often approximated by its area [110]. Therefore, the metrics to compare hardware systems should be:

1. the area-speed ratio, or equivalently the area-time product, commonly referred to as 퐴푇 in the literature [110, 28, 6, 7], and

2. the power-speed ratio, which is equivalent to energy cost per function evaluation.

Area and energy efficiency are the two major advantages of ASICs. The speed advantage canbe considered as a derived effect from them. Because an ASIC hash unit is small and energy efficient, ASIC designers can pack thousands of them in a single chip and still have reasonable manufacturing cost and manageable power consumption and heat dissipation. From an economic perspective, this means when speed is normalized, an adversary purchasing ASICs can lower its initial investment (capital cost) due to area savings and its recurring electricity cost due to energy savings, compared to a CPU user. To achieve ASIC resistance is essentially to reduce ASICs’ area and energy efficiency advantages.

Space-hard functions. Informally, a memory-hard function is one that require a lot of memory space to evaluate. To better distinguish from other notions in the chapter, I henceforth refer to memory-hard functions as space-hard functions. Historically, the space-hardness approach only attempts to resist ASIC’s area advantage by forcing it to spend significant area on memory. The following is quoted from Percival’s128 paper[ ]:

82 A natural way to reduce the advantage provided by an attacker’s ability to construct highly parallel circuits is to increase the size of the key derivation circuit — if a circuit is twice as large, only half as many copies can be placed on a given area of silicon ...

This reasoning is also reflected by Pervical’s definition for space-hardness: a function is space-hard if 1−휖 it (1) can be computed using 푇0 time and 푆0 = 푂(푇0 ) space, and (2) cannot be computed using 푇 2−휖 time and 푆 space where 푆푇 = 푂(푇0 ). The 푆푇 product approximates 퐴푇 assuming that memory (rather than compute units) dominates chip area. It should now be clear that the space-hardness approach does not provide a full solution to ASIC resistance since it attempts to address only the area aspect, but not the energy aspect of ASIC advantage. The relative importance of the two aspects depends on economic factors, which are out of the scope of this thesis. But it may be argued that the energy aspect is more important than the area aspect in some scenarios. Area advantage, representing lower capital cost, is a one-time gain, while energy advantage, representing lower electricity consumption, keeps accumulating with time. A major goal of this chapter is to fill in the important yet long-overlooked energy aspect ofASIC resistance.

Bandwidth-hard functions. We hope to find a function 푓 such that the energy cost to evaluate 푓 on an ASIC cannot be much smaller than on a CPU. We cannot change the fact that ASICs have much superior energy efficiency for computation compared to CPUs. Luckily, to our rescue, off-chip memory accesses incur comparable energy costs on ASICs and CPUs. Therefore, we would like an ASIC-resistant function 푓 to be bandwidth-hard, i.e., it should require a lot of off-chip memory accesses to evaluate 푓. If off-chip memory accesses account for a significant portion of thetotal energy cost to evaluate 푓, then they provide an opportunity to bring the energy cost on ASICs and CPUs onto a more equal ground. Our idea of using memory accesses resembles, and is indeed inspired by, memory-bound functions [1, 59, 62]. A comparison is deferred to Section 6.4. It is not a coincidence that storage plays a central role in both the area and the energy approach. As mentioned, CPUs are at a huge disadvantage over ASICs in computation because CPUs handle general-purpose computation while ASICs are specifically optimized for certain tasks. Memory or storage does not suffer from this problem because storage is, for the most part, intrinsically general- purpose. A storage device’s job is to hold bits and deliver them to the compute units regardless

83 of what the computational task is. New technologies like 3D-stacked memory [31], high-speed serial [148] and various types of non-volatile memory do not undermine the argument: they are general-purpose improvements and will be adopted by both CPUs and ASICs when they become successful. Note that a bandwidth-hard function also needs to be space-hard. After all, if the entire memory footprint fits in an ASIC chip, the function cannot be bandwidth-hard. This means a bandwidth-hard function inherits the area advantage resistance from space-hardness (though somewhat weakened by parallel attacks, cf. Section 6.4). On the other hand, a space-hard function is not necessarily bandwidth-hard. Intuitively, an exception arises when a space-hard function has good locality in its memory access pattern. In this case, an ASIC adversary can use some on-chip cache to “filter out” most off-chip memory accesses and make computation the energy bottleneck again. A function based on a stacked double butterfly graph is one such example (Section 6.3.4). On the positive side, many space-hard functions are indeed bandwidth-hard under suitable parameters, as we show in Section 6.3.

6.2 Bandwidth-Hard Functions: Definition and Limit

We will again adopt the graph labeling framework of evaluating random oracles (hashing) in DAGs. To study hardware energy cost more formally, we need to first introduce a hardware architecture model and an energy cost model.

6.2.1 Model

We assume the hardware to evaluate the function consists of a compute unit (e.g., a CPU or an ASIC chip) and a storage device. The adversary is allowed to have in its ASIC chip a cache of 푀 bits in size. It may use the optimal cache replacement policy [20]. We assume a one-level cache hierarchy for convenience. This does not affect the generality of the model. We do not charge the adversary for accessing the cache, so only the total cache size matters. The proofs in Section 6.3 do not directly analyze cache hit rate, but the results imply that a bandwidth-hard function ensures a low hit rate even for an optimal cache. It also means that honest users cannot utilize the large caches in modern CPUs and will observe a nearly 0% cache hit rate.

84 We assume it costs 푐푏 energy to transfer one bit of data between memory and cache, and 푐푟 energy to evaluate the random oracle on one bit of data in cache. If an algorithm transfers 퐵 bits of data and queries the random oracle on 푅 bits of data in total, its energy cost is ec = 푐푏퐵 + 푐푟푅. A compute unit and memory interface may operate at a much larger word granularity, but we define 푐푏 and 푐푟 to be amortized per bit for convenience. The two coefficients are obviously hardware dependent.

We write 푐푏,cpu, 푐푟,cpu and 푐푏,asic, 푐푟,asic when we need to distinguish them. We assume 푐푟,asic is much smaller than the other three coefficients, i.e., 푂(푐푟,cpu) = (푐푏,cpu) = 푂(푐푏,asic) = 푤(푐푟,asic). Example values of these coefficients are given in Section 6.2.4 either through experiments or from the literature.

While an ASIC’s energy cost for computation 푐푟,asic is small, we assume it is not strictly 0. Some prior works assume computation is completely free for the adversary [59, 62, 64]. If we adopt that model, we must find a function that has an absolute space lower bound (even an exponential computational penalty for space reduction is insufficient), and at the same time requires a comparable amount of computation and memory accesses. We do not know of any candidate construction that satisfies the above conditions. We believe the non-zero 푐푟,asic assumption is realistic. In fact, it may still be overly favorable to the adversary. It has been noted that the energy cost to access data from an on-chip cache is roughly proportional to the square root of the cache size [14]. Thus, if an adversary employs a large on-chip cache, the energy cost of fetching data from this cache should have been included in 푐푟,asic.

6.2.2 Definition: Energy Fairness

The ultimate goal of a bandwidth-hard function is to achieve fairness between CPUs and ASICs in terms of energy cost. For a function 푓, suppose honest CPU users adopt an algorithm with an energy cost ec0 = 푐푏,cpu퐵0 + 푐푟,cpu푅0. Let ec = ec(푓, 푀, 푐푏,asic, 푐푟,asic) be the minimum energy cost for an adversary to evaluate 푓 with cache size 푀 and ASIC per-bit energy coefficients 푐푏,asic and

푐푟,asic. Energy fairness is then measured by the energy advantage of an ASIC adversary over honest

CPU users (under those parameters): 퐴ec = ec0/ec. A smaller 퐴ec indicates better energy fairness.

Definition 6.1. A function is bandwidth-hard if it ensures 퐴ec = 푂(1), namely, if an adversary gains at most a constant factor advantage in energy cost.

We emphasize a function’s bandwidth-hardness often holds under particular parameters, usually only when its memory footprint is sufficiently large compared to the adversary’s cache size 푀.

85 This should be as expected: if the entire memory footprint fits in cache, then a function must be computation bound rather than bandwidth bound. As an example, we will later show that scrypt is bandwidth-hard when it requires sufficiently large space. But when scrypt is adopted in practice (e.g., in Litecoin), it is often configured to use much less memory (to be less demanding for honest users), thus losing its bandwidth-hardness and ASIC resistance. Also note that the terms “bandwidth-hard” and “space-hard” do not imply strict lower bounds on bandwidth and space. Space-hardness as defined by Percival [128] refers to a lower bound on the space-time product 푆푇 , while bandwidth-hardness defined in this thesis refers to a lower bound on an ASIC’s energy consumption.

6.2.3 Red-Blue Pebble Games

Since we introduced a cache/memory hierarchy for bandwidth-hard functions, we need a pebble game abstraction with two types of pebbles. We will use red-blue pebble games, which was introduced precisely for this purpose [79]: to model I/O complexity in a computer with a memory hierarchy. A red (hot) pebble models data in cache, which can be computed upon immediately. A blue (cold) pebble models data in memory, which must first be brought into cache to be computed upon. The rule of a red-blue pebble game is naturally extended as follows:

∙ A red pebble can be placed on vertex 푣 if 푣 is a source or if all predecessors of 푣 have red pebbles on them. ∙ A red pebble can be placed on vertex 푣 if there is a blue pebble on 푣. A blue pebble can be placed on vertex 푣 if there is a red pebble on 푣.

We refer to the first type of moves as red moves and the second type as blue moves. Pebbles (red or blue) can be removed from any vertices at any time. A pebbling strategy can be represented as a se- quence of transitions between pebble placement configurations on the graph, P = (푃0, 푃1, 푃2 ··· , 푃푇 ). Each configuration consists of two vectors of size |푉 |, specifying for each vertex if a red pebble exists and if a blue pebble exists. The starting configuration 푃0 usually is, but does not have to be, empty

(vertices may be pebbled in 푃0). Each transition makes either a red move or a blue move, and then removes any number of pebbles for free. If a pebble (red or blue) exists on a vertex 푣 in a configuration 푃푖, we say 푣 is pebbled in 푃푖. We say a sequence P pebbles a vertex 푣 if there exists

푃푖 ∈ P such that 푣 is pebbled in 푃푖. We say a sequence P pebbles a set of vertices if P pebbles

86 every vertex in the set. Note that blue pebbles cannot be directly created on unpebbled vertices. If a vertex 푣 is not initially pebbled in 푃0, then the first pebble that gets placed on 푣 in P must be a red pebble, and it must result from a red move.

Energy cost of red-blue pebbling. In red-blue pebbling, red moves model computation on data in cache and blue moves model data transfer between cache and memory. It is straightforward to adopt the energy cost model in Section 6.1 to red-blue pebbling. We charge 푐푏 cost for each blue move. For each red move (i.e., random oracle call), we charge a cost proportional to the number of input vertices (cf. Section 5.2.3). As before, removing pebbles (red or blue) is free. If P uses 퐵 blue moves and 푅 red moves each with 푑 predecessors, it incurs a total energy cost ec(P) = 푐푏퐵 + 푐푟푑푅. The adversary’s cache size 푀 translates to a bounded number of red pebbles at any given time, which we denote as 푚. For a graph 퐺, given parameters 푚, 푐푏 and 푐푟, let ec = ec(퐺, 푚, 푐푏, 푐푟) be the minimum cost to pebble 퐺 in a red-blue pebble game starting with an empty initial configuration under those parameters. Clearly, a legal red-blue pebbling sequence gives a graph labeling algorithm using the same energy cost. The reverse has also been shown with a constant factor relaxation in adversary cache size [32]. Let ec0 be the cost of an honest CPU user. The energy advantage of an

ASIC is 퐴ec = ec0/ec.

6.2.4 Limit of Energy Fairness

While our goal is to upper bound the energy advantage 퐴ec, it is helpful to first look at a lower bound to know the best resistance we can hope for. Suppose honest users adopt an algorithm that transfers 퐵0 bits and queries ℋ on 푅0 bits in total. Even if an adversary does not have a better algorithm, by running the honest algorithm on an ASIC, the adversary’s energy advantage is

푐푏,cpu퐵0 + 푐푟,cpu푅0 푐푏,cpu + 푐푟,cpu푅0/퐵0 퐴ec = = . 푐푏,asic퐵0 + 푐푟,asic푅0 푐푏,asic + 푐푟,asic푅0/퐵0

Since we expect 푐푟,cpu ≫ 푐푟,asic and 푐푏,cpu ≈ 푐푏,asic, the above value is smaller when 푅0/퐵0 is smaller (more memory accesses and less computation). Any data brought into the cache must be consumed by the compute unit — otherwise, the data transfer is useless and should not have happened. Thus,

87 Operation memory access SHA-256 AES Energy, CPU 0.5 30 1.5 Energy, ASIC 0.3 0.0012 /

Table 6.1: Measured energy cost (in nJ) per Byte for memory accesses and cryptographic operations on CPUs.

푅0/퐵0 ≥ 1 and the adversary can at least have an energy consumption advantage of:

푐푏,cpu + 푐푟,cpu 퐴ec ≥ = 퐴ec. 푐푏,asic + 푐푟,asic

Estimates of energy cost coefficients. All values we report here are approximates. Nevertheless, they should allow us to estimate 퐴ec to the correct order of magnitude. We keep a CPU fully busy with the task under test, i.e., compute hashes and making memory accesses. We use Intel Power Gadget [83] to measure the CPU package energy consumption over a period of time, and then divide by the number of Bytes processed (hashed or transferred). We run tests on an Intel Core I7-4600U CPU in 22nm technology clocked at 1.4 GHz. The operating system is Ubuntu 14.04 and we use Crypto++ Library 5.6.3 compiled with GCC 4.6.4. Table 6.2.4 reports the measured CPU energy cost per Bytes. We take the memory access energy estimates for ASICs from two papers [81, 127], which give fairly close estimations. We take the SHA-256 energy cost for ASIC from the state-of-the-art Antminer S9 specification. Antminer S9 spends 0.098 nJ to hash 80 Bytes, which normalizes to 0.0012 nJ / Byte. With these parameters, any function in the graph labeling framework can at most reduce an ASIC’s energy advantage to

퐴ec ≈ (0.5 + 30)/(0.3 + 0.0012) ≈ 100×.

Better energy fairness with AES-NI and SHA extensions. To further bring down 퐴ec, we need a smaller 푐푟,cpu. One option is to take advantage of the AES-NI or SHA extensions [82, 84]. These are ASIC-style AES or SHA circuits that vendors build into CPUs to improve the speed and energy efficiency of AES or SHA operations. But we still cannot expect them to match stand-alone ASICs because they are subject to design constraints imposed by the CPUs. Today AES-NI is available in all mainstream CPUs. We repeat our previous experiments for AES and obtain that

AES-NI achieves 1.5 nJ/Byte energy efficiency. We do not have data points for 푐푟,asic for AES but

88 푉

푈

Figure 6-1: A random sandwich graph with 푛 = 8.

푉

푈

Figure 6-2: A bit-reversal graph with 푛 = 8. expect it to be no better than that of SHA-256 ASIC. Hence, with AES-NI, the lower bound improves to 퐴ec ≈ (0.5 + 1.5)/0.3 ≈ 6.7×. We do not have access to a machine with SHA extensions but expect similar improvements to 퐴ec from them. It is worth noting that AES-NI or SHA extensions will also reduce ASIC’s 퐴푇 advantage as they make CPUs run faster (smaller 푇 ).

6.3 Bandwidth-Hardness of Candidate Constructions

Some candidate constructions we analyze in this chapter are based on a class of graphs called “sandwich graphs” [13, 33].

Definition 6.2. A sandwich graph is a directed acyclic graph 퐺 = (푉 ∪ 푈, 퐸) that has 2푛 vertices

푉 ∪ 푈 = (푣0, 푣1, ··· 푣푛−1) ∪ (푢0, 푢1, ··· 푢푛−1), and two types of edges:

– chain edges, i.e., (푣푖, 푣푖+1) and (푢푖, 푢푖+1) ∀푖 ∈ [0..푛 − 2], and – cross edges from 푉 to 푈.

In other words, a sandwich graph is a bipartite graph with the addition of chain edges. Figure 6-1 is a random sandwich graph with 푛 = 8. We call the path consisting of (푣0, 푣1), (푣1, 푣2), ··· (푣푛−2, 푣푛−1) the input path, and the path consisting of (푢0, 푢1), (푢1, 푢2), ··· (푢푛−2, 푢푛−1) the output path.

89 6.3.1 Scrypt

Scrypt [128] can be thought of as a sandwich graph where the cross edges are dynamically generated at random in a data-dependent fashion (cf. Figure 6-1). Each vertex 푢푖 on the output path has one incoming cross edge from a vertex 푣푗 that is chosen uniformly random from the input path based on the previous label 푙(푢푖−1) (or 푙(푣푛−1) for 푢0), and thus cannot be predicted beforehand.

The default strategy to compute scrypt is to first compute each 푙(푣푖) on the input path sequentially and store each one in memory, and then compute each 푙(푢푖) on the output path, fetching each 푙(푣푗) from memory as needed. The total energy cost of this strategy is (푐푟 +푐푏)푛+(푐푏 +2푐푟)푛 = (2푐푏 +3푐푟)푛 (every node on the output path has in-degree 2). To lower bound the energy cost, we make a simplifying assumption that if the adversary transfers data from memory to cache at all, it transfers at least 푤 bits where 푤 = |푙(·)| is the label size. We also invoke the “single-challenge time lower bound” theorem on scrypt [11], which we paraphrase below. The adversary can fill a cache of 푀 bits after arbitrary computation and preprocessing on the input path. The adversary then receives a challenge 푗 chosen uniformly at random from 0 to

푛 − 1 and tries to find 푙(푣푗) using only the data in the cache. Let 푡 be the random variable that represents the number of sequential random oracle calls to ℋ made by the adversary till it queries ℋ with 푙(푣푗) for the first time.

Theorem 6.3 (Alwen et al. [11]). For all but a negligible fraction of random oracles, the following 푛 1 holds: given a cache of 푀 bits, Pr[푡 > 2푝 ] > 2 where 푝 = (푀 + 1)/(푤 − 3 log 푛 + 1) and 푤 = |푙(·)| is the label size.

The above theorem states that in the parallel random oracle model, with at least 1/2 probability, an adversary needs 푛/2푝 sequential random oracles to answer the random challenge. 1 A lower bound on the number of sequential random oracle calls in the parallel model is a lower bound on the number of total random oracle calls in our sequential model. Theorem 6.3 states that if the adversary wishes to compute a label on the output path only using the 푀 bits in cache without fetching from memory, there is a 1/2 chance that doing so requires 푛/2푝 random oracle calls. If we choose a sufficiently large 푛 such that 푐푟푛/4푝 > 푐푏, then in expectation, relying on random oracle calls is more expensive than simply fetching the challenged input label from memory. We have assumed that

1Theorem 6.3 does not directly apply to scrypt since challenges in scrypt come from the random oracle rather than from an independent external source. This issue can be handled similarly as in [11].

90 the adversary fetches at least 푤 bits at a time, so if it fetches from memory at all, it rather fetches the entire challenged input label. Thus, the expected cost for an adversary to compute a label on

2푐푏,cpu+3푐푟,cpu the output path is at least 푐푏 and the energy advantage is at most 퐴ec < = 푂(1). 푐푏,asic Scrypt has been shown to be space-hard under infinite parallelism [11]. But scrypt also has a few drawbacks. First, its bandwidth-hardness also kicks in when 푛 = Θ(푝 · 푝푐푏,asic ) > Θ(푚 · 푐푏,asic ), 푐푟,asic 푐푟,asic which means the space requirement of scrypt need be orders of magnitude larger than an adversary’s conceivable cache size. Second, its memory access pattern is data-dependent, which is considered less secure in password hashing for fear of side channel attacks. Thus, it is interesting to also look for data-independent bandwidth-hard functions, especially those achieving bandwidth-hardness with a smaller memory footprint.

6.3.2 Bit-Reversal Graphs

A bit-reversal graph is a sandwich graph where 푛 is a power of 2 and the cross edges (푣푖, 푢푗) follow the bit-reversal permutation, namely, the binary representation of 푗 reverses the bits of the binary representation of 푖. Figure 6-2 is a bit-reversal graph with 푛 = 8. Catena-BRG [73] is based on bit-reversal graphs. For a red-blue pebble game on a bit-reversal graph, the default strategy is the same as the one for scrypt in Section 6.3.1 with an energy cost of (푐푟 + 푐푏)푛 + (푐푏 + 2푐푟)푛 = (2푐푏 + 3푐푟)푛. We now show a lower bound on the red-blue pebbling complexity for bit-reversal graphs borrowing techniques from Lenguaer and Tarjan [101].

Theorem 6.4. Let 퐺 be a bit-reversal graph with 2푛 vertices, and 푚 be the number of red pebbles available. If 푛 > 2푚푐푏/푐푟, then the red-blue pebbling cost ec(퐺, 푚, 푐푏, 푐푟) is lower bounded by (푐 + 푐 )푛(1 − 2(푚+1)푐푏 ). 푏 푟 푛푐푟

Proof. Suppose a red-blue pebbling sequence P pebbles the sink 푢푛−1 of a 퐺 starting from an ′ ′ empty initial configuration. Let 푚 be the largest power of 2 satisfying 푚 < 푛푐푟/푐푏. We have ′ 푚 ≥ 푛푐푟/(2푐푏) > 푚. Let the output path be divided into 푛/푚′ intervals of length 푚′ each. Denote the 푗-th interval ′ 퐼푗, 푗 = 1, 2, ··· , 푛/푚 . 퐼푗 contains vertices 푢(푗−1)푚′ , 푢(푗−1)푚′+1, . . . , 푢푗푚′−1. The first time these intervals are pebbled must be in topological order, so P can be divided into 푛/푚′ sub-sequences

91 (P1, P2, ··· , P푛/푚′ ) such that all vertices in 퐼푗 are pebbled for the first time by P푗. The red-blue pebbling costs of sub-sequences are additive, so we can consider each P푗 separately. ′ Suppose P푗 uses 푏 blue moves. For any 퐼푗, 1 ≤ 푗 ≤ 푛/푚 , let 푣푗1 , 푣푗2 , . . . , 푣푗푚′ be the immediate predecessors on the input path. Note that these immediate predecessors are 푛/푚′ edges apart from each other due to the bit-reversal property. P푗 must place red pebbles on all these immediate predecessors at some point during P푗. An immediate predecessor 푣 may get its red pebble in one of the following ways:

1. 푣 has a close ancestor (can be itself) that has a red pebble on it at the beginning of P푗. Here, ′ being close means being less than 푛/푚 edges away. In this case, P푗 can place a red pebble on 푣 using less than 푛/푚′ red moves utilizing this “close” ancestor. 2. 푣 has a close ancestor (can be itself) that gets a red pebble through a blue move. In this case, ′ P푗 can place a red pebble on 푣 using one blue move plus less than 푛/푚 red moves. 3. 푣 gets its red pebble through a red move and has no close ancestor that gets a red pebble ′ through a blue move. To place a red pebble on 푣, P푗 must use at least 푛/푚 red moves (except

when 푣 is close to the source node 푣0). The first category accounts for at most 푚 immediate predecessors due to the cache size limit. The second category accounts for at most 푏 immediate predecessors since each uses a blue move. If ′ ′ 푏 + 푚 < 푚 − 1, then P푗 must use at least 푛/푚 red moves for each immediate predecessor in the third category. Under the conditions in the theorem, the cost of 푛/푚′ red moves is greater than ′ a blue move since 푐푟푛/푚 > 푐푏. Thus, the best strategy is to use blue moves over red moves for vertices on the input path whenever possible. Therefore,

′ ′ ′ ec(P푗) ≥ 푐푟푚 + 푐푏(푚 − 푚 − 1) > (푐푏 + 푐푟)(푚 − 푚 − 1)

푛/푚′ 2(푚 + 1)푐푏 ec(P) = Σ푗=1 ec(P푗) > (푐푏 + 푐푟)푛(1 − ). 푛푐푟

When 푛 is sufficiently large, the red-blue pebbling cost has a lower bound close to (푐푏 + 푐푟)푛, and

2푐푏,cpu+3푐푟,cpu an ASIC’s energy advantage is 퐴ec ≈ = 푂(1). The space requirement for bit-reversal 푐푏,asic+푐푟,asic graphs to be bandwidth-hard is similar to the requirement for scrypt.

92 6.3.3 Stacked Expanders

Balloon hashing uses stacked expanders2 (cf. Section 5.2.3 and Figure 5-1) and further chains the vertices sequentially, i.e., there exist edges (푣푖,푗, 푣푖,푗+1) for each 0 ≤ 푖 ≤ 푘, 0 ≤ 푗 ≤ 푛 − 2 as well as an edge (푣푖,푛−1, 푣푖+1,0) for each 0 ≤ 푖 ≤ 푘. In other words, Balloon hashing uses a stacked random sandwich graph in which each vertex has 푑 > 1 predecessors from the previous layer. For red-blue pebble games on stacked expanders, an honest user would simply pebble each expander in order in a straightforward way. First, for each vertex 푣 in the source layer 푉0, the honest user places a red pebble on 푣 and then immediately replaces it with a blue pebble. Then, for each vertex 푣 ∈ 푉1, the honest user places red pebbles on its 푑 predecessors through blue moves, pebbles 푣 using a red move, replacing the red pebble with a blue pebble, and lastly removing all red pebbles.

The cost to pebble each source vertex is (푐푏 + 푐푟) and the cost to pebble each non-source vertex is

푐푏(푑 + 1) + 푐푟푑. The total cost to pebble the entire graph is ≈ 푛푘푑(푐푏 + 푐푟). We next prove a trade-off for red-blue pebble games on stacked expanders.

Theorem 6.5. In a red-blue pebble game on 퐺(푛,푘,훼,훽), if a sequence P pebbles any subset of 훼푛 sinks of 퐺 through red moves, using at most 푚 red pebbles (plus an arbitrary number of blue pebbles) and at most (훽 − 2훼)푛 − 푚 blue moves, then P must use at least 2푘훼푛 red moves.

The proof is similar to the inductive proof for Theorem 5.6. Informally, if there is a strategy that pebbles any subset of 훼푛 vertices using at most 푚 red pebbles and at most 푏 blue moves, it implies a strategy that pebbles those 훼푛 vertices using at most 푚 + 푏 black pebbles. The reason is that while there may be arbitrarily many blue pebbles, at most 푏 blue pebbles can be utilized since there are at most 푏 blue moves. Therefore, either 푚 + 푏 ≥ (훽 − 2훼)푛 or an exponential number of red moves are needed.

Proof. The base case is trivially true. Now we show the inductive step for 푘 ≥ 1 assuming the theorem holds for 푘 − 1. The 훼푛 sinks in 푉푘 that are pebbled through red moves collectively are connected to at least 훽푛 predecessors in 푉푘−1 due to the (푛, 훼, 훽) expander property. Each of these

훽푛 vertices in 푉푘−1 must have a red pebble on it at some point to facilitate the red moves on the 훼푛 sinks. These 훽푛 vertices may get their red pebbles in one of the three ways below. Up to 푚 of

2The latest version of the Balloon hash paper [33] analyzes random sandwich graphs using a new “well-spread” property rather than the expanding property.

93 them may initially have red pebbles on them. Up to (훽 − 2훼)푛 − 푚 of them may initially have blue pebbles on them get red pebbles through blue moves. The remaining 2훼푛 of them must get their red pebbles through red moves. These 2훼푛 vertices in 푉푘−1 are sinks of an (푛, 푘 − 1, 훼, 훽) stacked expander. Divide them into two groups of 훼푛 each in the order they get red pebbles in P for the first time. P can be then divided into two parts P = (P1, P2) where P1 places red pebbles on the first group (P1 does not place red pebbles on any vertices in the second group) and P2 places red pebbles on the second group. Both P1 and P2 use no more than 푚 red pebbles and (훽 − 2훼)푛 − 푚 blue moves. Due to the inductive hypothesis, both use at least 2푘−1훼푛 red moves. Therefore, P uses at least 2푘훼푛 red moves.

Theorem 6.5 can be generalized. If P′ uses at most 푚 red pebbles (plus an arbitrary number of blue pebbles) and at most (훽 − 푞훼)푛 − 푚 blue moves, then P′ must use at least 푞푖훼푛 red moves.

For a proof, simply notice that there will be 푞훼푛 vertices in 푉푖−1 that need to get their red pebbles through red moves. The 푞푖 factor then follows from a similar induction.

Theorem 6.6. Let 퐺 be an (푛, 푘, 훼, 훽) stacked expander with in-degree 푑. Its red-blue pebbling cost ec(퐺, 푚, 푐푏, 푐푟) is lower bounded by (푐푏 + 푐푟) · ((훽 − 2훼)푛 − 푚) · (푘 − ⌈log2(푐푏/푑푐푟)⌉)/훼.

Proof. With the chain edges, if a sequence starts from an empty configuration, it must pebble vertices in 퐺 in topological order. For simplicity, let us assume each layer of 푛 vertices can be divided into an integer number of groups of size 훼푛 each (i.e., 1/훼푛 is an integer). Now we can break up the sequence into (푘 + 1)푛/훼푛 sub-sequences; each one pebbles the next consecutive 훼푛 vertices for the first time. Since the red-blue pebbling costs from multiple sub-sequences are additive, we analyze and lower bound them separately. ′ Consider a sub-sequence P that pebbles 훼푛 vertices in 푉푖 for the first time. Theorem 6.5 shows a trade-off on the usage of red versus blue moves. For 푖 > ⌈log2(푐푏/푑푐푟)⌉, blue moves are not worth saving. This means, for layers relatively deep, the best strategy is to use blue moves whenever ′ possible. The cost is at least ec(P ) ≥ 푐푏((훽 − 2훼)푛 − 푚) + 푐푟푑훼푛 > (푐푏 + 푐푟)((훽 − 2훼)푛 − 푚). The latter inequality is due to 푑훼 > 훽−2훼, which is easy to check from the requirement on 푑 for expanders in Section 5.2.3. Lastly, there are (푘 − ⌈log2(푐푏/푑푐푟)⌉) layers 푉푖 satisfying 푖 > ⌈log2(푐푏/푑푐푟)⌉ and each contains 1/훼 vertex groups of size 훼푛. The bound in the theorem follows.

94 Figure 6-3: A double butterfly graph with 푛 = 8 sources and sinks. Vertices marked in red have locality assuming a cache size of 푚 = 4.

For a stacked expander graph to be bandwidth-hard, we need 푛 and 푘 to be a constant factor larger than 푚/(훽 − 2훼) and ⌈log2(푐푏/푑푐푟)⌉, respectively. (Contrast it with the requirements for scrypt and bit-reversal graphs.) When 푛 and 푘 are sufficiently large, an ASIC’s advantage 퐴ec ≈ 푐푏,cpu+푐푟,cpu · 푑훼 = 푂(1). 푐푏,asic+푐푟,asic 훽−2훼

6.3.4 Stacked Butterfly Graphs Are Not Bandwidth-Hard

In this section, we demonstrate that a space-hard function (in the sequential model) may not be bandwidth-hard, using a stacked double butterfly graph as a counterexample. A double butterfly graph consists of two fast Fourier transform graphs back to back. It has 푛 sources, 푛 sinks and

2푛 log2 푛 vertices in total for some 푛 that is a power of 2. The intermediate vertices form two smaller double butterfly graphs each with 푛/2 sources and 푛/2 sinks. Figure 6-3 shows an example double butterfly graph with 푛 = 8. A stacked double butterfly graph further stacks copies of double butterfly graphs back to back (not shown in the figure). A double butterfly graph is a superconcentrator [37]. It has been shown that a stacked supercon- centrator graph is space-hard since it has an exponentially sharp space-time trade-off in sequential pebble games [101]. However, a stacked double butterfly graph is not bandwidth-hard due to locality in its memory access pattern. One can fetch a batch of labels into the cache and perform a lot of computation with them before swapping in another batch of labels. For example, in Figure 6-3, one can pebble the red vertices layer by layer without relying on other vertices. If equipped with

95 a cache of size 푚 (assume 푚 is a power of 2 for simplicity), we can adopt the following pebbling strategy to save blue moves without sacrificing red moves. First place red pebbles on 푚 vertices in the same layer that are 푛/푚 away from each other, possibly through blue moves. Then, use red moves to proceed log2 푚 layers horizontally, placing red pebbles on the 푚 vertices in the same horizontal positions. To pebble the entire graph, this strategy uses 푁 = 2푛 log2 푛 red moves and only

푁/ log2 푚 blue moves. Its cost is therefore (2푐푟 + 푐푏/ log2 푚)푁. As demonstrated in Section 6.2.4,

푐푟,cpu is larger or at least comparable to 푐푏,cpu while 푐푟,asic ≪ 푐푏,asic. Therefore, the red-blue pebbling of a stacked double butterfly graph costs more than 2푐푟,cpu푁 on CPUs and roughly 푐푏,asic푁/ log2 푚 on ASICs. This results in an advantage proportional to log2 푚. Stacked double butterfly graphs are adopted by the space-hard function Catena-DBG73 [ ] and the space-hard PoW by Ateniese et al. [17]. We note that Catena-DBG designers further add chain edges within each layer [73]. These chain edges will prevent our proposed pebbling strategy, so

Catena-DBG may not suffer from the log2 푚 ASIC energy advantage. Our goal here is to show that space-hard functions (in the sequential model) are not necessarily bandwidth-hard, and a stacked double butterfly graph without chain edges serves as an example. We also remark that since stacked double butterfly graphs are not space-hard in the parallel model, the question remains openwhether parallel space-hardness implies bandwidth-hardness.

6.3.5 Summary

We conclude this section with a summary of applicability and provable security of different construc- tions under different threat models.

1. If memory access pattern leakage is not a concern, then scrypt [128] is a good option, as it enjoys parallel space-hardness [11] and bandwidth-hardness.

2. If we assume the adversary has limited parallelism, then Balloon hash is a good choice as it achieves sequential space-hardness [33] and bandwidth-hardness. Argon2i [27], the winner of the Password Hashing Competition, is a possible alternative, but we have not been able to analyze its bandwidth-hardness.

96 3. If memory access pattern must be data-independent and the adversary has massive parallelism, then a logarithmic loss in 퐴푇 is inevitable, and recent constructions achieve almost optimal 퐴푇 loss [8] and bandwidth-hardness [32].

6.4 Related Work

Space-hard functions and PoW. Space-hard functions are currently the standard approach towards ASIC resistance. The notion was first proposed by Percival along with the scrypt con- struction [128]. As its name suggests, a space-hard function is supposed to require a lot of memory space to compute. Follow-up works have proposed constructions with stronger notions of space- hardness [73, 5, 130, 27, 33]. A line of work known as proof-of-secure-erasure [129, 88] is also space-hard functions. A space-hard PoW requires a prover to use a lot of space and time while at the same time allows a verifier to check the prover’s claim with a small amount of space and time [17, 144, 30, 29].3 Many of the above proposals are ad-hoc and have to be patched when attacks are discovered [28, 15, 54].

Memory-bound functions. A memory-bound function requires a lot of memory accesses to evaluate. The notion was first proposed by Abadi et1 al.[ ] and later formalized and improved by Dwork et al. [59, 62]. Memory-bound functions predate space-hard functions, but unfortunately have been largely overlooked by recent work on ASIC resistance. A major difference between our work and memory-bound functions is that they assume computation is completely free while we assume computation is cheap but not free. As a result, they need to derive strict lower bounds on bandwidth (the number of memory accesses). Their solutions involve traversing random paths in a big table of true random numbers, where the big random table needs to be transferred to the prover from the verifier. Our relaxed model avoids this overhead and allows for more efficient solutions.A follow-up work allows the big table to be filled by pebbling a rather complex graph62 [ ], implicitly moving to our model.

Parallel attacks. Alwen and Serbinenko [13] observed that the original space-hardness defini- tion [128] overlooked parallelism, and that cumulative complexity better matches 퐴푇 in the parallel

3Ateniese et al. [17] named their scheme proof-of-space, but it is a space-hard PoW under our terminology.

97 model. An impressive line of work has since produced many interesting results in the parallel model. It is discovered that a property called depth-robustness [65] is both necessary and sufficient for a graph to exhibit high parallel cumulative complexity [6, 9]. Since no data-independence graph is maximally depth-robust [145], no data-independent function has perfect cumulative complexity [6]. Practical graphs with close to optimal depth-robustness have been constructed [8]. The practicality of parallel attacks, however, is less clear since they typically assume unlimited bandwidth for free. In practice, memory bandwidth is a scarce resource. Increasing memory bandwidth would inevitably increase chip area and manufacturing cost. We would also like to clarify a direct contradiction between some parallel attacks’ claims [6, 7, 12] and our results. We prove that Catena-BRG [73] and Balloon [33] enjoy great energy advantage resistance while those works conclude the exact opposite. The contradiction is due to their energy model based on space-hardness, which we consider flawed. They assume holding a large amount of data also costs energy anditmust be similar for ASICs and CPUs due to the general-purpose nature of storage. However, this argument breaks down for non-volatile memory/storage. Energy consumption in non-volatile memory/storage occurs almost only upon data transfer [149], which is what this chapter assumes.

98 Chapter 7

Conclusion

This thesis has presented distributed algorithms and cryptographic primitives to improve the efficiency and fairness of consensus. Chapter 3 has presented Solida, a permissionless consensus protocol based on PoW-augmented reconfigurable Byzantine consensus. We have proved safety and liveness under the bounded message delay model and provided a prototype implementation and evaluation results. Chapter 4 has described a 4-round synod protocol that tolerates 푓 Byzantine faults using 2푓 + 1 replicas in the synchronous and authenticated setting. We then applied the synod protocol to obtain a BFT state machine replication protocol with amortized 3 rounds per slot and a Byzantine agreement protocol that halts in expected 9 rounds. Chapter 5 has presented a proof-of-space construction based on stacked expanders. Chapter 6 hoped to call attention to the energy efficiency aspect of ASIC resistance. We have observed that the popular space-hardness notion does not capture and may not achieve energy efficiency fairness. We have proposed the notion of bandwidth-hardness and analyed candidate constructions.

99 100 Bibliography

[1] Martin Abadi, Mike Burrows, Mark Manasse, and Ted Wobber. Moderately hard, memory- bound functions. ACM Transactions on Internet Technology, 5(2):299–327, 2005. [2] Michael Abd-El-Malek, Gregory R. Ganger, Garth R. Goodson, Michael K. Reiter, and Jay J. Wylie. Fault-scalable byzantine fault-tolerant services. In ACM SIGOPS Operating Systems Review, volume 39, pages 59–74. ACM, 2005. [3] Hamza Abusalah, Joël Alwen, Bram Cohen, Danylo Khilko, Krzysztof Pietrzak, and Leonid Reyzin. Beyond hellmanâĂŹs time-memory trade-offs with applications to proofs of space. In International Conference on the Theory and Application of Cryptology and Information Security, pages 357–379. Springer, 2017. [4] Atul Adya, William J. Bolosky, Miguel Castro, Gerald Cermak, Ronnie Chaiken, John R. Douceur, Jon Howell, Jacob R. Lorch, Marvin Theimer, and Roger P. Wattenhofer. FARSITE: Federated, available, and reliable storage for an incompletely trusted environment. ACM SIGOPS Operating Systems Review, 36(SI):1–14, 2002. [5] Leonardo C. Almeida, Ewerton R. Andrade, Paulo S. L. M. Barreto, and Marcos A. Simplicio Jr. Lyra: Password-based key derivation with tunable memory and processing costs. Journal of Cryptographic Engineering, 4(2):75–89, 2014. [6] Joël Alwen and Jeremiah Blocki. Efficiently Computing Data-Independent Memory-Hard Functions, pages 241–271. Springer, 2016. [7] Joël Alwen and Jeremiah Blocki. Towards practical attacks on Argon2i and Balloon hashing. In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pages 142–157. IEEE, 2017. [8] Joël Alwen, Jeremiah Blocki, and Ben Harsha. Practical graphs for optimal side-channel resistant memory-hard functions. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pages 1001–1017. ACM, 2017. [9] Joël Alwen, Jeremiah Blocki, and Krzysztof Pietrzak. Depth-robust graphs and their cumulative memory complexity. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 3–32. Springer, 2017. [10] Joël Alwen, Binyi Chen, Chethan Kamath, Vladimir Kolmogorov, Krzysztof Pietrzak, and Stefano Tessaro. On the complexity of scrypt and proofs of space in the parallel random oracle model. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 358–387. Springer, 2016.

101 [11] Joël Alwen, Binyi Chen, Krzysztof Pietrzak, Leonid Reyzin, and Stefano Tessaro. Scrypt is maximally memory-hard. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 33–62. Springer, 2017.

[12] Joël Alwen, Peter Gazi, Chethan Kamath, Karen Klein, Georg Osang, Krzysztof Pietrzak, Lenoid Reyzin, Michal Rolínek, and Michal Rybár. On the memory-hardness of data- independent password-hashing functions. In Proceedings of the 2018 on Asia Conference on Computer and Communications Security, pages 51–65. ACM, 2018.

[13] Joël Alwen and Vladimir Serbinenko. High parallel complexity graphs and memory-hard functions. In Proceedings of the Forty-Seventh Annual ACM on Symposium on Theory of Computing, pages 595–603. ACM, 2015.

[14] Bharadwaj Amrutur and Mark Horowitz. Speed and power scaling of SRAMs. IEEE journal of solid-state circuits, 35(2):175–185, 2000.

[15] David G. Andersen. Exploiting time-memory tradeoffs in cuckoo cycle, 2014. (Accessed August 2016) https://www.cs.cmu.edu/ dga/crypto/cuckoo/analysis.pdf.

[16] D. F. Aranha and C. P. L. Gouvêa. RELIC is an Efficient LIbrary for Cryptography. https: //github.com/relic-toolkit/relic.

[17] Giuseppe Ateniese, Ilario Bonacina, Antonio Faonio, and Nicola Galesi. Proofs of space: when space is of the essence. In Security and Cryptography for Networks, pages 538–557. Springer, 2014.

[18] Paulo S. L. M. Barreto and Michael Naehrig. Pairing-friendly elliptic curves of prime order. In International Workshop on Selected Areas in Cryptography, pages 319–331. Springer, 2005.

[19] Leonid Alexandrovich Bassalygo. Asymptotically optimal switching circuits. Problemy Peredachi Informatsii, 17(3):81–88, 1981.

[20] Laszlo A. Belady. A study of replacement algorithms for a virtual-storage computer. IBM Systems journal, 5(2):78–101, 1966.

[21] Mihir Bellare and Gregory Neven. Multi-signatures in the plain public-key model and a general forking lemma. In Proceedings of the 13th ACM conference on Computer and communications security, pages 390–399. ACM, 2006.

[22] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In Proceedings of the 1st ACM conference on Computer and communications security, pages 62–73. ACM, 1993.

[23] Michael Ben-Or. Another advantage of free choice (extended abstract): Completely asyn- chronous agreement protocols. In Proceedings of the second annual ACM symposium on Principles of distributed computing, pages 27–30. ACM, 1983.

[24] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. Cryptocurrencies without proof of work. In International Conference on Financial Cryptography and Data Security, pages 142–157. Springer, 2016.

102 [25] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-security signatures. Journal of Cryptographic Engineering, 2(2):77–89, 2012.

[26] Alysson Bessani, João Sousa, and Eduardo E. P. Alchieri. State machine replication for the masses with BFT-SMaRt. In Dependable Systems and Networks (DSN), 2014 44th Annual IEEE/IFIP International Conference on, pages 355–362. IEEE, 2014.

[27] Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich. Fast and tradeoff-resilient memory- hard functions for cryptocurrencies and password hashing. IACR Cryptology ePrint Archive, Report 2015/430, 2015.

[28] Alex Biryukov and Dmitry Khovratovich. Tradeoff cryptanalysis of memory-hard functions. In International Conference on the Theory and Application of Cryptology and Information Security, pages 633–657. Springer, 2014.

[29] Alex Biryukov and Dmitry Khovratovich. Egalitarian computing. In USENIX Security Symposium, 2016.

[30] Alex Biryukov and Dmitry Khovratovich. Equihash: Asymmetric proof-of-work based on the generalized birthday problem. In NDSS, 2016.

[31] Bryan Black, Murali Annavaram, Ned Brekelbaum, John DeVale, Lei Jiang, Gabriel H. Loh, Don McCaule, Pat Morrow, Donald W. Nelson, Daniel Pantuso, et al. Die stacking (3D) microarchitecture. In Proceedings of the 39th Annual IEEE/ACM International Symposium on Microarchitecture, pages 469–479. IEEE Computer Society, 2006.

[32] Jeremiah Blocki, Ling Ren, and Samson Zhou. Bandwidth-hard functions: Reductions and lower bounds. Cryptology ePrint Archive, Report 2018/221, 2018.

[33] Dan Boneh, Henry Corrigan-Gibbs, and Stuart Schechter. Balloon hashing: A memory-hard function providing provable protection against sequential attacks. In International Conference on the Theory and Application of Cryptology and Information Security, pages 220–248. Springer, 2016.

[34] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verifiably en- crypted signatures from bilinear maps. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 416–432. Springer, 2003.

[35] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the Weil pairing. In International Conference on the Theory and Application of Cryptology and Information Security, pages 514–532. Springer, 2001.

[36] Gabriel Bracha. Asynchronous byzantine agreement protocols. Information and Computation, 75(2):130–143, 1987.

[37] William F. Bradley. Superconcentration on a pair of butterflies. CoRR, abs/1401.7263, 2014.

[38] Vitalik Buterin and Virgil Griffith. Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437, 2017.

103 [39] Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. Secure and efficient asynchronous broadcast protocols. In Annual International Cryptology Conference, pages 524–541. Springer, 2001.

[40] Christian Cachin, Klaus Kursawe, and Victor Shoup. Random oracles in Constantinople: Practical asynchronous byzantine agreement using cryptography. Journal of Cryptology, 18(3):219–246, 2005.

[41] Miguel Castro and Barbara Liskov. Authenticated byzantine fault tolerance without public-key cryptography. Technical report, MIT, 1999.

[42] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In OSDI, volume 99, pages 173–186, 1999.

[43] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance and proactive recovery. ACM Transactions on Computer Systems, 20(4):398–461, 2002.

[44] Tushar Deepak Chandra and Sam Toueg. Unreliable failure detectors for reliable distributed systems. Journal of the ACM (JACM), 43(2):225–267, 1996.

[45] F. R. K. Chung. On concentrators, superconcentrators, generalizers, and nonblocking networks. Bell System Technical Journal, 58(8):1765–1777, 1979.

[46] Stephen A. Cook. An observation on time-storage trade off. In Proceedings of the fifth annual ACM symposium on Theory of computing, pages 29–33. ACM, 1973.

[47] Miguel Correia, Nuno Ferreira Neves, and Paulo Veríssimo. From consensus to atomic broadcast: Time-free byzantine-resistant protocols without signatures. The Computer Journal, 49(1):82–96, 2005.

[48] James Cowling, Daniel Myers, Barbara Liskov, Rodrigo Rodrigues, and Liuba Shrira. HQ replication: A hybrid quorum protocol for byzantine fault tolerance. In 7th symposium on Operating systems design and implementation, pages 177–190. USENIX Association, 2006.

[49] Flaviu Cristian, Houtan Aghili, Ray Strong, and Danny Dolev. Atomic broadcast: From simple message diffusion to byzantine agreement. Information and Computation, 118(1):158, 1995.

[50] Bernardo David, Peter Gaži, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 66–98. Springer, 2018.

[51] Christian Decker, Jochen Seidel, and Roger Wattenhofer. Bitcoin meets strong consistency. In Proceedings of the 17th International Conference on Distributed Computing and Networking, page 13. ACM, 2016.

[52] Xavier Défago, André Schiper, and Péter Urbán. Total order broadcast and multicast algorithms: Taxonomy and survey. ACM Computing Surveys, 36(4):372–421, 2004.

[53] Digiconomist. Bitcoin energy consumption index. https://digiconomist.net/bitcoin-energy- consumption, Retrieved June 7, 2018.

104 [54] Itai Dinur and Niv Nadler. Time-memory tradeoff attacks on the mtp proof-of-work scheme. In Annual International Cryptology Conference, pages 375–403. Springer, 2017.

[55] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable random function with short proofs and keys. In International Workshop on Public Key Cryptography, pages 416–431. Springer, 2005.

[56] Danny Dolev, Cynthia Dwork, and Larry Stockmeyer. On the minimal synchronism needed for distributed consensus. Journal of the ACM (JACM), 34(1):77–97, 1987.

[57] Danny Dolev and H. Raymond Strong. Authenticated algorithms for byzantine agreement. SIAM Journal on Computing, 12(4):656–666, 1983.

[58] John R Douceur. The sybil attack. In International Workshop on Peer-to-Peer Systems, pages 251–260. Springer, 2002.

[59] Cynthia Dwork, Andrew Goldberg, and Moni Naor. On memory-bound functions for fighting spam. In Annual International Cryptology Conference, pages 426–444. Springer, 2003.

[60] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM, 35(2):288–323, 1988.

[61] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In Annual International Cryptology Conference, pages 139–147. Springer, 1992.

[62] Cynthia Dwork, Moni Naor, and Hoeteck Wee. Pebbling and proofs of work. In Annual International Cryptology Conference, pages 37–54. Springer, 2005.

[63] Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. Proofs of space. In Annual International Cryptology Conference, pages 585–605. Springer, 2015.

[64] Stefan Dziembowski, Tomasz Kazana, and Daniel Wichs. One-time computable self-erasing functions. In Theory of Cryptography, pages 125–143. Springer, 2011.

[65] Paul Erdős, Ronald L Graham, and Endre Szemeredi. On sparse graphs with dense long paths. Technical report, Stanford University, 1975.

[66] Ittay Eyal, Adem Efe Gencer, Emin Gün Sirer, and Robbert Van Renesse. Bitcoin-NG: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 45–59, 2016.

[67] Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining is vulnerable. In International Conference on Financial Cryptography and Data Security, pages 436–454. Springer, 2014.

[68] Pesech Feldman and Silvio Micali. An optimal probabilistic protocol for synchronous byzantine agreement. SIAM Journal on Computing, 26(4):873–933, 1997.

[69] Michael J. Fischer and Nancy A. Lynch. A lower bound for the time to assure interactive consistency. Information processing letters, 14(4):183–186, 1982.

105 [70] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374–382, 1985.

[71] Bryan Ford. Untangling mining incentives in bitcoin and byzcoin, 2016. http://bford.github.io/2016/10/25/mining/.

[72] Christian Forler, Eik List, Stefan Lucks, and Jakob Wenzel. Overview of the candidates for the password hashing competition, 2015.

[73] Christian Forler, Stefan Lucks, and Jakob Wenzel. Catena : A memory-consuming password- scrambling framework. In International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2014.

[74] Matthew Franklin and Haibin Zhang. Unique ring signatures: A practical construction. In International Conference on Financial Cryptography and Data Security, pages 162–170. Springer, 2013.

[75] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The Bitcoin backbone protocol: Analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 281–310. Springer, 2015.

[76] Juan A. Garay and Yoram Moses. Fully polynomial byzantine agreement for 푛 > 3푓 processors in 푓 + 1 rounds. SIAM Journal on Computing, 27(1):247–290, 1998.

[77] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, pages 51–68. ACM, 2017.

[78] Vassos Hadzilacos and Sam Toueg. A modular approach to fault-tolerant broadcasts and related problems. Technical report, Cornell University, 1994.

[79] Jia-Wei Hong and Hsiang-Tsung Kung. I/O complexity: The red-blue pebble game. In Proceedings of the thirteenth annual ACM Symposium on Theory of computing, pages 326–333. ACM, 1981.

[80] John Hopcroft, Wolfgang Paul, and Leslie Valiant. On time versus space and related problems. In 16th Annual Symposium on Foundations of Computer Science, pages 57–64. IEEE, 1975.

[81] Mark Horowitz. Computing’s energy problem (and what we can do about it). In Solid-State Circuits Conference Digest of Technical Papers (ISSCC), 2014 IEEE International, pages 10–14. IEEE, 2014.

[82] Intel. Intel advanced encryption standard instructions (AES-NI). https://software.intel. com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni. Ac- cessed: 2017-02-04.

[83] Intel. Intel power gadget. https://software.intel.com/en-us/articles/ intel-power-gadget-20. Accessed: 2017-02-04.

[84] Intel. Intel SHA extensions. https://software.intel.com/en-us/articles/ intel-sha-extensions, 2013. Accessed: 2017-02-04.

106 [85] Kazuharu Itakura. A public-key cryptosystem suitable for digital multisignatures. NEC J. Res. Dev., 71, 1983.

[86] Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic curve digital signature algorithm (ecdsa). International Journal of Information Security, 1(1):36–63, 2001.

[87] Flavio P. Junqueira, Benjamin C. Reed, and Marco Serafini. Zab: High-performance broadcast for primary-backup systems. In Dependable Systems & Networks (DSN), 2011 IEEE/IFIP 41st International Conference on, pages 245–256. IEEE, 2011.

[88] Nikolaos P. Karvelas and Aggelos Kiayias. Efficient proofs of secure erasure. In Security and Cryptography for Networks, pages 520–537. Springer, 2014.

[89] Jonathan Katz and Chiu-Yuen Koo. On expected constant-round protocols for Byzantine agreement. In Annual International Cryptology Conference, volume 4117, pages 445–462. Springer, 2006.

[90] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.

[91] Sunny King and Scott Nadal. Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. https://peercoin.net/assets/paper/peercoin-paper.pdf (Retrived June 19, 2018), 2012.

[92] Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. Enhancing Bitcoin security and performance with strong consistency via collective signing. In 25th USENIX Security Symposium, pages 279–296. USENIX Association, 2016.

[93] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford. Omniledger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP), pages 583–598. IEEE, 2018.

[94] Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: speculative byzantine fault tolerance. In ACM SIGOPS Operating Systems Review, volume 41, pages 45–58. ACM, 2007.

[95] Ramakrishna Kotla and Mike Dahlin. High throughput byzantine fault tolerance. In Dependable Systems and Networks, pages 575–584. IEEE, 2004.

[96] John Kubiatowicz, David Bindel, Yan Chen, Steven Czerwinski, Patrick Eaton, Dennis Geels, Ramakrishan Gummadi, Sean Rhea, Hakim Weatherspoon, Westley Weimer, and Ben Zhao. Oceanstore: An architecture for global-scale persistent storage. ACM Sigplan Notices, 35(11):190–201, 2000.

[97] Jae Kwon. Tendermint: Consensus without mining, 2016.

[98] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communica- tions of the ACM, 21(7):558–565, 1978.

[99] Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems, 16(2):133– 169, 1998.

107 [100] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3):382–401, 1982.

[101] Thomas Lengauer and Robert E. Tarjan. Asymptotically tight bounds on time-space trade-offs in a pebble game. Journal of the ACM, 29(4):1087–1130, 1982.

[102] Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar. Inclusive block chain protocols. In International Conference on Financial Cryptography and Data Security, pages 528–547. Springer, 2015.

[103] Yehuda Lindell, Anna Lysyanskaya, and Tal Rabin. Sequential composition of protocols without simultaneous termination. In Proceedings of the twenty-first annual symposium on Principles of distributed computing, pages 203–212. ACM, 2002.

[104] Barbara Liskov and James Cowling. Viewstamped replication revisited. Tech report: MIT- CSAIL-TR-2012-021, 2012.

[105] Shengyun Liu, Christian Cachin, Vivien Quéma, and Marko Vukolic. XFT: practical fault tolerance beyond crashes. In 12th USENIX Symposium on Operating Systems Design and Implementation, pages 485–500. USENIX Association, 2016.

[106] Jacob R. Lorch, Atul Adya, William J. Bolosky, Ronnie Chaiken, John R. Douceur, and Jon Howell. The SMART way to migrate replicated stateful services. In ACM SIGOPS Operating Systems Review, volume 40, pages 103–115. ACM, 2006.

[107] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 17–30. ACM, 2016.

[108] Mohammad Mahmoody, Tal Moran, and Salil Vadhan. Publicly verifiable proofs of sequential work. In Proceedings of the 4th conference on Innovations in Theoretical Computer Science, pages 373–388. ACM, 2013.

[109] J-P Martin and Lorenzo Alvisi. Fast byzantine consensus. IEEE Transactions on Dependable and Secure Computing, 3(3):202–215, 2006.

[110] Carver A. Mead and Martin Rem. Cost and performance of VLSI computing structures. IEEE Transactions on Electron Devices, 26(4):533–540, 1979.

[111] Silvio Micali. Algorand: The efficient and democratic ledger. arXiv:1607.01341, 2016.

[112] Silvio Micali, Michael Rabin, and Salil Vadhan. Verifiable random functions. In Foundations of Computer Science, 1999. 40th Annual Symposium on, pages 120–130. IEEE, 1999.

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

[114] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.

108 [115] Kartik Nayak, Srijan Kumar, Andrew Miller, and Elaine Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In 2016 IEEE European Symposium on Security and Privacy (EuroS&P), pages 305–320. IEEE, 2016.

[116] Tsuen-Wan “Johnny” Ngan, Dan S. Wallach, and Peter Druschel. Enforcing fair sharing of peer-to-peer resources. In International Workshop on Peer-to-Peer Systems, pages 149–159. Springer, 2003.

[117] Tatsuaki Okamoto. A digital multisignature scheme using bijective public-key cryptosystems. ACM Transactions on Computer Systems (TOCS), 6(4):432–441, 1988.

[118] Diego Ongaro and John K. Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference, pages 305–319, 2014.

[119] Sunoo Park, Albert Kwon, Joël Alwen, Georg Fuchsbauer, Peter Gazi, and Krzysztof Pietrzak. Spacemint: A cryptocurrency based on proofs of space. In Financial Cryptography and Data Security, 2018.

[120] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 643–673. Springer, 2017.

[121] Rafael Pass and Elaine Shi. Feasibilities and infeasibilities for achieving responsiveness in permissionless consensus. In International Symposium on Distributed Computing. Springer, 2017.

[122] Rafael Pass and Elaine Shi. FruitChains: A fair blockchain. In Proceedings of the ACM Symposium on Principles of Distributed Computing, pages 315–324. ACM, 2017.

[123] Rafael Pass and Elaine Shi. Thunderella: Blockchains with optimistic instant confirmation. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 3–33. Springer, 2018.

[124] Wolfgang J. Paul and Robert E. Tarjan. Time-space trade-offs in a pebble game. Acta Informatica, 10(2):111–115, 1978.

[125] Wolfgang J. Paul, Robert E. Tarjan, and James R. Celoni. Space bounds for a game on graphs. Mathematical Systems Theory, 10(1):239–251, 1976.

[126] Marshall Pease, Robert Shostak, and Leslie Lamport. Reaching agreement in the presence of faults. Journal of the ACM (JACM), 27(2):228–234, 1980.

[127] Ardavan Pedram, Stephen Richardson, Sameh Galal, Shahar Kvatinsky, and Mark Horowitz. Dark memory and accelerator-rich system optimization in the dark silicon era. IEEE Design & Test, 2016.

[128] Colin Percival. Stronger key derivation via sequential memory-hard functions, 2009.

[129] Daniele Perito and Gene Tsudik. Secure code update for embedded devices via proofs of secure erasure. In ESORICS, pages 643–662. Springer, 2010.

109 [130] Alexander Peslyak. yescrypt - a password hashing competition submission, 2014. (Accessed August 2016) https://password-hashing.net/submissions/specs/yescrypt-v2.pdf.

[131] Mark S. Pinsker. On the complexity of a concentrator. In 7th International Telegraffic Conference, volume 4, 1973.

[132] Joseph Poon and Thaddeus Dryja. The Bitcoin lightning network: Scalable off-chain instant payments. Technical Report. https://lightning.network, 2015.

[133] Michael O. Rabin. Randomized byzantine generals. In Proceedings of the 24th Annual Symposium on Foundations of Computer Science, pages 403–409. IEEE, 1983.

[134] Michael K. Reiter. The Rampart toolkit for building high-integrity services. In Theory and Practice in Distributed Systems, pages 99–110. Springer, 1995.

[135] Herbert Robbins. A remark on Stirling’s formula. The American Mathematical Monthly, 62(1):26–29, 1955.

[136] Rodrigo Rodrigues, Miguel Castro, and Barbara Liskov. BASE: Using abstraction to improve fault tolerance. In ACM SIGOPS Operating Systems Review, volume 35, pages 15–28. ACM, 2001.

[137] Fred B Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Computing Surveys, 22(4):299–319, 1990.

[138] Claus-Peter Schnorr. Efficient identification and signatures for smart cards. In Conference on the Theory and Application of Cryptology, pages 239–252. Springer, 1989.

[139] Uwe Schöning. Better expanders and superconcentrators by kolmogorov complexity. In SIROCCO, pages 138–150, 1997.

[140] Ravi Sethi. Complete register allocation problems. SIAM journal on Computing, 4(3):226–248, 1975.

[141] Adam Smith and Ye Zhang. Near-linear time, leakage-resilient key evolution schemes from expander graphs. Cryptology ePrint Archive, Report 2013/864, 2013.

[142] Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar. SPECTRE: A fast and scalable cryptocurrency protocol, 2016.

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

[144] John Tromp. Cuckoo cycle: a memory-hard proof-of-work system, 2014.

[145] Leslie G. Valiant. Graph-theoretic arguments in low-level complexity. In International Symposium on Mathematical Foundations of Computer Science, pages 162–176. Springer, 1977.

[146] Robbert Van Renesse, Chi Ho, and Nicolas Schiper. Byzantine chain replication. In International Conference On Principles Of Distributed Systems, pages 345–359. Springer, 2012.

110 [147] Wikipedia. List of countries by electricity consumption. https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption, Retrieved June 7, 2018.

[148] Xilinx. High Speed Serial. https://www.xilinx.com/products/technology/ high-speed-serial.html. Accessed: 2017-02-04.

[149] Chun Jason Xue, Guangyu Sun, Youtao Zhang, J Joshua Yang, Yiran Chen, and Hai Li. Emerging non-volatile memories: opportunities and challenges. In Hardware/Software Codesign and System Synthesis, 2011 Proceedings of the 9th International Conference on, pages 325–334. IEEE, 2011.

[150] Jian Yin, Jean-Philippe Martin, Arun Venkataramani, Lorenzo Alvisi, and Mike Dahlin. Separating agreement from execution for byzantine fault tolerant services. ACM SIGOPS Operating Systems Review, 37(5):253–267, 2003.

[151] Lidong Zhou, Fred Schneider, and Robbert van Renesse. COCA: A secure distributed online certification authority. ACM Transactions on Computer Systems, 20(4):329–368, 2002.

111