Efficient Proof-of-Space approaches for permissionless

Jo˜aoVasco Estrela Martinho [email protected]

Instituto Superior T´ecnico Advisors: Prof. Miguel Matos Prof. Jo˜aoBarreto

Abstract. Bicoin, one of the most famous blockchains in the world, relies on Proof- of-Work to solve the distributed problem. Proof-of-Work however is not ideal for its high energy consumption and overall high confirmation times. Alternatives such as Proof-of-Stake and Proof-of-Space promise better sustainability and scalabil- ity but introduce problems such as the nothing-at-stake issue. Therefore, they need to be combined with other mechanisms that counter these problems. Existing ap- proaches rely on ad-hoc mechanisms, such as Proof-of-Work itself, and thus have several theoretical and practical shortcomings. In this thesis, we propose AstroChain, a permissionless Proof-of-Space that uses a reconfigurable random generator protocol to ensure liveness and safety of the system. By simply relying on message passing to ensure security, AstroChain has lower energetic costs than Proof-of-Work blockchains and has the potential to offer high throughput and low confirmation times for transactions, which makes the blockchain more useful and sustainable. Table of Contents

1 Introduction ...... 3 2 Related Work ...... 5 2.1 Distributed Ledgers and Blockchains ...... 5 2.2 ...... 7 2.3 Alternatives to Bitcoin ...... 9 2.4 Random Beacons in Blockchains...... 15 2.5 Discussion ...... 15 3 AstroChain ...... 17 3.1 Proof chain ...... 18 3.2 Random chain ...... 18 3.3 Transaction chain ...... 20 3.4 Vulnerabilities and solutions ...... 21 3.5 Discussion ...... 21 4 Evaluation ...... 22 5 Schedule of Future Work ...... 22 6 Conclusion ...... 23 1 Introduction

Blockchains have become increasingly more popular in the last years, especially since the appearance of Bitcoin [1] in 2009. A blockchain is a distributed system that implements a ledger. A ledger is a record of transactions from one entity to another. A ledger has the property of only allowing for transactions to be appended sequentially and, once in the ledger, may not be changed. This way, order is secured and any change to previously stored transactions makes the ledger invalid. A ledger is then a ”full picture” of the assets held by each entity. The importance of blockchains comes from the fact that, using them, we can build a decentralized application where there are few trust assumptions and possibly a large number of processes are allowed to participate. In a lot of distributed systems nowadays, such as banking systems, for example, there exists a central third party on which the system relies, and thus, we must trust this entity for the system to work. This may be undesirable, since, should this central entity fail, the whole system breaks down. As such, permissionless blockchains were proposed to build a fully decentralized distributed system, where no single central entity exists, but multiple entities work together in a protocol that allows participants to not trust each other, but still trust the protocol itself. In doing this, if a single entity fails, the system still works as expected. Most blockchains nowadays (such as Bitcoin) are used to implement . By using blockchains to implement this , a user can transfer to others without needing to trust a centralized third-party (in contrast to traditional banking systems). An- other useful application of blockchains is smart contracts, first deployed in the [2] blockchain. In this approach, transactions are not currency transfers, but executable pieces of code (contracts) that are executed by users. The validation of these executions is done and agreed upon by blockchain users, thus allowing for the construction of fully decentralized applications. The most prevalent way of implementing blockchains follows a variant of what is called the Nakamoto Consensus, first introduced in Bitcoin [1]. The three main components of Nakamoto consensus are incentives, a chain selection rule, and Proof-of-Work. Proof-of-Work is a cryptographic puzzle that a participant must solve to add a block to the blockchain. To solve the puzzle, the participants must use a non-counterfeitable resource, in this case, computational power. This mechanism is used to prevent what is called Sybil attacks, which can be described as a single user voting as if they are multiple participants. This is not enough to ensure the validity of the chain, as two different participants may be able to solve the puzzle at similar times. At this point, what is called a may occur, where two valid views of the blockchain coexist. To prevent this, the chain selection rule tells us which chain to select based on the blocks we see. Finally, incentives are rewards given to participants that follow the protocol. This way, new participants are attracted to join the system, which will increase the security of the blockchain. Incentives also work to discourage malicious participants from breaking protocol. When a participant breaks protocol, it might not receive incentives, but still wasted the non-counterfeitable resource, which is wasteful for the malicious participant. However, Proof-of-Work has some important problems. Firstly, it uses up a lot of energy and thus is very wasteful. Currently, the energetic footprint of adding a transaction to Bitcoin and Ethereum, the two most famous blockchains that use Proof-of-Work, is equivalent to respectively 24 and 1 days worth of energy consumption of the average US household [3,4]. Another known issue of Proof-of-Work is its efficiency. For a blockchain to be fully useful,

3 it is required for there to be a low processing time for transactions. However, Proof-of- Work usually introduces low throughput and long confirmation times for transactions. This is because the puzzles in Proof-of-Work need to take some amount of time to be solved and each block cannot contain a high number of transactions, otherwise, the security of the system is not guaranteed. On top of that, the transactions need to be some blocks deep to be probabilistically trusted, due to forks. Only after being a few blocks deep, can transactions be trusted to be stable with high probability. Because of this, several proposals have appeared to build upon Proof-of-Work to solve these known issues [5,6,7]. A general idea to reduce the energy costs per transaction of Proof-of-Work is to parallelize the transaction handling and puzzle solving, which allows for higher transaction throughput and confirmation times, as well as reducing the difficulty of the puzzles, which decreases the energetic costs, as well as allowing for faster progress of the system. Proof-of-Work approaches in general still have large energetic costs and impractical trans- action handling, which becomes unsustainable and undesirable for the future of blockchains. As such, it is important to come up with blockchain approaches that replace Proof-of-Work as the central security enforcing mechanism. One interesting approach to blockchains that appeared was Algorand [8]. It used the well- known notion of Byzantine Agreement to solve the problem. Usually, this would be complicated, as Byzantine Agreement protocols have a scalability issue. Algorand however randomly selects from all participants a small set of processes, which acts as a committee that decides blocks to be added. In doing so, transaction handling is much faster and security is still preserved. Other systems to prevent Sybil attacks have also been appearing, to replace Proof-of- Work and its limitations in Nakamoto consensus. One example is Proof-of-Stake, which uses the amount of currency a participant holds in the system (stake) as the non-counterfeitable resource. For a user to add a block, they must stake their money and, the higher their stake is, the higher their chance of successfully adding a block to the chain. Another example is Proof-of-Elapsed-Time, where participants make use of a Trusted Execution Environment, a safe space in memory that no malicious process can tamper with, to run a lottery that will choose who adds the next block to the chain. Another approach to prevent Sybil attacks is Proof-of-Space. In this approach, the non- counterfeitable resource is memory or disk space. Usually, before being able to mine, a participant reserves some (non-trivial) amount of memory and dedicates it to the system, filling it with data. When trying to add a block to the chain, the participant resorts to this reserved space to generate the solution to the puzzle. This approach has the potential of making Nakamoto Consensus more energy and time-efficient, as the solution to the puzzle can be approximated to some memory accesses. Proof-of-Space has a known issue though: the proof generation is very fast. This creates the nothing-at-stake problem, that is, a participant can generate a lot of alternative blocks with a residual cost. It matters to note that this problem is not present in Proof-of-Work, since generating a block is expensive and therefore not worth it to mine multiple different blocks unless there is a relatively high degree of certainty in the success of the attack. Spacemint [9] was a Proof-of-Space proposal that tried to prevent nothing-at-stake by penalizing the participants that were found to try to mine multiple blocks for the same height. This however does not fully prevent the problem, because a miner may easily generate a sequence of blocks in private, with close to no cost, and thus, when they propose this new chain, no illegal behavior is detected. Another Proof-of-Space approach is Chia [10], where

