Bringing Consensus to Consensusless Cryptocurrencies

Miguel Barros Advisors: Jo˜aoBarreto and Miguel Matos

Instituto Superior T´ecnico,Universidade de Lisboa

Abstract. Blockchain systems are becoming more and more popular. These systems are typically used to replicate two classes of applications: cryptocurrencies and smart contracts; with strong consistency guarantees. Recent results have shown that cryptocurrencies can be implemented without the need for strong consistency, opening the door for faster consensusless cryptocurrencies. Despite this, for real-world systems, some cryptocurrency management operations still require strong consistency, as do smart contracts. These consistency requirements are typically achieved using consensus protocols, which are expensive, resulting in signiﬁcantly slower performance for the operations that use them. This thesis aims at studying more eﬃcient protocols that can be built on top of consensusless cryptocurrencies to obtain strong consistency.

Keywords: Blockchain · Hybrid Consistency · Epidemic Voting · Con- sensus · Proof-of-Stake Table of Contents

1 Introduction ...... 3 1.1 Motivation ...... 3 Cryptocurrencies ...... 3 Smart Contracts ...... 4 1.2 Objectives ...... 5 2 Background and Related Work ...... 5 2.1 Blockchain ...... 5 Proof of work and Nakamoto Consensus ...... 7 Properties ...... 8 Alternatives to Proof of Work ...... 9 Applications ...... 9 2.2 Proof-of-Stake ...... 10 2.3 Consensusless Cryptocurrencies ...... 11 2.4 Epidemic Quorum Systems ...... 13 Elections ...... 14 Unit Allocation ...... 14 Fault Detection and Handling ...... 14 Correctness ...... 15 2.5 Discussion ...... 15 3 Xenochain ...... 16 3.1 Overview ...... 16 3.2 System Model ...... 17 3.3 Consensusless Cryptocurrency Model ...... 18 3.4 Protocol ...... 19 3.5 Analysis ...... 20 3.6 Open Problems ...... 20 4 Evaluation Methodology ...... 21 5 Scheduling ...... 21 6 Conclusion ...... 22 Bringing Consensus to Consensusless Cryptocurrencies 3

1 Introduction

Since their inception, blockchains quickly rose in popularity. These systems are attractive due to their decentralization and scalability. The majority of mainstream blockchains, such as Bitcoin [25] and Ethereum [32] provide strong consistency guarantees (specifically total order) using Nakamoto Consensus, which is based on Proof-of-Work. This protocol (and its alternatives) can be seen as a probabilistic, totally- ordered broadcast service for permissionless, byzantine environments. Applica- tions can obtain strong consistency guarantees by issuing transactions in the blockchain and waiting for the transactions to be committed by the system. Blockchains can be used for two classes of applications: cryptocurrencies, decentralized asset transfer systems; and smart contracts, general-purpose programs. Each class of application has different consistency requirements. While smart contracts typically require strong consistency, recent work by Guerraoui et al. [20] showed that cryptocurrencies have weaker consistency demands, and can be cor- rectly implemented without resorting to consensus. The fact that cryptocurrencies can be implemented without the strong consistency guarantees that traditional blockchains provide has opened the door to new generations of consensusless cryptocurrency protocols, which are typically an order of magnitude faster than traditional blockchain protocols. For example, Astro [14] implements decentralized asset transfers in a permissioned setting using only byzantine reliable broadcast primitives, and Par- menides [29] supports consensusless cryptocurrencies in a permissionless setting by allowing applications to choose between different consistency levels for their operations. Despite this, a completely consensusless blockchain is not viable in the real world, since it must support smart contracts and less common cryptocurrency operations that have strong consistency requirements.

1.1 Motivation

In this section, we show real-world examples of both classes of blockchain applications that have some operations requiring strong consistency and thus cannot be fully implemented using consensusless cryptocurrency protocols.

Cryptocurrencies Despite their name, real-world consensusless cryptocurrencies often have some operations requiring stronger consistency requirements. For example, systems implementing cryptocurrencies in a permissioned setting, like the one developed by Guerraoui et al. [14] must support reconﬁguration: the joining and leaving of participants, to be viable for long term deployment. Reconﬁguration typically requires running a consensus protocol whenever some- one joins or leaves the system to decide the view (i.e. the current members of the system). 4 Miguel Barros

Another example is the ERC20 standard [31], which deﬁnes tokens that can be used for smart contract applications. A token is similar to a cryptocurrency, but with the added functionality that the owner can allow other processes to withdraw up to a certain number of tokens from his account. Once a token account is shared by more than one process, all transfer operations require strong consistency guarantees [20].

Smart Contracts Systems that wish to support smart contracts must provide strong consistency guarantees since these typically require total order, which is a problem equivalent to consensus. To show this, let us consider the following smart contract example implementing a cupcake vending machine taken from the Ethereum documentation [30]. 1 pragma solidity 0.6.11; 2 contract VendingMachine{ 3 4 address public owner; 5 mapping(address => uint) public cupcakeBalances; 6 7 constructor() public{ 8 owner= msg.sender; 9 cupcakeBalances[address(this)] = 100; 10 } 11 12 function refill(uint amount) public{ 13 require(msg.sender == owner,"Only the owner can refill."); 14 cupcakeBalances[address(this)] += amount; 15 } 16 17 function purchase(uint amount) public payable{ 18 require(msg.value >= amount*1 ether,"You must pay atleast1ETH per cupcake"); 19 require(cupcakeBalances[address(this)] >= amount," Not enough cupcakes in stock to complete this purchase"); 20 cupcakeBalances[address(this)] -= amount; 21 cupcakeBalances[msg.sender] += amount; 22 } 23 } The contract keeps track of the ownership of cupcakes and allows the reﬁlling of the vending machine (lines 12—15) and the purchase of cupcakes using eth, the Ethereum currency (method purchase in lines 17—22). The contract also enforces the invariant that the amount of cupcakes in the machine must always be greater or equal to zero (line 19). Let us consider the case where the machine initially has zero cupcakes and there are three pending transactions: T0 a reﬁll of 10 cupcakes, T1 and T2 a purchase, each of 10 cupcakes. Bringing Consensus to Consensusless Cryptocurrencies 5

