DEXON :

A Highly Scalable, Decentralized DAG-Based Consensus Algorithm

Tai-Yuan Chen, Wei-Ning Huang, Po-Chun Kuo, Hao Chung and Tzu-Wei Chao

DEXON Foundation,
Taiwan

{popo,w,pk,haochung,n}@dexon.org

November 20, 2018, v2.0

arXiv:1811.07525v1 [cs.CR] 19 Nov 2018

Abstract
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.
Keywords: Blockchain, Blocklattice, Consensus, Byzantine Agreement, Byzantine Fault Tolerance, Repli-
cated State Machine, Total Ordering

1
Contents
1 Introduction 3
1.1 Main Features of DEXON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries and Model 5

2.1 Cryptographic Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Terminology and System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Single Chain 6
3.1 Common Reference String and Verifiable Random Function . . . . . . . . . . . . . . . . . . . . . 6
3.2 Byzantine Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Communication Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Consensus on a Single Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Blocklattice 12
4.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 DEXON Total Ordering Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Correctness and Liveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Timestamping Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Consensus on the Blocklattice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Resistance Against Byzantine Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Extension of DEXON 19
5.1 Total Ordering as Sharding Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Configuration Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2
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 [GHM+ 17] 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 2, the total throughput of the whole system also increases by a factor of 2.

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 6λ time, where λ is the upper bound of the network’s gossip period. The DEXON con-
sensus 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.

3
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 O(n2 ) communication complexity in any n-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 n parties to O(log n). Thus, the communication cost is reduced from O(n2 )
to O(n log n). 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 [GHM+ 17, 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. [GHM+ 17], that reduces the communication complexity
from O(n2 ) to O(n ln n) 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

4
costs a latency of O(ln n) 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 Hash 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 Sig is available. We define Sigsk (m) to be the signature
of the message m signed by the secret key sk.

Threshold Signature Let n be the number of parties. A (n, t)-threshold signature scheme allows arbitrary
t 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(1Λ ): a distributed key generation algorithm takes as input a security parameter Λ, and outputs
a public key P K, a set of verification keys {V Ki }ni=1 , and the secret key SKi for each party i.
• ShareSign(SKi , m): a share signing algorithm takes as input a message m and a secret key SKi . It
outputs a signature share SSigni (m).
• Verify-ShareSign(m, V Ki , σi ): a share verification algorithm takes as input a message m, the verification
key V Ki and a signature share σi on m from the party i. It outputs 1 if σi is valid and outputs 0 otherwise.

• Combine(m, P K, {V Ki }i∈T , {σi }i∈T ): a share combining algorithm takes as input a message m, the public
key P K, the set of verification key {V Ki } and t verified signature shares {σi }i∈T on the message m where
T is a subset of {1, 2, · · · , n} such that |T | = t. It outputs a threshold signature T Sign(m).
• Verify-TSign(m, P K, Σ): a signature verification algorithm takes as input a message m, the public key
P K, and a threshold signature Σ. It outputs 1 if Σ is valid and outputs 0 otherwise.
It is required that except with negligible probability, Verify-ShareSign(m, V Ki , ShareSign(SKi , m)) = 1 holds
for any party i. It is also required that except with negligible probability, Verify-TSign(m, P K, Σ) = 1 holds,
where Σ is the threshold signature of t valid signature shares {σi }i∈T for any subset T ⊂ {1, 2, · · · , n}.
For the security definition, one can refer to [LJY14].

Verifiable Random Function Let (P K, SK) 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 SK can compute the function
whereas anyone can verify the validity of the function evaluation by P K and public information. Typically, a
VRF consists of the following algorithms:
• KeyGen(1Λ ): a probabilistic polynomial time algorithm takes as input a security parameter Λ, and gen-
erates a public key and private key pair (P K, SK).
• VRF(SK, x): a deterministic algorithm takes as input the private key and an initial value x, and outputs
verifiable random value y.
• Prove(SK, x): a deterministic algorithm takes as input the private key and an initial value x, and output
the proof of correctness w.
• Verify(x, y, w): a deterministic algorithm verifies the validity of the VRF using the proof w.

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

5
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 Snode where the members of Snode are called nodes. We define
two special sets of nodes: the CRS set SCRS and the notary set Snotary (a node can be in two sets at the same
time). The nodes in SCRS and Snotary 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 SCRS
generate a public randomness. Then, for each height of the single chain, the members in Snotary 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 i is updated by Ri = Hash(T Sig(Ri−1 )),
where T Sig(·) is a threshold signature function whose input is some set of share-signatures produced by the
nodes in SCRS of epoch i − 1.
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 [GHM+ 17] 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 j computes the
verifiable random function as:

Ri − Hash Sigskj (x) , (1)
where Ri is CRS of epoch i and x is public information. Thus, Hash(Sigskj (x)) is verifiable with userj ’s public
key and unpredictable.

6
 Our VRF has three benefits compared to the VRF in Algorand. First, our design is fairer. The verifiable
random function used in Algorand is Hash(Sigskj (Qi−1 , x)), where Qi−1 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
(1/3)/(1 − 1/3) = 1/2. 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, Hash Sigskj (x) . 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 Qi−1 to compute Qi . 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 b ∈ {0, 1} 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 Snotary . Thus, only the
members in Snotary are involved in the Byzantine agreement protocol. Let n be the number of nodes in Snotary
and t be the number of Byzantine nodes in Snotary .
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 2λ. Also, if no partition is present, our protocol terminates in t rounds in the worst
case and can be expected to terminate in 74 rounds.
Let tmax = b(n − 1)/3c, Ri denote the CRS at epoch i and V denote the set of values that can be decided.
We also define two special values ⊥ and SKIP that are not in V . For each node q ∈ Snotary , q has four internal
variables: rq records the index of the round at which q is working, lockvalueq records the candidate value that q
supports, lockroundq records the index of the round from which lockvalueq comes and clockq is q’s local clock. Let
skq and pkq denote the secret key and public key of q, 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 q ∈ Snotary
computes the signature σq = Sigskq (status) with its secret key skq . We define three kinds of messages:
1. the initial message of the node q: (“init”, vq , q, σq )
2. the pre-commit message of the value v from the node q at the round r: (“pre-com”, v, q, r)
3. the commit message of the value v from the node q at the round r: (“com”, v, q, r)
With these notations, we introduce the leader election algorithm which will be a subroutine of our Byzantine
agreement protocol. Let Mq denote the set of initial messages that the node q receives from other nodes. The
node q verifies the signatures in Mq and sets Uq to be the set of nodes whose signatures are valid. Then, q
computes
`q = argmin |Ri − Hash (σj )| .
j∈Uq

We say `q is the leader of q.

Our Byzantine agreement protocol (Algorithm 1) is a round-based protocol. Initially, for all correct nodes
q ∈ Snotary , q initializes its internal variables by rq = 1, lockvalueq = ⊥, lockroundq = 0 and clockq = 0 and also
chooses its initial value vq ∈ V .
Our protocol has four steps in each round. At Step 1, all the nodes gossip their own initial value vq in the
format (“init”, vq , q, σq ).
When clockq = 2λ, q enters Step 2. If lockvalueq = ⊥, q verifies the initial messages it receives and computes
the set Uq of nodes whose signatures are valid. If Uq 6= ∅, q identifies its leader `q and pre-commits `q ’s value;
otherwise, q pre-commits ⊥. If lockvalueq 6= ⊥, node q pre-commits lockvalueq . We say node q pre-commits on
a value v if node q gossips the message (“pre-com”, v, q, r) where r is the round number that node q is working
at.
When clockq = 4λ, node q enters Step 3. If node q has seen 2tmax + 1 pre-commit messages of the same
value v ∈ V ∪ {⊥} at round rq , node q updates lockvalueq = v and lockroundq = rq and commits v. Otherwise,

7
node q commits SKIP. Note that node q must commit some value at Step 3. We say node q commits on a value
v if node q gossips the message (“com”, v, q, r) where r is the round number that q is working at. After node q
gossips the commit message, q enters Step 4, at which q waits for the forward conditions.
Suppose a node q is working at round rq . The node q updates its internal variables as soon as one of the
following conditions holds:
1. If node q has seen 2tmax + 1 pre-commit messages of the same value v ∈ V ∪ {⊥} at the same round r
such that rq ≥ r > lockroundq , q sets lockvalueq = v and lockroundq = r.
2. (forward condition) If node q has seen 2tmax + 1 pre-commit messages of the same value v ∈ V ∪ {⊥} at
the same round r such that r > rq , q sets clockq = 2λ, lockvalueq = v, lockroundq = r and starts the round
r from Step 2.
3. (forward condition) If the node q has seen 2tmax + 1 commit messages of any value at the same round r
such that r ≥ rq , q sets clockq = 2λ and starts the round r + 1 from Step 2.
We say that node q achieves the forward condition, if the condition 2 or the condition 3 holds. Node q 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 q decides on a value v as soon as node q has seen 2tmax + 1 commit messages of the same value
v ∈ V ∪ {⊥} at the same round r.
The protocol for a node q is summarized as Algorithm 1.

Procedure DEXON Byzantine Agreement for node q

Input : an initial value vq ∈ V from node q and the public key {pkq } from all nodes
Output: an agreed value vf in ∈ V ∪ {⊥} from some node
Initialize rq = 1, lockvalueq = ⊥, lockroundq = 0 and clockq = 0
Step 1: when clockq = 0,
gossip(“init”, vq , q, σq )
Step 2: when clockq = 2λ,
if lockvalueq = ⊥ and Uq 6= ∅ then
node q identifies its leader `q at q’s current view
gossip(“pre-com”, v`q , q, rq )
else if lockvalueq = ⊥ and Uq = ∅ then
gossip(“pre-com”, ⊥, q, rq )
else
gossip(“pre-com”, lockvalueq , q, rq )
Step 3: when clockq = 4λ,
if node q has seen 2tmax + 1 pre-commit messages of the same value v ∈ V ∪ {⊥} at round rq then
lockvalueq = v
lockroundq = rq
gossip(“com”, v, q, rq )
else
gossip(“com”, SKIP, q, rq )
Step 4: when clockq ∈ (4λ, ∞)
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 t ≤ tmax . Suppose a node p receives 2tmax + 1 commit messages of vp and another node
q receives 2tmax + 1 commit messages of vq . If both these 2tmax + 1 commit messages all come from the round
r, then vp = vq .
Proof. We prove this lemma by contradiction. Suppose vp 6= vq . Because as many as t Byzantine nodes exist,
there exists at least one correct node that both commits on vp and vq 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 t ≤ tmax . Regardless of partition, if a correct node p decides on some
value vp and a correct node q decides on some value vq , then vp = vq . That is, the correct nodes will never
decide on different values.