4 they use Verifiable Delay Functions to prevent miners from creating long sequences of blocks without sacrificing any resource. These functions however need parametrization, that is, the protocol needs to calculate arguments for the functions to ensure the security of the system. If these parameters are not properly calculated, the security of the system is not ensured. We highlight the importance of randomness in blockchain systems. Algorand [8] uses randomness to select the committee that decides blocks. Proof-of-Elapsed-Time uses a lottery to decide who will add a block. In Proof-of-Work, Proof-of-Stake and Proof-of- Space approaches, the puzzle winner is randomly selected based on how much of the non- counterfeitable resources they hold in the system. With the nothing-at-stake issue, these odds of winning may be manipulated in Proof-of-Space. However, if we remove the ability to manipulate the odds of winning, the system becomes secure. A random beacon, which can be described as a steady generator of fresh randomness that is unpredictable and cannot be manipulated, may be an interesting system to combine with Proof-of-Space to ensure the security of the protocol. As such, in this document, we propose AstroChain, a novel Proof-of-Space permission- less blockchain system that introduces the first combination of random beacon protocols with a Proof-of-Space blockchain. With a random beacon, we ensure steady progress of the blockchain, as well as prevent well-known attacks that derive from the nothing-at-stake issue. With this proposal, we expect to have lower energy costs, better confirmation times for trans- actions, as well as higher throughput than most permissionless Proof-of-Work blockchains in production nowadays. The remainder of the document is structured as follows: Section 2 presents the current state-of-the-art, Section 3 presents AstroChain’s construction. In Section 4, we discuss the evaluation plan. In Section 5, we present a schedule for our future work. In Section 6 we conclude the document with some final remarks on the thesis project.

2 Related Work

In this section, we present the related work. In Section 2.1 we define what a blockchain is, what properties it must ensure and what are its applications. In Section 2.2 we describe in some detail the system of Bitcoin, how it defined the notion of Nakamoto consensus and what challenges it faces. In Section 2.3 we list and describe a few alternatives to Bitcoin, starting with improvements that still use Proof-of-Work, then Proof-of-Work alternatives, and finally highlight the idea of using Byzantine Agreement to also build blockchains. In Section 2.4, we describe what random beacons are and their potential usefulness for Proof-of-Space blockchains. In Section 2.5, we do an overall description of the blockchain constructions thus far, some of the challenges they face, and how our system improves on them. Finally, we conclude the section with a comparison of the systems presented and highlight their main limitations.

2.1 Distributed Ledgers and Blockchains

Historically, a ledger is a record of transactions, where one records how much resources one entity transfers to another. By having this information, we are able to keep track of how many resources each entity possesses at any given point in time. An important property of a ledger is that it must be immutable, otherwise, there is no way of trusting that a transaction is ever truly performed. The distributed ledger problem is a classical problem in

5 the distributed systems setting. In this case, the hardest property to hold is immutability, since a malicious process can behave arbitrarily. Distributed ledgers were first implemented using Byzantine agreement. Byzantine agree- ment is a classical problem, where a group of (honest) processes wants to decide on one action they must all perform (agree on) in a byzantine setting, that is, in a setting where there may exist some malicious processes that can behave arbitrarily. A ledger can be im- plemented using byzantine agreement, by deciding which transactions to add to the ledger at a specific point in time. Classical byzantine agreement algorithms however suffer from scalability issues, because their message-passing complexities are usually high to provide their strong safety guarantees, and every process needs to know all other processes for the protocol to work. Blockchains appeared as an implementation of the distributed ledger problem, but with- out the scalability limitations imposed by classical byzantine agreement algorithms. The first person (or group of people) to describe a blockchain was Satoshi Nakamoto in Bitcoin [1]. In this work, the author(s) describes a protocol that implements a decentralized currency, nowadays known as , through the use of Proof-of-Work. In these systems, the processes are identified by their public (asymmetric) keys. Through the use of these keys, processes are able to sign transactions they want to make. The use of signatures allows for a transaction to not be manufactured by someone other than the sender of the money. If all processes broadcast these transactions with a signature, we obtain an unordered list of transactions that each process wants to make. However, this naive approach does not implement the ledger abstraction, as the transactions do not have an obvious order and thus there are no guarantees that all processes have the same record. As such, to properly implement a distributed ledger, blockchains must meet two properties, as identified by Garay et al. [11] and which we describe informally below: – Persistence: If a transaction is k blocks deep in an honest process local chain, then with very high probability it will be present in every honest process local chain – Liveness: All transactions from honest processes will eventually end up k blocks deep in all honest processes chains To meet these properties, blockchains are usually implemented as a linked list of blocks, where each block contains a batch of transactions and a reference to the predecessor block. This reference is a means to ensure that, should an intermediate block be changed, all subsequent blocks must be changed as well, since the reference would become invalid. For this property to hold, the references are implemented as the cryptographic hash of the predecessor block. Other properties have been identified in [11,12] that, if guaranteed by a blockchain and combined with a proper majority of honest resources (e.g. over 50% of computation power in Proof-of-Work), ensure Persistence and Liveness in the blockchain construction. These properties are defined as: – Common prefix: If an honest process ”cuts-off” some blocks from the end of its local chain, then, with high probability, the resulting chain is a prefix of all honest processes local chain. This property ensures that there is an agreement between honest processes about the ledger’s past. – Chain Quality: With high probability, for a sequence of consecutive blocks in an honest process local chain, the percentage of blocks proposed by honest processes is no less than security parameter µ. Honest processes are then able to trust that, in their chain, an expected number of blocks come from honest processes, which enables them to trust that those blocks were honestly created.

6 – Chain growth: With high probability, given parameter τ (growth rate), after s con- secutive rounds, every honest process has grown its chain by at least τ × s blocks. This property is related to the liveness of the blockchain, that is, ensuring the blockchain makes steady progress.

Combined, these properties differ from classical consensus mainly because blockchains focus on progress of the blockchain (Liveness), in exchange for probabilistic agreement, while classical consensus focuses on the strong agreement between all correct processes (Safety), but sacrificing progress in the protocol in some situations. It is important to note that blockchain applications are not limited to cryptocurren- cies. The Ethereum blockchain [2] allows running fully distributed applications on top of a blockchain. This is achieved by defining smart contracts, which are, in simple terms, pieces of executable code, and the transactions become requests to run these contracts. For every transaction, the contract it refers to will be executed and its output state will be added to a new block. As such, we can look at blocks as state transition functions, where each transaction is simply one step of this function. The state of the system is thus defined as the composition of all state transition functions defined in the blocks. Blockchains can be divided into two categories: permissioned and permissionless. In permissioned blockchains, the processes are known to all participants, by registering to a trusted party, for example. In this case, since the number of processes is known, the distributed ledger problem may be solved by using a Byzantine consensus protocol (e.g. Practical Byzantine Fault Tolerance [13]) to decide which transaction to add to the chain. These constructions tend to have improved throughput, as transactions are ”immediately” confirmed and the time to choose transaction batches is simply bounded by the protocol message passing complexity. A well known permissioned blockchain implementation is Hy- perledger Fabric [14], which achieves an expected higher throughput (over 3500 transactions per second) when compared to Bitcoin (currently around 5 transactions per second). Per- missionless blockchains, such as Bitcoin [1] and Ethereum [2], allow for anyone to generate a process arbitrarily and join the system without the need for a ”registration” process. Because generating a new process is so simple, the system becomes prone to Sybil attacks, which can be informally defined as a single user voting multiple times. This can be devastating for classical consensus protocols since a single user has the potential to rig a whole voting. To counter this, permissionless blockchains require participants to prove they are using a non-counterfeitable resource (e.g. computation for Proof-of-Work), which makes the imper- sonation of multiple entities no longer attractive for malicious users. In this work, we will mainly focus on permissionless blockchains, because our trust base should be minimal (only need to trust protocol), which contrasts to permissioned blockchains, where all processes need to trust the ”registration” third party.

