DEXON: A Highly Scalable, Decentralized DAG-Based Consensus Algorithm

11/19/2018 ∙ by Tai-Yuan Chen, et al. ∙ 0

A blockchain system is a replicated state machine that must be fault tolerant. When designing a blockchain system, there is usually a trade-off between decentralization, scalability, and security. In this paper, we propose a novel blockchain system, DEXON, which achieves high scalability while remaining decentralized and robust in the real-world environment. We have two main contributions. First, we present a highly scalable sharding framework for blockchain. This framework takes an arbitrary number of single chains and transforms them into the blocklattice data structure, enabling high scalability and low transaction confirmation latency with asymptotically optimal communication overhead. Second, we propose a single-chain protocol based on our novel verifiable random function and a new Byzantine agreement that achieves high decentralization and low latency.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Blockchain systems are being challenged to demonstrate rigorous robustness and high performance in real-world situations. Many applications demand low transaction confirmation latency and high transaction throughput. However, most blockchain systems do not satisfy these criteria. For example, the confirmation latency of Ethereum is about 5 to 10 minutes and the throughput is limited to about 30 transactions per second. By contrast, some blockchain systems achieve high performance but sacrifice the robustness of the systems. For example, EOS is operated with only 21 supernodes, and is vulnerable to DDoS attacks.

We propose a novel blockchain framework, DEXON, which achieves high performance and remains robust on the real-world Internet. To this end, we design a data structure, called blocklattice, which allows numerous single chains to grow concurrently. Then, we propose a novel method to integrate these single chains into a globally-ordered chain without additional communication.

The blocklattice structure is a directed acyclic graph (DAG) that consists of many single chains. The blocks in the different chains acknowledge (ack) each other and collectively form this DAG structure. We use the total ordering algorithm to achieve consensus on the blocklattice so that all users are guaranteed to have the same view of the ordering of all the blocks. Because the single chains can grow concurrently, the throughput of DEXON can be easily scaled up.

We also propose our single-chain protocol, which is based on Algorand [GHM17] but with some minor improvements. The Algorand consensus protocol is a breakthrough that allows millions of nodes to join the protocol; each node has fair opportunity to propose and validate blocks. For this protocol, we present a new verifiable random function and Byzantine agreement achieving low confirmation time even for a large population of nodes. We emphasize that our blocklattice structure with its total ordering algorithm is a generic framework that applies to any kind of single-chain protocol. Thus, if the throughput of the underlying single-chain protocol increases by a factor of , the total throughput of the whole system also increases by a factor of .

1.1 Main Features of DEXON

DEXON has the following advantages:

High Scalability

Most blockchain solutions are not able to scale their throughput even with increased resources. Our blockchain system can adjust the number of chains dynamically while preserving the same latency. The throughput of our system is only bound by the available network bandwidth and computational power. In addition, the scaling methodology of the DEXON consensus is generic. That is, the blocklattice structure with its total ordering algorithm can be applied to any kind of single-chain consensus protocol.

Low Latency

Latency is the amount of time from block proposal to confirmation. Therefore, latency is one of the paramount properties for any blockchain. We propose a fast Byzantine agreement that is expected to terminate in time, where is the upper bound of the network’s gossip period. The DEXON consensus algorithm achieves second-level latency instead of traditional minute-level latency as exhibited by blockchains such as Ethereum or Bitcoin. A second-level latency blockchain opens a new era that provides numerous variations in service that cannot be delivered by traditional blockchains.

High Decentralization

The DEXON consensus is based on “proof-of-participation (PoP)”; that is, every node has equal chance to propose a block. We adopt a verifiable random function (VRF) to decide who can issue a block; this serves to minimize the communication cost so that a large population can join the protocol.

Transaction Ordering Fairness

In traditional blockchain systems, a single proposer can determine the transaction ordering; this makes traditional blockchain systems vulnerable to front-run attacks. By contrast, in the DEXON consensus algorithm, no single block proposer can determine the consensus timestamp of a proposed block.

Unpredictable Randomness

Randomness is often a desired functionality in various smart contracts such as decentralized applications (DApps), particularly gaming DApps. Normally, a blockchain system cannot generate unpredictable randomness on-chain, so DApp developers must rely on some trusted third party for random input, such as the service provided by Oracalize. However, the DEXON consensus generates on-chain unpredictable randomness on the fly as it achieves consensus. Once a block has been confirmed by the DEXON Byzantine agreement, a committee of nodes generates a threshold signature, which is an unpredictable value. Thus, the hash of the signature serves as the unique, unpredictable, and unbiased randomness of the block.

Explicit Finality

