TEEDAG: A High-Throughput Distributed Ledger Based on TEE and Directed Acyclic Graph

Abstract

With the arrival of the 5G era, the Internet of Things (IoT) has entered a new stage, and the amount of IoT data is growing rapidly. The traditional blockchain cannot handle massive amounts of data, which presents scalability challenges for blockchain technology. Existing blockchain improvement technologies such as off-chain payments, protocol improvements, and sharding techniques have performance bottlenecks and limitations in the data, which is rapidly growing. The blockchain is fundamentally a decentralized distributed ledger, and the traditional chain structure is inadequate for addressing concerns such as forks, double-spending attacks, and other factors in the current IoT landscape. In this paper, we propose a high-throughput distributed ledger based on Directed Acyclic Graph (DAG) named TEEDAG. We design a consensus algorithm based on self-referencing parallel chains combined with Trusted Execution Environment (TEE) to ensure the security of the consensus process. The experiment proves that TEEDAG demonstrates a significantly higher throughput compared to traditional blockchain solutions and offers improved security and efficiency compared to existing DAG-based distributed ledger solutions.

1. Introduction

Blockchain is a chain-like data structure consisting of chronologically linked blocks [1]. The essence of blockchain is a decentralized distributed ledger based on chains, which ensures the immutability and unforgeability of blocks through cryptography. Blockchain can ensure the authenticity and reliability of recorded information, addressing the issue of mutual distrust. With the development of the times, the decentralization and tamper-proof nature of blockchain have been increasingly valued, and its role has garnered increasing attention.

As 5G and the Internet of Things (IoT) continue to develop, the proliferation of IoT devices continues. According to a report by market research firm Juniper Research, it is predicted that the amount of data generated by global IoT devices will increase from 86 PB in 2022 to 1100 PB in 2027, a staggering increase of 1140%. The number of IoT connections worldwide that enable data roaming will increase from 300 million in 2022 to 1.8 billion in 2027, an exponential growth rate of 500% [2]. The immutability of blockchain can protect the vast volume of data generated by IoT devices and provide a platform for exchanging and sharing this data. However, IoT devices typically have limited computing and storage capabilities, posing challenges in supporting the substantial computational requirements for blockchain mining [3]. At the same time, due to the large number of IoT devices, traditional blockchain technology faces challenges such as scalability and security in handling transaction delays, slow confirmation speeds, and limited throughput. It is anticipated that in the future, the data in the IoT will be massive, and traditional blockchain technology will face multiple challenges in scalability and security.

Faced with the challenge of scalability, researchers have proposed numerous solutions to improve the performance of blockchain. First, in terms of consensus algorithms, there are many consensus algorithms, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), Delegated Proof of Stake (DPoS) and various Byzantine Fault Tolerance (BFT) algorithms. The continuous innovation of consensus mechanisms has also continuously improved the performance of blockchain. Secondly, from the perspective of transaction verification mechanisms, many methods such as sharding, off-chain transactions, and multi-chain architecture have been proposed to improve the transaction processing speed [4]. Researchers have suggested enhancing the physical configuration of node machines to provide high-speed network connections for network-wide communications, thereby improving the speed of P2P network communications [5].

While off-chain payments, protocol improvements, and sharding techniques provide partial enhancements to the blockchain, they have performance limitations. As a result, the utilization of Directed Acyclic Graph (DAG) as a technological alteration to the chain structure of blockchain to improve the transaction performance of blockchain has received attention in recent years [6].

In the era of massive data, the distributed ledger based on a chain structure cannot withstand massive real-time transaction requests. Substituting the chain structure with a Directed Acyclic Graph (DAG) structure can greatly improve the scalability of blockchain [7]. This approach offers distinct performance advantages, but at the same time, there are some new challenges in the implementation of consensus algorithms and security. Many existing research proposals are only theoretical designs and consider security and specific implementation less.

The DAG ledger, as an emerging distributed ledger technology, has attracted widespread attention in the blockchain field. Compared with traditional blockchain technology, the DAG ledger adopts a data structure, Directed Acyclic Graph, which allows transactions to be processed in parallel, thereby improving the throughput and processing efficiency of the ledger. However, at the same time, the DAG ledger also faces many security challenges. For example, since the DAG ledger is no longer a single chain structure, there are new problems in ensuring transaction order and integrity. In addition, network attacks and malicious behavior may also pose a threat to the security of the DAG ledger. Therefore, to facilitate the widespread adoption of the DAG ledger, it is necessary to consider how to solve these security issues and take corresponding measures to ensure the security and reliability of the DAG ledger.

This study presents and implements a high-throughput distributed ledger based on Trusted Execution Environment (TEE) and Directed Acyclic Graph (DAG). This study enhances the scalability of blockchain transactions by designing a consensus algorithm suitable for DAG distributed ledgers and integrates TEE and encryption technologies to ensure security and privacy.

