Smart contract non-incremental sorting execution method, system, device and storage medium based on DAG structure of account chain and guardian chain

Abstract

The present invention provides a non-incremental sorting execution method for smart contracts under a DAG structure based on an account chain and a guardian chain, characterized in that when the consensus node performs sorting, the following steps are included: S1. Anchoring the account chain sequence; S2. Recording the account chain block height; S3. According to the account chain sequence and block height, the contract transaction blocks to be executed on the account chain are traced back and executed in sequence; the witness node traces back and executes the contract transaction blocks to be executed on the account chain in sequence according to the account chain sequence and block height anchored by the consensus node. The present invention also provides a non-incremental sorting execution system, device and storage medium. The present invention can well complete the smart contract sorting execution without increasing the block size, and solves the problem of determining the final state of the contract under a multi-chain parallel structure.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and more specifically to a smart contract sorting execution method, system, device and storage medium based on a DAG structure of an account chain and a guardian chain. Background Art

[0002] The blockchain is a single chain composed of blocks, which can only be written in sequence according to the block generation time, just like a single-core single-threaded CPU.

[0003] The throughput of the blockchain is limited by the size of the block. If the block is too small and the transaction volume is large, many transactions cannot be packed into the block. If the block is too large, the data volume of the entire blockchain system will expand rapidly, and ordinary users will not be able to run a full node, which will cause centralization problems.

[0004] Later, some blockchain projects based on DAG topology emerged. These projects tried to apply the characteristics of DAG to improve the shortcomings of traditional chain-structured distributed ledger technology, introduced a blockless concept, and directly used transactions to confirm and maintain relationships with each other, eliminating the packaging process and bringing a new distributed ledger implementation idea.

[0005] DAG stands for Directed Acyclic Graph. In a DAG, all nodes point in the same direction, so it is acyclic. No element can refer back to itself. It is a data structure that only allows one-way information flow.

[0006] In addition, in another patent of the applicant, a system and method of a DAG blockchain structure based on an account chain and a guardian chain, a system of a DAG blockchain structure based on an account chain and a guardian chain is described. The system of a DAG blockchain structure based on an account chain and a guardian chain includes: a sender account chain, a receiver account chain, and a guardian chain;

[0007] The sender account chain is used to create a transaction sending block when a transaction needs to be initiated, sign the transaction sending block with a private key, obtain a signed transaction sending block, and broadcast the signed transaction sending block;

[0008] The receiver account chain is used to create a transaction receiving block after the signed transaction sending block is witnessed in the account chain witness network, and to establish a first block key between the transaction receiving block and the transaction sending block;

[0009] The sender account chain is also used to send a transfer transaction based on the transaction sending block;

[0010] The receiver account chain is further used to receive the transfer transaction based on the transaction receiving block;

[0011] The guard chain is used to obtain the first current state information of the transaction sending block and the second current state information of the transaction receiving block, package the first current state information and the second current state information, and store the packaged first current state information and the second current state information to guard the transfer transaction.

[0012] Optionally, the sender account chain is also used to create a contract deployment block when a contract needs to be deployed, and publish a contract transaction through the contract deployment block;

[0013] The guard chain is also used to deploy contracts according to the contract deployment block;

[0014] The receiver account chain is further used to create a contract execution block when a contract needs to be executed, establish a second block key between the contract deployment block and the contract execution block, and call the contract transaction through the contract execution block;

[0015] The guardian chain is also used to execute the contract according to the contract execution block, and obtain the third current state information of the contract deployment block and the fourth current state information of the contract execution block, package the third current state information and the fourth current state information, and store the packaged third current state information and the fourth current state information to complete the contract call process.

[0016] However, in the DAG diagram structure of multiple account chains and single guardian chain, the generation and calling of smart contracts are all issued by the account nodes on the account chain. The account chain is a multi-chain parallel transaction structure. Different account chains call a contract at the same time. This process is called a multi-chain parallel call contract scenario. In this scenario, multiple chains will read or change the data in the contract and the blockchain status at the same time, making it impossible to confirm the final status. How to ensure the reasonable implementation of the multi-chain parallel call contract scenario is an urgent problem to be solved.

[0017] The above contents are only used to assist in understanding the technical solution of the present invention and do not constitute an admission that the above contents are prior art. Summary of the invention