In blockchain systems based on proof-of-work, such as Bitcoin or Ethereum, transaction confirmation is probabilistic. Only after users have waited for a long sequence of block confirmations can a transaction be considered as probabilistically finalized

; the system is thus vulnerable to double spending attacks. For use cases such as payment networks, an explicit finality with probability 1 is necessary. In the DEXON consensus, every transaction is confirmed to be finalized with probability 1 and is secured by DEXON’s Byzantine agreement algorithm, which has been proven correct with rigorous mathematical logic.

Low Communication Overhead

A two-phase-commit consensus algorithm has an communication complexity in any -node setting and is thus highly costly to scale up. The DEXON consensus adopts VRF to reduce the amount of nodes joining the protocol from parties to . Thus, the communication cost is reduced from to . In this situation, the number of nodes can be scaled to millions while maintaining only hundreds of nodes that must communicate with each other.

Energy Efficiency

DEXON Consensus has asymptotically optimal computation overhead, making it highly energy efficient.

Low Transaction Fees

The transaction fees of a typical blockchain increase when the blockchain network is congested. The DEXON consensus is highly scalable and has low communication overhead, which enables it to maintain the lowest possible transaction fees in large-scale deployments.

When designing a blockchain system, a trade-off usually exists between decentralization, performance, and safety, which we call the trilemma problem in blockchains. For example, EOS and Hashgraph achieve high performance, but they are operated by few supernodes and are vulnerable to DDoS attack. By contrast, Algorand is decentralized and has robust safety, but its throughput is limited.

In DEXON, we balance the requirements of the trilemma. DEXON has scalable transaction throughput and low confirmation latency. However, DEXON remains highly decentralized and robust in practical deployment environments.

1.2 Related Work

Proof-of-Work Bitcoin [Nak08] is the first blockchain protocol whose consensus delivers Nakamoto consensus: This means that the Bitcoin system solves a mathematical puzzle as a proof to generate next block, and once a block has been followed by six continuous blocks, the block is confirmed. This mechanism causes Bitcoin to have a latency of approximately one hour. Even more problematically, proof-of-work-based consensus consumes exorbitant quantities of energy.
Proof-of-Stake Numerous proof-of-stake consensus systems [GHM17, HMW, BHM18, DGKR18] have been proposed in recent years. In these schemes, the nodes with adequate stakes have the right to propose their blocks. The probability that a node can propose a block is proportional to the stakes the node owns.
DAG-based consensus Phantom, SPECTRE, IOTA, Conflux, and Mechcash are DAG-based consensus systems, all of which are, at their core, variants of the Nakamoto consensus. This leads two disadvantages: first, these systems demonstrate low performance (throughput is low and latency is long); second, the finality is probabilistic, allowing some attacks (such as selfish-mining) to exist. To conclude, constructing a DAG-based consensus with the Nakamoto consensus limits performance and safety.
Algorand is a breakthrough proposed by Gilad et al. [GHM17], that reduces the communication complexity from to

and thus supports large population of nodes (e.g. 500K nodes). They use a verifiable random function (VRF) to protect nodes from DDoS attack, and the VRF is also a lottery that decides which node has the right to propose a block or to vote for each round of their Byzantine agreement protocol. The consensus of Algorand is based on Byzantine agreement among samples from the whole set of nodes. Thus, the probability of the correctness of whole system is based on hypergeometric distribution. This is the reason why Algorand can only tolerate less than one third of total number of nodes to be malicious while Algorand achieves high decentralized.


Dfinity [HMW] is a permissioned blockchain and is designed for large population of nodes (around 10K nodes). Dfinity contains a randomness beacon which generates new randomness by a VRF with information from new confirmed block. They use the output of a VRF to select a leader and electors for a round. By hypergeometric distribution, Dfinity only samples hundreds of nodes to notarize a block instead of using all nodes, and the correctness holds with high probability.
The consensus of Hashgraph [BHM18] adopts Byzantine agreement on a graph and their round-based structure costs a latency of for each round of Byzantine Agreement, which means its confirmation time increases with the number of nodes. This limits the decentralized level of Hashgraph.

Roadmap

In Section 2, we introduce the cryptographic primitives and the system model used in this paper. In Section 3, we formally introduce our Byzantine agreement protocol and describe how to build up a single chain by our Byzantine agreement protocol. In Section 4, we introduce how DEXON reaches a consensus on a blocklattice by using its total ordering algorithm. Finally, we discuss the sharding scheme and the method to adjust system parameters in Section 5.

2 Preliminaries and Model

2.1 Cryptographic Primitive

In this section, we introduce the cryptographic primitives used in this paper, including our hash function, digital signature, threshold signature, and verifiable random function.

Hash Function and Digital Signature