Section 2 of this paper discusses related work. Section 3 introduces our proposed system model. Next, Section 4 describes the design details of distributed ledgers based on DAG. Section 5 introduces Trusted Computing based on TEE. Section 6 explains the experiments and results of this study. Finally, Section 7 summarises our findings.

2. Related Work

Through research and analysis of existing DAG-based distributed ledgers, this study categorizes them into four types based on their structure: main chain-based DAG, parallel chain-based DAG, natural topology-based DAG, and hierarchical-based DAG.

A DAG ledger based on the main chain can clearly analyze the security of the entire DAG structure by identifying a main chain in the DAG. It can also facilitate the global sorting of the entire DAG distributed ledger. Main chain-based DAG ledgers include Ghost [8], Inclusive [9], Byteball [10], Conflux [11], DAG DLT [12], Occam [13], ORIC [14], etc.

The structure of a parallel chain-based DAG ledger is clear, with each node maintaining its chain, which is interconnected to form a DAG structure. Analyzing its security is relatively straightforward, but it requires the design of a special consensus algorithm to achieve total transaction ordering. Parallel chain-based DAG ledgers include Hashgraph [15], Dexon [16], Nano [17], Jointgraph [18], OHIE [19], Teegraph [20], DAG-Rider [21], etc.

The structure of a natural topology-based DAG ledger is more complex, making security proof more challenging. Each block in DAG ledgers can reference one or more blocks, and most DAG ledgers use voting-based consensus algorithms. The total order of transactions also requires a more complex consensus algorithm design and implementation. Natural topology-based DAG ledgers include DagCoin [22], Spectre [23], IOTA [24], Meshcash [25], Avalanche [26], G-IOTA [27], E-IOTA [28], Phantom [29], Blockgraph [30], UL-blockDAG [31], etc.

The structure of the hierarchical-based DAG ledger is clear. Due to its simple and deterministic structure, it is relatively easy to analyze the security of hierarchical-based DAG ledgers. The blocks in each level can only reference the previous level’s blocks, forming a regular DAG structure that facilitates easy transaction ordering. Hierarchical-based DAG ledgers include CoDAG [32], L-DAG [33], etc.

Through research and analysis of existing DAG solutions, it can be found that DAG ledgers have advantages in performance and throughput. However, there are still some issues in security, resource consumption, and other aspects. Specific problems are analyzed in

Table 1. Analysis and Comparison of Schemes.

Scheme	Year	Design	Problem
Ghost [8]	2015	Main chain	Low scalability, high resource consumption
Inclusive [9]	2015	Main chain	Low scalability and security
DagCoin [22]	2015	Natural topology	Low scalability and security
Byteball [10]	2016	Main chain	Uncertain transaction confirmation
Hashgraph [15]	2016	Parallel chain	Complex code Not open source
Spectre [23]	2016	Natural topology	Smart contracts are not supported
IOTA [24]	2016	Natural topology	Not completely decentralized
Meshcash [25]	2017	Natural topology	Low security High resource consumption
Dexon [16]	2018	Parallel chain	Single chain consensus
Conflux [11]	2018	Main chain	High resource consumption
Nano [17]	2018	Parallel chain	Insufficient scalability Contract not supported
Avalanche [26]	2018	Natural topology	High resource consumption Contract not supported
Jointgraph [18]	2019	Parallel chain	Weak centralization
G-IOTA [27]	2019	Natural topology	Optimized for IOTA
E-IOTA [28]	2019	Natural topology	Optimized for IOTA
OHIE [19]	2020	Parallel chain	High resource consumption for Pow
Phantom [29]	2020	Natural topology	Based on Spectre
Blockgraph [30]	2020	Natural topology	System not implemented
UL-blockDAG [31]	2020	Natural topology	Graph clustering algorithm is slow
CoDAG [32]	2020	Hierarchical	High resource consumption for Pow
DAG DLT [12]	2021	Main chain	High resource consumption for Pow
Occam [13]	2021	Main chain	High resource consumption for Pow
ORIC [14]	2021	Main chain	High resource consumption for Pow
Teegraph [20]	2021	Parallel chain	System not implemented
DAG-Rider [21]	2021	Parallel chain	Long time for consensus
L-DAG [33]	2021	Hierarchical	Delayed change in layer width

below.

3. System Design

3.1. System Architecture

Through the analysis of existing DAG-based distributed ledger solutions, a clear and concise system framework structure is designed. The architecture design of the DAG-based distributed ledger is presented in Figure 1 below, where the lower layers provide services to the upper layers, and the upper layers extend the functionality based on the lower layers.

