Distributed DAG block security sorting method based on TEE

Abstract

The present invention discloses a distributed DAG block security sorting method based on TEE, belonging to the field of information technology; specifically: first, based on a dual key system of a parallel chain structure, a new block structure is constructed, and respective keys are generated for TEE signatures and node signatures; then, for the block A to be signed issued by the current node I, after obtaining the node signature and TEE signature using the common environment signature and TEE signature function respectively, they are sent to other nodes to verify the legitimacy and the uniqueness of the block sequence number, and make a positive vote; by verifying the signature of the positive vote, when the number of votes vote_num is greater than half the number of nodes in the blockchain network, the savedHash field is updated; for the offline node, by communicating with other nodes, the new blocks issued by other nodes when the offline node is synchronized to complete the sorting of the newly released blocks during the offline period. The present invention ensures that blocks can be released in an orderly manner with lower network complexity in the blockchain system of the DAG structure.

Description

Technical Field

[0001] The present invention belongs to the field of information technology and relates to a distributed DAG (Directed Acyclic Graph) block security sorting method based on TEE (Trusted execution environment). Background Art

[0002] TEE refers to a trusted, isolated and independent execution environment that exists on a device independently of an untrusted operating system. It provides a safe and confidential space for private data and sensitive computing in an untrusted environment. Its security is usually guaranteed by hardware-related mechanisms. Ideally, all programs can be deployed and executed in the TEE environment to ensure the security of computing. However, in reality, the computing resources of TEE are very limited, and the execution speed is slower than that of programs in ordinary environments. Therefore, a small number of necessary programs need to be deployed in the TEE environment. In addition, the hardware of each node device in the alliance chain is different. In a blockchain system that publishes new blocks in high parallelism, it is necessary to solve the block sorting problem caused by the different running speeds of TEE devices.

[0003] In the blockchain system using TEE, the existing TeeGraph blockchain system uses the TEE-based gossipabout gossip protocol to obtain the consistency of the ledger. However, its application scenario is a large-scale deployed IoT network. When a node publishes a new block, it cannot obtain the global state of the ledger, so the block is published out of order. Various smart contracts often need to be run in the alliance chain, and the basis for executing smart contracts in the blockchain lies in the orderly arrangement of blocks. Therefore, a mechanism needs to be designed to ensure that the order of block publication is orderly in the TEE-based blockchain system.

[0004] In the application scenario of alliance chain, the blockchain system based on DAG structure can publish new blocks in parallel through multiple nodes, effectively improving the throughput of the system. Most alliance chain systems use PBFT consensus algorithm to prevent nodes from doing evil. Its main purpose is to prevent the main node that publishes the block from publishing different block copies to other nodes, such as the attached Figure 1 However, the traditional PBFT consensus algorithm based on voting requires a total number of nodes of n = 3f + 1, where f is the number of malicious nodes; this consensus algorithm causes network congestion of 2*(n-1)*n, and the network complexity will increase significantly with the increase in the number of nodes.

[0005] The Min-BFT algorithm uses TEE technology to improve the PBFT algorithm, ensuring that the master node that publishes the block publishes the same block copy to other nodes, making the total number of nodes n = 2f + 1, and the network congestion is (n-1) * n. However, the Min-BFT algorithm still requires a master node to publish new blocks, and the TEE signature program can only be executed by the master node, and does not support the parallel release of DAG structured blockchains.

[0006] Therefore, an efficient TEE solution for DAG-structured blockchains is needed. Under the premise that each node of the DAG-structured blockchain publishes blocks in parallel, only necessary programs are run in the TEE; and the block release order can be determined by the block sorting algorithm to avoid duplication of block numbers due to network delays and computing delays. Summary of the invention

[0007] In view of the different TEE execution speeds between different devices in the prior art and the high parallel block release of the DAG blockchain, the present invention proposes a distributed DAG block security sorting method based on TEE based on the voting mechanism of the min-BFT consensus algorithm, which saves TEE computing resources by deploying necessary programs in a trusted execution environment. By further improving the consensus algorithm, the DAG blockchain system is guaranteed to operate under lower network congestion and computing costs. At the same time, the voting algorithm ensures that nodes cannot repeatedly vote for other blocks of the same number, thereby ensuring the order of block release.