In this paper, we model the hash function as a random oracle. That is, the hash function acts as a truly random function which can only be accessed by “querying” an oracle. We also assume that an unforgeable digital signature is available. We define to be the signature of the message signed by the secret key .

Threshold Signature

Let be the number of parties. A -threshold signature scheme allows arbitrary parties to sign a message and any party with the public key can verify the threshold signature. A threshold signature scheme consists of five probabilistic polynomial-time algorithms:

  • KeyGen(): a distributed key generation algorithm takes as input a security parameter , and outputs a public key , a set of verification keys , and the secret key for each party .

  • ShareSign(): a share signing algorithm takes as input a message and a secret key . It outputs a signature share .

  • Verify-ShareSign(): a share verification algorithm takes as input a message , the verification key and a signature share on from the party . It outputs if is valid and outputs otherwise.

  • Combine(): a share combining algorithm takes as input a message , the public key , the set of verification key and verified signature shares on the message where is a subset of such that . It outputs a threshold signature .

  • Verify-TSign(): a signature verification algorithm takes as input a message , the public key , and a threshold signature . It outputs if is valid and outputs otherwise.

It is required that except with negligible probability, Verify-ShareSign holds for any party . It is also required that except with negligible probability, Verify-TSign holds, where is the threshold signature of valid signature shares for any subset .

For the security definition, one can refer to [LJY14].

Verifiable Random Function

Let be a pair of a public key and a private key. Verifiable random function (VRF) is a kind of pseudo-random function such that only a user that has can compute the function whereas anyone can verify the validity of the function evaluation by and public information. Typically, a VRF consists of the following algorithms:

  • KeyGen(): a probabilistic polynomial time algorithm takes as input a security parameter , and generates a public key and private key pair .

  • VRF(): a deterministic algorithm takes as input the private key and an initial value , and outputs verifiable random value .

  • Prove(): a deterministic algorithm takes as input the private key and an initial value , and output the proof of correctness .

  • Verify(): a deterministic algorithm verifies the validity of the VRF using the proof .

For the correctness and security of VRF, we refer to [MRV99, DY05].

2.2 Terminology and System Model

Terminology

In DEXON, an user is uniquely identified by its public key and secret key pair. All users can transfer and receive the stakes from other users. They can also verify the correctness of the blockchain. Our blockchain is maintained by a special set of users where the members of are called nodes. We define two special sets of nodes: the CRS set and the notary set (a node can be in two sets at the same time). The nodes in and are crucial for our single chain algorithm, which will be explained in Section 3.

A node can pack a batch of transactions into a block. In our single chain algorithm, we say a node proposes a block if the block is a candidate that can be selected by our Byzantine agreement protocol. We say a node issues a block if the block is selected and becomes a block in the single chain.

System Model

We assume the adversary can corrupt the nodes adaptively. That is, the adversary can choose which nodes are corrupted during the protocol. The corrupted nodes are called Byzantine and the nodes that are not corrupted are called correct. A Byzantine node can deviate from the protocol arbitrarily; it can engage in problematic malfunctions such as sending conflicting messages, violating algorithm criteria, delaying the messages between other nodes, and so on. We also assume the adversary has full control of the network. The adversary can learn all the messages delivered on the network and determine the delay and the order of the delivered messages.

If the adversary does not delay any messages between the correct nodes, we assume the network is weakly-synchronous. That is, there exists a known time bound for the messages between any two correct nodes. We say the network is partitioned if the messages between the correct nodes are delayed such that the delivering time exceeds .

3 Single Chain

In this section, we introduce how a set of nodes build an agreed single chain. In short, the members in generate a public randomness. Then, for each height of the single chain, the members in propose their blocks. Then, they try to reach an agreement regarding who is the leader for that height and all nodes adopt the leader’s proposal for the next block. As long as all the correct nodes can agree on who is the leader for each height, they can build up an agreed blockchain.

In Section 3.1, we introduce two useful primitives for Byzantine agreement protocol: common reference string and verifiable random function. In Section 3.2, we introduce our Byzantine agreement protocol based on leader election. Finally, we formally describe how to build a single chain in Section 3.3.

3.1 Common Reference String and Verifiable Random Function

In this section, we introduce two useful primitives for building a single chain: common reference string (CRS) and verifiable random function (VRF).

Common Reference String

An epoch

consists of a specific number of blocks. The CRS in our setting is actually a public randomness generated by a deterministic algorithm for each epoch; no user in the system can predict the CRS of any future epoch. In our setting, the CRS of epoch

is updated by , where is a threshold signature function whose input is some set of share-signatures produced by the nodes in of epoch .

This method is similar to DFinity [HMW], but their system categorizes the group when users join the system. We emphasize that the users in their system have a high incentive to be malicious because each group has non-negligible probability to have the right to propose a block and compute the randomness. However, our system selects CRS nodes to compute the randomness according to results from a previous epoch.