The storage layer of the DAG-based distributed ledger consists of several components, including a log module, a relational database module, a lightweight database module, a key-value (KV) database module, and a serialization module.

The data layer of the DAG-based distributed ledger consists of several modules, including the block module, DAG structure module, hash function module, encryption algorithm module, and timestamp module.

The network layer of the DAG-based distributed ledger consists of several modules, including the P2P network module, transmission mechanism module, and validation mechanism module.

The consensus layer of the DAG-based distributed ledger consists of two main modules: the consensus algorithm module and the total order consistency module.

The incentive layer of the DAG-based distributed ledger primarily includes the Token module.

The application layer of the DAG-based distributed ledger primarily includes the DAPP module and API module.

The DAPP module caters to future smart contract or DAPP development needs. The application layer’s development is still evolving and involves various areas such as asset management, digital finance, identity authentication, healthcare information management, and more. The API module prepares for the subsequent adaptation of front-end pages.

3.2. System Model

TEEDAG is a consortium blockchain; its system model is shown in Figure 2. TEEDAG uses Docker technology to achieve virtualization deployment by deploying different containers in Docker. Docker containers comprise various components such as management, nodes, and database. Each node acquires information about consortium chain members, permission details, and organizational information through the management interface and connects to the P2P network using the node server. In addition, each node establishes a consistent DAG ledger through specific consensus algorithms and stores the block information in a local key-value database for efficient retrieval.

4. Design of Distributed Ledger Based on DAG

4.1. Parallel Chain Based on Self-Referencing

This paper proposes a novel DAG structure built upon self-referencing parallel chains. In this structure, each node maintains an independent parallel chain. When nodes publish blocks, a specific parent hash pointer is required to connect to the node’s parallel chain, thereby establishing the desired self-referencing parallel chain structure. Furthermore, to facilitate inter-chain referencing, an additional pointer called the proof hash reference is computed and employed. The structure based on self-referencing parallel chains is shown in Figure 3.

The specific calculation method for proof hash is to first count the number of nodes(n) in the current network and then calculate the number of bits(x) to be truncated from the block hash value using Formula (1).

$$x={log}_{2}n$$

(1)

After obtaining the number of bits(x) required to truncate the block hash value, the binary number(y) of the chain pointed to by the proof hash is obtained by taking the last x bits of the block hash value.

$$y=\left(hash\left(10101010···111101011\right) | \left[x\right]\right)$$

(2)

After obtaining the binary number(y), it is converted to a decimal number(z), which represents the index of the chain pointed to by the proof hash. The hash of the latest block in this chain is then retrieved, forming the DAG structure based on self-referencing parallel chains.

$$z=Decimal\left(y_{binary}\right)$$

(3)

This structure not only increases the security and reliability of the distributed ledger but also adds randomness to block references, effectively preventing the existence of isolated blocks. In addition, through references between different chains, it can also provide a reference for the total order of blocks. The self-parent hash and proof hash are shown in Figure 4.

4.2. DAG Blocks Based on Multiple Hash References

Different consensus algorithms and ledgers require distinct block structures. For example, Bitcoin, which utilizes the PoW consensus, requires a nonce field to increase mining difficulty. Ethereum, on the other hand, introduced the concept of uncle blocks and added a field for uncle block hashes to prevent resource waste.

Due to the complexity of the distributed ledger structure based on DAG compared to traditional single-chain structures, it is necessary to define specific block structures and reference methods to ensure the consistency of the entire ledger. The implemented block structure in this study consists of a block header and a block body. The block header contains essential information such as the self-parent hash, proof hash, timestamp, block hash (MerkleRoot), version, and public key. The block structure is designed to facilitate efficient referencing and maintain the integrity of the DAG-based ledger. A visual representation of the block structure can be seen in Figure 5 below.

The self-parent hash refers to the hash of the latest block published by the same node. The proof hash is calculated by extracting the last few bits of the MerkleRoot of the block to determine which node’s latest block to reference. The timestamp indicates the publication time of the block and is used for ordering blocks. The version and public key are used to verify the correctness of the block information. The MerkleRoot is calculated using a binary tree, incorporating the hash values of all transaction records in the current block. All hash values are concatenated in pairs and then hashed as the root hash value of the previous layer until the hash value of the last layer is MerkleRoot. If any transaction is tampered with, it can be easily located by tracing the MerkleRoot.

4.3. DAG Consensus Algorithm Based on Voting

Consensus is an inevitable issue for distributed systems. It requires consensus algorithms to achieve distributed consistency in the face of potentially malicious or crashed nodes. Consensus algorithms are the process of implementing distributed consensus protocols. For example, in traditional blockchains, Bitcoin uses Proof of Work (PoW) as its consensus algorithm, Ethereum uses Proof of Stake (PoS), and consortium chains typically use Byzantine Fault Tolerance (BFT), Crash Fault Tolerance (CFT), and other consensus algorithms.