8
Proof. Because p decides on vp and q decides on vq , p and q must see 2tmax + 1 commit messages of vp and
2tmax + 1 commit messages of vq , respectively. Suppose both these 2tmax + 1 commit messages come from the
same round r. By Lemma 3.1, we have vp = vq .
Suppose the 2tmax + 1 commit messages that p receives come from the round rp and the 2tmax + 1 commit
messages that q receives come from the round rq . Without loss of generality, we assume rp < rq . Because there
are up to tmax Byzantine nodes, there must be at least tmax + 1 correct nodes commit on vp so that p can receive
2tmax + 1 commit messages of vp . For all rounds r > rp , these tmax + 1 correct nodes will always pre-commit
on vp until they see 2tmax + 1 pre-commit messages of v 0 6= vp at Step 3. However, only 2tmax nodes remain,
so these tmax + 1 correct nodes will never pre-commit any v 0 6= vp for all r > rp . Thus, for all r > rp , if some
value v has 2tmax + 1 pre-commit messages, then v = vp .
Because q receives 2tmax + 1 commit messages of vq , there must exist at least tmax + 1 correct nodes that
commit on vq at the round rq . These tmax + 1 correct nodes commit on vq only if they have seen 2tmax + 1
pre-commit messages of vq at round rq . Therefore, vq = vp .

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 t ≤ tmax . If all the correct nodes start at the r-th
round within time λ and no partition exists, all the correct nodes will decide on some values in t + 1 rounds.
Proof.
Case 1: Some correct node has decided. If a correct node p has decided on value vp , p must have seen 2tmax + 1
commit messages of vp . Because p propagates these 2tmax + 1 commit messages, all the correct nodes will hold
this information after time λ and decide on vp in one round.
Case 2: Some correct node has seen 2tmax + 1 pre-commit messages. Suppose no node has decided but there
exists a correct node p that has seen 2tmax + 1 pre-commit messages of a value vp . Because p propagates these
2tmax + 1 pre-commit messages, all the correct nodes will hold this information after time λ. Thus, all the
correct nodes will commit vp so that they can reach an agreement on vp .
Case 3: No correct node has seen 2tmax + 1 pre-commit messages. Because no correct node has ever seen
2tmax + 1 pre-commit messages, lockvalueq = ⊥ for all correct node q. 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 r-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 nodes1 . 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
t Byzantine nodes can only interfere during t rounds. Thus, all the correct nodes will decide on some values in
t + 1 rounds with certainty.
Proposition 3.4. Assume t ≤ tmax . Suppose all correct nodes start at r-th round within time λ and no partition
exists. Then, it is expected that all correct nodes will decide on some values in 74 rounds.
Proof. From the proof of Proposition 3.3, we know that if some correct node has decided on a value v or has
seen 2tmax + 1 pre-commit messages of a value v, then all the correct nodes will decide on v 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 k rounds successfully, the Byzantine nodes must win
the leadership 2 in the following k rounds. The probability of such an event is
k−1
Y   k
t−i t
≤ .
i=0
n−i n

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