[0008] The TEE-based distributed DAG block security sorting method has the following specific steps:

[0009] Step 1: Based on the dual-key system of the parallel chain structure, a new block structure consisting of 4 fields is constructed;

[0010] The 4 fields are: block hash block_hash, block parent hash previous_hash, node signature node_signature and TEE signature tee_signature.

[0011] When a node publishes a block, it needs to sign the TEE and the node separately;

[0012] The TEE signature needs to check the parent hash of the block and sign the block hash to ensure that the node cannot send different blocks with the same number to other nodes.

[0013] The node signature is a signature obtained using a signature algorithm in a non-trusted execution environment, which is used to ensure the non-repudiation of newly released blocks.

[0014] Step 2: For the TEE signature tee_signature field in the new block structure, generate the key of this field in the TEE executable program and save it in the TEE secure file system;

[0015] The specific process of generating a key is as follows:

[0016] First, check whether there is a key stored in the secure file system; if so, end; otherwise, execute the function EC_KEY_new_by_curve_name to generate a pair of ECDSA public and private keys Tee_privatekey and Tee_publickey for a specific elliptic curve;

[0017] Then, the functions PEM_write_bio_ECPrivateKey and BIO_get_mem_data are executed to save the private key Tee_privatekey as a string and store it in the secure file system.

[0018] Step 3: For the node signature node_signature field in the new block structure, use the ECDSA function in a normal environment to generate the public and private key pairs privatekey and publickey in a normal environment.

[0019] The ECDSA functions come from the org.spongycastle.crypto.params.ECDomainParameters package.

[0020] Step 4: For the block A to be signed published by the current node I, use the common environment signature function Sign to obtain the node signature node_signature;

[0021] Step 5: Use TEE signature function TEE_Sign to sign block A and determine whether block A is the first block released by node I. If so, proceed to step 6 for TEE signature; otherwise, proceed to step 10 for TEE signature;

[0022] Step 6: After signing the first block A published by the current node I, send it to other nodes in the blockchain network.

[0023] The specific process is:

[0024] Create an intermediate variable temp in the TEE environment; then, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; and sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network.

[0025] Step 7: Other nodes in the blockchain network verify the legitimacy and uniqueness of block A and vote in favor after verification.

[0026] The uniqueness verification is as follows: when other nodes in the blockchain network receive block A, they store the block hash block_hash in the voting queue HashMap, and search in the queue HashMap whether there is already a block with the same block number number as block A but a different block hash hash. If so, it proves that votes have been cast for other blocks of number, and block A cannot be voted for repeatedly.

[0027] The verification of legitimacy is as follows: the Verify function and TEE_Verify function are called respectively to perform signature verification on the node signature node_signature and TEE signature tee_signature of block A. After the signature verification passes, an affirmative vote is made. In the affirmative vote, TEE is used to sign the voting information to obtain tee_vote_signature.

[0028] Step 8. Node I calls the TEE_Verify function in the TEE environment to verify the signature tee_vote_signature of the affirmative vote, and counts the number of votes vote_num that have passed the verification;

[0029] Step 9. Create the savedHash field in the TEE environment of node I. When the number of votes vote_num is greater than half of the number of nodes in the blockchain network, update the savedHash field.

[0030] When the number of votes vote_num is greater than half of the number of all nodes in the blockchain network, node I saves the variable temp field to the savedHash field and deletes the temp field; at this time, the savedHash field in the TEE environment is updated to the block_hash of block A;

[0031] When the number of votes vote_num is less than or equal to half of the number of all nodes in the blockchain network, it means that the block released by this node may conflict with other nodes.