The consensus algorithm proposed in this study is as follows: when a node needs to publish a transaction, it constructs a block and broadcasts it to the entire network for consensus calculation. When other nodes receive this block application, they verify the hash, signature, permission, and other information in the block. After verification, the node broadcasts its affirmative vote to the entire network. This study also ensures the security of the consensus process by using the Trusted Execution Environment (TEE). As long as a node accumulates the affirmative votes from more than half of the total nodes, it can locally add the block to the directed acyclic graph structure. Then, the node broadcasts a block status confirmation message to indicate that it has added the block. When the number of block status confirmation messages accumulated by the node exceeds half of the total number of nodes, consensus can be considered achieved, and the block has been added to the directed acyclic graph-based distributed ledger.

Figure 6 is an example of the consensus algorithm with four nodes, where blue blocks represent the received blocks, and red blocks represent the self-generated blocks. The rules of the consensus are described in detail below. In step 1, node A and node C want to publish blocks. After building the block, node A and node C simultaneously send the block to other nodes in the network for verification and voting except for themselves. In step 2, nodes B, C, and D received the block message from node A, and nodes A, B, and D received the block message from node C. In step 3, nodes A, B, C, and D will each count the number of approval votes for the blocks built on nodes A and C. At the same time, node B starts packing transactions to build a block, step 1. In step 4, nodes A, B, C, and D will each independently track the construction progress of the block by other nodes except themselves. Meanwhile, nodes A, C, and D will verify and vote on the block constructed by node B, which is step 2. Finally, in step 5, A, B, C, and D have reached a consensus, and all nodes have built the same DAG ledger locally.

The following are the detailed steps for reaching a consensus between nodes.

Initial state: each node has the same local DAG ledger, and it is in a state of consensus. In this example, there are four nodes in the network, and both Node A and Node C want to publish a block at the same time.

Step 1: Before publishing a block, the node first needs to package its transactions to build a block. The block header and block body are set according to relevant information, and then a block is generated. Next, the node calls the TEE to compute and set the self-parent hash and proof hash of the block header and signs the block to obtain a signature. The operations involving the TEE will be explained in detail in the next section.

$$block=TEE.build\left(blocks\right)$$

(4)

$$signature=TEE.sign\left(block\right)$$

(5)

$$Node.sendBlockMessage\left(members, block\right)$$

(6)

Step 2: The node receives the block messages from other nodes and independently verifies and votes. The node verifies the information of the block, such as the hash, the signature, the timestamp, the permissions and so on.

$$check1=TEE.verfy\left(signature\right)$$

(7)

$$check2=Manager.checkBlockMessage \left(blockMessage\right)$$

(8)

Then, the node votes for the block message and sends its endorsement vote to other nodes in the network if the validation passes. Otherwise, the node discards the block message.

$$Node.sendVoteMessage\left(members, true,blockMessage\right)$$

(9)

Step 3: After receiving votes from other nodes in the network, each node validates and tallies them. The node first verifies whether the votes are valid.

$$Manager.checkVote\left(vote\right)$$

(10)

After verifying the validity of the received votes, the node counts the number of approval votes for the corresponding block based on the block message.

$$voteCount\left[blockMessage\right]=Server.count\left(vote,blockMessage\right)$$

(11)

If the number of approval votes for a certain block message is greater than half of the total number of nodes in the network after the counting process, the node will add the block to its local DAG ledger based on the block message. The node will also generate a block status confirmation message to confirm the state of the block. After successfully adding the block, the node will broadcast the block status confirmation message to the entire network.

$$Node.sendStateMessage\left(members, true,blockMessage\right)$$

(12)

Step 4: After receiving block state confirmation messages from other nodes, the node verifies and counts them. First, the node validates the block state confirmation message.

$$Manager.checkStateMessage\left(stateMessage\right)$$

(13)

Afterward, the node tallies the number of state messages for that block. If the number of state messages for a block is greater than half of the total number of nodes in the network, the node can conclude that the consensus on constructing that block has been reached by all nodes in the network, and the block can be confirmed in the DAG distributed ledger network. Nodes can also proceed with other steps concurrently without affecting each other.

$$stateCount\left[blockMessage\right]=Server.count\left(stateMessage,blockMessage\right)$$

(14)

$$localBlock=Node.build\left(blockMessage\right)$$

(15)

Step 5 indicates that nodes A, B, C, and D have reached consensus, and all nodes have built the same DAG ledger locally.

The specific algorithm process is shown in Algorithm 1.

Algorithm 1 The DAG consensus algorithm based on voting

Begin

//Build the block messages to send to the other nodes

members, permissions, organizations, nodeCount = Manager.getInfomations()

blocks = Server.build(transactions)