Since T1 and T2 rely on the observation that there are 10 cupcakes available, they causally depend on T0, meaning they can only be committed after it. However, satisfying the causal dependencies T0 → T1 and T0 → T2 is not enough to guarantee a consistent ﬁnal state. Since only the ﬁrst of the two transactions T1 and T2 committed will be successful, total order among these two transactions is also necessary.

1.2 Objectives As shown previously, an alternative to consensusless protocols with stronger consistency guarantees is necessary to fully support both classes of blockchain applications. To solve this problem, Parmenides [29] offers a strongly consistent view of the system that relies on Nakamoto Consensus, while Astro [14] implements reconfiguration using Byzantine Quorums [9]. These protocols are typically expensive, resulting in these operations having significantly slower performance than the rest of the system. This thesis aims at studying more efficient protocols than the state of the art, but that are still able to offer strong consistency guarantees. Specifically, we will explore epidemic voting protocols, proposed by Keleher et al. [22] whose consistency requirements are met by consensusless cryptocurrency protocols. Voting protocols allow a set of processes to agree on a value, among one or more values proposed, by running a set of elections. In each election, each process votes for one of the proposed values, and the winning value is mutually decided. These protocols are a natural fit for blockchain systems since they allow reaching agreement in a completely decentralized and weakly connected network. By tying voting power to the amount of cryptocurrency a process owns, they can be made resistant to Sybil attacks and malicious adversaries. The rest of this document is organized as follows. Section 2 provides background on permissionless blockchain systems and epidemic quorum protocols. Section 3 presents the first sketch of our protocol. Section 4 explains our plan for the evaluation of the protocol and Section 5 presents the scheduling of future work. Finally, Section 6 concludes and summarises the document.

2 Background and Related Work

In this section, we present the state of the art in blockchain systems, Proof-of- Stake protocols, consensusless cryptocurrencies, and epidemic quorum protocols.

2.1 Blockchain Blockchain systems were introduced by Satoshi Nakamoto [25] as a completely decentralized system for electronic payments allowing transactions between two parties that do not trust each other. 6 Miguel Barros

Fig. 1. Blockchain Structure

Fig. 2. Transaction Structure

A blockchain system implements a tamper-proof, totally-ordered distributed ledger of transactions. The system is composed of a set of processes organized in a peer-to-peer network. Each process has a local replica of the distributed ledger, which is possibly inconsistent, and a queue of individual transactions not yet included in the local ledger called the mempool. Each entry of the ledger is called a block, and is composed of the following: – A set of ordered transactions. – The cryptographic hash of the previous block in the ledger. This makes it practically impossible to change a block without also replacing all the following blocks in the blockchain. – A nonce used to check the validity of the block’s Proof of Work – A public key identifying the process that generated the block which is called the miner of the block Processes share the same first block of the blockchain, called the genesis block. Each transaction in the blockchain is composed of: – A public key identifying the process that issued the transaction – A sequence number, that defines the order of transactions issued by the same user – A transaction payload specific to the application (for example a cryptocurrency transaction or a smart contract function with some arguments) – A digital signature (using the private key of the issuer) to prevent forging. When a process issues a transaction, it broadcasts it to the peer-to-peer network. Transactions propagate in the network through a gossip protocol, and upon reception, are added to the processes mempool. By definition, transactions issued by correct processes always have incremental sequence numbers. A byzantine process, however, may issue two transactions with the same sequence Bringing Consensus to Consensusless Cryptocurrencies 7 number but different payloads, which prefigures a double-spending attack that the system must be resilient to. It is necessary that all processes eventually agree on the state of the distributed ledger. To do this, a consensus mechanism is used to decide the next block appended to the blockchain. For Bitcoin and Ethereum, the consensus mechanism is known as Nakamoto Consensus and it relies on Proof-of-Work, which we detail later. Blockchain systems come in two variants: – Permissionless: Anyone can join the system, issue transactions, and see them being committed. There is no access control mechanism, making the system fully decentralized. This complicates system design as there is no way of knowing the number of processes participating in the system at any given time (necessary for classical consensus protocols). It also enables ”Sybil attacks”, where an attacker creates countless numbers of identities and gains control of the system. – Permissioned: Have an access control mechanism, controlling who can join the system and issue transactions. This makes the system centralized, but allows knowing the number of participants, and thus rely on classical consensus protocols

Proof of work and Nakamoto Consensus To achieve consensus on a totally- ordered distributed ledger despite Sybil attacks, an unforgeable resource must be tied to appending a block in the blockchain. In most mainstream permissionless blockchains the resource is CPU time. A process that wishes to append a block in the distributed ledger must produce a Proof-of-Work object. To do so, it must solve a computationally difficult puzzle consisting of finding a nonce such that the hash of the new block begins with a certain number of zeroes. Since cryptographic hash functions are hard to invert, the only chance of solving the puzzle is to brute force it [4]. Once a process is successful in solving the Proof-of-Work, it broadcasts the corresponding block through the peer network. Other processes validate the block’s transactions and the Proof-of-Work object. If valid, processes append the block to the local ledger, remove its transactions from the mempool (and any transactions that conflict with the block, including double-spend transactions), and start trying to produce a block to follow the new one in the ledger. Validating a Proof-of-Work is significantly easier than generating it, as it means calculating the hash of the received block and validating that it has a certain number of zeroes as a prefix. Due to concurrency, various blocks can be mined at the same time by different processes. This results in forks: different processes trying to append a block to different local ledgers. To solve this problem, processes replace their local ledger by one with more Proof-of-Work invested in it (typically the longest chain). This means that processes agree on an ever-increasing common prefix [17] of the blockchain but may see a previously appended block be replaced by a different block of a longer chain. 8 Miguel Barros

