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 guaran- tees. Recent results have shown that cryptocurrencies can be imple- mented without the need for strong consistency, opening the door for faster consensusless cryptocurrencies. Despite this, for real-world sys- tems, some cryptocurrency management operations still require strong consistency, as do smart contracts. These consistency requirements are typically achieved using consensus protocols, which are expensive, result- ing in significantly slower performance for the operations that use them. This thesis aims at studying more efficient 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 main- stream blockchains, such as Bitcoin [25] and Ethereum [32] provide strong con- sistency 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 pro- grams. 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 con- sistency 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 per- missioned 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 appli- cations that have some operations requiring strong consistency and thus cannot be fully implemented using consensusless cryptocurrency protocols. Cryptocurrencies Despite their name, real-world consensusless cryptocurren- cies often have some operations requiring stronger consistency requirements. For example, systems implementing cryptocurrencies in a permissioned set- ting, like the one developed by Guerraoui et al. [14] must support reconfiguration: the joining and leaving of participants, to be viable for long term deployment. Reconfiguration 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 defines 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 implement- ing 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 refilling 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 refill 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 final state. Since only the first 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 reconfig- uration 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 back- ground 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