004 | DEXON | Overview of DEXON | Programmer Explain

This article is written by Wayne Chiu, Full Stack Javascript Developer Contributor of open source blockchain project (NEO).

This is a special series that helps you to uncover how DEXON could qualify (or over qualify) real-business adoption as DApps platform.

Before we dive in, if you are wondering 「Why DApps?」 you can check out 『002 | DApps, do we really need it? | Programmer Explain』for different DApp projects built from the Hackathon.

DEXON DApps Hackathon

Now, let’s dive in!

In this post, you would be learning how blockchain works and its limitations. Along with it, will help you to uncover how DEXON work in order to break those limitations.


There are three limitations that current blockchain technology is facing

Limitation 1 — Low Transactions Per Second

It means how many transactions a system can take.
For example, VISA can take about 2,000 transactions per second.

Transaction Per Second

Limitation 2— Transactions Confirmation Time

It means how long would your transaction get confirmed after you sent it.
For example, it usually takes about 3 second to get a successful message after you swap your credit card.

Confirmation Time

Limitation 3— Probabilistic Finality

The transaction that you made is probabilistic. In other words, the transaction that you made has a chance to disappear cause the nature of blockchain consensus mechanism(proof of work). If you choose to dive in, please check out Finality in Blockchain Consensus.

In order to motivate you to dive into how DEXON works under the hood. Let’s talk about DEXON current performance first.

DEXON’s TPS is 2,000 with 1 chain
DEXON’s confirmation time is 3 second
DEXON’s transaction is not probabilistic but final once written on its ledge

Note: DEXON is able to scale up by adding more chains. As for current record, its TPS is 12,000 by running 6 chains in parallel. Check out DEXON Scan for real time data.

Warning: Contents that will be presented might not be user friendly, feel free to come join DEXON's Gitter

The thought process of following content would be

  1. Recap for how blockchain works and the root cause of its 3 limitations
    – Transactions Per Second
    – Transactions Confirmation Time
    – Probabilistic Finality
  2. How DEXON is structured to break those 3 limitations

Let’s see how blockchain works.
In this view, blockchain is a distributed ledger linked by hash value.

A visual demo

By viewing the visual demo, you would know how easy it is to spot someone who is trying to forge any bit of data in the past and the amount of time that find the nonce is to create a boundary for those bad people.

However, finding nonce mechanism(proof of work) to secure the network are the root cause of a blockchain three limitations. Let’s take Bitcoin as example.

Overview of Bitcoin

Limitation 1 + 2 — Transactions Per Second/Confirmation Time

Since there are fixed number of transactions in each block, and the block producing time is fixed to 10 minutes. In result, Bitcoin’s TPS is 7 and its confirmation time is 10 minutes.

Limitation 3 — Probabilistic Finality

Because Bitcoin chose the proof of work consensus algorithm , and the algorithm’s rule is that whoever has the longest chains would be considering as correct chain. In result, a transaction that is written on the blockchain is probabilistic.


Let’s see how DEXON to break those limitations.

If the throughput of a single chain is low, what not having multiple chains simultaneously?
multiple chains simultaneously
However, how can we have a "globally ordering" of all the blocks?
total-ordered algorithm with multi-chains running in parallel
Once we have multi-chains structure with total-ordered algorithm
We can scale up the entire the entire DEXON network linearly by speeding up "single chain"

Single Chain Algorithm

Before introducing DEXON’s single chain algorithm,
let’s talk about two important primitives

primitives: Threshold Signature primitives: Byzantine Agreement

Threshold Signature

To have a threshold signature considering valid without all participants participated

threshold signature

Suppose we use a (5,3)-threshold signature
Every three signature shares can produce a threshold signature

primitives: Threshold Signature
primitives: Byzantine Agreement

Byzantine Agreement
Bring processors to agreement despite a fraction of bad processors behaving to disrupt the outcome

Byzantine Agreement

DEXON Byzantine Agreement
Byzantine agreement (BA) helps all the miners agree on who can issue the next block

Byzantine agreement (BA) helps all the miners agree on who can issue the next block

Once we have those two primitives understanding, let’s dive into DEXON’s single chain algorithm.

Nodes set Selection
Node set - people who stake money
Function: has a chance to be selected in CRS set or Notary
CRS set - selected from Node Set
Function: responsible for generating common reference string for all the users
Notary set - selected from Node Set
Function: responsible for maintaining a single chain

Node set
The reason to become one of the Node set is the same as becoming a miner for Bitcoin network.

Node set - people who stake money
Function: has a chance to be selected in CRS set or Notary
CRS set - selected from Node Set
Function: responsible for generating common reference string for all the users
Notary set - selected from Node Set
Function: responsible for maintaining a single chain

CRS set
to serve as a good random seed for DEXON’s single chain algorithm

Ri -> Previous Random Seed
Tsig -> Threshold Signature
Node set - people who stake money
Function: has a chance to be selected in CRS set or Notary
CRS set - selected from Node Set
Function: responsible for generating common reference string for all the users
Notary set - selected from Node Set
Function: responsible for maintaining a single chain

Notary set
members in notary set
have right to propose a block
: participate in Byzantine agreement for consensus
: sign a threshold signature on the valid block


Let’s recap, we have two primitives and three different type of Node Set.

primitives: Threshold Signature
primitives: Byzantine Agreement
Node set - people who stake money
Function: has a chance to be selected in CRS set or Notary
CRS set - selected from Node Set
Function: responsible for generating common reference string for all the users
Notary set - selected from Node Set
Function: responsible for maintaining a single chain

With those five components, we are able to create DEXON’s single chain algorithm.

DEXON’s single chain algorithm overview

Now we have a fast single chain algorithm, let’s dive in blocklattice structure.

Within multiple chains structure. Conceptually, all participated nodes needs to have a global/single view to determine the order of each transaction in order to avoid the same transaction spend in two different chain.

The blocklattice is formed by ack (acknowledgement) relation.
A first node sends message to second node, the second node replies “I receive the message.” That is called “ack.”

all purple arrows are “Ack”

The ordering of all blocks will be the same among each node’s output with causality preserved.

DEXON achieve the global/single view across different Nodes by the algorithm called total-ordering

We will dive into total ordering algorithm in my 「005 | DEXON | Overview of DEXON | Programmer Explain」


DEXON breaks the limitations of a traditional blockchain by running multiple chains in parallel with total ordering algorithm and reach its consensus via DEXON Byzantine Agreement.

Traditional Blockchain Limitation
- Low Transactions Per Second
- Transactions Confirmation Time
— Probabilistic Finality

Free to join DEXON social groups
Telegram/Gitter/Github/Reddit

Leave a Reply

Your email address will not be published. Required fields are marked *