[0032] Step 10: For the second and subsequent blocks A released by the current node I, the parent hash previous_hash field of the block and the generation time of block A are verified and signed, and then sent to other nodes in the blockchain network, and then return to step 7 for verification of block A by other nodes in the blockchain network.

[0033] The specific verification and signing steps are:

[0034] First, get the parent hash previous_hash of the block A to be signed, and check whether the previous_hash field is the same as the savedHash field; if they are not the same, reject the signature; if they are the same, check whether there is an intermediate variable temp and its corresponding timestamp temp_timestamp;

[0035] If it exists, check whether the difference between the release time of block A and temp_timestamp exceeds TTL; if it does not exceed TTL, TEE refuses to sign; if it exceeds TTL, execute TEE signature; if it does not exist, execute TEE signature directly.

[0036] The TEE signing process is as follows: create an intermediate variable temp in the TEE environment, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; sign the block_hash field to obtain the TEE signature tee_signature; and send block A to other nodes in the blockchain network.

[0037] Step 11. During the actual operation, when the offline node node_x reconnects to the blockchain network, it needs to communicate with other nodes to synchronize the new blocks released by the node when it is not in the blockchain network, so as to complete the sorting of the newly released blocks during the offline period.

[0038] The following two steps are discussed in detail:

[0039] 11.1: When node node_x suddenly disconnects from the blockchain network after saving the temp field and signing to obtain tee_signature, when node node_x reconnects, it first asks node_x in the blockchain network whether there are newly released blocks, that is, blocks released before node_x goes offline. If there are newly released blocks, delete the temp field after synchronizing the node.

[0040] 11.2: After checking the temp field, the reconnected node node_x only needs to synchronize the newly released blocks of other nodes. Therefore, after the node is connected to the blockchain network, it needs to poll other nodes, query the new blocks released by each node and synchronize them to this node.

[0041] At this point, the block synchronization and sorting process is completed, including the block sorting when the node is running online and the block sorting after the node is disconnected and reconnected, which can ensure the orderly arrangement of blocks in the entire process of node operation in the blockchain system.

[0042] The advantages of the present invention are:

[0043] 1) The distributed DAG block security sorting method based on TEE of the present invention ensures that blocks in the blockchain system with DAG structure can be released in an orderly manner with lower network complexity.

[0044] 2) The distributed DAG block security sorting method based on TEE of the present invention uses the parent node single reference technology in the TEE environment to ensure that the master node publishes the same block copy to other nodes, and introduces the intermediate variable temp in consideration of the situation that the block is not received by other nodes. This enhances the fault tolerance of the system and reduces the network complexity of consensus voting to 1 / 2 of PBFT.

[0045] 3) The distributed DAG block security sorting method based on TEE of the present invention applies an algorithm for determining whether to vote repeatedly at the consensus layer to ensure that nodes can only vote for unique blocks with the same sequence number. This enables each node in the blockchain system with a DAG structure to publish blocks, while ensuring the orderliness of block publishing. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A schematic diagram of a synchronization error caused by a malicious node in a blockchain system without TEE protection in the prior art;

[0047] Figure 2 This is a flowchart of the steps of the distributed DAG block security sorting method based on TEE of the present invention;

[0048] Figure 3 This is the basic structure diagram of the DAG structure blockchain of the present invention;

[0049] Figure 4 It is the necessary fields of the block of the present invention, the necessary TEE devices, node signatures and the generation process of TEE signatures. DETAILED DESCRIPTION

[0050] In order to facilitate those skilled in the art to understand and implement the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. Obviously, the described embodiments are only partial embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work should fall within the scope of protection of the present invention.

