Dora Network’s Perspective & Adoption on DEX
- Current status of DEX (Decentralized Exchange)
DEX stands for Decentralized Exchange. The first reaction you may have when hearing this term may be: the traffic on DEX is very small, and users’ enthusiasm is low. Below is the real stats:
Here is the ranking on current DEX trading volume on Ethereum that’s actively running: IDEX is #1, and DDEX is the runner up. The combined trading volume of these 2 is about 68% of all the DEXes combined. The total trading volume of all DEXes is about 40k ETH per day, which is about 0.2% of all the centralized exchanges.
Currently most of DEXes are based on Ethereum. After studying the data on trading pairs from centralized exchanges, the trading volume of crypto currencies based on Ethereum is only about 5% of the total volume.
Let’s take a look at the frame work of the current main DEX.
2. Main Frame work of DEX
2.1 Off-chain Matching Framework
The off-chain matching framework is consistent with the current process of centralized exchanges on the user transaction flow. The user needs to deposit before trading, and to withdraw after. The process of deposit and withdrawal is achieved through smart contract. Through this matching process, “off-chain matching, on-chain recording” method is adopted. This means that the matching process itself is not decentralized, but only the end results of the matching process is decentralized and confirmed. 0X protocol, Loopring and IDEX all adopted this framework. Loopring uses a unique “Loop Matching” technique to match multiple orders in a single transaction.
2.2 Kyber Framework
Rather than categorizing Kyber as a decentralized exchange protocol, it’s more appropriate to list it as a “digital currency bank”. Kyber protocol maintains a number of Reserves that provide the liquidity of digital currencies. Users will inquire about price through Kyber Protocol, and once Kyber Protocol finds the Reserve with the appropriate price, it will return it to the user. User will complete the token exchange with the Reserve through Kyber smart contract.
2.3 Bancor Framework
The Bancor Protocol is designed to solve the long-tail token exchange problem in the Token Economy. A larger number of small market value tokens were not able to get listed on exchanges, and the Bancor Protocol will enable the free exchange between Token & “collateral” when certain “collateral” has been obtained. Furthermore, all tokens that are traded through the Bncor protocol can be grouped together to form the Bancor ecosystem. For example, TokenA and TokenB both use Ether as collateral. Bancor can implement TokenA : Ether and TokenB : Ether transactions, logically, the exchange between TokenA & TokenB is implemented.
2.4 Plasma Framework
Plasma is a layer2 expansion technology based on Etherium. Plasma expansion technology can be utilized in areas such as DEX, social network, private blockchain, and micro payments.
Plasma framework has 2 versions currently: Plasma MVP and Plasma Cash. The basic ideas of these 2 versions are the same. Plasma Cash supports inseparable digital assets, similar to Ethereum’s ERC721 token. OmiseGo, BankEx etc. develop decentralized trading on the Plasma MVP framework, while Loom Network is developing and supporting Plasma Cash. The Plasma Debit, which supports divisible digital assets, remains in the discussion phase, and no public implementation has been found.
Plasma MVP Framework below:
Plasma sub-chain uses the trading model of UTXO. The transaction in each block calculates the Merkle root, and the operator submits the Merkle root of each block to the Plasma Smart Contract of the main chain. The users will deposit and withdraw through Plasma Smart Contract. Every user should check the Merkle root data submitted to the main chain by Operators, once there is a mistake, the user will challenge.
Plasma’s security performance is as high as the Ethereum main chain. Its security does not depend on the Operator’s integrity, but guarantees that even if the Operator is bad, the user can still safely exit the Plasma sub-chain, transfer back its asset. However, in order to ensure this, the asset transfer mechanism is particularly complicated, and the wait time is very long, and the user experience will be relatively poor.
2.5 Polkdot
Polkdot provides a demo implementation of the Ethereum side-chain, https://github.com/paritytech/parity-bridge，to illustrate user deposit, the flow charge is as follows. The relay-network is implemented between Ethereum main-chain and side-chain through POA (Proof of Authority) mechanism. The biggest problem with the current implementation is that the relay-network must be fixed before deployment and cannot be changed. This will bring the risk of potential collusion.
3. DEX’s Future and Challenges.
DEX can very well solve the core trust and security issue in transactions, but based on the DEX transaction data and current DEX frameworks, there are some problems as follows:
• DEX lacks cross-chain capabilities: currently most DEX can only support token to token exchanges on Ethereum. Under current market, Ethereum trading is relatively small (5%+/-).
• Trading speed is too slow on DEX, negatively impacting user experience: even with the off-chain matching, the transaction speed for on-chain clearing is still limited by Ethereum’s TPS.
• DEX trading depth is not enough. This issue is closely related to the previous one. The users’ trading experience and trading depth are similar to the problem of chickens and eggs.
4. Dora Network Solution for DEX
To solve the above problems encountered by the current DEX, Dora Network converged cross-chain idea and implemented a DEX side-chain solution. The user projects asset to the sub-chain through the smart contract of the main chain, and can quickly completes the transaction on the sub-chain, and finally, the asset is projected from the sub-chain to the main-chain by withdrawal request. Unlike Plasma side-chain, the security of the entire platform relies on the security of the sub-chain consensus algorithm.
One of the difficulties in the cross-chain solution is how the main chain can verify the validity of the data submitted by the sub-chain. This can be solved by requiring the data submitted by the sub-chain to have the signature data of the sub-miners, but this introduces a new problem: how does the main-chain verify the sub-chain miner’s identity. The sub-chain can monitor the data from the main-chain, but main-chain does not have any perception about the data from sub-chain. The only thing that can be done on the main-chain is to deploy a smart contract as the sub-chain agent. As long as the agent also maintains a lit of sub-chain miners while keeping this list and sub-chain miners in sync, this can ultimately solve the problem.
Above is the framework design of the overall DEX side-chain. Below we take the specific flow for deposit and withdrawal process as an example to illustrate how it works. Let’s look at the complete process for deposit:
1. User first transfers asset into the deployed smart contract on the main chain;
2. Smart contract corresponds to generate a deposit event;
3. After the sub-chain’s account node listens to this deposit event, it waits for the main chain to confirm completion (i.e., wait for 20 main-chain blocks), a corresponding deposit transaction deposit_tx is generated on sub-chain, thereby converting the asset on main-chain to asset on sub-chain;
Withdrawal operation is relatively more complicated. The complete process is follows:
1. The user first sends a request for the coin to exit_tx on the sub-chain;
2. Withdrawal requests will only be processed together on some special blocks on the sub-chain (i.e. every 100 blocks);
3. When withdrawal request collects more than 2/3 of the accounting nodes signature on the sub-chain, the accounting node on the sub-chain will submit some information of this special block to the smart contract of the main chain;
4. Finally, the user also needs to send a withdraw request to the smart contract on the main chain, the smart contract will perform final verification based on the data collected from step 3 and the transaction data submitted by user on this current step, once verified, the asset will be transferred from the smart contract to the user.
5. Dora Network Technical characteristics.
Some of Dora Network technologies can be applied to the DEX scene very well to solve the problem of low transaction speed.
5.1 EVMParallelization
Dora Network is fully compatible with EVM, so the decentralized exchange protocol based on Ethereum can be easily deployed on our side-chains, such as Looping, 0X, Kyber, etc. For the issue of DEX low throughput, Dora’s proposed solution is smart contracts parallelization. In legacy blockchains, all smart contracts within a block are processed sequentially.
The advantage of sequential processing is that implementation and verification are very simple, everyone follows the same sequential processing steps, the same results will be achieved, but sequential processing will inevitably lead to low efficiency. Is the processing of the smart contract indie the block must be sequential? The answer is no. For example, if I transfer money to you, and he transfers money to her, it doesn’t matter which transaction happens first, the end results will be the same, then these 2 transactions can be processed in parallel.
Following this concept, we collected data on Ethereum, and we discovered that close to 60% of the transactions are smart contract transactions, and 50–70% of them are not related to each other, and can be processed in parallel. Based on Amdahl’s law, if the parallelization can be improved to 80%, the processing speed can increase by 5 times.
Now let’s see how physically we will process smart contracts in parallel. Dora Network will start a number of transaction execution treads based on the number of CPUs in the machine, and divides a block production cycle into several cycles. Each cycle starts to detect possible conflicts according to the form, to of the transaction, and all the possible conflicting transactions are placed in the same execution thread and processed sequentially. At the end of the cycle, the results of the processing is inspected and merged to the global state database. Conflicts are inspected during the merging process, only one result will be selected from multiple conflicting results, and rest will be discarded, with the corresponding transaction put back into the transaction pool to be processed in the next round. The detailed architecture diagram is as follows:
For more details on Dora Network EVM Parallel framework, please read this article:
https://medium.com/@tylerkot/dora-network-introduction-to-dvbc-consensus-algorithm-afbcdedf1d2e
5.2 DVBC Tiered Consensus Algorithm
In the Blockchain world, there must be trade-offs amongst decentralization, security, and scalability. It is impossible to optimize all 3 aspects at the same time. Dora Network is to improve the security and decentralization as much as possible once we have resolved the scalability issue. The balance lies in the new hierarchical consensus algorithm we designed. It’s divided into three layers. The first layer is DPOS, second is VRF, and 3rd is BFT algorithm.
Assuming that Dora Network has a total of M nodes, a total of N+1 = 22 nodes is selected (for an intuitive description, N is set to 21). At the beginning of each round of consensus, Dora Network fist uses the DPOS consensus algorithm to select N/3 = 7 candidate nodes ranked first by the number of votes from the M nodes. Secondly, from the remaining nodes, 2*N/3+1=15 candidate nodes are randomly selected by the verifiable random number VRF algorithm. The account holder of the current round will be the 7+15=22 candidate nodes selected from the DPOS consensus algorithm and the VRF random algorithm. The consensus algorithm flow for the entire DVBC is show below:
The second layer introduces VRF with three advantages: one is that random nodes increases the degree of decentralization, and the other is to improve security. Even if the N nodes elected by DPOS collude, the nodes selected by VRF can still counter them. The third benefit is to incentivize the candidate nodes, because they also have the opportunity to get block rewards. The design of 1:2 ratio between the 2 groups is determined by the characteristics of the third layer BFT algorithm. The BFT algorithm can ensure that the whole network can achieve effective consensus as long as the bad nodes are no more than 1/3 of the total nodes.
The consensus algorithm designed in this way can also be applied to the DEX application very well. The generation of each block is deterministic, and there is no need to worry about forking.
For more details on the Dora Network DVBC layered consensus algorithm, you can read this article if interested:
https://medium.com/@tylerkot/dora-network-dvbc-consensus-algorithm-description-d4f43a587286
5.3 P²BFTConsensus Algorithm
The traditional PBFT algorithm is usually divided into four stages: the first stage produces and broadcasts the block; the second stage prevote, the node receives the block and then verifies and votes, when a node receives more than 2/3 of the votes, it knows that this block has been approved by most nodes of the whole network; but it is not enough to know it by yourself. You have to broadcast it to tother nodes that you have received the votes from most nodes. This is what the third stage, Precommit, has to do. At this stage, when a node receives more than 2/3 of Precommit, it knows that most nodes in the whole network also agree; finally, it enters the 4th Commit stage, where the block reaches a consensus on the whole network.
The four stages of the traditional PBFT algorithm are sequential, and due to network latency, it is necessary to wait for the nodes to acknowledge, causing the resource to be idle. The P²BFTadds pipeline design to the traditional PBFT consensus algorithm, streamlining multiple consensus states and improving consensus speed of the block.
Looking at this picture, if you have some understanding of the CPU pipeline processing, you can see at a glance that this is the classic four pipeline processing process. In terms of time series, we will have four blocks being processed in parallel at the same time, that is, one node can participate in Propose of one block, Prevote of another block, Precommit of a 3rd block and Commit on 4th block, simultaneously.
The experimental results show that under the Alibaba Cloud network, the TPS of the P²BFTconsensus algorithm is about 1.6 times that of the traditional PBFT TPS. It should be noted that the performance of the P²BFTconsensus algorithm is related to the time ratio of the four stages of the PBFT algorithm. If they are close, the performance of the P²BFTwill be better. Theoretically, the performance of the P²BFTis four times that of the PBFT algorithm.
For more details about P²BFTconsensus algorithm design，please read this article if you are interested:
https://medium.com/dora-network/p%C2%B2bft-consensus-algorithm-introduction-cb00ccb0cc67
Summary: Decentralized trading DEX can solve the core trust and security problems in the transaction. However, looking at the DEX transaction data and the current DEX framework, the decentralized exchanges currently have wear cross-chain capabilities and slow transaction speed. Insufficient depth and other issues affect the user’s trading experience. Dora Network adopts DVBC hierarchical consensus algorithm, EVM parallelization, PBFT pipeline consensus algorithm and other special technologies, and integrates the corss-cross-chain idea to realize a DEX side chain solution.
Dora Network grows with the blockchain ecosystem and continues to focus on the latest research trend in the blockchain field, absorbing and improving existing technologies. You are welcome to join Dora Network technology enthusiasts community, where we will regularly share technology updates. Please join the wechat group by adding ID: Blockheader.
To show our appreciation of your support, we have prepared a airdrop for this sharing. Please scan the QR code below register. Thanks again!
