A high-throughput distributed ledger system based on DAG

Abstract

The present invention discloses a high-throughput distributed ledger system based on DAG, which belongs to the field of information technology; it comprises from bottom to top: storage layer, data layer, network layer, consensus layer and application layer. The log module and lightweight database, KV database and relational database of the storage layer are the basis of the blockchain system, which are used to store the basic information of the database; the block structure, DAG module, hash function module, encryption algorithm module and timestamp module of the data layer are the basis for building the DAG ledger system; the P2P network module, transmission mechanism module and verification mechanism module of the network layer ensure the normal operation and transmission of the entire system network. The consensus algorithm module and total order consistency module of the consensus layer are distributed consensus based on the P2P network; the application layer ensures the normal operation of the DAG ledger system through interface testing and application operation. The present invention uses a trusted execution environment to improve the security of the distributed ledger based on DAG, while reducing the complexity of the voting consensus algorithm.

Description

Technical Field

[0001] The present invention belongs to the field of information technology, and in particular relates to a high-throughput distributed ledger system based on DAG (Directed Acyclic Graph). Background Art

[0002] The essence of blockchain is a decentralized distributed ledger based on a chain. Blockchain uses three core technologies: consensus algorithm, encryption algorithm and peer-to-peer (P2P) network to ensure the immutability and decentralization of the blockchain. The data of the blockchain has copies on multiple nodes on the chain, which can effectively prevent single-point attacks and losses, and ensure the security of the data.

[0003] Due to its characteristics, blockchain ensures that the recorded information is more authentic and reliable, which can help solve the problem of people's distrust of each other. However, with the advent of the 5G era, the Internet of Everything is no longer just a simple idea. Since the devices in the Internet of Things are distributed, the decentralized blockchain can enable these devices to communicate directly, and no longer need centralized servers to forward and control. The immutability of the blockchain can also protect the large amount of data generated in the Internet of Things and provide a platform for the exchange and sharing of this data. However, the devices in the Internet of Things usually have only limited computing and storage capabilities, which cannot support the large amount of computing power required by the blockchain; and due to the large number of devices in the Internet of Things, the latency of blockchain in processing transactions is high, so there may be problems such as slow transaction confirmation and low transaction throughput. It is foreseeable that the data in the Internet of Things will be massive in the future, and traditional blockchains will also face multiple challenges such as scalability and security.

[0004] With the rise of blockchain research, research on consensus algorithms has become more in-depth. However, blockchain always faces a three-dilemma: decentralization, scalability, and security. One of the biggest challenges currently faced is scalability. The number of transactions per second of traditional virtual currencies is very low and cannot be used in actual large-scale transactions.

[0005] In the face of the challenge of scalability, scholars have proposed many solutions to improve the performance of blockchain: First, in terms of consensus algorithms, from Proof-of-Work (PoW) to Proof-of-Stake (PoS) to Delegated Proof of Stake (DPoS) and various Byzantine Fault Tolerance (BFT) algorithms, the performance of blockchain in processing transactions has been continuously improved in the process of continuous optimization and innovation of consensus mechanisms. Secondly, from the perspective of transaction verification mechanisms, methods such as sharding technology, off-chain transactions and multi-chain architecture have been proposed to improve the transaction processing speed [1]. In terms of broadcast communication, some scholars have proposed improving the physical configuration of node machines to provide high-speed network links, so that the speed of P2P network communication can be improved [2].

[0006] Off-chain payment, protocol improvement, and sharding technology are only partial improvements to blockchain. There are performance bottlenecks and upper limits. With the rapid development of network technology and speed, there are certain limitations. A technology that changes the chain structure of blockchain to a directed acyclic graph (DAG) structure to improve the transaction performance of blockchain has attracted people's attention in recent years [3].

[0007] Traditional blockchains all use a single chain as the ledger structure and set different rules to prevent fork attacks, including the longest chain rule and the heaviest chain rule, which results in a long block confirmation time and is not suitable for scenarios with high throughput requirements. In the era of massive data, chain-structured distributed ledgers have certain limitations and cannot withstand the information operation mode contained in massive data, so considering replacing the chain structure with a DAG structure can greatly improve the scalability of the blockchain.

[0008] DAG is a directed graph without loops that can be expressed in order through topological sorting, in which all directed edges do not form a loop. That is, any point in the directed graph cannot return to its original position through the edges. The in-degree in DAG refers to the number of arcs that end at a vertex with a vertex as the arc head. The out-degree refers to the number of arcs that start at the vertex. It can be found that when the out-degree and in-degree of DAG are both 1, DAG becomes a chain structure, which shows that the chain structure is a special case of DAG. Since the DAG-based ledger has no restrictions on the number of out-degree and in-degree of each node, a node can be referenced by multiple nodes at the same time, which greatly increases the transaction concurrency of the ledger. Therefore, DAG is an extension of the chain structure, suitable for high concurrency and high throughput scenarios, but its implementation is also more complicated.

[0009] Currently, DAG distributed ledger technology often remains in the theoretical stage. Because the technologies involved are relatively complex and diverse, there are few systems that can actually be implemented.

[0010] References are as follows:

[0011] [1] Shao Qifeng, Jin Cheqing, Zhang Zhao, Qian Weining, Zhou Aoying. Blockchain technology: architecture and progress[J]. Chinese Journal of Computers, 2018, 41(05): 969-988.

[0012] [2] Han Xuan, Yuan Yong, Wang Feiyue. Security issues of blockchain: research status and prospects[J]. Acta Automatica Sinica, 2019, 45(01): 206-225. DOI: 10.16383 / j.aas.c180710.

[0013] [3] Gao Zhengfeng, Zheng Jilai, Tang Shuyang, Long Yu, Liu Zhiqiang, Liu Zhen, Gu Dawu. Research on distributed ledger consensus mechanism based on DAG[J]. Journal of Software, 2020, 31(04): 1124-1142. DOI: 10.13328 / j.cnki.jos.005982. Summary of the invention

[0014] In view of the above problems, the present invention proposes a high-throughput distributed ledger system based on DAG, starting from the framework design of the DAG ledger, and implementing each level and each module in the DAG ledger step by step. The distributed ledger system based on DAG is finally built by designing the DAG ledger system model.

[0015] The DAG-based high-throughput distributed ledger system includes five layers, from bottom to top: storage layer, data layer, network layer, consensus layer and application layer.

[0016] 1) The storage layer consists of five modules: log module, lightweight database, KV database, relational database and serialization module.

[0017] The log module includes receiving messages, synchronizing blocks, and error logging. By setting logback-spring.xml, the log information of the distributed ledger is stored locally in the logs folder.