2.2 Bitcoin

As referenced before, the first blockchain to appear was Bitcoin. To ensure the properties introduced in Section 2.1, it implements what is now known as Nakamoto Consensus. In Bitcoin, for a miner to add a block, it must solve a cryptographic puzzle. This cryp- tographic puzzle is finding a nonce s.t. H(B, nonce) < D, where H is a hash function (e.g. SHA-256), D is a difficulty parameter and B is the (potential) block to be added, composed of the miner identifier, a reference to the predecessor block (i.e. H(predecessor block)) and a batch of (valid) transactions. Because H is non-invertible, a miner must brute force until

7 one of the hashes is indeed below D. If such a nonce is found, the miner appends to B the signature of H(B, nonce) and broadcasts this block. To check that a received block is valid, the receiver needs only to calculate H(B, nonce), verify that it matches the value in the signature, and check if this value is indeed lower than D. The difficulty parameter D is tuned every 2016 blocks to make block generation, or more specifically, finding the solution to the puzzle, take 10 minutes on average. This adjustment exists to take into account the hardware advancements that happen throughout the years. The above process of finding the nonce that meets the criteria is known as Proof-of-Work and was first invented to fight off spam emails [15]. Because brute force is the only option, a lot of computations must be performed to add a valid block to the chain. This prevents Sybil attacks because, should a process try to impersonate multiple entities at once in order to gain an advantage over others, it would need to compute hashes proportional to the number of entities it is trying to impersonate, which becomes unpractical. Another important component of Nakamoto consensus is incentives. There are two types of incentives: mining a block and transaction fees. When a miner successfully mines a block, it receives some currency. This is actually how new money is introduced in Bitcoin. Transaction fees are, as the name suggests, fees that transaction issuers pay to the miner of the block that includes their transaction. These incentives are yet another mechanism to convince miners to (honestly) adhere to the protocol. This incentive system works indirectly to make attacks harder: by attracting new (honest) processes to the protocol, the attacker’s capabilities need to be much higher. Specifically, let us consider the 51% attack. In Bitcoin, should an attacker possess more than 50% of hashing power in the whole system, it would be able to do anything (e.g. double-spending), as probabilistically it would always be able to (eventually) overwrite an honest active chain with an arbitrary one [16]. Here, through incentives, the assumption that no single miner is able to have this much power becomes more reasonable, because the new honest miners that join are making it less likely for a miner to have so much relative power. Transaction fees however also introduce the problem of selfish mining and fairness, where a miner may selectively choose the transactions that pay better, and thus slow down less ”appealing” transactions. Finally, to complete Nakamoto Consensus, there needs to be a chain selection rule. When multiple miners are concurrently mining a block, because each puzzle has multiple solutions more than one miner may find a valid solution to the puzzle at similar times. When this happens, there exist multiple different but valid chains. This is what is called a fork. The chain selection rule is then used to select which of the multiple chains a participant should mine on top of. Generally speaking, the selected chain should be the one with more Proof- of-Work, that is, the one with the most blocks. In , this is enough, as the computation of the proof is hard and it is always worth it to mine on top of the highest block we have seen thus far, or one might fall behind other processes that follow the same strategy. This strategy is known as the ”longest-chain-rule”. Bitcoin suffers from some limitations, however. One of the most concerning ones is en- ergy consumption. Because Proof of Work requires processes to perform a large number of computations per generated block, the energetic footprint is enormous. The amount of energy it takes to add a transaction to the chain is nowadays equivalent to 24 USA house- holds’ average energy consumption in a day [3]. Another issue of Bitcoin is transaction throughput. Money systems, such as Visa, for example, are able to process thousands of transactions per second, while nowadays Bitcoin only processes around 5 transactions per second [17]. Lastly, Bitcoin suffers from long confirmation times. Because forks can happen in the system, a transaction that is in a chain at a given time may not be there after some

8 time, because a longer chain that excluded the transaction was selected. As such, we need to wait for the transaction to be deep enough for the probability of it disappearing from the chain to be (sufficiently) negligible. In Bitcoin, the recommended depth is 6 blocks. Because the block generation time is around 10 minutes, it takes one hour on average to trust that a transaction is stable, which is a very long confirmation time.

2.3 Alternatives to Bitcoin

Because Bitcoin has some very concerning limitations, both in energy consumption and actual transaction handling, but also because blockchains have very interesting applications in a decentralized setting, the research in this area has increased a lot since 2009 when Bitcoin was first released. The approaches that were proposed and that we will present in this section fall mainly in three categories: improvements on Proof-of-Work, that is, still use Proof-of-Work, but in an alternative construction that allows for better transaction handling; alternatives to Proof-of-Work, where instead of Proof-of-Work, miners prove they have a non- counterfeitable resource other than computation power; and Byzantine Agreement, where one replaces Nakamoto consensus with (classical) byzantine consensus protocols to decide the blocks that are added.

2.3.1 Improvements on Proof-of-Work

In 2016, Bitcoin-NG [6] was introduced to improve Bitcoin’s transaction throughput and confirmation times. The construction proposes two different types of blocks that are kept in the chain: key-blocks, used for leader election, and micro-blocks, to serialize transactions. A key-block, similarly to Bitcoin blocks, contains a reference to the predecessor block (e.g. hash of predecessor block) and a Proof-of-Work. These blocks are used, as mentioned, to elect an epoch-leader. This epoch-leader will be in charge of creating micro-blocks until a new Proof-of-Work appears. Micro-blocks are simply a reference to the previous block and a batch of transactions, with a signature for integrity and authentication of the leader. To prevent a malicious leader from publishing multiple micro-blocks for the same height, they are penalized if such behavior is detected by removing incentives during their lead- ership. The incentives are similar to Bitcoin’s, in the way that mining a key-block awards some newly-generated currency, as well as paying transaction fees. However, unlike Bit- coin, the fees are distributed in a 40%-60% manner for the current and next epoch-leaders, respectively, in order to convince the latter to mine a key-block on top of a (possibly) longer micro-block ”epoch chain”, rather than racing to be leader immediately. While this construction does improve the transaction throughput, the confirmation times are similar to Bitcoin’s, as one still needs to have a number of key-blocks to be mined on top of a transaction for it to be considered stable. Also in 2016, ByzCoin [7] appeared, which combined Byzantine agreement with Proof- of-Work. Similarly to Bitcoin-NG, they used the blockchain underlying mechanism of Proof- of-Work (key-blocks) to select leaders, only instead of a single leader, a committee is selected from the last winners. This committee is then in charge of deciding which transactions to be serialized in the blockchain (micro-blocks). They are able to do this by using collective signatures [18]. Collective signatures are a cryptographic primitive that allows for multi- ple entities to collectively emit a certificate, instead of classical protocols, where a single Certificate Authority does this. Informally, by collectively signing transactions into a cer- tificate and then collectively signing the certificate itself, the committee is able to decide