Verifiable Random Function

The verifiable random function introduced by Micali, Rabin and Vadhan [MRV99] is a type of pseudorandom function by which anyone can verify the validity of the function evaluation from public information. Several practical VRFs have been proposed [DY05, GHKW17] and most of them are based on bilinear functions. Algorand [GHM17] and Ouroboros Praos [DGKR18] have demonstrated that VRF is a powerful primitive for achieving cryptographic sortition in blockchains. Our system works with PKI; each user can access all other users’ public keys (preregistered in previous blocks) and user computes the verifiable random function as:

(1)

where is CRS of epoch and is public information. Thus, is verifiable with ’s public key and unpredictable.

Our VRF has three benefits compared to the VRF in Algorand. First, our design is fairer. The verifiable random function used in Algorand is , where is the randomness from the previous block. Whether an adversary can choose to propose a block depends on the randomness of that adversary’s block. If the randomness is beneficial for Byzantine nodes (e.g. higher probability of proposing the next block), then the adversary proposes the block. Thus, the overall advantage of the adversary increases up to . The main problem is that the proposer decides the block and the randomness at the same time. Therefore, we separate the permission of proposing a block and generating the randomness in order to avoid such bias attacks. Second, our design is more flexible to compute because each user can compute part of the VRF for any status at any time, say, . At the beginning of each epoch, any user can get the CRS of the epoch and compute the probability of proposing a block in the epoch. However, Algorand’s VRF requires to compute . Third, our design has better space consumption. In Algorand, each block must store the randomness for VRF, but our design uses the same randomness for many blocks in one epoch. Thus, the space complexity is reduced by a constant.

A further optimization is only to update CRS when new users join. Then, the space complexity is reduced to a constant value that is independent of the number of blocks.

3.2 Byzantine Agreement

The Byzantine general problem was introduced by Lamport, Shostak, and Pease [LSP82]; it allows a set of nodes to agree on a single bit where some of the nodes may be malicious. Recently, Chen et al. [CGMV18] proposed a Byzantine agreement protocol based on leader election, which achieves fast agreement in a synchronous network, upholds safety in an asynchronous network, and recovers from any partition rapidly.

Now, we introduce our Byzantine agreement protocol, which is based on Algorand’s protocol but includes some minor improvements. In DEXON, each single chain is maintained by a notary set . Thus, only the members in are involved in the Byzantine agreement protocol. Let be the number of nodes in and be the number of Byzantine nodes in .

Comparing to Algorand, our leader election procedure is independent of the round index, so the nodes are not required to propose their values at each round. Consequently, except for the first round, the running time of each round reduces to . Also, if no partition is present, our protocol terminates in rounds in the worst case and can be expected to terminate in rounds.

Let , denote the CRS at epoch and denote the set of values that can be decided. We also define two special values and SKIP that are not in . For each node , has four internal variables: records the index of the round at which is working, records the candidate value that supports, records the index of the round from which comes and is ’s local clock. Let and denote the secret key and public key of , respectively. We define status to be the public predictable information of the block (e.g. shard ID, chain ID, block height). For the leader election, each node computes the signature with its secret key . We define three kinds of messages:

  1. the initial message of the node :

  2. the pre-commit message of the value from the node at the round :

  3. the commit message of the value from the node at the round :

With these notations, we introduce the leader election algorithm which will be a subroutine of our Byzantine agreement protocol. Let denote the set of initial messages that the node receives from other nodes. The node verifies the signatures in and sets to be the set of nodes whose signatures are valid. Then, computes

We say is the leader of .

Our Byzantine agreement protocol (Algorithm 1) is a round-based protocol. Initially, for all correct nodes , initializes its internal variables by , , and and also chooses its initial value .

Our protocol has four steps in each round. At Step 1, all the nodes gossip their own initial value in the format .

When , enters Step 2. If , verifies the initial messages it receives and computes the set of nodes whose signatures are valid. If , identifies its leader and pre-commits ’s value; otherwise, pre-commits . If , node pre-commits . We say node pre-commits on a value if node gossips the message where is the round number that node is working at.

When , node enters Step 3. If node has seen pre-commit messages of the same value at round , node updates and and commits . Otherwise, node commits SKIP. Note that node must commit some value at Step 3. We say node commits on a value if node gossips the message where is the round number that is working at. After node gossips the commit message, enters Step 4, at which waits for the forward conditions.

Suppose a node is working at round . The node updates its internal variables as soon as one of the following conditions holds:

  1. If node has seen pre-commit messages of the same value at the same round such that , sets and .

  2. (forward condition) If node has seen pre-commit messages of the same value at the same round such that , sets , , and starts the round from Step 2.

  3. (forward condition) If the node has seen commit messages of any value at the same round such that , sets and starts the round from Step 2.