[0018] The lightweight database is used to store block-specific information locally, directly embedded into the application and displayed on the front-end page.

[0019] The relational database is used to store alliance information, alliance member information, member permission information, etc., as well as to perform functions such as permission verification, member verification, member query and permission query.

[0020] The KV database mainly uses a key-value database to store block information of distributed ledgers, including important information such as the block header and block body, the transaction content contained in the block, and the hash of the block. The KV database stores each data item as a key-value pair, where the key is used to find data and the value is the data itself.

[0021] The serialization module is mainly used to parse strings in JSON format. It supports serializing Java Beans into JSON strings and deserializing from JSON strings to JavaBeans.

[0022] 2) The data layer consists of five modules: block module, DAG module, hash function module, encryption algorithm module and timestamp module.

[0023] The block module mainly contains the structural information of the block.

[0024] The DAG module is the underlying structure of the blocks. Multiple blocks reference each other through certain rules to form a directed acyclic graph structure.

[0025] The hash function module mainly uses hash function algorithms to implement functions such as digital signatures, identity authentication, cryptography, and data integrity checks.

[0026] The encryption algorithm module mainly uses encryption algorithms to generate public and private keys, generate wallet addresses, and perform encryption and decryption.

[0027] The timestamp module is mainly used to ensure that the timestamps before and after the block are correct and to prevent attacks from malicious nodes.

[0028] The hash function module, encryption algorithm module and timestamp module all use the trusted execution environment TEE to ensure computing security.

[0029] 3) The network layer mainly consists of three modules: P2P network module, transmission mechanism module and verification mechanism module.

[0030] The P2P network module mainly implements distributed ledgers by building a P2P network, and performs functions such as publishing transactions, consensus blocks, synchronization blocks and verification blocks between different nodes through the P2P network.

[0031] The transmission mechanism module mainly transmits through point-to-point connections and improves the transmission efficiency of nodes through concurrent transmission.

[0032] The verification mechanism module mainly ensures the security of the distributed ledger through member verification, member authority verification, block timestamp verification, block public key verification and block hash verification.

[0033] 4) The consensus layer mainly consists of two modules: the consensus algorithm module and the total order consistency module.

[0034] A consensus algorithm refers to an algorithm that reaches a consistent decision or a consistent state through the mutual collaboration of various nodes in a distributed system. TEE applied at the data layer can reduce the complexity of the voting consensus algorithm.

[0035] The total order consistency module is mainly used to support smart contracts, because the development and operation of smart contracts require the total order consistency of blocks. In smart contracts, it is necessary to ensure that all nodes operate in the distributed ledger in the same order, which requires the total order consistency of blocks. Only when all nodes reach a consensus can the correctness and reliability of smart contracts be guaranteed.

[0036] 5) The application layer mainly consists of two modules: alliance application module and interface testing module.

[0037] The alliance application module is mainly used to support the needs of smart contracts or DAPP development, and can provide corresponding functions for different application needs based on the infrastructure of this blockchain system.

[0038] The interface testing module mainly provides online automatic generation of interface documents + functional testing, and provides raw data for the front-end interface.

[0039] The bottom-level log module and lightweight database, KV database, and relational database are the foundation of the blockchain system, storing basic information of the database and providing services to the hierarchical modules above it. The block structure, DAG module, hash function module, encryption algorithm module, and timestamp module of the data layer are the basis for building the DAG ledger system. The P2P network module, transmission mechanism module, and verification mechanism module of the network layer are built on the basis of using the lower-level modules, ensuring the normal operation and transmission of the entire system network. The consensus algorithm module and total order consistency module of the consensus layer run on the basis of the network layer, and are a distributed consensus based on the P2P network. The consensus algorithm also provides services and support for the application layer above it. The application layer is the external manifestation of the entire DAG ledger system. The normal operation of the DAG ledger system can be guaranteed through interface testing and application operation.

[0040] The implementation process of the DAG-based high-throughput distributed ledger system includes:

[0041] Step 1: Build a DAG distributed ledger system including the management end and the server end, obtain nodes whose members, permissions and organization information have been verified by the management end, and join the DAG distributed ledger network;

[0042] The management end is used to manage member information, permission information, and organization information in the relational database. When a node needs to join a DAG ledger network, its identity and permission information must be verified through the management end; each node obtains the permission information of all nodes from the management end at regular intervals. Secondly, the management end obtains node information for block verification and determines whether the block message is legal through comparison. The management end uses the Spring-boot framework to connect to the MySQL database through a relational database.

[0043] The server builds the DAG ledger system from the bottom up according to the framework design, realizing functions such as block publishing, transaction query, and node consensus. The server application is packaged as a Docker container and runs, and each node corresponds to a server, thus realizing the multi-machine construction function of the DAG ledger.

[0044] Step 2: Node A builds a block through its own server. The server calculates and sets the self-parent hash and proof hash of the block header by calling the trusted execution environment TEE, and signs the block.

[0045] The specific construction process includes: using the public key algorithm to sign each transaction information, building a block body with a MerkleTree structure from the transaction message, generating MerkleRoot based on the MerkleTree of the block body, building a block header, and calculating the block hash.

[0046] The block header specifically includes the block number, parent hash, proof hash, timestamp, block hash (MerkleRoot), version, and public key. The block body contains the transaction list and transaction information.

[0047] The hash of the latest block in the parachain maintained by the node itself is referenced from the parent hash;

[0048] The calculation process of the proof hash is as follows:

[0049] First, count the number of nodes n in the current system, and then calculate the number of bits x of the intercepted block hash value:

[0050] x=log 2 n

[0051] After obtaining the number of bits x of the required block hash value, use the last x bits of the block hash value to obtain the binary number y of the chain number pointed to by the proof hash:

[0052] y=(hash(10101010···111101011)|[x])

[0053] After obtaining the binary number y, convert it to a decimal number z, which is the chain number pointed to by the proof hash. At this time, referencing the hash of the latest block in the chain can form a DAG structure based on the self-referencing parallel chain:

[0054] z=Decimal(y binary )

[0055] Step 3: After successful signing, node A will construct block A i Published to other nodes in the DAG distributed ledger network.

[0056] Step 4: Other nodes receive block A from the DAG distributed ledger network i Messages and call their respective servers for verification;

[0057] Block messages include block hash, permissions, version, parent hash, proof hash, signature, etc.

[0058] The server verifies the block signature and block timestamp by calling the trusted execution environment TEE. At the same time, it verifies whether the block serial number is outdated or advanced, whether the block's parent hash and proof hash are correct, and whether the node that publishes the block has the corresponding authority.