9 which transactions are added. Collective signatures also have the property of being publicly verifiable, which allows for any process, not only the committee members, to validate the certificates and thus, the validity of the transactions in them. This means the transaction confirmation time is simply bounded by the time it takes for the committee to see the transaction and collectively sign it. This offers better throughput, as the Proof-of-Work and transaction processing are decoupled, which allows for these processes to run in parallel. Another thing that this construction improves on is the confirmation time for transactions, since a transaction that is added to the blockchain is final, or, in other words, will not be discarded once it is committed. It is important to note that the way to ensure the trans- actions are not discarded by a new leader, in contrast to Bitcoin-NG’s incentives, is by having the committee also collectively sign the new key-block, which must reference the latest micro-block. ByzCoin however does not explain how reconfiguration of the committee happens. This is important for the protocol, because, should it not be properly implemented, a malicious leader may be able to indefinitely stall the reconfiguration and prevent progress. This is where Solida’s [5] contribution comes in. In Solida, similarly to ByzCoin, the committee members are selected from previous Proof-of-Work winners. However, to actually join the committee, they must send a join request to the committee, which triggers a view-change protocol in the committee. The committee then goes through a PBFT variant, where the new member acts as leader to try and enter the committee. Using this, if the new member is malicious and tries to stall out the reconfiguration protocol, it will not be able to commit its view-change request and thus is unable to join the committee. All of these systems suffer from a common issue, and that is their use of Proof-of-Work, which, as mentioned, has very large energetic costs. Even though these approaches need less computation power per transaction than Bitcoin, they still have a large energetic footprint and are thus undesirable from a sustainability point of view.

2.3.2 Alternatives to Proof-of-Work

We now discuss several approaches that replace Proof-of-Work as the blockchain con- sensus mechanism. Proof-of-Stake (PoS) Proof-of-Stake was first proposed in a Bitcoin forum [19]. In this approach, one substi- tutes the non-counterfeitable computation resource of Proof-of-Work with currency in the system. It is a simple and fair assumption, because, if the system is secure, then the money in it cannot be forged and, therefore, we may use this primitive as a counter to Sybil attacks. In systems that use Proof-of-Stake, the probability of a miner winning in a round is proportional to the amount of currency they have in the system. Proof-of-Stake provides some interesting improvements over Proof-of-Work, one of which is the reduction of the computational power needed to prove that one holds the non-counterfeitable resource: it is simply done by reviewing the ledger’s history, finding out how much currency the candidate process possesses and, based on that, calculate the probability it has of successfully ”mining” the block. One big issue of Proof-of-Stake is the nothing-at-stake problem. Because block generation is so simple, a malicious miner may try out different blocks at close to no cost, in hopes of finding one that gives it an unfair advantage over a process that simply follows protocol. Also because of this issue, malicious miners are able to indefinitely extend multiple forks that will never converge, because they can mine on these different chains with ease. One

10 solution to this is proposed in Slasher [20], where a miner makes a deposit when it wants to mine, and this deposit cannot be changed for some amount of time. While the deposit is valid, if a miner is found to participate in multiple forks, the deposit is lost, which will discourage this kind of behavior. Another attack that Proof-of-Stake is vulnerable to is costless simulation attacks [21]. In these attacks, a set of nodes has had a majority of the currency at some point in the past, but have since sold it. They can rewrite the chain’s history, however, for they can, at the point where they have a majority of stake, collude to write a new chain that extends this given point in history. In this new chain, by colluding, the set is also able to keep holding the majority of the stake, which completely biases the system. In [21], it is proposed that from time to time, the protocol creates checkpoints of the system. When a node joins, it will ask participants for the latest checkpoint and, assuming that a majority of the participants that reply are honest, it can obtain an honest checkpoint. These honest checkpoints are then pieces of history that cannot be changed, which will mitigate the history-rewriting that costless simulation attacks allow. As of writing this document, Ethereum [2] has launched its Beacon chain, the first of a three-step transition from Proof-of-Work to a more efficient approach based on Proof-of- Stake, known as Ethereum 2.0 [22]. Proof-of-Elapsed-Time (PoET) Proof-of-Elapsed-Time is a new blockchain consensus approach, which relies on a Trusted Execution Environment (TEE) to achieve consensus. A TEE can be seen as a safe place in memory, that is, a part of code or memory that is important for the protocol and that cannot be tainted by a malicious process. In Proof-of-Elapsed-Time, the block winner is selected at random, and this ”lottery” is done in the TEE. During the protocol, and before adding a new block, miners submit to the TEE a request to create a timer, which, after expiring, can be attested by the TEE that the process actually waited the given time. The winner is thus the process that gets the timer that finishes first. Sawtooth [23] is one permissioned blockchain that implements PoET. The TEE in this case is provided by Intel’s Software Guard Extensions (SGX). In this approach, it is plain to see that, for any process to trust the protocol, they must also trust Intel or the trusted hardware platform provider. In 2017, Chen et al. [24] proved that by compromising O(log(log(n))/log(n)) processes, where n is the total number of processes in the system, one attacker is able to break the whole blockchain system. Scalability is also an issue, as pointed out in [25], because the more processes there are in the system, the more likely it is for different processes to finish waiting for their timers at similar times, which creates forks in the blockchain, reducing the throughput. Proof-of-Space (PoSpace) Proof-of-Space was first introduced in 2015 by Dziembowski et al. [26]. In this Proof- of-Work alternative, the non-counterfeitable resource is memory or disk space. Usually, ev- eryday users have free space in their disks, and so, dedicating some of that free space to a blockchain may become profitable. Another interesting reason to investigate this approach comes from the fact that memory is cheaper than powerful computation hardware (e.g. GPU’s), making participation in the protocol much more appealing for everyone. Proof-of-Space can be seen as an interactive protocol between a prover P and a verifier V . As the names suggest, P ’s job is to provide to V a proof that it has indeed reserved some non-trivial amount of memory to the protocol, and V is then in charge of verifying that the proof was indeed well generated based on some information stored by P .

11 To be able to do this, P must first go through an initialization process I where it reserves some memory to the protocol and fills it with information that takes a non-trivial time to compute. After filling the amount of memory it wants, P sends a commitment C of the memory it has reserved to V . When this is done, P is able to generate proofs. This step is called execution (E). In this phase, V emits a challenge to P , and based on it, P retrieves from memory a statement S, which is sent to V . Using S and C, V is able to accept or deny a proof to the challenge. The first proposal of a Proof-of-Space was based on graph pebbling [26]. For this ap- proach, in phase I a process generates an acyclic, directed graph of N vertices. Then, it labels each vertex n with value ln = H(n, lp1, ..., lpm), where H is a hash function, and lp1, ..., lpm are the labels of n’s parent vertices. After the labeling of all vertices has been done, P creates a Merkle tree of the labels that were created, and shares the root with V . During E, V ’s challenge is asking for P to reveal the labels of vertices r1, ..., ri − 1 in the graph, which P does by revealing the necessary nodes of the Merkle tree. By having the tree’s root and the revealed values, V is able to verify that P had indeed previously stored the graph it had committed to. Spacemint [9] was a blockchain proposal that used this approach to replace Proof-of- Work. For a process to start mining, it performs the initialization step and then proposes to the blockchain a special transaction that contains the commitment. When the transaction is accepted, the process becomes able to mine. It is important to point out that challenges are chained, that is, the challenge for a given height h is based on the predecessor block at height h − 1. As such, completeness, that is, a process has a proof that corresponds exactly to the challenge, is not guaranteed. Because of this, a quality function is necessary that ranks proofs according to how close they are to the challenge. The winner of a round is then the one that has the proof with better quality. One shortcoming of Spacemint, and more generally, the acyclic graphs approach, is that a process needs to publish its commitment to the chain before being able to mine. Unlike other permissionless blockchains, where a process may enter the system whenever they please, in this approach, there needs to be a (probabilistic) waiting time for the process to be able to mine. To the best of our knowledge, Spacemint was never deployed. The second approach to Proof-of-Space was proposed by Abusalah et al. [27]. This pro- tocol is based on the inversion of random (hash) functions. In this approach, a prover P is given the description of random functions gf : N × N → N and f : N → N. The initial- ization phase is then finding all pairs x, x0 ∈ N s.t. x 6= x0 ∧ f(x) = f(x0) and then storing (g(x, x0), (x, x0)). In the execution phase, V sends to P a challenge y and the proof is thus a pair (x, x0) s.t. g(x, x0) = y. In [10], Abusalah et al. propose Chia, which combines Proof-of-Space, based on the inversion of random functions. PoSpace alone is vulnerable to what is called long-range attacks, which we describe later in this section, and to solve this Chia makes use Proof-of- Time (PoT). Proof-of-Time can be described as a proof that a process spent some amount of time to compute a function output. This can be done using Verifiable Delay Functions (VDF’s), a recent family of functions that take (close to) a fixed number of steps to execute. Another blockchain proposal that uses Proof-of-Space based on the inversion of random functions is EtherSpace [28]. In this proposal, the Proof-of-Space is combined with a dis- tributed random generator protocol, run by a committee, that allows for reconfiguration and whose output can be verified. By having challenges be dependent on the random gen- erator output, which no single miner can manipulate, malicious miners have their ability to generate chains longer than the honest one mitigated.

