Open in app

Sign in

Write

Sign in

DEXON vs 25 blockchain projects

An overview of current blockchain technology in comparison to DEXON

DEXON
DEXON
19 min readFeb 7, 2019

--

Introduction

This document explains how DEXON is different compared to other blockchain infrastructures. We do our best to explain the main differences but take note of the following when reading this:

  1. We will not dive into details of other projects. We only focus on the differences. For the details, please refer to their websites and whitepapers.
  2. The comparison is based on our current understanding, and projects can be updated frequently. We will update this document if necessary.

EDITOR’s NOTE:

This is originally posted on DEXON’s GitHub, updated as of April 2019. The article below may appear different from the original as it has been annotated for clarity and brevity.

DEXON

DEXON is a scalable, low-latency, energy efficient and inter-chain operable DApp ecosystem. DEXON uses an efficient Byzantine agreement as its main consensus algorithm, of which throughput can scale linearly with the number of nodes while latency remains nearly constant. With the adoption of verifiable random function, DEXON can provide high performance while keeping the network decentralized (~ 100K nodes). With such high throughput and low latency, practical DApp can finally be developed and widely used.

Table of contents

ii. Definition of terms

  • Node in this document is a validator or a full node in the network.
  • n: number of nodes
  • For the smart contract column:
    • O: Supported
    • X: Not supported
    • △: Currently not supported, but can be supported

ii. Blockchain technology overview

The image below highlights the throughput (TPS), network speed (latency measured in seconds), the type of data structure used, what technology is used to reach blockchain consensus, and smart contract support of all 25 blockchain technology projects included in this list (26, including DEXON).

You can refer to this table as you read through the project in the list.

This list is originally posted on DEXON’s GitHub

A. Blockchain technology (alphabetical)

1. Algorand

Algorand is designed for a larger population (500K~ nodes). They use a verifiable random function to protect nodes from DDoS attack, and it is the lottery that decides who have the right to propose a block or to vote for each round.

The consensus of Algorand is based on Byzantine agreement among samples from the whole set of nodes. This is the reason why Algorand can only tolerate less than one-third of the total number of nodes. Similarly, the gossip mechanism used in Algorand could make confirmation time longer when the number of nodes increases at different locations worldwide. With these limitations, the confirmation time could be around one minute if the number of nodes is expected to go beyond 500K. Another factor that will affect the confirmation time is Byzantine behavior. If a Byzantine node wins the lottery and becomes a leader, the process of the Byzantine agreement will need more rounds to converge. On the other hand, DEXON’s confirmation time is not affected by Byzantine behavior as long as the number of Byzantine nodes is less than one-third of the total nodes.

If Algorand wants to increase its throughput, it must increase block size. However, increasing block size causes a longer network delay, increasing the confirmation time. This means scalability could be an issue for Algorand. On the other hand, DEXON increases throughput by increasing the number of nodes without affecting the confirmation time.

2. Bitcoin

Bitcoin is the first cryptocurrency that ushered in all other blockchain technology. It is the most well-known and widely used cryptocurrency. However, it is infamous for its long confirmation time, low TPS, and high transaction fee. DEXON solves all of these while providing DApp functionality, which Bitcoin cannot.

3. Cardano

Cardano is the first project that provides a concrete mathematical proof on the security of PoS blockchain. Aside from PoS, they also propose other promising ideas such as unbiased randomness with the commit-reveal scheme and using Nash Equilibrium to prevent selfish mining attack. However, its chain-based structure naturally limits its throughput, since chain-based structures can only process block linearly, and can be proved that it can not scale.

Another problem in Cardano consensus is that it highly depends on time synchronization. If some honest nodes are desynchronized (for example, NTP service is hijacked by an attacker), the starting time of a slot will be hard to determine (if possible to determine at all) and will be treated as fail-stop nodes. They claim desynchronized nodes could be corrected by some method introduced in the future, but it is not implemented yet.

4. Conflux

Conflux is a graph-based PoW consensus based on the GHOST protocol which fixed the Phantom blockchain. Conflux uses the GHOST protocol to select the main chain in a graph and produce a totally-ordered graph on the main chain. Thus, it is can be considered as a Bitcoin consensus, and they also identified a bias problem in Phantom.

Moreover, the latency is bounded by its PoW mechanism. It needs some to select the correct and consistent main chain with high probability. Even if it switches to a PoS mechanism, the latency would still be unacceptably long since the GHOST protocol also has a “longest chain” rule consensus.