[0059] Step 5: After each node passes the verification process, it will determine whether to synchronize block A. i The voting message is sent to other nodes in the DAG distributed ledger network;

[0060] The voting message needs to include the voting target block A i , voting node number, voting type (True or False), and the voter's signature.

[0061] Each node that receives a voting message can receive voting and block messages from other nodes in the DAG distributed ledger network.

[0062] Step 6: The server of each node verifies the voting information received from each node;

[0063] Here it is necessary to verify whether the voting target block has been synchronized in the system (the voting message may arrive due to network delays) and whether the voter's signature is correct.

[0064] Step 7: Each node counts the data received by its own server about block A i If the number of affirmative votes is greater than half of the total number of nodes in the network, a block A is sent. i The confirmation message is sent to the DAG distributed ledger network.

[0065] Similar to the voting message, the confirmation message needs to include the confirmation target block A i Whether it has been synchronized in the system (the confirmation message may arrive due to network delays), the confirmation node number, the confirmation type (True or False), and the signature of the confirmer.

[0066] Step 8. Each node can receive confirmation messages from other nodes in the DAG distributed ledger network, call their own server to verify the confirmation messages and count the number of confirmation messages.

[0067] Here it is necessary to verify whether the target block has been synchronized in the system (the confirmation message may arrive due to network delays) and whether the signature of the confirmer is correct.

[0068] Step 9: The number of confirmed messages counted by each node is greater than half of the total number of nodes in the network, and block A is generated locally on each node. i , completing the synchronization of the DAG distributed ledger.

[0069] The advantages of the present invention are:

[0070] 1) The present invention provides a high-throughput distributed ledger system based on DAG, which is a parallel chain structure based on self-reference. Traditional blockchains all use a single chain as the ledger structure, and set different rules to prevent fork attacks, including the longest chain rule, the heaviest chain rule, etc., which leads to a long confirmation time for blocks. The blockchain based on this structure can greatly improve the throughput of the blockchain; the present invention provides a specific implementation and specific structure based on this mechanism.

[0071] 2) The present invention provides a high-throughput distributed ledger system based on DAG, which uses a trusted execution environment TEE to calculate the parent hash and the proof hash and sign the block. When the block is received, the trusted execution environment is also used to verify the signature, which improves the security of the DAG-based distributed ledger and reduces the complexity of the voting consensus algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 This is a framework design diagram of a DAG-based high-throughput distributed ledger system of the present invention;

[0073] Figure 2 This is a design diagram of the storage layer in the distributed ledger system of the present invention;

[0074] Figure 3 This is a design diagram of the data layer in the distributed ledger system of the present invention;

[0075] Figure 4 A network layer design diagram in the distributed ledger system of the present invention;

[0076] Figure 5 This is a design diagram of the consensus layer in the distributed ledger system of the present invention;

[0077] Figure 6 This is a design diagram of the application layer in the distributed ledger system of the present invention;

[0078] Figure 7 This is a diagram of the implementation process of the DAG-based high-throughput distributed ledger system of the present invention;

[0079] Figure 8 Add a flow chart to the nodes of the management end of the present invention;

[0080] Fig. 9 This is a block verification flow chart of the present invention;

[0081] Fig.10 Construct a flow chart for the block of the present invention;

[0082] Fig.11 It is a flow chart of receiving the block of the present invention;

[0083] Fig.12 This is a block brief information interface diagram of an embodiment of the present invention;

[0084] Fig.13 This is a block detailed information interface diagram of an embodiment of the present invention;

[0085] Fig.14 A schematic diagram of a block structure used in an embodiment of the present invention;

[0086] Fig.15 This is a flow chart of block reception according to an embodiment of the present invention;

[0087] Fig.16 This is a flowchart of block voting in an embodiment of the present invention;

[0088] Fig.17 This is a flow chart of block confirmation according to an embodiment of the present invention;

[0089] Fig.18 A parallel chain structure based on self-reference in an embodiment of the present invention;

[0090] Fig.19 A schematic diagram of the self-parent hash and proof hash used in the present invention;

[0091] Fig. 20 The throughput experiment comparison chart of the present invention and Fabric and ETH algorithms. DETAILED DESCRIPTION

[0092] The embodiments of the present invention are described in detail and clearly below with reference to the accompanying drawings.

[0093] At present, the distributed ledger technology about DAG often stays in the theoretical stage, because the technology involved is relatively complex and diverse, so there are few systems that can really be implemented. The present invention provides a high-throughput distributed ledger system based on DAG, which analyzes the advantages and disadvantages of the existing DAG distributed ledger scheme, designs a clear parallel chain structure, and forms a DAG structure through mutual reference between chains, which can be more easily analyzed for security, but a specially designed consensus algorithm is required to achieve a full order arrangement of transactions. By analyzing the consensus algorithm of the public chain (PoW, PoS, DPoS, etc.), the consensus algorithm of the alliance chain (BFT, PBFT, Election, etc.), and the consensus algorithm of the DAG ledger, the consensus algorithm is optimized and improved, so that the consensus algorithm can arrange all blocks in a consistent order under the premise of reaching a consensus.

[0094] The DAG-based high-throughput distributed ledger system, such as Figure 1 As shown in the figure, it contains five layers, from bottom to top: storage layer, data layer, network layer, consensus layer and application layer. The lower layer provides services for the upper layer, and the upper layer expands the functions based on the lower layer.

[0095] 1) The storage layer consists of five modules: log module, lightweight database, KV database, relational database and serialization module.

[0096] The content, structure and relationship of each module are as follows Figure 2 As shown:

[0097] 1.1) Log module, mainly used to store log information of distributed ledgers, including receiving messages, syncing blocks, error records, etc. Log information is stored locally by date, which is convenient for tracing past information. Spring Boot is a rapid application development framework based on the Spring framework, which can help developers quickly build Spring applications, simplify the complexity of Spring application development, deployment and operation and maintenance, and improve development efficiency. Spring Boot comes with a large number of configurations, simplifies the configuration process of the application, and also integrates many commonly used third-party libraries, which developers can directly use for development. The goal of Spring Boot is to make Spring development faster, simpler and more convenient, so that developers can focus more on the development of business logic. The present invention uses SpringBoot to build a system framework, and the specific implementation of the log module is mainly to store log information locally in the logs folder by setting logback-spring.xml.