block = TEE.build(blocks)

signature = TEE.sign(block)

if block is null

throw exception

else

Node.sendBlockMessage(members, block)

//Receive the block messages from the other nodes

blockMessage = Net.getBlockMessage ()

if blockMessage is null

throw exception

else

blockHash,permission,version,selfHash,proofHash,signature = Server.get(blockMessage)

check1 = TEE.verfy(signature)

check2 = Manager.checkBlockMessage (blockMessage)

if check1 is false or check2 is false

throw exception

else

Node.sendVoteMessage(members, true)

//Receive the vote messages from the other nodes

vote = Net.getVote()

Manager.checkVote(vote)

if vote is true

voteCount = voteCount + 1

if voteCount > nodeCount/2

Node.sendStateMessage(members,true)

//Receive the state message from the other nodes

stateMessage= Net.getStateMessage()

Manager.checkStateMessage (stateMessage)

if stateMessage is true

stateCount = stateCount + 1

if stateCount > nodeCount/2

localBlock = Node.build(block)

//the block in local DAG is built

End

5. Trusted Computing Based on TEE

A Trusted Execution Environment (TEE) [34] refers to a secure, trusted, isolated execution environment created within a computing device. This research proposes the use of TEE to improve the security, performance, and privacy of distributed ledgers. By utilizing TEE, the integrity and expected execution of the code within it can be ensured. Thus, some computations can be offloaded to the TEE environment to reduce the cost of achieving global consensus and improve the performance of the distributed ledger.

Common TEE-embedded hardware technologies include Platform Security Processors (PSP), ARM TrustZone technology, and Software Guard Extensions (SGX). The common implementations of TEE software include t-base, securiTEE, OP-TEE, TLK, T6, Open TEE, SierraTEE, and others. The consensus algorithms that use TEE mainly include MinBFT [35], MinZyzzyva [36], Teegraph [20], Teechain [37], and others. This research employs TEE for experimental research and analysis, and the working principle of TEE is shown in Figure 7.

When a program executes within a TEE, its code and data undergo encryption and are stored securely in the TEE’s protected memory, which only the TEE can access. When the program is required to communicate with external entities, the TEE encrypts the data and transmits it. Upon receiving the encrypted data, the external program decrypts it for further processing. To ensure secure and reliable data transmission between the inside and outside of the TEE, the application outside the TEE must communicate with the TEE using the provided API interfaces.

5.1. Trusted Signature Technology Based on TEE

This research proposal aims to leverage Trusted Execution Environment (TEE) technology to enhance the security of the block building process, as illustrated in Figure 8. Whenever a node needs to construct and publish a block, it must use TEE to compute and verify the self-parent hash and proof hash. Only after the verification is passed can the node sign and publish the block. By using TEE, malicious nodes are prevented from constructing and publishing malicious blocks, thereby reducing the complexity of the consensus algorithm. Therefore, similar to crash fault-tolerant (CFT) algorithms such as RAFT [38] and Paxos [39], the consensus is reached when the number of confirmations received is greater than half of the total number of nodes in the network.

Algorithm 2 illustrates the block building process. Before the block is published, three TEE methods are utilized to calculate the timestamp, self-parent hash, and proof hash of the block and assign values to them. If any of these three is null, an exception is raised. Then, signing is executed and returned only when all three values are non-null.

Algorithm 2 The algorithm of trusted signature technology based on TEE

Begin

//Receive a block from the node

block.timeStamp = TEE.getTimeStamp()

block.selfParentHash = TEE.getSelfParentHash(nodeId)

block.proofHash = TEE.getProofHash(blockHash)

if timestamp is null or selfParentHash is null or proofHash is null

throw exception

else

TEE.sign(block)

return the block back to the node

End

5.2. Trusted Verification Technology Based on TEE

The research proposal presented in this article utilizes TEE to ensure the correctness of blocks when receiving block messages, as depicted in Figure 9. When a node receives a block message, it needs to employ TEE to verify the block’s signature. Since both the signature and verification processes occur within TEE, they can be deemed secure and trustworthy, thereby guaranteeing the correctness of the block and preventing malicious attacks on block messages. Only after completing the verification of the block signature within TEE can the node vote on it and proceed to the next step.

The algorithm process for receiving blocks is illustrated in Algorithm 3. Upon receiving a block message, a node initiates a check to determine if the block message is empty. Subsequently, TEE is invoked to verify the block signature only when the block message is non-empty and both the public key and signature information are present. TEE will call the verification function to determine if the signature is legal and return the verification result. The node can determine the correctness and legality of the block message based on the returned result.

Algorithm 3 The algorithm of trusted verification technology based on TEE

Begin

//Receive a block from the other node

if blockMessage is null

throw exception

publicKey, signature = get(blockMessage)