To remove a transaction from the blockchain, stored in a block with depth z (defined as the number of blocks appended to it in the ledger), an adversary must be able to create a longer chain. By fixing the mining power of the adversary and modeling the Proof of Work as a Poisson process, we can calculate the probability of an attacker being successful in undoing a transaction as a function of z [26]. To prevent a committed block from being replaced, processes wait for a block to be deep enough in the blockchain that the probability of it being replaced by a longer chain is marginal, before considering it committed. In the Bitcoin blockchain this value is 12 blocks and in the Ethereum blockchain it is 6 blocks. By waiting for a transaction to be in a committed block, processes can be certain that the probability of there being a longer chain containing a double- spending of that transaction is very low. The time it takes to solve the Proof-of-Work puzzle is a parameter of the system. As such, the puzzle difficulty (i.e. the number of zeros the hash of the block must start with) is dynamically adjusted to compensate for improving hardware being able to solve the Proof-of-Work faster. This means that the throughput of the system is roughly constant. In the Bitcoin and Ethereum blockchain, a block is mined every 10 minutes and 20 seconds respectively. The resulting commit latency (measured as the time it takes for an issued transaction to be considered committed) is the product of the time it takes to produce a block (D) and the depth a block must have to be considered committed (z). This value is 1 hour in Bitcoin and 4 minutes in Ethereum. The combination of Proof of Work and the Longest Chain Rule is commonly known as Nakamoto Consensus or Proof-of-Work Consensus.

Properties Pash and Shi[28] provide a formal analysis of Nakamoto Consensus, using the following assumptions:

– Adversaries control less than 50% of the CPU resource in the system and cannot break the hash function – Transactions and blocks broadcast by correct processes are delivered to every correct process with high probability and with a maximum delay D. – The time to solve the Proof-of-Work puzzle and thus generate a block is constant and much larger than D.

The authors prove the following set of guarantees:

– Agreement: If a correct process commits a transaction, all correct processes eventually commit that transaction with high probability – No duplication: Every correct process commits a transaction at most once – Total order: If a correct process commits t1 before t2, every correct process commits t1 before t2 with high probability- – Double-spending Tolerance: If a correct process commits transaction t, no correct processes commits any double-spending transaction of t, with high probability. Bringing Consensus to Consensusless Cryptocurrencies 9

Alternatives to Proof of Work Nakamoto Consensus is the permissionless consensus protocol employed in the two most popular blockchains: Bitcoin and Ethereum. It does however have serious drawbacks, such as high commit latency and limited throughput. The protocol is also computationally expensive and results in high energy consumption(In Bitcoin, 14 Megajoules are consumed for every dollar’s worth of bitcoin generated [23]). These limitations motivated research in alternative permissionless consensus protocols, normally relying on proof of some other unforgeable resource:

– Proof-of-Space: Disk space is the resource. Processes must generate a very large data structure on disk to append a block to the blockchain. The Spacemint [27] and Chia [13] blockchains use this approach. – Proof-of-Stake: Use a cryptocurrency as the unforgeable resource. Pro- cesses vote with their coins on the block appended to the blockchain. Ethereum’s Casper protocol [8] is an example of this approach. We present these protocols and their limitations in more detail in Section 2.2. – Committee: Use the unforgeable resource to elect a committee of participants, who then use classical byzantine consensus protocols to select the next block appended. The Solida [1] and Algorand [18] blockchains use Proof-of- Work and Proof-of-stake respectively to select the members of the committee.

Applications The properties provided by Blockchain systems are typically leveraged to support two types of applications: Cryptocurrencies and Smart Contracts. Cryptocurrencies are the most common use of blockchains. They serve as a completely decentralized digital coin to be traded, and as an incentive for nodes to support the network with their CPU time. Each transaction yields a fee to the miner responsible for appending it to the ledger. Additionally, each block mined awards a new coin to the successful miner. Once a predetermined number of coins have been generated from mining, the incentive becomes based entirely on transaction fees. Due to the properties of Nakamoto Consensus, cryptocurrencies work cor- rectly even in the presence of a malicious node attempting a double-spend attack (spend the same coin twice). The consensus protocol can also be used to support arbitrary programs, known as Smart Contracts, through state-machine replication. A smart contract is an automated, deterministic program running on top of the blockchain, composed of data and code (a set of operations that interact with the data). Processes interact with the program by broadcasting transactions that execute an operation deﬁned in the contract. Transactions are executed locally at each process in the order they are committed. 10 Miguel Barros

2.2 Proof-of-Stake Proof-of-Stake protocols were proposed as a way to eliminate the high energy cost involved in solving the Proof-of-work puzzle in Nakamoto Consensus[23]. They work by randomly selecting a committee of processes (called validators) which are then responsible for generating a block and appending it to the blockchain. The probability of a process being selected is directly proportional to its stake in the cryptocurrency (i.e. to the number of coins it holds), which they cannot forge, making the selection resistant to Sybil Attacks. For an adversary to increase the chances of being selected, it needs to purchase more stake in the currency, which comes at a cost. As stake switches hands in the system, the committee must be updated to reﬂect current stake distribution. This is an important security feature since processes may try to misbehave once they lose their stake in the system. [7] Members of the committee may also be randomly chosen as block proposers, responsible for generating blocks. The committee chooses which generated block to append via a permisssioned consensus protocol (this is equivalent to mining in a Proof-of-Work protocol, and similarly yields rewards). Daian et al. [15] present the conditions for a suitable consensus protocol in Proof-of-Stake systems. These are:

– The participants should have voting rights weighted by their respective stake amount – The protocol should be robust in the presence of sporadic participation. In particular, progress should be made even if fewer than anticipated processes participate in the protocol. – It should be impractical for an adversary to corrupt the committee selection process. This is tied to the source of randomness used in the committee selection process. If this can be subjected to adversarial inﬂuence, it can be biased in a way that allows corrupt processes to be selected to the committee or to be chosen as a block proposer more often. – The protocol should be robust to costless simulation attacks. These attacks may happen if an adversary holds more than half the stake in a past committee. If so, after selling his stake, the adversary can fork the history of transactions from the point at which they controlled the majority of the stake in the committee and generate an alternate history where they always maintain the majority of stake, sustaining the attack.

