Dora Network’s Vision and Technologies
Dora Network is a highly parallelized, high performance public blockchain with zero transaction fees. Current public blockchains are facing performance issues and are constraint to support more applications. Dora solves this problem from 3 aspects: vertical expansion, horizontal expansion and consensus algorithm. This article will briefly explain Dora Network unique technical advantages and our vision. Dora Network’s white paper can be downloaded at our website: https://dora.network.
1. Vision of Dora Network
As the next generation public blockchain, the goal of Dora is to become a public chain that everyone can use with ease. Dora introduces a brand new Blockchain architecture designed to meet the needs of global business activities. Inspired by the pipeline model and branch prediction systems that are currently applied in many applications in CPU, our core members are trying to apply these technologies and ideas into Blockchain area, creating a unique solution dedicated for the scalability problem of Blockchain. The solution can substantially increase the performance of the Blockchain without compromising its security and decentralization characteristics.
2. Vertical Expansion
There are two types of expansion solution in traditional Blockchain: state channel and Multi Chain sharding. Serialization mechanism is taken as the assumption by all of these solutions when in transaction, because the serialization of the transaction enables each miner node to perform and verify independently. The same output result obviously can be obtained after the same serial operation starting from the same genesis block.
The TPS of the system is always constrained by the performance of a single node definitely because the serialization of transactions. However, we need to think about it carefully, is serial execution the only option for transactions? Can we do parallel processing at the transaction level in order to design a vertical expansion technology?
2.1 Normal Transaction Parallelization
The account is regarded as a node. When transaction occurs from account A to account B, an arrow is added between node A and node B, the number next to the arrow indicates the transaction amount. Thus, a list of transactions within a block can form a diagram. Let’s look at an example, assuming that a block contains the following transactions. {A transfers 10 tokens to B, and transfers 5 tokens to C, D transfers 3 tokens to F, E transfers 2 tokens to G }, As shown in figure below.

From the diagram, it is obvious that the whole transaction set is divided into three sub connected graphs. {A,B,C}, {D,F}{E,G}. Tansactions in the same connected graph can only be executed sequentially because of dependencies. But in fact, transactions in different connected graphs can be executed in parallel. For example, the execution sequence between D to F and E to G is different only in the middle temporary state, but it does not affect the state that the block eventually reaches, and in the real Blockchain world, we can easily find a set of transactions without dependency.
2.2 Smart Contracts Parallelization
The execution logic of a smart contract can be considered as two parts: the first part is EVM explanation and execution marked by white, and the second part is what truly change the world state and marked by gray. The grey part is the key component which influence the final world status. Dora Network will collect the world state of the external account that the smart contract relies on during an execution process of the smart contract, and can also collect the world state of the external account that is affected ultimately.
The two smart contracts are considered connected as long as there are intersections in account sets which rely on and change by these two smart contracts. In this way, all the smart contract transactions in a block can be divided into different connected subgraphs, and each subgraph can be executed in parallel. Please see figure below:

3) Horizonal Expansion
Dora also supports horizontal expansion of the Blockchain in the way of Hub-Zone chains. By dividing the set of smart contracts into separate subsets (basically divided by dApp), each of these subsets runs on a subchain independently, allowing the transaction of the master chain to be diverted, which is equal to performing sharding processing on the input set.
The Hub-Zone chain uses an account model, account can be shared on both Hub and Zone chain. However, for the same account, the world status will be recorded on the different chains separately. Please see diagram below for Hub-Zone chain structure.

Hub-Zone Chain
3.1 Security of Hub-Zone chain
Dora Hub chain supports a special transaction. The miners that generate blocks in the Zone chain are responsible for packing the sub block information (ChildChainBlock) that have not been recorded on the Hub chain and transferring it to the Hub chain, but it should be noted that the complete Zone block info will not be recorded on the Hub chain, only head info of Zone block will be recorded. These data are only records. The miners of the Hub chain are not responsible for verification when they perform packaging. In order to ensure the security of Zone chain data, Dora designed a new supervisor role.
The supervisor will monitor all transactions of the Hub chain and Zone chain simultaneously. When a Zone chain block package message(ChildChainBlock) is detected, it will perform verification referring to the transaction data previously received from Zone chain. Once a problem is found for Zone chain, the evidence will be submitted to the Hub chain, and the Hub chain miners will check the evidence. If the evidence is valid, the miners of this particular Zone chain will be punished.

