TwinsCoin: A Cryptocurrency via Proof-of-Work and Proof-of-Stake
Alexander Chepurnoy∗ Tuyet Duong† Lei Fan‡ Hong-Sheng Zhou§
Abstract 1 Introduction
e emergence of decentralized cryptocurrencies like We design and implement TwinsCoin, the rst cryp- Bitcoin [40] has the potential to signicantly reshape the tocurrency based on a provably secure and scalable future of nancial transactions and distributed interac- public blockchain design using both proof-of-work and tions in general, and eventually bring us a much more or- proof-of-stake mechanisms. Dierent from the proof-of- ganized and documented digital world. In the Bitcoin sys- work based Bitcoin, our construction uses two types of tem, a public distributed ledger, called blockchain, is main- resources, computing power and coins (i.e., stake). e tained by a peer-to-peer network of nodes called Bitcoin blockchain in our system is more robust than that in a miners via the proof-of-work (PoW) mechanism [2,15]. pure proof-of-work based system; even if the adversary Essentially, the proof-of-work mechanism enables an controls the majority of mining power, we can still have open blockchain, where miners are allowed to join and the chance to secure the system by relying on honest leave the system at any moment. stake. In contrast, Bitcoin blockchain will be insecure if the adversary controls more than 50% of mining power. Garay et al. [18] and then Pass et al. [44] investigated the blockchain security in the cryptographic seing and Our design follows a recent provably secure proof- have shown that, assuming the majority of mining power of-work/proof-of-stake hybrid blockchain by Duong et in the Bitcoin system is controlled by the honest miners, al. (ePrint 2016). In order to make our construction prac- the blockchain indeed satises several important secu- tical, we enhance Duong et al.’s design. In particular, we rity properties (which are critical for blockchain-based introduce a new strategy for diculty adjustment in the applications). In contrast, if the assumption of “honest hybrid blockchain and provide an analysis of it. We also majority of computing power” does not hold, i.e., the show how to construct a light client for proof-of-stake adversary dominates the computing resources in the sys- cryptocurrencies and evaluate the proposal practically. tem, then Bitcoin blockchain will not be trustworthy any We implement our new design. Our implementa- more. tion uses a recent modular development framework for In practice, it is not clear if assumption of “honest blockchains, called Scorex. It allows us to change only majority of computing power” always holds. Here are certain parts of an application leaving other codebase few examples. GHash.io, the largest mining pool at the intact. In addition to the blockchain implementation, a moment, exceeded 50% of Bitcoin’s mining power in testnet is deployed. Source code is publicly available. 2014 [20]. For now, several top mining pools (e.g., F2Pool, AntPool, BTCC, BW) collectively control about 60% min- ing power. It is unclear if they could be inuenced by ∗IOHK. Email: [email protected]. certain party or collude. Novel ideas were introduced [38] †Virginia Commonwealth University. Email: duong[email protected]. to discourage the formation of mining pools. Unfortu- ‡Shanghai Jiao Tong University. Partial work done while visiting the Cryptography Lab at Virginia Commonwealth University. Email: nately, if the adversary controls the majority of mining [email protected]. power, they can still be able to dominate the system §Virginia Commonwealth University. Email: [email protected]. (which makes the system not trustworthy). We also re-
1 mark that blockchain protocols could be vulnerable dur- However, these existing solutions cannot scale to a large ing the process of spliing. As an example, in Summer number of network nodes in an open seing where par- 2016 Ethereum network had been split into two forks, ticipants can freely join or leave the system at any time Ethereum and Ethereum Classic. In the early days of they want. Ethereum Classic one of the biggest Ethereum miners, In particular, in these existing provably secure, pure Chandler Guo, threatened it with “51% aack” [22]. Simi- PoS proposals, a majority voting (or the equivalent) is larly, in the face of a possible spliing in Bitcoin, a group required to enable new participants to join the system. of miners supporting Bitcoin Unlimited was threatening In contrast, without this mechanism, the adversary could “CoreCoin” with the same adversarial majority mining corrupt elected leaders at a later point and produce an power aack [12]. How can users protect their assets “alternative” blockchain which could be longer than the from a majority of mining power which is willing to blockchain in the system (even if the adversary does not destroy the system? is leads to our research goal: control the majority of stake). Unfortunately, this voting Research Goal: Develop Bitcoin-like open blockchains so process requires most of existing players to participate in that they can be secure even when the adversary controls the protocol, which cannot scale to a large scale network. more than 50% computing power. At the moment of writing, it remains unclear if we can construct a provably secure, scalable open blockchain via any pure PoS mechanism. 1.1 Our Approach We here remark that these recent provably secure 1.1.1 Singling out a suitable candidate blockchain pure PoS-based protocols are useful for relatively small networks. But they not suitable for (potentially big) open e research goal above seems to be impossible to reach networks because of performance issues. without additional resources or assumptions. It is pop- 2-hop blockchain is scalable but not practical yet. ular in the cryptocurrency community to suggest to Duong et al. [14] design the rst provably secure and scal- use coins (i.e., stake) in order to protect the blockchain. able open blockchain, called “2-hop blockchain”, via com- Such method is called proof-of-stake (PoS). In a high level, bining proof-of-work and proof-of-stake. In their design, proof-of-stake requires protocol players to prove own- in addition to miners, a new type of players, stakeholers ership of a certain amount of stake in the system. Only (stakeholders) are introduced. A winning miner cannot those who can provide such a proof can participate in extend the blockchain immediately as in Bitcoin. In- the process of maintaining the blockchain. Naturally, stead, the winning miner provides a base which enables we could have two approaches to achieve the research a stakeholder to be “selected” to extend the blockchain. goal: (i) blockchain via a pure PoS mechanism, and (ii) at is, a miner and then a stakeholder jointly extend blockchain via a hybrid (PoW and PoS) mechanisms. the blockchain with a new block. Note that, in Bitcoin, We are aware that it is dicult to give a complete se- winning miners directly extend the blockchain. curity analysis for a complex, real-world protocol such as Bitcoin. However, the well-received provable security In the 2-hop blockchain protocol PoW-chains and approach still deserves our aention. If a full-edged PoS-chains are plaited together in every time step, and security analysis of a blockchain protocol is not feasible these PoW/PoS-chains are extended alternately. Intu- at the moment, we could focus on a much simplied itively, the 2-hop blockchain can be viewed as a proof- “core” of the targeted protocol. Provable security of the of-stake scheme which uses a proof-of-work chain as simplied core, once established, will help gain signi- a biased random beacon. is critical idea enables the cant condence on the security of the target blockchain. 2-hop scheme to achieve almost the same eciency as With this in mind, we next make eort to single out the original Bitcoin scheme. Also, the 2-hop blockchain a candidate, i.e., a provably secure blockchain core, so can scale to a large size of network. that we may be able to “upgrade” the candidate core to Unfortunately, Duong et al.’s 2-hop blockchain, as it the full-edged blockchain, and eventually achieve our is, has a signicant weakness: the resulting blockchain research goal. protocols are expected to be executed in the static proto- col execution environments. at is, in each round, the Existing provably secure pure proof-of-stake invested/involved physical computing resources as well schemes do not scale. Blockchain researchers have as virtual resources (i.e., stake/coins) in the system are made aempts to construct provably secure, scalable always the same. is does not reect the reality. Take blockchains via pure PoS mechanisms; see [6, 31, 36]1. Bitcoin as an example. In the past years, the amount of 1ese are concurrent eorts of our work. computing resources that invested for each unit of time
2 period has increased dramatically. In Bitcoin, Nakamoto blockchain in this paper essentially consists of two parts, creatively introduced the diculty adjustment mecha- the PoW-chain, and the PoS-chain, and they always go nism to address this issue. By seing a target of extending along together, like twins, and we coin our system as the blockchain with a new block in each 10 minutes, and TwinsCoin. by measuring the total time for extending a xed number (e.g., 2016) of blocks, each miner can be aware if more 1.2 Our Contributions computing power has been invested. If so, then each miner will increase the diculty, and vice versa. Unfortu- In this paper we provide a clear roadmap for designing nately, adaptive diculty adjustment mechanism is miss- provably secure yet scalable blockchain protocols which ing in the 2-hop blockchain. We remark that blockchains can be secure even when the adversary controls more without adaptive diculty adjustment mechanism can than 50% computing power in the system. We prove oen be easily broken. Nevertheless, the provably se- viability of our design in practice with the help of an cure, and scalable 2-hop blockchain can serve as a good actual implementation done. In details, our contributions starting point for us to achieve our research goal. are as follows: • Garay et al. [19] extend their previous model [18] 1.1.2 From 2-hop blockchain to TwinsCoin by addressing adaptive diculty adjustment in the Adaptive diculty adjustment. In our TwinsCoin Bitcoin system. In our work, we further extend their system design, we need to make our blockchain proto- model by allowing diculty adjustment for both cols to be adaptive to the protocol execution environ- proof-of-work and proof-of-stake. To the best of ments. Note that here we have to address two types of our knowledge, there has not been yet a formal def- resources, computing power and stake. It seems that inition, design, and analysis for adaptive diculty we need to measure the system through two dierent for proof-of-stake, or hybrid proof-of-work/proof- ways. However, in the original 2-hop design, the total of-stake blockchains. Furthermore, before our work, number of proof-of-work blocks (PoW-blocks) is equal to there is no treatment in non-at seing. the total number of proof-of-stake blocks (PoS-blocks). It • We propose a way to make light clients possible is not clear how to use Nakamoto’s diculty adjustment in a proof-of-stake seing. As far as we know this mechanism directly for our purpose. is the rst concrete proposal backed by a practical In order to address this issue, we change the evaluation. blockchain structure. Our new blockchain structure al- low us to “measure” the system thru two dierent ways. • We provide experimental results on dierent char- Now we record more PoW-blocks, called aempting acteristics of certain parts of our proposal. In par- proof-of-work blocks; these blocks are generated due to ticular, we obtain concrete numbers for a race of a successful rst hop, but a failure second hop. For the adversarial and honest chains as initial estimations sake of presentation, we call PoW-blocks successful if on security against adversarial majority of mining they are generated due to a successful rst hop along power. Some properties of proof-of-stake diculty with a successful second hop. Once we have two types adjustment function are also obtained in a dierent of PoW-blocks, we can measure the ratio between these experiment. e light client proposal has been exam- two types of PoW-blocks. is idea eventually allows us ined in a set of experiments measuring verication to design a new diculty adjustment mechanism. time as well as an overhead needed for a simulated Moving the underlying blockchain to the non-at blockchain. We also provide a full-edged imple- setting. In the original 2-hop blockchain design [14], mentation of our design in the form of TwinsCoin the resulting blockchain protocols are expected to be cryptocurrency. Source code of the implementation executed in the idealized at-model. Note that, in the at is available. More details on the implementation model, each proof-of-work miner holds the same amount and the experiments can be found in Section5. of computing power and each proof-of-stake holder has the same amount of stake (i.e., coins). Apparently, this Organization. In Section2, we present our threat model at model does not reect the reality. Strictly sticking to and assumptions. In Section3, we recall the most rele- the at model will only allow us to design non-practical vant work that TwinsCoin system builds on: Nakamoto’s blockchains. blockchain and 2-hop blockchain. Next, in Section4, we Blockchain is the core component of our TwinsCoin present the details of our TwinsCoin design, and then in system. Note that, the designed and then implemented Section5, we provide the implementation and evaluation
3 details. Future work and related work are provided in Assumptions. As in [14], we assume that the major- Section6 and in Section7, respectively. Finally, some ity of collective resources (including hashing power and supporting materials are provided in AppendixA, and stake) are controlled by well-behaved (honest) players. B. Furthermore, our system is assumed to be extended from an “already mature blockchain” such as Bitcoin blockchain. 2 reat Model and Assumptions 3 Background We consider a standard multi-player asynchronous com- munication seing (e.g., Canei’s formulation of the “real 3.1 Nakamoto’s blockchain world” execution [10]), with the relaxations that (i) the We here briey review Nakamoto’s Bitcoin blockchain [40]. underlying communication graph is not fully connected, Bitcoin blockchain is based on proof-of-work puz- and (ii) the underlying communication channel is reliable zles [2, 15], which can be abstractly described via the but not authenticated. In this seing, an adversary is not following hash inequality: allowed to stop the messages from being delivered, but he may “spoof” the source of a message and impersonate H(hw,w,X) < T the (well-behaved) sender of the message, or to “delay” κ messages from any participants. Moreover, the adver- where hw 0,1 is the hash of the previous proof-of- sary is “rushing” in the sense that, in any given round, work block∈ {(κ is} a security parameter), w is a suitable he is allowed to see all honest (well-behaved) miners’ solution for this puzzle, X is the record component of the messages before deciding his strategy. block, and T denotes the current proof-of-work target. We consider a model which allows both proof-of-work See [18] for more details. miners and proof-of-stake holders, and the diculty for Extending the chain. At any point of the protocol proof-of-work and proof-of-stake can be adaptively ad- execution, each miner aempts to extend the blockchain. justed. We remark that all previous models (which will More concretely, upon receiving some record X, a miner be reviewed below) are idealized. In the reality, each chooses random w 0,1 κ and checks whether w is a dierent honest miner may have a dierent amount of valid solution to the∈ above { } hash inequality with respect computing power or stake. Our protocol is described in to hw, hash value of the last block in the blockchain; a non-at model where each stakeholder is associated if so, the miner reveals the solution to the system. In with a dierent amount of coins. Nakamoto’s design, multiple miners might nd distinct solutions with the same preceding block, in which a blockchain fork will be introduced. To resolve this issue, Previous models. Following the well-received prov- all well-behaved (honest) miners are expected to follow able security approach, Garay et al. [18] provide the rst the longest blockchain in the system. comprehensive security analysis framework for Bitcoin Security. Garay et al. [18] and Pass et al. [44] have al- blockchain in the cryptographic seing. To simplify the ready rigorously analyzed the security of Nakamoto’s analysis, Garay et al. consider an idealized “at-model” blockchain in the cryptographic seing. In a nutshell, where all miners have the same amount of computing the Nakamoto’s blockchain satises certain important power. security properties such as common prex, chain quality Pass et al. [44] recently extend Garay et al’s model [18] and chain growth, under the assumption that the major- by considering a more realistic communication network ity of computing power is controlled by honest players. (i.e., partial synchronous network) in which messages Please refer to AppendixA for the denitions of secu- from honest players can be delayed with an upper bound rity properties (common prex, chain quality and chain units of time. Duong et al. [14] propose a further ex- growth). tended model by considering two types of players, proof- of-work miners and proof-of-stake holders, in blockchain 3.2 Duong et al’s 2-hop blockchain protocols. Very recently, Garay et al. [19], extend their previous model [18] by addressing adaptive diculty for Nakamoto’s blockchain is powered by computing re- proof-of-work blockchains. To the best of our knowledge, sources, and the blockchain is maintained by only min- there has not been yet a formal denition and analysis ers. Duong et al. [14] propose 2-hop blockchain — a for adaptive diculty of proof-of-stake blockchains. combination of proof-of-work (PoW) and proof-of-stake
4 (PoS). ere, the blockchain is managed by two types ... B 1 B0 B1 B2 B3 B4 B5 ... of nodes, called miners and stakeholders (users). Corre- − spondingly, there are two types of chains: proof-of-work ... chain (PoW-chain), denoted , and proof-of-stake chain Be1 Be2 Be3 Be4 C (PoS-chain), denoted e, in the system. ese PoW/PoS time chains are securely tiedC together, as a chain-pair. Stake- holders maintain the proof-of-stake chain. On the other hand, miners together manage the proof-of-work chain Figure 1: 2-hop blockchain structure which is considered as a biased random beacon for choos- Here, dot arrows denote the rst hops, and solid arrows denote ing stakeholder (to extend the proof-of-stake chain). the second hops. Green blocks Bi’s denote the proof-of-work blocks, and red blocks B˜i’s denote the corresponding proof- Extending the chain-pair. In general, miners (or of-stake blocks. Note that 2-hop blockchain is bootstrapped stakeholders) collect information from the network, per- from an existing blockchain and the blue blocks are from the form some validation and generate proof-of-work blocks “mature blockchain”. (PoW-blocks) or proof-of-stake blocks (PoS-blocks), and then share their states to the network. Extending the PoW-chain: To generate a new PoW- is the best valid chain-pair. e criterion is that the win- ning chain is the longest valid one. block, each miner rst computes the hash hw κ ∈ 0,1 of the previous PoW-block (the head of the Security. Duong et al. [14] have already analyzed the {PoW-chain} ), the hash h 0,1 κ of the head of the s ∈ { } security of their 2-hop blockchain in the cryptographic PoS-chain. Here, without connecting to the head model. Under the assumption that the majority of collec- of the current PoS-chain, the adversary can rewrite tive resources (computing power and stake) are honest, any information stored on the chain-pair. e miner then important security properties such as common pre- then aempts to solve the following hash inequality x, chain quality and chain growth can be guaranteed. Similar to the analysis in [18, 44], their security analysis H(hw,hs,w) < T is in the at model. by nding a suitable solution w where T denotes the current proof-of-work target. If he succeeds in nding the proper w, he then generates a new 4 Main Design PoW-block which includes the hash values hw,hs and the solution w, and shares this PoW-block to Starting with a provably secure “core”, the 2-hop other players in the network. blockchain [14], we develop our TwinsCoin system by Extending the PoS-chain: In the 2-hop design, each following the steps below. PoW-block is used for selecting new stakeholders (to generate new PoS blocks). More concretely, if First, we redesign the structure of the 2-hop there is a new PoW block B in the system, any stake- blockchain in [14] with the goal of enabling a new holder whose verication key vk satises the follow- mechanism for adjusting diculties. We call this a ing hash inequality modied 2-hop blockchain. Please see Section 4.1. Second, based on the modied 2-hop blockchain, we H vk e(B, ) < eT introduce a new mechanism to adjust the diculties is allowed to generate a new PoS block. at is, for both PoW and PoS chains. Please see Section 4.2. the selected stakeholder can use the corresponding In addition, from a dierent angle, we extend the signing key sk to sign the new PoS-block. Note that 2-hop blockchain to the non-at seing where stake- here, eT is the current proof-of-stake target. holders may have dierent amounts of stake. Please Please see Figure1 for an illustration of 2-hop blockchain. see Section 4.3 for details. Resolving Fork. If multiple players (miners or stake- By combining these above steps, we have the holder) create blocks (PoW-blocks or PoS-blocks) with blockchain for our TwinsCoin. is new blockchain the same preceding block, the chain is forked into is in the non-at model with adaptive diculty ad- branches, forming a tree. Other players may subse- justment. quently add new valid blocks to any of these branches. Finally, we enhance the TwinsCoin system with light To resolve forks, the protocol species which chain-pair clients. Please see Section 4.5.
5 4.1 A modied blockchain structure the topmost successful PoW-block B` in blockchain . at is, we do not consider an aempting block as the headC of Besides PoS-blocks and PoW-blocks, our modi- the proof-of-work chain, and the head of a PoW-chain is ed blockchain species two types of PoW-blocks: not necessary the topmost PoW-block since the topmost aempting blocks and successful blocks with respect to the PoW-block could be an aempting block. Moreover, we local view of each player in the system. If a node receives only link a new proof-of-work block to the head of the a new PoW-block without a corresponding PoS-block, proof-of-work chain. is implies that there may multi- the PoW-block becomes an aempting block with respect ple aempting blocks aaching to a successful block in to the view of the player. In opposite, if a node receives a our proof-of-work chain. If a proof-of-work blockchain new PoW-block along with a corresponding PoS-block, is a prex of another blockchain , we write . the PoW-block is now considered as a successful block in C C0 C C0 the node’s local view. Extending a proof-of-work blockchain. Since the We now present the blockchain structure in our modi- PoW structure is changed, mechanism to extend a PoW ed 2-hop blockchain. Please also see Figure2. chain is slightly dierent from 2-hop design. Here, each miner will only mine from the latest successful proof-of- 1 1 work block. B2 B3 2 2 We illustrate the high level idea as in Figure3. In this B2 B3 3 3 B2 B3 gure, we consider a miner aempting to mine from a valid block-pair consisting of a PoW-block B and a PoS-block Be. ere, in the rst aempt, a new PoW-block ... B 1 B0 B1 B2 B3 ... 1 − B2 is linked to B (by the hash hw of B) and to Be (by the hash hs of Be); however, the corresponding PoS-block Be Be ... 1 1 1 2 of B2 is not seen by the miner. erefore, we say B2 time is an aempting PoW-block. In the second aempt, a 2 new PoW-block B2 is produced without any correspond- ing PoS-block, this block also becomes an aempting Figure 2: A modied 2-hop blockchain structure block. e third aempt is a successful one, and a new Here, dot arrows (that link to the previous successful block and successful PoW-block with the corresponding PoS-block aempting blocks) denote the rst hops, and solid arrows de- is aached to the chain. note the second hops. Green blocks Bi’s denote the successful j proof-of-work blocks, B ’s denote the aempting proof-of- 1 1 1 i B2 B2 B2 work blocks, and red blocks B˜ ’s denote the corresponding i 2 2 proof-of-stake blocks. Note that the blue blocks are from the B2 B2 hw “mature blockchain”. ha B1 B1 B1 B2 hs Proof-of-Work block structure. Let H( ) be a cryp- tographic hash function with output in ·0,1 κ. Now Be1 Be1 Be1 Be2 we have two dierent types of PoW-block{s: aempting} First Aempt blocks and successful blocks. e structure of aempting Second Aempt Successful Aempt and successful blocks are the same. However, they have dierent meaning: (1) no PoS-block refers to an Figure 3: Generating new PoW-blocks aempting block, and (2) we only count the successful blocks when calculating the real length of a proof-of- work chain. A PoW-block B is a tuple of the form Resolving fork. In 2-hop blockchain design, fork is re- κ hw,hs,ha,w , where ha 0,1 denotes the digest solved by choosing the chain-pair with the longest PoW- ofh the latesti seen aempting∈ {proof-of-work} block, w chain. In our design, a PoW-block could be an aempting 0,1 κ is a random nonce, and block B satises ∈ or successful block. Furthermore, successful blocks are { } much more important than aempting blocks. erefore, H(hw,hs,ha,w) < T the winning chain-pair is the one with the most number where the parameter T N denotes the current proof-of- of successful blocks, that is, the one that required (in work target of the block.∈ expectancy) the most successful mining power. A PoW-chain consists of a sequence of ` concate- Security. We emphasize that, this section only focuses nated successfulC PoW-blocks. We denote head( ) as to on the structure of the blockchain. We slightly modify C
6 2-hop blockchain to construct a more practical cryptocur- the i-th epoch. PoW diculty target is used to control rency system. e security proof for this modied ver- the probability of nding a new valid PoW-block for each sion is directly implied from 2-hop blockchain security. aempt. Secondly, we use eT to denote the PoS diculty Please refer to AppendixB for more details on our target in general. We also use eTi as the PoS diculty modied 2-hop blockchain. target in the i-th epoch. PoS diculty target is used to control the probability that a PoW-block is successfully 4.2 Blockchain with adjustable diculty mapped to a valid stakeholder. PoS diculty target adjustment. To extend a PoS- 4.2.1 Nakamoto’s diculty adjustment for PoW chain, a stakeholder uses the inequality eH(B,vk) < eT to In Bitcoin, in order to keep the block extension with a test if he is qualied to sign a PoS-block. Here, B is a new steady rate, the system adjusts the PoW hash target adap- PoW-block and vk is the verication key of the stake- tively. e intuition is that the lower target means lower holder. We assume the expectation of the probability probability to get a valid PoW block by calling a hash that a PoW-block is successfully mapped to a stakeholder function. is intuition provides a method to control the is R < 1. Suppose there are mi PoW-blocks that are gen- block generation rate by a diculty target adjustment erated in the i-th epoch. Let eTi be the PoS diculty in scheme. For some time interval, if the chain extension the i-th epoch. e PoS diculty in the (i + 1)-th epoch rate is higher than expected, the diculty target need to is dened by the following equation: be decreased to make the successful probability lower. m R e diculty target is adjusted every m blocks. In eT = i eT (1) i+1 m i Bitcoin system, we have m = 2016. We dene a time period of m blocks (precisely, dierence between times- We interpret the PoS diculty adjustment by the fol- mi tamps of the last and the rst blocks in the sequence) as lowing. If m R > 1, then the probability that the PoW- an epoch. Let t be the expected time of an epoch. For block is mapped to a stakeholder is lower than the expec- example, in Bitcoin a new valid block is to be generated tation R. e PoS target eTi+1 will be increased. Similarly, mi every 10 minutes on average. en we have t = m 10 if m R < 1, then the probability that the PoW-block is minutes, which is approximately 14 days for an epoch.× mapped to a stakeholder is higher than the expectation R Let ti be the the actual duration of the i-th epoch. Let . e PoS target eTi+1 will be decreased. Ti be the diculty target in the i-th epoch. We have the It is easy to see this is a negative feedback algorithm diculty target in the (i + 1)-th epoch as follows: that can maintain the successful probability close to R. As far as we know this is the rst diculty adjustment t T = i T procedure for proof-of-stake. i+1 t i PoW diculty target adjustment. e diculty ad-
From the equation above we can observe that, if ti > t justment strategy for PoW-chain in our system is similar then Ti+1 > Ti and vice-versa. In the case that ti > t, the to the original Bitcoin system except that we addition- miners spend longer time to obtain m blocks in the i-th ally consider the inuence of PoS-chain generation to epoch. erefore, the system diculty target should be the PoW-chain. increased so that the miners can nd new blocks faster As discussed in Section 4.1, in order to generate a valid in the next epoch. is negative feedback mechanism block a miner need to try dierent w to satisfy a hash makes the system stable. inequality, i.e., H(hw,hs,ha,w) < T. It is easy to see that Next, in order to increase readability, we rst discuss if we increase T, the probability to generate a valid PoW- PoS diculty target adjustment. en, we will turn to block of one hash query will increase and vice versa. We the discussions about PoW diculty target adjustment. assume the probability that a PoW-block is successfully mapped to a stakeholder is R < 1. e diculty is ad- m 4.2.2 Our diculty adjustment for PoW/PoS justed every PoW-blocks of the chain-pair. We can take the typical value m = 2016 as in Bitcoin system. We For the same consideration as in Bitcoin, we propose use mi to denote the total number of aempting (and suc- two adaptive diculty target mechanisms for PoW and cessful) PoW-blocks that are generated in the i-th epoch. PoS chains in order to keep the chain-pair growth with If some PoW-blocks are not be successfully mapped to a stable rate. stakeholders, we would have mi > m. Similar to Bitcoin, First, we use T to denote the PoW diculty target in we also use t to denote the expected time span for an general. We also use Ti as the PoW diculty target in epoch, and ti do denote the actual time span for the i-th
7 epoch. Before our analysis, we will dene some notations. Let Ti be the diculty target in the i-th epoch. e We assume all of the computing power can make n hash diculty target in the (i + 1)-th epoch is dened by queries to generate PoW-blocks in an epoch. e ratio of honest computing power is ρ and the ratio of mali- mti cious computing power is 1 ρ. We also assume the Ti+1 = Ti − mitR total amount of coins is nˆ and the honest ratio is ρˆ the malicious ratio is 1 ρˆ. For simplicity we only discuss e diculty adjustment for PoW is based on two “fac- the average case. − tors”, ti and mi. e logic is as follows: Lemma 4.1. Suppose the malicious players stop to con- If ti < t, we know that the i-th epoch is shorter than tribute the block generation to increase the diculty target. expected. In this case, we need to increase Ti+1 to In the i-th epoch, the system reaches stable target regime. decrease the PoW diculty in the (i + 1)-th epoch. Let t be the actual time span of the i-th epoch. Suppose t i Similarly, if ti > , we need to reduce Ti+1 to increase in the (i + 1)-th epoch, the malicious players try to extend the PoW diculty. chains with all of resources. Let Let ti+1 be the actual time If m > m/R, we know that the probability that PoW- i span of the (i + 1)-th epoch. We have ti+1 = tiρρˆ. block can be mapped to a stakeholder is lower than ˆ ˆ the expectation R. In this case, the PoS diculty Proof. For the i-th epoch is stable, we have Ti = Ti+1. We (see PoS diculty adjustment) would be decreased get m = m . e PoW-blocks generation ratio is m 1 . For i R R ti and we need to increase PoW diculty (by reducing the malicious will begin to generate PoW in the (i +1)-th Ti+1 ) to keep the balance between PoS and PoW. epoch, the PoW-blocks generation ratio will increase to m 1 1 Similarly, if mi < m/R, the PoS diculty would be . R ti ρ increased, then we need to decrease PoW diculty Suppose there are mi+1 PoW-blocks are generated (by increasing T ). i+1 in the (i + 1)-th epoch with the time ti+1. We have m = m ti+1 1 . By the denition of epoch, m PoW- i+1 R ti ρ i+1 4.2.3 Security analysis blocks are mapped to m PoS-blocks by honest and mali- cious stakeholders together. For the current PoS diculty In this section we provide an informal security analysis target is adjusted for honest stake only in i-th epoch, the to demonstrate that the malicious players are not able to ratio that a PoW-block is mapped to a stakeholder is R 1 . aack the ρˆ 1 TwinsCoin system by taking advantage of the diculty We have m = mi+1R ρˆ . Puing them together, we have adjustment mechanism. ti+1 = tiρρˆ. In [14], the authors give a formal security proof for 2-hop blockchain (without considering diculty adjust- From the Lemma 4.1, the ratio that the malicious play- ers can increase is bounded by the factor 1 . ment). ere, they assume that the probability that a ρρˆ PoW block is generated in a round is very low. A poten- tial aack is that the malicious players can increase the 4.3 PoS blockchain in the non-at model diculty target to make it is easier to generate a PoW 4.3.1 Moving PoS blockchain from the at to the block. In the remaining of this section, we will prove this non-at model aack does not work for our modied 2-hop blockchain, under certain assumption. We note that a formal security e (modied) 2-hop blockchain in section 4.1 is de- proof for our modied 2-hop blockchain with diculty scribed in the at model with a pre-xed diculty pa- adjustment in the cryptographic seing is challenging rameter. at is, a stakeholder is qualied to sign and and we leave it for further work. generate a new PoS-block for a PoW block B when his e intuition is that in order to increase the diculty verication key vk satises the inequality eH(B,vk) < eT. target, the malicious players can stop to contribute new Intuitively, if stakeholders have dierent amounts of PoW-blocks and PoS-blocks from some moment. is stake (coins), they would have dierent probabilities to will make the block extension rate lower. With our dif- be elected. us we improve the construction to be suit- culty adjustment algorithm, the diculty target will able for non-at model that means the stakeholder can increase to speed up the block generation. At some later keep dierent amount of stake in an account. Next, we point, the malicious players will begin to work and sign prove that our construction is fair in the non-at model under the current diculty target. All the players can so a stakeholder will not get any advantages if he splits generate more blocks with the current diculty target. his stake to multiple accounts.
8 We describe the non-at model with hash inequality If the stakeholder puts his v coins in v accounts and rst. For a stakeholder, vk is his verication key (public every account has one coin, for any PoW-block B, key), and sk is the corresponding signing key. To extend the probability that an account is selected to sign the PoS-chain, the stakeholder will choose the best chain- corresponding PoS-block is p. e outputs of hash pair with the most “successful” mining power. Let , e function eH(B,vk) are independent for dierent vk. hC Ci be the best chain-pair, and is PoW-chain, eis PoS-chain. e total probability that the stakeholder is selected If the last PoW-block B onC chain is aC new block in is also vp. which there is no corresponding PoS-blockC on PoS-chain, at is, the probability a stakeholder is selected in the then the stakeholder will aempt to generate a new PoS- non-at model is equal to the accumulated probability block as the following: Let eT denote the current diculty that he distributes the stake to dierent accounts in the target for the PoS-block generation. We assume the total at-model. For a stakeholder, the probability that he amount of stake in the whole system is nˆ, we also assume is selected only depends on the total amount of stake the length of the output of hash function eH( ) is κ. Let (coins) he controls. eT · p = 2κ , we assume npˆ < 1. Let v be the number of coins in the account of a stakeholder with vk. If the inequality 4.4 Blockchain design in TwinsCoin eH(B,vk) < veT In this subsection, we summarize our blockchain design in TwinsCoin. Starting with the 2-hop blockchain (Sec- is satised, the stakeholder with the key-pair (sk,vk) tion 3.2), we rst propose a slightly modied version wins a chance to sign the corresponding PoS-block for (Section 4.1) by changing the structure of the proof-of- PoW-block B. As far as we know this is the rst concrete work chain as well as the format of proof-of-work blocks. non-at treatment for PoS-chain. en we improve this modied 2-hop blockchain fur- ther, (i) by enabling diculty adjustment for both PoW 4.3.2 Security analysis and PoS chains (see Section 4.2), and (ii) by introducing an alternative method to choose stakeholders to extend We provide here a security analysis for the non-at model. the PoS chain in the non-at seing where players may e players may take more than 1 coin in an account have dierent amounts of coins. By combining these under non-at model. We will argue that if a stakeholder improvements, we complete the blockchain design in puts more than 1 coin in his account, this will not change our TwinsCoin system. Please refer to Figure4 for the the probability for PoS-block mapping. Intuitively, from roadmap of blockchain design. In next subsection, we our non-at construction, if a stakeholder puts more will return to the client design in our TwinsCoin. coins in an account, he has a higher probability to be selected; therefore, he does not need to split his coins Sec 3.2 into multiple accounts. eT Lemma 4.2. Let p = 2κ and κ is the length of hash Sec4.1 4.1 output. Let nˆ be the total number of coins. We assume npˆ < 1. For any stakeholder with account (sk,vk), we as- Sec4.2 4.2 Sec 4.3Sig F sume there are v coins in this account, where v < nˆ. We have Pr[eH(B,vk) < veT] = vp. TwinsCoinSec 4.1
Proof. From the denition we have veT = vp2κ. For npˆ < 1 and v < nˆ, we have veT < 2κ. Since eH(B,vk) produces Figure 4: Roadmap for blockchain design in TwinsCoin. the output uniformly in (0,2κ), we have Pr[eH(B,vk) < veT] = vp.
From the Lemma 4.2, we have the probability that a 4.5 Light client design in TwinsCoin stakeholder is selected to generate a PoS-block is propor- Checking the validity of a proof-of-work block requires tional to the amount of stake he controls. a constant-time operation (i.e., two SHA256 invocations); If the stakeholder puts his v coins in one account, for thus for a blockchain with n blocks, the time to check the any PoW block B, the probability that he is selected validity is linear (O(n)). In contrast, in all the proof-of- to sign the corresponding PoS block is vp. stake protocols checking a balance of a block generator
9 is needed in order to verify the validity of blockchain. 5.1 Implementation Currently, holding the whole balance sheet is needed for the verication. However, this creates lots of diculty We implement TwinsCoin using the Scorex frame- for light clients. Verication time (if a balance sheet is work [25] in Scala language. Our implementation is indexed by a public key) for a block is about O(logS), full-edged. erefore, it is possible to run the testing where S is a size of the balance sheet. Once balance network without any code modications. Our implemen- sheet becomes too big to be stored in random-access tation is opensourced [1] and published under public memory, performance could be degraded signicantly. In domain CC0 license. Bitcoin, once block size limit is reached, size of a balance ere are a few open source modular blockchain de- sheet (more precisely, unspent outputs set) is growing velopment tools available, such as Scorex [25], Sawtooth roughly linearly with time (a corresponding graph could Lake [26], and Fabric [24]. We choose to use Scorex be found at [9]), thus verication time for n PoS blocks 2.0 [25] because this is the only existing tool which sup- is O(n logn). e concerns of heavy validation could ports two (or more) types of blocks. be the solid· arguments against switching from a Proof- e idea of a modular design for a cryptocurrency was of-Work chain to the hybrid one. rst proposed by Goodman in Tezos whitepaper [21]. e whitepaper (Section 2 of it) proposes to break a cryptocur- As a solution, we propose to authenticate the balance rency design into three protocols: network, transaction sheet as 2-party dynamic authenticated (public key → and consensus. In many cases, however, these layers are balance) dictionary. In the paper [45] an authenticated tightly coupled and it is hard to describe them separately. data structure of this kind is proposed to be used in order For example, in a proof-of-stake cryptocurrency a bal- to avoid holding all the state for the full nodes. We are ance sheet structure, which is heavily inuenced by a applying the principle further in order to make light transaction structure, is used in a consensus protocol. To clients feasible in a Proof-of-Stake environment. split the layers clearly, Scorex 2.0 has ner granularity. A root value aer processing the transactions in a In particular, in order to support hybrid blockchains as block is to be included in a blockheader of a PoS-block. well as more complicated structures than a chain (such Also, a stakeholder generating a block is including an as SPECTRE [48]), Scorex 2.0 does not even have a no- authenticating path for his output against a root of a pre- tion of the blockchain as a core abstraction. Instead, it vious PoS-block. However, verication time for a block provides an abstract interface to a history which contains remains the O(logS), with O(n logn) for a chain, but persistent modiers. e history is a part of a node view, a constant factor would be much· smaller. We back the which is a quadruple of history, minimal state, vault, h claim with an experiment provided in Section 5.2.2. It memory pool . e minimal state is a data structure and i is not needed to hold the whole state in order to check a corresponding interface providing an ability to check whether a PoS-block was generated in a valid way, as by a validity of an arbitrary transaction for the current mo- using a 2-party authenticated dynamic dictionary it be- ment of time with the same result for all the nodes in the comes possible to check proofs and get a new root value network having the same history. e minimal state is to without holding the whole dataset. As a drawback, block be obtained deterministically from an inital pre-historical size would be increased by O(logS) bytes, we provide state and the history. e vault is the node-specic infor- concrete numbers in Section 5.2.2. mation, for example, a node user’s wallet. e memory pool holds unconrmed transactions being propagated across the networks by nodes before got into blocks. e whole node view quadruple is to be changed atom- 5 TwinsCoin System ically by applying whether a persistent node view modi- er or an unconrmed transaction. Scorex provides guar- antees of atomicity and consistency for the application We provide a full-edged implementation of TwinsCoin. while a coin developer needs to provide implementations Details on the implementation are provided in Section 5.1. for the abstract parts of the quadruple as well as a family We run several experiments on particular aspects of our of persistent modiers. Our implementation is introduc- design in order to empirically evaluate the claims made ing two kinds of persistent modiers, PoW-Blocks and throughout the paper and also study some aspects of PoS-Blocks. proof-of-stake diculty readjustment function in Sec- Our implementation has simpler transactions than Bit- tion 5.2. We also run fully functional TwinsCoin nodes coin [55]: while a TwinsCoin transaction has multiple over a testing network which is described in Section 5.3. inputs and outputs, like in Bitcoin, an output contains
10 only a public key of a spender and a value (so no sup- Our implementation is compact, just about 2,300 lines port for Bitcoin Script [53] or another authentication of code, thanks to the frameworks used and concise Scala language is provided). To spend an output, one needs to language. sign its bytes in a referring input. In order to prevent re- play aacks, we also associate an output with an unique 5.2 Experiments nonce value, which is a result of hash(all the transaction bytes without nonces output index in the transaction). In this section, we investigate some aspects of the Like in Bitcoin referencek implementation, the minimal TwinsCoin proposal with the help of targeted experi- state in the TwinsCoin is the current unspent outputs ments. First experiment is about a competition of two set (UTXO [7] set). In both the systems, with the UTXO chains, an honest and an adversarial, similar to described set it is possible to decide whether an arbitrary transac- in the original Nakamoto paper ( [40], Section 11). e tion valid against it or not. By processing a block, a node goal of a second experiment is to measure eciency of is removing outputs spent in the block from the set and the light client proposal from the Section 4.5. ird exper- put there newly created unspent outputs. iment examines proof-of-stake diculty readjustment We also have implemented block generation function- procedure in a simulated environment. ality directly inside the node soware. Iteration over nonce space in Proof-of-Work mining component is arti- 5.2.1 Chain race experiment cially limited in order to reduce the load of an evaluation In the original Bitcoin paper [40], Nakamoto evaluated environment and model non-at mining networks easily. his proposal by considering competition of two chains, us, a number of hash function calls per second is to one of an adversary and another of an honest miner be set explicitly in code. As in Bitcoin, a proof-of-work showing that the adversarial chain cannot overtake the function is about to nd a hash value with a certain prop- honest one until it is backed by majority of mining power. erty of a block header with a nonce eld included. We As there are two resources providing a possibility to gen- use Blake2b hash function with 256 bits output to have erate a block in our proposal, we simulate an adversary 128-bit security level. In our implementation miners start possessing dierent amounts of total hashing power and to work on a next aempting block right aer previous also total stake. one seen and before corresponding PoS-block arrives. In our experiment, an adversarial and an honest par- us the mining component working all the time except ties work on separate TwinsCoin instances generating PoS-block processing phases. chain-pairs of length 10 (so 10 PoW-blocks and also 10 Rollbacks are possible in a blockchain system if a beer PoS-blocks). A party which generates its chain-pair rst fork found. We store all the blocks ever got from the wins the race. e honest party owns 100 outputs locking network (Bitcoin does the same), so an implementation of the same amount of money while the adversary has only the history interface is just switching a pointer to a new some fraction of that. Diculties are static during the best chain in case of a fork. For the minimal state (the experiment, time to generate a PoW-block on average is UTXO set) as well as for the wallet we need to restore overwhelmingly big in comparison with time needed to an old version of possibly big dataset before applying process a block, and proof-of-stake diculty is set to have blocks from a new best chain aer a common one. To about 1 output chosen on average for the honest party. simplify previous database snapshot restoring, we are e code could be found in the le PrivateChain.scala. using a versioned key-value database engine IODB [33]. e result is presented in Figure5. We run every IODB has been built to be used in blockchain systems, experiment 20 times and consider that the adversary so it provides batch updates only and a rollback to an succeeds if he wins at least once. Gray area in the gure arbitrary snapshot in the past within depth to be set shows adversarial success. during database creation. e results show that even with 70% of total mining We are reusing peer-to-peer network from the Scorex power, the adversary also needs for about 20% of total without any changes. Nodes in the network send an- stake to generate a beer chain than the honest party’s. nounces about their blocks and transactions with INV Given Bitcoin capitalization of $20 billion at the moment messages like in Bitcoin [8]. A new block is announced of writing, 20% of stake is about $4 billion. However, not with the same mechanism; thus, propagation time for all the stake is online so security projected into money miners is worse than in Bitcoin network where miners would be about lower level. It is hard to dene precisely have direct low-latency links to each other and push a how much stake is online in Bitcoin, and how much header of a new block immediately. it would be in case of PoS rewards being granted for
11 Figure 6: Balance lookup time. Figure 5: Inuence of aacker’s stake to his hashrate. in the Figure7. e proof size for a Bitcoin-like balance sheet size (46M elements) is about 960 bytes and remains that. Also, we have observed only the simplest kind of no more than kilobyte when balance sheet is about 92M aack in this experiment. e adversary can do beer, elements. for example, by exploiting network-level protocol with Eclipse aacks [23]. Nevertheless, a malicious miner needs to spend a lot of money to overtake the honest parties.
5.2.2 Light validation experiment We estimate practically how ecient is the light vali- dation procedure proposed in the Section 4.5. For that, we compare two chain validators. A full validator is operating with full state residing in a persistent key- value database. A light validator is checking lookup proofs from blockheaders. Both validators are perform- ing lookup operations only. For the experiment, we use authenticated AVL+ trees Figure 7: Balance lookup proof size. from [45]. e full validator code is using disk-based database MvStore with 128 MB in-memory LRU cache. e experiment is started with a balance sheet of about 5.2.3 Proof-of-stake diculty experiments 46 million (public key balance) pairs (where a public → key is about 32 bytes, a value is about 8 bytes). We then In the Proof-of-Stake diculty readjustment formula (see try bigger sheets, up to 92 million pairs in size. us Formula1) we use the R parameter to show the proba- the testing dataset starts from a size like Bitcoin UTXO bility that a PoW-block is a successful block. In other set of today [9] and nishes with twice of that size. We words, R indicates the probability that a PoW-block is use a machine with i7 processor, 16 GB RAM and HDD successfully mapped to a stakeholder. Also, 1 R value disk (5400 RPM) for the experiment. shows how many aempting blocks an average− success- Figure6 shows running times for both the validators. ful proof-of-work block has included. However, in a e results show that our light validator is running in distributed environment, real values could be dierent eective constant time negligible to the running time of from the planned ones because of propagation eects. the full validator (the running time of the light validator To know the dierence we made an experiment where is about 20-25 microseconds per operation). proof-of-stake block was sent to proof-of-work miner For the light validator, a proof of a block generator’s not immediately but with a random delay distributed balance is to be included into a block. We obtain proof uniformly from 0 to 5% of target generation time. We sizes for dierent sizes of balance sheet, they are provided measure number of aempting blocks included into a
12 successful blocks. Results provided in the Figure8 show User interface. Scorex generates a user interface (UI) that in this scenario experimental numbers are close to automatically and few requests regarding common func- the planned ones. tionality are available with no any eorts needed. In or- der to add specic functionality, a coin developer needs to specify handlers for the additional requests. e inter- face is available in a web browser. With the help of the UI, a TwinsCoin user is able to see the hybrid blockchain contents, network peers and their statuses, wallet public keys and corresponding balances. It is also possible to create a transaction (to send tokens) via the user inter- face. Monetary policy and incentives. e currency in the network has no emission, so all the coins are issued in the initial state. Proof-of-Stake block generators are geing transaction fees as rewards while Proof-of-Work miners are geing nothing (as nding a proper incentives Figure 8: Percentage of Aempting Blocks structure is le for further research).
We found that, given a constant stake, target value is changing with number of stakeholders growing. e 6 Future Work dependency is presented in the Figure9. ere are still some issues to resolve before launching a production-ready system. We highlight the most impor- tant ones below. Incentives. How to properly incentivize participants in a cryptocurrency is a non-trivial task. As an example, in April 2016, Lerner reported [35] about uncle mining issue regarding improper rewards for uncle blocks in the GHOST [49] component found in the Ethereum protocol. In TwinsCoin, rewards should be given to stakeholders generating PoS-blocks and also to generators of success- ful as well as aempting PoW-blocks. Finding a proper balance is le for further research. ˜ Figure 9: T Value Switching. Changing rules in a cryptocurrency is a hard topic. ere are two ways, sofork and hardfork, to upgrade the design recognized in the community. A 5.3 Testnet sofork [54] is such a protocol upgrade that only pre- viously valid rules are made invalid. Nodes not being We launch TwinsCoin full-edged implementation over a updated will recognize the new blocks as valid, thus a publicly accessible testing network (so-called “testnet” in sofork is backward-compatible. To activate a sofork a cryptocurrency jargon). For that, we deploy TwinsCoin majority of mining power is required. A hardfork [52] is to tens of machines, including AWS (Amazon) instances such a protocol upgrade that makes previously invalid in the US, Europe, Asia, as well as physical machines rules valid. A hardfork requires all the users to upgrade. in Germany and Russia. Each node in the network is If swapping from a PoW-chain to the hybrid solution is connected to 10 random neighbors. Every machine is not hard-coded since a launch of a coin, upgrade would be participating in proof-of-work blocks mining, few ma- non-trivial and probably requires hardfork, but hardforks chines have public keys with stake on-board so gener- are beer to be avoided in a mature system. We leave ating proof-of-stake blocks also. Target time between identifying suitable switching mechanisms for further proof-of-work blocks is 10 minutes and R = 0.8. research.
13 7 Related Work References
Closely related work. Combining proof-of-work and [1] Twinscoin source code. https://bitbucket. proof-of-stake has been studied in [4,5, 13, 32]. Unfor- org/TwCoin/twinscoin. tunately, no rigorous security analysis has ever been [2] A. Back. Hashcash — A denial of service counter- provided for these proposals. Duong et al [14] provide measure. 2002. http://hashcash.org/ the rst provably secure, proof-of-work and proof-of- papers/hashcash.pdf. stake hybrid blockchain protocol. In addition, Duong et [3] I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurrencies al’s proposal is easy to implement and does not involve without proof of work. In 3rd Workshop on Bitcoin and a trusted entity. Blockchain Research - Financial Cryptography, 2016. [4] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld. Proof of Independent work on secure pure proof-of-stake. activity: Extending Bitcoin’s proof of work via proof of Several recent and concurrent eorts (e.g., [6,31,36]) have stake. Cryptology ePrint Archive, Report 2014/452, 2014. made to construct provably secure, scalable blockchains http://eprint.iacr.org/2014/452. via pure PoS. Unfortunately, these solutions cannot scale [5] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld. Proof to a large number of network nodes (e.g., billion nodes) of activity: Extending bitcoin’s proof of work via proof in an open seing where participants can freely join or of stake [extended abstract]. SIGMETRICS Perform. Eval. leave the system at any time they want. Rev., 42(3):34–37, Dec. 2014. Bitcoin and provable security. Anonymous digital [6] I. Bentov, R. Pass, and E. Shi. Snow white: Provably currency was introduced by Chaum [11]. However, the secure proofs of stake. In Cryptology ePrint Archive, Re- rst decentralized and practical currency system, Bit- port 2016/919, 2016. http://eprint.iacr.org/ coin [40], was developed many years later, using the 2016/919. so-called proofs-of-work puzzles [2,15]. Recently, the se- [7] Bitcoin Developer Guide. UTXO denition. https: curity of Bitcoin system has been analyzed in the rational //bitcoin.org/en/developer-guide# seing, e.g., [16,17,28,41,46,47], and in cryptographic term-utxo. seing [14, 18, 19, 29, 30, 44, 49]. [8] Bitcoin Wiki. Protocol documentation. https: //en.bitcoin.it/wiki/Protocol Cryptocurrencies via alternative physical re- documentation. sources. Alternative consensus techniques via dierent [9] Blockchain.info. Number of Unspent Transaction physical resources (e.g., space/memory) have been inves- Outputs. 2017. https://bitcoin.org/en/ tigated to replace computing power. For instance, the developer-guide#term-utxo. physical storage resource is used in [37,43]. Interestingly, [10] R. Canei. Security and composition of multiparty cryp- hybrid proof system utilizing both computational and tographic protocols. Journal of Cryptology, 13(1):143–202, space resources—proofs of space time—has been intro- 2000. duced in [39]. Intel proposes the use of trusted hardware [11] D. Chaum. Blind signatures for untraceable payments. for blockchain protocols in [27]. In D. Chaum, R. L. Rivest, and A. T. Sherman, editors, Additional cryptocurrencies via virtual resources. CRYPTO’82, pages 199–203. Plenum Press, New York, USA, We review proof-of-stake (PoS) based blockchain. Since 1982. the idea in an online forum [50], several pure PoS [12] CryptocoinsNews. Bitcoin Market Needs Big Blocks, Says schemes that have been proposed and/or implemented in Founder of BTC.TOP Mining Pool. 2017. https://t. real world including [3,34,42,51]. As mentioned above, co/fS5sy7jpPD. in [4,5, 13, 32], the proof of work and proof of stake [13] CryptoManiac. Proof of stake. NovaCoin can be combined together. However, no rigorous secu- wiki, 2014. https://github.com/ rity analysis has ever been provided for these propos- novacoin-project/novacoin/wiki/ als. Fortunately, proof-of-stake related, provably secure Proof-of-stake. blockchains have been developed very recently; please [14] T. Duong, L. Fan, and H.-S. Zhou. 2-hop blockchain: see [6, 31, 36] and [14]. Combining proof-of-work and proof-of-stake securely. In Cryptology ePrint Archive, Report 2016/716, 2016. https: //eprint.iacr.org/2016/716. Acknowledgements [15] C. Dwork and M. Naor. Pricing via processing or com- baing junk mail. In E. F. Brickell, editor, CRYPTO’92, We would like to thank Dmitry Meshkov for helping volume 740 of LNCS, pages 139–147. Springer, Heidelberg, with coding and testing the system. Aug. 1993.
14 [16] I. Eyal. e miner’s dilemma. In 2015 IEEE Symposium [31] A. Kiayias, A. Russell, B. David, and R. Oliynykov. on Security and Privacy, pages 89–103. IEEE Computer Ouroboros: A provably secure proof-of-stake blockchain Society Press, May 2015. protocol. In Cryptology ePrint Archive, Report 2016/889, http://eprint.iacr.org/2016/889 [17] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin 2016. . mining is vulnerable. In N. Christin and R. Safavi-Naini, [32] S. King and S. Nadal. Ppcoin: Peer-to-peer editors, FC 2014, volume 8437 of LNCS, pages 436–454. crypto-currency with proof-of-stake. 2012. Springer, Heidelberg, Mar. 2014. https://peercoin.net/assets/paper/ peercoin-paper.pdf. [18] J. A. Garay, A. Kiayias, and N. Leonardos. e bitcoin back- bone protocol: Analysis and applications. In E. Oswald [33] J. Kotek. IODB storage engine. https://iohk.io/ and M. Fischlin, editors, EUROCRYPT 2015, Part II, volume blog/scorex/iodb-storage-engine/. 9057 of LNCS, pages 281–310. Springer, Heidelberg, Apr. [34] J. Kwon. Tendermint: Consensus without min- 2015. ing. 2014. http://tendermint.com/docs/ [19] J. A. Garay, A. Kiayias, and N. Leonardos. e bitcoin back- tendermint.pdf. bone protocol with chains of variable diculty. In Cryp- [35] S. Lerner. Uncle mining, an ethereum consensus protocol tology ePrint Archive, Report 2016/1048, 2016. https: aw. 2016. https://t.co/YnnkzROp02. //eprint.iacr.org/2016/1048. [36] S. Micali. ALGORAND: the ecient and democratic [20] D. Goodin. Bitcoin security guarantee shaered by anony- ledger. CoRR, abs/1607.01341, 2016. mous miner with 51% network power. 2014. http: [37] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz. Permacoin: //arstechnica.com/. Repurposing bitcoin work for data preservation. In 2014 [21] L. M. Goodman. Tezos: A self-amending crypto-ledger. IEEE Symposium on Security and Privacy, pages 475–490. position paper. IEEE Computer Society Press, May 2014. [22] C. Guo. ”I am Chandler Guo, a 51% aack on [38] A. Miller, A. E. Kosba, J. Katz, and E. Shi. Nonoutsource- Ethereum Classic (ETC) is coming with my 98G hashrate”. able scratch-o puzzles to discourage bitcoin mining coali- 2016. https://twitter.com/chandlerguo/ tions. In I. Ray, N. Li, and C. Kruegel:, editors, ACM CCS status/757191880740184064. 15, pages 680–691. ACM Press, Oct. 2015. [23] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse [39] T. Moran and I. Orlov. Proofs of space-time and ratio- aacks on bitcoin’s peer-to-peer network. In USENIX nal proofs of storage. Cryptology ePrint Archive, Re- Security, pages 129–144, 2015. port 2016/035, 2016. http://eprint.iacr.org/ 2016/035. [24] IBM Corp. Hyperledger-Fabric. 2016. https:// github.com/hyperledger/fabric. [40] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash sys- tem. 2008. https://bitcoin.org/bitcoin. [25] Input Output Hong Kong. e Scorex Project. 2016. pdf. https://github.com/input-output-hk/ Scorex. [41] K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selsh mining and combining [26] Intel. Hyperledger-Sawtooth Lake. 2016. with an eclipse aack. Cryptology ePrint Archive, Re- https://github.com/hyperledger/ port 2015/796, 2015. http://eprint.iacr.org/ sawtooth-core. 2015/796. [27] Intel. Proof of elapsed time (PoET). 2016. [42] NXT Community. Nxt whitepaper. 2014. https: https://intelledger.github.io/ //www.dropbox.com/s/cbuwrorf672c0yy/ introduction.html. NxtWhitepaper v122 rev4.pdf. [28] A. Kiayias, E. Koutsoupias, M. Kyropoulou, and Y. Tselek- [43] S. Park, K. Pietrzak, A. Kwon, J. Alwen, G. Fuchsbauer, and ounis. Blockchain mining games. In Proceedings of the P. Gazi.ˇ Spacemint: A cryptocurrency based on proofs of 2016 ACM Conference on Economics and Computation (EC), space. Cryptology ePrint Archive, Report 2015/528, 2015. pages 365–382, 2016. http://eprint.iacr.org/2015/528. [29] A. Kiayias and G. Panagiotakos. Speed-security trade- [44] R. Pass, L. Seeman, and A. Shelat. Analysis of the os in blockchain protocols. Cryptology ePrint Archive, blockchain protocol in asynchronous networks. Cryp- Report 2015/1019, 2015. http://eprint.iacr. tology ePrint Archive, Report 2016/454, 2016. http: org/2015/1019. //eprint.iacr.org/2016/454. [30] A. Kiayias and G. Panagiotakos. On trees, chains and [45] L. Reyzin, D. Meshkov, A. Chepurnoy, and S. Ivanov. Im- fast transactions in the blockchain. Cryptology ePrint proving authenticated dynamic dictionaries, with appli- Archive, Report 2016/545, 2016. http://eprint. cations to cryptocurrencies. 2016. http://eprint. iacr.org/2016/545. iacr.org/2016/994.
15 [46] A. Sapirstein, Y. Sompolinsky, and A. Zohar. Optimal Denition A.3 (Chain ality Property). e chain selsh mining strategies in bitcoin. In Financial Crypto, quality property cq with parameters µ R and ` N 2016. states that for anyQ honest player P with∈ chain in∈ the C [47] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. execution of the blockchain protocol Π, it holds that for Incentive compatibility of bitcoin mining pool reward large enough ` consecutive blocks of the ratio of honest functions. In Financial Crypto, 2016. blocks is at least µ for µ (0,1). C ∈ [48] Y. Sompolinsky, Y. Lewenberg, and A. Zohar. SPECTRE: A fast and scalable cryptocurrency protocol. In IACR Cryp- tology ePrint Archive, 2016. http://eprint.iacr. B Our modied 2-hop blockchain org/2016/1159. In Section 4.1, we describe the modied version of 2-hop [49] Y. Sompolinsky and A. Zohar. Secure high-rate transac- blockchain. Here, we provide more details. tion processing in bitcoin. In R. Bohme¨ and T. Okamoto, editors, FC 2015, volume 8975 of LNCS, pages 507–527. As in the 2-hop blockchain design [14], we here also Springer, Heidelberg, Jan. 2015. have two tightly coupled blockchains: proof-of-work blockchain (PoW-chain) and proof-of-stake blockchain [50] User antumMechanic. Proof of stake instead of proof of work. 2011. https://bitcointalk.org/ (PoS-chain). A PoW-chain is dened as a sequence index.php?topic=27787.0. of temporally ordered PoW-blocks; however, our PoW-chain is dierent from one in the 2-hop de- [51] P. Vasin. Blackcoin’s proof-of-stake proto- sign as there are two dierent types of PoW-blocks col v2. 2014. http://blackcoin.co/ blackcoin-pos-protocol-v2-whitepaper. in our system: aempting PoW-blocks and successful pdf. PoW-blocks (see Section B.1 for more details). Proof-of- Stake blockchain consists of PoS-blocks and maintained [52] B. Wiki. Hard fork. https://en.bitcoin.it/ wiki/Hardfork. by a set of stakeholders. We summarize the frequently used notations in Table [53] B. Wiki. Script. https://en.bitcoin.it/ 1. wiki/Script. [54] B. Wiki. Sofork. https://en.bitcoin.it/ Table 1: Table of notations wiki/Softfork. [55] B. Wiki. Transaction. https://en.bitcoin.it/ Notation Description wiki/Transaction. κ security parameter. init an initial blockchain. C B, a PoW-block, a PoW-chain. A Security properties for blockchains C B,e e a PoS-block, a PoS-chain C a set of proof-of-work blocks To capture the security of blockchain protocols, several B com- , e a chain-pair consisting of PoW-chain fundamental security properties for them, namely hC Ci C mon prex property [18,44], chain quality property [18] and PoS-chain e. C C and chain growth property [29], have been dened. a set of chain-pairs. X information stored in blockchain. Denition A.1 (Chain Growth Property). e chain Σ digital signature scheme Σ = growth property states that for any honest player P Gen Sign Verify Qcg ( , , ). with the local chain at round r and 0 at round r0 where (sk,vk) a signing and verication key-pair C C κ s = r0 r > 0, in the execution of the blockchain protocol where (sk,vk) Gen(1 ). ← Π. It− holds that len( ) len( ) g s where g is the Broadcast( ) unauthenticated send-to-all functional- 0 · growth rate and len( C) denotes− C the≥ number· of blocks on ity. the chain. C
Denition A.2 (Common Prex Property for We suppose that there exists an initial blockchain init C PoS-chain). e common prex property with pa- as the starting point, and init is known to all participants Qcp C rameter κ N states that for any two honest players P1 in the TwinsCoin system. at round r ∈and P at round r , where r r , with the Now we present the behaviors of miners and 1 2 2 1 ≤ 2 local chains 1, 2, respectively, in the execution of the stakeholders in our system. In general, miners and blockchain protocolC C Π, it holds that [1,` ] and stakeholders collect blockchain information from the C1 1 C2 `1 = len( 1) Θ(κ) where len( ) denotes the number of broadcast channel, perform some validation and generat- blocks onC the− chain. C ing blocks, and then share their states with the network
16 through broadcast. We now explicitly describe the two Algorithm 2: Main Protocol: stakeholder. e procedures for miners and stakeholders as follows. stakeholder algorithm is parameterized by signing and ver- ication keys (sk,vk). Miners. Initially, each miner sets the set of chain-pairs 1 C ; ← C to empty (i.e., ). A miner then continues execution 2 while True do 3 C all chain-pairs received from the network. as follows. First, the player copies all chain-pairs re- ← 4 X all payloads received from the network. ceived from the network into his local state. e miner ← 5 , e BestValid(C) then selects the best chain-pair in his view by calling hC Ci ← BestValid 6 enew PoS(sk,vk,X, , e ) the algorithm (see Algorithm6) over the set C ← hC Ci e 7 if e, enew then of chain-pairs. Upon deriving the best chain-pair , C C hC Ci 8 e e (based on length and validity), the miner calls PoW al- C ← Cnew gorithm (see Algorithm3) to make a bounded number 9 C C , e ← ∪ hC Ci of hash queries in an aempt to nd a proof of work 10 Broadcast( , e ); hC Ci solution and extend the PoW-chain . If it is successful, then his local best chain-pair is extendedC by one block, the PoW-chain in the pair is updated, and then the best B.1 Proof-of-Work Blockchain chain-pair is broadcast to the network. is procedure is formally presented by Algorithm1. B.1.1 Attempting and Successful Blocks
e players listen to and receive many chain-pairs (con- Algorithm 1: Main Protocol: miner. sisting of new PoW-blocks) from the network. For each 1 C ; ← player, if he receives a new PoW-block without its cor- 2 while True do responding PoS-block, the new PoW-block becomes an 3 C all chain-pairs received from the network. ← aempting block with respect to the view of the player. 4 , e BestValid(C) hC Ci ← On the other hand, if he receives a new PoW-block with 5 , PoW( , e ) Cnew ← hC Ci the corresponding PoS-block, this PoW-block is now con- 6 if , then C Cnew sidered as a successful block in the player’s local view. 7 C ← Cnew 8 C C , e ← ∪ hC Ci 9 Broadcast( , e ); B.1.2 Proof-of-Work Block Structure hC Ci Let H( ),G( ) be cryptographic hash functions with out- put in· 0,1·κ where κ is the security parameter. As in- troduced,{ we} have two dierent types of PoW-blocks: Stakeholders. e initialization of every stakeholder aempting blocks and successful blocks. e structure of is the same as miners except that each valid stakeholder aempting and successful blocks are the same. However, is parameterized by a unique pair of signing and veri- they have dierent meaning as follows: (1) no PoS-block cation keys (skj ,vkj ) and amount of coins vj . (In this links to an aempting block, and (2) we only count the appendix, the blockchain protocol is described in the at successful blocks when calculating the real length of a model, and we assume vj = 1.) proof-of-work chain. A PoW-block B is a tuple of the Consider a stakeholder, in each time step, any form ctr,hw,hs,ha,w , where chain-pairs and payload X from the network are copied h i Notation ctr denotes a positive integer, 1 ctr q, into the stakeholder’s local state. e stakeholder then and q is the maximum number of random≤ oracle≤ selects the best chain-pair on his view through the N queries∈ from each player per unit of time, BestValid algorithm (see Algorithm6) over a set of chain-pairs C. en, upon deriving the best chain-pair Notation hw denotes the digest of the previous proof- of-work block, where h 0,1 κ, the stakeholder aempts to extend the PoS-chain of the w ∈ { } best chain-pair through the PoS algorithm (see Algo- Notation hs denotes the digest of the previous proof- κ rithm4). If this stakeholder is the lucky stakeholder, of-stake block, where hs 0,1 , ∈ { } then he will produce and sign a new block and extend Notation ha denotes the digest of the latest seen the PoS-chain, and nally broadcasting the newly ex- aempting proof-of-work block, where h 0,1 κ a ∈ { } tended chain-pair to the network. Notation w is a random nonce, where w 0,1 κ, ∈ { }
17 2 and block B satises the inequality Algorithm 3: e proof-of-work function, parameterized by positive integers q,T and hash functions H( ), G( ). e H(ctr,G(hw,hs,ha,w)) < T · · input is ( , e ). where the parameters T N denotes the current hC Ci ∈ 1 function PoW( , e ) proof-of-work target of the block. hC Ci 2 Let be a set of aempting blocks that aach to A PoW-chain consists of a sequence of ` concatenated headB( ). C C successful PoW-blocks. We denote head( ) as to the 3 Let l be the number of aempting blocks in . C B topmost successful PoW-block B` in blockchain . at is, 4 Set h := if is empty. C a ⊥ B we do not consider an aempting block as the head of 5 hw H(head( )); hs H(head(e)) ← C κ ← C the proof-of-work chain, and the head of a PoW-chain is 6 ctr 1; w 0,1 ← ← { } not necessary the topmost PoW-block since the topmost 7 B ← PoW-block could be an aempting block. Moreover, we 8 if l , 0 then l only link a new proof-of-work block to the head of the 9 Let B be the latest PoW-block found that B proof-of-work chain. is implies that there may ex- aaches to head( ). l C 10 h H(B ); ist multiple aempting blocks aaching to a successful a ← 11 while ctr q do block in our proof-of-work chain. If a proof-of-work ≤ 12 if (H(ctr,G(hw,hs,ha,w)) < T) (ctr q) then blockchain is a prex of another blockchain 0, we ∧ ≤ C C 13 B ctr,hw,hs,ha,w write 0. ← h i C C 14 B C ← C /* Extend proof-of-work chain B.1.3 Extending a Proof-of-Work Blockchain */ 15 ctr ctr + 1 Miners maintain our system by extending the PoW-chain. ← 16 return ; /* Return the updated chain */ Algorithm3 formally describes how to extend a proof- C of-work blockchain in our system. is algorithm is parameterized by hash functions H( ),G( ) as well as two · · positive integers q,T where q is the maximum num- In our system, a digital signature scheme is used ber of random oracle queries of each miner per unit of by stakeholders to create new valid PoS-blocks. Let time, and T determines the “current block target” of the Σ = (Gen,Sign,Verify) be the digital signature scheme. PoW. e algorithm works as follows: given a chain-pair Let eH( ) be a cryptographic hash function with output in , e , the algorithm computes the hash h of the pre- 0,1 κ·where κ is the security parameter. We now intro- hC Ci w vious PoW-block (the head of the PoW-chain), the hash duce{ } the format of a PoS-block. In our system, each valid hs of the head of the PoS-chain, and the hash ha of the PoS-block is coupled with a valid PoW-block. Based on latest aempting block collected. We emphasize that, a given PoW-block B, a valid stakeholder with the veri- the head of the PoW-chain is the “most recent successful cation key vk such that block” on the chain (not an aempting block), and with- out connecting to the head of the current PoS-chain or eH(B,vk) < eT the latest aempting block, the adversary can rewrite any information stored on the chain-pair. e algorithm is allowed to generate the corresponding PoS-block Be. w then samples a random initial string of length κ, then it Here, eT is the current proof-of-stake target. increments ctr and checks if H(ctr,G(h ,h ,h ,w)) < T; w s a e PoS-block Be is dened as a tuple of the form if a suitable (ctr,h ,h ,h ,w) is found then the algorithm w s a B,vk,X,σ . Here, X 0,1 is the payload of the proof- succeeds in solving the PoW and extends blockchain by ∗ of-stakeh blocki Be (also∈ denoted { } as payload(Be)); and σ is one block. We can this new PoW-block is now aachedC to a signature for (B,X), i.e., σ = Sign (B,X) (sk is the the header of ; If no suitable (ctr,h ,h ,h ,w) is found, sk w s a corresponding signing key of vk.) the algorithmC simply returns the chain unaltered. We dene head(e) as the topmost PoS-block of the C B.2 Proof-of-Stake Blockchain proof-of-stake chain e. We note that, in PoS-chain, payload is stored, andC we use payload(e) to denote C We remark that this part is almost the same as that in the information we store in e. If ` is the total num- the 2-hop blockchain [14]. ber of PoS-blocks in the PoS-chainC e, then we have ` C 2 payload(e) = payload(Be ), where is the concate- A more comprehensive version of the inequality, i.e., C ||i=1 i || (H(ctr,G(h ,h ,h ,w)) < T) (ctr q) can be found in [18]. nation notation. w s a ∧ ≤
18 B.2.1 Extending a Proof-of-Stake Blockchain Algorithm 4: e proof-of-stake function, parameterized by a signature scheme Σ = (Gen,Sign,Verify), a parameter In Algorithm4, we describe how the stakeholders extend eT, a hash function eH( ). e input is (sk,vk,X, , e ). PoS-chains. Intuitively, if the stakeholder with verica- · hC Ci tion key vk is the elected one, he can to sign and generate 1 function PoS(sk,vk,X, , e ) hC Ci a new PoS-block. 2 Let is the set of all aempting blocks that aach to headB( ). In more details, Algorithm4 processes as follows. C 3 Let l be the number of aempting blocks in . Upon receiving input (sk,vk,X, , e ), the algorithm B hC Ci 4 Let B be the latest PoW-block in that aaches to aempts to extend the specied PoS-chain e in the head( ). B C C chain-pair , e ; e algorithm then executes the fol- /* If there is one new PoW-block that hC Ci lowing two main steps: attaches to head( ). */ C 5 if l > 0 then Step 1—Leader Election. e algorithm collects all 6 if (eH(B,vk) < eT)) then aempting blocks that link to the head of . We de- 7 σ Signsk(B,X) note the set of these aempting blocks as , andC denote ← 8 Be B,vk,X,σ l as the number of blocks in ; here, l = 0 meansB this set ← h i B 9 e eBe is empty and there are no aempting blocks that follow C ← C /* Extend proof-of-stake chain head( ). en, let B be the latest aempting block in C */ . If is not empty meaning that there exits a block B, 10 return e; /* Return the updated chain */ theB algorithmB checks if the verication key vk is a valid C key (owns the stake) and the inequality eH(B,vk) < eT holds. If yes, the stakeholder with the key pair (sk,vk) is the winning stakeholder. at is, stakeholders are B.3 Validating a Chain-pair H vk elected based on this inequality e(B, ) < eT. By this Chain-Pair validation is the most important process in mechanism, the proof-of-work blockchain is treated as a our design. Before going to explain our validation al- biased random beacon for electing a stakeholder. gorithm. We formally describe the following predicates Step 2—Signature generation. Aer the rst step, the used in the ValidateChainPair algorithm. stakeholder with signing and verication keys (sk,vk) is the winning stakeholder. e algorithm then generates a q,T Predicate ValidPoW (B,B ,B,e , ˆ). is predicate signature σ Signsk(B,X) and forms a new PoS-block H,G 0 B B Be= B,vk,X←,σ . We then say the stakeholder with the is parameterized by two integers q, T, and two hash h i functions H( ),G( ). e goal of this predicate is to check key pair (sk,vk) extends the specied PoS-chain ewith · · the new block Be. C the validity of a successful PoW-block B upon receiving e Figure 10 illustrate the structure of a chain-pair inputs: the successful block B, another successful block aer executing Algorithm4. As shown in the gure, we B0, a PoS-block Be, two sets of aempting PoW-blocks and ˆ. Here, the block B consists of ctr,h ,h ,h ,wB, have B the most recently produced PoW-block, and the B h w s a i new PoS-block links to B by storing B in the block. block B0 consists of ctr0,hw0 ,hs0 ,ha0 ,w0 , the set consists B of l aempting blocksh B1,...,Bl wherei each blockB Bi = i i i i i { } ˆ ctr ,hw,hs,ha,w for 1 i l, and the set consists h i ≤ ≤ ˆ B of lˆ aempting blocks Bˆ1,...,Bˆl where each block Bˆj = j ˆj ˆj ˆj j { ˆ} ctrˆ ,hw,hs,h ,wˆ for 1 j l. Note that, PoW-blocks h b i ≤ ≤ in and ˆ are in temporal-order. e predicate checks theB following.B head( ) B C B is properly solved if
H(ctr,G(hw,hs,ha,w)) < T head(e) Be C B links to the previous PoW-block B0 if hw = H(B0). B links to the previous PoS-block Be if hs = H(Be). Figure 10: Generating new PoS-blocks If lˆ > 0, check whether B links to the latest ˆ aempting block in the second set ˆ if h = H(Bˆl). B a
19 If l > 0, check whether all aempting blocks in in the PoW-chain , the algorithm applies the predicate B q C are properly solved if for 1 i l, ValidPoW ,T and ValidPoSΣ,eT, respectively, to validate ≤ ≤ H,G eH the blocks. If both predicates output 1, the considered H(ctri,G(hi ,hi ,hi ,wi)) < T w s a block-pair (including a PoW-block and its corresponding If l > 0, check whether all aempting blocks Bi = PoS-block) are valid. en, the examining chain-pair is ctri,hi ,hi ,hi ,wi in ˆ are properly linked if valid if all block-pairs are valid. Please refer to Algorithm h w s a i B i i 5 for more details. • B links to the previous PoW-block B0 if hw = H( ). B0 Algorithm 5: e chain-pair validation algorithm, param- i i • B links to the previous PoS-block Be if hs = eterized by a signature scheme Σ = (Gen,Sign,Verify), the H(Be). stake-identity set S, parameters q, T, eT, an initial chain i init, the hash functions eH( ), H( ),G( ) and the content • B links to the previous aempting block in the C · · · i i 1 validation predicate V ( ). e input is ( , e ). set if ha = H(B − ) (Note that, we consider · hC Ci 0 B B = B0.) 1 function ValidateChainPair( , e ) hC Ci q,T 2 b V (payload(e)) e predicate ValidPoWH,G outputs 1 if and only the ← C 3 if b = True then examined block B passes all tests described above. 4 repeat 5 B H(head( )). Σ,eT ← C Predicate ValidPoS (B,Be ). is predicate is param- 6 Let is the set of all aempting PoW-blocks eH aachingB to head( ). eterized by a signature scheme Σ, an integer eT, and a C 7 Be H(head(e)). hash function eH( ). e goal of this predicate is to check ← C 8 Truncate all PoW-blocks from the head of the validity of a PoS-block· Be= B ,vk,X,σ upon receiv- C h 0 i (including the head), and truncate the head ing inputs: a PoS-block Be, a PoW-block B. of e. C e predicate checks the following /* obtain new heads */ Be is generated by an elected stakeholder if 9 Let ˆ is the set of all aempting PoW-blocks eH(B,vk) < eT aachingB to the newhead( ). C 10 b Be links to the corresponding PoW-block B if B = B0 1 ← q,T e signature σ of Be is properly generated if ValidPoW (B,head( ),head(e), , ˆ) H,G C C B B Verifyvk(B0,X,σ) = 1 Σ,eT 11 b2 ValidPoS (B,Be ) Σ,eT ← eH e predicate ValidPoW outputs 1 if and only if the 12 b = b b eH 1 ∧ 2 examined PoS-block Be passes all tests described above. 13 until ( = init) (b = False); C C ∨ Our chain-pair validation algorithm, denoted 14 return b ValidateChainPair, is introduced to examine if a pair of chains (including a PoW-chain and a PoS-chain ) is valid. Intuitively, a valid chain-pair means its members PoW-chain and PoS-chain e are both valid, respec- B.4 Best Chain-pair Strategy C C tively. Furthermore, each block of the PoS-chain must In this section, we describe the rules in which a single contain the valid supporting signature for the corre- chain-pair is selected for consensus. We introduce an sponding block of the PoW-chain. e algorithm is pa- algorithm BestValid for selecting the best chain-pair on Σ rameterized by the signature scheme , parameters q, a set of chain-pair C. Please refer to Algorithm6 for e H H G T, T, the hash functions e( ), ( ), ( ), and the content more details. validation predicate V ( ). Note· that,· the· predicate V ( ), Algorithm 6: e BestValid, parameterized by the introduced in [18], determines· the proper structure of· Max( , ) function. e input is (C) the information (i.e., payload) that is stored into the · · PoS-chains. 1 function BestValid(C) 2 temp e ValidateChainPair algorithm takes as input a ← 3 foreach , e C do chain-pair ( , e). It rst applies the validation predicate hC Ci ∈ C C 4 if ValidateChainPair( , e) then V ( ) to check the payload in the PoS-chain e. If the pay- C C · C 5 temp Max( , e ,temp) load is valid, then starting from the head of , for every ← hC Ci successful PoW-block and its correspondingC PoS-block 6 return (temp)
20 e BestValid algorithm is executed by miners and stakeholders. It is by the function Max( , ) (see Algo- rithm7) which outputs the chain-pair having· · the most number of successful PoW-blocks. at is, function Max( , ) only counts the successful PoW-blocks on the proof-of-work· · chain. Algorithm 7: e Max function. e input is ( , e , , e ) hC1 C1i hC2 C2i 1 function Max( , e , , e ) hC1 C1i hC2 C2i 2 Let `i denote the number of successful PoW-blocks in , for i 1,2 . Ci ∈ { } 3 Let is the set of all aempting PoW-blocks Bi aaching to head( ), for i 1,2 . Ci ∈ { } 4 Let l be the number of aempting blocks in . i Bi 5 for i 1,2 do ∈ { } 6 if li , 0 then 7 ` ` + 1 i ← i 8 if ` ` then 1 ≥ 2 9 return , e hC1 C1i 10 else 11 return , e hC2 C2i Tie breaking. In our system, we break the tie deter- ministically. In more detail, if the two chain-pairs have the same number of successful PoW-blocks, then the one having the most number of aempting blocks would win. If they even have the same number of aempting blocks, we would hash the head of the proof-of-work chain in each chain-pair, and choose the one with the smaller hash value. To increase the readability, we demonstrate a toy ex- ample to illustrate our typical best chain-pair policy in Figure 11. In the gure, we have two chain-pairs. We present a successful PoW-block as a lled green box, an aempting PoW-block as an unlled green box, and a PoS-block as a lled red box. ere, the rst chain-pair only has 4 successful blocks where the second chain-pair has 5 successful blocks. By Algorithm6, the second chain-pair is the best one.
(1) ...
(2) ...
time
Figure 11: A toy example for illustrating the best chain-pair policy.
21