Under these constraints, it is possible to prove that the Proof-of-Stake protocol is secure provided the adversary owns a minority of stake in the system and money is not transferred too fast [15]. Cohen et al. [7] provide a formal analysis of Proof-of-Stake protocols and their limitations. At the heart of these limitations is the nothing-at-stake problem. Since deviations from the protocol consume no resources, there is no reason not to misbehave. This results in a nothing-at-stake attack, where a process creates a fork from an outdated history of the ledger and starts mining on top of it as well. The process effectively attempts to mine on top of multiple blocks, which Bringing Consensus to Consensusless Cryptocurrencies 11 it can trivially do since mining no longer requires investing large computational power. The consensus protocol used can help mitigate such an attack. For example, Algorand [18] shows that the probability of a fork is negligible using its PBFT[11] based protocol under their network model, and as such behavior that results in a fork can be detected and ignored. Ethereum’s Casper protocol [8] presents another possible mitigation by pun- ishing miners whose blocks end up being discarded by the system. This however results in well-behaved miners being punished by bad luck, and there is no formal proof it works. Another possible attack is the selfish mining attack. In it, a process does not broadcast a block B upon creating it. Instead, it continues generating blocks on top of it, faster than the network can generate blocks on top of the predecessor of B. It continues doing this while it possesses the longest chain. Finally, the process broadcasts its longer chain, causing the rest of the network to abandon the current chain and adopt the new one. There is no risk in doing this and the benefit is that the process obtains the rewards of mining the longest chain. There are ways to mitigate such attacks. These involve designing protocols where blocks need to be supported once mined. The ability to support a block is once again tied to the stake a process owns. A selfish miner would thus need not only a longer chain but also a majority of support tokens to succeed. The Snow White blockchain [15] is an example of a system where such deviations from the protocol yield a minimal mining reward (though the attack is not strictly disincentivized).

2.3 Consensusless Cryptocurrencies At the heart of cryptocurrencies is the problem of preventing double-spending i.e., spending the same currency more than once. In blockchain systems, this is normally achieved by totally ordering all issued transactions using a consensus protocol. Recent results by Guerraoui et al. [20] proved that cryptocurrencies can be supported without consensus. More specifically it modeled the asset transfer problem as a sequential object and proved that it has consensus number one in Herlihy’s hierarchy [21], assuming every account is owned by only one process, i.e. only one process can execute outgoing transfers from an account. This is because most operations in a cryptocurrency system commute, i.e., different processes can apply the operations in any arbitrary order and end in the same final state. For instance, a transfer T1 from Alice to Bob commutes with a transfer T2 from Carol to Drake since the two transfers involve different accounts. In the absence of other transfers, T1 and T2 can be applied in different orders by different processes, resulting in the same final state. A transaction T0 from Alice to Carol, however, does not commute with T1 since both involve the same account—that of Alice—and she may be unable to fulfill both T0 and T1 (due to insufficient balance). Assume that Alice issues T0 12 Miguel Barros

Fig. 3. Causal dependencies between transfers T0, T1 and T2. (Taken from [19]) before T1. This means T1 depends on T0, and so T0 should be applied before T1. Suppose now that Carol does not have enough money in her account to fulfill T2 before she receives transfer T0 from Alice. T2 then depends on T0 and all processes should apply T0 before applying T2. Note that transfers T1 and T2 still commute. Intuitively, the ordering constraint to enforce in the system is that every outgoing transfer for an account causally depends on all preceding transfers (both incoming and outgoing) involving that account. This constraint can be achieved without consensus. This opens the door to create much more efficient cryptocurrencies since consensus is the major bottleneck in blockchain protocols. Following this result, Guerraoui et al. [14] developed Astro, a completely decentralized, permissioned system supporting asset transfer in an asynchronous network without consensus. Instead, Astro relies only on byzantine reliable broadcast primitives based on Bracha’s algorithm [6], resulting in a more simple and efficient implementation than consensus-based payment systems. Despite this, Astro still has strong consistency requirements for operations related to membership changes (i.e. the joining and leaving of replicas). These operations are necessary for any real-world system, meaning any realistic cryptocurrency requires a protocol providing strong consistency (though there are systems that achieve this without consensus in the crash model [3] [2]). The full details of how Astro handles membership changes are not known, but the authors mention using Byzantine Quorums [24] while adopting ideas from the Freestore protocol [3]. Implementing such a cryptocurrency in a permissionless setting has the additional challenge of preventing Sybil attacks. General-purpose blockchains must also take smart contracts into account, which generally have stronger consistency guarantees and thus still require consensus. Bringing Consensus to Consensusless Cryptocurrencies 13

Silva et al. [29] propose Parmenides, the ﬁrst blockchain system to address this challenge, by providing a hybrid-consistency model, supporting both consensusless transactions and consensus-based transactions, provided by the underlying permissionless consensus protocol. This is achieved by providing two views of the distributed ledger:

– Admitted/Blue view: a weakly-consistent view of the distributed ledger providing causal consistency while preventing censorship and double-spending. This view can support cryptocurrency transactions and transactions from smart contracts with weaker consistency needs. – Committed/Red view: Classical view of the ledger, providing total order and supporting strongly consistent transactions.

Due to the admitted view not requiring consensus, its latency is an order of magnitude lower than the committed view. The two views are kept consistent, allowing an application to safely switch between them when invoking transactions in both views. Speciﬁcally, no transaction is committed/admitted before its causal dependencies.

2.4 Epidemic Quorum Systems

Epidemic Quorums were proposed by Keleher et al. [22,12] as a way to reach agreement in mobile, weakly-connected, non-byzantine, permissioned environments. These environments are similar to Blockchain systems in their decentralization but less hostile due to the absence of adversaries. Epidemic Quorum Systems combine epidemic information propagation with voting to reach agreement. The system model consists of a set of replica servers. Replicas are not necessarily directly connected and do not know all replicas that exist. Updates may be issued by any replica and propagate through the network in an epidemic fashion. To ensure consistency, all replicas must start from the same initial state and all commit all update events in the same order. This is typically achieved by running a consensus/agreement protocol. Voting protocols are one such example. They allow a quorum of interconnected replicas (i.e. a set of replicas that intersects with any other quorum) to commit an update. This way, two committed updates are serialized by the intersecting replica of the corresponding quorums. Epidemic Quorum Systems expand voting protocols in two ways:

1. There is a ﬁxed amount of voting units. There are divided among all replicas and are used to weight replicas. Unit allocation is not static and not known to replicas, but the total amount of units is ﬁxed and known. 2. Votes propagate through an epidemic protocol. This means the protocol can make progress and eventually commit an update even if there is not a quorum of replicas connected simultaneously. 14 Miguel Barros

Elections Update commitment is done through an election. Replicas hold one vote for each unit they have, and they vote for an arbitrary update. Vote counting is done in a decentralized manner. Each replica counts the votes it receives from other replicas and decides the outcome of the election. Once an update wins the election, it is committed locally and a new election begins. Replicas can be temporarily in diﬀerent elections. Elections end when an update receives a plurality of votes (i.e. more votes than any other update but not necessarily the majority of votes). Replicas do not need to wait for all votes to commit an update, they just need to receive enough votes for the winner of the election to be certain. If a tie occurs a deterministic tie-breaking criteria is used to commit one of the updates. Votes propagate through the system using a gossip protocol. Periodically, each replica contacts the other replicas it knows and exchange voting information (i.e. votes, election decisions, and updates)

Unit Allocation When a server joins the system, it contacts an existing replica and receives the current state and some units, subtracted from the existing replica. This means that unit distribution is not necessarily uniform. Replicas can also exchange units among themselves to make the unit distribution converge to a desirable state. Care must be taken to avoid the ﬂow of units from a replica that has voted in an election to a replica that has not. Replicas that are leaving the system designate a proxy replica that votes using their units, avoiding a loss of units in the system. There are two possible approaches to establishing proxies in replication protocols.

1. Explicitly transfer units to the proxy. Drawbacks to this approach are that the proxies become visible to all servers, and problems can arise from race conditions between voting and transferring units. 2. The leaving replica allows the proxy to vote in its place. When it reconnects, it updates its state to match the proxy. There are no race conditions and the proxy is transparent to the rest of the system. In case the leaving replica fails permanently the proxy votes with his units, making failures transparent.

Fault Detection and Handling If not detected, crash faults can lead to a permanent loss of units in the system, eventually compromising liveness. Detecting permanent faults is diﬃcult. Temporary disconnects are frequent and might be lengthy, making timeouts unviable. The approach used is to count the number of updates that commit without a vote from the server in question. Since planned disconnects result in a server designating a proxy, votes are only not cast by servers that are unexpectedly disconnected from the rest of the system. Once a failure is detected, lost units are redistributed. This is done through a reevaluation update, that competes with other normal updates. When committed, each server gains a percentage of the lost units. Bringing Consensus to Consensusless Cryptocurrencies 15

Any server that exchanged units with the failed server subsequently to the last election resets its units to the level before the exchange.

Correctness Barreto and Ferreira [5] have formally deﬁned epidemic quorum systems and proved their safety and liveness properties, as well as discussed the diﬀerences with traditional quorum systems. They found epidemic quorum systems to satisfy the following safety properties:

1. nontriviality: Any value decided must have been proposed at some process. 2. stability: A process can only decide a single value 3. consistency: Diﬀerent processes cannot decide diﬀerent values

In terms of liveness, epidemic quorum systems may block if at least one process is faulty, as a consequence of the FLP impossibility [16]

2.5 Discussion

In this section, we discuss and summarize the blockchain systems introduced previously, and our proposed solution, Xenochain. Table 1 presents a comparative analysis of the systems. We compare the systems using the following dimensions:

– Setting: Whether the system is permissioned or permissionless. Permission- less systems are more desirable due to their decentralization but have the added challenge of preventing Sybil attacks. – Consistency: The consistency guarantees the system offers. As stated previously, causal consistency is sufficient to support cryptocurrencies, but not smart contracts. Moreover, systems that offer only strong consistency cannot benefit from the performance improvements of a consensusless cryptocurrency. Hybrid systems provide the best of both worlds since they can support fast consensusless cryptocurrencies and smart contracts. – Protocol: The backbone protocol of the system. For systems offering strong consistency, this will be the consensus protocol, while systems offering causal consistency are based on a simpler and faster consensusless protocol. – Latency: The average time between a transaction being issued and committed. Consensus protocols typically have an order of magnitude higher latency than consensusless protocols, but offer stronger consistency guarantees. For systems offering hybrid consistency, we present the latency of the consensus protocol. – Applications supported: The class of applications the system supports. Completely consensusless systems have the disadvantage of not supporting smart contracts.

∗The setting of Xenochain depends on the setting of the underlying system, so it may be Permissioned if built on top of Astro 16 Miguel Barros

Solution Comparison Name Setting Consistency Protocol Latency Applications supported Bitcoin Permissionless Strong Proof-of-Work 1 hour Cryptocurrencies+Smart Contracts Ethereum Permissionless Strong Proof-of-Work 4 minutes Cryptocurrencies+Smart Contracts Astro Permissioned Causal Consensusless 1 second Cryptocurrencies Parmenides Permissionless Hybrid Consensusless+Proof-of-Work 4 minutes Cryptocurrencies+Smart Contracts Xenochain Permissionless∗ Hybrid Consensusless+Epidemic Quorums few seconds Cryptocurrencies+Smart Contracts Table 1. Comparison of blockchain systems