[0051] Since the use of TEE can ensure the consistency of node block release, fewer consensus steps can be used to make nodes reach consensus. In the traditional BFT algorithm, each message is released by the master node, and it is impossible to achieve multi-node parallel block release. The distributed ledger with Dag structure does not need to select a master node. Any node can build a block and then broadcast it to the entire network, thereby achieving a high-concurrency ledger. Obviously, compared with the master node, the concept of order is missing, and in the concurrent process, different nodes will generate blocks with the same serial number due to network delay and calculation delay. Therefore, it is necessary to improve the BFT algorithm. The main improvement is to set up a voting queue and find whether there is already a block with the same block number but different block hash in the HashMap of the voting queue. If there is such a block, it proves that the block with serial number number has been released, and the duplicate block cannot be voted. The block that finally obtains the majority of votes will be added to the consensus ledger. At the same time, it is also necessary to consider the occurrence of situations such as continuing to synchronize blocks after the node goes offline.

[0052] Based on the above background, the present invention proposes a distributed DAG block security sorting method based on TEE, such as Figure 2 and Figure 4 As shown, the specific steps are as follows:

[0053] Step 1: Based on the dual-key system of the parallel chain structure, a new block structure consisting of 4 fields is constructed;

[0054] The 4 fields are: block hash block_hash, block parent hash previous_hash, node signature node_signature and TEE signature tee_signature.

[0055] The parent hash of a block is the hash of the latest block that it has published.

[0056] When a node publishes a block, TEE signature and node signature must be performed separately; TEE signature and node signature are implemented using different public and private keys respectively;

[0057] The TEE signature is a signature obtained using the trusted execution environment TEE. It is necessary to check the parent hash of the block and sign the block hash to ensure that the node that publishes the block cannot send different blocks with the same number to other nodes.

[0058] The TEE signature key is stored in a secure file system and cannot be directly accessed from the outside. It can only be read by the TEE program, ensuring the confidentiality and non-tamperability of the key.

[0059] The node signature is a signature obtained using a signature algorithm in a non-trusted execution environment, which is used to ensure the non-repudiation of newly released blocks.

[0060] Due to the non-repudiation of the digital signature itself, the node signature does not need to be executed in the TEE, saving computing resources.

[0061] The blockchain structure based on parallel chains, such as Figure 3 As shown, each block has two references, pointing to the last block published by this node and the last block published by another node;

[0062] Step 2: For the TEE signature tee_signature field in the new block structure, generate the key for this field in the TEE executable program and save it in the TEE secure file system; it can only be accessed by the TEE executable program.

[0063] The specific process of generating a key is as follows:

[0064] First, check whether there is a key stored in the secure file system; if so, skip the generation step and end; otherwise, execute the function EC_KEY_new_by_curve_name(NID_secp256k1) to generate a pair of ECDSA public and private keys Tee_privatekey and Tee_publickey for a specific elliptic curve;

[0065] Then, the functions PEM_write_bio_ECPrivateKey and BIO_get_mem_data are executed to save the private key Tee_privatekey as a string and store it in the secure file system.

[0066] Step 3: For the node signature node_signature field in the new block structure, use the ECDSA function in a normal environment to generate the public and private key pairs privatekey and publickey in a normal environment.

[0067] The ECDSA functions come from the org.spongycastle.crypto.params.ECDomainParameters package.

[0068] Step 4: For the block A to be signed published by the current node I, use the common environment signature function Sign to obtain the node signature node_signature;

[0069] When a block signature operation needs to be performed, two types of signatures need to be executed, namely the normal environment signature Sign and the TEE signature TEE_Sign.

[0070] First, use the ordinary signature to get the node_signature to ensure the non-repudiation of the node's block release, and the security can be guaranteed by the digital signature itself. Then use TEE_Sign in the trusted execution environment to prevent nodes from doing evil. Due to the use of TEE, each parent hash PreviousHash can only be signed once, so malicious nodes cannot build and publish malicious blocks, thereby reducing the complexity of the consensus algorithm.

[0071] Step 5: Use TEE signature function TEE_Sign to sign block A and determine whether block A is the first block released by node I. If so, proceed to step 6 for TEE signature; otherwise, proceed to step 10 for TEE signature;

[0072] Step 6: After signing the first block A published by the current node I, send it to other nodes in the blockchain network.

[0073] The specific process is:

[0074] Create an intermediate variable temp in the TEE environment, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network.