Zone Chain Security
3.2 Data Pruning and Snapshot
To solve the problem of data explosion, the Dora Hub chain supports pruning of the Zone chain block information, and the data recorded on the Hub chain only retain the latest block data(proposed 2048 blocks in the early stage) of Zone chain , and the data prior to that can be removed from the Hub chain.
The Hub chain also supports the snapshot, and a snapshot contains the world status information of all the accounts of the current block, so that a new node can be synchronized quickly from a snapshot block, and even a secondary node can delete all the block data before the snapshot.
3.3 Cross Chain Transaction Between Hub and Zone Chain
Generally, a token will circulate only within a particular subchain, but Dora designs a special CrossChainTransaction that allows tokens in the same account to be transferred to each other between the Zone Chain and the Hub chain.
CrossChainTransaction: {
blockno: block number, rawtransaction in which block in which specific block of this transaction blockhash:Block Hash corresponding to blockno
merklepath:Merkel tree path to verify if the rawtransaction is in block( blockno). rawtransaction:{
owner: “”0xfbc2a4…ed””,
symbol: UT,
value: 100,
direction: 0 or 1 0 for from Zone Chain to Hub Chain 1 for from Hub Chain to Zone Chain
} }
As shown in the figure below, how the token UT is transferred from the Zone chain to the Hub chain.
Suppose that account A transfers 100 UT to the Hub chain, when cross chain transactions occur:
1. First A launches a special transfer transaction on the UT Zone chain, which requesting to transfer the 100 UT from the Zone account A to the Hub account A.
2. When the transaction is confirmed on the Zone chain, then awaiting miner of the Zone chain records the block information containing the transaction into the Hub chain.
3. Then on the Hub chain, A initiates a CrossChainTransaction from the Zone chain to the Hub chain, with transfer transaction in step 1, the block height and the Merkle path for Hub chain to verify;
4. The miner of the Hub chain verifies the CrossChainTransaction. If verified, it will be packaged into the Hub chain block, and the state record of the Hub chain account A is updated to transferred in 100 UT.

On the contrary, the token can be transferred back to the Zone chain from the Hub chain, the advantage of which is that the tokens are retained in the same account during the entire transfer process and do not require additional controlled accounts to be introduced as other cross chain solutions.,
At the same time, a special TokenSwapAction is designed on the Dora Hub chain, which allows to perform atomic exchange between two types of tokens, and the signature information of the two parties is required to carry, and determine whether the exchange can be performed after checks the balance of the two parties.
TokenSwapAction: { taker: “LRC”,
takerAddr: 0xfbc2a4…ed takerValue: 1000,
maker: “RDN”, makerAddr: 0xabc35e…ef makerValue: 500, takerOrderWithSignature makerOrderWithSignature
}
Through this atomic token exchange TokenSwapAction and cross chain operation CrossChainTransaction, it is easy to implement cross chain transactions between the Hub chains and Zone chain (Figure 9). Dora will create some special bridging sub chains which is able to insert other existing public chains, so that the cross chain transactions of existing chains can be supported as well.
4 DVBC Consensus Algorithm
To balance between high performance and high security requirements, Dora proposed a hybrid consensus algorithm DVBC (Delegate Verifiable BFT Consensus). DVBC is based on DPoS, VRF and BFT. Assuming that there are M nodes, N + 1 nodes are selected in total, and the initial value of N is 21. At the beginning of each round of consensus, Dora first uses the first layer algorithm DPoS to select the number of top N/3 nodes from the number ofM nodes according to the size of the vote, and these nodes will automatically become the bookkeeper of the current round. In second layer algorithm, the remaining nodes M − N/3 are selected as candidates. In these nodes, the VRF algorithm is utilized, the 2*N/3+1 candidate nodes are selected randomly as the bookkeepers. In the last layer, we use the BFT algorithm to reach the consensus of the blocks among these selectd N + 1 bookkeepers. This ensures that as long as there are no more than N/3 fraud nodes in the N + 1 nodes, the correctness of the blocks is guaranteed and there is no fork at all. Obviously, this algorithm can prevent super-nodes from frauding jointly. Additionally, because the candidate nodes also have the probability to be selected as the bookkeeper, this economic incentive mechanism motivates more nodes to be selected as candidate nodes, thereby improving the security and robustness of the network.
Considering each dApp has the different requirements for security and performance, it is allowed in Dora to specify which consensus algorithm for subchains to be used when creating subchains: DPoS+VRF, BFT, or both.
4.1 BFT Parallelization
For four states of a block, propose, prevote, precommit, commit, assuming their corresponding time are T1,T2,T3,T4, the time needed to genterate and confirm Nblocks by serial execution is N∗ (T1 + T2 + T3 + T4).
From the point of view of pipeline, the four states can be executed in an orderly and parallel manner. Ideally, as shown in Figure 11, the time required to generate and confirm N blocks in pipeline mode is N ∗T1+T2+T3+T4. When N is large enough, after this pipelining operation, the time is approximately N ∗ T 1.