5. Dfinity

Dfinity is a permissioned blockchain and is designed for a large population (around 10K nodes). Dfinity contains a randomness beacon which generates new randomness by a VRF (verifiable random function) with information from a new confirmed block. They use the randomness to select a leader and electors for a round. By hypergeometric distribution, Dfinity only samples hundred of nodes to notarize a block instead of using all nodes, and this is correct with high probability. However, this reduces the tolerance ability to Byzantine nodes. For example, to achieve a non-Byzantine majority of nodes with good probability, it needs to sample at least 423 nodes from 10K nodes with a maximum of 1/3 Byzantine nodes. Nevertheless, Dfinity is chain-based, so its throughput is limited.

6. EOS

EOS reaches high throughput and low latency. They have 21 so-called “supernodes,” which can be considered as not true decentralized. Also, at the time of writing, its Byzantine fault tolerance consensus is not implemented yet, so the confirmation time is about 165 seconds, not 1 or 2 seconds as they claimed.

7. Ethereum

Ethereum is the first blockchain system that has a complete DApp ecosystem. It has a throughput that is higher and latency that is lower than Bitcoin—but still not enough for common applications that require large infrastructure such as payment or gaming. A popular DApp can block the whole system, causing high transaction fees. Also, its current speed (now at several minutes) is not ideal for real-time applications.

8. Hashgraph

The consensus of Hashgraph is adapted Byzantine agreement on a graph, while on the other hand, the core of DEXON consensus is a responsive Byzantine agreement algorithm. Their round-based structure costs latency for each round, which means its confirmation time becomes longer when the number of nodes increase. With this limitation, it cannot be fully decentralized as the confirmation time can take minutes. Also, liveness is not guaranteed in Hashgraph and only the correctness proof is provided. With Byzantine nodes presented in its network, it is possible that Hashgraph cannot output any block. Meanwhile, DEXON’s confirmation time remains constant as the number of nodes increases. Since DEXON consensus has responsiveness, the confirmation time only depends on the actual network speed, not some predefined paramters.

9. Hyperledger

Hyperledger (specifically, Hyperledger Fabric) is a distributed ledger designed for enterprise use. It’s permissioned, low-latency, high-throughput, and provides private transaction functionalities. Its consensus is modularized and pluggable. It can choose among consensus engines/algorithms such as Tendermint, PBFT, Kafka ordering ,or RAFT.

It is much easier to address consensus problem in a permissioned consortium setting with high throughput and low latency because the assumption of the environment is: the number of nodes is fixed, each identity is known, the goal of all nodes is the same, and the network environment is stable and fast, but the node does not fully trust to each other. While these settings may not be suitable for enterprise use, DEXON aims to be more open and decentralized, providing high throughput and low latency at the same time.

10. IOTA

IOTA follows the longest chain rule on a graph: a node randomly chooses and verifies two previous blocks and attaches its block to them. A block is confirmed if enough number of blocks followed it and the length of the connected chain is the longest. However, the rule is inefficient because the confirmation time is not guaranteed by a specific bound. Moreover, a block might be invalid if it is attached to a block that contains conflicting transactions. That block has to be re-attached to other blocks and may cause a very long confirmation time. Furthermore, IOTA does not support smart contracts due to the lack of total ordering among all blocks.

11. Kadena

Kadena aims to solve the scalability issue of blockchain. It uses Chainweb to process transactions in parallel. Each chain includes others’ block headers, forming a DAG similar to the DEXON blocklattice. To perform cross-chain transactions, one has to provide Merkle proof to the smart contract, and assets will be deleted from the source chain and re-created on a destination chain. Kadena also analyzes peer header relationships and uses specifically designed graphs that have a small diameter and large order to achieve low latency and high throughput.

The latency of Chainweb partly lies on the diameter of a graph. When it scales and increases the number of chains, the diameter of the graph also becomes larger, causing latency to increase. Another problem can occur when a block is proposed on a chain. The block has to include its peer’s block headers. This means that block proposing is blocking and not efficient, while in DEXON, a block actively acks any other newly proposed blocks, achieving fast, non-blocking block proposing.

12. NANO

NANO is the first project that introduced blocklattice as their data structure. Each account has its blockchain, and the transactions it proposes is recorded on its blockchain. When a blockchain fork happens, NANO uses DPoS voting to resolve it.