t  i t
X t n
·i≤ .
i=1
n (1 − nt )2
1 Note that not proposing any initial value is considered to be equivalent to proposing ⊥.
2 Notice that the leader is the node j with the lowest value |Ri − Hash (σj )|.

9
Because n ≥ 3tmax + 1 ≥ 3t + 1, the expected number of interfered rounds is less than 43 . 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
7
4 rounds.

Proposition 3.5 (Termination when the partition is resolved). Assume t ≤ tmax . If the partition is resolved,
all the correct nodes will decide on some values in t + 2 round. It is to be expected that all correct nodes will
decide on some values in 11 4 rounds.

Proof. If there exists a node p that has decided on a value vp , p must have seen 2tmax + 1 commit messages of
vp . All the correct nodes will receive these 2tmax + 1 commit messages of vp within time λ after the partition
is resolved and decide on vp .
Suppose no node has decided and p is the node working on the latest round rp . To enter the round rp , p
must achieve the forward condition at round rp − 1. 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 rp .
Later on, if some node q achieves the forward condition and enters the round rp + 1, other correct nodes will
also achieve the forward condition within time λ. Thus, all correct nodes start at the round rp + 1 with time
difference < λ and Proposition 3.3 guarantees that they will decide on some values within the following t + 1
rounds. Similarly, it is to be expected that all correct nodes will decide on correct values in 11
4 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 O(n) messages in a single round. Thus, the
communication complexity for all nodes is O(n2 ) 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 t + 1 rounds in the worst case and is expected to terminate in 11 4 rounds. We
assume n ≥ 3t + 1, so the protocol terminates in O(n) rounds in the worst case and is expected to terminate
in O(1) rounds. Therefore, the total communication complexity of the protocol is O(n3 ) in the worst case and
O(n2 ) 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 SCRS are responsible for updating the CRS. The members in Snotary 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 Snotary 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 Σh . The threshold signature Σh 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 SCRS and Snotary are re-elected for each epoch. Each epoch i corresponds to a randomness
Ri of CRS. When SCRS is re-elected, the members in SCRS 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 Snode can announce the request. The request will be recorded in the blocks.
The node is called valid if it owns enough deposit3 and has registered a valid public key. Let viewi denote the
i
snapshot of the whole system at the first block of the epoch i. Let Snode denote the set of all valid nodes in
i i+1 i
view . The set Snode can be updated by Snode and the blocks in the epoch i.

Proposing Blocks Only the nodes in Snotary can propose new blocks. To propose a block, a node q computes
the hash vq of the block and takes vq as the initial value for the Byzantine agreement protocol. Note that node
q 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 pre-

dictable information status, Ri , and the secret keys, the node q can compute the value Ri − Hash Sigskq (status)
3 To 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.