12 Proof-of-Space has some challenges related to the nothing-at-stake issue, that is, a proof is computationally easy to create and thus, many can be created at close to no cost. One possible attack is known as a digging attack, where a miner tries to extend a block in many ways (e.g. try different combinations of transactions to propose) in order to gain an unfair advantage over honest processes. The solution proposed in both Spacemint and Chia to mitigate this issue is the decoupling of transactions and proofs. By making the proof not dependent on the transactions proposed, it becomes unique. Thus, the probability of a miner successfully wining at a round is simply determined by the predecessor block, making it impossible to manipulate the odds of winning. In EtherSpace, it is suggested that the committee’s job is extended by making it decide which transactions to be added, similarly to Solida [5]. This can be compared to Chia and Spacemint’s solution, as the transactions and proofs are also decoupled in this solution. Another attack Proof-of-Space is vulnerable to is double-dipping, which can be described as a malicious miner trying to extend chains that are not the best one so far, in the hopes of obtaining a better chain. Spacemint tries to prevent this by penalizing processes that propose blocks for one given height but that extend two different blocks. However, this issue is not solved by penalties, as double-spending, for example, may still be profitable, even if a penalty is applied. Chia mitigates double-dipping by having honest processes mine on top of the first k blocks they see at each height. This is exactly the that a double-dipping attacker would follow, and it works because, by making the ”attack” a part of the honest protocol, the attacker needs to further double dip to gain an advantage over honest miners, which becomes less profitable as k increases. This however creates some overhead in complexity for each process, because they need to validate (k − 1) times more blocks per height. Finally, Proof-of-Space suffers from what is called long-range attacks. In these attacks, a miner tries to grow a chain in private, starting at some point in the past, which eventually outgrows the honest chain. When that time comes, the attacker may propose the chain, which will be accepted because it has more accumulated weight than the honest chain. To counter this, Spacemint provides an ad-hoc chain weight function, that instead of simply using the sum of all qualities of the blocks in the chain, also gives more weight to recent block’s qualities, so as to prevent against memory hardware becoming cheaper and thus, more available. As for Chia, they use VDF’s to prevent these long-range attacks, because a miner that tries to mine a chain completely in private still has to compute VDF’s for its chain to be acceptable. This slows down the block creation of the attacker and makes ”catching-up” with the honest chain non-profitable, as well as unlikely. VDF’s are still a recent topic of investigation and thus, may require further study to be fully trusted in a blockchain environment.

2.3.3 Byzantine Agreement

Nakamoto consensus appeared as a replacement to classical consensus when we want to improve scalability, because the consensus algorithms that are well studied nowadays, such as PBFT [13] or HotStuff [29], require the participants to know ahead of time the identity, or more precisely, the public keys, of all processes that participate in the system. Consensus algorithms also suffer from the fact that they usually do not allow for reconfiguration on the set of participants, since the algorithms capitalize on the number of faults they want to tolerate and the number of participants depends on this quantity. Finally, consensus algorithms are usually expensive in terms of communication, which is another factor that prevents scaling for permissionless blockchains. Consensus however gives stronger safety

13 guarantees than Nakamoto consensus, as the decisions are final and agreed upon by all (honest) processes, while Nakamoto consensus simply gives probabilistic guarantees. Because in permissioned blockchains such as Hyperledger Fabric [14] a miner registers to a trusted third-party, all processes may know at all times who are the members participating. As such, classical consensus algorithms are possible, offering better security guarantees and transaction handling, assuming a relatively small number of participants. In permissionless blockchains, where scalability and availability are key, consensus becomes cumbersome, as processes are usually not aware of all participants at one given time and the number of participants may be too high for consensus to be practical. It is however possible to apply some sort of byzantine agreement to permissionless blockchains if we are able to narrow down the number of participants to a smaller set of processes, which we will call a committee, that decides which transactions or blocks are added to the chain. In doing so, there is the potential that the higher throughput of the permissioned blockchains and the scalability of permissionless blockchains are achieved. As we have seen before, Byzcoin [7] was a proposal that selected the committee by choosing from the set of past winners of Proof-of-Work and collectively signing which transactions to be added. Solida [5] also used Proof-of-Work to select a committee, but further proposed a reconfiguration protocol that prevented a malicious leader from stalling the progress of the system, by running a consensus instance when a new leader wants to join the committee. Algorand [8] was proposed by Gilad et al. with a focus on making forks in the blockchain impossible. By doing this, all blocks that are added to the chain are trusted as final the moment they are decided. To do so, they make use of Verifiable Random Functions (VRF’s) to select committee members, who are in charge of deciding which block will be added, using a new Byzantine agreement protocol named BA∗ that scales better than previous Byzantine agreement protocols. VRF’s are also used to select potential leaders, who are in charge of proposing blocks to the blockchain. Informally, a VRF is a function Vsk(x) that outputs (h, p), where sk is the private (asymmetric) key of a process, x is any bitstring input, h is a fixed size bitstring and p is a proof that enables anyone that knows the process public key pk to verify that h does relate to x. At each round r of Algorand, when a process i wants to mine a block, they use a VRF to obtain a quantity Pi that is not manipulable by the miner. If the quality of Pi is above a certain threshold τP ROP OSER, they are a potential leader for round r. The actual leader of round r is thus the miner that publishes a quantity Pi that is the best of all quantities that were proposed. The notion of potential leader exists to reduce the communication complexity of the protocol: if a miner draws a value from the VRF that is not good enough to even be considered a leader, then it does not broadcast a block for round r. Another interesting notion in this construction is that the VRF cannot be calculated by anyone other than the process itself. As such, an attacker with DoS capabilities cannot target a leader before they publish their winner block, after which time it is already too late for the attacker to gain any meaningful advantage. As for the committee selection, it is done in a similar fashion to potential leader selection, that is, at each round, each process i calculates a quantity Vi using a VRF and checks if this value is above a certain threshold τ. Assuming the VRF is uniformly distributed, τ allows us to estimate and control how many participants will be in the committee. The processes in the committee are then in charge of selecting the leader (and thus, the winner block) for a given height using BA∗1.

1 For further details on BA∗, we direct the reader to [8].

14 Algorand further extends their construction to have the members’ probability of winning or participating in the committee be based on how much stake they have in the system, in a Proof-of-Stake fashion. This is used to give better security guarantees. However, and as we have seen before when talking about Proof-of-Stake, this may lead to some inequalities, where the rich processes get richer and, over time, are able to exert more control in the system.