The two most popular general-purpose blockchains are Bitcoin and Ethereum. Both are based on a Proof-of-Work Consensus protocol and thus suffer from high commit latency. Ethereum’s latency is much smaller since the time to generate a block is much lower. Ethereum smart contracts are also much more popular, while Bitcoin is mainly used for its cryptocurrency. Astro builds on the results from Guerraoui et al. [14] by implementing a cryptocurrency without resorting to consensus. Because of this, transactions are committed with subsecond latency (for a system with 100 replicas). However, it does not support strong consistency. It is also permissioned, meaning it is not resistant to Sybil attacks and is not fully decentralized. Parmenides is, to the best of our knowledge, the first system supporting consensusless cryptocurrencies in a permissionless setting. It provides a hybrid consistency model, thus also supporting smart contracts that can use its committed view. Since the red view uses a Proof-of-Work-based consensus protocol, it again suffers from high commit latency (the protocol is based on Ethereum so the commit latency is roughly the same). The admission time (for operations that require causal consistency) is an order of magnitude faster. Our contribution, Xenochain, offers the same consistency guarantees as Par- menides, but we believe it may offer significantly lower latency due to the use of epidemic voting protocols that have lower complexity than consensus. In the next section, we will present how this is going to be achieved.

3 Xenochain

In this section, we discuss our main ideas. We begin by presenting a general overview of the protocol. Following that, we present the system model. We model the operations and properties provided by a generic consensusless cryptocurrency, which are used by our protocol. Finally, we present the agreement protocol in full and open problems to be solved during this dissertation.

3.1 Overview As stated previously, our proposal builds on Epidemic Quorum protocols. These protocols allow reaching agreement by running a set of elections wherein each process votes for a value. Votes are weighted by the voting units each process owns. Once an election is over, all correct processes agree on the winning value. Our protocol expands Epidemic Quorums protocols by tying unit allocation to Proof-of-Stake in a consensusless cryptocurrency. Speciﬁcally, in each election, Bringing Consensus to Consensusless Cryptocurrencies 17

Fig. 4. Xenochain Architecture

the amount of units each process owns is equal to its current stake in the cryptocurrency, which an adversary cannot forge. This makes the protocol resistant to Sybil attacks. We also consider byzantine processes, which previous Epidemic Quorum Protocols do not. To the best of our knowledge, ours is the ﬁrst protocol based on Proof-of- Stake of a consensusless cryptocurrency. Because of this, it presents additional challenges which we detail in Section 3.6.

3.2 System Model

The system model is similar to that of standard blockchain systems. We assume a set of N processes, some of which may behave arbitrarily. Each process is uniquely identified by a key-pair, of which the public key is shared and the private key is known only to the owner. Processes are organized in a peer- to-peer network, and broadcast messages via a probabilistic gossip broadcast protocol. The properties of this protocol are described in Section 3.3 The main difference in our system model is we assume that all processes participate in the same consensusless cryptocurrency system and have some stake in it (i.e. a portion of the currency) Like other Proof-of-Stake protocols, we assume the stake of faulty processes is bounded and significantly less than the stake held by correct processes (we will define the precise bounds for this during the ongoing work). 18 Miguel Barros

3.3 Consensusless Cryptocurrency Model We model a consensusless cryptocurrency as a set of accounts, each owned by a different process, and containing some non-negative balance. Each account is uniquely identified by the public key of the process that holds it. The operations that can be issued on the cryptocurrency system are: – Read(a): Can be invoked by any process. Returns the units of currency of the account owned by process a. – Transfer(a, b, x): Can be invoked only by the process that owns account a. Succeeds if a has more than x units of currency, with x a positive amount. If it does, x units of currency are transferred from the account owned by a to the account owned by b. The properties of the cryptocurrency system are as follows: – Double-spending resistance: A process cannot spend the same unit of cryptocurrency twice. – Strong eventual consistency: The state of an account converges once the same updates are applied at all processes, but might be temporarily divergent until that happens. – Fixed Total Stake: The total amount of currency available is fixed and known. – Causal Serialization: An outgoing transfer for an account is serialized with respect to all incoming and outgoing transfers to the same account. When a transaction is issued, it is broadcast to the rest of the system. The broadcast protocol offers the following interface: – Broadcast(p, s, c, t): Invoked by process p to broadcast transaction t with sequence number s and set c of transactions on which t causally depends. – Deliver(q, m): Invoked by process q to deliver transaction m = (p, s, c, t). The properties of the broadcast protocol are: – No duplication: Every correct process delivers a transaction t at most once. – Agreement: If a correct process has delivered a transfer t, all other correct processes will eventually deliver t with high probability. – Validity: Transfers issued by correct processes are eventually delivered by all correct processes with high probability. – Causal Order: If transaction t2 causally depends on t1, no correct process delivers t2 before it delivers t1. – Double Spending Tolerance: If a correct process delivers a transaction t, no correct process delivers a double-spending transaction of t with high probability (this comes from the consistency property of the Byzantine Reliable Broadcast specification [10]). These properties are common for the consensusless cryptocurrencies ana- lyzed, particularly Astro [14] and the Parmenides blockchain [29]. Bringing Consensus to Consensusless Cryptocurrencies 19

1 pid = ... // current process id 2 P = {p1, p2, . . . , pn} 3 V = map() // vote units per process id 4 T = 0 // total vote units 5 E = set() // processes that have voted 6 R = map() // election tally 7 8 Upon event election start do 9 foreach process p of P do V [p] = read(p) 10 T = sum of votes in V 11 v = some arbitrary value 12 Broadcast(vote(p, v)) 13 14 Upon event vote(p, v) do 15 if p in P and p not in E then 16 add p to E 17 R[v] = R[v] + V [p] 18 check election decision() 19 end 20 21 Function check election decision is 22 cast = sum of units in R 23 missing = T − cast 24 top = value with most units in R 25 contender = value with most units in R − top 26 if R[contender] + missing < R[top] then 27 Decide(top) 28 end 29 end Algorithm 1: Initial sketch of proposed protocol

3.4 Protocol

In this section, we present our epidemic quorum protocol. It is built on top of the previous cryptocurrency model and uses its underlying broadcast protocol, as can be seen in Figure 4 The pseudocode of the protocol is shown in Algorithm 1: The set of processes participating in the election is known beforehand (line 2). This is trivial in permissioned settings. For permissionless settings, a committee election mechanism can be used to select the participating processes. The protocol starts with an election start event (line 8). This event assigns to each process a number of units equal to the amount of currency they hold. After the election has begun, processes vote for an arbitrary value by broadcasting a vote message (line 12). For simplicity, we omit how processes decide which value to vote for (line 11). 20 Miguel Barros