10
locally. If the value is too large, q 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 q will propose a block if and
only if Ri − Hash Sigskq (status) ≤ δ. Suppose n is the number of nodes in Snotary . Then, the probability
that at least one node proposes a block is 1 − (1 − δ)n . Choosing δ = 20/n, the probability is larger than
1 − 10−8 . 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 Snotary are responsible for running the Byzantine agreement protocol (Al-
gorithm 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 Snotary can reach an agreement even if they do not start within time λ.
To notarize a block, we choose a (n, tmax + 1)-threshold signature scheme. When a node q ∈ Snotary decides
on some value v for the block with height h, node q signs a signature share σq by its secret key SKq 4 and
announces σq . The block proposers of the next block (of height h + 1) have to verify at least tmax + 1 signature
shares for the block with height h and combine the signature shares into a threshold signature Σh . The threshold
signature Σh should be packed into the next block. We say a block with height h is notarized if its threshold
signature Σh is packed in the next block and the next block is issued.
Assume the number of Byzantine nodes is up to tmax . Then, anyone can make sure the block with the hash
v is notarized by Snotary if more than tmax + 1 nodes in Snotary have signed on v. To verify the fact, we only
need to check whether the block hash v matches the threshold signature Σh stored in the next block and verify
whether Σh is valid or not.

i i
Updating Epoch The members in SCRS and Snotary are re-elected for each epoch. Let SCRS and Snotary
denote the CRS set and the notary set of the epoch i.
i i
The set SCRS , the set Snotary , and the randomness Ri are decided before the epoch i starts. When the epoch
i
i starts, the members in SCRS generate the randomness Ri+1 by

Ri+1 = Hash (T Sig(Ri )) ,

i i+1
where T Sig(Ri ) is the threshold signature signed by the nodes in SCRS . After Ri+1 is decided, the set SCRS and
i+1 i
the set Snotary can be elected by Fisher-Yate shuffle with the randomness Ri+1 from the set Snode . Finally, the
i+1 i+1
members in SCRS and Snotary 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 Note that the key pair (P K , SK ) for the threshold signature is different from the key pair (pk , sk ) that the node q registers
q q q q
on the block.

11
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 N be the set of chains and F be the set of chains which contains the blocks from Byzantine nodes in the
DAG, whose maximum capacity is limited by fmax = b(|N | − 1)/3c. Let P 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 A follows another block B, we call this relation A acks B. Let C be the set of candidate
blocks that only ack the blocks that are already in the compaction chain. Informally, A 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 (·)p to denote a set or function in p’s local view, for example, Cp is the candidate set
in p’s local view. We use bq,i to denote the i-th block from node q. We define indirect ack by the transitive law
of ack: if a block A acks another block B through the transitive law of ack, then we say A indirectly acks B.
For example, if A acks B and B acks C, A indirectly acks C. An example is provided in Figure 2.

Figure 2: A simple example illustrates the notation: N = {A, B}, C = {bA,1 , bB,3 }. Also, bA,2 acks bA,1 and
bB,4 . Both bA,2 and bB,5 indirectly ack bB,3 .

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 fmax 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
|N | ≥ Φ > |N |/2; it can be seen as the threshold of the output criterion. We set Φ = 2fmax + 1 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

12
(DAG) from the received blocks. More precisely, each vertex corresponds to some block and each edge corre-
sponds 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, AN Sp (b) = { j : ∃bj,k ∈ P s.t. bj,k directly or indirectly acks b }∪{p}, is the set of nodes
that issued blocks ack
S block b in node p’s local view. Moreover, the global Acking Node Set AN Sp for
node p is defined by b∈Cp AN Sp (b).

2. AHVp (b) is the Acking block-Height Vector of block b in node p’s view, defined as:


⊥,
 if q ∈
/ AN Sp
AHVp (b)[q] = k, if bq,k acks b, where k = min{i : bq,i ∈ P}

∞, otherwise.


3. #AHVp = | { j : AHVp (b)[j] 6= ⊥ and AHVp (b)[j] 6= ∞ } | is the number of integer elements in AHVp (b).
Next, we define two functions,

1,
 if |{j : AHVp (b1 )[j] < AHVp (b2 )[j]}| > Φ
P recedep (b1 , b2 ) = −1, if |{j : AHVp (b1 )[j] > AHVp (b2 )[j]}| > Φ

0, otherwise,


and

1, if P recedep+ (b1 , b2 ) = 1

Gradep (b1 , b2 ) = 0, if |{j : AHVp+ (b1 )[j] < AHVp+ (b2 )[j]}| < Φ − (n − |AN Sp |)

⊥, otherwise,


where (·)p+ is the local view of p in the future. That is, the pending set becomes Pp ∪Sp , where Sp consists of all
the probable blocks received by p in the future. The Gradep (b1 , b2 ) function outputs the three possible relations
between block b1 and b2 in the future: the first possibility is Gradep (b1 , b2 ) = 1, which means block b1 always
precedes block b2 regardless of arbitrary following input. The second possibility is Gradep (b1 , b2 ) = 0 which
means block b1 cannot precede block b2 regardless of arbitrary following input. The last possibility comprises
all other relations.
We say a candidate block b is preceding if ∀ b0 ∈ Cp , Gradep (b0 , b) = 0, and the preceding set A 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 C \ A cannot precede the blocks in A.

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 n be the number of total nodes. The criteria to
output the preceding set Ap for node p is defined as follows:
• Internal Stability: ∀b ∈ Cp \ Ap , ∃b0 ∈ Ap s.t. Gradep (b0 , b) = 1
• External Stability:
– (a) |AN Sp | = n, or
– (b) ∃b ∈ Ap s.t. #AHVp (b) > Φ and
∀b ∈ Ap , |AN Sp (b)| ≥ n − Φ
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.

13
Theorem 4.1 (Simplifying Criterion for normal delivery). External Stability (a) implies Internal Stability.
That is, if |AN Sp | = n, then, ∀b ∈ Cp \ Ap , ∃b0 ∈ Ap s.t. Gradep (b0 , b) = 1.
Proof. First, we prove Ap 6= ∅ by contradiction. Assume Ap = ∅. By the definition of a preceding set, ∀b ∈
Cp , ∃b0 ∈ Cp s.t. P recedep (b0 , b) = 1. However, by the definition of P recedep function, b0 ∈ Ap , contradiction.
Second, assume ∃b0 ∈ Cp \ Ap , ∀b ∈ Ap s.t. P recede(b, b0 ) 6= 1. Case 1: ∀b00 ∈ Cp \ Ap , P recede(b00 , b0 ) 6= 1, then
b0 ∈ Ap , contradiction. Case 2: ∃b00 ∈ Cp \ Ap , P recede(b00 , b0 ) = 1, then b00 ∈ Ap , contradiction.
Third, if Ap = Cp , it is easy to check the correctness for the theorem.
Theorem 4.2 (Simplifying Criterion for early delivery). If both internal stability and Cp \ Ap 6= ∅ hold, then,
external stability (b) also holds.
Proof. It is easy to prove A = 6 ∅. Let b0 ∈ A be the block that precedes a block, then #AHVp (b0 ) > Φ
holds. Next, assume ∃b ∈ A s.t. |AN Sp (b)| < n − Φ. Then, #AHVp (b) < n − Φ holds. |{j|AHVp (b0 )[j] <
AHVp (b)[j]}| > Φ − (n − Φ) = 2Φ − n and for the case |AN Sp | > Φ. When the blocks issued by all nodes have
been received, |{j|AHVp (b0 )[j] < AHVp (b)[j]}| can reach more than (2Φ − n) + (n − Φ) = Φ. This means b is
preceded by b0 . Thus, b ∈
/ A, contradiction. Therefore, ∀b ∈ A s.t. |AN Sp (b)| ≥ n − Φ.
Hence, the criteria are simplified into the following conditions:

• Normal Delivery: |AN Sp | = n

• Early Delivery: ∀b ∈ Cp \ Ap , ∃b0 ∈ Ap s.t. Gradep (b0 , b) = 1 and Cp \ Ap 6= ∅

Procedure DEXON Total Ordering for node p