2.4 Random Beacons in Blockchains Random beacons are a way to generate fresh randomness for multiple parties, at steady intervals. The use of random beacons has the potential to support Proof-of-Space blockchain systems, because they provide [30,31]: i) liveness, generating randomness at steady inter- vals, ii) unpredictability, which prevents malicious participants from guessing the output of the random beacon, iii) bias-resistance, which does not allow the malicious participants to arbitrarily change the outcome of the random beacon and iv) publicly-verifiability, allowing bystanders to verify the validity of the generated randomness. If challenges are derived from the randomness provided by a beacon, we reduce the ability for a malicious miner to explore the nothing-at-stake issue, because their puzzles will be based on the randomness imposed by the beacon, as well as setting a pace at which the chain can grow. HydRand [30] implements a random beacon. It is a recent approach that improves on most previous proposals by reducing the communication complexity from the O(n3) of some well known random beacon algorithms, such as RandShare [32], to O(n2), where n is the number of processes participating in the protocol, making it more scalable. Hydrand offers guaranteed output delivery, that is, a malicious process cannot prevent honest ones from getting an output at every round. This is done by using PVSS [33] commitments, a type of commitment that can be opened if multiple parties that hold a share of the secret cooperate. In doing so, the protocol is always able to make progress, even with malicious processes. RandHerd [31] also implements a random beacon, making use of sharding to allow for the random beacon protocol to scale better. Sharding is described as dividing the partici- pants in the protocol into smaller subgroups. By having each subgroup generate their own randomness, then combine all subgroups randomness, the protocol is able to achieve a com- munication complexity of O(c2log(n))2, where n is the total number of nodes in the system and c is the size of subgroups in the system. This is a low communication complexity com- pared to most random beacon protocols out there, which makes it very scalable and thus, interesting for a blockchain application.

2.5 Discussion There exist multiple blockchain proposals out there that offer different properties. Per- missioned blockchains usually offer better safety guarantees and transaction handling guar- antees, at the expense of scalability, while permissionless constructions prioritize liveness, with some safety relaxations. Proof-of-Work approaches have high energetic costs, which becomes undesirable from a sustainability point of view. Some other approaches that replace Proof-of-Work, such as 2 This statement is made in the original paper [31], however, according to an analysis in [30], the actual communication complexity may be O(n), which is higher than O(c2log(n)) when c is constant and n is large

15 Proof-of-Stake or Proof-of-Space, suffer from the nothing-at-stake issue, since generating proofs is computationally easy. Byzantine agreement approaches are interesting because they may scale well, if using committees, and give better confirmation times for transactions. They require however well-studied reconfiguration strategies that are proven to be secure, and committee members need to be online for the roles of the committee to be fulfilled. In Table 1 we make a critical analysis of the blockchain implementations mentioned above.

Protocol Name Non-counterfeitable Throughput % of honest Latency Liveness/Safety resource (tx/s) resource (s) [1] Bitcoin Computation time 5 50% 600 Yes/Prob. [2] Ethereum Computation time 10 50% 360 Yes/Prob. [22] Eth 2.0 Stake - 67% - Yes/Prob. [8] Algorand Stake and > 1k 67% 5 Prob./Yes Byzantine Agreement [14] Hyperledger Byzantine > 3.5k 67% <1 Prob./Yes Fabric Agreement [23] Hyperledger Trusted Execution 900 100% 28 Yes/Yes Sawtooth Environment [10] Chia Space and VDF - ∼63% - Yes/Prob. [28] EtherSpace Space 5 67% 240 Yes/Prob. AstroChain Space high 67% low Yes/Yes Table 1: Comparison between existing blockchain implementations

In Table 1, Non-counterfeitable resource is the resource that cannot be forged and thus, prevents Sybil attacks and is used to achieve blockchain consensus. In the case of Hyperledger Sawtooth, we considered the TEE as a resource because it is the underlying technology that enables the blockchain to work. Hyperledger Fabric does not use a specific ”resource” to ensure security but a consensus algorithm. In our approach, we will be using Proof-of-Space, and therefore, the non-counterfeitable resource becomes memory and space in disk. Throughput is the average number of transactions per second that the blockchain is able to confirm. In the case of Eth 2.0 [22], as of writing this document, only the first phase has been launched and thus no meaningful analysis has been performed on throughput. As for Chia [10], the blockchain is currently gathering miners without processing transactions, and thus no throughput value is available. In our approach, we hope to achieve throughput values that are better than Proof-of-Work approaches. The % (Percentage) of honest resource refers to the amount of non-counterfeitable re- source that honest users must own in order for the blockchain to ensure its security. In the case of Hyperledger Sawtooth, 100% is stated because a process must use the TEE to participate and, as such, all miners are, by construction, ”honest”. Hyperledger fabric uses a consensus algorithm and, as such, 67% is the optimal percentage of participants that must be honest. We state 67% as our percentage of honest resources because random beacon protocols usually require 2/3 of the participants to be honest. Latency refers to the average time a round in the blockchain is expected to take. As with throughput, because Chia and Eth 2.0 are recent blockchain proposals that are at early production stages, there are no known meaningful latency values. Here, our approach

16 should be able to have lower latencies than existing blockchain approaches, as the round time should be similar to the random beacon pace, which is in the order of tens of seconds. Finally, in the Liveness/Safety column we point out whether the system provides these properties or if they are guaranteed in a probabilistic fashion. As can be seen for most per- missionless blockchains mentioned, liveness is the main focus, and so it is always guaranteed, while Safety is probabilistic. Our approach should be similar to this scenario. In Section 3 we introduce a possible construction that may ensure Safety as well. Algorand is different from most permissionless blockchains because Safety is guaranteed by using Byzantine agreement. However, we consider its liveness to be probabilistic because winner blocks may be empty, that is, blockchain progress at each round is probabilistic. Hyperledger uses consensus as its security mechanism, sacrificing liveness in exchange for the stronger safety guarantees these protocols entail.

3 AstroChain

Nowadays, blockchains mostly rely on Proof-of-Work, which is not ideal for its high energy consumption and overall high confirmation times. Alternatives such as Proof-of-Stake and Proof-of-Space promise better sustainability and scalability but introduce problems such as the nothing-at-stake issue, thus they need to be combined with other mechanisms that counter this issue. In this thesis, we propose AstroChain, a novel Proof-of-Space permissionless blockchain that makes use of random beacons to offer better energy efficiency than most permissionless blockchain systems out there, as well as better transaction handling overall. In doing so, we expect to make evident the potential of blockchain systems that use Proof-of-Space as their blockchain consensus mechanism. AstroChain is divided into three main components: the ”proof chain”, where Proofs-of- Space are chained with one another, the ”random chain”, where the outputs of the random beacon protocol are stored, and the ”transaction chain”, where we chain the transactions parallel to the proofs. In Figure 1, we provide a high-level view of the system as a whole.

Block h - 1 Block h Legend:

Transaction block h - 1 Transaction block h Gets challenge from

Proof block h - 1 Proof block h Derives from

Random block h - 1 Random block h Reference

Fig. 1: Blocks at height h and h − 1

17 3.1 Proof chain

In AstroChain, we chain Proofs-of-Space independently of transactions, unlike how it is done in Bitcoin [1], for example. We call these blocks ”proof blocks”. Proof blocks are used to decide which processes will be joining the random beacon protocol next. The challenges for each height are dependent on the predecessor proof block, as well as the random beacon’s output, whose behavior we describe in Section 3.2. Depicted in Figure 2 we have a proof block’s structure, described as:

– Identifier of miner, the public key of the miner that generated this proof block – Reference to predecessor block, a hash of the predecessor block, so as to make impossible altering the chain’s past, otherwise the chain becomes invalid – Last random beacon output, in order to generate the challenge that this block solves (i.e. generates a proof to) – Signature of block, to ensure integrity and authenticity of the block

Proof block Challenge Public key Predecessor block reference Proof-of-Space Previous random beacon output Signature

Fig. 2: ”Proof block” structure