[0098] 1.2) Relational database module, mainly used to store alliance information, alliance member information and member permission information, etc., as well as to perform functions such as permission verification, member verification, member query and permission query. A relational database is a database that uses a relational model as a data structure, in which data is organized into one or more tables. Each table consists of one or more columns, each column has a unique column name and a data type, and a row represents a record or tuple. Since MySQL has the advantages of high reliability, excellent performance, strong openness, rich support engines and active community, this embodiment uses the common free open source database MySQL to store various member or permission information.

[0099] 1.3) A lightweight database module is used to store specific information of blocks locally and provide the function of displaying it on the front-end page. A lightweight database generally refers to a database system that is smaller, faster, and easier to deploy than a traditional relational database. These database systems usually run in an embedded manner and can be directly embedded in an application without the need to install and configure database services separately. Due to their lightweight characteristics, these database systems have been widely used in some small projects and embedded devices. Since SQLite is a feature-rich, efficient, reliable, easy-to-use, free and open source lightweight relational database suitable for various embedded devices, mobile devices and small applications, this embodiment uses SQLite to store information locally.

[0100] 1.4) KV database, which mainly uses key-value database to store block information of distributed ledger, including block header and block body of the block, transaction content contained in the block, hash of the block and other important information. KV database is a database based on key-value pairs, and the unit of data storage is key-value pairs. KV database stores each data item as a key-value pair, the key is used to find data, and the value is the data itself. KV database is usually used in scenarios that require high performance, low latency, and high concurrent reading and writing, such as cache systems, session storage, message queues, etc. This embodiment stores relevant information by implementing RocksDB and LevelDB respectively, and compares the read and write efficiency of the two through experiments, so as to select the corresponding relational database according to actual conditions.

[0101] 1.5) Serialization module, mainly used for parsing strings in JSON format, supports serializing Java Beans into JSON strings, and can also deserialize from JSON strings to JavaBeans. Fastjson2 is a lightweight library with high performance, easy to use and powerful functions. Fastjson2 supports serialization and deserialization of JSON strings, supports conversion of Java objects into JSON strings, supports parsing of JSON strings, supports formatting of JSON strings, and also supports conversion of Java objects into XML strings. It is one of the commonly used JSON processing libraries in Java development. This embodiment uses the domestic Fastjson2 serialization to implement the functions of the serialization module.

[0102] 2) The data layer consists of five modules: block module, DAG module, hash function module, encryption algorithm module and timestamp module.

[0103] The content, structure and relationship of each module are as follows Figure 3 As shown:

[0104] 2.1) Block module, mainly including block structure information. The block structure of DAG-based distributed ledger is generally different from that of chain-based blockchain. Common DAG ledger block structures include transaction structure and transaction unit structure, etc. This embodiment adapts to DAG-based distributed ledger by designing a specific block structure.

[0105] 2.2) DAG structure module is the underlying structure of blocks. Multiple blocks refer to each other through certain rules to form a directed acyclic graph structure. This embodiment implements the underlying structure of the parallel chain based on the concept of DAG. Compared with the chain structure, the distributed ledger based on the parallel chain can have higher throughput, faster confirmation time, lower transaction fees and better scalability, etc.

[0106] 2.3) Hash function module, which mainly uses hash function algorithms to implement functions such as digital signatures, identity authentication, cryptography, and data integrity checks. A hash function is a function that maps data of any length to a fixed-length value, and its output value is usually called a hash value, message digest, digital fingerprint, etc. Currently common hash functions include MD5, SHA-1, SHA-2, and so on. This embodiment uses the SHA-256 hash algorithm for the hash function module through the trusted execution environment TEE.

[0107] 2.4) Encryption algorithm module, which mainly uses encryption algorithm to generate public and private keys, generate wallet addresses, and perform encryption and decryption. Encryption algorithm is a process of converting plain text into ciphertext, which plays a role in confidentiality and security in the process of information transmission. Encryption algorithms can be divided into symmetric encryption algorithms and asymmetric encryption algorithms. This embodiment uses the ECDSA algorithm in asymmetric encryption to implement the digital signature of the block through the trusted execution environment TEE.

[0108] 2.5) Timestamp module, used to ensure the correctness of the timestamps before and after the block to prevent attacks by malicious nodes. The timestamp refers to the total number of seconds from 00:00:00 Greenwich time on January 1, 1970 (08:00:00 Beijing time on January 1, 1970) to the present. This embodiment obtains a trusted timestamp through the trusted execution environment TEE.

[0109] 3) The network layer mainly consists of three modules: P2P network module, transmission mechanism module and verification mechanism module.

[0110] The content, structure and relationship of each module are as follows Figure 4 As shown:

[0111] 3.1) P2P network module, which implements distributed ledger by building a P2P network, and performs functions such as publishing transactions, consensus blocks, synchronization blocks and verification blocks between different nodes through the P2P network. The t-io network framework is a lightweight, high-performance NIO framework based on the Java language. It provides a highly scalable and easy-to-use network programming API that supports TCP, UDP, SSL / TLS and other protocols. The advantages of the t-io framework include high performance, flexibility and ease of use, good scalability, and concise code. It is widely used in various high-concurrency and high-performance server application scenarios. This embodiment uses the t-io framework to implement the construction of the P2P network, and uses the Java NIO mechanism to achieve high-concurrency and high-throughput network communication.

[0112] 3.2) Transmission module, which transmits through point-to-point connections and improves the transmission efficiency of nodes through concurrent transmission. Disruptor is a high-performance concurrent programming framework that is used to solve latency and performance issues when transferring data between producers and consumers. The core idea of ​​Disruptor is to use lock-free algorithms and ring buffers, which optimize data structures and thread scheduling to the extreme, and can process large amounts of data with very low latency and high throughput. Disruptor has been widely used in high-performance message middleware, trading systems and other fields. This embodiment uses the Disruptor concurrent device to achieve concurrent transmission between nodes.

[0113] 3.3) Verification mechanism module, which ensures the security of distributed ledgers by verifying members, member permissions, block timestamps, block public keys, and block hashes. The verification mechanism module of this embodiment includes multiple implementations. First, verification of members, permissions, and organizations are implemented through the management end. Secondly, verification of timestamps, signatures, etc. are implemented through a trusted execution environment. Finally, verification of specific block information is also implemented by the server and the management end.

[0114] 4) The consensus layer mainly consists of two modules: the consensus algorithm module and the total order consistency module.

[0115] The content, structure and relationship of each module are as follows Figure 5 As shown:

[0116] 4.1) Consensus algorithm module, through the research and analysis of the current consensus algorithms for DAG distributed ledgers, based on the existing consensus algorithms, absorb their advantages to design a consensus algorithm suitable for DAG distributed ledgers, and improve the throughput of distributed ledgers. Consensus algorithm refers to an algorithm that reaches a consistent decision or a consistent state through the mutual cooperation of various nodes in a distributed system. In blockchain technology, consensus algorithms are used to ensure the consistency and security of distributed ledgers, ensure that the data between different nodes is consistent, and thus avoid malicious nodes from tampering with and attacking the ledgers. Currently common consensus algorithms include consensus Byzantine fault tolerance, practical Byzantine fault tolerance, proof of authority, proof of equity, delegated proof of equity, or proof of work, etc.

[0117] 4.2) Totally consistent module

[0118] The total order consistency module is mainly used to support smart contracts, because the development and operation of smart contracts require the total order consistency of blocks. In smart contracts, it is necessary to ensure that the operations of all nodes on the distributed ledger are performed in the same order, which requires the total order consistency of blocks. Only when all nodes reach a consensus can the correctness and reliability of smart contracts be guaranteed. If smart contracts do not require the total order consistency of blocks, then the execution of smart contracts on different nodes may lead to different results, which will undermine the consistency and credibility of the entire distributed ledger system. Therefore, this study uses the TEE trusted execution environment to calculate the order of all blocks and achieve total order consistency.

[0119] 5) The application layer mainly consists of two modules: alliance application module and interface testing module.

[0120] The content, structure and relationship of each module are as follows Figure 6 As shown:

[0121] 5.1) Alliance application module, used to support the needs of smart contracts or DAPP development, can provide corresponding functions for different application needs on the infrastructure of this blockchain system. At present, the development of the application layer is still in the development stage, mainly involving some asset management, digital finance, identity authentication, Internet of Things information management, medical information management and other directions.

[0122] 6.2) Interface testing module, which provides online automatic generation of interface documents + functional testing, in preparation for the subsequent front-end page adaptation. Swagger is an API document generation tool that can automatically generate RESTful API documents. It can automatically generate API documents by scanning comments in the code, and can also provide API testing functions and API visual document display. Using Swagger can reduce the time and effort of handwriting API documents, and improve the accuracy and readability of API documents. This embodiment mainly uses Swagger to provide API testing functions.

[0123] The bottom-level log module and lightweight database, KV database, and relational database are the foundation of the blockchain system, storing basic information of the database and providing services to the hierarchical modules above it. The block structure, DAG module, hash function module, encryption algorithm module, and timestamp module of the data layer are the basis for building the DAG ledger system. The P2P network module, transmission mechanism module, and verification mechanism module of the network layer are built on the basis of using the lower-level modules, ensuring the normal operation and transmission of the entire system network. The consensus algorithm module and total order consistency module of the consensus layer run on the basis of the network layer, and are a distributed consensus based on the P2P network. The consensus algorithm also provides services and support for the application layer above it. The application layer is the external manifestation of the entire DAG ledger system. The normal operation of the DAG ledger system can be guaranteed through interface testing and application operation.

[0124] The implementation process of the DAG-based high-throughput distributed ledger system is as follows: Figure 7 As shown, specifically:

[0125] Step 1: Build a DAG distributed ledger system including the management end and the server end, obtain nodes whose members, permissions and organization information have been verified by the management end, and join the DAG distributed ledger network;

[0126] 1) Management system

[0127] The management system is mainly designed to manage member information, permission information, and organization information in relational databases. When a node needs to join a DAG ledger network, its identity and permission information must first be verified by the management system. Each node obtains the permission information of all nodes from the management system at regular intervals. Only nodes that have passed the verification are allowed to join the DAG ledger network for the next step. The flowchart of this step is as follows: Figure 8 shown.

[0128] Secondly, the management system is used to obtain node information for block verification. After receiving the block message, each node will call the management system through the server to obtain the node information, and then compare to determine whether the block message is legal. Only block messages that have passed the verification can proceed to the next step. The flowchart of the verification process is as follows: Fig. 9 shown.

[0129] The specific implementation of the management system uses the Spring-boot framework and connects to the MySQL database through the relational database module. The management system sets up a log module to store log messages locally and provides an interface to display member information, permission information, etc. through the interface test module.

[0130] 2) Server system

[0131] The server system is mainly responsible for implementing most of the functions of the DAG ledger system. It builds the DAG ledger system from the bottom up according to the framework design, and implements functions such as block publishing, transaction query, and node consensus. The server system can be deployed on Docker as a Docker container, thereby realizing the multi-machine construction function of the DAG ledger.

[0132] The process of block construction is as follows Fig.10 As shown in the figure, before a node needs to use the block publishing function of the DAG ledger system, the node must first join the distributed ledger network. After joining the distributed ledger network, the node calls the server system to build blocks, package transactions, calculate hashes, and set other information of the block. The server system also calls the trusted execution environment to calculate the parent hash and proof hash and sign the block. Only when these steps are successfully passed, the block will be created and enter the consensus step of the block.

[0133] The server system is also responsible for verifying and voting when the node receives messages from other nodes. When other nodes have block messages coming, the node will call the server system to verify the block message. The server system first calls the trusted execution environment to verify the signature of the block, and then calls the management system to obtain the node information for verification. Finally, the server system will also calculate the correctness of the verification hash value. After the verification is passed, the server system will send an approval vote to other nodes to indicate that the node is correct, and the construction and sending process of the confirmation message is similar. The specific process of the server system receiving the block is shown in Figure 11.

[0134] The specific implementation of the server system also uses the Spring-boot framework. The server system is the core of the system and includes most modules.

[0135] Step 2: Node A builds a block through its own server. The server calculates and sets the self-parent hash and proof hash of the block header by calling the trusted execution environment TEE, and signs the block.

[0136] The specific construction process includes: using the public key algorithm to sign each transaction information, building a block body with a MerkleTree structure from the transaction message, generating MerkleRoot based on the MerkleTree of the block body, building a block header, and calculating the block hash.

[0137] The block header specifically includes the block number, parent hash, proof hash, timestamp, block hash (MerkleRoot), version, and public key. The block body contains the transaction list and transaction information.

[0138] The hash of the latest block in the parachain maintained by the node itself is referenced from the parent hash;

[0139] The calculation process of the proof hash is as follows:

[0140] First, count the number of nodes n in the current system, and then calculate the number of bits x of the intercepted block hash value:

[0141] x=log 2 n

[0142] After obtaining the number of bits x of the required block hash value, use the last x bits of the block hash value to obtain the binary number y of the chain number pointed to by the proof hash:

[0143] y=(hash(10101010···111101011)|[x])

[0144] After obtaining the binary number y, convert it to a decimal number z, which is the chain number pointed to by the proof hash. At this time, referencing the hash of the latest block in the chain can form a DAG structure based on the self-referencing parallel chain:

[0145] z=Decimal(y binary )

[0146] This structure not only increases the security and reliability of the distributed ledger, but also adds randomness to the references between blocks, which can effectively prevent the existence of isolated blocks. Through references between different chains, it can also provide a reference for the total order of blocks. Fig.19 shown.

[0147] Step 3: After successful signing, node A will construct block A i Published to other nodes in the DAG distributed ledger network.

[0148] Step 4: Other nodes receive block A from the DAG distributed ledger network i Messages and call their respective servers for verification;

[0149] like Fig.15 As shown, the block message includes block hash, permissions, version, parent hash, proof hash, signature and other information.

[0150] The server verifies the block signature and block timestamp by calling the trusted execution environment TEE. At the same time, it verifies whether the block serial number is outdated or advanced, whether the block's parent hash and proof hash are correct, and whether the node that publishes the block has the corresponding authority.

[0151] Step 5: After each node passes the verification process, it will determine whether to synchronize block A. i The voting message is sent to other nodes in the DAG distributed ledger network;

[0152] like Fig.16 As shown, the voting message needs to include the voting target block A i , voting node number, voting type (True or False), and the voter's signature.

[0153] Each node that receives a voting message can receive voting and block messages from other nodes in the DAG distributed ledger network.

[0154] Step 6: The server of each node verifies the voting information received by each node;

[0155] Here it is necessary to verify whether the voting target block has been synchronized in the system (the voting message may arrive due to network delays) and whether the voter's signature is correct.

[0156] Step 7: Each node counts the data received by its own server about block A i If the number of affirmative votes is greater than half of the total number of nodes in the network, a block A is sent. i The confirmation message is sent to the DAG distributed ledger network.

[0157] like Fig.17 As shown, similar to the voting message, the confirmation message needs to include the confirmation target block A i Whether it has been synchronized in the system (the confirmation message may arrive due to network delays), the confirmation node number, the confirmation type (True or False), and the signature of the confirmer.

[0158] Step 8. Each node can receive confirmation messages from other nodes in the DAG distributed ledger network, call their own server to verify the confirmation messages and count the number of confirmation messages.

[0159] Here it is necessary to verify whether the target block has been synchronized in the system (the confirmation message may arrive due to network delays) and whether the signature of the confirmer is correct.

[0160] Step 9: The number of confirmed messages counted by each node is greater than half of the total number of nodes in the network, and block A is generated locally on each node. i , completing the synchronization of the DAG distributed ledger.

[0161] Example:

[0162] In order to ensure the normal operation of the DAG-based distributed ledger system, the system must implement functions such as node joining, information verification, information query, block publishing, and block query. Through in-depth research and analysis of the framework design, the architecture of the model and the corresponding technology selection were determined. After in-depth research and analysis of the architecture of the DAG-based distributed ledger, the entire ledger system model was designed.

[0163] In the model design and specific implementation of the DAG-based distributed ledger, multiple technologies and middleware are used. The entire DAG distributed ledger uses Docker technology, and different containers are deployed in Docker to achieve virtualized deployment. The specific implementation of the system is mainly divided into management, server, and MySQL. Each node obtains member information, permission information, organization information, etc. in the MySQL database through the management system to use the server system to connect to the distributed ledger network. In the P2P network, an identical DAG ledger is built through the consensus algorithm, and the block information in it is stored in the local KV database for query, and the front-end display function is provided through the SQLite lightweight database.

[0164] This embodiment develops a visual display platform, which deploys a distributed ledger system based on a directed acyclic graph on a server and displays the block data in the system on a front-end page. Fig.12 and 13 As shown. The visualization platform is a web application for browsing and querying information on distributed ledgers. These tools allow people to easily view transactions, addresses, blocks, network status and other information on distributed ledgers, while also providing a more intuitive and easier to understand way to view distributed ledger data.

[0165] As shown on the interface, the visual browser contains two interfaces: block summary information and block detailed information. The block summary information interface includes information such as the block timestamp, block hash, saved content, and block list, and provides related query services. The block detailed information additionally includes information such as the user who published the block, user number, self-parent hash, and proof hash.

[0166] The operating environment of this embodiment includes the operating environment and technical version required by the DAG distributed ledger system. The specific configuration is shown in Table 1 below:

[0167] Table 1 DAG ledger system operating environment

[0168]

[0169] The operation process of the DAG distributed ledger system is mainly divided into four steps: block publishing, block receiving, block voting and block confirmation:

[0170] Step 1: Block Release:

[0171] The process mainly includes five participants: nodes, management end, server end, trusted execution environment and distributed ledger. The detailed operation process is shown in the figure below:

[0172] 1) Before publishing a block, the node needs to obtain all member information, permissions information and organization information from the manager. Only when the node's members, permissions and organizations match the information stored in the manager, the node is allowed to join the distributed ledger network, that is:

[0173] members,permissions,organizations=Manager.getInfomations() (3-4)

[0174] 2) Before publishing a block, the node needs to build a block first. The node enters the block building process through the server. The server automatically sets the block hash, version information, public key and other information of the block body header and the transaction information of the block body according to the current information:

[0175] blocks=Server.build(transactions) (3-5)

[0176] 3) The server calls the trusted execution environment TEE to calculate and set the self-parent hash selfProof and proof hash proofHash of the block header, and signs the block to obtain the signature:

[0177] block=TEE.build(blocks) (3-6)

[0178] signature=TEE.sign(block) (3-7)

[0179] 4) After successfully signing and building the block, the node Node publishes the block to other nodes in the DAG distributed ledger network Net:

[0180] Node.sendBlockMessage(members,block) (3-8)

[0181] Since the distributed ledger structure based on directed acyclic graph is more complex than the traditional single chain structure, it is necessary to set a specific block structure and reference method to better achieve the consistency of the entire ledger. The block structure designed and implemented in this embodiment is divided into a block header and a block body. The structure of the block is as follows Fig.14 shown.

[0182] The parent hash is the hash of the latest block referenced by itself. The proof hash is determined by calculating the last few bits of the MerkleRoot of the block to determine which node's latest block to reference. The timestamp mainly indicates the release time of the block and is used for sorting between blocks. The version and public key are used to verify whether the block information is correct. MerkleRoot uses a binary tree to add the hash values ​​of all transaction records in the current block layer by layer and calculate a new hash value until the hash value of the last node is the MerkleRoot. In this way, as long as a transaction is tampered with, it is easy to locate the transaction.

[0183] Step 2: Block reception.

[0184] It mainly includes five participants: node, management end, server end, trusted execution environment and distributed ledger. The detailed operation process is as follows Fig.11 As shown:

[0185] 1) Node receives blockMessages from other nodes in the DAG distributed ledger network Net:

[0186] blockMessage=Net.getBlockMessage() (3-9)

[0187] 2) The node automatically calls the server to obtain the block hash blockHash, permission permission, version version, self-parent hash selfHash, proof hash proofHash, signature signature and other information of the block, and calls the verification program for verification:

[0188] blockHash,permission,version,selfHash,proofHash,signature=Server.get(blockMessage) (3-10)

[0189] 3) The server verifies the signature by calling the trusted execution environment TEE:

[0190] check1=TEE.verfy(signature) (3-11)

[0191] 4) The server verifies other information of the block by calling the manager:

[0192] check2=Manager.checkBlockMessage((blockMessage) (3-12)

[0193] 5) After passing the verification process, the node Node will send a vote for the block message blockMessage to other nodes in the DAG distributed ledger network Net:

[0194] Node.sendVoteMessage(members,true,blockMessage) (3-13)

[0195] Step 3: Block voting.

[0196] It mainly includes four participants: nodes, management end, server end and distributed ledger. The detailed operation process is as follows Fig.16 As shown:

[0197] 1) Node receives votes and block messages from other nodes in the DAG distributed ledger network Net:

[0198] vote,blockMessage=Net.getVote() (3-14)

[0199] 2) The server verifies the voting information by calling the manager:

[0200] Manager.checkVote(vote) (3-15)

[0201] 3) The node Node calls the server Server to count the number of votes in favor of the corresponding block according to the blockMessage:

[0202] voteCount[blockMessage]=Server.count(vote,blockMessage) (3-16)

[0203] 4) If the number of votes voteCount[blockMessage] for a block message blockMessage is greater than half of the total number of nodes in the network, a confirmation message commitMessage for the block message is sent to the DAG distributed ledger network Net.

[0204] Node.sendcommitMessage(members,tue,blockMessage) (3-17)

[0205] Step 4: Block confirmation.

[0206] It mainly includes four participants: nodes, management end, server end and distributed ledger. The detailed operation process is as follows Fig.17 As shown:

[0207] 1) Node receives the confirmation message commitMessage from other nodes in the DAG distributed ledger network Net.

[0208] commitMessage,blockMessage=Net.getcommitMessage() (3-18)

[0209] 2) The node Node verifies the confirmation message commitMessage by calling the server Server.

[0210] Manager.checkcommitMessage(commitMessage) (3-19)

[0211] 3) The node Node counts the number of confirmation messages commitMessage by calling the server Server.

[0212] stateCount[blockMessage]=Server.count(commitMessage,blockMessage) (3-20)

[0213] 4) If the number of confirmation messages commitCount[blockMessage] is greater than half of the total number of nodes in the network, it means that more than half of the nodes in the entire network have confirmed the block and the block can be confirmed in the DAG distributed ledger network.

[0214] localBlock=Node.build(blockMessage) (3-21)

[0215] This embodiment designs a DAG structure based on self-referencing parallel chains, such as Fig.18 As shown in the figure, in this structure, each node maintains one of the parallel chains. A parent hash pointer in the block published by each node must point to the parallel chain maintained by the node itself to achieve a self-referencing parallel chain structure. Another hash pointer in the block is referenced through calculation to achieve a structure in which parallel chains reference each other. This reference is called a proof hash reference. The structure based on the self-referencing parallel chain is shown in the figure:

[0216] The results show that:

[0217] One of the most important performance indicators of a distributed ledger is throughput. This experiment will test the throughput of a distributed ledger based on DAG: In this experiment, each node is simulated as a Java thread and tested through IDEA. Each node concurrently builds blocks, publishes blocks, and confirms blocks. In the experiment, different numbers of nodes are set to test the impact of the number of nodes on the throughput of the distributed ledger.

[0218] The present invention compares Ethereum and Hyperledger Fabric as baseline methods. This experiment uses virtual machines to build Ethereum test networks and Hyperledger Fabric test networks to test the throughput of Ethereum and Fabric. The present invention uses the Hyperbench distributed test platform to test performance. Hyperbench is a high-performance, easy-to-use, distributed blockchain platform performance testing tool that can flexibly adapt to mainstream blockchain platforms such as Ethereum, Fabric, and HyperChain. The use of Hyperbench ensures the authenticity and credibility of the experimental data.

[0219] In actual application scenarios, nodes are divided into full nodes and light nodes. Full nodes must have a full copy of the ledger, so they must download every transaction and block that has ever occurred on the ledger. However, for most nodes that only need to query, it is not necessary to obtain all blocks and transactions. They only need to download the block header to verify the authenticity of the transaction. Such nodes are called light nodes. Light nodes are mainly for saving storage space and computing time, so light nodes cannot join the consensus process of blocks. In this experiment, all nodes are full nodes, so the number of nodes set in this experiment is reasonable.

[0220] The experimental results are as follows Fig. 20 As shown in the figure, it can be found that as the number of nodes increases, the throughput of the DAG distributed ledger also increases, indicating that the DAG-based distributed ledger significantly increases the concurrency of nodes. Fabric's throughput is determined by many factors, such as network bandwidth, number of nodes, transaction size, etc. Fabric's throughput may vary greatly under different experimental conditions. Limited by environmental conditions, Fabric's throughput will continue to decline under high load. It should be noted that Fabric does not pursue high throughput, but focuses more on scalability, security, and flexibility. Ethereum is a classic public chain that has become very mature and stable after years of development. It can be found that Ethereum's throughput is relatively stable and cannot increase with the growth of nodes. This is also the shortcoming of traditional proof-based consensus.

Claims