Input : a block bq,i from node q and its acking information per iteration
Output: ordered block series
when receiving a block bq,i ,
if bq,i only acks the blocks that have been output, then
Cp = Cp ∪ {bq,i }
foreach r ∈ AN Sp do
AHVp (bq,i )[r] = ∞
if q ∈
/ AN Sp , then
foreach b ∈ Cp do
if b is directly or indirectky acked by bq,i , then
AHVp (b)[q] = i,
AN Sp (b) = AN Sp (b) ∪ {q}
else
AHVp (b)[q] = ∞
end;
when criteriap holds,
output Ap in the lexicographical order of the hash value of each block
//update Ap and Cp
Cp = Cp \ A
Ap ← ∅
foreach b ∈ Pp only acks the blocks that have been output do
Cp = Cp ∪ {b}
foreach b ∈ Cp do
compute AHVq (b), AN Sq (b)
foreach b ∈ Cp do
if b is preceding, then
Ap = Ap ∪ {b}
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 bq,i is received, the
algorithm updates its potential function of candidate blocks according to the ack information from bq,i . If bq,i
only acks the blocks that have been output, it is a candidate block. Then, the algorithm updates AHVp (bq,i )
according to AN Sp . Otherwise, bq,i is not a candidate. If node q has never been in node p’s view, each candidate
block updates its potential function. If node q has been in node p’s view, there must exist a j < i s.t. bq,j ∈ P.
Thus, both potential functions AHVp , AN Sp for all candidate blocks would not change and the algorithm would

14
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 C’s local view, C =
{bA,1 , bB,3 , bE,0 }, A = {bA,1 , bB,3 , bE,0 }, AHVC (bA,1 ) = (1, ∞, ∞, ∞, ∞, ⊥), AHVC (bB,3 ) = (∞, 3, ∞, ∞, ∞, ⊥),
AHVC (bE,0 ) = (∞, ∞, 2, 1, 0, ⊥), #AHVC (bA,1 ) = 1, #AHVC (bB,3 ) = 1, #AHVC (bE,0 ) = 3, AN SC (bA,1 ) =
{A}, AN SC (bB,3 ) = {A, B, D}, AN SC (bE,0 ) = {A, B, C, D, E}

4.2.1 Correctness and Liveness

Lemma 4.3 (Consistency of AHV). The first time the criterion holds for node p, q, AHVp (b) and AHVq (b)
are consistent for any block b ∈ Cp ∩ Cq . That is, for each node r, if AHVp (b)[r] 6= ⊥ and AHVq (b)[r] 6= ⊥, then
AHVp (b)[r] = AHVq (b)[r].
Proof. Let r ∈ N satisfy AHVp (b)[r] 6= ⊥ and AHVq (b)[r] 6= ⊥. Consider that if both functions AHVp (b)[r] =
AHVp (b)[r] = ∞ hold, then this lemma is correct. Without loss of generality, assume AHVp (b)[r] = k,
AHVq (b)[r] = k 0 or ∞, for some integer k 0 6= k, because node r ∈ Nq . Case 1: AHVq (b)[r] = ∞, let i be
the minimum number s.t. br,i ∈ Pq . If i < k, AHVp (b)[r] < k, which leads to a contradiction. If i > k, br,k must
be in Pq . By the causality of blocks in the blocklattice, i must be equivalent to k, which leads to a contradiction.
Case 2: AHVq (b)[r] = k 0 , the argument is similar to case 1, thus, by the causality of blocks in the blocklattice,
k 0 = k, which leads to a contradiction.
Lemma 4.4 (Consistency of Grade). The first time the criterion holds for node p, q, Gradep (b1 , b2 ) and
Gradeq (b1 , b2 ) are consistent for any two blocks b1 , b2 ∈ Cp ∩ Cq . That is, Gradep (b1 , b2 ) = Gradeq (b1 , b2 ).

Proof. Because both of the local views of nodes p and q are partial DAGs, they will be the same eventually. By
Lemma 4.3, the output of function AHV (b) of node p and q are consistent for every block b ∈ Cp ∩ Cq . Thus,
Gradep (b1 , b2 ) = Gradeq (b1 , b2 ).
Lemma 4.5 (Arrival of the Preceding set). When the first time the criterion holds for node p, q, then Ap ⊂ Cq
and Aq ⊂ Cp holds.
Proof. We have three cases: first, node p, q are normal delivery; second, one node is normal delivery and the
other is early delivery; third, both are early delivery. Case 1: we have |AN Sp | = n, so Aq ⊂ Cq ⊂ Cp and
|AN Sq | = n. Consequently, Ap ⊂ Cp ⊂ Cq . The lemma holds in this case.
Case 2: Without loss of generality, we assume |AN Sq | = n and early deliver happened in node p. First,
Ap ⊂ Cp ⊂ Cq because |AN Sq | = n. Second, we prove Aq ⊂ Ap by contradiction. Assume there exists a block
b ∈ Aq \ Ap . By the definition of the preceding set, ∃b0 ∈ Ap , s.t. P recedep (b0 , b) = 1. However, because
b ∈ Aq , ∀b00 ∈ Aq , P recedeq (b00 , b) = 0. By the Lemma 4.3, b0 ∈ Cq is also present in the preceding set, and
P recedeq (b0 , b) = 1, which leads to a contradiction. This means Aq ⊂ Ap ⊂ Cp .
Case 3: ∀b ∈ Ap , let b0 ∈ Aq be the block with #AHVq (b0 ) > Φ. Because |AN Sq (b0 )| > Φ and |AN Sp (b)| ≥
n − Φ, there must exist a node r ∈ AN Sp (b) ∩ AN Sq (b0 ) by the pigeonhole principle. Thus, b and b0 are received
if the blocks issued by r are received; this means b ∈ Cq . Furthermore, Aq ⊂ Cp holds as well.
Theorem 4.6 (General Correctness for total ordering). Let Aip , Aiq be the i-th set output by node p, q, then
Aip = Aiq holds.