Only processes that are part of the election can vote, and each process can only vote once (line 15). When a process receives a valid vote, it updates the election information (lines 16—17) and veriﬁes if the winner of the election is certain (line 26). If so, the process can safely decide the winning value.

3.5 Analysis To ensure that all processes see the same winner in an election, they must agree on unit distribution and observe the same set of votes. Due to consensusless cryptocurrencies only having strong eventual consistency, the read operation in line 9 can return different values for different processes (for example if a process has seen a transfer operation and the other has not), potentially causing different processes to disagree on voting distribution To prevent this, all processes that receive the election start message must see the same state of the cryptocurrency, effectively tying a distributed snapshot to each election. For now, we will assume this is the case. We present possible solutions to achieve this in Section 3.6 Since vote messages are broadcast, and the broadcast protocol is resistant to double-spending, a byzantine process cannot broadcast two votes at once to try and split the system into two views, where each view saw a different value voted for. Because all correct processes agree on unit distribution and see the same votes, they will all arrive at the same election winner, and decide the same winning value in line 27, ensuring safety. Liveness is not ensured. By withholding votes, byzantine processes can, in some cases, stop an election from deciding. This can happen independently of the amount of stake held since in the worst case the election is tied without the votes of the faulty processes. This problem is equivalent to a fault in the crash model. In the best case, the protocol decides in two communication rounds (one for the broadcast of the election start message and one for the broadcast of the vote messages). This potentially presents a big performance improvement over standard Proof-of-Work protocols.

3.6 Open Problems There are two open problems to be addressed in the current sketch of the protocol: – Ensuring a consistent snapshot of the Proof-of-Stake: This is an underlying problem in Proof-of-Stake. Previous protocols [15] solve this by dividing the blockchain into epochs (each epoch representing a set of n con- tinuous committed blocks) and considering the stake of the processes at the ﬁrst block of the current epoch. In our case, because the transactions in a consensusless cryptocurrency are not totally ordered, no epoch exists, and so a new solution must be developed. Bringing Consensus to Consensusless Cryptocurrencies 21

– Preventing vote withholding: We plan to research two possible ways of solving this problem: The ﬁrst is based on existing Proof-of-Stake protocols that punish non-participating processes, normally by making them lose stake. The second is by detecting blocked elections and repeating them.

During this thesis, we will ﬁnish making the protocol by solving these open problems and implement it in a real-world system.

4 Evaluation Methodology

The evaluation process will focus on the following aspects of the system:

– Performance: What’s the latency and throughput of the protocol. – Fault Tolerance: How the protocol behaves in the presence of crash and/or arbitrary failures. – Usability: How easy and intuitive is it to use the protocol and to build smart contracts that leverage its guarantees.

We will compare our work with existing systems, such as Ethereum or Par- menides. Regarding the deployment, we plan on creating a private network using ma- chines in the GSD cluster. We’ll use virtualization to scale to hundreds of nodes. Regarding the workload, we plan to use traces obtained from real systems, such as the ones provided by Ethereum. The metrics used for the performance assessment are the decision latency (time for a value to be decided) and decision throughput (number of decisions per unit of time). The latency results obtained will be compared with the theoretical values calculated in Section 3 and to the values of the existing systems. We will assess the behavior of our solution in the presence of crashed or byzantine participants. Most importantly, we will demonstrate that the protocol continues making progress in such situations, and does not compromise safety. Finally, we will measure the performance penalty for such scenarios. Finally, we will assess the protocol from a usability standpoint by presenting the diﬃculties encountered when implementing smart contracts using our library.

5 Scheduling

The schedule of future work is shown in Figure 5. We will begin by researching solutions to the open problems of the protocol discussed in Section 3.6. With this, we will develop the ﬁnal version of the protocol which we will implement on a real-world system and evaluate. To conclude, we will write an article detailing our results and ﬁnish writing the dissertation. 22 Miguel Barros

February March April May June July August

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Research open problems

Design and implement solution

Evaluate solution

Write article

Write dissertation

Fig. 5. Work Schedule by week

6 Conclusion

The widespread popularity of cryptocurrencies such as Bitcoin and Ethereum has led to an explosion of research into blockchain systems. This research is typically focused on ﬁnding alternatives to Nakamoto Consensus, due to its limited throughput, high latency, and energy consumption. However, recent results [20] have shown that cryptocurrencies can be made much faster since they do not require strong consistency for their most common operations, and can thus avoid the cost of consensus entirely. Real-world systems are still limited since smart contracts and some mainte- nance cryptocurrency operations require strong consistency, implying the need for consensus. In this report, we have presented an initial sketch of Xenochain, a new protocol whose goal is to provide strong consistency based on epidemic voting protocols that can be built on top of consensusless cryptocurrencies. These protocols can be used by smart contracts and cryptocurrencies as a faster and more eﬃcient alternative to existing consensus protocols. Finally, we presented our evaluation methodology and the scheduling of future work.

References

1. Abraham, I., Malkhi, D., Nayak, K., Ren, L., Spiegelman, A.: Solida: A blockchain protocol based on reconfigurable byzantine consensus (2017) 2. Aguilera, M., Keidar, I., Malkhi, D., Martin, J.P., Shraer, A.: Reconfiguring replicated atomic storage: A tutorial. Bulletin of the European Association for Theo- retical Computer Science EATCS (11 2010) 3. Alchieri, E., Bessani, A., Greve, F., Fraga, J.: Efficient and modular consensus-free reconfiguration for fault-tolerant storage (07 2016) 4. Back, A.: Hashcash - a denial of service counter-measure (09 2002) Bringing Consensus to Consensusless Cryptocurrencies 23