if publicKey is null or signature is null

throw exception

flag = verify(signature)

return the flag to the node

End

5.3. Trusted Sorting Technology Based on TEE

This paper also utilizes TEE to acquire timestamp information for establishing the ordering of blocks when receiving block messages. Since total order consistency serves as the foundation for smart contract execution, ensuring the proper order of blocks is a critical concern in the context of a DAG-based distributed ledger. Because the DAG itself does not have a representation of global order consistency, the algorithm is needed to establish an order. Unlike blockchain, it is more difficult to achieve a full order for blocks in a DAG-based distributed ledger due to its high scalability. This paper determines the order of blocks based on timestamp, self-parent hash, proof hash, and node number.

The sorting algorithm process is shown in Algorithm 4. When a block is referenced by subsequent blocks through the self-parent hash and proof hash, it can be considered confirmed and positioned prior to the subsequent blocks that reference it. Only confirmed blocks are eligible to participate in the sorting process. First, all confirmed blocks are sorted based on timestamps in ascending order. Due to the high concurrency of nodes, there may be two blocks with the same timestamp. In this case, the blocks are sorted in ascending order by the parallel chain number to which they belong to determine the global order.

Algorithm 4 The algorithm of trusted sorting technology based on TEE

Begin

//Get all the identified blocks from DAG

block = getEach(blocks)

timeStamp, selfParentHash, proofHash, nodeId = get(block)

if timeStamp is null or selfParentHash is null or proofHash is null or nodeId is null

throw exception

else

blocks.sort(timeStamp)

if block.timeStamp is equal and blockHash is not equal to selfParentHash and blockHash is not equal to proofHash

blocks.sort(nodeId)

else

throw exception

End

6. Experiment and Analysis

6.1. Experimental Environment

To verify the feasibility of the distributed ledger system based on TEE and DAG, this study developed a prototype system for evaluation purposes. The distributed ledger system mainly includes the management and the node. The management component is responsible for member and permission management, while the node mainly handles block publishing, receiving, and consensus. The system mainly uses technologies such as Docker, TEE, t-io network framework, lightweight database, relational database, and key-value database to construct the distributed ledger network. Docker is a lightweight virtualization technology that can package an application and its dependencies in a container to achieve quick deployment and portability of the application. It utilizes operating system-level virtualization to isolate the application environment. In this study, Docker is employed to configure and deploy the node server within the distributed ledger. Additionally, the management and database components are deployed through Docker to establish a DAG-based distributed ledger system.

Table 2. Docker Configuration.

Node	Docker Image	Simulate Object
Peer0.org1.example.com	dag:v1	Network Node 0
Peer1.org1.example.com	dag:v1	Network Node 1
Peer2.org1.example.com	dag:v1	Network Node 2
Peer3.org1.example.com	dag:v1	Network Node 3
mysql	mysql:8.0.19	mysql database server
dag_manager	manager:v1	management

illustrates the configuration of the four node containers through Docker, and the distributed ledger system connects the four nodes through a P2P network.

The hardware platform configuration of this experiment is shown in

Table 3. Performance Parameters of Experimental Equipment.

Name	Related Configurations
LAPTOP-48C72J20	Windows10; CPU i5-9300H; RAM 16.0GB; NVIDIA GeForce GTX 1660 Ti

.

6.2. Experiments and Results

6.2.1. Efficiency Testing of Distributed Ledger Databases

Distributed ledgers typically use key-value databases to store metadata of blocks, with commonly used KV databases including LevelDB and RocksDB. Distributed ledgers embed the KV database into the program and can directly call interfaces to read and write data, resulting in high efficiency.

This experiment aimed to assess the read and write efficiency of two widely used KV databases in distributed ledgers, LevelDB and RocksDB. Different numbers of messages were read and written using these two databases, and the time was recorded. The experimental results are shown in Figure 10 and Figure 11. The experiment showed that LevelDB has higher efficiency in writing, while RocksDB has higher efficiency in reading. Therefore, LevelDB is suitable for scenarios with more writes and fewer reads, while RocksDB is suitable for scenarios with more reads and fewer writes. However, as LevelDB has an advantage in writing efficiency and the difference in reading efficiency between LevelDB and RocksDB is not significant, this study opts to utilize LevelDB as the database for the distributed ledger system.

6.2.2. Throughput Testing of Distributed Ledger

The primary performance metric for evaluating a distributed ledger is throughput. Throughput is a measure of how many actions are completed within a given time frame. In the blockchain space, throughput is commonly expressed in transactions per second (TPS).

This experiment focuses on measuring the throughput of a DAG-based distributed ledger. In this experiment, each node builds, publishes, and confirms blocks concurrently. In addition, different numbers of nodes are configured to assess the impact of node quantity on the throughput of the distributed ledger. Ethereum and Hyperledger Fabric will be compared as baseline methods. Virtual machines were used to set up test networks for Ethereum and Hyperledger Fabric to evaluate their throughput in this experiment.