In our Proof-of-Space, we will consider the inversion of random functions, because it enables a node to join the system without the need for interactivity, that is, a node may simply go through the initialization phase, and, once done, may start mining immediately, which is a desirable property for a permissionless blockchain. The construction in [27] was built with the possibility of further inverting the functions: instead of only finding collisions on f, we also find collisions on gf , store them as input to another random function, and then find further collisions, and so on. This gives better security guarantees, as an attacker needs to perform many more computations to successfully undermine a proof, but it makes the initialization process much slower, which is not problematic, as the important step that needs efficiency is verification. We will consider initially only the simplest version of random function inversion, with the possibility of extending to further inversions if deemed necessary.

3.2 Random chain

AstroChain makes use of randomness generated by a random beacon protocol to create the challenges, as well as impose steady progress to the blockchain. As such, we store in parallel to the proof chain the outputs of the random beacon, into what we call ”random blocks”. Figure 3 describes the overall random block structure, which we describe as:

18 – Predecessor random block reference, used to ensure that the random outputs are properly chained – Current proof block reference, used to ensure that this random block refers to a specific height, and finalize a proof block – Random beacon output value, the actual random value that we obtain from the normal execution of the random beacon – Log of random beacon execution, which holds the message exchanges performed in the random beacon, for external nodes to verify the validity of the output

Random block Predecessor random Random beacon block reference output value

Current proof block Log of random reference beacon execution

Fig. 3: ”Random block” structure

To implement the random beacon in our system, we will consider both HydRand [30] and RandHerd [31] as possible approaches. Both of these algorithms do not support partici- pant reconfiguration, because they were developed as standalone random beacon protocols. AstroChain requires that to happen because the participants in the committee will be chang- ing dynamically, in a fashion similar to Solida [5]. We proceed to motivate both protocols as random beacons for blockchains and suggest reconfiguration approaches that may be interesting for our system. In HydRand, there is a focus on having guaranteed output delivery, that is, guaranteeing that the beacon outputs at a steady and bounded pace, despite the presence of malicious pro- cesses. Guaranteed output delivery is a very desirable property in a blockchain environment since liveness is the main focus of blockchains nowadays. This introduces a relatively high communication complexity of O(n2), where n is the number of participants in the protocol. This complexity comes from the fact that it requires nodes to broadcast messages to all nodes in the system, which impacts scalability. For the random beacon to be practical, the committee needs to have a reduced number of nodes. As for reconfiguration, two approaches may be considered: at every round of the blockchain, we do a reconfiguration, that is, a new potential leader tries to enter the committee by doing a view-change round. If it succeeds, it broadcasts its commitment and joins the committee, while the oldest member of the com- mittee leaves. This approach allows for continuous steady output, but the pace gets slowed down by the reconfiguration at every round. Another option is to leave the committee as-is for some blockchain rounds and then introduce a new committee every few rounds. This may introduce some temporary delays from time to time but allows for continuous operation in these ”in-between” periods. We will analyze both approaches to determine which is more practical and allows for better security and performance. RandHerd’s focus is scalability, which is very important in a permissionless blockchain, where we want as many nodes to be able to join without negatively impacting performance

19 or security. This protocol has a probabilistic liveness guarantee, however, based on how big the subgroups are. For subgroups of size c = 32, the probability of failure is around 0.08%. The reconfiguration in this protocol may be done by determining which is the oldest member in the committee and replacing it with the new leader after a view-change protocol. The new leader will become part of an existing subgroup. In RandHerd, for a subgroup to function, they must go through an initialization protocol. As such, if a new leader joins the subgroup, the initialization protocol must be remade, which will introduce an overhead in the reconfiguration process.

3.3 Transaction chain

Finally, in AstroChain we store transactions in a separate chain, parallel to the proof chain. To do this, we have what we call ”transaction blocks”, which are comprised of, as depicted in Figure 4:

– Predecessor transaction block reference, allowing for chaining of transactions and ensure the validity of the past transactions – Current proof block reference, to make sure that a transaction block is indeed at a given height, ensuring the order of the transactions – Transactions, the actual transaction information – Signature, to ensure the integrity of the transactions, as well as make sure that the issuer of the transaction block is the same as the creator of the current proof block

Transaction block

Predecessor transaction Transactions block reference

Current proof block Signature reference

Fig. 4: ”Transaction block” structure

This approach to transaction handling does not ensure the integrity of the transaction block during the round it was created, since the proof is not dependent on it and the only integrity guarantee comes from the signature, which allows for a round leader to change the transaction block. However, once a transaction block is added to the chain on top of the current one, the latest block needs to be changed for the transaction chain to still be valid. The more blocks are added to the chain, the more likely it is that one honest block is added to the chain. When this happens, the transaction history is ensured, as no honest miner will change its transaction block.

20 3.4 Vulnerabilities and solutions

As stated before, Proof-of-Work suffers from the nothing-at-stake issue because proofs are computationally easy to generate. As such, we list some attacks that exploit this vul- nerability, and how our solution protects against them:

– digging attacks - these attacks are defined as a malicious miner trying to extend a block in multiple ways. This is usually done by trying out multiple transaction combinations to try to obtain a better proof, in a way that is unfair when compared to honest behavior. This attack is executable in Proof-of-Space approaches because generating proofs is computationally easy. Our construction prevents this attack by having transactions and proofs be decoupled from one another. This way, proofs are unique and a malicious miner cannot obtain different proofs for the same height. – long range attacks - these attacks are defined as a malicious miner trying to generate a chain starting at some point in the past of the blockchain. Because proofs are easy to generate, the malicious miner could try to create a chain in private that eventually outgrows the honest one. To prevent this, we use the random beacon, which will force a steady rhythm at which the chain can grow. A malicious miner is then bounded by the random beacon progress, which prevents them from outgrowing the honest chain. – double-dipping attacks - these attacks are characterized as a malicious miner extending blocks that are not the best one for a given height, in hopes of obtaining a better chain when they generate a block on top of this less desirable block. Our construction prevents this by having the random blocks reference the current proof block. In doing so, the proof block that is chosen becomes final, and therefore miners can only mine on top of this one proof block.

3.5 Discussion

In this proposal, we have discussed a blockchain system that allows for better energy efficiency than most blockchains out there, because our system relies solely on Proof-of- Space as well as a random beacon protocol. Proof-of-Space improves on Proof-of-Work energy efficiency because generating a proof can be compared to a few memory accesses, instead of the large amounts of computations that must be done in Proof-of-Work. The random beacon protocol is also energy efficient, for its major energetic costs come from the cryptographic primitives one must calculate for verification purposes, for instance, which are much less than the number of calculations one must perform in Proof-of-Work. Our transaction handling techniques also have the potential of yielding better results than most state-of-the-art approaches, especially Proof-of-Work approaches, because forks are unlikely if we combine the random beacon with the proof-generation. By having this sort of immediate finality, the confirmation times are only bounded by the random beacon speed, which is ideal, for it only relies on message passing and not parametrization of functions. Our system will be built upon the go-ethereum [34], the official open-source implemen- tation of Ethereum [2] in Go. This allows for a more modular view of a blockchain system, implementing the main communication system relative to a blockchain. As such, it allows us to focus on the main challenges of our system, namely, replacing Proof-of-Work with Proof-of-Space and implementing a random beacon protocol with a blockchain system.

21 4 Evaluation

To evaluate AstroChain and its performance and security guarantees, we will seek to answer the following research questions:

– Is our system more energy efficient than current blockchain implementations? – What is our blockchain system throughput and how does it compare to existing ones? – Can we obtain low confirmation times with a Proof-of-Space approach? – Does our system scale well, allowing for a similar number of participants of current permissionless blockchains?