[0075] The signature block block_hash is temporarily saved in the temp variable.

[0076] When it exists, directly store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; and sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network.

[0077] Since the published block may not be confirmed by other nodes, the content of the temp field will be written into the savedHash field after the block is confirmed. The temp field generation timestamp temp_timestamp is recorded. During the existence of the temp field (the maximum time is set to the threshold TTL), the temp field cannot be changed or deleted to ensure that the node does not publish different blocks.

[0078] The initial value of savedHash is the block_hash of the first block that has passed verification and voting in the blockchain network. The savedHash value is not saved before the first block is released. The first block has no parent hash previous_hash, so there is no need to verify whether previous_hash is equal to savedHash.

[0079] During the actual operation, the node may shut down due to unexpected failures such as power outages. To ensure the persistent storage of the savedHash field and the temp field, these two fields need to be written to the secure file system of the TEE.

[0080] Step 7: Other nodes in the blockchain network verify the legitimacy and uniqueness of block A and vote in favor after verification.

[0081] The uniqueness verification is as follows: when other nodes in the blockchain network receive block A, they store the block hash block_hash in the voting queue HashMap, and search in the queue HashMap whether there is already a block with the same block number number as block A but a different block hash hash. If so, it proves that votes have been cast for other blocks of number, and block A cannot be voted for repeatedly.

[0082]

[0083] The verification of legitimacy is as follows: the Verify function and TEE_Verify function are called respectively to perform signature verification on the node signature node_signature and TEE signature tee_signature of block A. After the signature verification passes, an affirmative vote is made. In the affirmative vote, TEE is used to sign the voting information to obtain tee_vote_signature.

[0084] Step 8. Node I calls the TEE_Verify function in the TEE environment to verify the signature tee_vote_signature of the affirmative vote, and counts the number of votes vote_num that have passed the verification;

[0085] Step 9. Create the savedHash field in the TEE environment of node I. When the number of votes vote_num is greater than half of the number of nodes in the blockchain network, update the savedHash field;

[0086] When the number of votes vote_num is greater than half of the number of all nodes in the blockchain network, node I saves the variable temp field to the savedHash field and deletes the temp field; at this time, the savedHash field in the TEE environment is updated to the block_hash of block A;

[0087] When the number of votes vote_num is less than or equal to half of the number of nodes in the blockchain network, it means that the block released by this node may conflict with other nodes. When a new node is released, check whether the difference between the release timestamp and temp_timestamp exceeds TTL. If it exceeds TTL, it means that the block has not been received. At this time, the original temp field can be deleted and a new block can be released.

[0088] Step 10: For the second and subsequent blocks A released by the current node I, the previous_hash field of the block and the generation time of the block need to be verified and signed, and then sent to other nodes in the blockchain network, and return to step 7 for verification of block A by other nodes in the blockchain network.

[0089] The specific verification and signing steps are:

[0090] Step 10.1. First, obtain the parent hash previous_hash of the block A to be signed, and check whether the previous_hash field is the same as the savedHash field; if they are not the same, reject the signature; if they are the same, check whether there is an intermediate variable temp and its corresponding timestamp temp_timestamp;

[0091] Step 10.2: If it exists, check whether the difference between the release time of block A and temp_timestamp exceeds the pre-set threshold TTL. If it does not exceed TTL, it means that TEE has performed a signing operation on another block within the TTL time, and the block has not been confirmed by other nodes. At this time, in order to prevent nodes from maliciously publishing different copies of blocks, TEE refuses to sign. If it exceeds TTL, it means that there is a block signed before TTL that has not been confirmed by other nodes in the blockchain. At this time, the TEE signature of step 1004 can be executed.

[0092] Step 10.3: If it does not exist, directly execute TEE signing in step 1004.

[0093] Step 10.4, TEE signature process is: create an intermediate variable temp in the TEE environment, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network.

[0094] Step 11. During the actual operation, when the offline node node_x reconnects to the blockchain network, it needs to communicate with other nodes to synchronize the new blocks released by the node when it is not in the blockchain network, so as to complete the sorting of the newly released blocks during the offline period.