15
Proof. We use inductive assumption to prove this theorem. For i = 1 (the first time the criterion holds), for
node p, q, we prove that Aip = Aiq : we prove this by contradiction. Assume Ap 6= Aq . Without loss of generality,
there exists a block b ∈ Ap \ Aq . By Lemma 4.5, we have Ap ⊂ Cq which implies b ∈ Cq \ Aq . Let b0 ∈ Aq ⊂ Cq
be the block s.t. Gradeq (b0 , b) = 1. This implies AN Sq (b0 ) > ∅. Consider two cases: either normal delivery
or early delivery happened on node p. Case 1: (normal delivery) |AN Sp | = n means b0 ∈ Cp . By Lemma
4.4, Gradep (b0 , b) 6= 1, contradiction because of b ∈ Ap in our assumption. Case 2: (early delivery) We have
|AN Sp (b)| ≥ n−∅ because b ∈ Ap . By the pigeonhole principle, there exists some node r ∈ AN Sp (b)∩AN Sq (b0 ).
When the blocks issued by the node r in both local views of nodes p and q are received, it proves b ∈ Cq , but
b∈/ Aq , contradiction. Thus, the i = 1 case holds. For i + 1 case, once the output set is the same, the sub-DAG
is eventually consistent in every node’s local view. Therefore, it follows the statement of Lemmas 4.3, 4.4, and
4.5 and the case of i = 1. This completes the proof.
Lemma 4.7. Let p be a correct node and ∆BA be the upperbound of processing time of BA, then the following
statements are correct:
1. If b is received by p at time T , then either b has been output or |AN Sp (b)| = |Np \ Fp | holds at time
T + ∆BA + λ.

2. If b ∈ P and |AN Sp (b)| ≥ |Np \Fp | holds at time T , then the criterion holds during time T and T +∆BA +λ.

Proof. For the first statement, suppose b is not output and |AN Sp (b)| = 6 |Np \ Fp |. We assume that each
correct node receives a block within ∆BA + λ after it is issued and all correct nodes will ack it or ack the
following blocks issued by that node. Thus, |AN Sp (b)| ≥ |Np \ Fp |. For the second statement, we have
|AN Sp | ≥ |AN Sp (b)| ≥ |Np \ Fp | and any Byzantine node must issue a block during time T and T + ∆BA + λ.
Thus, |AN Sp | = |Np | holds, and the criterion must hold by Theorem 4.1.
Lemma 4.8. If Cp 6= ∅ and the criterion holds, then Ap 6= ∅ for any node p.
Proof. Because Cp 6= ∅ and the criterion holds, internal stability implies there exists at least one element in Ap
that precedes the element in Cp . Thus, Ap 6= ∅ holds.

Theorem 4.9 (Liveness for total ordering). Let p be a correct node and ∆BA +λ be the upperbound of processing
time of BA. For any time interval ∆o ≥ 2∆BA + λ the criterion holds and the set of output is non-empty in the
interval ∆o .
Proof. We first prove that if a block b is received by p at time T , the criterion holds and the set of output is
non-empty before T + 2∆BA + λ: by Lemma 4.7, the criterion will hold before T + 2∆BA + λ. By Lemma 4.8,
the output set is not empty. Because each chain has liveness, the theorem is proved.

Theorem 4.10 (Validity of liveness for total ordering). For each input of a valid block b, the total ordering
algorithm will output b eventually.

Proof. Assume there exists a valid block b in p’s local view s.t. it is not output by the DEXON total ordering
algorithm. Let the set of blocks that acks b be the set Γ and let the set Λ be the set of nodes that issued
blocks in Γ. Because b is not output, no block in Γ will be a candidate block at any time. Thus, only the
elements in set Γ0 or Γs could be output, where Γ0 is the set of blocks issued by the node in N \ Λ and
Γs is the set of blocks whose heights are lower than those of the blocks in Γ for each node in Λ. That is,
Γs = { bq,j : j < j 0 , where bq,j 0 ∈ Γ and q ∈ Λ }. If the algorithm produces output many times, we can discover
a set of blocks B ∈ Γ0 that are acked by some blocks whose heights are higher than those of the blocks in
Γ for some node in Λ. Thus, we have #AHVp (b0 ) < fmax , for all b0 ∈ B. Now, consider two cases: the
first case is #AHV (b) > Φ, then b ∈ A. The second case is #AHVp (b) ≤ Φ, but |AN Sp | > 2fmax and
#AHVp (b0 ) < fmax < Φ. Thus, either b or some blocks in Γs will be in A. Because Γs is a finite set, the
algorithm will eventually output block b.

4.2.2 Complexity
In this section, we analyze the complexity of our total ordering algorithm. First, we describe the data structure
we used: we store both AHV 0 and AN S vectors for each block in the pending set, and AHVp0 (b) is defined as

⊥, if q ∈
 / AN Sp ,
k, where k is the minimum number s.t. bq,k acks b,

∞, otherwise.


16
We also store a global vector GAHVp , which is the minimum height of blocks issued by each node in p’s local
view. Thus, the AHVp (b)[j] can be computed from GAHVp [j] and AHVp0 (b)[j] in O(1).
Second, we start to analyze the algorithm: when a block is received, if it is a candidate block, the algorithm
updates the AHV vectors for the all blocks in the candidate set. This costs O(n) time. Because no block
acks it, only the criterion |AN Sp | = n must be determined. Otherwise, some block indirectly or directly acks
candidate blocks in the DAGp ; thus, both AHV 0 and AN S of all the blocks acked by the received block must
be updated. This costs O(n2 ) time because the total number of blocks in DAGp is O(n2 ) and the computation
of updating for each block is O(1) .
Third, to maintain the preceding set, a direct method to implement the algorithm is to compute all candidate
blocks every time; this method is exactly the same as the pseudo code, but it costs O(n3 ) because |A| × |C \ A|
blocks exist and for each iteration, the method requires O(n) to compute |{j|AHVp (b)[j] < AHVp (b0 )[j]}|. We
use a lazy-computation to reduce the complexity because we can store the current value and update it lazily.
Specifically, we use a matrix of (|A| + |C \ A|) rows and |C \ A| columns, consisting of elements of the form
(i1 , i2 ), each of which is |{j|AHVp (bi1 )[j] < AHVp (bi2 )[j]}| for bi1 ∈ A if i1 < |A|, bi1 ∈ C \ A if i1 ≥ |A|, and
bi2 ∈ C \ A. Thus, every time a block is received, the matrix updates the current relations of AHV functions
between candidate blocks. The preceding set and criterionp can both be determined by the matrix within
O(n2 ) time. Several operations can be conducted on the matrix. One operation is updating the matrix when a
block is received, all the elements in the matrix are updated and each update costs a constant operation time.
If the elements in a row all have value less than Φ − n + |ABSp |, this means that the block corresponding to
the row should be in the preceding set. Thus, the algorithm adds the block into the preceding set and updates
the matrix. If there exists an elements in a row whose value is larger than Φ, it means that there exists an
element in the preceding set that precedes the block corresponding to the row. Therefore, the complexity of all
aforementioned cases is bound by O(n2 ).
Therefore, both time and space complexity of the total ordering algorithm is bound by O(n2 ). Note that,
no communication exists between any two nodes in this total ordering algorithm.