We say that node achieves the forward condition, if the condition 2 or the condition 3 holds. Node goes into the next round immediately if it achieves the forward condition even if it does not achieve the forward condition at Step 4.

Node decides on a value as soon as node has seen commit messages of the same value at the same round .

The protocol for a node is summarized as Algorithm 1.

Procedure DEXON_Byzantine_Agreement for node q
       Input : an initial value from node and the public key from all nodes
       Output : an agreed value from some node
       Initialize , , and Step  1: when ,
             gossip
      
      Step  2: when ,
             if  and  then
                   node identifies its leader at ’s current view
                   gossip
            
            else if  and  then
                   gossip
            
            else
                  gossip
            
            
      
      Step  3: when ,
             if node has seen pre-commit messages of the same value at round  then
                  
                  
                   gossip
            
            else
                  gossip
            
            
      
      Step  4: when
             wait until the forward condition is achieved
      
      
Algorithm 1 Synchronized Byzantine Agreement Algorithm

3.2.1 Agreement

We first show that our protocol will reach agreement; that is, all the correct nodes will decide on the same value.

Lemma 3.1.

Assume . Suppose a node receives commit messages of and another node receives commit messages of . If both these commit messages all come from the round , then .

Proof.

We prove this lemma by contradiction. Suppose . Because as many as Byzantine nodes exist, there exists at least one correct node that both commits on and by the pigeonhole principle. However, correct nodes can only commit on one value at one round, which leads to a contradiction. ∎

Theorem 3.2 (Agreement).

Assume . Regardless of partition, if a correct node decides on some value and a correct node decides on some value , then . That is, the correct nodes will never decide on different values.

Proof.

Because decides on and decides on , and must see commit messages of and commit messages of , respectively. Suppose both these commit messages come from the same round . By Lemma 3.1, we have .

Suppose the commit messages that receives come from the round and the commit messages that receives come from the round . Without loss of generality, we assume . Because there are up to Byzantine nodes, there must be at least correct nodes commit on so that can receive commit messages of . For all rounds , these correct nodes will always pre-commit on until they see pre-commit messages of at Step 3. However, only nodes remain, so these correct nodes will never pre-commit any for all . Thus, for all , if some value has pre-commit messages, then .

Because receives commit messages of , there must exist at least correct nodes that commit on at the round . These correct nodes commit on only if they have seen pre-commit messages of at round . Therefore, . ∎

3.2.2 Termination

We now analyze when the algorithm terminates if no partition exists or if the system recovers from a previous partition.

Proposition 3.3 (Termination without partition).

Assume . If all the correct nodes start at the -th round within time and no partition exists, all the correct nodes will decide on some values in rounds.

Proof.

Case 1: Some correct node has decided. If a correct node has decided on value , must have seen commit messages of . Because propagates these commit messages, all the correct nodes will hold this information after time and decide on in one round.

Case 2: Some correct node has seen pre-commit messages. Suppose no node has decided but there exists a correct node that has seen pre-commit messages of a value . Because propagates these pre-commit messages, all the correct nodes will hold this information after time . Thus, all the correct nodes will commit so that they can reach an agreement on .

Case 3: No correct node has seen pre-commit messages. Because no correct node has ever seen pre-commit messages, for all correct node . Thus, they will identify their own leader by their local view and by the leader’s pre-commit value. Because all correct nodes start at the -th round within time , they can receive all the initial values from other correct nodes before identifying the leaders. Thus, there exists some correct nodes that pre-commit different values relative to each other only if a Byzantine node proposes different initial values to different nodes111Note that not proposing any initial value is considered to be equivalent to proposing .. However, the correct nodes will propagate the initial value so all correct nodes will have the same set of initial values after time . Thus, to prevent the correct nodes from agreeing on the same leader, Byzantine nodes must propose different initial values to different nodes at every round. However, a node can only propose an initial value once or it will be caught. Thus, the best strategy of Byzantine nodes is that different Byzantine nodes propose their initial values at different rounds so Byzantine nodes can only interfere during rounds. Thus, all the correct nodes will decide on some values in rounds with certainty. ∎

Proposition 3.4.

Assume . Suppose all correct nodes start at -th round within time and no partition exists. Then, it is expected that all correct nodes will decide on some values in rounds.

Proof.

From the proof of Proposition 3.3, we know that if some correct node has decided on a value or has seen pre-commit messages of a value , then all the correct nodes will decide on in one round.