[0095] The following two steps are discussed in detail:

[0096] 11.1: When node node_x saves the temp field and signs to obtain tee_signature, it suddenly disconnects from the blockchain network. At this time, even if the block published by node_x is received by other nodes, the offline node_x cannot update the temp field in time, which will cause node_x to be unable to publish new blocks. Therefore, when node node_x reconnects, it first asks node_x in the blockchain network whether there are newly published blocks, that is, blocks published before node_x goes offline. If there are newly published blocks, delete the temp field after synchronizing the node.

[0097] 11.2: After checking the temp field, the reconnected node node_x only needs to synchronize the newly released blocks of other nodes. Therefore, after the node is connected to the blockchain network, it needs to poll other nodes, query the new blocks released by each node and synchronize them to this node.

[0098] At this point, the block synchronization and sorting process is completed, including the block sorting when the node is running online and the block sorting after the node is disconnected and reconnected, which can ensure the orderly arrangement of blocks in the entire process of node operation in the blockchain system.

[0099] The symbol comparison table used in the present invention is as follows:

[0100] TEE_Sign Signature function in Tee environment TEE_Verify Verification function in Tee environment Sign Signature function in normal environment Verify Verification function in normal environment Tee_privatekey Private key in Tee environment Tee_publickey Public key in Tee environment privatekey Private key in normal environment publickey Public key in normal environment block_hash Block Hash in Block Structure previous_hash Parent hash in block structure tee_signature Tee signature in block structure node_signature Node signature in block structure tee_vote_signature TEE signature in voting message savedHash Save the block_hash of the last signed block temp Intermediate variable, temporarily save block_hash temp_timestamp The generation time of the intermediate variable temp vote_num Number of votes passed TTL Maximum timeout for temp field lock node_x A node that leaves the blockchain network

Claims

1. A distributed DAG block security sorting method based on TEE, characterized in that: The specific steps are as follows: Step 1: Based on the dual-key system of the parallel chain structure, a block structure consisting of 4 fields is constructed; The 4 fields are: block hash block_hash, block parent hash previous_hash, node signature node_signature and TEE signature tee_signature; when a node publishes a block, it needs to perform TEE signature and node signature respectively; Step 2: For the TEE signature tee_signature field in the block structure, generate the key of this field in the TEE executable program and save it in the TEE secure file system; Step 3: For the node signature node_signature field in the block structure, use the ECDSA function in a normal environment to generate the public and private key pair privatekey and publickey of the normal environment; Step 4: For the block A to be signed published by the current node I, use the common environment signature function Sign to obtain the node signature node_signature; Step 5: Use TEE signature function TEE_Sign to sign block A and determine whether block A is the first block released by node I. If so, proceed to step 6 for TEE signature; otherwise, proceed to step 10 for TEE signature; The uniqueness verification is as follows: when other nodes in the blockchain network receive block A, they store the block hash block_hash in the voting queue HashMap, and check in the queue HashMap whether there is already a block hash hash with the same block number number as block A but different from it. If so, it proves that they have voted for other blocks with the same block number number, and they cannot vote for block A repeatedly. The verification of legitimacy is as follows: call the Verify function and TEE_Verify function to perform signature verification on the node signature node_signature and TEE signature tee_signature of block A respectively. After the signature verification passes, make an affirmative vote. In the affirmative vote, use TEE to sign the voting information and obtain tee_vote_signature; Step 6: After signing the first block A published by the current node I, send it to other nodes in the blockchain network; The specific process is: Create an intermediate variable temp in the TEE environment; then, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; and sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network; Step 7: Other nodes in the blockchain network verify the legitimacy and uniqueness of block A and vote in favor after verification. Step 8. Node I calls the TEE_Verify function in the TEE environment to verify the signature tee_vote_signature of the affirmative vote, and counts the number of votes vote_num that have passed the verification; Step 9. Create the savedHash field in the TEE environment of node I. When the number of votes vote_num is greater than half of the number of nodes in the blockchain network, update the savedHash field. When the number of votes vote_num is greater than half of the number of all nodes in the blockchain network, node I saves the variable temp field to the savedHash field and deletes the temp field; at this time, the savedHash field in the TEE environment is updated to the block_hash of block A; When the number of votes vote_num is less than or equal to half of the number of all nodes in the blockchain network, it means that the block released by the current node I may conflict with other nodes; Step 10: For the second and subsequent blocks A released by the current node I, the parent hash previous_hash field of the block and the generation time of block A are verified and signed, and then sent to other nodes in the blockchain network, and then return to step 7 for other nodes in the blockchain network to verify block A; The specific verification and signing steps are: First, get the parent hash previous_hash of the block A to be signed, and check whether the previous_hash field is the same as the savedHash field; if they are not the same, reject the signature; if they are the same, check whether there is an intermediate variable temp and its corresponding timestamp temp_timestamp; If it exists, check whether the difference between block A’s publishing time and temp_timestamp exceeds TTL; If the TTL is not exceeded, TEE refuses to sign; If the TTL is exceeded, TEE signing is performed; If it does not exist, execute TEE signing directly; The TEE signature process is as follows: create an intermediate variable temp in the TEE environment, store the hash block_hash of block A in the intermediate variable temp, record the generation timestamp temp_timestamp of the variable temp field; sign the block_hash field to obtain the TEE signature tee_signature; send block A to other nodes in the blockchain network; Step 11. During the actual operation, when the offline node node_x reconnects to the blockchain network, it needs to communicate with other nodes to synchronize the new blocks released by the offline node node_x during the period when it was not in the blockchain network, so as to complete the sorting of the newly released blocks during the offline period.