DEXON chain structure is entirely different from NANO’s. In DEXON, instead of every account having its blockchain, each validator has a blockchain. This could save a lot of memory space. In DEXON’s blocklattice, each vertex is a block, while in NANO, each vertex is half of a transaction ( send tx or recv tx). In our point of biew, their blocklattice is more akin to a “tx-lattice,” not blocklattice, and we consider blocklattice a general term that can be used by other projects, just like blockchain, since it is just a type of DAG.

DEXON’s consensus algorithm is also completely different from NANO’s. Validators in DEXON rely on DEXON fast Byzantine agreement algorithm to decide sequence of blocks and transactions, while NANO does not have consensus on the order of transactions. Without ordering transactions, it can not support smart contracts. Another problem is its DPoS to resolve forks. The voting process NANO used to resolve fork is mysterious. In its whitepaper, there is no detail about the voting process. The only thing we know is that there is a majority voting with 4 rounds. Without further details and security proof, the security in NANO can be met with skepticism. Also, NANO needs PoW to prevent spam (penny) attacks, increasing the cost of attack but also limiting its throughput and increasing its latency.

13. Omniledger

Omniledger aims to solve scalability issues without sacrificing security and decentralization. Its primary approach is sharding, which allows the throughput to scale linearly with the number of nodes. Omniledger also provides nice features such as ledger pruning, cross-shard transaction, and trust-but-verify validation.

A perceived problem with Omniledger is that its latency could be large in a fully decentralized setting. The reason is that it uses ByzCoinX (which is an optimization of PBFT-like consensus algorithm) for intra-shard consensus and Atomix (DB-like atomic broadcast) for inter-shard transactions. This means the group size in a shard for communication cannot be too large, or the communication cost and latency will be large. To increase the number of nodes with limited shard size, the number of shards will increase, and the needs for cross-shard transactions will also increase. With atomic broadcast, a cross-shard transaction has to wait for every involved shard to be confirmed, and even a single failed shard will cause the transaction to fail. In DEXON, transactions only need to enter one shard and will be output immediately.

Omniledger also sacrifices some security. According to hypergeometric distribution, if the sampled Byzantine nodes in a shard must be less than one third, one can only tolerate Byzantine nodes much less than one third in the whole network, or sampling cannot be successful with high probability. This is why the number of Byzantine nodes Omniledger can tolerate is one fourth, not one-third of total nodes.

14. Ontology

The Ontology consensus algorithm, Ontorand, uses randomness from the last block to generate new block proposers and validators. Its Byzantine agreement voting process (although not detailed enough) looks extremely similar to Algorand. Its verifiable random function, which generates randomness in a block, is exactly the same as Algorand. Without any citation and improvement from Algorand, Ontorand seems to be very similar with Algorand. For the comparison to Algorand, please reference here.

15. Orbs Helix

The top priority of Helix is fairness. It uses VRF (verifiable random function) as an unbiased random source to elect the committee and leader. When running its core consensus (PBFT), all transactions are encrypted by users using threshold encryption. This means there is no way a node can censor or prioritize any transaction. After consensus is reached, the content of a block is then decrypted, and transactions are executed. Thus, the order of transactions cannot be biased, achieving fairness. Helix also uses VRF to decide which transaction can be put into a block. Because nodes cannot decide which transactions are to be put into a block, transaction fees can be set to a constant.

Unfortunately, fairness does not come without cost. Threshold encryption not only increases computational costs but needs an extra phase of decryption. This increases the latency. Moreover, its chain structure is not scalable. To solve the scalability problem, Orbs introduces “intelligent sharding” (which we did not find any technical details of). A recent simulation shows that Helix has only 10 TPS (with unknown latency). With 100 shards, it can reach 1000 TPS, while DEXON has 1M+ TPS with a hundred nodes in one shard.

16. Phantom

Phantom is a DAG-based blockchain which is generalized from Bitcoin’s longest chain rule on a chain to a DAG. Phantom is a proposal for Spectre, and they proposed a greedy algorithm called ghostDAG protocol to achieve total ordering. However, they did not prove the correctness and liveness of their algorithm or provide the simulation results about Phantom in the distributed setting. Another liveness attack on Phantom was individually proposed by the work from Li et al. and the work from Kiayias and Panagiotakos. They also claimed they would try to combine Phantom and Spectre in the future. We will update the information if they provide new and correct results.