In a network without partition, the best strategy for the Byzantine nodes has been described in Case 3 in the proof of Proposition 3.3. However, to interfere with rounds successfully, the Byzantine nodes must win the leadership 222Notice that the leader is the node with the lowest value . in the following rounds. The probability of such an event is

Thus, in expectation, the number of interfered rounds can be upper-bound by

Because , the expected number of interfered rounds is less than . After an interfered round, all the correct nodes will decide in the next round, so it is to be expected that they will all terminate in rounds. ∎

Proposition 3.5 (Termination when the partition is resolved).

Assume . If the partition is resolved, all the correct nodes will decide on some values in round. It is to be expected that all correct nodes will decide on some values in rounds.

Proof.

If there exists a node that has decided on a value , must have seen commit messages of . All the correct nodes will receive these commit messages of within time after the partition is resolved and decide on .

Suppose no node has decided and is the node working on the latest round . To enter the round , must achieve the forward condition at round . Because the partition is resolved, all correct nodes will also achieve the forward condition within time after the partition is resolved and also enter the round . Later on, if some node achieves the forward condition and enters the round , other correct nodes will also achieve the forward condition within time . Thus, all correct nodes start at the round with time difference and Proposition 3.3 guarantees that they will decide on some values within the following rounds. Similarly, it is to be expected that all correct nodes will decide on correct values in rounds. ∎

3.2.3 Communication Complexity

We now analyze the communication complexity of a single node for a single round. Because a correct node will help to propagate the messages, all correct nodes will gossip messages in a single round. Thus, the communication complexity for all nodes is in a single round.

As discussed in Section 3.2.2, if no partition exists or the system recovers from a partition, our Byzantine agreement protocol terminates in rounds in the worst case and is expected to terminate in rounds. We assume , so the protocol terminates in rounds in the worst case and is expected to terminate in rounds. Therefore, the total communication complexity of the protocol is in the worst case and in the expected case.

3.3 Consensus on a Single Chain

In this section, we describe how to build up a single chain by Byzantine agreement protocol. Our single chain protocol has four parts: system setup, registering public key, proposing block, notarizing blocks and updating epoch.

Overview

The members in are responsible for updating the CRS. The members in have right to propose a block and are responsible for running the Byzantine agreement protocol to decide whose block can be chosen for the single chain.

When the members in reach an agreement of a block, they sign their respective signature shares of the agreement. The block proposer of the next block has to verify these signature shares and combine them into a threshold signature . The threshold signature should be stored in the next block. If someone tampers the content of a block, the hash of the block changes and become inconsistent with the threshold signature in the next block. Because it is infeasible to forge the threshold signature, the integrity of the blocks is guaranteed.

The members in and are re-elected for each epoch. Each epoch corresponds to a randomness of CRS. When is re-elected, the members in will update the CRS for the next epoch.

Registering Public Key

Any user with enough deposit can register its own public key in the chain. The users who want to enter or leave can announce the request. The request will be recorded in the blocks. The node is called valid if it owns enough deposit333To avoid nothing-at-stake problem, the node who wants to register its public key needs to lock its deposit. In practice, this can be done by smart contracts. and has registered a valid public key. Let denote the snapshot of the whole system at the first block of the epoch . Let denote the set of all valid nodes in . The set can be updated by and the blocks in the epoch .

Proposing Blocks

Only the nodes in can propose new blocks. To propose a block, a node computes the hash of the block and takes as the initial value for the Byzantine agreement protocol. Note that node can send the hash of the block to join the BA scheme as early as possible, but has to propose the complete block immediately so that other nodes can determine the block and commit it.

A node is allowed not to propose any block. Because the leader election is determined by the public predictable information , and the secret keys, the node can compute the value locally. If the value is too large, is unlikely to be chosen as the leader so it may give up the chance to propose the block.

Practically, we can set a threshold of proposing a block. That is, the node will propose a block if and only if . Suppose is the number of nodes in . Then, the probability that at least one node proposes a block is . Choosing , the probability is larger than . If no one proposes a block, all the correct nodes will pre-commit and they will soon decide on . Thus, the protocol will not halt. All the correct nodes can agree on an empty block and start the protocol for the next block soon.

Notarizing Blocks

The nodes in are responsible for running the Byzantine agreement protocol (Algorithm 1) to decide the next block of the chain. As shown in Section 3.2, as long as there is no partition, the members in can reach an agreement even if they do not start within time .

To notarize a block, we choose a -threshold signature scheme. When a node decides on some value for the block with height , node signs a signature share by its secret key 444Note that the key pair for the threshold signature is different from the key pair that the node registers on the block. and announces . The block proposers of the next block (of height ) have to verify at least signature shares for the block with height and combine the signature shares into a threshold signature . The threshold signature should be packed into the next block. We say a block with height is notarized if its threshold signature is packed in the next block and the next block is issued.