[0018] The purpose of the present invention is to solve the above problems and provide a non-incremental sorting execution method for smart contracts under the DAG structure based on account chain and guardian chain.

[0019] In order to achieve the above object, the technical solution of the present invention is as follows:

[0020] The method for executing non-incremental sorting of smart contracts under the DAG structure based on the account chain and the guardian chain is characterized in that when the consensus node performs sorting, the following steps are included: S1. Anchoring the account chain sequence; S2. Recording the account chain block height; S3. According to the account chain sequence and block height, tracing back and executing the contract transaction blocks to be executed on the account chain in sequence; the witness node traces back and executes the contract transaction blocks to be executed on the account chain in sequence according to the account chain sequence and block height anchored by the consensus node.

[0021] Furthermore, when the consensus node needs to include a newly added contract transaction block, steps S1-S3 are re-executed.

[0022] Furthermore, the account chain node initiates the deployment and execution request of the smart contract, and then the guardian chain node completes the actual deployment and execution procedure of the smart contract.

[0023] The present invention also provides a non-incremental sorting execution system for smart contracts under a DAG structure based on an account chain and a guardian chain, characterized in that it includes an account chain sequence module, an account chain block height module and an execution module. The account chain sequence module sorts the account chains, the account chain block height module records the block height of each account chain, and the execution module traces and executes the contract transaction blocks of the account chain according to the account chain sequence and block height.

[0024] Furthermore, the system also includes a request module, which is set in the account chain node, and the request module initiates a deployment and execution request of the smart contract.

[0025] Furthermore, the execution module includes a consensus node execution module and a witness node execution module.

[0026] In addition, the present invention also provides a non-incremental sorting execution device for smart contracts under the DAG structure based on account chain and guardian chain, characterized in that it includes: a memory, a processor, and a non-incremental sorting execution program for smart contracts under the DAG structure based on account chain and guardian chain stored in the memory and runnable on the processor, the non-incremental sorting execution program for smart contracts under the DAG structure based on account chain and guardian chain is configured with all or a certain process of implementing the non-incremental sorting execution method for smart contracts under the DAG structure based on account chain and guardian chain.

[0027] The present invention also provides a storage medium, characterized in that a non-incremental sorting execution program for smart contracts under the DAG structure based on account chains and guardian chains is stored on the storage medium. When the non-incremental sorting execution program for smart contracts under the DAG structure based on account chains and guardian chains is executed, all or a certain process in the non-incremental sorting execution method for smart contracts under the DAG structure based on account chains and guardian chains is implemented.

[0028] By adopting the above technical solution, the present invention has the following advantages:

[0029] 1. Ordinary transactions of the present invention can be completed without the execution of the guardian chain. Only smart contract transactions require the witness execution of the guardian chain, so the efficiency of ordinary transactions on the account chain is very high.

[0030] 2. The transaction efficiency of the smart contract of the present invention is determined by the witness consensus, and the efficiency can still be very high.

[0031] 3. The present invention solves the problem of determining the final state of a contract under a multi-chain parallel structure, and can well complete the sorting execution of smart contracts without increasing the block size.

[0032] 4. Without incorporating new contract transaction blocks, the execution efficiency of the present invention is very high. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a diagram of the deployment and execution process of the smart contract of the present invention.

[0034] Figure 2 Process diagram of the transaction non-incremental sorting execution method of the present invention.

[0035] Figure 3 It is a process diagram of the transaction increment sorting execution method of the present invention. DETAILED DESCRIPTION

[0036] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not intended to limit the present invention.

