Consensus Mechanism Design based on Structured Directed Acyclic Graphs
aa r X i v : . [ c s . D C ] J a n Consensus Mechanism Designbased on Structured Directed Acyclic Graphs
Jiahao He * , Guangju Wang * , Guangyuan Zhang * , and Jiheng Zhang † * † DMAC Lab * † Department of Industrial Engineering and Decision Analytics † Department of Mathematics * † The Hong Kong University of Science and TechnologyJanuary 10, 2019
Abstract
We introduce a structure for the directed acyclic graph (DAG) and a mechanism designbased on that structure so that peers can reach consensus at large scale based on proofof work (PoW). We also design a mempool transaction assignment method based on theDAG structure to render negligible the probability that a transaction being processed bymore than one miners. The result is a significant scale-up of the capacity without sacrificingsecurity and decentralization.
Key words: consensus; directed acyclic graph; proof of work; transaction assignment.
Blockchain technology is fundamentally a consensus mechanism design based on a chain struc-ture of storing information in a distributed manner over a peer-to-peer network. Taking Bitcoin[6] for example, multiple transactions are grouped together and stored in a block that is lessthan 1 megabyte in size, and all blocks are connected in a chain structure. Although this maynot be the most efficient way of storing information, with the help of cryptographic tools suchas hash functions and public/private keys for integrity check and authentication, Nakamotoconsensus [6] proposed based on the chain structure is able to achieve both security and decen-tralization. Blockchain technology has achieved great success as exemplified by Bitcoin [6] andEthereum [11]. They have proved that a decentralized and secure public ledger system is notonly possible, but also has a great impact in our financial system and gives rise to a whole newecosystem with extendable services and applications.In Bitcoin, all participants compete in solving cryptographic puzzles by tuning a nonce sothat the hash result exhibits a certain required pattern known as proof of work (PoW). The1uzzles are so difficult that in a given period of time, long enough for a block of a given sizeto propagate over the network, it is likely only one miner can form such a block. Miners, infact those who will create future blocks, can choose not to agree with the information in ablock simply by forking from a position preceding that block. Based on the honest majorityassumption, all honest miners will eventually be able to collectively agree upon a chain of validblocks, with invalid blocks on the forks. So all blocks ever created form a tree. The longest chainin the tree, referred to as the Nakamoto chain, is collectively created by all honest miners usingPoW. It is the Nakamoto chain that confirms all the historical records. A rigorous formulationof consensus has been proposed by [3] together with a probabilistic model that formally provesit. With its rapid adoption over the last decade, blockchain technology has now come face toface with a serious bottleneck, the extremely limited capacity, i.e., small number of transactionsper second (TPS). Removing this bottleneck will be a significant breakthrough in advancingthe blockchain technology, and open the possibility for a wide range of applications. However,scaling up the capacity should not be at any compromise of security and decentralization.Within the confines of the chain structure, we can try to increase the block size, or equiva-lently to decrease the time interval between blocks, or use a combination there of to increase theTPS. However, since larger blocks require more time to propagate over a peer-to-peer network,such an attempt would increase the occurrence of forked blocks, even in the absence of mali-cious miners. In order to increase the capacity by an order of magnitude, it is inevitable thatwe explore beyond the chain structure. This naturally leads to the idea of expanding the chainof blocks to a directed acyclic graph (DAG) of blocks to allow parallelism . The idea has beenimplemented by IOTA [9]. In IOTA, everyone has the right to form a small block as no PoW isrequired. The validity of a block is justified whenever someone is willing to append a new blockto it either directly or indirectly. This requires performing the computationally expensive taskof updating weights to calculate the number of blocks appended to each block. The weightsupdate approaches such as Ghost [10] suffer from what is known as the “balancing attack” [1].Meanwhile, capacity is not the only issue in current blockchain systems. With the ever-growinghashing power, cryptographic puzzles are becoming increasingly difficult. Miners with certainhashing power would be able to mine a certain number of blocks and collect the correspondingreward in expectation. However, the huge fluctuations of the actual reward around the expec-tation force most miners to join mining pools in order to smooth their income, leading to theconcentration of hashing power within a few big mining pools. Another issue is the high latencysince it takes a long time to confirm a transaction. In addition, because they are self-interested,miners would try to pack transactions with high fees into their blocks to maximize their reward.Thus, transactions with little to no transaction fees hardly have a chance to be processed.Among the different ways to achieve security and decentralization, PoW and Nakamotoconsensus are two fundamental tools that have been proven to be effective. In this paper, wefurther explore the idea of expanding the chain to a DAG, while still keeping using these twofundamental tools. Without sacrificing security and decentralization whatsoever, the objectivesare to 2 scale up the capacity; • shorten the latency; • deconcentrate the mining power; • increase the probability that transactions with small fees are processed.Our key idea is to embed a Nakamoto chain in a DAG by designing a structure that is stronglyconnected and incorporates miner information. In this way, the security of our design is guaran-teed by the security of the proven Nakamoto consensus, eliminating the need to update weights.Based on the guaranteed security, we will take advantage of the strong connectivity in our DAGstructure to increase the throughput and shorten the latency. A DAG also provides an orderingof transactions so that all honest peers (miners) will be able to build the same public ledgeronce they have reached a consensus on the DAG. We will also explore the rich possibility ofusing our designed structure in DAGs to realize various improvements in line with the aboveobjectives.Our design breaks a large block into multiple smaller ones. In fact, for simplicity, we putonly one transaction in each block. This does not only lead to a smaller block size, but alsomuch easier cryptographic puzzles. This design enables miners to broadcast transactions (storedin small blocks) continuously over time, instead of waiting to broadcast a large batch of trans-actions every once in a while. As mentioned earlier that a major bottleneck for blockchainsis their linear structure which forbids parallelism and the tradeoff between block size and syn-chronization time. Using small blocks allows fast peer-to-peer propagation and parallelism,thus significantly improving the throughput. However, a well-designed structure in the DAGis needed together with a consensus mechanism for security and robustness. This leads to ouridea of interspersing relatively more difficult blocks, referred to as milestones , in the DAG forsecurity purpose. Our DAG starts from the genesis block, which contains a set of trusted setupinformation. The workflow is the same for creating every block, regardless of whether it willbe a milestone or a regular block. When preparing a new block, every miner must choose atransaction that is valid to the best of his latest knowledge, and specify three pointers. Thefirst pointer points to the miner’s previous block, or the genesis if the miner does not have anyprevious block. With this requirement, each miner will have a peer chain representing the stateof that miner, which enables the possibility of incorporating information such as the miner’s“identity” and hashing power. The second pointer points to the previous milestone, or thegenesis if there is no previous milestone, following the traditional longest chain principle in thecase where there is a fork. This pointer is required because the miner does not know whetheror not the new block will turn out to be a milestone. If the new block does turn out to be amilestone, we will need all of the milestones to be connected to form a Nakamoto chain. Thelast pointer must point to another miner’s recent regular block to enhance connectivity amongpeer chains. Note that pointing to too old a block contribute little to connectivity and thus is We use the terms“miner” and “peer” almost interchangeably. The only subtle difference is that a miner mustsolve cryptographic puzzles to create blocks, while a peer does not. Like a miner, a peer may propagate blocksto a peer-to-peer network. secp256k1 ECDSA key verifi-4ation is computationally expensive and could potentially be a bottleneck as TPS increases.Our mechanism design can help a system to approach the ceiling. Our design does not requirestrong information synchronization as in some current systems. Unlike systems requiring fre-quent weights updates, our design does not require expensive computing. Putting only onetransaction in a block may seem inefficient, but the amount of overhead created is in fact quitesmall due to the registration and redemption design introduced in Section 4, and so the designis worthwhile considering the advantages it brings. How close our design is to the ceiling canonly be verified through an open test net, which is under development at the time of writing.We hope to add running results of our open test net in future version updates.Our mechanism design can be viewed as an extension of blockchain technology, such asBitcoin [6] and Ethereum [11], and unstructured DAGs, such as IOTA [9]. Recently, buildingupon the idea of DAG, Conflux [5]solves the waste of discarding the fork blocks by selectingthe “pivot chain” with the highest “weight” whose consensus is guaranteed by Ghost [10].In contrast, we eliminate the need to compute weights and use Nakamoto consensus instead.Algorand [2] provides a new scaling consensus based on Byzantine Agreement, and Thunderella[8] offers a new consensus mechanism that is robust in the worst case and enables fast transactionconfirmation in the optimistic case. These topics are beyond the scope of this paper. Manyproblems exist in the emerging field of blockchain and cryptocurrency. For example, as TPSincreases to the thousands, a dozen terabytes of data will easily accumulate each year. Thecurrent reward scheme only incentivizes people to provide mining service to a public ledger.How do we design an economic model that incentivizes people to provide storage and therequired bandwidth? We will leave this kind of problem to future research.
Among many applications, a graph can describe a data structure, with each vertex representinga basic unit of information, and each edge the relationship between two units. In this section,we describe in detail our proposed structure in a DAG. The objective of this structure is toenable miners across the network to reach a consensus on a set of data, so that they can buildand maintain a public ledger in a distributed fashion that all honest peers agrees on. We presentthe DAG structure in a general setting without too much dependency on public ledgers, sinceit can potentially have other applications.We first describe the basic element, namely a block , in the DAG. As a basic unit of infor-mation, a block B should contain a message , which is the essential data such as transactionsfor cryptocurrency applications. It should also contain some additional information, namelythe block header , for integrity checking and positioning in the DAG. Assume there is a randomoracle H which maps a string of arbitrary length to a unique identity. In actual implementa-tion, we would use a reasonably good cryptographic hash function, e.g. SHA-256 , as the randomoracle. We apply the random oracle to the concatenation of all parts of a block, symbolicallydenoted by H ( B ), to obtain the block’s identity. To check a block’s integrity, we just need to5heck whether the block and its identity match under the random oracle. Formally, a block B = ( id prev , id ms , id tip , peer , nonce , message ) , (1)where ( id prev , id ms , id tip ) are the unique identities of some other blocks in the DAG, peer isthe miner who creates on this block, and nonce is the solution to the cryptographic puzzle.Before giving further explaining the components of a block, we define the genesis O to be aspecial block containing certain trusted setup information. Proof of Work.
We require a proof of work (PoW) for each block in order to decide if aminer has the right to form the block. The miner should tune the nonce until the hash of theblock H ( B ) exhibits a certain pattern. Suppose the hash result H ( B ) is a string of zero-onebits and denote by .H ( B ) the number in [0 ,
1] to which this string of bits converts followingthe convention in [2]. Since H is a random oracle, .H ( B ) can be modeled as a random variableuniformly distributed on the interval [0,1] for any block a priori . In order to “prove work”,a miner needs to vary the nonce until .H ( B ) < d , where d is called the difficulty. Among allthe blocks, we allow a portion of them to be of a special type, called milestones. A block isa milestone if .H ( B )) < pd , where p is the probability that a block is a milestone. Note thata miner has to specify all parts of a block including the three pointers, the main message andthe nonce before working on it (computing the hash). The type of block is revealed only afterthe peer has worked on it. In other words, a peer does not know whether he is working towarda milestone or a regular block. A miner may continue working on the block after obtaining ahash .H ( B ) ∈ [ pd, d ) with the intention of making it a milestone. However, devoting a miner’shashing power to the creation of milestone blocks will not change the expected number ofmilestone blocks he is able to create. Since a regular block also yields a mining reward, albeita smaller reward than that offered by a milestone, and involves a transaction fee, exclusivelymining milestone blocks is not economically beneficial for peers.To describe the structure we want to design in a DAG, we now explain how the three pointers( id prev , id ms , id tip ) position the block in the DAG and the intuitions behind our design. Peer Chain.
The first pointer id prev points to the most recent block created by the sameminer or the genesis if the miner has not mined any blocks before. By this mechanism, blocksmined by the same miner are organized into a chain, namely the peer chain . The head of thechain, defined to be the most recent block, of the chain can also be interpreted as the stateof the miner. A peer chain is designed to provide not only a clear structure in the DAG, butalso valuable information including the miner’s mining history, from which we can estimate theminer’s hashing power. In Section 4, we will introduce a transaction scheduling scheme thatutilizes the miner state and estimated hashing power to reduce the probability that a transactionis processed by multiple miners. The peer chain could also potentially generalize our design tocredit-based applications. Formally, we require B . id prev = H ( B ′ ) = ⇒ { B ′ . peer = B . peer } or { B ′ = O } . (2)6ote that this mathematical requirement cannot prevent a miner from forking his own peerchain (e.g., not appending to the miner’s most recent block) nor attacking (e.g., forking anotherminer’s peer chain). As explained later in the reward scheme in Section 4, a miner not appendingto his most recent block only cause less mining reward and waste of his hashing power. Anda miner mining on another miner’s peer chain might be wasting a small amount of the systemcapacity at the cost of his own hashing power without any benefit to anyone. None of the aboveactions would affect the consensus. In fact, incentivizing a miner to append a newly minedblock to his most recent block lessens the effect of “lazy connecting”, i.e. not appending torecent blocks, an issue raised in the implementation of IOTA [9]. The pointer B . id prev specifiedin (2) is essentially a directed edge from B to B ′ if we view each block as a vertex in a graph. Anydirected edge plays a confirmation role in that block B confirms B ′ , which confirms its previousblocks via its three pointers. Connectivity.
To create the connectivity among different peer chains, we use id tip to pointto a regular block of another miner. The genesis O is set as the default when no such blockexists. Formally, B . id tip = H ( B t ) = ⇒ { B t . peer = B . peer , .H ( B t ) ∈ [ pd, d ) } or { B t = O } . (3)Again, the directed edge from block B to B t plays a role of confirming B t and all of the blocks that B t confirms. See (10) for a mathematical definition of confirming previous blocks. Intuitively,a stronger connection leads to faster confirmations, thus we could have multiple such pointersto further enhance the connectivity. However, these pointers have to be synchronized, verifiedand stored by all peers and therefore having more pointers will incur a higher overhead cost.Our analysis in Section 5.3 shows that having one such pointer is enough to ensure reasonableconfirmation latency. Embedding a milestone chain.
The pointer id ms points to a milestone block B m or thegenesis O , i.e. B . id ms = H ( B m ) = ⇒ { .H ( B m ) < pd } or { B m = O } . (4)Our milestone chain works the same ways as the Bitcoin blockchain. The difference is thateach blocks on our milestone chain is smaller and confirms some other regular blocks in astructured way. A major barrier to scaling up the capacity of a blockchain system is the slowsynchronization of large blocks in a peer-to-peer network. Our milestone chain, consists of muchsmaller blocks, is designed as a bridge between high throughput and stable synchronization.Each milestone, despite being small, confirms a relatively large number of other blocks asdefined in (10). In other words, each milestone confirms a part of history. Therefore, as long asthe peers reach a consensus on all milestones, they reach a consensus on the entire history. Toachieve the objective, we have to put all milestones in a chain structure by requiring all blocksto have a pointer pointing to a previous milestone. This is because when preparing a block, inparticular when setting the pointer id ms , there is no way of knowing whether or not that block7ill be a milestone until cryptographic puzzle is solved. If the block turns out to be a milestone,we want to make sure it connects to a previous milestone via the pointer id ms .Let G be a collection of blocks including the genesis O , such that each non-genesis blocksatisfies (2)–(4), and ∀ B ∈ G , H ( B ′ ) = B . id key , key ∈ { prev , ms , tip } = ⇒ B ′ ∈ G . (5)In other words, all blocks to which B ∈ G points are also in G . Essentially, G is a directed graphif we regard blocks as vertices and pointers as directed edges. We say there exists a path from B to B ′ if starting at block B we can follow a consistently-directed sequence of edges to reachblock B ′ . Such a graph is called acyclic if for any block B in G there is no directed path from B to itself.A block is syntactically valid if its format satisfies (1) and it matches its identity. This issimilar to the integrity check of a block in Bitcoin. A DAG G is syntactically valid if all of itsblocks are syntactically valid, and it is acyclic and satisfies (5). A block B is syntactically valid for the sDAG G if G ∪ { B } is syntactically valid. A peer’s first task is to ensure his local DAGis syntactically valid. Such a check protects the system from being flooded with invalid blocks.It will become self-evident that under our protocol, the milestone tree is essentially the treeoccurring in a blockchain with forks. The milestone tree plays an essential role in connectingall of the peer chains, while the pointers id tip further enhance the connectivity of the DAGFigure 1 provides an illustration of such a structure. O miner 5miner 4miner 3miner 2miner 1 Figure 1: DAG structure for 5 miners with milestone forks.We now define the height of milestone blocks in a structured DAG. The height of the genesis η ( O ) = 0, and for a milestone block B , i.e., H ( B ) < pd , the height is defined as η ( B ) = η ( B m ) + 1 , where H ( B ) < pd and B . id ms = H ( B m ) . (6)The genesis and all milestone blocks in G form a tree where the depth of each milestone blockis its height. The leaf set of all milestone blocks is T m ( G ) = { B m ∈ G : H ( B m ) < pd and ∄ B ′ m ∈ G s.t. H ( B ′ m ) < pd and B ′ m . id ms = H ( B m ) } . (7)For a milestone block B m in the leaf set with η ( B m ) = n , following the pointers id ms we canfind a sequence of blocks B m,n = B m , B m,n − , B m,n − , ...., B m, , B m, = O , (8)8uch that H ( B m,k ) < pd and B m,k . id ms = H ( B m,k − ) for all k = 1 , , . . . , n . We call such asequence the milestone chain for block B m . So each block in the leaf set of all milestone blocksrepresents a milestone chain, whose length is equal to the height of that block. We define theheight of the DAG to be the length of the longest chain(s), η ( G ) = max { η ( B ) : B ∈ T m ( G ) } . (9)Note that multiple longest chains might exist. To choose a longest chain, we just need to choosea block with the largest height in the leaf set. The n th milestone is defined to be the block onthe longest milestone chain with height n .For any milestone block B m ∈ G , we define the DAG confirmed by the milestone B m to be C ( B m ) = { B ∈ G : there exits a path from B to B m } ∪ { B m } . (10)If B ′ m ∈ G is the milestone or genesis that immediately preceding B m , i.e. B m . id ms = H ( B ′ m ),then we define the level set to be S ( B m , B ′ m ) = C ( B m ) \ C ( B ′ m ) . (11)With slight extension of notation, we define C ( k ) = C ( B m,k ) to be the DAG confirmed by the k th milestone and S ( k ) = C ( k ) \ C ( k −
1) to be the k th level set, with C (0) = { O } . In Figure 2,level sets S ( k ), S ( k + 1), S ( k + 2) and S ( k + 3) are shaded in gray. The pending set is definedto be the set of all blocks that have not yet been confirmed by any milestone on the longestmilestone chain. It is worth pointing out that the blue block is also a milestone block. Thismilestone forked from the ( k + 1)th milestone due to either network synchronization delay orattack. The blue and red blocks in Figure 2 form the milestone tree above defined. The blueblock and the current ( k + 2)th milestone will compete for confirmations by future milestonesbased on Nakamoto consensus. If the blue blocks fails, i.e. all honest peers thinks it is a fork,it will be treated as a regular block in Section 4 when we building the ledger. O miner 5miner 4miner 3miner 2miner 1 k − k k + 1 k + 2 k + 3Pending Set Figure 2: An Illustration of Level Sets and the Pending Set
The structured DAG is collectively created and maintained in a distributed fashion by all peersover a peer-to-peer network following a protocol. Peers following this protocol are said to be9 onest and peers not following this protocol are said to be malicious . In a decentralized system,each peer will have his own local DAG, which can be different from the local DAG of another peerdue to issues like network synchronization delay and malicious attacks. This can be illustratedby comparing Figure 2 and Figure 3. Suppose the due to network synchronization, an honestpeer has not received the latest milestone created by miner 5. He may then think that the bluemilestone is the ( k + 2)th on the longest chain. In this case, his view is depicted in Figure 3. O miner 5miner 4miner 3miner 2miner 1 k − k k + 1 k + 2 Pending Set Figure 3: Level Sets from a Different PerspectiveFor a peer a , denote his local DAG by G a , which is evolving he creates and receives blocks.All miners start their peer chains from the genesis block O . We now describe the protocol to befollowed by each peer/miner. The objective for all honest peers to agree upon the same DAG(see Section 5.1), and consequently to use the same set of data to construct the public ledger.We will present our protocol in the setting of a cryptocurrency application for concretenessand clarity, although the protocol can potentially be generalized to other applications. To thisend, we first discuss the mempool, which is the buffer holding all pending transactions to beprocessed. When someone wants to initiate a transaction, he will broadcast it to a few connected peers.This is implemented via an inventory message and getdata approach in Bitcoin for example. Ifa peer considers the transaction valid after receiving it, he will also broadcast the transactionto all of his peers. A peer also need to remove a transaction from his local mempool once hefind out that transaction has already been put in a block, created either by himself or otherpeers. In such a way, all peers will locally have a buffer of all outstanding transactions waitingto be processed.The purpose of expanding the chain structure to a DAG structure is to allow parallelism forscaling up the capacity. However, with the current mempool design, it is highly possible that thesame transaction, especially when it is associated with a high transaction fee, will be processedby multiple miners due to network broadcast delay. Consequently, the same transaction mayend up in multiple blocks. Although only one block will be valid according to our local algorithmof constructing the ledger from the local DAG, much capacity would go to waste. If someonewith malicious intent wants to ruin the network by wasting a large portion of the capacity, he10ould broadcast transactions with attractive fees in rapid succession. Such an attack would bemuch less costly than owning and using a certain percentage of the hashing power on the onehand, and can effectively reduce the capacity on the other hand.Therefore, we need to design a mechanism to effectively reduce the chance of collision,i.e., the chance of one transaction being processed by multiple miners. The basic idea is todynamically limit the number of transactions a miner can process at any time by using thehash result .H ( H ( B i ) , Tx ) as a distance between transaction Tx and the miner’s state B i , i.e. themost recent block on miner i ’s peer chain. The peer chain can also give a clear count of theproportion of blocks created by this miner in any level set, and thus it provides a reference ofthe miner’s hashing power. Suppose miner i possesses q i ∈ [0 ,
1] proportion of the total hashingpower. We say that transaction Tx is workable for miner i only if the distance .H ( H ( B i ) , Tx ) ≤ cq i , (12)where c is parameter to be specified based on some careful analysis in Section 5. This meansthat a transaction has a probability of only min( cq i ,
1) to be workable for miner i at any time.We now provide some simple calculation to give some idea. First, miner i can surely processall transactions if c is chosen such that cq i ≥
1. So we just limit our choice of c to the range(0 , / max i q i ). Under this assumption, we have P ( Tx is not workable for any miner) = n Y i =1 (1 − cq i ) ≤ ( P ni =1 (1 − cq i ) n ) n = (cid:16) − cn (cid:17) n ≈ e − c , (13)as n becomes large. So intuitively, making c small cause a transaction hard to be processedby miners in the network. Here we want to estimate the probability that a transaction can beprocessed by two or more miners. To do so, we need to compute P ( Tx is workable for exactly one miner) = n X i =1 cq i Y j = i (1 − cq j ) ≈ e − c n X i =1 cq i − cq i ≈ ce − c , (14)as n becomes large. The last estimate in the above is under the assumption that no miner ownsa significant portion hashing power thus 1 − cq i can be approximated by 1 when n is large. Inthis way, we obtain a neat answer and we can see clearly how the parameter c plays a role.Summarizing the above two estimates, the probability of collision is given by P ( Tx is workable by more than one miners) ≈ − e − c − ce − c . (15)11aking c smaller helps to reduce collision. To give some quantitative idea, simply setting c = 0 . . c wisely to strike a balance between the wasted capacity and waiting time. A peer may be new to the network or has been offline for a while. In this case, the peer shouldfirst learn from his connected peers the height of the longest milestone chain. If the height of hislocal DAG is much smaller, he should start downloading the missing level sets. Once a peer’slocal height is close to the heights of his connected peers, e.g., within a threshold specified in ourcode implementation, the peer can start to receive broadcasted newly mined blocks. Supposepeer a receives a block B through broadcast. It is possible that he does not have some blocksto which B either directly or indirectly points due to synchronization delay. He should start aprocess to solidify the block B by asking his peers for the missing blocks from its peers. Once hehas obtained all the missing blocks, peer a needs perform topological sorting (e.g. Section 2.2.3in [4]) of these blocks, so that blocks can be added sequentially to the peer’s local DAG.We now describe how to add a block B , where the blocks to which it points are already inthe DAG G a . First, check if block B is syntactically valid for G a = C ( B m ). If not, discarded theit immediately; otherwise update the local DAG G a by letting G a := G a ∪ { B } and relay the block B to connected peers. If block B contains a transaction that is in thepeer’s mempool, the peer removes the transaction from his mempool. Note that we do notrequire the peer to verify the transaction in block B at this stage. Taking Bitcoin for example,the verification requires verifying signatures and checking that all inputs of the transactioncorrespond to some unspent outputs in the public ledger according to the current local DAG,and ensuring no double spending occurs among all transactions. We postpone such verificationto the time when we convert the local DAG to a ledger, primarily because it takes time, inparticular the secure latency (Section 5.3), to reach consensus on the DAG.The primary concern is whether block B is a forked milestone or not. In other words, weneed to consider what kind of block it is. If block B is regular, do nothing. If block B is amilestone, we need to compare the height of G a with η ( B ). If η ( B ) > η ( B m ), then set G a := C ( B ) . This means a major update of the G a since the peer needs to switch from the current milestonechain to the newly discovered longest milestone chain in the local DAG.12 .3 Creating a block If a miner wants to create a block B , and have it accepted by all other peers as part of theirlocal DAGs, the actions to be taken are as follows. The first thing the miner needs to do isto find a transaction that he can process from his mempool as required in by (12), and putthis transaction in a block. We also require the selected transaction to be compatible with theminer’s ledger, i.e. the input(s) for this transaction should be in the unspent outputs of theledger constructed based on the DAG C ( B m ), where B m is the highest milestone in its localDAG.Next, the miner must prepare three pointers so that the block will be syntactically valid.The steps are as follows1. Pick the highest milestone B m in his local DAG G a and set B . id ms = H ( B m ).Note that B m is the most recent milestone in the local DAG G a . However, due to networksynchronization, B m is may not necessarily be the most recent milestone block in reality.2. Pick the most recent block B ′ created by himself in G a and set B . id prev = H ( B ′ ). If nosuch B ′ exists, set B . id prev = H ( O ).Note that block B ′ and B being consecutive blocks created by the same miner is a strongerrequirement than (2). See further discussion in the next section.3. Define the tip set to be the set of regular blocks to which none of the blocks in G a pointsand are not created by the miner a . Randomly pick a block B t from the tip set and set B . id tip = H ( B t ). If the tip set is { O } or empty, then set B . id tip = H ( O ).This means that the miner needs to find a regular block B t created by some other miner.4. Keep applying the hash function to this block by changing the nonce untill .H ( B ) < d .5. Finally, the miner needs to broadcast B through a peer-to-peer network. This certainlytakes time, as we will discuss in the subsection on the broadcast delay assumption inSection 5. We present this section in the context of the unspent transaction output (UTXO) model ofBitcoin for concreteness. The idea of constructing a public ledger from the DAG structure canbe extended to other models. In the UTXO model, a transaction essentially specifies previoustransaction outputs as new transaction inputs and allocates all input values to new outputs.Obviously, signatures are required in order to use an output as a transaction input. Readers canrefer to Bitcoin documents for details. A ledger is an ordered list of transactions, from whichwe can construct the set of UTXOs. We say that a transaction is valid if it passes the signaturevalidation and its inputs are indeed from the UTXOs according to all preceding transactions.A ledger is valid if all of its transactions are valid.13ince we do not impose validity checks when receiving transactions packed in blocks, thereis no guarantee that all of the transactions in a local DAG are valid. For example, it is likelytwo or more double-spending transactions coexist in a local DAG. The level sets in our DAGalong the longest milestone chain provide the natural ordering of level sets from low to high.Within each level set, we utilize a depth-first search algorithm to order all its transactions. Inthis way, as long as peers agree on the same DAG, they agree on the same way to order thesame set of transactions. We then specify an algorithm to chose a subset of this transactionfollowing the same ordering to form the public ledger.Recall the definition of syntactical validity of our DAG, which every honest peer shall checkwhen updating it. Although it specifies a structure in the DAG, it does not enforce hardconstraints on the following requirements: • Each miner should keep the blocks created by himself in a chain structure without anyforks. • A new block shall point to the most recent milestone being created. • A new block shall point to a recent regular block on another peer chain when created.In fact, we could not enforce hard constraints in most cases since there is synchronization takestime. For example, ideally, we would like to force each miner to connect to a block on anotherpeer chain in the pending set. But as illustrated in Figures 2 and 3, there may be no consensuson the pending set due to temporary broadcast delay. Also, forbidding forking of a peer chainadd too many complicated rules while performing syntactical validity check and is not easy toreach consensus when there is a forking attack. On the other side, not following the above threeprinciples decreases the performance of our system in terms of latency and wasted capacity. Forexample, connecting to a too old regular block on another peer chain contributes very little tothe connectivity, thus slow down the confirmation by a milestone block. Also, not connecting tothe latest milestone creates the same issue of forking as in Bitcoin. Though eventually honestpeer will reach consensus on the longest milestone chain, forking is not desirable as it is a wasteof mined milestone blocks and cause delay in secure confirmation.
Reward Scheme.
We design the following reward scheme to incentivize miners to follow theabove mentioned principles. A miner should be rewarded by a fixed fee (even if the block doesnot contain a transaction) plus the transaction fee for creating a block. Exactly how much aminer can get out of a block depends on three factors: the type of the block, the ultimate statusof this block, and the validity of the transaction in this block. The first two factors depends onconsensus dictated by the longest milestone chain, and the last one depends on the ordering oftransactions as we will explain later.We have been using milestone and regular as block types so far. As discussed in Section 2, allthe milestone blocks form a tree. When computing the reward, we would like to treat milestoneblock not on the longest chain as regular blocks. For ease of reference, let’s call regular andforked milestone blocks regular+ . Let r m and r n denote the fixed reward for milestones on the14ongest milestone chain and regular+ blocks, respectively. It is natural that r m > r n milestoneblocks are more difficult to create. As mentioned before, miners do not know the type of ablock a priori when working on it. Let B m and B ′ m be two consecutive milestones on the longestmilestone chain with B m . id ms = H ( B ′ m ). Define R ( B m ) = r n ( |S ( B m , B ′ m ) | − S ( B m , B ′ m ). We summarize ourreward scheme in the following table:Block Type Block Status Transaction Rewardregular+ on peer chain Valid r n + Tx feeregular+ on peer chain Invalid r n regular+ forked from peer chain Valid 0regular+ forked from peer chain Invalid 0milestone on the longest milestone chain Valid r m + Tx fee + δR ( B m )milestone on the longest milestone chain Invalid r m + δR ( B m )Table 1: Reward SchemeOn top of fixed amount r m and the transaction fee if valid, a milestone block also bringsadditional reward of δR ( B m ). We can think of the parameter δ as for example 2%. This meansthat any miner who created a milestone, he will get in addition 2% of the rewards for all theblocks that milestone confirmed in its level set. For example, if a system is running at 1000 TPS,and milestones are generated every 10 seconds, there will be on average 10000 blocks in a levelset. So there is quite a big bonus compared with the situation where the block, despite qualifiedto be a milestone, end up being a regular+ block because it is not on the longest chain. Byappropriately chose the parameters r n , r m and δ , we hope to provide miners enough incentiveto try their best to point to the most recent milestone when creating new blocks. Since theextra bonus depend on the number of blocks in the level set, this will also incentivize a minerto point a new block to a recent regular block on another peer chain to maximize the numberof blocks he can confirm.The economic model is out of the scope of this paper which focus on consensus. Under ourdesign, one can choose to adjust r n and r m every once in a while so that the total number ofissued coins is fixed like in Bitcoin. Alternatively, one can keep them fixed so that the totalamount of currency in the system will inflate. There are many ways to design the financialsystem, which we will not discuss here. No matter how to choose these parameters, such ascheme together with smaller blocks which can be miner more easily will make miner i ’s incomerate commensurate (without too much volatility) to his q i proportion of total hashing powertimes the rate at which new currencies are issued plus transaction fees.Note that in the above table, forked blocks from a peer chain brings zero reward thusincentivize miners to follow the principle of maintaining the structure in peer chains. Howexactly does this work will be discussed in the following part.15 egistration and Redemption. As we can see in the designed scheme, the reward for ablock cannot be recorded as a static numerical number upon the time creating the block. Thus,we need a mechanism that rewards each miner after consensus has been reached on the DAG.One possible solution is to build a script in each block which will be able to calculate theexact reward based on the three factors. But this solution costs too much storage overheadfor a block with only one transaction since a script itself will contain address and public keyaccumulating to about the similar size as a transaction. It is also computationally expensivesince we find the secp256k1 ECDSA key verification time consuming. We hence propose thefollowing registration-redemption solution The first block each miner creates (the one directlypoints to the genesis) should contain a special transaction called registration , which specifies anaddress where future rewards on the peer chain should be awarded to. Every once in a while, aminer can choose to create a block on his peer chain contain another special transaction called redemption , which plays two roles. The first is to redeem the accumulated reward since theprevious redemption (registration) transaction on his peer chain to the address specified by theprevious redemption (registration) transaction. The second is to specify the address to whichnext redemption shall be awarded to. To publish the a redemption block block, a miner has toprove the ownership of the address in his previous redemption block by using his secrete key. Assuch, the reward of a miner can only be claim by himself. Also, a miner can choose to redeemwhenever he wants and have the option to specify a different address to store his reward everytime he redeems. Since a redemption block can only redeem all the rewards in the blocks on thepeer chain since the previous redemption block, this effectively prevent a miner from forking hisown peer chain since in that way, the forked block costs computing power but brings no reward.This design also prevents the forking attack on a peer chain by another miner. Suppose amalicious miner, Alice, try to fork the peer chain of an honest miner Bob. Alice first spendssome hashing power to create a block whose peer is set to Bob and pointer id prev is set to pointto some block on Bob’s peer chain. If the chosen block is not the head of Bob’s peer chain, Alicecreates a fork on Bob’s peer chain. Alice can surely extend this fork by continuing spendingmining power to create more blocks along it. Note that Alice cannot publish a redemption blockon Bob’s chain since that requires Bob’s private key to prove the ownership of the address inBob’s previous redemption block. Thus there is no way Alice can redeem any reward on Bob’schain, even the reward in the forked blocks which are create by Alice. In fact, this actuallygives Bob a choice if the rewards along the fork is larger, Bob can easily append a redemptionblock to that fork to redeem the rewards. Of course, Bob has to give up the blocks mined byhimself by doing so. Such an attack causes no damage to consensus and Bob’s revenue andAlice’s hashing power will be wasted.In summary, the registration and redemption approach help to determine a unique peerchain for each miner by embedding a sequence of redemptions block which requires that miner’ssignature. Note that a simple idea is to a signature in every block in order to determine aunique peer chain. But a signature require substantial space in the block, causing too muchstorage and computation (for signature verification) overhead.16 epth-first Search. The final preparation before constructing the ledger is to provide an or-dering of all the transactions (equivalently blocks). Recall in Section 2 that blocks are organizedin level sets S (1), S (2), S (3), . . . along the longest milestone chain. So we order the level setsusing the heights of their milestones from low to high. According to the definition (11), level set S ( n ) is a directed binary tree with the root being the n th milestone B m,n . Each directed edgein the tree is essentially a pointer in { id prev , id tip } . Note that we remove id ms since it eitherpoints to a previous level set or is redundant. We use the depth-first search (DFS) to traversethis tree starting from the root B m,n along the directed edges in the order of first id prev andthen id tip . Blocks in each level set are ordered according the post-order DFS .Assume we obtain an ordered list of transactions following the above level set ordering andDFS ordering within each level set, Tx , Tx , Tx , . . . Let L k be the ledger constructed based on the first k transactions and U k denote the set ofUTXO based on L k . We start with L = { Tx } and U being the outputs of Tx . In order toobtain ( L k +1 , U k +1 ) from ( L k , U k ) and Tx k +1 , we need to perform the following check. If theinputs of Tx k +1 are all from U k and Tx k +1 passes signature verification, then L k +1 = L k +1 ∪ ( Tx k +1 ) , U k +1 = U k ∪ { outputs from Tx k +1 } \ { inputs from Tx k +1 } , otherwise ( L k +1 , U k +1 ) = ( L k , U k ).We would like to point out that any graph traversal algorithm leading to a unique orderingwill be good enough for consensus purpose but an advantage of the DFS ordering is that thechronological order of blocks on a peer chain is kept. We now provide a modeling approach to analyze the performance of such a distributed system.We focus on the three most important measures—consensus, latency and TPS. Throughout ouranalysis, we make the following synchronization assumption.
Broadcast Delay Assumption.
When a peer broadcasts a message of size ν size to a peer-to-peer network with n peers, F ( t ) fraction of the peers will receive the message after t amountof time. Clearly, F ( t ) increases with time t . We further assume there exists a finite time t suchthat F ( t ) = 1. In other words, all peers will be able to receive the message within t amountof time.Note that the broadcast curve F and the bound t depend on both the message size ν andthe number of peers n . We point out that the block size in our DAG (typically less than onekilobyte in our implementation) is much smaller than that of Bitcoin for example, which is one https://en.wikipedia.org/wiki/Tree_traversal t should be quite small. By classical results in regular graphs, a block willbe able to reach all n honest peers in O (ln( n )) relays in expectation, assuming it is syntacticallyvalid such that all honest peers will relay the block immediately after receiving it. Since all blocks will be confirmed by some milestone block along the longest milestone chain, ourlevel sets essentially play the role of the blocks in Bitcoin. So the consensus of our DAG systemessentially boils down to that of the block chain. This has been formally proven by [3] whoproposed the Bitcoin Backbone Protocol model. We will not repeat the proof here. Instead,we make the connection to convince readers that it is legitimate for us to directly borrow theirresult with the following assumptions.The analysis in [3] is based on discrete rounds, which is not too different from our model.We can discretize our time line into intervals of length t and let time interval ( rt , ( r + 1) t ] beround r . Based on our broadcast delay assumption, blocks produced in round r will reach allhonest peers by the end of round r + 1. In the round-based model, we assume all actions aretaken at the end of each round.Let f be the probability that there exists an honest peer producing one milestone in a round.The honest majority assumption requires that the number of malicious peers κ , constitute onlya small fraction of the total population. Specifically, the number of malicious miner κ ≤ (1 − f ) n Note that a large f intuitively implies a high chance that honest miners will create more thanone milestones miners in the same round. This would increase the chance of their forking themilestone chain due to broadcast delay. Thus the larger the f , the smaller the proportion ofmalicious miners required for the following result to hold true. In fact, more subtle relationshipsexist between f and ( n, κ ). Interested readers can refer to the proofs in [3] for more details.The good news is that under the honest majority assumption, we have the following result onconsensus. The following property follows from Theorem 15 in [3]. Common Prefix.
Consider any pair of honest peers p and p following our protocol tomaintain their local DAGs. Let G p be the local DAG of peer p at round r , and G p be thelocal DAG of peer p at round r . Suppose r ≤ r and the height of G p is h . For any positiveinteger h ′ , let B m,h ′ be the milestone of height h ′ in G p , and C p ( B m,h ′ ) be the DAG confirmedby B m,h ′ in p ’s local DAG. There exists a k such that C p ( B m,h − k ) ⊆ G p with probability higherthan 1 − e − Ω( k/f ) , where Ω( x ) dominates x as x grows.Note that the Bitcoin Backbone Protocol model is well designed for proving the consensusproperty, as we are only interested in the existence of the number k and the probability 1 − e − Ω( k/f ) in the above. However, it is not suitable for parameter selection. For example, to ensurethe probability 1 − e − Ω( k/f ) exceeds 99.9%, we may end up with a too big a k for practical use.18his is because the estimations in the backbone model are quite conservative. We propose amore accurate model in the next subsection for setting a practical parameter k . Due to synchronization issues, a transaction may be processed by multiple peers and put inseveral blocks. The extra copies are a waste of hashing power. This subsection is devoted togiving an upper bound for the wasted capacity under our transaction assignment protocol (12).In the subsequent analysis, we assume there are n honest miners with equal hashing power.We also assume that with the current total hashing power, new blocks are created by followinga Poisson process with rate nµ (blocks/unit of time), where µ denotes the average rate of blockcreation for each miner.Suppose transaction Tx reaches miner i at time 0. However, Tx has just been mined bysome miner, who has subsequently broadcasted his block B tx containing this transaction tothe network at time 0. Suppose it takes T i amount of time for miner i to receive this block.According to our broadcast delay assumption, T i is a random variable following distribution F . Let us assume the worst case where the transaction fee of Tx is so attractive that miner i will surely mine this transaction whenever he can before time T i . Let N i ( t ) denote the numberof blocks miner i can create during time (0 , t ]. Clearly N i ( · ) is a Poisson process with rate µ .During the time (0 , t ], miner i will have changed his miner chain head N i ( t ) times, which followsthe Poisson distribution with rate µt . So conditional on N i ( t ) = k , the probability that miner i is eligible to work on transaction Tx some time during the interval (0 , t ] is P ( I i ( t ) = 1 | N i ( t ) = k ) = 1 − (1 − cn ) k ≤ − e − ckn , where I i ( t ) indicates whether or not miner i is eligible to work on Tx .Let A i denote the event where miner i successfully mines Tx before he receives the block bytime T i . We have the conditional probabilities P ( A i | I i ( T i ) = 1 , T i = t ) ≤ − e − µt , P ( A i | I i ( T i ) = 0 , T i = t ) = 0where 1 − e − µt is the probability that miner i will successfully create the block in time t andthis is an upper bound for the left side of the first expression.So, conditional on T i = t , the probability that miner i creates a block for transaction Tx canbe bounded as follows: P ( A i | T i = t ) ≤ (1 − e − µt ) P ( I i ( T i ) = 1 | T i = t )= (1 − e − µt ) E N i [1 − (1 − cn ) N i | T i = t ]= (1 − e − µt )(1 − e − µt cn )This implies P ( A i ) ≤ E (1 − e − µT i )(1 − e − cn µT i ) ≤ (1 − e − µ ¯ t )(1 − e − µ ¯ t cn ) , t = E ( T i ) = R t tdF ( t ), and the last inequality is obtained by Jenson’s inequality as theabove conditional probability is convex in t . The probability that Tx is mined exactly once islower-bounded by n Y i =1 (1 − P ( A i )) ≥ ( e − cn µ ¯ t (1 − e − µ ¯ t ) + e − µ ¯ t ) n → e − cµ ¯ t (1 − eµ ¯ t ) as n → ∞ . The expected number of copies of mined Tx is upper-bounded by1 + n X i =1 P ( A i ) ≤ − e − µ ¯ t ) n (1 − e − µ ¯ t cn ) → − e − µ ¯ t ) µc ¯ t as n → ∞ . So the proportion of capacity that is wasted is upper-bounded by θ ( c ) = (1 − e − µ ¯ t ) µc ¯ t − e − µ ¯ t ) µc ¯ t . (16) c is a design parameter, and the smaller c is, the less capacity that is wasted. After a transaction enters the mempool, it will go through three phases before it is finallyconfirmed in the public ledger. Firstly, the transaction has to wait in the mempool until someminer creates a block B to store it. We call this waiting time the queueing latency W . Next, thisblock needs to be confirmed by a milestone B m . Recall the definition of confirmation given in(10). We call this period the infection latency W since it will be analyzed through an infectionmodel. Lastly, the milestone B m needs to be extended by a chain of future milestones with acertain number to ensure a certain level of security. We call the last stage secure latency W . Queueing Latency.
Suppose new transactions arrive at the mempool following a countingprocess with a constant rate λ . The mempool is essentially a queueing system with arrival rate λ and effective processing rate depending on both nµ and the transaction assignment rule (12).We now give an estimation of the waiting time in queue W based on the idea of the fluid modelin queueing theory.Denote by Q the stable queue length, i.e. number of transactions in the mempool. Whenevera miner tries to find a transaction from the mempool to work on, he will find that the numberof transactions he can process follows the binomial distribution with total number of trials Q and success probability c/n , which can be approximated by the Poisson distribution with rate( Qc/n ) since Q is large and c/n is small. So the proportion of time that a miner has to work onan empty block is the probability that the Poisson random variable equals 0, i.e. e − Qc/n . Therate at which blocks containing transactions are generated is therefore nµ (1 − e − Qc/n ). As notedin the previous section, only (1 − θ ( c )) of the transactions are distinct, so the rate at which thetransactions in the mempool are processed is (1 − θ ( c )) nµ (1 − e − Qc/n ). For the system to havea stable Q , it is required that nµ (1 − e − Qc/n )(1 − θ ( c )) = λ. Q = nc ln( nµnµ − λ/ (1 − θ ( c )) ). By Little’s law, the average waitingtime of a transaction is W = ncλ ln nµnµ − λ − θ ( c ) ! = 1 c ρµ ln − ρ − θ ( c ) ! , (17)where ρ = λnµ denotes the traffic intensity. Note that the number of miners does not affect thequeueing latency as long as the rate at which new blocks are produced remains the same. Theinfluence of c on W is complicated. On the one hand, a larger c will result in less idle time, thusincreasing the effective processing rate. On the other hand, a larger c leads to a higher proportionof duplicate blocks, thus decreasing the effective processing rate. The relation between wastedcapacity and queueing latency can be described as follows: W ( θ ) = (1 − θ )¯ t (1 − e − µ ¯ t ) θρ ln − ρ − θ ! (18)Our quantitative modeling analysis sheds the light on how the parameter c can be chosen tostrike a balance between collision and latency.Traditional queueing theory suggests that the waiting time will blow up when the trafficintensity ρ − θ approaches 1. A more complicated model can be analyzed by allowing eachtransaction to have an expiration clock, without which the mempool size will grow without abound. For the time being, the above queueing model is good enough to get the system started. Infection Latency.
A primary difference between the DAG and chain structures is that theformer goes beyond the one-dimensional linear structure by allowing parallelism. Despite themany advantages of the DAG, one issue is that a block may not necessarily be confirmed bythe next milestone—it may have to wait for a later milestone. A natural question is how long ittakes for a block to be confirmed by a milestone block after it is broadcasted to all miners. Wenow provide an upper bound on this waiting time by modeling confirmation in our DAG usingan infection model. In our analysis, we assume all of the n miners are incentivized to follow thethree principles specified in Section 4.Suppose that at time 0, block B is in the pending set, i.e. it has not been confirmed by anymilestone. As previously discussed, new blocks arrive following a Poisson process with rate nµ .Each new block has probability p of being a milestone. Suppose that at time s >
0, there are X s miners whose head block can reach B by following a path in the DAG. We say that theseminers are infected by B . Note that if all miners are infected, then B will surely be confirmedby the next milestone. Assume the next new block is created by miner a at time t > s . Withprobability n − X s n , miner a is not infected. In this case, the probability that he will becomeinfected assuming he randomly picks any of the n chain heads is X s n . Note that this probabilityis lower than the actual probability because block B may have already been confirmed by amilestone if the chain head of any of the X s infected miners’s is a milestone. Since we areconsidering an upper bound, we may assume X = 1 and X r = X s + 1 with probability X s ( n − X s ) n ,X s with probability 1 − X s ( n − X s ) n . (19)21e also introduce M s , which indicates whether or not B is confirmed by a milestone. So M = 0and M t = p X s n , − p X s n . (20)The above modeling gives a continuous-time Markov chain ( X t , M t ) and we are interested in theexpected time taken to hit the set { ( x, m ) : x, ≥ , m = 1 } . Let q x denote the expected jumpsneeded to hit the set starting from ( x, q x = 1 + (cid:16) − p xn (cid:17) (cid:18) x ( n − x ) n q x +1 + (1 − x ( n − x ) n ) q x (cid:19) , x = 1 , , · · · , n − ,q n = 1 p . Therefore, q = n X k =1 n pk − n ( p + 1) k + n ( p + 1) k k − Y j =1 ( pj − n )( j − n ) pj − n ( p + 1) j + n ( p + 1) < n (1 + ln( n )) + 1 p . Let τ := inf { t : M t = 1 } , the time needed for B to be confirmed by a milestone. Since blocksarrive at the rate nµ , which is exactly the rate for all jumps, the infection latency is W = E ( τ ) = 1 nµ q < n ) µ + 1 npµ . (21)Note that the second term in the above upper bound is basically the expected time it takes fora milestone to arrive, which is fixed. Another contribution to the infection latency comes fromln( n ) in the first term. Intuitively, the infection latency increases with the number of miners, n , due to parallelism. The relationship is better than linear in that it is a slow logarithmicincrease. Secure Latency.
After a block is confirmed by a milestone, we still need to wait for thismilestone to be extended by a number of future milestones for security guarantee. This isessentially the same latency that occurs in blockchain systems like Bitcoin. This type of latencywas analyzed in [6] in a simple model assuming honest miners will not fork among themselves.However, honest miners may fork among themselves due to broadcast delay because when anhonest miner creates a new block, he may not be aware of a recent block created by anotherhonest miner. A round-based model was formulated by [3] to handle this situation. Thesynchronization assumption is that whatever happened in the previous round will be madeknown to all honest miners in the present round so that they can act accordingly. However,such a model requires a worst-case scenario analysis and thus is too conservative for parameterselection. We now describe a continuous-time model to incorporate the broadcast delay function F and the potential forking among honest miners.Consider the arrival process of milestones created by honest peers. Let us call such milestones honest milestone blocks. The creation of honest milestone blocks is a Poisson process with rate22 nµ . Let U , U , U , . . . denote the inter-arrival times of milestones in this process. They areindependent and follow the exponential distribution with rate pnµ . Let us call the i th arrival milestone i . This milestone is chronologically the i th milestone created by the honest peers, butit may not be the i th milestone ever created in the network due to the exsitence of maliciousminers. We would like to tag milestone i with a value Y i ∈ { , } , for i = 1 , , . . . , in such away that if Y i = 1 then the creator of milestone i will have received all preceding milestonescreated by all honest miners upon the creation of milestone i . The tag Y i = 1 implies thatmilestone i must be higher than any previous milestone tagged with a 1 because the creator ofmilestone i is aware of all previous type-1 milestones when he is creating milestone i . Intuitively,being tagged with a 1 is a good signal and will likely lead to a height increment of the longestchain. It follows from our tagging method that, among all milestones of the same height in themilestone tree, at most one can be tagged with a 1 as illustrated in Figure 4, where * representsa milestone of type-0 or a milestone created by a malicious peer.* * 1 *1 * * 1 1 1* *1 height: k k + 1 k + 2 k + 3 k + 4 k + 5 k + 6 Figure 4: Illustration of Tags in the Milestone TreeThe first arrival is tagged with a 1, i.e., Y = 1, as it is the first milestone created by honestpeers after the genesis O . Let us now think about then circumstances in which a future honestmilestone, say milestone i , may be tagged with a 0. Consider the case where its precedinghonest milestone is tagged with a 1, i.e., Y i − = 1. If the inter-arrival time between milestone( i −
1) and milestone i , U i , exceeds t , then the honest miner who creates milestone i willhave certainly received all honest milestones. Suppose U i = t ∈ (0 , t ), then according to thebroadcast delay assumption, the honest miner who creates milestone i have probability F ( t ) ofhaving received milestone ( i −
1) and thus all preceding honest milestones. So milestone i willbe tagged with a 1 with probability F ( t ). In general, let Z i be a Bernoulli random variable withsuccess probability P ( Z i = 1) = Z t F ( t ) pnµe − pnµt dt + e − pnµt . Milestone i will be tagged with a 1 if Y i − = 1 and Z i = 0. Now consider the case where thepreceding honest milestone is tagged with a 0, i.e., Y i − = 0. We would like to be conservativeby tagging milestone i with a 0 whenever U i < t . In this case, only when the inter-arrival time U i exceeds t can we be sure that the honest miner who creates milestone i has received all23receding honest milestones and we will then tag milestone i with a 1. Mathematically, Y i = , if ( Y i − = 0 and U i ≤ t ) or ( Y i − = 1 and Z i = 0) , , otherwise. (22)The milestone chain evolves as follows. First, a number of milestones are tagged with a 1meaning the longest milestone chain will grow whenever an honest peer produces a milestone.When the first type-0 milestone arrives, it may be of the same height as a previous type-1milestone, and thus it could potentially lead to forks. Once a type-0 milestone arrives, all newlyarriving milestone blocks will be regarded as useless until another milestone tagged with a 1arrives, the height of which will exceed that of any milestone previously mined by honest peers.Beyond that point in time, the regenerative cycle restarts. This is a conservative model, becauseafter a typ-0 milestone arrives, the miner of some subsequent milestone with inter-arrival timeless than t may be informed of all preceding honest milestones if he is lucky enough, but aninter-arrival time greater than t will ensure that he will be informed.In each regenerative cycle, the milestones tagged with a 0 can be regarded as wasted. Actu-ally, we can consider the wasted milestone as if they were created by malicious miners. In otherwords, the effective hashing power of honest miners should be discounted by the proportion ofthe blocks tagged with a 1 in a cycle. In each cycle, the number of blocks tagged with a 1 followsthe geometric distribution with success probability R t (1 − F ( t )) pnµe − pnµt dt and the number ofblocks tagged with a 0 is geometric with success probability e − pnµt . Thus, the long-run averageproportion of milestones tagged with a 1 can be estimated as e − pnµt e − pnµt + R t pnµ (1 − F ( t )) e − pnµt dt . If pnµ = 0 . /s , t = 2 s and F ( t ) = t − t /
4, then the above fraction will be 0 . × . × . , − − − − Secure Latency T F a il u r e F r e q u e n c y
10% adversary30% adversaryFigure 5: Failure Frequency based on Simulation of 10 Sample Paths24lternatively, we can perform simulations based on our model to determine how long thesecure latency needs to be in order to ensure a given level of security. Suppose a milestone B m is created at time t , and is still part of the longest chain in the local DAG of some honestpeer after a period of time T . We want B m to be in the longest milestone chain from everyhonest peer’s perspective and to stay in the longest chain thereafter with a high probability.Suppose at time t + T , milestone B m is on the currently longest chain C of one honest peer,and there exists another honest peer adopting a chain C which does not contain B m . Considerthe type-1 arrivals during [ t + t , t + T − t ], all of them are higher than B m and are receivedby all honest peers by t + T . Suppose that B is one of them and is of height h > η ( B m ). Both C and C have a block of height h , say B and B respectively, since both peers have received B and C and C are the longest chain from each peer’s own point of view. In addition B = B as both of them are higher than B m but only B extends B m . Hence either B = B or B = B or both are true. Therefore the number of 1s during [ t + t , t + T − t ] is less than the totalnumber of 0s plus the number of milestones created by malicious miners during [ t, t + T ]. Theprobability of this event is low when T is sufficiently large and decays rapidly with respect to T as shown in our simulation results in Figure 5. To be on the conservative side, we start oursimulation with the first tag being 0, which is stochastically a worse initial condition. It can beseen from the figure that we have to wait 130 seconds and 810 seconds assuming 10% and 30%of the hashing power comes from malicious miners, respectively, to ensure a failure frequencyof less than 10 − . We use pnµ = 0 . /s , t = 2 s and F ( t ) = t − t / Discussion on Parameter Selection
We now summarize the above analysis, and providea concrete example demonstrating parameter selection and its corresponding performances.We assume that there are n = 1000 honest miners in the system, with each miner creatingblocks at the rate µ of 1.2 blocks per second. We also assume that the mempool assignmentparameter c = 0 .
01 in (12). So the max TPS of the design is approximately 0 . nµ = 1179 . − θ ( c ) = 0 .
983 according to (16).The total latency is W = W + W + W , where W is the queueing latency, W is theinfection latency and W is the secure latency.By assuming that transactions arrive at the rate λ of 1000 per second, the queueing latency W is approximately 188 seconds according to (17). We further assume that the expectationof the inter-arrival time of milestones is 1 /pnµ = 10 seconds (i.e., p = 1 / W is approximately 23 seconds according to (21). If we use the broadcastcurve F ( t ) = t − t / t = 2 and ¯ t = 5 /
3. Suppose also that less than 30%of hashing power comes from malicious miners. If we want to ensure that the probability of asuccessful attack is less than 10 − , then W is 810 seconds according to the simulation shownin Figure 5. So the total latency W is approximately 1021 seconds or just over 17 minutes.25 eferences [1] Vivek Bagaria, Sreeram Kannan, David Tse, Giulia Fanti, and Pramod Viswanath. De-constructing the blockchain to approach physical limits. arXiv preprint arXiv:1810.08092 ,2018.[2] Jing Chen and Silvio Micali. Algorand. arXiv preprint arXiv:1607.01341 , 2016.[3] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Anal-ysis and applications. In Advances in Cryptology - EUROCRYPT , pages 281–310, Berlin,Heidelberg, 2015. Springer.[4] Donald E. Knuth.
The art of computer programming. Vol. 1 . Addison-Wesley, Reading,MA, 1997.[5] Chenxing Li, Peilun Li, Wei Xu, Fan Long, and Andrew Chi-chih Yao. Scaling nakamotoconsensus to thousands of transactions per second. arXiv preprint arXiv:1805.03870 , 2018.[6] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. https://bitcoin.org/bitcoin.pdf .[7] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder.
Bitcoin and cryptocurrency technologies: a comprehensive introduction . Princeton Univer-sity Press, 2016.[8] Rafael Pass and Elaine Shi. Thunderella: Blockchains with optimistic instant confirma-tion. In
Annual International Conference on the Theory and Applications of CryptographicTechniques , pages 3–33. Springer, 2018.[9] Serguei Popov. The tangle. cit. on , page 131, 2016. https://iota.org/IOTA_Whitepaper.pdf .[10] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin.In
International Conference on Financial Cryptography and Data Security , pages 507–527.Springer, 2015.[11] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger.
Ethereumproject yellow paper , 2014. https://ethereum.github.io/yellowpaper/paper.pdfhttps://ethereum.github.io/yellowpaper/paper.pdf