Assume the number of Byzantine nodes is up to . Then, anyone can make sure the block with the hash is notarized by if more than nodes in have signed on . To verify the fact, we only need to check whether the block hash matches the threshold signature stored in the next block and verify whether is valid or not.

Updating Epoch

The members in and are re-elected for each epoch. Let and denote the CRS set and the notary set of the epoch .

The set , the set , and the randomness are decided before the epoch starts. When the epoch starts, the members in generate the randomness by

where is the threshold signature signed by the nodes in . After is decided, the set and the set can be elected by Fisher-Yate shuffle with the randomness from the set . Finally, the members in and run the key generation algorithm of the threshold signature scheme, respectively.

The timeline of building a single chain is summarized in the Figure 1.

Figure 1: The consensus of a single chain

4 Blocklattice

In DEXON, the blocklattice arises from numerous single chains and the ack information in the blocks of those chains. We introduce the total ordering algorithm on the blocklattice to produce a globally-ordered chain, called the compaction chain.

In this section, we first present our main algorithm to compact the proposed blocklattice into the compaction chain and then to generate the timestamp for each block in the compaction chain. For the compaction, we introduce a basic total ordering algorithm in Section 4.2. In Section 4.3, we present our timestamping algorithm that ensures the unbiased consensus timestamp of blocks in the blocklattice, which is close to real-world time. We present the consensus on a blocklattice in Section 4.4.

4.1 Notation

Let be the set of chains and be the set of chains which contains the blocks from Byzantine nodes in the DAG, whose maximum capacity is limited by . Let denote the set of pending blocks, which means the block is received by a node and has not been output into the compaction chain.

When a block follows another block , we call this relation acks . Let be the set of candidate blocks that only ack the blocks that are already in the compaction chain. Informally, denotes the set of preceding candidate blocks that have higher priority than other candidate blocks, which corresponds to the “source message” in the TOTO protocol [DKM93].

We use the subscript to denote a set or function in ’s local view, for example, is the candidate set in ’s local view. We use to denote the -th block from node . We define indirect ack by the transitive law of ack: if a block acks another block through the transitive law of ack, then we say indirectly acks . For example, if acks and acks , indirectly acks . An example is provided in Figure 2.

Figure 2: A simple example illustrates the notation: , . Also, acks and . Both and indirectly ack .

Next, we present the definition of specifications of our total ordering algorithm as the following:

  1. Correctness: all non-Byzantine nodes will eventually generate the same ordered chain.

  2. Liveness: the system will not halt with up to Byzantine nodes, and every block will eventually be finalized.

For a formal definition, we follow the specifications in [DSU04].

4.2 DEXON Total Ordering Algorithm

First, we introduce the DEXON total ordering algorithm, which ensures that the blocklattice data structure can be compacted into the compaction chain. The DEXON total ordering algorithm is described with a parameter ; it can be seen as the threshold of the output criterion. We set to guarantee the liveness of the total ordering algorithm. In this scenario, a problem arises: each node receives all block information asynchronously, thus, the order of blocks from the blocklattice cannot be decided directly by the receiving times. Therefore, we introduce the DEXON total ordering algorithm; it is a symmetric algorithm and it outputs the total order for each valid block.

The DEXON total ordering algorithm is based on [DKM93], which is a weak total order algorithm [DSU04]. The main idea of the DEXON total ordering algorithm is to dynamically maintain a directed acyclic graph (DAG) from the received blocks. More precisely, each vertex corresponds to some block and each edge corresponds to some ack relation between blocks. Intuitively, once a block in the graph obtains enough acks from other blocks, the algorithm outputs the block.

Before we state the algorithm, we will first introduce some functions and properties for the algorithm. We use the following three functions as potential functions that evaluate the quality of each candidate block in order to decide the output order.

  1. Acking Node Set, , is the set of nodes that issued blocks ack block in node ’s local view. Moreover, the global Acking Node Set for node is defined by .

  2. is the

    Acking block-Height Vector

    of block in node ’s view, defined as:

  3. is the number of integer elements in .

Next, we define two functions,

and

where is the local view of in the future. That is, the pending set becomes , where consists of all the probable blocks received by in the future. The function outputs the three possible relations between block and in the future: the first possibility is , which means block always precedes block regardless of arbitrary following input. The second possibility is which means block cannot precede block regardless of arbitrary following input. The last possibility comprises all other relations.

We say a candidate block is preceding if , , and the preceding set is the set of all preceding blocks, which means that such blocks have a relatively high priority to be output by the algorithm. Thus, regardless of which blocks are received afterwards, the blocks in cannot precede the blocks in .

