SURFACE: A Practical Blockchain Consensus Algorithm for Real-World Networks
SSURFACE: A Practical Blockchain Consensus Algorithm forReal-World Networks
Zhijie Ren and Ziheng ZhouVeChain zhijie.ren, [email protected]
August 17, 2020 A BSTRACT
SURFACE, standing for S ecure, U se-case adaptive, and R elatively F ork-free A pproach of C hain E xtension, is a consensus algorithm that is designed for real-world networks and enjoys the benefitsfrom both the Nakamoto consensus and Byzantine Fault Tolerance (BFT) consensus. In SURFACE,a committee is randomly selected every round to validate and endorse the proposed new block. Thesize of the committee can be adjusted according to the underlying network to make the blockchainmostly fork-free with a reasonable overhead in communication. Consequently, the blockchain cannormally achieve fast probabilistic confirmation with high throughput and low latency. SURFACEalso provides a BFT mechanism to guarantee ledger consistency in case of an extreme networksituation such as large network partition or being under a massive DDoS attack. K eywords Blockchain · Consensus · Byzantine Fault Tolerance · Bitcoin · VeChain
Blockchain, originated from Bitcoin [35], has received great attention recently since it can be used to create a trustedledger/system amongst multiple untrusted parties without a central authority or an authorized third party. One of themostly discussed and vastly studied problems in blockchain is improving the throughput and latency, or in particular,the Bitcoin POW scheme, which is called the scalability problem [9]. Briefly speaking, the traditional Bitcoin POW issub-optimal due to various reasons, one of which is the dependency between the Bitcoin POW’s consensus and thesynchrony of the network [9, 11]. More precisely, forks would be created due to the asynchrony of the network, whichwaste bandwidth to be transmitted, reduce the security, and thus reduces the throughput and increases the confirmationtime, i.e., the latency. One way to mitigate this problem is to transform the chain structure to a Directed Acyclic Graph(DAG) so that all branches of blocks could be counted in the consensus. As a result, the mining power as well as thetransactions on the forks are all taken into account and thus the throughput and the security would not be degraded[44, 43, 30, 3]. Another approach is to prevent forks, i.e., using Byzantine Fault Tolerant (BFT) algorithms to reachconsensus for each block [37, 25, 20].In this paper, we introduce SURFACE, which is the abbreviation of S ecure, U se-case adaptive, and R elatively F ork-free A pproach of C hain E xtension. The name suggests some of the major features of SURFACE, one of which is “relativelyfolk-free”. In SURFACE, we focus on practical networks in real-world and propose a blockchain consensus algorithmthat is “mostly” fork-free by introducing a committee to validate the proposed block. At the meantime, the validationprocess of the committee is much simpler than running BFT algorithms in the whole network, thus it causes lowerlatency and communication overhead. As a result, the bandwidth will not be wasted due to transmitting forks that areeventually discarded and the latency will not be increased comparing to the schemes without committee. Moreover, theperformance is adaptive as we could adjust the committee size according to the network condition to achieve the bestthroughput/latency performance for specific use cases. In addition to the committee based block validation scheme, aBFT scheme is also included in SURFACE to achieve finality, i.e., uncompromised consistency (security), even underthe strict asynchronous assumption. 1 a r X i v : . [ c s . D C ] A ug PREPRINT - A
UGUST
17, 2020
Whether forks are allowed in the blockchain is in fact depending on the types of consensus algorithms, i.e., whetherit achieves Nakamoto consensus [19, 51] or BFT consensus [29, 6]. Bitcoin and Ethereum [47], as well as manyblockchains following their paths [46, 36, 24] achieve Nakamoto consensus. The achieved consistency is probabilistic,i.e., the probability that a block is immutable is not definitive but increases exponentially as more blocks appending toit. Some other blockchains use BFT algorithms to achieve deterministic consistency [20, 31, 23, 32], that is, blocks canbe proven to be definitively immutable once they reach consensus.Blockchain consensus algorithms could also be categorized into permissioned and permissionless by whether somepermission from a trusted source is required for a node to participate in the consensus process. For example, Bitcoin’sPOW is a permissionless consensus scheme as participants only need to solve a hash function based Proof-of-Work(PoW) puzzle to participate in the consensus process without needing permissions from any party. On the otherhand, EOS [12], using the Delegated-Proof-of-Stake (DPoS) as its consensus scheme, is permissioned. In DPoS, allstakeholders vote for a certain number of “super nodes” to participate in the consensus. However, eventually, the electedsuper nodes are permissioned by the trusted authority who initiated the vote.
In this paper, we focus on the consensus algorithm for permissioned blockchain that functions in large real-worldnetworks, some of the favorable choices are BFT algorithms and Proof-of-Authority (PoA) based consensus schemes.Alternatively, we could modify permissionless consensus algorithms to our scenario.BFT algorithms are originated from [29] and has already been developed for decades [6, 4, 8] before the blockchain era.However, these algorithms are either too theoretical to be used in practice or not designed for scenarios of blockchainsand have poor scalability in large networks. Some novel BFT algorithms designed for blockchains like Byzcoin [25],Tendermint [28], Algorand [20], and HotStuff BFT [49] reduce the message complexity of classical BFT algorithms.However, the block interval has to be set in such a way that the consensus could be reached via multiple rounds ofcommunication, or at least the messages from the super majority (more than 2/3 of the population) could be received,which brings a relatively high latency than PoA.PoA is a type of permissioned Nakamoto consensus schemes, which is used in several blockchains including VeChainand Parity. In general, PoA schemes enjoy the advantage of a simpler mechanism and lower latency as the block intervalonly needs to be sufficient for the block to be broadcast. However, it also has many drawbacks. First, probabilisticconsensus is sometimes not sufficient for practical uses, in particular, for high sensitive data or law related affairs.These is also known as the “finality” problem, which has been addressed in Casper [7], Polkadots [48], and some others.However, as all these algorithms are ongoing works that are independent from our research, we will not address themhere but compare SURFACE to them in Section 6.Second, as most PoA schemes are roughly a natural extension of PoW in the permissioned setting, they also suffer fromthe above mentioned scalability problem. This problem has already been addressed by enormous number of workswith various approaches [45, 15, 24, 43], most of which consider permissionless settings but could be modified to beapplied in permissioned blockchains. Directed Acyclic Graph (DAG) based approaches [43, 30] have a rather highcomplexity, in particular, while dealing with problems of block ordering and transaction repetition. Then, “non-DAG”Nakamoto consensus based approaches [15, 50, 24, 5] have their dependencies on synchrony and the performances ofthese algorithms are thus more situational. More precisely, in BFT based blockchain consensus algorithms, the blocksize and intervals have to be adjusted such that the block could be broadcast and the response from the super majoritycould be received in each round. However, in these Nakamoto consensus algorithms, the block size and intervals onlyneed to be suffice for the block to be broadcast. Hence, the throughput would be higher when the message delays aresmall and most nodes behave honestly. However, it is not safe to only consider the best scenario as otherwise maliciousnodes could easily attack the blockchain by creating forks. Hence, redundancy has to be introduced in the throughputand latency to cope with the non-ideal situations, which leads to a sub-optimal performance.
SURFACE focuses on the practicality of the consensus algorithms in real-world networks and enjoys the benefitfrom both worlds of Nakamoto consensus and BFT consensus. More precisely, SURFACE achieves fast probabilisticconfirmation with high throughput and low latency that are comparable to the state-of-the-art algorithms with Nakamotoconsensus like [50, 24]. At the meantime, SURFACE could achieve deterministic consistency (finality) as BFTalgorithms like PBFT and HotStuff BFT [8, 49], and the consistency will not be compromised even if the network isasynchronous. In particular, our contributions are the following.2
PREPRINT - A
UGUST
17, 2020 • We use a committee endorsing mechanism for each proposed block, where the size of the committee isadjustable to the network condition in such a way that the probability of forks is minimum in the “normal”situation of the practical network. – Comparing to other Nakamoto consensus algorithms without committee [15, 24, 5], we minimize theprobability of fork and thus achieve a higher and more stable performance in terms of throughput andlatency with minimum overhead in communication. – Comparing to BFT based algorithms, in case that the network is large, it does not take multiple rounds ofmessages responding from the super majority to reach consensus. Instead, a block could be probabilisti-cally confirmed by a certain number of successive leaders and committees. At the meantime, the blockinterval could be set shorter as only a fraction of nodes need to respond. Hence, for transactions that donot require definitive consistency, SURFACE allows faster confirmation in large network. • We use a BFT based consensus algorithm to achieve deterministic consistency (finality) in asynchronousnetworks. – Most Nakamoto consensus algorithms use synchronous assumptions and could not achieve consistency ifthe network is asynchronous, e.g., the security is not guaranteed in extreme situations. In that perspective,SURFACE achieves higher security. – We use an approach that is inspired by HotStuff BFT and prove that the consistency is achieved withoutany synchronous argument. As a result, instead of guaranteeing both liveness and consistency withsome synchronous assumptions [28, 7], we guarantee uncompromised consistency but not liveness inasynchronous network. We will argue that this is practical in real-world applications in Section 2. • We further incorporate with several novel ideas and mechanisms like block decomposition and delayedvalidation to further improve the performance of the consensus algorithm in practical networks.
In Section 2, we explain practical asynchronous networks with their network and security assumptions that will beused throughout this paper. A detailed explanation of SURFACE will be given in Section 3 with a high level overviewfollowed by all the functions used in SURFACE. Then, in Section 4, we explain some of the novel ideas and mechanismsused in the design of SURFACE and compare them to previous works. In Section 5, we give numerical analysis on thesecurity of probabilitic confirmation and theoretical proofs for the consistency and liveness of SURFACE. Then, inSection 6, we compare SURFACE to some closely related and recent works. At last, we conclude our paper in Section 7.
Bitcoin was described and considered as a secure value-transfer system that functions in asynchronous network as longas the majority (more than 50%) of the hashing power is rational. However, this description has already been challengedand proven wrong in many aspects. In [16], selfish mining is introduced, which could attack Bitcoin with merely 25%of the hashing power. In [9, 11], it is stated that Bitcoin is only secure if the network of Bitcoin is synchronous. Then,in [17], a collection of literature pointing out vulnerabilities in Bitcoin is listed [2, 14] etc., which leads to a conclusionthat “rationality” is not a potent argument for honesty. In other words, evidences show that it is very hard to designincentive mechanism such that the rational players would only perform a certain behaviors. Hence, rational playersshould be considered as Byzantine players who would behave arbitrarily.On the other hand, despite of all vulnerabilities and synchronous limitations, Bitcoin is still considered as secure andsuitable for asynchronous network in the “common belief” as it functions well in real-world for years. Hence, in thispaper, we take both the theoretical asynchoronous network model and the practical network in real life into account.We consider two scenarios: firstly, in a “normal” situation, we assume that the network is synchronous, the nodes aresemi-trusted as their behavior is restricted by rational arguments, and the messages are propagated via gossip protocol.We argue that this is a reasonable assumption as most blockchain systems, including Bitcoin, function in this kindof networks in the practice. Then, we consider an “abnormal” situation that either the network is partitioned due toaccident or attack, or the adversaries are trying to create inconsistency. In the “abnormal” situation, we use the strictasynchronous BFT assumption, i.e., the message delay as well as the behavior of the malicious nodes are arbitrary.We assume that the network could arbitrarily switch in between these two situations. However, we assume that theabnormal situation is “temporary”, i.e., after each abnormal period of arbitrary length, there will always be a longnormal period in which the transactions could be confirmed.3
PREPRINT - A
UGUST
17, 2020Then, we aim for different goals in different scenarios. In “normal” situation, we aim for high throughput, fastconfirmation, and probabilistic consistency which is secure in the same fashion as Bitcoin. Then, to cope with theabnormal situation, we aim for uncompromised security such that the security of the blockchain is guaranteed withoutany synchronous argument. However, we do not guarantee liveness in abnormal situations.The reason of choosing this model over traditional BFT network model or Nakamoto consensus model is purely practical.First, it is reasonable to assume that the “normal” situation is dominant as by our observation, most blockchains areworking in the normal situations and rarely experienced abnormal situations, particularly, for permissioned blockchainsin which the nodes are authorized to participate in the first place. At the meantime, it is crucial that the blockchaincould guarantee its consistency without using any argument of synchrony or rationality, otherwise it is vulnerable tovarious types of attacks.Here, we further specify our practical asynchronous network model.
We consider a network with n nodes, denoted by node i ∈ { , , . . . , n } . The number of adversaries is f that satisfying f + 1 ≤ n . We assume that nodes have limited computation capacity such that they could not break the cryptographicprimitives used in this paper. The hash function is modelled as a random oracle. In the normal situation, the message delay is upper bounded by a known ∆ . Moreover, messages are propagated to thenetwork via gossip protocol, i.e., adversaries cannot secretly split the network by sending different messages to differentnodes, as these messages will eventually be gossiped to all nodes. W.l.o.g., we assume that in synchronous situations, ifa message is received by an honest node at time t , then it will be received by all honest nodes before t + ∆ .Moreover, in normal situation, we assume there is an incentive or punishment mechanism so that adversaries arereluctant to perform attacks on liveness, i.e., they will respond and propose blocks normally. In abnormal situation, the network is asynchronous but not hostile. By not hostile we mean that the duration of messagedelay follows some random distribution which is independent of the message content. In particular, as we use a VRFbased committee selection scheme, the role of a committee member is not revealed until they send their proofs. Hence,a non-hostile asynchronous network will not “coincidently” delay all messages from nodes with a certain roles, as if thenetwork could break the VRF or know the private keys of the nodes in advance.The malicious nodes are Byzantine nodes, i.e., they could perform arbitrary behaviors, including not responding orbehaving honestly. We also allow them to manipulate the network, e.g., arbitrarily delay the message. Package losses,i.e., the losses of messages send by honest nodes, are not considered in this paper.
The network could change between these two situations arbitrarily and the duration of any situation is arbitrary.However, it is guaranteed that abnormal situation is temporary, i.e., after each period of abnormal situation, there will bea relatively “long” period of normal situation, i.e., the period is sufficiently long for some transactions to be confirmed.Then, we assume that when the situation is back to normal, all blocks that are transmitted by honest nodes during theabnormal situation will be received by all honest nodes.
Our network assumption is a strictly stronger assumption than asynchronous assumption and partial synchronousassumption, as we make extra assumptions of the “normal situation” and the “asynchronous but not hostile” network.Hence, BFT algorithms that works in asynchronous networks [34] and partial synchronous networks [8, 49] could alsobe applied in our network.Then, it is strictly weaker than the synchronous assumption, as there could be asynchronous periods. Hence, BFTalgorithms, as well as most NC algorithms, that function under synchronous assumption, fail in this network.4
PREPRINT - A
UGUST
17, 2020
In practical asynchronous networks, we propose a novel framework of blockchain consensus algorithms which containstwo components: • The first component guarantees that in normal situation, the consensus algorithm should be able to achieveNC, which suggests that: – Probabilistic consistency (safety) : If an honest node confirms a block B at height h , then the probabilitythat another honest node confirms a block B (cid:48) (cid:54) = B at height h is smaller than (cid:15) . – Liveness : New transactions can be confirmed. • The second component guarantees that in abnormal situation, the consensus algorithm should be able toachieve definitive consistency (safety) , i.e., if an honest node finalizes a block B at height h , then therecannot be another honest node finalizes a block B (cid:48) (cid:54) = B at height h . In SURFACE, we merge several schemes and concepts from existing blockchain and BFT algorithms. At the meantime,we make many improvements by proposing some additional mechanisms. In this section, we first give a high leveloverview on SURFACE. Then, we explain SURFACE in detail by firstly giving two core functions: a main function thatis executed at the beginning of each round and a block receiving function that is used every time a new correct block isreceived. Then, we explain all the functions and variables used in these functions, without giving much explanation oftheir purposes, which we will do in Section 4.
SURFACE works in practical asynchronous networks, in which we define round according to Global StabilizationTime (GST) with a predetermined time interval. Further, we define epoch as a relatively long duration consisting manyrounds. In this paper, the hash function is modeled by a random oracle.Then, for each round, we randomly select a leader to create a block and a committee for validation. The leader isselected by a hash function and a random beacon determined by some randomness created and acknowledged by theend of the previous epoch by all nodes. The committee members of a round are determined by each node comparing arandom number generated by a Verifiable Random Function (VRF) [33] to a given threshold. As a result, the leader of around is known by all nodes by the end of the previous epoch, and the committee members of a round are only revealedwhen they announce their roles by revealing their proofs.Each leader needs to first broadcast the new block and collect the endorsements from d committee members to generatea valid block. There remains a possibility of forks, although the chance is much lower than the algorithms withoutcommittee and it can only be caused by an adversarial leader colluding with an adversarial committee. In case of forks,nodes will determine the valid chain by the classical “longest chain rule”. The above-mentioned algorithm is designedto have fast confirmation and high throughput in the normal situation.The abnormal mode of our algorithm is a BFT consensus algorithm that guarantees consistency in asynchronousnetwork and liveness if the network regains synchrony. We introduce a “finality vector” that is included in each block.It is a collection of new view messages, prepare messages, pre-commit messages, and commit messages that are sent bythe leader and committee together. Then, we use a chain selection and finality rule inspired by HotStuff BFT [49] toreach BFT, which is alternatively called “finality” in this paper, for the blockchain. At round r , a node u calls the main function MainFunction ( u, r, mode ( r − , F ( u, r − .A node u will always keep track of an unpublished valid transaction set T X ( u ) . At the start of each round, it detectsits mode mode ( u, r ) of this round and determines the set of blocks that he will consider to determine the canonicalchain C ( u, r ) , namely the candidate blocks B ( u, r ) , according to the mode of this round. Then, he will update his ownfinality vector F ( u, r ) according to his finality vector of the previous round as well as the finality vectors (actually thepruned finality vectors, which will be explained later) collected in the canonical chain C ( u, r ) .Then, at the beginning of each round, each node determines his role by RoleDetermine ( u, r ) . If u is the leader ofthis round, he makes a block summary s ( B ( u, r )) according to C ( u, r ) and T X ( B ( u, r )) ⊆ T X ( u ) . He broadcasts5 PREPRINT - A
UGUST
17, 2020
Algorithm 1
Main Function
MainFunction ( u, r, mode ( r − , F ( u, r − C ( u, r − is the finalized chain till the last round T X ( u ) ← the set for all unpublished valid transactions known to umode ( u, r ) ← SwitchMode ( u, r, mode ( r − B ( u, r ) ← CandidateBlocks ( B hon ( u, r ) , B val ( u, r ) , mode ( u, r )) C ( u, r ) ← CanonicalChain ( B ( u, r ) , F ( u, r − F ( u, r ) ← Finality ( B ( u, r ) , C ( u, r ) , F ( u, r − role ( u, r ) ← RoleDetermine ( u, r, C ( u, r )) if role ( u, r ) == (cid:48) leader (cid:48) then T X ( B ( u, r )) ← an ordered set of new transactions packed by u to be published in this round ( s ( B ( u, r )) , Sig u ( s ( B ( u, r )))) ← BlockSummary ( C ( u, r ) , T X ( B ( u, r ))) Broadcast s ( B ( u, r )) , Sig u ( s ( B ( u, r ))) and T X ( B ( u, r )) Receive for d endorsements E v ( Sig u ( s ( B ( u, r )))) , role ( v ) = (cid:48) committee (cid:48) and combine it into a ˆ E ( B ( u, r )) Broadcast ˆ E ( B ( u, r )) , Sig u ( ˆ E ( B ( u, r ))) else if role ( u, r ) == (cid:48) committee (cid:48) then Receive s (cid:48) and sig (cid:48) valbs ( s (cid:48) ) ← ValBlockSum ( s (cid:48) , sig (cid:48) , C ( u, r )) if valbs ( s (cid:48) ) == (cid:48) valid (cid:48) then E u ( s (cid:48) ) ← Endorsement ( s (cid:48) , u ) Send s (cid:48) , sig (cid:48) , End u ( s (cid:48) ) to the leaderReceive T X the block summary s ( B ( u, r )) , a corresponding signature Sig u ( B ( u, r )) , along with T X ( B ( u, r )) and waits for theendorsements from the committee members of this round. Once d endorsements have been received, he combines theseendorsements into a collected endorsements ˆ E ( B ( u, r )) and broadcasts it with Sig u ( ˆ E ( B ( u, r ))) .Then, if u is a committee member of this round, he waits for the block summary s (cid:48) and a signature sig (cid:48) . He validatesthe block summary and endorses for it by signing it if it is valid. Then, he sends his endorsement E u ( s (cid:48) , sig (cid:48) ) alongsidewith s (cid:48) , sig (cid:48) and at the meantime receives T X ( B ( u, r )) . In SURFACE, the blocks are not as straightforward as they are in Bitcoin since a block is decomposed into multipleparts that are not sent together as an actual “block”, but separately. The matching parts are combined into a block by thereceiver. Then, the receivers will validate these blocks and for each round, they will select a chain according to the canonical chain rule.However, not all blocks are directly considered as candidate blocks for the canonical chain. Nodes will also use theirlocal knowledge to judge whether the block is suspicious , i.e., sent by adversaries to intentionally cause inconsistency.When the node is in the normal mode, inconsistent blocks sent by the same leader or blocks received outside of theirrounds are all suspicious and will not be considered as candidate blocks. However, when the node is in abnormal mode,these blocks will be also considered. Hence, nodes will keep two sets of blocks, which are called valid blocks and honest blocks , respectively. Then, they will select the candidate blocks from these two sets accordingly to the mode.
A block B ( u, r ) consists of three parts: A set of transactions T X ( B ( u, r )) , a signed block summary s ( B ( u, r )) , Sig u ( s ( B ( u, r ))) , and a signed collected endorsement ˆ E ( B ( u, r )) , Sig u ( ˆ E ( B ( u, r ))) . Transaction set
T X ( B ( u, r )) Each node will maintain a set of valid and unpublished transactions
T X ( u ) accordingto the canonical chain that they observed. Then, if he is in turn as a leader, he will make a transaction set to publish inthis turn T X ( B ( u, r )) ⊆ T X ( u ) . Block summary
A block summary is composed by the following items in the exact order.1. A hash of the block summary and the collected endorsement of the previous block, i.e., H ( s ( B ( u, r )) | ˆ E ( B ( u, r ))) , where B ( u, r ) is the last block of the canonical chain C ( u, r ) .2. The current epoch and the round number. 6 PREPRINT - A
UGUST
17, 20203. A Merkle root of
T X ( B ( u, r )) .4. A pruned finality vector F p ( u, r ) (Subsection 3.6). Collected endorsement
Once d endorsements are collected, they are ordered according to the ascending order of thepublic keys of committee members and concatenated into the collected endorsement ˆ E ( B ( u, r )) . We consider a block B as “valid” if it is self-contained, i.e., it is consistent with itself and all previous blocks on itschain C . Hence, we define the correctness of a block as the following • The leader, round number, epoch number, and the finality vector are consistent with what can be computedfrom C . • The block summary and the collected endorsement are correctly signed by the leader. • The Merkle root in the block summary is consistent with the transaction set. • The transactions in the transaction set are all valid with regards to the chain that it is on. • There are d endorsements in the collected endorsements from the committee members of round r . • All previous blocks on C are also valid.Throughput this paper, if we refer to a “block”, then it is a valid block. In other words, we do not take a block thatis not self-contained into account when we consider the blockchain, even if it has a valid block summary, or enoughendorsements from the committee, or valid transaction sets, etc. We denote all blocks that are received by node u tillround r by B val ( u, r ) . Nodes that are participating in the consensus will also mind the honesty of the block, i.e., whether they are sent byhonest nodes. In normal situation, a block will be received by all honest nodes in that round. Hence, a block issuspicious if • there are different blocks or block summaries generated by the same leader of that round; • it is received outside of their round.We define the blocks that are not suspicious as honest blocks, i.e., the honest blocks are • received in the corresponding rounds; • with no received blocks or block summaries that are from the same leader of the same round but are different.We denote all honest blocks that are received by node u till round r by B hon ( u, r ) . Note that honest blocks only makesense in “normal situations”. We will specify how nodes determine their current mode in Subsection 3.9. At the start of each round, node u runs the function CandidateBlocks ( u, r ) to determine the blocks to be consideredfor the canonical chain of this round. In normal mode, a node will only consider honest blocks for their chain selectionand could confirm transaction using probabilistic metrics. In abnormal mode, a node will consider all blocks for theirchain selection and be aware of the confirmed transactions might not be final. Algorithm 2
Determine the candidate blocks
CandidateBlocks ( B hon ( u, r ) , B val ( u, r ) , mode ( u, r )) r (cid:48) ← the last round that mode ( u, r (cid:48) ) (cid:54) = (cid:48) normal (cid:48) if mode ( u, r ) = (cid:48) normal (cid:48) then B ( u, r ) ← { B : B ∈ ( B hon ( u, r ) \B hon ( u, r (cid:48) + 1)) ∪ B val ( u, r (cid:48) ) ∧ B ∼ fn ( u, r − else B ( u, r ) ← { B : B ∈ B val ( u, r ) , B ∼ fn ( u, r − return B ( u, r ) Here, B ∼ B is defined as B is not conflict with any block in B , and fn ( u, r − is the block that is considered as finalby node u in round r − , which we will explain later. 7 PREPRINT - A
UGUST
17, 2020
We use the following rules to determine the canonical chain:1. C includes fn ( u, r ) , which is the newest finalized block considered by u at round r .2. For two chains C , C ∈ B ( u, r ) satisfying the first rule, select the longer chain.3. If the length of the chain is tied, select the chain with a newer block.4. If there are still multiple chains left, select the one that is received first.The function CanonicalChain ( B ( u, r )) is an implementation of these chain selection rules. A finality vector F ( u, r ) is a vector including five values, each value is a hash pointer to a block. Then, if F ( u, r ) =[ H ( B ) , H ( B ) , H ( B ) , H ( B ) , H ( B )] we define nv ( u, r ) = B , pp ( u, r ) = B , pc ( u, r ) = B , cm ( u, r ) = B , and fn ( u, r ) = B , representing the blocks that are seen as the provisioned view, being prepared, being pre-committed, being committed, and finalized by node u in round r , respectively. A pruned finality vector F p ( u, r ) excludes the last value of F ( u, r ) . Then, we denote such a pruned finality vector included in block B by F ( B ) =[ H ( nv ( B )) , H ( pp ( B )) , H ( pc ( B )) , H ( cm ( B ))] . In the context of HotStuff BFT [49], F ( B ) can be seen as the newview requests including a proposal of block nv ( B ) , prepare messages for block pp ( B ) , pre-commit messages forblock pc ( B ) , and commit messages for block cm ( B ) sent by the leader and all signed committee members in block B .Further, we use the notation B (cid:22) B (cid:48) if block B is in an earlier round than or the same round as B (cid:48) and B (cid:23) B (cid:48) if block B is in a later round than or the same round as B (cid:48) .We use the notation u (cid:96) pc ( u, r ) = B to represent that u sends a pcmessage for B at round r . Note that this is a sufficient but not necessary condition for pc ( u, r ) = B .We define a counter N tp ( v, b, C ) to count the number of messages of one of the four above-mentioned types. It countsthe number of distinct leaders and committee members that produce blocks { B : B ∈ C ∧ nv ( B ) = v ∧ tp ( B ) = b } where tp = { nv , pp , pc , cm } standing for “new view”, “prepare”, “pre-commit” and “commit”, respectively. Similarly,we also define N tp ( b, C ) with the same definition with N tp ( v, b, C ) except that it ignores the new view check nv ( B ) = v .If a block B has N nv ( B, C ) , C ∈ B ( u, r ) , we call B a view , and we use the notation V | B [ conditions of B ] for a block B that satisfies N nv ( B, C ) ≥ f + 1 , C ∈ B ( u, r ) as well as the given conditions and −−→ V | B [ conditions of B ] for thelatest such view.Given the locally observed canonical chain, node u uses Algorithm 3 to determine the finality vector F ( u, r ) thatrecords the node’s BFT consensus status. The vector is initialized as F ( u,
0) = [ H ( b ) , H ( b ) , H ( b ) , H ( b ) , H ( b )] where b is an unique identifier standing for “null” and b the genesis block.Let C be the canonical chain of round r , here, we describe the rules that node u uses in round r in Algorithm 3 inwords: • Commit rules: u commits a block B if he has received f + 1 pc messages of B in one view.2. u commits a block B if he receives f + 1 cm messages for B . • Pre-commit rules:
There exists a block that is “ready to pre-commit”:1. There exists a view B (cid:48) ∈ C (cid:48) ⊆ B such that N pp ( B (cid:48) , B, C (cid:48) ) ≥ f + 1 and N pc ( B (cid:48) , B (cid:48) , C (cid:48) ) = 0 for all B (cid:48) ⊥ B ;2. For all C (cid:48)(cid:48) ⊆ B and V | B (cid:48)(cid:48) [ B (cid:48)(cid:48) (cid:31) B (cid:48) , B (cid:48)(cid:48) ∈ C (cid:48)(cid:48) ] , it holds that N pc ( B (cid:48)(cid:48) , B, C (cid:48)(cid:48) ) > .Then, let us denote the latest pre-committed block of u by B (cid:48) , i.e., B (cid:48) = pc ( u, max pc ( u,r (cid:48) ) (cid:54) = b ( r (cid:48) )) . We denotethe latest view that u sends a pc message for B (cid:48) by B (cid:48) , i.e., B (cid:48) = nv ( u, r ) where r = max u (cid:96) pc ( u,r (cid:48) )= B (cid:48) ( r (cid:48) ) .Now, u pre-commits B in one of the two cases:1. B (cid:48) ∼ B or B (cid:48) does not exist or B (cid:48) does not exists;2. B (cid:48) ⊥ B , but there exists a view V | B (cid:48) [ B (cid:48) (cid:31) B (cid:48) , B (cid:48) ∈ C (cid:48) , N pc ( B (cid:48) , B (cid:48) , C (cid:48) ) = 0] . • Unlock the pre-committing block:
If pc ( u, r ) = B , he set pc ( u, r ) = b if B is no longer “ready topre-commit” according to the current B ( u, r ) . • Prepare rules: u prepares B if u receives f + 1 nv messages of B with no pc message for a conflictingblock B (cid:48) ⊥ B on the canonical chain. 8 PREPRINT - A
UGUST
17, 2020
Algorithm 3
Updating the finality vector F ( u, r ) based on B ( u, r ) , C ( u, r ) Let B be the last block on C ( u, r ) . type ( u, r ) ← type ( u, r − where type = { nv , pp , pc , cm , fn } . We denote C = C ( u, r ) , B = B ( u, r ) , andtype ( u ) = type ( u, r ) to simplify the presentation below. ( u ) . if N pc (cid:0) nv ( B ) , pc ( B ) , C (cid:1) ≥ f + 1 then cm ( u ) ← pc ( B ) , pc ( u ) ← b else if N cm (cid:0) cm ( B ) , B ( u, r ) (cid:1) ≥ f + 1 , cm ( B ) (cid:31) cm ( u ) then cm ( u ) ← cm ( B ) if fn ( u ) ≺ cm ( u ) then fn ( u ) ← cm ( u ) ( u ) . if ∃ B : (cid:16) ∃ B (cid:48) ∈ C (cid:48) ⊆ B : N pp ( B (cid:48) , B, C (cid:48) ) ≥ f + 1 ∧ N pc ( B (cid:48) , B (cid:48) , C (cid:48) ) = 0 , ∀ B (cid:48) ⊥ B ) ∧ ( ∀ C (cid:48)(cid:48) ⊆ B , V | B (cid:48)(cid:48) [ B (cid:48)(cid:48) (cid:31) B (cid:48) , B (cid:48)(cid:48) ∈ C (cid:48)(cid:48) ] : N pc ( B (cid:48)(cid:48) , B, C (cid:48)(cid:48) ) > then B RTPC ← B ˆ B ← pc ( u, max pc ( u,r (cid:48) ) (cid:54) = b ( r (cid:48) )) if ∃ r (cid:48) : u (cid:96) pc ( u, r (cid:48) ) = ˆ B then ˆ B ← nv ( u, max u (cid:96) pc ( u,r (cid:48) )= ˆ B ( r (cid:48) )) if B RTPC exists ∧ ( ˆ B ∼ B RTPC ∨ ˆ B = b ∨ ˆ B does not exist ) then pc ( u ) ← B RTPC else if B RTPC exists ∧∃ V | B (cid:48) [ B (cid:48) (cid:31) ˆ B , B (cid:48) ∈ C (cid:48) , N pc ( B (cid:48) , ˆ B, C (cid:48) ) = 0] then pc ( u ) ← B RTPC ( u ) . if B RTPC exists ∧ pc ( u ) (cid:54) = B RTPC then pc ( u ) ← b ( u ) . if (cid:16) N nv ( nv ( B ) , C ) ≥ f + 1 (cid:17) ∧ (cid:16) N pc ( nv ( B ) , B (cid:48) , C ) = 0 for ∀ B (cid:48) ∈ B ∧ B (cid:48) ⊥ nv ( B ) (cid:17) then pp ( u ) ← nv ( B ) , pc ( u ) ← b ( u ) . if nv ( B ) (cid:31) nv ( u ) then nv ( u ) ← nv ( B ) else if (cid:16) nv ( B ) ⊥ nv ( u ) (cid:17) ∨ (cid:16) nv ( u ) = b (cid:17) then nv ( u ) ← B if N nv ( nv ( B ) , C ) ≥ f + 1 then nv ( u ) ← B if pp ( u ) ⊥ nv ( u ) then pp ( u ) ← b return H ( nv ( u )) , H ( pp ( u )) , H ( pc ( u )) , H ( cm ( u )) , H ( fn ( u )) PREPRINT - A
UGUST
17, 2020 • New view rules:
1. giving a previous block B , if nv ( u, r − ≺ nv ( B ) , then nv ( u, r ) ← nv ( B ) .2. giving a previous block B , if nv ( u, r − (cid:23) nv ( B ) and nv ( u, r − ⊥ nv ( B ) , then nv ( u, r ) ← B .3. set block B as the provisioned new view if f + 1 consistent nv message has been received. – Unlock the preparing block (line 32) if the block that it prepares conflicts the provisioned new viewblock. The leader and the committee members are selected by using a hash function and a VRF, respectively, on the randombeacon of the epoch and the round number.
A random beacon of epoch e , denoted by b e , is determined in the epoch e − . We find the ˆ E contained in the lastfinalized block before round r e − − τ − τ , where r e is the last round of epoch e , τ is a parameter set according tothe estimated maximum latency of block propagation, and τ is an estimated maximum latency of finality. We thencompute b e by b e = H ( ˆ E ) . We then use the
RoleDetermine function to determine the roles of nodes in round r , which determines the leader ofeach round by a hash function and determines the committee by comparing a random number generated by a VRFfunction to a predetermined threshold (cid:15) , which is set such that the expected number of committee members is c .Here, we use the ECDSA-based VRF scheme proposed in [21], where the VRF could be abstracted as the following.Node u could use his private key sk u to compute a random number β u with an arbitrary input α by: β u = f VRF ( α, sk u ) (1)Then, node u could provide a proof: π u = Π VRF ( α, sk u ) . (2)Any node could use the public key of u , denoted by pk u and Π u to verify that β u is collision free defined similarly to acryptographic hash function, pseudorandom in the sense that it is indistinguishable from a random number createdby another node, and unique in the sense that each α corresponds to a unique β u . Moreover, the ECDSA-based VRFscheme proposed in [21], we also have β u = H ( π u ) . (3)Further, we define a mapping function M ( x ) = u that will map an arbitrary input x to a node u with uniform probability.Now we introduce function RoleDetermine ( u, r, C ( u, r )) . Algorithm 4
Role Determination
RoleDetermine ( u, r, C ( u, r )) e ← the current epoch by rb e ← the random beacon of this epoch with C ( u, r ) if u == M ( b e | r ) then role ( r ) ← (cid:48) leader (cid:48) if H ( f VRF ( b e | r, sk u )) ≤ (cid:15) then role ( u ) ← (cid:48) committee (cid:48) return role ( u ) If node u is a committee member in round r , in the time interval of [∆ , in round r , he will wait for the block summaryas well as the transaction set sent by the leader of the round. Then, he calls the ValBlockSum ( s (cid:48) , sig (cid:48) , T X , C ( u, r )) tovalidate the block summary. If the result is (cid:48) valid (cid:48) , it endorses this block summary and broadcasts its endorsement.The expected number of the committee members of each round is c and the leader waits for the endorsements from d < c committee members, combines them, and sign them as shown in Algorithm 1. Here, c and d are set accordinglyto the probability of misbehavior in the normal situation such that with high probability, a block could be proposed ineach round. 10 PREPRINT - A
UGUST
17, 2020
The block summary is validated with
ValBlockSum ( s (cid:48) , Sig (cid:48) , T X , C ( u, r )) . Algorithm 5
Validate Block Summary
ValBlockSum ( s (cid:48) , Sig (cid:48) , T X , C ( u, r )) s (cid:48) is a summary in the form of H ( h ( B (cid:48) )) | r (cid:48) | M R ( T X ) (cid:48) | F (cid:48) ; B ← the last block on C ( u, r ) ; if B (cid:48) == B ∧ r (cid:48) == r ∧ F ( u, r ) == F (cid:48) ∧ Sig (cid:48) is s (cid:48) signed with the correct key of the leader of round r thenreturn (cid:48) valid (cid:48) If the result of the validation of the block summary is (cid:48) valid (cid:48) , node u endorses it by broadcast E u ( s (cid:48) ) = Endorsement ( s (cid:48) , u ) . Algorithm 6
Endorsement algorithm
Endorsement ( s (cid:48) , u ) π u ← Π u ( b e | r, sk u ) return ( π u , Sig u ( s (cid:48) )) Here, π u should be broadcast with the endorsement so that the role of u can be verified. In SCEM, the main function has two modes, normal mode and abnormal mode, to deal with normal and abnormalsituations in the network, respectively. In the normal situation, honest nodes will not consider dishonest blocks, exceptfor the dishonest block they received before this period of the normal situation. In the abnormal situation, all blockswill be considered. Moreover, honest node will not confirm any blocks in abnormal mode.In fact, honest nodes are encouraged to use any on-chain and off-chain information to determine their modes as longas it has a low false negative probability for abnormal situations, i.e., if an honest node confirms a block, then theprobability that the node is actually in abnormal situation should be smaller than a given (cid:15) . In fact, if honest nodes arerational, they would naturally stop confirming transactions if they suspect the network is abnormal. Here, we propose apractical mode switching mechanism based on randomly pinging other nodes. Algorithm 7
Determine the mode according to the network
Mode ( u, r ) pinging node with H ( π u | v ) mod n ≤ c , where v is the id of the node. if more than c ( n − f ) n nodes response in time then cnx ( r ) = normal if cnx ( r − k + 1) , cnx ( r − k + 2) , . . . , cnx ( r ) = normal then mode = normal else mode = abnormal return mode In this section, we explain the reason behind the designs introduced in Section 3 with context. We decompose thealgorithm into several mechanisms and compare them to their counterparts in existing works, and clarify the similaritiesand differences, as well as our reason of choice.
With the practical asynchronous network assumption, we use a round based leader selection mechanism which has beenwidely used in existing works, in particular, proof-of-stake (POS) algorithms like [5, 24, 20, 23]. These algorithms aredifferent in three aspects: 11
PREPRINT - A
UGUST
17, 2020 • Sole leader vs. Committee : The single leader approach is a straightforward extension of Bitcoin. It isfollowed by POW based algorithms like [15] as well as POS based algorithms like [5, 24, 10]. Thesealgorithms achieve Nakamote-like consensus that require several rounds to probabilistically confirm with nofinality. In POW based algorithms like [37, 25] and POS based algorithms like [20, 23], a random selectedcommittee is used to achieve immediate finality with negligible fault probability. However, it introduces ahigher message complexity due to the communication in the committee. Moreover, the fault tolerance ratio(the ratio of allowed adversaries in the total population) should be calculated carefully in order to guaranteethat less than 1/3 of the committee are adversarial. • The choice of random function : Hash function is one of the most straightforward choice as a random oracle,which is used by [5, 24]. However, it suffers the disadvantage of predictability, which can be exploit by theadversaries. Then, VRF is used by [20, 10] so that the role of a node is not known until himself revealingit with a proof. However, the number of leader or committee members is not definitive. In [23], the BLSthreshold signature is used for it is both deterministic and unpredictable. • Random beacon : A random beacon is required to generate a pseudo-random number, which must havereached consensus and could not be manipulated by the adversaries. An epoch based random beacon is usedby most algorithms, where an epoch is a period that is sufficiently long for nodes to reach consensus on thebeacon. Then, in order to prevent manipulation, [5] uses the concatenation of randomness from many nodesso that adversaries could not manipulate all of them and in [24, 20], the randomnesses are proposed witha commitment scheme to further prevent manipulation. Then, the beacon is used for an epoch so that it isimpossible to successfully bias the selection of the whole period.In SURFACE, we aim at a consensus algorithm that “almost fork-free” under normal situation in practical so that thebandwidth will not be wasted on transmitting blocks that are eventually discarded. Hence, we choose a leader pluscommittee approach, which is similar to [20]. The main difference in here is that in [20] the size of the committeeshould be chosen sufficiently large so that the super majority (more than 2/3 of the population) of the committee arehonest. However, in SURFACE, this is not a hard requirement as we only aim for “almost fork-free” but not absolutefork free. As a result, SURFACE could be seen as a generalization of leader based approach and committee basedapproach. It can achieve fast confirmation or even immediate finality if the committee size is large, and has a lessmessage complexity but longer confirmation time if the committee size is small.Second, for the random function, we use the straightforward hash mapping to select the leader and uses VRF to select thecommittee. The VRF committee selection will limit the capability of adversarial leaders to collude with the committee.Then, the hash mapping will guarantee that each round having exactly one leader, which will not result in empty roundsor inconsistency caused by multiple leaders in one round like in [10]. However, it does result in predictability of theleaders of the next epoch, which gives a chance of corruption attack. In our assumption, we assume the “one-epochahead” predictability is acceptable.Third, we also uses the randomness from many nodes of the previous epoch to determine the random beacon. Inparticular, the random beacon is determined by the randomness created by VRF in the last finalized and received blockin the previous epoch. It is guaranteed to be consistent for all nodes as it is finalized. Then, it could be manipulatedwith a non-negligible probability, which is the main different of SURFACE and [20]. However, we will later show thatwe could still achieve probabilistic consistency even if the adversaries could manipulate the random seed.
In SURFACE, many schemes are used to achieve an optimized throughput in practical use cases, especially in aindustrial oriented consortium blockchain where the nodes are considered trusted in a certain degree.
The idea of “one round, one block” is the most straightforward approach of making a “blockchain”. However, if weconsider reaching consensus on messages rather than “blocks”, then we have alternations like BFT algorithms anddirected acyclic graphs (DAGs).Classical BFT algorithms [6, 4, 8] has O ( n ) message complexity per consensus, where n is the number of nodes in thenetwork. Some more recent BFT algorithms could reduce the message complexity to O ( n ) [27, 25, 22, 34, 49]. Thefinality mechanism of SURFACE is inspired by HotStuff BFT [49], which also organizes the consensus into a chain ofblocks. We will later clarify the similarities and differences between our algorithm and HotStuff BFT.12 PREPRINT - A
UGUST
17, 2020DAG based consensus algorithms allow multiple nodes to propose blocks simultaneously and eventually reach consensuson a graph instead of a chain [40, 44, 43, 30, 42, 3] . However, these algorithms are in general more complicated,especially to order transactions, and there are no clear evidence that they achieve higher throughput, lower latency,and/or have better bandwidth efficiency than the chain based approaches.Another alternation is scale-out consensus algorithms like sharding approaches [26, 1, 41] or off-chain approaches like[39, 38]. However, all these algorithms compromise in security, decentralization, or functionality, which are not suitablefor our case.Hence, we use a one-round one-block approach for our blockchain, which is also in line with many state-of-the-artconsensus algorithms like [24, 20, 18, 23]. In our algorithm, the block is decomposed into multiple parts and the actual block is never broadcast together. Thepurpose of this design is to reduce communication redundancy. In particular, the transactions will only be broadcastonce by the leader, instead of twice, i.e., first sent to the committee for validation, then broadcast with the completeblock to the whole network.There are other works that partially address this problem. In [20, 13], the redundancy of the “the transactions isbroadcast twice, once before the block and once in the block” is mitigated by only sending the hash indices of thetransactions in the block.
In our algorithm, the transaction set included in the block of round r is actually not validated by the committee membersof round r . It is validated by the leader and the committee members of round r + 1 to decide whether to append blocksto it.The reason behind this choice is to reduce the latency and wasted bandwidth caused by the validation of the transactions.If the committee validates the transaction of this round, then, the leader has to wait for the committee to validate thetransactions and response with the endorsements, during which the bandwidth is wasted. The delayed validation designwill allow the leader to fully utilize the bandwidth of a round for block transmission, while the validation could bedone by the committee in the next round, while they are receiving the block of the next round. This is essentiallyoptimistically trading the bandwidth wasted on waiting for the validation results for the possible bandwidth wasted onreceiving invalid blocks, which will improve throughput in general as we assume that the network is mostly in normalsituation and it is almost fork-free.Similar approaches have also appeared in [50, 18], however, in different forms and for different purposes. To achieve finality, we include a finality vector in each block, which could be seen as a collection of new view messages,prepare messages, pre-commit messages, and commit messages in HotStuff BFT [49]. In other words, a finality vector F ( B ) included by a valid block B is a collection of these consensus messages send by the leader and all endorsedcommittee members of block B . Then, as the chain grows, these messages will be collected to proceed a three-phasecommit approach, i.e., B will be proposed in a new view when f + 1 new view messages are received, be preparedwhen f + 1 prepare messages are received, and be pre-committed when f + 1 pre-commit messages are received, asshown in Figure 1. We use a view-change mechanism that is similar to HotStuff BFT, where nodes send pre-commitmessages along with the new view messages, and a new is entered and a new block is only seen as proposed if itreceives f + 1 new view messages without pre-commit messages for a conflicting block, which is an indication of noconflicting block that has been committed. On the other hand, if there exists a conflicting committed block B , there isat least one honest node that will send pre-commit message of B along with the new view message and all nodes willeventually receive the chain of B and pre-commit B . This mechanism guarantees both liveness and consistency.However, although the finality mechanism in SURFACE uses a similar consensus process as HotStuff BFT, it is verydifferent from HotStuff BFT by its nature. Firstly, as SURFACE is a chain based algorithm that uses a BFT basedmechanism to achieve finality, it is crucial that the finality is chain compliant: Definition 1 (Chain compliant finality) . If a block B is finalized by an honest node u , then another honest node v couldalso finalize B even if he has only received the chain C (: B ) . Note that these algorithms are different in many aspects with the only similarity of organizing data in the form of DAG. PREPRINT - A
UGUST
17, 2020Figure 1: Normal procedure of finality in SURFACEFigure 2: Nodes will always provision a newer view on the canonical chain.Chain compliant finality suggests that all consensus messages required to commit a block should be included on thechain that it is committed. As a result, the consensus messages are subjective to their chains, which is not the case fornormal BFT consensus algorithms.The second difference is that honest nodes should follow canonical chain rules to only select and extend the heaviestchain if they have locally observed multiple candidate chains that are not finalized. Hence, honest nodes could vote inmultiple QCs due to forks, which will lead to confusion. To address this problem, we let nodes always change their newview to a newer block as shown in Figure 2 so that honest nodes will not simultaneously vote for multiple QC.In rare situations, a block with a heavier weight, denoted by B (cid:48) , is not the block that is the closest to reach finality,denoted by B . In this case, the consensus process will continue on the chain of B (cid:48) until B is committed, as shown inFigure 3. Then, the chain of B (cid:48) will be discarded and nodes will resend the pre-commit messages of B in the chain of B for the sake of chain compliant finality.In HotStuff BFT, if nodes are locked on different views, they will wait for the leader to send a high QC (the QC in thehighest view), then unlock their current view and change their views according to the high QC. However, in SURFACE,since a message can only be sent if the leader and the committee both agree with it, the liveness will not be guaranteed ifnodes prepare or pre-commit for many different blocks and only unlock their current view when f + 1 new messagesare received. Hence, we let nodes first unlock their current view as soon as they discover another chain preparing anewer block and realize that their views are not the newest, then change to the view with the high QC when f + 1 messages are received. In Figure 4, we show that a node prepared for a block B will unlock if he provisions to aconflicting view. SURFACE could achieve faster confirmation by letting more nodes endorse a block. We prove that a fork could only becreated by an adversarial leader colluding with an adversarial committee in the normal situation. Here, an adversarialcommittee suggests that there are at least d adverserial committee members. As a result, the blocks in SURFACE areconfirmed faster comparing to the scenario that a sole leader is used. A fork is defined as two chains C and C ⊥ C which are returned from CanonicalChain ( B ( u , r ) , F ( u , r − and CanonicalChain ( B ( u , r ) , F ( u , r − , where u and u are two honest nodes. Here, C ⊥ C is defined asthere exists a block set B ⊂ C , B ∩ C = ∅ and a B ⊂ C , B ∩ C = ∅ . We concern about the probability of14 PREPRINT - A
UGUST
17, 2020Figure 3: Node u switches to a chain when he has already prepared and pre-committed a conflicting block. Note thatin here, node u and v will still considers the chain of B (cid:48) is the canonical chain until they commit B . Then, they willdiscard the chain of B (cid:48) and change to B .Figure 4: Node u unlocks its prepared block.15 PREPRINT - A
UGUST
17, 2020existing a fork with depth k , where k is a parameter for confirmation. Clearly, a fork of depth k is able to be exploit toperform a double spending attack. Firstly, we consider the case in which there exists colliding blocks, i.e., there are two blocks that B ∈ B and B ∈ B of the same round.In this case, as the leader and committee are deterministic and fixed for each round given that the random beacons areconsistent, the leader of round r must be adversarial to create B and B . Then, in order to create inconsistency, hesends these two blocks, in particular, the last part of the block, in the very end of round r . However, by our endorsementrule, the committee members will only endorse for a block summary after a period of ∆ in round r + 1 . Then, by thegossip communication model in normal situation, both blocks will be received and be considered as suspicious byhonest nodes and discarded. Hence, a k -depth fork with colliding block must be caused by k consecutive adversarialleaders and committee members in synchronous scenario. There is another scenario in which the fork could be created and extended without colliding blocks. Let consider thefollowing case:At round r + 1 , the adversarial leader l r +1 creates a block B r +1 appending to the block in round r , denoted by B r . Hefollows the normal procedure to broadcast the block summary, collect the endorsements, except for that he “fraudulentlydelays” the broadcast of the collected endorsements. As a result, B r +1 is not actually broadcast, and thus not acquiredby the rest of the network. Then, the adversarial leader of round r + 2 , l r +2 , creates a block appending to B r . It willbe endorsed by the honest committee as B r is the latest block that they observed. However, l r +2 again “fraudulentlydelays” the broadcast of B r +2 . At the meantime, l r +1 broadcasts B r +1 . Then, the adversarial leader of round r + 3 will perform the same strategy to extend the chain of B r +1 . Further, the leader of round r + 4 could also use the samestrategy to extend B r +2 . Note that although the chain of B r +2 has the same length as the chain of B r +1 , however,by our chain selection rule, B r +2 is the latest and should be selected. So on and so forth, adversaries could create a k -depth fork with k adversarial leaders with honest committees.However, this type of forks are addressed by our rules of honest blocks. In normal mode, the blocks which are receivedoutside of its round will be considered as suspicious and will not be taken into account for canonical chain selection. In the abnormal situation, a fork with colliding blocks could be created with less than d malicious committee members.More precisely, since a malicious leader could propose colliding blocks and if the network is partitioned and themessages between committee members are delayed, honest committee members could endorse for a block B while theother honest committee members endorsing for a block B (cid:48) . Then, as the committee size is not fixed, a fork could becreated by a malicious leader colluding with m < d malicious committee members. Additionally, there are d − m ) honest committee members are parted into two groups and all intermediate messages between these two groups aredelayed.However, as committees are selected by VRF and the network is not hostile by assumption, the adversaries could notpredict who are the honest committee members and could only perform this type of attack by dividing the networkbefore sending colliding blocks. This attack will be countered by our mode switching mechanism in which honest nodeswill detect a partition of the network with a same probability of a malicious committee. As a result, the probability offalse confirmation decays at a same rate as the fork rate in the normal situation. As discussed previously, a violation in consistency occurs with a k -depth fork, which requires at least k consecutivemalicious leaders and committees in the normal situation. Then, in asynchronous but not hostile networks, it occurswhen adversaries conduct a network partition attack and successfully created a fork by less than d malicious nodes. Atthe meantime, the mode switching mechanism of two honest nodes in both parts of the network simultaneously failed todetect a network partition for k consecutive rounds.Moreover, we need to consider the possibility of biasness, i.e., if the beacon happens to be created by a malicious leader,then, he could exhaust approximately b = (cid:0) cd (cid:1) times to try to create a scenario of k consecutive adversarial leaders andcommittees. 16 PREPRINT - A
UGUST
17, 2020Biasness s s c = 10 , d = 7 k = 7 , f = 33 . × − . × − c = 8 , d = 5 k = 5 , f = 25 . × − . × − c = 6 , d = 4 k = 4 , f = 20 . × − . × − Table 1: The security parameters given in a network with n = 101 .Then, we have s = (cid:16) BC ( d, f, cn ) fn (cid:17) k (cid:18) cd (cid:19) (4) s = BC ( (cid:100) c ( n − f ) n (cid:101) , c, n + f n ) k (cid:18) cd (cid:19)(cid:104) d (cid:88) d (cid:48) =1 (cid:16) BP ( d (cid:48) , f (cid:48) , cn ) BC ( d − d (cid:48) , (cid:98) n − d (cid:48) (cid:99) , cn ) (cid:17) fn (cid:105) k , (5)where s and s are the probability of k -length fork occurs in normal and abnormal situation, respectively, takeninto account the factor of biasness. Here, the probability density function and the cumulative distribution function ofbinomial distribution of winning (at least) x times in n trials with probability p are denoted by:BP ( x, n, p ) = (cid:18) nx (cid:19) p x (1 − p ) n − x , (6)BC ( x, n, p ) = ∞ (cid:88) x (cid:48) = x (cid:18) nx (cid:48) (cid:19) p x (cid:48) (1 − p ) n − x (cid:48) , (7)respectively. In Table 1, we give the security parameters in various network configurations. Example 1.
We consider a network with 101 nodes, 33 adversaries, and a committee size of 10 with a requirementof 7 endorsements. Then, if an honest node sees a block B appended by 7 blocks and he is in normal mode, he canconfirm by knowing that the probability that there exists another honest node that confirms a conflicting block is smallerthan . × − , regardless of whether the network situation is normal or not. If the block interval is 10 seconds, theconfirmation time is 70 seconds, guaranteeing that an attack on the consistency could only happen approximately onceper 2 years. For comparison, to achieve the same level of security, a classical approach will requires k = 15 . Besides a generalization of the Nakamoto-like consensus, SURFACE is also a generalization of BFT algorithms like[20, 49] with a flexible committee size. As a result, SURFACE could also achieve finality, i.e., the consistency conditionin BFT consensus, in a similar fashion as [49].
Theorem 1 (Finality) . In SURFACE, if an honest node u has cm ( u, r ) = B , then, there could not be another honestnode u (cid:48) that considers a conflicting chain is final, i.e., there cannot be another node u (cid:48) and a round r (cid:48) that hascm ( u (cid:48) , r (cid:48) ) = B (cid:48) and B ⊥ B (cid:48) .Proof. Assume that there exists two honest nodes u and u (cid:48) that have cm ( u, r ) = B and cm ( u (cid:48) , r (cid:48) ) = B (cid:48) , B ⊥ B (cid:48) .By the commit rule, there must exist a chain C that has f + 1 nv messages and f + 1 pp messages. Moreover, weassume there are f + 1 pc messages for B in a view B , i.e., coming along with the nv messages for B . Similarly,there must exist a chain C (cid:48) that has f + 1 pc messages for B (cid:48) in a view B (cid:48) . Hence, there must be a node v that sendsa pc message for B at view B and sends a pc message for B (cid:48) at view B (cid:48) . W.l.o.g. we assume that B (cid:48) (cid:31) B .By the nv rules, v must send pc messages for B before sending pc message to B (cid:48) since he cannot change from view B (cid:48) to a older view B . Then, as he has send a pc message for B , he can only send the pc message for B (cid:48) ⊥ B according tothe second pc rule. Hence, there must exist a chain C (cid:48)(cid:48) (could be the same as C (cid:48) ) that has f + 1 nv messages for ablock B (cid:48)(cid:48) (cid:31) B with no pc message for B . Then, node v observes the view B (cid:48)(cid:48) at round r and afterwards pre-commits B . 17 PREPRINT - A
UGUST
17, 2020Figure 5: Illustration for proving Theorem 1Then, there must be a node v (cid:48) that sends both the pc message for B in the view B and the nv message of B (cid:48)(cid:48) without pcmessage for B . Here, as B (cid:48)(cid:48) (cid:31) B , by the new view rule, v (cid:48) must first send a pc message for B then sends a nv messageat view B (cid:48)(cid:48) without pc message for B , which suggests that he has unlocked B . Then, according to the unlock rule, theremust exist a chain C (cid:48)(cid:48)(cid:48) that has f + 1 nv messages for a block B (cid:48)(cid:48)(cid:48) (cid:31) B with no pc message for B . Moreover, v (cid:48) must have observed this and unlocked B at a round r (cid:48) < r so that v could make the later observation and unlocking.As there are finite rounds between B and B (cid:48) , there must exists a node that sends pc message in the view B butunlocks B without meeting the condition of unlocking pre-committed blocks. Firstly, we prove the following lemma showing that the system could enter a new view in “normal” situations.
Lemma 1.
In the normal situation, new blocks can be proposed in a new view regardless of the finality vectors of thenodes.Proof.
By our assumption, it is straightforward that blocks will be proposed in a new view if the network is always innormal situation. We focus on the scenario that nodes start with different finality vectors, in particular, locked withdifferent prepare and pre-commit blocks. We show that there will eventually be large groups of nodes having consistentfinality vectors if they have the same B ( u, r ) so that the leaders and committees could reach agreement and blockscould be proposed with non-zero probability. Let us assume that honest nodes are pre-committing to a set of blocks B ∗ at round r . Moreover, by our assumption of the normal situation, all node should have a consistent B ( u, r ) andcanonical chain C .By the pre-committing rule, for each block B i ∈ B ∗ , there must exists a block B (cid:48) i such that there exists a chain C i inwhich there are f + 1 nv messages for B (cid:48) i coming along with f + 1 pp messages for B i . Moreover, there are no pcmessages for any B j ⊥ B i coming along with these pp messages. We use the notation B (cid:48) for the set for all B (cid:48) i , B (cid:48) forthe newest block in B (cid:48) , B for the block that receives f + 1 pp messages in the view B (cid:48) , and C for the chain thatincludes B , B (cid:48) , and these f + 1 pp messages.Now, we discuss two cases: first, if there exists a view B (cid:48)(cid:48) (cid:31) B (cid:48) with no pc message for B , then B is not “ready topre-commit” according to B ( u, r ) and will be unlocked by all nodes. Then, the process will continue with all nodespreparing and pre-committing new blocks. Second, if there dose not exist a view B (cid:48)(cid:48) (cid:31) B (cid:48) with no pc message for B ,the B is “ready to pre-commit” according to B ( u, r ) by definition.18 PREPRINT - A
UGUST
17, 2020Then, by the pre-commit rule, all nodes that have send pc messages of B i before the view B (cid:48) will pre-commit B . Onthe other hand, all nodes that have send pc messages of B i after the view B (cid:48) will unlock their pre-committing blocks,but not yet pre-commit B . We denote the group of nodes that have pc ( u, r ) = B by Ω and the group of nodes thathave pc ( u, r ) = b by Θ .Assume that there are m honest nodes in group Ω and and f + 1 − m honest nodes in group Θ . Then, in normalsituation, with a probability of BC ( d, c, m + f ) that a new block will be created by group Ω with a pre-commit messageof B and with a probability of BC ( d, c, n − m ) that a new block will be created by group Θ with no pre-commitmessage. As a result, in the worst case, there is a probability of BC ( d, c, n/ that a block could be created. As thecommittee members of each block are independently and uniformly selected, nv messages of a view B from f + 1 different nodes will be eventually received and all nodes will either unlock B and prepare B or all honest nodes willpre-commit B .With Lemma 1, we have the following theorem. Theorem 2 (Liveness) . In normal network situation, new blocks could be committed.Proof.
By Lemma 1, all node will enter newer views. Then, in the normal situation, all node should be able to havea consistent canonical chain. Hence, by our algorithm, the proposed block would be able to collect f + 1 preparemessages, f + 1 pre-commit messages, and eventually be committed.Note that leaders and colluding committees could try to propose blocks B with a pre-commit message for arbitrary B (cid:48) in a view to delay the process. However, as we always assume that the probability of a colluding leader and committeeis very low (very unlikely to happen during the consensus process) in the normal situation, we guarantee that newblocks will eventually be committed in the normal situation. In general, one of the major difference between SURFACE and all other algorithms are the design of two modes,which distinguishes SURFACE from most blockchain consensus algorithms. The most similar ones are the Nakamotoconsensus algorithms with finality, like Casper [7] and GRANDPA-BABE [48, 18]. Besides, we will also compareSURFACE to BFT algorithms like Algorand, HotStuff BFT, Tendermint, and Nakamoto consensus algorithms likeOuroboros.
Casper [7] is a consensus algorithm that is designed to promote public blockchains like Ethereum with finality.Polkadots [48] uses a consensus scheme called GRANDPA-BABE [18], which uses the finality arguments of Casper ina permissioned blockchain. Firstly, BABE is an algorithm that is similar to Ouroboros-Praos [10] that uses a VRF basedapproach to determine the block proposer of each round. Then, GRANDPA is used to allow nodes to spontaneouslyvote for the blocks and uses BFT arguments to reach finality.As far as we know, GRANDPA-BABE is independently developed and is the most similar consensus algorithm toSURFACE in sense that it also uses a VRF based approach to guarantee an ever-growing chain and achieve finalityupon that with BFT arguments. However, SURFACE and GRANDPA-BABE are different in the following aspects: • In a certain sense, the voting mechanism of GRANDPA is equivalent to a dynamic-size committee for eachblock. Hence, the performance of GRANDPA-BABE will differ from SURFACE depending on the networksituation. In general, SURFACE will give a more stable confirmation time and a lower fork rate, while theperformance of GRANDPA-BABE will depends on how motivated nodes are for voting. On the other hand,GRANDPA-BABE has not yet introduce an incentive scheme for the voters. • GRANDPA does not have optimal responsiveness as stated in [49]. In other words, in extreme scenario, honestnodes will have to wait for the maximum delay δ to make progress, which is not the case in SURFACE. The “abnormal” mode in SURFACE uses a similar but not identical approach as HotStuff BFT [49] to achieve consensus.However, it is explained in Subsection 3.6 that the finality mechanism used in SURFACE is different from HotStuffBFT in many aspects, e.g., chain compliant, unlocking pre-commit blocks.19
PREPRINT - A
UGUST
17, 2020Another difference is that SURFACE functions in the practical asynchronous network and HotStuff BFT functions inpartial synchronous network, which is weaker assumption. However, although HotStuff BFT, as well as PBFT, couldbe straightforwardly use in the practical asynchronous network, the view changing time-out should be modified to aconstant, otherwise they will suffer from a very long latency in the normal situation after a long period of abnormalsituation.The main advantage of SURFACE over HotStuff BFT is the random sample of committee allows a faster probabilisticconfirmation speed in large networks in the “normal” mode. In HotStuff BFT, the block interval needs to be sufficientfor f + 1 nodes to respond. However, in SURFACE, the block interval could be set smaller as the leader only needs towait for the committee to respond. Algorand [20] is similar to the “normal” mode of SURFACE in many aspects. However, Algorand achieves provableBFT with the leader and committee selected in each round, while SURFACE aims to only reduce the probability offorks. Note that there is a trade-off between the committee size and the fault tolerance in Algorand: in order to guaranteethat the number of the adversaries in each committee is less than 1/3 by the law of the large number, the size of thecommittee and the ratio of adversaries in the network should be set accordingly. In SURFACE, this is not a concern aswe allow the committee to be malicious and to create forks.
Tendermint [28] uses a two-phase BFT consensus approach, in which the process of committing a block is identical toPBFT. Then, in order to guarantee liveness, a node that has pre-committed for a block will unlock and prepare for anew block only if
BOTH of the two condition holds: 1) a block proposed in a newer view has received f + 1 preparemessages; 2) a certain timeout is reached. This approach is lack of responsiveness comparing to PBFT and HotStuff assuggested in [49], as a view change will only happen after the timeout, even if there are already f + 1 votes for a newview.In our model, as we incorporate with the possibility of asynchronous and a random committee selection mechanism, arather large timeout should be used to guarantee that there will be enough blocks to commit a block before timeout incase that nodes are locked on inconsistent blocks at the beginning of a consensus round. As a result, we choose to use asimilar three-phase approach as HotStuff BFT to have responsiveness, i.e., the ability to make progress on the BFTprocess without needing to wait for any preset timeout period for view changes. In this paper, we present SURFACE, a blockchain consensus algorithm that is especially designed and optimized forlarge real-world blockchains. The main reason behind the proposal of blockchain is the observation that in real-world,we tend to use double standards on the consensus algorithms used in blockchains. On one hand, it is commonlybelieved that synchronous consensus algorithms are not sufficient and suitable for blockchains. On the other hand,most blockchains function in highly synchronous networks and Bitcoin’s POW actually has a very high requirement ofsynchrony. As a result, the proposed blockchain consensus algorithms are either theoretically sound for asynchronouscase but not optimized in practice, or achieve sky-high performance in laboratory environments but vulnerable inextreme situations. Hence, we take both perspectives into account and put forth the practical asynchronous networkmodel. We then propose SURFACE, which will give a near-optimal performance in the normal situation but still beable to reach definitive consistency in the extreme situations. Certainly, the drawback of SURFACE is that it will havesub-optimal performance if the network is different from our assumptions, e.g., the network shifts between multiplesituations or partitions or attacks in network becomes a new “normal” situation for various reasons. However, we believeSURFACE does fit the scenarios of most real-world blockchains and could provide a reasonably good performance forgeneral cases.
References [1] Al-Bassam, M., Sonnino, A., Bano, S., Hrycyszyn, D., Danezis, G.: Chainspace: A sharded smart contractsplatform. CoRR abs/1708.03778 (2017), http://arxiv.org/abs/1708.03778 [2] Babaioff, M., Dobzinski, S., Oren, S., Zohar, A.: On bitcoin and red balloons. In: Proceedings of the 13th ACMconference on electronic commerce. pp. 56–73. ACM (2012)20
PREPRINT - A
UGUST
17, 2020[3] Bagaria, V., Kannan, S., Tse, D., Fanti, G., Viswanath, P.: Prism: Deconstructing the blockchain to approachphysical limits. In: Proceedings of the 2019 ACM SIGSAC Conference on Computer and CommunicationsSecurity. pp. 585–602 (2019)[4] Ben-Or, M., Kelmer, B., Rabin, T.: Asynchronous secure computations with optimal resilience. In: Proceedings ofthe thirteenth annual ACM symposium on Principles of distributed computing. pp. 183–192. ACM (1994)[5] Bentov, I., Pass, R., Shi, E.: Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive ,919 (2016)[6] Bracha, G.: Asynchronous byzantine agreement protocols. Information and Computation (2), 130–143 (1987)[7] Buterin, V., Griffith, V.: Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437 (2017)[8] Castro, M., Liskov, B.: Practical byzantine fault tolerance. In: OSDI. vol. 99, pp. 173–186 (1999)[9] Croman, K., Decker, C., Eyal, I., Gencer, A.E., Juels, A., Kosba, A., Miller, A., Saxena, P., Shi, E., Sirer, E.G.,et al.: On scaling decentralized blockchains. In: International Conference on Financial Cryptography and DataSecurity. pp. 106–125. Springer (2016)[10] David, B., Gaži, P., Kiayias, A., Russell, A.: Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In: Annual International Conference on the Theory and Applications of CryptographicTechniques. pp. 66–98. Springer (2018)[11] Decker, C., Wattenhofer, R.: Information propagation in the bitcoin network. In: IEEE P2P 2013 Proceedings. pp.1–10. IEEE (2013)[12] EOS: https://eos.io/ [13] Ersoy, O., Ren, Z., Erkin, Z., Lagendijk, R.L.: Transaction propagation on permissionless blockchains: incentiveand routing mechanisms. In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT). pp. 20–30.IEEE (2018)[14] Eyal, I.: The miner’s dilemma. In: 2015 IEEE Symposium on Security and Privacy. pp. 89–103. IEEE (2015)[15] Eyal, I., Gencer, A.E., Sirer, E.G., Van Renesse, R.: Bitcoin-NG: A scalable blockchain protocol. In: 13th USENIXSymposium on Networked Systems Design and Implementation (NSDI 16). pp. 45–59. USENIX Association(2016)[16] Eyal, I., Sirer, E.G.: Majority is not enough: Bitcoin mining is vulnerable. In: International Conference onFinancial Cryptography and Data Security. pp. 436–454. Springer (2014)[17] Ford, B., Böhme, R.: Rationality is self-defeating in permissionless systems. arXiv preprint arXiv:1910.08820(2019)[18] Foundation, W..: Byzantine finality gadgets. https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf (2019)[19] Garay, J., Kiayias, A., Leonardos, N.: The Bitcoin Backbone Protocol: Analysis and Applications, pp. 281–310.Springer Berlin Heidelberg, Berlin, Heidelberg (2015). https://doi.org/10.1007/978-3-662-46803-6-10[20] Gilad, Y., Hemo, R., Micali, S., Vlachos, G., Zeldovich, N.: Algorand: Scaling byzantine agreements forcryptocurrencies. In: Proceedings of the 26th Symposium on Operating Systems Principles. pp. 51–68. ACM(2017)[21] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.: Nsec5 from elliptic curves: Provably preventing dnsseczone enumeration with shorter responses. IACR Cryptology ePrint Archive , 83 (2016)[22] Guerraoui, R., Kneževi´c, N., Quéma, V., Vukoli´c, M.: The next 700 BFT protocols. In: Proceedings of the 5thEuropean conference on Computer systems. pp. 363–376. ACM (2010)[23] Hanke, T., Movahedi, M., Williams, D.: Dfinity technology overview series, consensus system. arXiv preprintarXiv:1805.04548 (2018)[24] Kiayias, A., Russell, A., David, B., Oliynykov, R.: Ouroboros: A provably secure proof-of-stake blockchainprotocol. In: Annual International Cryptology Conference. pp. 357–388. Springer (2017)[25] Kokoris-Kogias, E., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., Ford, B.: Enhancing bitcoin security andperformance with strong consistency via collective signing. CoRR abs/1602.06997 (2016), http://arxiv.org/abs/1602.06997 [26] Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Ford, B.: Omniledger: A secure, scale-out, decentralizedledger. IACR Cryptology ePrint Archive (2017), https://eprint.iacr.org/2017/406.pdf PREPRINT - A
UGUST
17, 2020[27] Kotla, R., Alvisi, L., Dahlin, M., Clement, A., Wong, E.: Zyzzyva: speculative byzantine fault tolerance. In: ACMSIGOPS Operating Systems Review. vol. 41, pp. 45–58. ACM (2007)[28] Kwon, J.: Tendermint: Consensus without mining. https://tendermint.com/static/docs/tendermint.pdf (2014)[29] Lamport, L., Shostak, R., Pease, M.: The byzantine generals problem. ACM Transactions on ProgrammingLanguages and Systems (TOPLAS) (3), 382–401 (1982)[30] Li, C., Li, P., Xu, W., Long, F., Yao, A.C.c.: Scaling nakamoto consensus to thousands of transactions per second.arXiv preprint arXiv:1805.03870 (2018)[31] Libra: [32] Mazieres, D.: The stellar consensus protocol: A federated model for internet-level consensus. Stellar DevelopmentFoundation (2015)[33] Micali, S., Rabin, M., Vadhan, S.: Verifiable random functions. In: 40th Annual Symposium on Foundations ofComputer Science (Cat. No. 99CB37039). pp. 120–130. IEEE (1999)[34] Miller, A., Xia, Y., Croman, K., Shi, E., Song, D.: The honey badger of BFT protocols. In: Proceedings of the2016 ACM SIGSAC Conference on Computer and Communications Security. pp. 31–42. ACM (2016)[35] Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008), https://bitcoin.org/bitcoin.pdf [36] Parity: Proof-of-authority chains - wiki parity tech documentation. https://wiki.parity.io/Proof-of-Authority-Chains [37] Pass, R., Shi, E.: Hybrid consensus: Efficient consensus in the permissionless model. IACR Cryptology ePrintArchive (2016), http://eprint.iacr.org/2016/917.pdf [38] Poon, J., Buterin, V.: Plasma: Scalable autonomous smart contracts. https://plasma.io/plasma.pdf (2017)[39] Poon, J., Dryja, T.: The bitcoin lightning network: Scalable off-chain instant payments. Technical Report (draft)(2015), https://lightning.network/lightning-network-paper.pdf [40] Popov, S.: The tangle. https://iota.org/IOTA_Whitepaper.pdf (2014)[41] Ren, Z., Cong, K., Pouwelse, J., Erkin, Z.: Implicit consensus: Blockchain with unbounded throughput. CoRR abs/1705.11046 (2017), http://arxiv.org/abs/1705.11046 [42] Rocket, T.: Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies (2018)[43] Sompolinsky, Y., Zohar, A.: Phantom: A scalable blockdag protocol (2018)[44] Sompolinsky, Y., Lewenberg, Y., Zohar, A.: Spectre : Serialization of proof-of-work events : Confirmingtransactions via recursive elections (2017)[45] Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in bitcoin. In: International Conference onFinancial Cryptography and Data Security. pp. 507–527. Springer (2015)[46] Vechain: [47] Wood, G.: Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper (2014), http://gavwood.com/paper.pdf [48] Wood, G.: Polkadot: Vision for a heterogeneous multi-chain framework. https://github.com/polkadot-io/polkadot-white-paperhttps://github.com/polkadot-io/polkadot-white-paper