To answer these questions, we will measure confirmation times, empirically analyze the transaction throughput and the total energy consumption of the system. We shall also test scalability, both in the committee size and the total number of participants in the blockchain. To do so, we will deploy the system across multiple machines, to better emulate the functioning of a real blockchain. In terms of workload, we will extract a number of consecutive blocks from the Ethereum blockchain as transaction sources. Using this as a testing base, we will be able to compare our system performance to Ethereum [2]. This allows us to understand how our system compares to a currently widely-used blockchain. By the time of our evaluation, we also hope that Chia [10] is in a more advanced production stage, so as to allow us to compare our implementation with another Proof-of-Space approach. This would be ideal, as Proof-of- Space is still a recent approach for blockchain consensus and we would be able to have a more accurate baseline for comparison.

5 Schedule of Future Work

In Table 2 we provide a draft of the organization and timings we expect to follow during thesis development. Throughout the whole research and development cycle, we will proceed with the writing of the final thesis document.

Begin End Task 01 Feb 2021 08 Feb 2021 Specification 08 Feb 2021 15 Feb 2021 Study go-ethereum as a framework 15 Feb 2021 01 Mar 2021 Implement Random Beacon with reconfiguration 01 Mar 2021 15 Mar 2021 Implement Proof-of-Space 15 Mar 2021 19 Apr 2021 Implement system 19 Apr 2021 26 Apr 2021 Test planning 26 Apr 2021 13 Jul 2021 Testing and Evaluation of tool 13 Jul 2021 21 Sep 2021 Writing of thesis document Table 2: Draft of schedule for thesis development

22 6 Conclusion

While Proof-of-Work has been able to ensure most blockchain systems’ security so far, it has a big energy footprint and thus, it is unsustainable. In this document, we propose AstroChain, a Proof-of-Space blockchain that allows for a more sustainable system, while ensuring the same security properties as Proof-of-Work approaches and possibly improving on its throughput and confirmation times. Our approach builds upon existing blockchain proposals and combines them with a random beacon, which allow for challenge generation in an unbiased way and prevents malicious users from progressing faster than the honest chain. Random beacons are usually not thought out to allow for reconfiguration, and thus, our proposal will also provide an adaptation of existing random beacon protocols to allow for members to change over time, while maintaining their security properties. A practical and secure Proof-of-Space system has the potential to replace existing blockchain systems, at a much lower energy cost and also, at a much lower mining cost. As such, mining becomes much more attractive, and an ideal setting where the system is fully decentralized becomes more likely.

References

1. S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Cryptography Mailing list at https://metzdowd.com, 03 2008. 2. Ethereum, “Ethereum white paper,” https://ethereum.org/en/whitepaper/, accessed: 11- November-2020. 3. “Bitcoin energy consumption index,” https://digiconomist.net/bitcoin-energy-consumption/, accessed: 07-November-2020. 4. “Ethereum energy consumption index (beta),” https://digiconomist.net/ethereum-energy- consumption/, accessed: 21-December-2020. 5. I. Abraham, D. Malkhi, K. Nayak, L. Ren, and A. Spiegelman, “Solida: A blockchain protocol based on reconfigurable byzantine consensus,” 2017. 6. I. Eyal, A. E. Gencer, E. G. Sirer, and R. V. Renesse, “Bitcoin-ng: A scalable blockchain protocol,” in 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16). Santa Clara, CA: USENIX Association, Mar. 2016, pp. 45–59. [Online]. Available: https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/eyal 7. E. K. Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford, “Enhancing bitcoin security and performance with strong consistency via collective signing,” in 25th USENIX security symposium (USENIX security 16), 2016, pp. 279–296. 8. Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand: Scaling byzantine agreements for cryptocurrencies,” in Proceedings of the 26th Symposium on Operating Systems Principles, 2017, pp. 51–68. 9. S. Park, A. Kwon, G. Fuchsbauer, P. Gaˇzi,J. Alwen, and K. Pietrzak, “Spacemint: A cryp- tocurrency based on proofs of space,” in International Conference on Financial Cryptography and Data Security. Springer, 2018, pp. 480–499. 10. B. Cohen and K. Pietrzak, “The chia network blockchain,” 2019. 11. J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and appli- cations,” Cryptology ePrint Archive, Report 2014/765, 2014, https://eprint.iacr.org/2014/765. 12. R. Pass, L. Seeman, and abhi shelat, “Analysis of the blockchain protocol in asynchronous net- works,” Cryptology ePrint Archive, Report 2016/454, 2016, https://eprint.iacr.org/2016/454. 13. M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in OSDI, vol. 99, no. 1999, 1999, pp. 173–186.

23 14. E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, and et al., “Hyperledger fabric,” Proceedings of the Thirteenth EuroSys Conference, Apr 2018. [Online]. Available: http://dx.doi.org/10.1145/3190508.3190538 15. A. Back et al., “Hashcash-a denial of service counter-measure,” Tech Report, August 2002. 16. M. Conti, E. S. Kumar, C. Lal, and S. Ruj, “A survey on security and privacy issues of bitcoin,” IEEE Communications Surveys & Tutorials, vol. 20, no. 4, pp. 3416–3452, 2018. 17. “Bitcoin confirmed transactios per day,” https://www.blockchain.com/charts/n-transactions, accessed: 14-November-2020. 18. E. Syta, I. Tamas, D. Visher, D. I. Wolinsky, P. Jovanovic, L. Gasser, N. Gailly, I. Khoffi, and B. Ford, “Keeping authorities ”honest or bust” with decentralized witness cosigning,” 2016. 19. QuantumMechanic, “ instead of proof of work,” https://bitcointalk.org/index.php?topic=27787.0, accessed: 14-November-2020. 20. V. Buterin, “Slasher: A punitive proof-of-stake algorithm,” https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/, accessed: 22-December-2020. 21. P. Daian, R. Pass, and E. Shi, “Snow white: Robustly reconfigurable consensus and applications to provably secure proof of stake,” in International Conference on Financial Cryptography and Data Security. Springer, 2019, pp. 23–41. 22. Ethereum, “Eth2 upgrade,” https://ethereum.org/en/eth2/, accessed: 20-November-2020. 23. Hyperledger, “Hyperledger sawtooth,” https://sawtooth.hyperledger.org/, accessed: 21- November-2020. 24. L. Chen, L. Xu, N. Shah, Z. Gao, Y. Lu, and W. Shi, “On security analysis of proof-of-elapsed- time (poet),” in International Symposium on Stabilization, Safety, and Security of Distributed Systems. Springer, 2017, pp. 282–297. 25. A. Corso, “Performance analysis of proof-of-elapsed-time (poet) consensus in the sawtooth blockchain framework,” 2019. 26. S. Dziembowski, S. Faust, V. Kolmogorov, and K. Pietrzak, “Proofs of space,” in Annual Cryptology Conference. Springer, 2015, pp. 585–605. 27. H. Abusalah, J. Alwen, B. Cohen, D. Khilko, K. Pietrzak, and L. Reyzin, “Beyond hellman’s time-memory trade-offs with applications to proofs of space,” Cryptology ePrint Archive, Re- port 2017/893, 2017, https://eprint.iacr.org/2017/893. 28. D. P. Castilho, “Etherspace: Practical proof-of-space for blockchains,” 2019. 29. M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “Hotstuff: Bft consensus with linearity and responsiveness,” in Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, 2019, pp. 347–356. 30. P. Schindler, A. Judmayer, N. Stifter, and E. Weippl, “Hydrand: Practical continuous dis- tributed randomness,” 2020. 31. E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford, “Scalable bias-resistant distributed randomness,” in 2017 IEEE Symposium on Security and Privacy (SP). Ieee, 2017, pp. 444–460. 32. M. Raynal, “Randshare: Small-scale unbiasable randomness protocol,” 2018. 33. M. Stadler, “Publicly verifiable secret sharing,” in Advances in Cryptology — EUROCRYPT ’96, U. Maurer, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 1996, pp. 190–199. 34. Ethereum, “go-ethereum,” https://github.com/ethereum/go-ethereum, accessed: 13-December- 2020.

24