4.3 Timestamping Algorithm

In this section, we present the timestamp algorithm, which ensures that the timestamp is decided from consensus
so that the Byzantine nodes cannot bias it. To compute the consensus timestamp for block b, the timestamping
algorithm first constructs a vector, whose elements are the newest time of blocks from each chain before block b.
Then, the median of the vector is the consensus timestamping of block b. The algorithm is shown in Algorithm
3, where b.Chain ID means b is generated from the chain ID and b.block timestamp is the block timestamp
of b.

Procedure Compute Timestamp

Input : ordered chain Chainorder =< b0 , b1 , ... >
Output: CompactionChain {bi } with consensus timestamp for each block
Let n be the number of chains and V is n-dimensional vector
foreach ID of the chain do
V [ID] = time of genesis block.
i=0
while i ≤ height of ordered chain do
V [Chainordered [i].Chain ID] = Chainordered [i].block timestamp
Chainordered [i].consensus timestamp = median(V )
i++
end
Algorithm 3: Compute Timestamp Algorithm

4.4 Consensus on the Blocklattice

Overview The DEXON consensus is the consensus of a blocklattice that consists of acking information and
numerous single chains as presented in the design in Section 3.3. With the total ordering algorithm, the
blocklattice is processed to a compaction chain by each node individually. The timestamping algorithm computes
the consensus timestamp for each block in the compaction chain. The parameter in the system contains the
number of chains, Φ, threshold κ for total ordering, and the network latency bound λ. We first explain how to
add acking information into block information, and then present the mechanism of the consensus of blocklattice
including adapting the total ordering and notarizing the blocks so that user can verify the validity of the blocks
in the compaction chain. In the end of this section, we introduce the load balancer that allows each chain to
gather the transactions that are not contained in the blocks of other chains.

17
 Figure 4: Blocklattice

Block Information To form a blocklattice structure, each block must add additional acking information.
When a user proposes a new block, the proposed block acks the latest notarized blocks of other chains it has
received. This means it sees the blocks from other nodes and supports them. We say that a block acks another
block if its ack field contains the acked block’s information. An ack field has the following data structure:

block proposer id block proposer’s ID

acked block hash hash of the acked block
block height height of the block, starting at 0

The DEXON blocklattice is formed by numerous single chains with acks between blocks. An example of a
DEXON blocklattice data structure is illustrated in Figure 4.

Single Chain The protocol is described as Section 3. Note that these single chains can share the same CRS,
so the system is only required to have one CRS set SCRS .

Compacting into Total-Ordered Chain Each single chain generates its blocks individually and these
generated blocks form a blocklattice. Then, each node executes the total ordering algorithm with the blocklattice
as input, and the output of the total ordering algorithm is the compaction chain, which is compacted from the
blocklattice. Then, the system applies the timestamping algorithm to compute the consensus time for each
block in the compaction chain.

Notarizing the Blocks in the Compaction Chain Once a block is in the compaction chain, the height of
the block in the compaction chain, the consensus timestamp, and the threshold signature are confirmed. These
three items of information are recorded in one of the next blocks of the compaction chain. Thus, the validity
of the block in the compaction chain can be verified by the following blocks which contains the notarizing
information.

Load Balancer In DEXON, many single chains grow concurrently. This leads to a problem: some transactions
(especially those with high transaction fees) may be packed into several single chains simultaneously. Note that
this problem does not do harm to the correctness of DEXON. Suppose a transaction tx is notarized in two
different single chains. Because all nodes can agree on the same compaction chain after the total ordering
algorithm, the transaction in the block with a smaller block height in the compaction chain will be executed
and the other will not be executed due to contradiction. However, this problem wastes the space utility of
blocks.
To solve this problem, we introduce a constraint of packing transactions, which is called load balancer.
Suppose the number of single chains is N . Let Snotary,j be the notary set of the j-th single chain. The node
can pack a transaction tx into its proposed block only if
Hash(tx) mod N = j.
With load balancer, each transaction is only allowed to be packed into one single chain and the problem is
resolved.

18
4.5 Resistance Against Byzantine Nodes
We briefly discuss how robust DEXON is against different ratio of Byzantine nodes. As a general framework
for combining many single chains, DEXON can resist against b(|Snode | − 1)/3c Byzantine nodes as long as the
correctness and the liveness of all individual single chain holds. That is, given N single chains with agreement,
DEXON can integrate these single chains into a globally-ordered chain with unbiased timestamp.
As for the single chain algorithm, in Section 3.2, we show that the agreement and the termination of our
Byzantine agreement protocol holds if t ≤ b(|Snotary | − 1)/3c, where t is the number of Byzantine nodes in
Snotary .
Thus, if we adopt our Byzantine agreement protocol as DEXON’s underlining single chain algorithm, we
need to guarantee that the number of Byzantine nodes in each notary set is smaller than b(|Snotary | − 1)/3c.
Let Snotary,i be the notary set of i-th single chain and ti is the number of Byzantine nodes in Snotary,i . Because
the notary set of each single chain is chosen independently, the probability that ti ≤ b(|Snotary,i | − 1)/3c for
all i will follow hypergeometric distribution. Consequently, there is a trade-off between the size of notary set,
the ratio of Byzantine nodes and the probability of failure. The following table illustrates that the lowest size
of Snotary with different ratio of Byzantine nodes and different probability of failure given |Snode | = 10k and
|Snode | = 100k.

ratio of Byzantine nodes in Snode