The performance testing was conducted using the Hyperbench distributed testing platform. Hyperbench is a high-performance, user-friendly, distributed blockchain performance testing tool that can flexibly adapt to mainstream blockchain platforms such as Ethereum, Fabric, and HyperChain. By utilizing Hyperbench, the experimental data in this study maintain authenticity and credibility.

In practical application scenarios, nodes are typically categorized as full and light nodes. Full nodes maintain copies of the entire ledger, so they must download every transaction and block that has ever occurred on the ledger. However, for most nodes that only require querying capabilities, it is unnecessary to obtain all the blocks and transactions. Instead, they only need to download the block headers to verify the authenticity of the transactions. These nodes are called light nodes. Light nodes primarily aim to conserve storage space and computing resources, and they do not participate in the consensus process of blocks. In this experiment, all nodes are full nodes, so the number of nodes set for this experiment is reasonable.

As illustrated in Figure 12, the throughput of the DAG-based distributed ledger demonstrates an increasing trend as the number of nodes increases, indicating a significant enhancement in node concurrency. The throughput of Fabric is influenced by various factors, including network bandwidth, the number of nodes, the size of the transaction, and more. Under different experimental conditions, the throughput of Fabric may vary greatly. Due to limitations imposed by environmental factors, the throughput of Fabric tends to decline under high load conditions. It should be noted that Fabric does not pursue high throughput but focuses more on scalability, security, flexibility, and other aspects. Ethereum is a classic public chain that has become very mature and stable after many years of development. Therefore, it can be found throughput of Ethereum is relatively stable and does not increase with the growth of nodes, which is also the drawback of traditional proof-of-work consensus.

6.2.3. Throughput Testing of Distributed Ledger

This study utilizes TEE for signature and verification to ensure the security and stability of distributed ledgers. Existing solutions based on TEE include MinBFT and Teegraph, which all utilize TEE as a tamper-resistant trusted counter server and provide functions such as signature, verification, and counting.

In this experiment, MinBFT and Teegraph were utilized as baseline methods for signing and verifying a specific number of messages. In addition, this experiment uses these two schemes and the proposed approach to compare relevant usage time. Specifically, 500,000 messages were signed and verified by using MinBFT, Teegraph, and the proposed approach separately, and the time spent by each method was recorded. The experimental results are presented in Figure 13 and Figure 14.

The experiment results demonstrate that TEEDAG requires relatively less time for signing messages. MinBFT not only implements the function of signature and verification but also implements the function of a counter. Since each node needs to store the counter of other nodes, this increases the resource consumption. Teegraph’s consensus protocol introduces some resource waste due to its utilization of the gossip protocol, despite reducing the number of empty blocks compared to Hashgraph. Additionally, Teegraph requires nodes to pass events into the TEE before obtaining signatures, which consumes time by comparing and storing information in TEE’s memory. In contrast, this study can directly sign after successfully calculating the hash, which is more efficient.

In terms of signature verification, the differences among the three approaches are not significant, and TEEDAG exhibits relatively lower time consumption. MinBFT, in addition to verifying the signature, also requires the verification of the counter value, which increases the time required for verification. In Teegraph, block validation requires the vote of subsequent blocks, which increases the time cost of verification. However, since 500,000 messages are signed and verified, the time consumption per message is minimal for all three approaches. Even MinBFT, which has the longest time cost, using TEE takes less than 1ms. Therefore, it can be considered that the use of TEE will not have a significant impact on the throughput and performance of the DAG-based distributed ledger.

6.3. Comprehensive Evaluation

Conventional blockchain solutions commonly encounter a “trilemma” where decentralization, security, and scalability cannot be achieved simultaneously. Additionally, high throughput often results in high resource consumption. Therefore, this paper primarily evaluates and analyzes the aspects of scalability, security, decentralization, and resource consumption.

6.3.1. Scalability

In the DAG-based distributed ledger, the presence of light nodes reduces the number of full nodes. This design has several benefits, such as increasing the number of participating nodes to some extent and reducing storage resource consumption. Additionally, as the number of nodes increases, the throughput of the entire distributed ledger also increases. In terms of transaction processing, each node in the DAG-based ledger can concurrently package transactions and publish blocks, leading to a significant enhancement in transaction processing capacity compared to traditional blockchains. Unlike other solutions, where each transaction faces wait times in the transaction pool, block publishing, and confirmation delays for the block, this study significantly increases the concurrency among nodes. It reduces transaction confirmation delays through consensus algorithms by introducing the DAG as the underlying structure of the distributed ledger.

6.3.2. Security

