Abstract
Because of the characteristics of decentralization, immutability, and transparency, blockchain has gradually become a new and revolutionary technology, which has far-reaching significance for the development of modern technology. However, the traditional Bitcoin blockchain that supports synchronous consensus suffers from the fatal flaw of low throughput. To improve throughput, a number of DAG distributed ledgers have been proposed that support asynchronous consensus, all of which allow multiple nodes to process concurrent transactions asynchronously. However, most DAG distributed ledgers do not implement consistent sorting of transactions, making it difficult to deploy smart contracts. To overcome this problem, in this paper, an epoch-based transaction consistency sorting protocol for DAG distributed ledger is proposed, which not only provides the possibility for the deployment of smart contracts but also can be used to resolve conflicting transactions in the ledger. Transaction consistency sorting protocol provides a more reasonably ordered list of all transactions by taking scalars, such as the set of their own past and future, parent block, and timestamp. In addition, through theoretical analysis, the stability and rationality of the transaction consistency sorting protocol are proved, and there is no Condorcet cycle. Finally, the simulation results demonstrate the protocol is efficient and achieve a throughput of at least 2000 transactions per second.
1. Introduction
Since Satoshi Nakamoto published the white paper on Nakamoto and Bitcoin [1] in 2008, blockchain, as the underlying technology of distributed ledger, has become increasingly popular around the world. The immutability, decentralization, transparency, and other characteristics of blockchain ensure the privacy and security of distributed ledger, so it also promotes the rapid development of the Internet system, financial system, Internet of Things (IoT), healthcare, and other fields.
The traditional Bitcoin blockchain adopts the Nakamoto consensus, which organizes all transactions into an orderly list of the blocks. Each generated block points to its parent block and contains multiple transactions. All blocks form an irreversible single chain. The nodes (miners) participating in the Nakamoto consensus compete for accounting rights through the Proof of Work (PoW) mechanism; that is, the winner can write a new block in the ledger. Then, through the broadcast of the gossip network, we wait for the whole network nodes to reach a consensus on whether to receive the new block or not. On this basis, a new round of accounting rights competition is launched. However, with the rapid development of IoT, due to the inadmissibility of fork and low blocking rate, traditional Bitcoin blockchain faces fatal defects of low transaction throughput and high resource consumption, which cannot meet the needs of practical applications.
In order to solve the performance bottleneck of traditional blockchain (i.e., Nakamoto consensus), such as low transaction throughput. In recent years, some scholars have proposed a structure of a Directed Acyclic Graph (DAG) distributed ledger [2, 3]. In DAG distributed ledger, forks are allowed. Nodes can simultaneously release multiple transactions, and the system can also process multiple transactions at the same time. In addition, using Gossip Network [4], transactions or blocks can be broadcast to all nodes in the network in a short time. Compared with the traditional Bitcoin blockchain, this DAG distributed ledger effectively solves the problems of forks and low block generation rate, which greatly improves the transaction throughput of the system.
Although many consensus of DAG distributed ledger have emerged in recent years, the issues of block sorting has not been fully resolved. For example, Conflux [5–7] consensus achieves good throughput, and the hash value is used to solve the problem of sequence between the two concurrent blocks. However, although the hash function is very efficient, it is unreasonable to use it to sort blocks because of its pseudorandomness. In other words, if there are two conflicting transactions, the pseudorandom hash function cannot reflect the actual order between them, which may lead to the result that the attacker wins. In order to reflect the real order between transactions and achieve the goal of deploying smart contracts in the DAG distributed ledger, we propose a new epoch-based consistent block sorting protocol for DAG distributed ledger. The main contributions of this paper are as follows:(1)By selecting main blocks and determining the main chain in the DAG distributed ledger, the structure of an epoch-based DAG distributed ledger is formed. On this basis, a transaction consistency sorting protocol is designed, which not only provides the possibility to deploy smart contracts in the DAG distributed ledger but also can be used to resolve conflicting transactions in the ledger.(2)It is proved by a derivation that the proposed transaction consistency sorting protocol does not have Condorcet cycles[8] when sorting blocks in pairs, thus ensuring that our sorting results are reasonable and unique.(3)The theoretical analysis and performance estimation of the epoch-based transaction consensus sorting protocol are given in this paper. The results show that the protocol is efficient and can achieve a throughput of at least 2000 transactions per second.
The rest of this paper is organized as follows: In Section 2, we firstly introduce the related work. Secondly, we provide an overview of the epoch-based transaction consistent sorting protocol in Section 3. In Sections 4 and 5, the theoretical analysis and performance evaluation of the transaction consistent sorting protocol are given. Finally, we conclude this paper in Section 6.
2. Background
In the Bitcoin network, new transactions will first be placed in an unverified transaction pool. Miners will package new transactions from the transaction pool and then try to solve a difficult problem of PoW to prove the legitimacy of this block. The data structure of a blockchain is a single chain formed by blocks in chronological order, and the height of blocks represents the linear order of blocks. Therefore, there is no sorting problem in Bitcoin. The main problems of Bitcoin are low throughput, long confirmation delay, and high transaction fee.
In order to solve the performance bottleneck of the Bitcoin blockchain, the idea of a DAG distributed ledger has emerged. In 2013, Sompolinsky et al. proposed a consensus protocol based on the tree DAG-GHOST (Greedy Heaviest-Observed Subtree) [2, 3]. GHOST introduced weights to measure the number of blocks in the additional subtrees on each block, and reached a consensus on the order of transactions on the main chain. In 2015, Lewenbegr et al. proposed Inclusive on the basis of the GHOST agreement [9]. Inclusive protocol introduces the concept of uncle block, reaches a consensus in the main chain based on DAG and then sorts all blocks according to the main chain and topological structure.
In 2016, several blockchain consensus protocols based on DAG emerged: SPECTRE [9, 10], IOTA [11], Hashgraph [12, 13], Byteball [14], etc. IOTA is a micropayment system for IoT. It has no mining, no blocks, and no transaction fee. Anyone can participate in it, but it does not achieve the order of all transactions. Baird et al. proposed a Hashgraph [12, 13] consensus protocol based on the Gossip protocol and virtual voting algorithm, which is a completely asynchronous, decentralized, leaderless Byzantine fault-tolerant system, without PoW. Sompolinsky et al. proposed an unlicensed SPECTRE protocol allowing forks. This protocol uses a recursive weighted voting algorithm for topological sorting in blocks and is very suitable for DAG distributed ledger. However, this order is not linear, so the protocol does not support smart contracts. PHANTOM [15, 16] and SPECTRE are completely independent protocols. The difference is that the PHANTOM protocol eventually forms a linear sorting, but the order is not unique. Churyumov et al. proposed a DAG-based ledger Byteball [14]. In Byteball, the introduction of witnesses realizes the sequencing of transactions, but it also affects the complete decentralization of the system.
Colin et al. proposed a nonpermissible protocol Nano [17], which uses a lattice structure. Each node maintains its own single chain, and it can freely trade between chains. However, it is not mentioned in the consensus article on how to achieve the order of all transactions between multiple chains. In the same year, Team Rocket proposed the avalanche agreement Avalanche [18, 19]. Through the Gossip algorithm and Epidemic network, the avalanche protocol connects the original transaction to DAG and constructs four consensuses at the bottom, namely, Slush, Snowflake, Snowball, and Avalanche. Finally, a Byzantine fault-tolerant consensus family without a leader, based on metastable state and independent of PoW is formed. The order between transactions in this protocol is topological.
In 2018, Li et al. proposed a fast, scalable, decentralized blockchain system Conflux [5], which realized the throughput of thousands of transactions per second and used a hash function to reach a consensus on the overall order between blocks. In order to prevent liveness attacks [19], the team proposed another consensus GHAST in 2020. In 2019, Gupta and others proposed CDAG [20] (Converging Directed Acyclic Graph). The participants of CDAG used the Colosseum consensus to compete in pairs, and finally the winner won the right to record the new block. The CDAG consensus effectively solves the ranking problem of transactions in the DAG distributed ledger while ensuring efficiency. In the same year, Tong Zhou et al. proposed DLattice [21] with double DAG based on Nano protocol and realized the sorting between transactions.
Furthermore, Yu proposed a novel permissionless blockchain protocol OHIE [22] which explicitly aims for simplicity. OHIE composes as many parallel instances of Bitcoin’s original (and simple) backbone protocol as needed to achieve excellent throughput. In 2020, Wang [23] systematically summarizes the research on DAG technology and provides a comprehensive analysis (SoK) of the blockchain system based on DAG. They summarized the main components and characteristics of open source systems, provided a comprehensive analysis of DAG-based blockchain systems, and pointed out the promising direction of their future research by reviewing the deconstruction and academic research of open source systems. Giridharan proposed Bull Shark [24] in 2022, the first asynchronous Byzantine atomic broadcast protocol based on directed acyclic graphs (DAG). It has optimal amortized communication complexity, it provides fairness and asynchronous liveness, and safety is guaranteed even under a quantum adversary. In recent years, many efficient and secure schemes have emerged, but these schemes need to be improved in the aspect of block sorting.
Among these consensus algorithms of the DAG distributed ledger, only a few can deploy and realize smart contracts. Although Conflux supports smart contracts, the blocks in Conflux are sorted according to the hash value of the blocks, because the pseudorandomness of the hash function that cannot reflect the real order between transactions, which cannot be used to solve conflict transactions.
3. The Protocol of Epoch-Based Transaction Consistency Sorting for DAG Distributed Ledger
In this section, we provide a detailed overview of an epoch-based transaction consistency sorting protocol that is common to any DAG distributed ledger, including the motivation of research and specific scheme.
3.1. The Motivation of Research
As we all know, the DAG distributed ledger is a directed acyclic graph consisting of vertices and directed edges, represented by . Among them, is the set of vertices and it is the vertex of the directed acyclic graph, also known as the block in the DAG distributed ledger, which can contain one or more transactions. In this article, we refer to them collectively as blocks. is the set of directed edges between blocks (vertices), represents the directed edges from block to block . A specific network structure example of is shown in Figure 1, where is Genesis, and the newly added block that has not been verified is called a tip.
There are two kinds of directed edges in Figure 1, which we call parent edges and reference edges, respectively [5]. The parent edges represent the voting relationship, represented by solid arrows. Since each block has only one parent, its parent edge is also unique and deterministic. The reference edges correspond to the generation order between blocks, represented by dashed arrows. A block can contain multiple reference blocks.
Due to the use of an asynchronous concurrency model, DAG distributed ledgers allow multiple transactions to join the blockchain network at the same time, thereby significantly increasing transaction throughput. However, this method also brings some new problems. Asynchronous concurrency makes the transactions in the system do not have a clear order, so it cannot support the deployment of smart contracts, and it also brings inevitable conflict transactions to the system, which are difficult to solve.
In response to these problems, we design an epoch-based transaction consistency sorting protocol for DAG distributed ledgers. The transaction consistency sorting protocol not only provides the possibility for DAG distributed ledger to deploy smart contracts but also can be used to resolve conflicting transactions in the ledger. Furthermore, our protocol is general to any DAG distributed ledger.
3.2. Specific Scheme
Specifically, the operation of the epoch-based transaction consistency sorting protocol we designed is as follows: First, in any DAG distributed ledger, the main block is selected according to the principle of the heaviest subtree to determine the main chain. Second, the original DAG distributed ledger is converted into an epoch-based DAG distributed ledger structure according to the order of the main blocks on the main chain. Then, use epoch sorting to get the rough order of blocks. Subsequently, for each epoch, the blocks are strictly ordered according to the rules for internal fine sorting. Finally, the global consistency sorting for DAG distributed ledger is obtained by integrating all of the internal fine sorting.
In fact, the transaction consistency sorting protocol we designed can be divided into two main stages, including the construction stage of the epoch and the sorting stage of blocks. The former involves the determination of the main chain and the division of epochs, while the latter includes epoch rough sorting, epoch internal fine sorting, and global consistency sorting. Therefore, our transaction consistency sorting protocol consists of five steps, the process of which is shown in Figure 2, and the specific sorting steps are as follows.
Step 1. Determination of the main chain.
Given a DAG distributed ledger , the main chain is determined as shown in Algorithm 1.
The main chain is the heaviest chain formed by the linear connection of main blocks selected according to the heaviest subtree principle of GHOST [2, 3]. The main block is the child node selected according to the principle of the heaviest subtree of the previous main block , and it is the block with the largest value calculated according to the function of the node. Assuming that the main block is known, the operation of selecting the next main block can be formally expressed as follows:Among them, represents the main block, and represents the set of sub-blocks of block . represents the set of blocks that directly or indirectly refer to block and contain itself, and represents the number of elements in . The symbol “” represents a direct reference; the symbol “” represents an indirect reference. It is worth emphasizing that if the block with the largest is not unique, these blocks are hashed, and the one with the largest hash value is selected as the main block. Assuming that there are main blocks in the DAG distributed ledger at this time, then the main chain can be formally expressed as follows:where the symbol “” means “is a prefix of”, is Genesis.
To sum up, taking the DAG distributed ledger shown in Figure 1 as an example, according to the determination rules of the main chain, the main chain is determined as .
|
Step 2. Division of epoch.
Inspired by Conflux, we use the concept of epoch to partition the DAG distributed ledger. The traditional DAG distributed ledger divides epochs according to the blocks in the main chain, that is, each main block corresponds to an epoch. The epoch corresponding to the main block is represented by the symbol . is the epoch, and only contains a unique block (ie, the Genesis). Specifically, blocks that satisfy one of the following conditions are divided into the same Epoch :(1)main block .(2)the block that the main block can reach through directed edges, but not included in the previous epoch , it can be formally expressed as follows:Therefore, for the DAG distributed ledger shown in Figure 1, we transform it into an epoch-based architecture as shown in Figure 3. It is divided into 6 epochs: .
For convenience, we denote the ledger obtained by dividing the traditional DAG distributed ledger by epoch as . Among them, represents the blocks, represents the directed edges, represents the main chain, and represents the sequence of all epochs. The difference between the new structure and the original DAG distributed ledger is that the former contains an epoch sequence and a main chain formed by a linear link of main blocks.
Step 3. Epoch rough sorting.
Epoch rough sorting is to use the result of Step 2 division to perform the rough order of blocks. Follow the principle of time from far to near, that is, the earlier the time of is, the more priority the blocks contained in will be, namely, .
According to this rule, we perform epoch rough sorting on the epoch-based DAG distributed ledger shown in Figure 3, we have the following equation:That is, the result of the rough sorting is
Step 4. The internal fine sorting of each epoch.
The internal fine sorting of each epoch is the process of strictly sorting the blocks in each epoch. Given a transformed epoch-based DAG distributed ledger , the process of sorting any two blocks without reference relationship in is shown in Algorithm 2.
Assuming that all blocks in each epoch are to be sorted now, then we start from the first containing two or more blocks that do not have a reference relationship, and calculate the set of any two unordered blocks in . represents the set of blocks directly or indirectly referenced by block , and includes itself, which we can formalize as follows:where represents a block generated before a given block , which can be expressed as follows:Any two blocks and block that have no reference relationship in are then sorted pairwise according to the following rules:(1)Compare of block and block , where is the number of elements in set . Following the principle from small to large, the smaller the value of , the more priority the order of blocks is. There may be the following three situations:(a)If , then (b)If , then (c)If , then go to the next step(2)Calculate and compare of block and block , where is the number of elements in set . The ordering obeys the principle from large to small. The larger the value of is, the more priority the order of blocks is. Similarly, the following three situations may occur:(a)If , then (b)If , then (c)If , then jump to the next step Consider the parent blocks of block and block , namely, and , and according to the principle of the earlier the parent block, the priority of the block, we have:(a)If , then (b)If , then (c)If , then then go to next step(3)When appears, the order between block and block is determined according to their timestamp. The earlier the time, the higher the priority of the block. While the probability of this happening is extremely small, it can still happen due to network delays caused by device functionality.Through the above-given method, we can sort all unordered blocks without reference relationship in pairs and finally get the strict order of all blocks in the epoch. In addition, we prove that this pairwise sorting algorithm does not suffer from the Condorcet cycle problem in Section IV.A. The specific process of internal fine sorting of Epoch is shown in Figure 4.
|
Step 5. Integrate sorting results.
After the internal fine sorting of blocks in each epoch is determined, based on the order of each , we perform a global consistency sorting on the entire DAG distributed ledger to get the strict order of all blocks.
The epoch-based transaction consistency sorting protocol for DAG distributed ledgers is not only suitable for ledgers with parent edges, such as Conflux. In particular, it can also be used for DAG distributed ledgers with only reference edges, where we only need to determine the order between blocks based on their , , and without comparing their parents block .
To sum up, continue to sort the blocks in Figure 1, and finally we can get the strict order of the blocks as follows:
4. Theoretical Analysis
In this section, we will prove through theoretical analysis that there is no Condorcet cycle in the epoch-based transaction consensus sorting protocol, and the protocol is stable and reasonable.
4.1. Proof of No Condorcet Cycle
In this section, we first introduce the definition of the Condorcet cycle [8, 10] and then use Theorem 1 to show that our proposed transaction consistency sorting protocol does not exist Condorcet cycle (in the pairwise ordering of blocks).
Definition 1. The Condorcet cycle is shown in Figure 5. When a pairwise sorting is performed on a set of blocks , the order of block and block is , and the order of block and block is . However, the order of block and block is . This situation is called a Condorcet cycle when the blocks are sorted in pairs.
Theorem 1. Suppose there is a DAG distributed ledger, and block , and are all belong to the same epoch in , if both and hold, then . That is, there will be no Condorcet cycle in the transaction consistency sorting algorithm of the Epoch-based DAG distributed ledger.
Proof. Because when appears, there may be the following situations:(1)(2), but (3) and , but (4), and , but Similarly, because , then one of the following four conditions occurs:(1)(2), but (3) and , but (4), and , but Now, can be deduced according this pairwise ordering of and as follows:(1)If , i.e., (a)If , we have , then it is obvious that (b)If , but , then we have , then can be deduced(c)If and , but , then we have , therefore, can be deduced(d)If , and , but , then we have , therefore, it is obvious that (2) and , i.e., (a)If , we have and , then can be deduced(b)If , but , then we have , then it is obvious that (c)If and , but , then we have , therefore, can be deduced(d)If , and , but , then we have , therefore, can be deduced(3) and , but , i.e., (a)If , we have and , then can be deduced(b)If , but , we have and , then can be deduced(c)If and , but , then we have , therefore, it is obvious that (d)If , and , but , then we have , therefore, can be deduced(4), and , but , i.e., (a)If , we have and , then can be deduced(b)If , but , we have and , then can be deduced(c)If and , but, then we have , therefore, can be deduced(d)If , and , but , then we have , therefore, it is obvious that To sum up, using the block sorting rules of the Epoch-based DAG distributed ledger, when all blocks in an Epoch are sorted in pairs, there will be no Condorcet cycle, that is to say, there will be no contradictory sorting. This also shows that our sorting protocol is correct and reasonable.
4.2. Stability of Sorting under Network Latency
Considering that the state of the DAG distributed ledger is constantly updated, the set of blocks changes in real time due to the concurrent network model. In this section, according to the conclusions of Proposition 6.1 and Lemma 6.4 in the literature [25], the stability of the transaction consistency sorting protocol based on the Epoch for DAG distributed ledger is deduced under the network delay. First, we introduce two definitions ( and [25]).
Definition 2. is a set of blocks of height that directly or indirectly reference block and have .
Definition 3. Assuming that block and block are honest blocks and malicious blocks containing conflicting transactions, represents the number of times that honest blocks in the network are confirmed, then in the final consensus reached by nodes, malicious blocks replace honest blocks to proceed. The probability of sorting is defined as follows:where represents the number of blocks that directly or indirectly point to the honest block when the height is , namely,Therefore, we have the following equation:and represents the number of blocks that directly or indirectly point to malicious block when the height is , namely,
Lemma 1 (see [25]). Suppose at time , a block is included in the DAG ( represents the DAG observed by node at time ), and at time has
Lemma 2 (see [25]). For any , there is , and the minimum number of confirmations required for block is
These two lemmas have been proved in [25]. Using the Poisson distribution, the law of iterative expectations, and the law of total variance [26], the authors first obtained the expectations and variances of these random variables and then proved that approaches 0. On this basis, it is proved that the minimum number of confirmations required for block is finite (ie, Lemma 2). According to the above-given conclusions, this paper has such a derivation that if and both contain blocks at time , block is a valid block published by an honest node, and block is a malicious block broadcast by an attacker, Then, when there are blocks in , block is finally approved. Furthermore, since is finite, then for any , there is ; thus, we can get the following:
When ( is the proportion of the attacker’s computing power in the entire network), tends to ;
When , tends to 1.
That is, the best case is to wait for no more than 2 new blocks to be added to , block can be finally approved, and the recognition of block (malicious block) will also decrease with the continuous expansion of the DAG distributed ledger.
In summary, although the set of blocks will change as the network expands, the Epoch-based transaction consistency sorting is stable.
4.3. The Rationality of Transaction Consistency Sorting
In the existing DAG distributed ledger, the SPECTRE protocol determines the order of blocks based on the process of pairwise voting. However, due to the existence of the Condorcet paradox, the pairwise ordering relationship of blocks in the SPECTRE protocol is not transitive of. PHANTOM classifies blocks into honest blocks and malicious blocks by solving . Then, according to a topological sorting algorithm, the honest blocks are prioritized, and finally the total ordering of blocks is given, but solving is NP difficult question. Transactions in IOTA are not completely ordered, and there may be some conflicting transactions that cannot be successfully verified due to a lack of liveness.
Hashgraph uses consensus timestamps to order transactions and then uses XOR signatures to break the ordering tie. In Nano, transactions on a single chain are sorted according to the time they were received. The parachains of DEXON confirm each other through the reference field of the block and finally determine the global block order through these reference relationships.
In addition, although Byteball and Conflux all give a global ordering scheme for transactions, they all use hash functions when conflicting transactions occur. While sorting with hashes can improve efficiency, hashes are pseudorandom, so sorting blocks using a hash function does not reflect the true order between transactions. Therefore, this method is considered unreasonable.
As shown in Table 1, by comparing the transaction throughput of these schemes, we can find that the sorting protocol in this paper is second only to the Conflux protocol in efficiency, but when there are more than three blockchains in the system, our scheme will be superior. On the other hand, the blocks in Conflux are sorted according to the hash function, while the sorting protocol in this paper uses more scalars to give a specific and reasonable order between transactions, including the past of blocks set Past(.), future set and parent block , and the timestamp of the transaction itself. Moreover, in terms of advantages, since the hash function is pseudorandom, the block sorting result of conflux cannot reflect the real order between transactions, and it may even vote for dishonest nodes in the process of resolving conflicting transactions. However, the sorting protocol in this paper cleverly solves this problem by measuring multiple scalars to reflect the order of transactions as truly as possible, so as to avoid the serious harm caused by malicious attackers to the greatest extent.
5. The Estimation of Performance
5.1. Environment Setup
We use Golang as the programming language and Goland as the integrated compilation and development environment. Golang features easy deployment, excellent performance, a large number of built-in libraries, and cross-platform compilation. In addition, we also implement transaction consistency sorting for all DAG-type distributed ledgers by the creation and receiving of the block, the selection of the main chain, and complete sorting modules. This machine’s operating system and processor for win10 and 2.4 GHz, 4 core Inter core i5, the computing capacity of 23588 hashes per second.
5.2. Parameter Setting
The derivation process in this section follows the following assumptions and related parameters. Modeling a DAG network [2, 3] as , the entire network generates blocks with a Poisson process of rate [28]. Whenever a node creates a new block, the new block is broadcast to the entire network immediately and waits for other nodes to verify it. Assume that each edge has a network delay [3, 29], which is the time it takes for a message to reach the other end of a directed edge. Assuming that the sum of the computing power of the entire network is 1, the computing power of the attacker is , is the attacker’s block creation rate, is the block creation rate of honest nodes. Therefore, we have the following equation:
5.3. Estimation of Throughput in Main Chain
In an Epoch-based DAG distributed ledger, the creation of blocks is a Poisson process. is the average block generation rate of the entire network. TPS is the product of the main chain’s average block growth rate , block size , and average transaction size [2], which can be formalized as follows:
Proposition 8.4 in [2] and Lemma 6 in [3] both demonstrate that the main chain growth rate of the heaviest chain is: . From this we know that when all nodes follow the heaviest subtree rule, the transaction throughput on the main chain follows:
According to Proposition 3.1 in the article [2] and the data provided by Decker and Wattenhofer [30], it is known that a 50% attack has no restrictions on the choice of block size and block generation rate . At this time, TPS is only affected by the node’s physical limitations, such as bandwidth limitations, network delays. A test study of the data found a strong correlation between the size of a block and the time it takes to propagate a block [29]. Even if the size of a block is very small, there is a small delay in propagating it. Besides, for every 1 KB increase in block size, the latency increases linearly. This can be explained by the combination of the constant propagation delay of blocks on the link and transmission delay due to bandwidth constraints and block verification time, which is linearly related to the block size.
Therefore, by fitting these two influencing factors, the obtained linear model can be formalized as follows:
represents the metric value of the total propagation delay; represents the 1 KB delay metric value. After testing, the optimal parameters obtained are: , . From this, the time it takes for a block to reach 50% of the network nodes is . Therefore, for the transformed Epoch-based DAG distributed ledger, the transaction throughput of the main chain can be expressed as follows:
Based on the above-given conclusions, we estimated the TPS of the main chain in Epoch’s DAG distributed ledger. The specific parameter settings are shown in Table 2. By using the control variable method, each of the two variables in the block size , the number of transactions per KB, and the block creation rate are controlled separately to observe the impact of another variable on the TPS of the consensus main chain.
In order to make the TPS optimal, we take the optimal values for each parameter. According to Figure 6, when the parameter is 256 and the block creation rate is equal to 10, the TPS increases with the block. It increases with the increase of the size of block but tends to stabilize after a certain degree, so we take the optimal value of as 2048.
Figure 7 depicts the relationship between the TPS of the main chain and the number of transactions. With a fixed block size and 4 different parameters , it shows that the TPS on the main chain is mainly affected by the parameter . Specifically, for different , there are
To sum up, without considering the throughput of the entire DAG network, the TPS of the main chain in the Epoch-based DAG distributed ledger is quite high, reaching a transaction throughput of close to 1000 . For the entire DAG network, it is formed by main chains, so the transaction throughput of the entire network can reach . Because of , this distributed ledger can achieve at least 2000 transactions per second.
6. Conclusion
In view of the general lack of transaction consistency sorting protocol in the DAG distributed ledger, we propose a transaction consistency sorting protocol based on Epoch in this paper. The protocol uses the heaviest chain as the main chain, and the blocks on the main chain determine the epoch. Then, the blocks are arranged by epoch to get the epoch rough sorting, and then the blocks in each epoch are sorted in pairs by combining the past set future set and parent block , and finally get a global transaction order. The protocol not only makes it possible to deploy smart contracts on the DAG distributed ledger but also provides a new method for resolving conflicting transactions in the ledger. In addition, the stability and rationality of the proposed transaction consistency sorting protocol are proved by theoretical analysis, and there is no Condorcet cycle. Finally, the simulation results demonstrate the protocol is efficient, achieving at least 2000 transactions per second.
Data Availability
The data used to support the study are included in the paper.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the National Natural Science Foundation of China under Grant no. 61572019, the Shaanxi Province Key Research and Development Program under Grant no. 2020GY-006, and the Science and Technology Project of Shaanxi Province under Grant no. 2022GY-040.