5. Barreto, J., Ferreira, P.: The availability and performance of epidemic quorum algorithms (03 2007) 6. Bracha, G., Toueg, S.: Asynchronous consensus and broadcast protocols. J. ACM 32(4), 824–840 (Oct 1985). https://doi.org/10.1145/4221.214134, https://doi.org/ 10.1145/4221.214134 7. Brown-Cohen, J., Narayanan, A., Psomas, C.A., Weinberg, S.M.: Formal barriers to longest-chain proof-of-stake protocols (2018) 8. Buterin, V., Griffith, V.: Casper the friendly finality gadget. CoRR abs/1710.09437 (2017), http://arxiv.org/abs/1710.09437 9. Cachin, C., Guerraoui, R., Rodrigues, L.: Introduction to Reliable and Secure Distributed Programming, chap. 4, pp. 137–203. Springer Publishing Company, Incorporated, 2nd edn. (2011) 10. Cachin, C., Guerraoui, R., Rodrigues, L.: Introduction to Reliable and Secure Distributed Programming, chap. 3, pp. 137–203. Springer Publishing Company, Incorporated, 2nd edn. (2011) 11. Castro, M., Liskov, B.: Practical byzantine fault tolerance. In: Proceedings of the Third Symposium on Operating Systems Design and Implementation. p. 173–186. OSDI ’99, USENIX Association, USA (1999) 12. Cetintemel, U., Keleher, P.J., Bhattacharjee, B., Franklin, M.J.: Deno: A decentralized, peer-to-peer object replication system for mobile and weakly-connected environments. IEEE Transactions on Computers (TOC) 52 (July 2003) 13. Cohen, B., Pietrzak, K.: The chia network blockchain (2019) 14. Collins, D., Guerraoui, R., Komatovic, J., Kuznetsov, P., Monti, M., Pavlovic, M., Pignolet, Y., Seredinschi, D., Tonkikh, A., Xygkis, A.: Online payments by merely broadcasting messages. In: 2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). pp. 26–38 (2020). https://doi.org/10.1109/DSN48063.2020.00023 15. Daian, P., Pass, R., Shi, E.: Snow White: Robustly Reconfigurable Consensus and Applications to Provably Secure Proof of Stake, pp. 23–41 (09 2019) 16. Fischer, M.J., Lynch, N.A., Paterson, M.S.: Impossibility of distributed consensus with one faulty process. J. ACM 32(2), 374–382 (Apr 1985). https://doi.org/10.1145/3149.214121, https://doi.org/10.1145/3149.214121 17. Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis and applications. In: Oswald, E., Fischlin, M. (eds.) Advances in Cryptology - EUROCRYPT 2015. pp. 281–310. Springer Berlin Heidelberg, Berlin, Heidelberg (2015) 18. Gilad, Y., Hemo, R., Micali, S., Vlachos, G., Zeldovich, N.: Algorand: Scaling byzantine agreements for cryptocurrencies. In: Proceedings of the 26th Symposium on Operating Systems Principles. p. 51–68. SOSP ’17, Association for Computing Machinery, New York, NY, USA (2017). https://doi.org/10.1145/3132747.3132757, https://doi.org/10.1145/3132747.3132757 19. Guerraoui, R., Kuznetsov, P., Monti, M., Pavlovic, M., Seredinschi, D.A.: At2: Asynchronous trustworthy transfers (2019) 20. Guerraoui, R., Kuznetsov, P., Monti, M., Pavloviˇc, M., Seredinschi, D.A.: The consensus number of a cryptocurrency. In: Proceedings of the 2019 ACM Symposium on Principles of Distributed Comput- ing. p. 307–316. PODC ’19, Association for Computing Machinery, New York, NY, USA (2019). https://doi.org/10.1145/3293611.3331589, https://doi.org/10.1145/3293611.3331589 24 Miguel Barros

21. Herlihy, M.: Wait-free synchronization. ACM Trans. Program. Lang. Syst. 13(1), 124–149 (Jan 1991). https://doi.org/10.1145/114005.102808, https://doi.org/10. 1145/114005.102808 22. Keleher, P.J.: Decentralized replicated-object protocols. In: Proceedings of the Eighteenth Annual ACM Symposium on Principles of Distributed Computing. p. 143–151. PODC ’99, Association for Computing Machinery, New York, NY, USA (1999). https://doi.org/10.1145/301308.301345, https://doi.org/10.1145/301308. 301345 23. Krause, M., Tolaymat, T.: Quantiﬁcation of energy and carbon costs for mining cryptocurrencies. Nature Sustainability 1 (11 2018). https://doi.org/10.1038/s41893-018-0152-7 24. Malkhi, D., Reiter, M.: Byzantine quorum systems. In: Proceedings of the Twenty-Ninth Annual ACM Symposium on Theory of Computing. p. 569–578. STOC ’97, Association for Computing Machinery, New York, NY, USA (1997). https://doi.org/10.1145/258533.258650, https://doi.org/10.1145/258533.258650 25. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. Cryptography Mail- ing list at https://metzdowd.com (03 2009) 26. Ozisik, A.P., Levine, B.N.: An explanation of nakamoto’s analysis of double-spend attacks (2017) 27. Park, S., Kwon, A., Fuchsbauer, G., Gaˇzi,P., Alwen, J., Pietrzak, K.: Spacemint: A cryptocurrency based on proofs of space. In: Meiklejohn, S., Sako, K. (eds.) Fi- nancial Cryptography and Data Security. pp. 480–499. Springer Berlin Heidelberg, Berlin, Heidelberg (2018) 28. Pass, R., Shi, E.: Rethinking large-scale consensus. In: 2017 IEEE 30th Computer Security Foundations Symposium (CSF). pp. 115–129 (2017). https://doi.org/10.1109/CSF.2017.37 29. Silva, P., Matos, M., Barreto, J.: Introducing consensusless cryptocurrencies to general-purpose permissionless blockchains 30. Wackerow, P.: Introduction to smart contracts (2020 (accessed November 19, 2020)), https://ethereum.org/en/developers/docs/smart-contracts/ 31. Wiki, E.: ERC-20 Token Standard - Ethereum Smart Contracts (2014 (accessed November 19, 2020)), https://en.bitcoinwiki.org/wiki/ERC20 32. Wood, D.: Ethereum: A secure decentralised generalised transaction ledger (2014)