In DEXON, the correctness and liveness of DEXON Byzantine agreement are both strictly proved.

17. Radix

Radix uses the sharding technique to increase throughput. In order to reach consensus among different shards, a transaction needs to be gossiped and be validated by many nodes. Each node provides its local logical clock and appends its value to the transaction. Nodes can then use this logical clock vector to decide partial ordering between two conflicting transactions. In case of a concurrent set, a node finds other transactions from its local storage or from its peer trying to decide partial ordering of transactions.

However, one can say that there is a fundamental problem in Radix: a partial ordering can never become total ordering without consensus algorithm. Some partial ordering of transactions in Radix can be decided by vector timestamps, but no matter how many transactions are involved, there always exists some cases that concurrent sets can ever resolve. In other words, orders of some transactions may never be decided and will not be output by the system. Moreover, when a network is shortly partitioned or has a long delay, nodes can have different local views. Since a node decides an ordering from other transactions from its local view, this will cause different ordering among nodes, resulting in a fork, and there is no consensus algorithm in Radix to address this issue.

To sum up, Radix does not have consensus. It can be used in private / permissioned settings but will not work in a real-network environment.

18. Snowflake

The Snowflake consensus starts from a simple coloring method, adds additional counters and rules, and finally ends up a provably probabilistic secure consensus algorithm, Avalanche. All nodes converge to the same color, which means that they will agree on the same transaction set when conflict happens.

In order to resolve conflicting transactions, nodes need to execute Avalanche algorithm on every transaction in a conflict set. Maliciously, an attacker can spam the system with a large number of conflict transactions, resulting in the system to execute Avalanche algorithm hundreds of thousands of times, and the latency will grow significantly. DEXON will not suffer from such an attack. DEXON Byzantine agreement remains fast no matter how many conflict transactions there are.

19. Spectre

Spectre is a DAG-based digital ledger system that uses recursive block voting to decide which conflict block should be finalized. This consensus algorithm allows participants to propose blocks arbitrarily fast, which means its scalability and latency is bounded to the network. However, its lack of total ordering of blocks makes it impossible to execute a smart contract. That is the reason why they propose “Phantom,” a consensus that is also DAG-based but with total ordering properties. We also compare DEXON to Phantom.

20. Stellar

Stellar uses a generalized version of a traditional Byzantine agreement protocol, which they called “federated Byzantine agreement.” This consensus algorithm requires participants to choose their own quorum slices. If quorum intersection is satisfied, it is proved that all intact participants will reach consensus.

The only concern about this kind of consensus is that whether a node can remain intact (not affected by Byzantine nodes) depends on the choice of its quorum slices. In order to have a secure configuration with fast response and stable service, it is better for a node to choose nodes set up by reliable companies or banks as quorum slices, which may lead to semi-centralization.

21. Tendermint

Tendermint uses PBFT as their consensus algorithm. Although PBFT has low latency in permissioned settings, it can not be permissionless, because PBFT has a heavy communication cost due to its two-phase commit. This means when the number of nodes increases, the required bandwidth of the network will also increase quadratically, limiting the number of nodes. DEXON uses cryptographic sortition sharding technique and configurable ack frequency to reduce the communication cost.

22. Thunderella

Thunderella combines two different consensus algorithms and tries to achieve high security with good performance. With less than one-fourth of the committee are Byzantine nodes, it can achieve a low latency with BFT algorithm. With more than one fourth, it can fall back to any blockchain system that can tolerate less than 1/2 of n Byzantine nodes.

If more than one-fourth of the committee are Byzantine nodes, Thunderella becomes as slower, while DEXON remains its low latency. Also, Thunderella is a chain-based system, and scaling can be an issue.

23. TON

TON (Telegram Open Network) is a blockchain system featuring high throughput with short confirmation time. To achieve this, they propose a new point of view called “Infinite Sharding Paradigm,” which tries to push sharding to its extreme. In TON, there is a masterchain for general state finalization. Under a masterchain, there are several workchains to perform specific tasks for different cryptocurrencies and services. If a workchain is overloaded, under it can have several shardchains to increase throughput. In each chain, validators run a BFT-based consensus algorithm with a DPoS mechanism to propose blocks. With this sharding design, TON claims it can reach several millions of TPS with 5 seconds latency.