The security of the distributed ledger is influenced by various factors, including network architecture, consensus mechanism, encryption technology, and more. When evaluating the security of DAG-based distributed ledgers, these factors need to be considered comprehensively.

In terms of network architecture, the TEEDAG proposed in this paper is suitable for consortium chains, which are targeted at specific industries and organizations. It ensures that only approved nodes can participate in transactions and data storage, avoiding the exposure of public information and preventing malicious nodes from joining at will. Furthermore, in terms of consensus mechanism, due to the use of node audit consortium architecture and TEE, TEEDAG can effectively prevent the misconduct of nodes. Therefore, consensus among more than half of the nodes in the network is sufficient to form a consistent consensus across the entire network.

6.3.3. Decentralization

This study uses a distributed network to store and maintain the data, thereby reducing the risk of a single point of failure and improving system security. At the same time, this technology can ensure that all nodes in the network have sufficient trust in the consistency and integrity of the data. Each node can build and publish blocks autonomously, with a high degree of autonomy and relatively fair accounting allocation. However, this approach is suitable for a consortium architecture, where only approved nodes are allowed to join the distributed ledger, and due to the use of TEE technology, the degree of decentralization is reduced compared to traditional public chains. However, even the most decentralized Bitcoin was able to achieve complete decentralization only because its founder, Satoshi Nakamoto, disappeared. Otherwise, mature public chains like Ethereum would have faced hard forks due to attacks and eventually split into ETH and ETC due to human interference.

6.3.4. Resource Consumption

In terms of storage resource consumption, TEEDAG only needs to reference the hashes of previous blocks rather than containing the entire block information. This means that TEEDAG requires relatively less data storage, making it more scalable. In terms of computing resource consumption, all nodes run in TEEDAG are parallel and can simultaneously build and publish blocks. However, since the TEEDAG ledger does not require proof-of-work calculations, it does not require as much computing power compared to blockchain using proof-of-work. In terms of bandwidth resource consumption, TEEDAG transactions need to be broadcasted for publication and confirmation. Since each node can simultaneously publish and confirm blocks, it consumes more bandwidth resources. Overall, TEEDAG has higher throughput and scalability compared to traditional blockchain while ensuring the security and decentralization of the ledger through the design of TEE and consensus algorithm. TEEDAG has certain advantages in terms of storage and computing resource consumption. Still, it consumes more network bandwidth resources and requires better algorithms and protocols to optimize and further improve its performance.

7. Conclusions

In recent years, decentralized distributed ledger technology has received widespread attention and application. The distributed ledger technology based on directed acyclic graph is a new technology that aims to improve the throughput and concurrency of blockchain. Its core idea is to ensure the security and reliability of ledger data through encryption technology and distributed network technology in a decentralized environment. To realize a ledger solution that can accommodate massive and tamper-proof data from the Internet of Things, this study proposes a high-throughput distributed ledger technology based on DAG called TEEDAG.

TEEDAG proposes a solution to address the issues of latency, slow transaction confirmation, and low transaction throughput in blockchain transaction processing. It introduces a self-referencing parallel chain structure and a consensus algorithm combined with TEE suitable for DAG-distributed ledgers. The proposed approach effectively improves the throughput of distributed ledgers while enhancing their scalability and concurrency. With an increasing number of nodes, TEEDAG achieves a throughput of over 50 times that of Ethereum and over 5 times that of Fabric.

To tackle the susceptibility of blockchain operations to malicious attacks, TEEDAG introduces the signature and verification technique based on TEE. Providing a secure execution environment for data and code execution enhances the security of DAG ledgers. The proposed solution significantly reduces the complexity of the consensus algorithm and demonstrates higher efficiency compared to other blockchain ledgers based on TEE. The signature time consumption of TEEDAG is reduced by 55% compared to MinBFT and by 38% compared to Teegraph. The verification time consumption is reduced by 28% compared to MinBFT and 13% compared to Teegraph. Experimental results confirm that the involvement of TEE in the construction of DAG-distributed ledgers will not significantly affect the performance of the ledgers.

This study has limited research on incentive mechanisms in DAG-based distributed ledgers. The purpose of incentive mechanisms is to encourage more nodes to participate in consensus and incentivize honest behavior. Without proper incentives, it is challenging to ensure that nodes have sufficient motivation to generate and publish blocks, as well as to ensure the continued normal operation of committees. Incentive mechanisms can better guarantee the security and vitality of the ledger, and only suitable incentive mechanisms can build a long-term and stable distributed ledger ecosystem with strong vitality. This study still has a long way to go in researching incentive mechanisms.

Currently, distributed ledger technology based on DAG has been widely applied in various fields, such as finance, supply chain management, and digital asset management. With the continuous advancement of technology, the future prospects of distributed ledger technology based on DAG are extremely promising.