[0037] Example 1: The present invention is based on the smart contract sorting execution method under the DAG structure of the account chain and the guardian chain. The account chain is a chain structure formed in sequence by recording each account separately, with a single transaction as a single block, and each account forms an account chain. Each account forms an account chain. The account chain block mainly includes ordinary transaction blocks and contract transaction blocks. Its ordinary transaction block includes sending transaction blocks (such as Figure 1 Block S in Figure 2 , Figure 3 AS2, BS1, DS1, DS3) and receiving transaction blocks (such as Figure 1 Block R in Figure 2 , Figure 3 The contract transaction block includes the contract deployment block (such as Figure 2 , Figure 3 Block CC1 in the contract execution block (such as Figure 1 , Figure 2 , Figure 3The first block on each account chain is a receiving transaction block, which completes the creation of the account chain by receiving the first transaction sent by other accounts to the account.

[0038] The ordinary transaction blocks or contract transaction blocks on the account chain mainly contain information such as header and body. The header mainly contains information such as the transaction type, receiver, sender, parent block hash, transaction amount, etc.; the body mainly contains information such as balance, guardian chain deposits received by the account chain, and account chain record points.

[0039] The reference relationship between account chains due to sending and receiving transactions is called a block bond. Account chains are linked to each other through block bonds to form a DAG structure, which is similar to a lattice model and is also called an account lattice.

[0040] There are several types of account chains, including common nodes and witness nodes. Common nodes are nodes that implement transactions in the account chain, and are mainly responsible for the generation of various transaction blocks in the account chain; witness nodes are full nodes in the account chain, composed of authoritative and trusted nodes, and complete functions such as block verification, block witnessing, block chaining, block broadcasting, and block storage. The operation of witness nodes is supervised by other nodes. If there is any violation, it will be punished by witness authority, deposit deduction, etc.

[0041] The consensus nodes in the guardian chain generate guardian blocks by packaging account chain transaction blocks (such as Figure 1 , Figure 2 and Figure 3 The blocks D3, D7, and D in the blockchain constitute the guardian chain. The guardian chain is started by the genesis block G. The guardian block mainly contains information such as header and body. The header mainly contains information such as the world state tree hash, difficulty, block number, and parent block hash; the body mainly contains information such as the anchored account chain address, the block height of the account chain, and the transaction block.

[0042] When the guardian block on the guardian chain is generated, it will package the latest transaction block of the account chain of the current epoch, and there will be a reference relationship with the block on the account chain. When the account block on the account chain is generated, it will point to the latest guardian block on the account chain through the reference relationship to obtain the current state and complete the witness of the block. The reference relationship between the guardian block and the transaction block of the account chain is called a cross-link bond. The guardian chain mainly witnesses the current account lattice state. At the same time, the account chain records the guardian block, which is cross-linked with each other through the cross-link bond to form the final stable lattice structure.

[0043] There are two main types of nodes in the Guardian Chain: consensus nodes and witness nodes. The consensus node can complete the sorting of smart contract transactions in the Guardian Chain and package them to generate guardian blocks; the witness node is a full node in the Guardian Chain, composed of authoritative and trusted nodes, and completes functions such as block verification, block witnessing, block chaining, block broadcasting, and block storage. The operation of the witness node is supervised by other nodes. If there is any violation, it will be punished by witness authority, deposit deduction, etc.

[0044] like Figure 1 As shown in the figure, the generation and release of smart contracts are the work of ordinary nodes and witness nodes of each account chain. The ordinary node of the account chain determines the contract text, generates a contract deployment block, and broadcasts it to the witness node in the account chain for witnessing. At this time, the state of the contract deployment block (C1) is in the sent stage. After receiving the broadcast, the account chain witness node witnesses it. When a certain number of account chain witness nodes complete the witness consensus of the contract deployment block, the contract deployment block is successfully chained to the account chain that generated the transaction block. At this time, the state of the contract deployment block (C2) is in the deployment waiting stage, completing the generation and release process of the smart contract.

[0045] Contract deployment is the work of consensus nodes and witness nodes in the guardian chain. The consensus node sorts and packages the received contract deployment blocks to generate a guardian block (D3). Then the witness node executes the smart contract once according to the order of the consensus node and witnesses it. After the witness process is completed, the contract deployment block is uploaded to the guardian chain along with the guardian block. At this time, the contract deployment block is in the deployed stage, completing the contract deployment process.

[0046] When an account on the account chain needs to call a smart contract transaction that has been deployed by the guardian chain, the ordinary node of the account chain will generate a contract execution block and broadcast it to the witness node in the account chain for witnessing. At this time, the state of the contract execution block (E5) is in the sent stage. When a certain number of witness nodes complete the witness consensus of the contract execution block, the contract execution block is successfully chained to the account chain that generated the transaction block. At this time, the state of the contract execution block (E6) is in the pending execution stage. Then it is sorted and packaged by the guardian chain consensus node to generate a guardian block (D7). After the guardian chain witness node executes the witness, the state of the contract execution block is converted from pending execution to executed state, completing the process of the account on the account chain calling the smart contract.

[0047] The generation and calling of smart contracts are all issued by ordinary nodes on the account chain. When generating and calling smart contracts, the data in the smart contract and the blockchain status will be read or changed. Since the account chain is a multi-chain parallel transaction structure, when different accounts call a smart contract at the same time, the same smart contract data or blockchain status will be read or changed at the same time, making it impossible to confirm the final status. This process is called a multi-chain parallel contract call scenario.

[0048] In order to solve the problem of being unable to determine the final state due to the scenario of multi-chain parallel contract calls, the present invention generates a corresponding contract transaction block by the account chain node when the smart contract has simultaneous call access status, reading and writing of the same data, contract transfer, etc., initiates the deployment and execution request of the smart contract, and then hands it over to the guardian chain node to complete the actual deployment and execution procedure of the smart contract. In the actual deployment and execution process, the smart contracts are sorted through the established process, and the sorting is guaranteed to be fixed, and all nodes are performed in the same order.

[0049] The present invention provides two sorting methods as follows:

[0050] The first is a non-incremental transaction sorting execution method. It is suitable for scenarios where after the guard block is packaged, no new contract transactions will be included. The advantage of this sorting method is that it does not increase the block size.

[0051] Under this method, when the consensus node packages the guardian block, it collects the latest transaction blocks of the account chain that needs to be packaged in the transaction pool, anchors the account chain sequence, and records the current block height of each account chain. Then the consensus node traces back the contract transaction blocks to be executed on each account chain according to the anchored account chain sequence and the block height of each account chain. The consensus node will select these contract transaction blocks to execute. When the guardian block is packaged, the consensus node will broadcast it. After receiving the broadcast, the witness node on the guardian chain will trace back the contract transaction blocks to be executed on each account chain according to the account chain sequence anchored by the guardian block and the recorded account chain block height, and execute them to complete the witness verification.

[0052] Since both the consensus node and the witness node trace the contract transaction blocks on the account chain according to the account chain sequence anchored by the guardian block and the recorded account chain block height, the execution order of the consensus node and the witness node can be guaranteed to be consistent.

[0053] It should be noted that the non-incremental sorting execution method referred to herein, and the scenario setting applicable to no longer including new transactions after the guardian block is packaged, does not mean that incremental sorting cannot be performed, nor does it mean that new contract transactions cannot be included after the block is packaged. It is just that when the non-incremental sorting execution method is used, if incremental sorting is required and new contract transactions are continued to be included, if the new contract transactions cannot be sorted at the end, the consensus node needs to re-execute all contract transaction blocks from the beginning, which affects efficiency.

[0054] The second method is the transaction incremental sorting execution method, which better supports transaction incremental operation and is suitable for scenarios where new transactions need to be included after the block is packaged. This method can avoid wasting computing resources and packaging time.

[0055] For example, to ensure that blocks can be generated within the specified time, the guardian chain consensus node always prepares a guardian block to package the account chain transaction block. Before the block generation time point, as long as there are new transaction blocks on the account chain, the guardian chain consensus node can package them into the guardian block and update the block.

[0056] If the first non-incremental transaction sorting execution method is used, the consensus node only records the order and block height of the account chain. When tracing the contract transaction blocks of the account chain, these newly added contract transaction blocks are likely to not be directly sorted at the end. In order to ensure the consistency of the execution order of the consensus node and the witness node, the consensus node needs to re-execute all contract transaction blocks from the beginning. This wastes computing resources and delays packaging time, seriously affecting operating efficiency.

[0057] In this scenario, the present invention provides a second transaction incremental sorting execution method as follows: add smart contract records (Instructions) in the guardian block. The consensus node records the sorting results of the contract transaction block in the smart contract record (Instructions). If there are new transactions that need to be packaged into the guardian block, the consensus node can record the sorting results of the new contract transaction blocks in the smart contract record (Instructions) in sequence after the original sorting results.

[0058] After the consensus node has packaged the guard block, the smart contract record (Instructions) is fixed in the guard block. The subsequent witness node can obtain the smart contract record (Instructions) information in the guard block, and select the contract transaction block to execute in turn according to the information of the smart contract record (Instructions) to complete the witness verification.

[0059] Since the smart contract records (Instructions) record the sorting results of all contract transaction blocks, the consensus nodes and witness nodes are executed in the order recorded in the smart contract records (Instructions), ensuring the consistency of the execution order. In this way, when a new contract transaction block appears, the consensus node does not need to re-execute from the first contract transaction block of the block.

[0060] Combine the following Figure 2 and Figure 3 The above two sorting execution methods are described in detail respectively.

[0061] like Figure 2 As shown in the figure, it is a non-incremental sorting execution method. After the first generation (Epoch1) guardian block is put on the chain, the packaging process of the second generation (Epoch2) guardian block is entered. The consensus node of the guardian chain collects the latest transactions of the account chain, obtains the block height of each current account chain, and records it in the current guardian block. Before the new contract execution block AE3 is put on the account chain, the order of the account chain anchored by the consensus node and the recorded account chain block height are: A account chain AS2, B account chain BE2, C account chain CE3, D account chain DS3.

[0062] Then the consensus node will trace back the pending contract transaction blocks on each account chain in turn according to the anchored account chain sequence and account chain block height, and execute them. At this time, the consensus node first traces back the A account chain and executes the contract execution block AE1. Since the contract execution block AE3 of the A account chain is not on the chain at this time, the A account chain has only one pending block AE1 at the AS2 height. The consensus node traces back and executes the A account chain, and continues to trace the B account chain and executes the contract execution block BE2. After tracing and executing the B account chain, the consensus node continues to trace the C account chain and executes the contract execution blocks CE2 and CE3 in turn. Then trace the D account chain and execute the contract execution block DE2.

[0063] The execution order is: AE1-BE2-CE2-CE3-DE2.

[0064] When the guardian block is packaged, the consensus node will broadcast it. After receiving the broadcast, the witness node on the guardian chain will trace back the contract transaction blocks to be executed on each account chain in turn according to the account chain sequence anchored by the guardian block and the recorded account chain block height, and execute them to complete the witness verification. Since the account chain sequence traced by the consensus node and the guardian node and the block height of each account chain are consistent, the order in which the consensus node and the witness node execute the contract transaction blocks is exactly the same.

[0065] Before the consensus node broadcasts, if a new contract execution block AE3 is on the chain, and the consensus node wants to include this block in the guardian block of this generation (Epoch2), because if the consensus node puts the execution order of the new contract execution block AE3 at the end, its final execution order will be: AE1-BE2-CE2-CE3-DE2-AE3. The witness node performs retroactive execution according to the account chain sequence anchored by the guardian block and the recorded account chain block height, and its final execution order will be: AE1-AE3-BE2-CE2-CE3-DE2. This will cause the execution order of the consensus node and the witness node to be inconsistent. In order to keep the execution order of all nodes consistent, the consensus node needs to re-anchor the account chain sequence and re-record the block height of each account chain, and execute the contract transaction block again from the beginning. That is, the re-anchored account chain sequence and block height are: A account chain AE3, B account chain BE2, C account chain CE3, D account chain DS3. The final execution order of the consensus nodes is: AE1-AE3-BE2-CE2-CE3-DE2. In this way, the execution order of subsequent witness nodes can be consistent with that of the consensus nodes.

[0066] like Figure 3 As shown in the figure, it is the transaction incremental sorting execution method. After the first generation (Epoch1) guardian block is on the chain, it enters the packaging process of the second generation (Epoch2) guardian block. During the packaging time period of the second generation guardian block, if there are new account chain transaction blocks on the chain, the transaction hashes of these transaction blocks will be stored in the transaction pool of the consensus node. The consensus node of the guardian chain collects the latest transactions of the account chain and records the transaction hash of the contract transaction block in the smart contract record (Instructions) of the guardian block. Then the consensus node will sort these transaction hashes (that is, sort the contract transaction blocks), and according to the sorting results, quickly trace and locate the contract transaction blocks through the transaction hashes in turn, and execute them.

[0067] Before the new contract execution block AE3 is put on the account chain, the consensus node collects the transactions of the account chain and records the transaction hashes of the contract transaction blocks AE1, BE2, CE2, CE3, and DE2 in the transaction pool into the smart contract record (Instructions), and then sorts them to get the sorting result: AE1-BE2-CE2-CE3-DE2. Figure 3As shown, directly according to the time sequence of the contract transaction blocks, the transaction hashes of the corresponding contract transaction blocks are added to the smart contract records (Instructions) in sequence to form a sorting result: AE1-DE2-CE2-CE3-BE2. Of course, the corresponding transaction hashes can also be added in other ways, and then they can be sorted according to rules or not, as long as a sequence result is finally formed, which we also call the "sorting result". It can be seen from this that the "sorting result" does not necessarily have to go through the rule sorting procedure.

[0068] The consensus node will then trace the transaction hashes based on the sorting results and locate the corresponding contract transaction blocks for execution.

[0069] When the guardian block is packaged, the consensus node will broadcast it. After receiving the broadcast, the witness node on the guardian chain will trace back to the contract transaction block on the account chain through the transaction hash in turn according to the sorting results recorded in the smart contract record (Instructions) of the guardian block, and execute it to complete the witness verification. Since both the consensus node and the guardian node are executed according to the sorting results recorded in the smart contract record (Instructions), it can be well guaranteed that all nodes are executed in a unified order.

[0070] Before the consensus node broadcasts, if a new contract execution block AE3 is on the chain, and the consensus node wants to include this block in the guardian block of this generation (Epoch2), the consensus node can record the transaction hash of the contract execution block in the smart contract record (Instructions). Since the consensus node does not want to re-execute the previous contract transaction block, the consensus node will sort the latest contract transaction block to the back of the original order in the smart contract record (Instructions), such as Figure 3 As shown in the figure, the ordering result in the smart contract record (Instructions) is: AE1-DE2-CE2-CE3-BE2-AE3. Then the consensus node will execute the newly added contract transaction block.

[0071] It should be noted that the above only describes the situation where a new block is on the chain. If there are multiple account chains, multiple new blocks on the chain, and the consensus node wants to include all these new blocks in the guardian block, the consensus node will still record the transaction hash of these new contract transaction blocks in the smart contract record (Instructions), and put the order of these new contract transaction blocks behind the original sorting result. Then the consensus node will execute the newly added contract transaction blocks according to the sorting result.

[0072] Subsequent witness nodes are executed in the order of the modified smart contract records, which can ensure that the execution order of all nodes is consistent.

[0073] It should be noted that the consensus node can execute the contract transaction block after the sorting result is formed or before the sorting result is formed. For example, the consensus node first executes the contract transaction block, and then adds the transaction hash of the contract transaction block to the smart contract record (Instructions) in the execution order to form the sorting result; it can also add the transaction hash of the contract transaction block to the smart contract record (Instructions) while executing to form the sorting result, which does not affect the overall operation consistency. In other words, as long as the consensus node and the witness node execute the contract transaction block in the order of the sorting result in the smart contract record, the overall operation consistency can be guaranteed.

[0074] It should be noted that in the above description, the smart contract record (Instructions) records the order of transaction hashes, and traces and locates them through transaction hashes. In fact, not only transaction hashes can be used as the basis for recording, but any content that can identify the transaction block can be recorded in the smart contract record (Instructions) as an effective means, and then these contents are sorted, and based on the sorting results, they can be traced back to the contract transaction block for execution.

[0075] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of the present invention. In practical applications, technicians in this field can select part or all of them according to actual needs to achieve the purpose of the invention, and no limitation is made here.

[0076] Embodiment 2: In addition, the embodiment of the present invention also proposes a non-incremental sorting execution system for smart contracts based on the DAG structure of the account chain and the guardian chain, including an account chain sequence module and an account chain block height module. The account chain sequence module sorts the account chains, and the account chain block height module records the block height of each account chain.

[0077] The smart contract non-incremental sorting execution system also includes an execution module, which traces and executes the contract transaction blocks of the account chain according to the account chain sequence and block height. The execution module includes a consensus node execution module and a witness node execution module.

[0078] The smart contract non-incremental sorting execution system also includes a request module, which is set in the account chain node, and the request module initiates the deployment and execution request of the smart contract.

[0079] It should be noted that the above modules can be deployed separately in different spatial areas or devices and systems in actual deployment. Those skilled in the art understand the respective functions of each module and can deploy or use them separately to use the module in different devices, methods and systems.

[0080] It should be noted that the above module inclusion relationship means that the upper module includes the lower module, and does not mean that it is only composed of the lower module. In fact, the upper module can include many other lower modules, and those skilled in the art can add them as needed.

[0081] In addition, this embodiment is only a basic description of the smart contract sorting execution system of the present invention. For technical details that are not fully described in this embodiment, please refer to the method provided in any embodiment of the present invention, and will not be repeated here.

[0082] Embodiment 3: Those skilled in the art can clearly understand that the systems and methods of the above embodiments can be implemented by means of software plus a necessary general hardware platform, or by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory (ROM) / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a node packaging device, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0083] Therefore, the present invention also provides a non-incremental sorting execution device for smart contracts under the DAG structure based on account chain and guardian chain, including: a memory, a processor, and a non-incremental sorting execution program for smart contracts under the DAG structure based on account chain and guardian chain stored in the memory and runnable on the processor, the non-incremental sorting execution program for smart contracts under the DAG structure based on account chain and guardian chain is configured with a method for implementing the non-incremental sorting execution of smart contracts under the DAG structure based on account chain and guardian chain.

[0084] In addition, the present invention also provides a storage medium, on which is stored a non-incremental sorting execution program of a smart contract under a DAG structure based on an account chain and a guardian chain.

[0085] Because, in reality, when deploying equipment or programs, the operation of a program can be to implement all steps, or it can be to implement only one step, and all steps can be implemented through the cooperation of multiple programs.

[0086] Therefore, the non-incremental sorting execution program of the smart contract under the DAG structure based on the account chain and the guardian chain, when executed, implements all or a certain process of the non-incremental sorting execution method of the smart contract under the DAG structure based on the account chain and the guardian chain.

[0087] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are included in the patent protection scope of the present invention.

Claims

1. A non-incremental sorting execution method for smart contracts based on the DAG structure of account chain and guardian chain, characterized in that: The account chain node initiates the deployment and execution request of the smart contract, and then the guardian chain node completes the actual deployment and execution of the smart contract. The guardian chain includes two types of nodes: consensus nodes and witness nodes. The guardian chain consensus node can complete the sorting of smart contract transactions in the guardian chain and package them to generate guardian blocks. The guardian chain witness node is a full node in the guardian chain, composed of authoritative and trusted nodes. Its functions include block verification, block witnessing, block chaining, block broadcasting, and block storage. When the guardian chain consensus node performs sorting, the following steps are included: S1. Anchor account chain sequence; S2. Record the account chain block height; S3. According to the account chain sequence and block height, trace back and execute the contract transaction blocks to be executed on the account chain in sequence; The guardian chain witness node traces back and executes the contract transaction blocks to be executed on the account chain according to the account chain sequence and block height anchored by the guardian chain consensus node.

2. According to claim 1, the method for executing smart contracts in a DAG structure based on an account chain and a guardian chain is characterized in that: When the guardian chain consensus node needs to include a new contract transaction block, re-execute steps S1-S3.

3. A non-incremental sorting execution system for smart contracts based on the DAG structure of account chain and guardian chain, characterized by: The Guardian Chain includes two types of nodes: consensus nodes and witness nodes. The Guardian Chain consensus node can complete the sorting of smart contract transactions in the Guardian Chain and package them to generate guardian blocks. The Guardian Chain witness node is a full node in the Guardian Chain, composed of authoritative and trusted nodes. Its functions include block verification, block witnessing, block chaining, block broadcasting, and block storage. The system further includes a request module, which is arranged in the account chain node, and the request module initiates a deployment and execution request of the smart contract; The system further includes an account chain sequence module, an account chain block height module and an execution module. The account chain sequence module sorts the account chains, the account chain block height module records the block height of each account chain, and the execution module traces and executes the contract transaction blocks of the account chain according to the account chain sequence and block height; The account chain sequence module and the account chain block height module are set in the guardian chain consensus node; The execution module includes a guardian chain consensus node execution module and a guardian chain witness node execution module.

4. A non-incremental sorting execution device for smart contracts based on the DAG structure of the account chain and the guardian chain, characterized in that: include: A memory, a processor, and a non-incremental sorting execution program for smart contracts under a DAG structure based on an account chain and a guardian chain, which is stored in the memory and can be run on the processor. The non-incremental sorting execution program for smart contracts under a DAG structure based on an account chain and a guardian chain is configured to implement the non-incremental sorting execution method for smart contracts under a DAG structure based on an account chain and a guardian chain as described in claim 1.

5. A storage medium, characterized in that The storage medium stores a non-incremental sorting execution program for smart contracts under the DAG structure based on the account chain and the guardian chain. When the non-incremental sorting execution program for smart contracts under the DAG structure based on the account chain and the guardian chain is executed, the non-incremental sorting execution method for smart contracts under the DAG structure based on the account chain and the guardian chain as claimed in claim 1 is implemented.

Images