failure 1/4 1/5 1/4 1/5
probability Snode = 10k Snode = 100k
2−40 1237 481 1402 489
2−60 1789 724 2165 774
2−80 2272 952 2900 1054

Table 1: The lowest sizes of Snotary such that less than 1/3 members in Snotary are Byzantine nodes for |Snode | =
10k and 100k under the ratio of Byzantine nodes 1/4 and 1/5 with different probability are illustrated. For
example, if |Snode | = 10k and the number of Byzantine nodes is 10000 × 1/4 = 2500, the lowest size of Snotary
is 1237 such that less than 1/3 members in Snotary are Byzantine nodes with probability of at least 1 − 2−40 .

5 Extension of DEXON
5.1 Total Ordering as Sharding Framework
As mentioned before, compacting a blocklattice into a compaction chain by the total ordering algorithm is a
generic method for any blockchain with single-chain structure. A real-time total ordering can support up to 90
nodes in our experiment on a laptop (this experiment does not involve parallelization). A further way to create
more sharing chains is to shard many total orderings, and then, to sort the many compacted outputs by each
total ordering algorithm according to the unbiased timestamp.

5.2 Configuration Change

One of the main features of our consensus is the support of configuration changes while the consensus is
operating. For example, the parameters of the algorithm or the number of chains may be adjusted in order
to reach higher efficiency or higher throughput. To change configuration, all nodes must initiate at the same
state; otherwise, the system will be inconsistent. Fortunately, the output of total ordering is a sequence of sets
and each node outputs the same set through either normal delivery or early delivery at the same height of the
compaction chain. Moreover, each block in the compaction chain is marked by a consensus timestamp, which
is close to real-world time. Thus, a way to change configuration is to change the system at the same height or
at a specific consensus time (e.g. the first block after the specific consensus time).

Adding/Deleting Chain As previously mentioned, the consensus algorithm can change configuration by the
state of total ordering. In this section, we demonstrate how to achieve configuration changes by the consensus
in each single chain.
Given a specific time T , the block bi after T is the first block after a configuration change in chain i. Let
prev(b) be the parent block of b; let the blocks before the configuration change be in round r1 ; and let the
blocks after the configuration change be in round r2 . That is, all blocks before prev(bi ) are in r1 and all blocks
after bi are in r2 . Now, we add a rule for acking: any block in round r2 can only ack the last block in round r1
or blocks in round r2 .

19
 We use total ordering algorithm to compact the blocks in r1 until the system has received all {bi }i∈{1,...,n} .
If some blocks in r1 are not output by total ordering, we use a deterministic topological sort to output them
(e.g. output the candidate set with lexicographical order each time). Then, we start a new total ordering
algorithm with input blocks of round r2 . This is correct because of the liveness of each single chain. However,
the confirmation time may delay due to the quality of synchronization. The worst case of confirmation time
increases as λ + TBA + Ttotal ordering , but configuration changes rarely occur.
For the consensus timestamp, the causality may be demolished when adding or deleting chains because the
median of the latest time of each chain may be early. However, the number of the blocks whose block time is ear-
lier is very small. Thus, an easy way to fix this is to add a condition bi .timestamp = max(bi−1 .timestamp, bi .timestamp)
that ensures the consensus timestamp to continuously increase.

References
[BHM18] Leemon Baird, Mance Harmon, and Paul Madsen. Hedera: A governing council & public hashgraph
network. Whitepaper, May 2018. https://s3.amazonaws.com/hedera-hashgraph/hh-whitepaper-
v1.1-180518.pdf.

[CGMV18] Jing Chen, Sergey Gorbunov, Silvio Micali, and Georgios Vlachos. Algorand agreement: Super fast
and partition resilient byzantine agreement. IACR Cryptology ePrint Archive, 2018:377, 2018.
[DGKR18] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An
adaptively-secure, semi-synchronous proof-of-stake blockchain. In Advances in Cryptology - EU-
ROCRYPT 2018 - 37th Annual International Conference on the Theory and Applications of Cryp-
tographic Techniques, Tel Aviv, Israel, April 29 - May 3, 2018 Proceedings, Part II, pages 66–98,
2018.
[DKM93] Danny Dolev, Shlomo Kramer, and Dalia Malki. Early delivery totally ordered multicast in asyn-
chronous environments. In Digest of Papers: FTCS-23, The Twenty-Third Annual International
Symposium on Fault-Tolerant Computing, Toulouse, France, June 22-24, 1993, pages 544–553,
1993.
[DSU04] Xavier Défago, André Schiper, and Péter Urbán. Total order broadcast and multicast algorithms:
Taxonomy and survey. ACM Comput. Surv., 36(4):372–421, 2004.
[DY05] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable random function with short proofs and
keys. In Public Key Cryptography - PKC 2005, 8th International Workshop on Theory and Practice
in Public Key Cryptography, Les Diablerets, Switzerland, January 23-26, 2005, Proceedings, pages
416–431, 2005.
[GHKW17] Rishab Goyal, Susan Hohenberger, Venkata Koppula, and Brent Waters. A generic approach to
constructing and proving verifiable random functions. In Theory of Cryptography - 15th Interna-
tional Conference, TCC 2017, Baltimore, MD, USA, November 12-15, 2017, Proceedings, Part II,
pages 537–566, 2017.
[GHM+ 17] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scal-
ing byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating
Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM.

[HMW] Timo Hanke, Mahnush Movahedi, and Dominic Williams. Dfinity technology overview seriescon-
sensus system. Whitepaper. https://dfinity.org/pdf-viewer/pdfs/viewer?file=../library/dfinity-
consensus.pdf.
[LJY14] Benoı̂t Libert, Marc Joye, and Moti Yung. Born and raised distributively. In Proceedings of the
2014 ACM symposium on Principles of distributed computing - PODC '14. ACM Press, 2014.

[LSP82] Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem. ACM
Transactions on Programming Languages and Systems, 4(3):382–401, jul 1982.
[MRV99] Silvio Micali, Michael Rabin, and Salil Vadhan. Verifiable random functions. In Proceedings of the
40th Annual Symposium on the Foundations of Computer Science, pages 120–130, New York, NY,
October 1999. IEEE.
[Nak08] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.

20