2. The TEE-based distributed DAG block security sorting method as claimed in claim 1, characterized in that: In steps 6 and 10, the TEE signature needs to check the parent hash of the block and sign the block hash to ensure that the node cannot send different blocks of the same parent node to other nodes; at the same time, the intermediate variable temp is used to ensure that the TEE can continue to sign subsequent legal blocks even if the block is not confirmed by other nodes in the network; The node signature is a signature obtained using a signature algorithm in a non-trusted execution environment, which is used to ensure the non-repudiation of newly released blocks.

3. The TEE-based distributed DAG block security sorting method as claimed in claim 1, characterized in that: In step 2, the specific process of generating the key is as follows: First, check whether there is a key stored in the secure file system; if so, end; otherwise, execute the function EC_KEY_new_by_curve_name to generate a pair of ECDSA public and private keys Tee_privatekey and Tee_publickey for a specific elliptic curve; Then, the functions PEM_write_bio_ECPrivateKey and BIO_get_mem_data are executed to save the private key Tee_privatekey as a string and store it in the secure file system.

4. The TEE-based distributed DAG block security sorting method as claimed in claim 1, characterized in that: In step 3, the ECDSA function comes from the org.spongycastle.crypto.params.ECDomainParameters function package.

5. The TEE-based distributed DAG block security sorting method as claimed in claim 1, characterized in that: In step 11, the following two steps are discussed in detail for block synchronization after the disconnected node is reconnected: 11.1: If node node_x suddenly disconnects from the blockchain network after saving the temp field and signing to obtain tee_signature, when node node_x reconnects, it first asks node_x in the blockchain network whether there is a newly released block, that is, the block released before node_x goes offline; if there is a newly released block, delete the temp field after synchronizing the node; 11.2: After checking the temp field, the reconnected node node_x only needs to synchronize the newly released blocks of other nodes; therefore, after the node is connected to the blockchain network, it needs to poll other nodes, query the new blocks released by each node and synchronize them to node node_x; At this point, the block synchronization and sorting process is completed, including the block sorting when the node is running online and the block sorting after the node is disconnected and reconnected, which can ensure the orderly arrangement of blocks in the entire process of node operation in the blockchain system.

Images