1. A high-throughput distributed ledger system based on DAG, characterized in that: Contains from bottom to top: storage layer, data layer, network layer, consensus layer and application layer; The storage layer consists of five modules: log module, lightweight database, KV database, relational database and serialization module; the data layer consists of five modules: block module, DAG module, hash function module, encryption algorithm module and timestamp module; the network layer mainly consists of three modules: P2P network module, transmission mechanism module and verification mechanism module; the consensus layer mainly consists of two modules: consensus algorithm module and total order consistency module; the application layer mainly consists of two modules: alliance application module and interface test module; The bottom-level log module, lightweight database, KV database, relational database and serialization module are the foundation of the entire DAG distributed ledger system, storing basic database information and providing services to the upper-level modules. The block module, DAG module, hash function module, encryption algorithm module and timestamp module of the data layer are the foundation of the DAG distributed ledger system. The P2P network module, transmission mechanism module and verification mechanism module of the network layer are constructed on the basis of the lower-level modules, ensuring the normal operation and transmission of the DAG distributed ledger system. The consensus algorithm module and total order consistency module of the consensus layer are operated on the basis of the network layer, and are a distributed consensus based on the P2P network. The consensus algorithm also provides services and support for the application layer above it. The application layer is the external manifestation of the DAG distributed ledger system, and the normal operation of the DAG distributed ledger system can be guaranteed through interface testing and application operation. The implementation process of the DAG-based high-throughput distributed ledger system includes: Step 1: Build a DAG distributed ledger system including the management end and the server end, obtain nodes whose members, permissions and organization information have been verified by the management end, and join the DAG distributed ledger network; Each node corresponds to a server. Step 2: Node A builds a block through its own server. The server calls the trusted execution environment TEE to calculate and set the parent hash and proof hash of the block header, and signs the block. After successful signing, node A will build block A. i Publish to other nodes in the DAG distributed ledger network; The hash of the latest block in the parachain maintained by the node itself is referenced from the parent hash; The calculation process of the proof hash is as follows: First, count the number of nodes n in the current system, and then calculate the number of bits x of the intercepted block hash value: x = log2n After obtaining the number of bits x of the required block hash value, use the last x bits of the block hash value to obtain the binary number y of the chain number pointed to by the proof hash: y=(hash(10101010···111101011)|[x]) After obtaining the binary number y, convert it to a decimal number z, which is the chain number pointed to by the proof hash. At this time, referencing the hash of the latest block in the chain can form a DAG structure based on the self-referencing parallel chain: z=Decimal(y binary ) In this structure, each node maintains one of the parallel chains. In each block published by a node, a parent hash pointer must point to the parallel chain maintained by the node itself to achieve a self-referencing parallel chain structure. Another hash pointer in the block is referenced through calculation to achieve a structure in which parallel chains reference each other. This reference is called a proof hash reference. Step 3: Other nodes receive block A from the DAG distributed ledger network i The message will be sent to each node and the respective server will be called for verification. After passing the verification process, each node will determine whether to synchronize block A. i The voting message is sent to other nodes in the DAG distributed ledger network; Step 4: The server of each node verifies the voting information received by each node and counts the voting information received by its own server about block A. i If the number of affirmative votes is greater than half of the total number of nodes in the DAG distributed ledger network, a request for block A is sent. i The confirmation message is sent to the DAG distributed ledger network; Step 5: Each node can receive confirmation messages from other nodes in the DAG distributed ledger network, call their own server to verify the confirmation messages and count the number of confirmation messages; when the number of confirmation messages counted by each node is greater than half of the total number of nodes in the DAG distributed ledger network, block A is generated locally on each node. i , completing the synchronization of the DAG distributed ledger.

2. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The log module includes receiving messages, synchronizing blocks and error records; by setting logback-spring.xml, the log information of the DAG distributed ledger system is stored locally in the logs folder; The lightweight database is used to store block-specific information locally, which is directly embedded into the application and displayed on the front-end page; The relational database is used to store alliance information, alliance member information and member authority information, as well as to perform authority verification, member verification, member query and authority query; The KV database mainly uses a key-value database to store the block information of the DAG distributed ledger system, including the block header and block body of the block. The block body contains the transaction content, and the block header contains the hash of the block. The KV database stores each data item as a key-value pair, where the key is used to find the data and the value is the data itself. The serialization module is mainly used to parse strings in JSON format. It supports serializing Java Beans into JSON strings and deserializing from JSON strings to JavaBeans.

3. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The block module mainly includes the structural information of the block; The DAG module is the underlying structure of the block. Multiple blocks refer to each other through certain rules to form a directed acyclic graph structure. The hash function module mainly uses hash function algorithms to implement digital signatures, identity authentication, cryptography, and data integrity checks; The encryption algorithm module mainly uses encryption algorithms to generate public and private keys, generate wallet addresses, and perform encryption and decryption; The timestamp module is mainly used to ensure that the timestamps before and after the block are correct and to prevent attacks from malicious nodes.

4. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The P2P network module mainly implements distributed ledger by building a P2P network, and publishes transactions, consensus blocks, synchronization blocks and verification blocks between different nodes through the P2P network; The transmission mechanism module mainly transmits through point-to-point connections and improves the transmission efficiency of nodes through concurrent transmission; The verification mechanism module mainly ensures the security of the distributed ledger through member verification, member authority verification, block timestamp verification, block public key verification and block hash verification.

5. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The consensus algorithm refers to an algorithm that reaches a consistent decision or a consistent state through the mutual cooperation of various nodes in the DAG distributed ledger system; The total order consistency module is mainly used to support smart contracts, because the development and operation of smart contracts require the total order consistency of blocks. Smart contracts need to ensure that all nodes operate in the DAG distributed ledger system in the same order, which requires the total order consistency of blocks. Only when all nodes reach a consensus can the correctness and reliability of smart contracts be guaranteed.

6. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The alliance application module is mainly used to support the needs of smart contracts or DAPP development, and provides corresponding functions for different application needs on the infrastructure of the DAG distributed ledger system; The interface testing module mainly provides online automatic generation of interface documents + functional testing, and provides raw data for the front-end interface.

7. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The management end of step 1 is used to manage member information, authority information and organization information in the relational database; When a node needs to join a DAG distributed ledger network, its identity and permission information must be verified by the management end; each node obtains the permission information of all nodes from the management end at regular intervals; Secondly, the management end obtains node information to verify the block and determines whether the block message is legal through comparison. The management end uses the Spring-boot framework to connect to the MySQL database through a relational database. The server side builds the DAG distributed ledger system from the bottom up according to the framework design, realizing the functions of block publishing, transaction query, and node consensus; the server side is deployed on Docker as a container, thereby realizing the multi-machine construction function of the DAG distributed ledger.

8. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: The process of building a block in step 2 includes: Use the public key algorithm to sign each transaction message, build a block body with a MerkleTree structure from the transaction message, generate MerkleRoot based on the MerkleTree of the block body, build a block header, and calculate the block hash; The block header specifically includes the block number, parent hash, proof hash, timestamp, block hash, version, and public key; the block body includes the transaction list and transaction information; The self-parent hash refers to the hash of the latest block in the parachain maintained by the node itself.

9. A DAG-based high-throughput distributed ledger system as claimed in claim 1, characterized in that: In the step 2, the server verifies the block signature and block timestamp by calling the trusted execution environment TEE. At the same time, it verifies whether the block serial number is outdated or advanced, whether the block's parent hash and proof hash are correct, and whether the node that publishes the block has the corresponding authority.

Images