Now, we present the DEXON total ordering algorithm, which is a symmetric algorithm. The DEXON total ordering algorithm is an event-driven online algorithm. The input is one block per iteration and the algorithm produces blocks when specific criteria are satisfied. Regardless of the order of the inputs, the algorithm is executed by each node individually, and the algorithm outputs blocks in the same order. The only requirement regarding input is that the set (including acking information) of input for each node is the same eventually.
The criteria consist of two parts: the internal stability and the external stability. Informally, internal stability ensures each block in the preceding set has the highest priority to be output compared with all other blocks in the candidate set, and external stability ensures that each block in the preceding set always has higher priority to be output irrespective of the type of blocks received. Let be the number of total nodes. The criteria to output the preceding set for node is defined as follows:

  • Internal Stability: s.t.

  • External Stability:

    • (a) , or

    • (b) s.t. and
      lllll ,

We call the output normal delivery if it satisfies internal stability and external stability (a), and early delivery if it satisfies internal stability and external stability (b).

Next, we simplify two criteria by the following theorems.

Theorem 4.1 (Simplifying Criterion for normal delivery).

External Stability (a) implies Internal Stability. That is, if , then, s.t. .

Proof.

First, we prove by contradiction. Assume . By the definition of a preceding set, s.t. . However, by the definition of function, , contradiction.
Second, assume s.t. . Case 1: , , then , contradiction. Case 2: , , then , contradiction.
Third, if , it is easy to check the correctness for the theorem. ∎

Theorem 4.2 (Simplifying Criterion for early delivery).

If both internal stability and hold, then, external stability (b) also holds.

Proof.

It is easy to prove . Let be the block that precedes a block, then holds. Next, assume s.t. . Then, holds. and for the case . When the blocks issued by all nodes have been received, can reach more than . This means is preceded by . Thus, , contradiction. Therefore, s.t. . ∎

Hence, the are simplified into the following conditions:

  • Normal Delivery:

  • Early Delivery: s.t. and

Procedure DEXON_Total_Ordering for node p
       Input : a block from node and its acking information per iteration
       Output : ordered block series
       when receiving a block ,
             if  only acks the blocks that have been output, then
                  
                   foreach  do
                        
                  
                  
            
            if , then
                   foreach   do
                         if  is directly or indirectky acked by , then
                               ,
                              
                        
                        else
                              
                        
                        
                  
                  
            
            
      end ;
      when holds,
             output in the lexicographical order of the hash value of each block
             //update and
            
            
             foreach  only acks the blocks that have been output do
                  
            
            foreach  do
                   compute
            
            foreach  do
                   if  is preceding, then
                        
                  
                  
            
            
      end ;
Algorithm 2 DEXON Total Ordering Algorithm

The DEXON total ordering algorithm is listed as Algorithm 2. There are two events that must be considered: one is a block received and the other is that some criteria are satisfied. When a block is received, the algorithm updates its potential function of candidate blocks according to the ack information from . If only acks the blocks that have been output, it is a candidate block. Then, the algorithm updates according to . Otherwise, is not a candidate. If node has never been in node ’s view, each candidate block updates its potential function. If node has been in node ’s view, there must exist a s.t. . Thus, both potential functions for all candidate blocks would not change and the algorithm would do nothing. When the second event occurs, this means that the potential functions of the preceding candidate blocks are adequate and the preceding candidate can be output. After the algorithm outputs, it continues to collect the next candidate blocks and to update their potential functions.

Figure 3: Example of the DEXON total ordering algorithm: if this is in node ’s local view, , , , , , , , , , ,

4.2.1 Correctness and Liveness

Lemma 4.3 (Consistency of AHV).

The first time the criterion holds for node , and are consistent for any block . That is, for each node , if and , then .

Proof.

Let satisfy and . Consider that if both functions hold, then this lemma is correct. Without loss of generality, assume , or , for some integer , because node . Case 1: , let be the minimum number s.t. . If , , which leads to a contradiction. If , must be in . By the causality of blocks in the blocklattice, must be equivalent to , which leads to a contradiction. Case 2: , the argument is similar to case 1, thus, by the causality of blocks in the blocklattice, , which leads to a contradiction. ∎

Lemma 4.4 (Consistency of Grade).

The first time the criterion holds for node , and are consistent for any two blocks . That is, .

Proof.

Because both of the local views of nodes and are partial DAGs, they will be the same eventually. By Lemma 4.3, the output of function of node and are consistent for every block . Thus, . ∎

Lemma 4.5 (Arrival of the Preceding set).

When the first time the criterion holds for node , then and holds.

Proof.

We have three cases: first, node are normal delivery; second, one node is normal delivery and the other is early delivery; third, both are early delivery. Case 1: we have , so