One significant difference between TON and DEXON is that TON needs to run BFT consensus algorithm on several different levels of the chains. For the masterchain, it requires all validators to participate in BFT algorithm. Since BFT algorithm is typically not scalable, we can only have a limited number of nodes to participate in the masterchain. This can be considered a bit centralized. In DEXON, we do not require all nodes to run a single BFT algorithm; thus we can have hundreds of thousands of nodes participating in our system.

TON also has a finalization problem. It allows validators to modify invalid blocks without forking since it is more efficient and will only affect some history blocks. However, this design also allows an attacker to modify arbitrary history blocks if they can compromise the validator set. Typically, in a system with BFT finalization, it should be impossible to modify the history even if the current validator set is compromised. Even in traditional PoW scheme, launching a 51% attack and modifying history blocks has a much higher cost with low probability to success. This design may cause security issues in TON.

24. Vite

Vite mainly fixes NANO’s problem we mentioned in our comparison to NANO. It uses the same blocklattice with NANO, and adds a new consensus mechanism (HDPoS) to construct a snapshot chain. This not only solves security issues in NANO but also orders transactions, making it capable to run smart contracts. What’s more, Vite inherits NANO’s advantages, including nearly instant transactions with high TPS.

One of the difficult challenges to use a DAG structure is to decide the ordering of transactions. Vite has a global consensus group to run a consensus algorithm to create a snapshot chain. This algorithm is important because it is the key to improve NANO’s disadvantages on security and lack of total ordering. Unfortunately, we can not find any detail about the algorithm in their paper and do not know how transactions on the blocklattice are picked and put into a snapshot chain. Is this critical process secure and fair? To address this challenges, DEXON develops our own fast Byzantine agreement algorithm, and it is provably secure and reasonably fair.

25. Zilliqa

Zilliqa is an optimized PBFT. It uses EC-Schnorr multi-signature to aggregate signatures from nodes. This reduces communication costs. To address limited throughput in a chain-based system, Zilliqa uses sharding technique to process transactions in parallel. A specific shard collects micro blocks from normal shards to produce final blocks.

There are several drawbacks in Zilliqa. First, multi-signature aggregation is computationally costly. This is not a problem with ten-second finalization time, but in sub-second finalization time, it is not feasible with a large number of nodes in a shard. Second, Zilliqa uses a specific shard running consensus protocol to combine micro blocks from other shards. This doubles the latency. In DEXON, there is no specific shard to run another redundant consensus protocol. DEXON sharding mechanism is symmetric. DEXON uses state sharding, which means each shard only stores state related to itself. This sharding mechanism is symmetric, which means every shard has the same contribution in terms of consensus, and this is considered more fair.

Conclusion

In summary, there are many blockchain systems with their own strengths and drawbacks. In this article, we highlight 25 (out of who knows how many) blockchain systems that are available publicly. While we want to compare these systems with DEXON, one key takeaway we wish you as a reader to have is to understand that blockchain (or distributed ledger technology) is still in its early stages and with the innovations introduced in this infancy stage, the technology is set to mature and flourish in no time, with more available blockchain systems that could benefit a company or a person according to their specific needs.

If you wish to discuss this article or want us to add more on this list, talk directly to DEXON’s tech team through Gitter: https://gitter.im/dexon-foundation/Lobby

We welcome your opinions and want to enrich the existing body of knowledge regarding blockchain technology for the benefit of all.

Let’s talk about DEXON

You can register for the newsletter for the latest updates, or join us in our various community discussions in different platforms.

✅ Telegram discussions: https://t.me/dexon_foundation
✅ Announcements: https://t.me/dexon_news
✅ Scam alerts: https://t.me/dexon_scam_alerts

👩‍💻 Gitter (DEXON’s official dev chat): https://gitter.im/dexon-foundation/Lobby
👩‍💻 Github: https://github.com/dexon-foundation
👩‍💻 Reddit: https://www.reddit.com/r/DEXONFoundation/

👉 Twitter: https://twitter.com/dexonfoundation
👉 Faceboook: https://www.facebook.com/DEXON.Foundation/
👉 YouTube: https://www.youtube.com/channel/UCbg6l4M8QmSrJphxQvKof5g
👉 Medium: https://medium.com/dexon

Blockchain
Dexon
Dlt
Tutorial
Cryptocurrency

--

--

DEXON
DEXON

Written by DEXON

239 Followers

Empowering the Decentralized Future https://dexon.foundation

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams