Smart contract 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 method for executing smart contract incremental sorting under a DAG structure based on an account chain and a guardian chain, characterized in that a smart contract record is set, the smart contract record records the sorting result of the contract transaction block, and the consensus node and the witness node execute the contract transaction block according to the sorting result. The present invention also provides an incremental sorting execution system, device and storage medium. The present invention can well solve the problem of determining the final state of a contract under a multi-chain parallel structure, and can include newly added transactions to avoid wasting computing resources and packaging time.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a method, system, device, and storage medium for the ordered execution of smart contracts based on a DAG structure of account chain and guardian chain. Background Technology

[0002] A blockchain is a single chain composed of blocks, which can only be written synchronously and sequentially according to the block production time, much like a single-core, single-threaded CPU.

[0003] The throughput of a blockchain is limited by the block size. If the blocks are too small, many transactions cannot be included in the block if the transaction volume is large. If the blocks are too large, the data volume of the entire blockchain system will expand rapidly, making it impossible for ordinary users to run full nodes, which will cause centralization problems.

[0004] Later, some blockchain projects based on DAG topology emerged. These projects attempted to use the characteristics of DAG to improve the shortcomings of traditional chain-structured distributed ledger technology, introducing a blockless concept. Transactions directly confirm and maintain relationships, eliminating the packaging process and bringing a new approach to distributed ledger implementation.

[0005] DAG stands for Directed Acyclic Graph. In a DAG, all nodes point in the same direction, making it acyclic. No element can reference itself. It is a data structure that allows only unidirectional information flow.

[0006] In addition, another patent of the applicant, "System and Method of DAG Blockchain Structure Based on Account Chain and Guardian Chain", describes a system based on DAG blockchain structure based on account chain and guardian chain. The system based on DAG blockchain structure includes: sender account chain, receiver account chain and guardian chain.

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

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

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

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

[0011] The guardian chain is used to obtain the first current status information of the transaction sending block and the second current status information of the transaction receiving block, package the first current status information and the second current status information, and store the packaged first current status information and the second current status information to protect 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 to publish contract transactions through the contract deployment block;

[0013] The guardian chain is also used to deploy contracts based on the contract deployment block;

[0014] The receiving account chain is also 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 to 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 multi-account chains and single-guardian chains, the generation and invocation of smart contracts are all initiated by account nodes on the account chain. The account chain is a multi-chain parallel transaction structure. Different account chains simultaneously invoking a contract is called a multi-chain parallel contract invocation scenario. In this scenario, multiple chains may simultaneously read or modify data within the contract or the blockchain state, leading to an inability to confirm the final state. Ensuring the reasonable implementation of multi-chain parallel contract invocation scenarios is a problem that urgently needs to be solved.

[0017] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

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

[0019] To achieve the above objectives, the technical solution of the present invention is as follows:

[0020] The incremental sorting and execution method for smart contracts based on the DAG structure of account chain and guardian chain is characterized by setting up a smart contract record, which records the sorting results of contract transaction blocks, and the consensus node and witness node execute the contract transaction blocks according to the sorting results.

[0021] Furthermore, when a consensus node needs to include a new contract transaction block, the sorting result of the new contract transaction block is recorded sequentially after the original sorting result.

[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 smart contract incremental sorting and execution system based on a DAG structure of an account chain and a guardian chain. The system is characterized by including a smart contract recording module and an execution module. The smart contract recording module records the sorting results of contract transaction blocks, and the execution module executes the contract transaction blocks of the account chain according to the sorting results.

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

[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 smart contract incremental sorting execution device based on a DAG structure of account chain and guardian chain, characterized in that it includes: a memory, a processor, and a smart contract incremental sorting execution program based on a DAG structure of account chain and guardian chain stored on the memory and executable on the processor, wherein the smart contract incremental sorting execution program based on a DAG structure of account chain and guardian chain is configured to implement all or some of the processes of the smart contract incremental sorting execution method based on a DAG structure of account chain and guardian chain.

[0027] The present invention also provides a storage medium, characterized in that the storage medium stores a smart contract incremental sorting execution program based on a DAG structure of account chain and guardian chain, wherein when the smart contract incremental sorting execution program based on the DAG structure of account chain and guardian chain is executed, it implements all or some of the processes in the smart contract incremental sorting execution method based on the DAG structure of account chain and guardian chain.

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

[0029] 1. In this invention, ordinary transactions can be completed without the execution of the guardian chain. Only smart contract transactions require the witnessing and 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 in this invention is determined by the witness consensus, and the efficiency can still be very high.

[0031] 3. This invention effectively solves the problem of determining the final state of a contract under a multi-chain parallel structure, and can include new transactions, avoiding wasting computing resources and packaging time. Attached Figure Description

[0032] Figure 1 This is a diagram illustrating the deployment and execution process of the smart contract in this invention.

[0033] Figure 2 The process diagram of the non-incremental sorting execution method for transactions in this invention.

[0034] Figure 3 This is a flowchart illustrating the transaction incremental sorting execution method of the present invention. Detailed Implementation

[0035] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0036] Example 1: This invention presents a smart contract ordering and execution method based on a DAG structure of account chains and guardian chains. The account chain is formed by each account keeping its own ledger, with each transaction as a single block, arranged sequentially in a chain structure. Each account forms one account chain. The account chain blocks mainly include ordinary transaction blocks and contract transaction blocks. The ordinary transaction blocks include sending transaction blocks (such as...). Figure 1 Block S in Figure 2 , Figure 3 Blocks AS2, BS1, DS1, and DS3 in the middle) and receiving transaction blocks (such as Figure 1 Block R in Figure 2 , Figure 3 In the blocks AR, BR, CR, DR), contract transaction blocks include contract deployment blocks (such as... Figure 2 , Figure 3 Block CC1) and contract execution blocks (such as Figure 1 , Figure 2 , Figure 3 Blocks E4, E6, AE1, AE3, BE2, CE2, CE3, and DE2 in the blockchain. The first block on each account chain is the transaction receiving block, which completes the creation of the account chain by receiving the first transaction sent to that account by other accounts.

[0037] The main information in the ordinary transaction block or contract transaction block on the account chain includes header and body. The header mainly includes information such as transaction type, recipient, sender, parent block hash, and transaction amount; the body mainly includes information such as balance, guardian chain deposits received by the account link, and account chain record point.

[0038] The reference relationship between account chains due to sending and receiving transactions is called a block bond. Account chains are linked together by block bonds to form a DAG structure, similar to a lattice model, also known as an account lattice.

[0039] The account chain mainly consists of several types of nodes, including ordinary nodes and witness nodes. Ordinary nodes are the nodes that implement transactions in the account chain, and are mainly responsible for generating 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 uploading, block broadcasting, and block storage. The operation of witness nodes is supervised by other nodes, and if violations occur, they will be punished with penalties such as loss of witnessing privileges and deduction of deposit.

[0040] Consensus nodes in the guardian chain generate guardian blocks by packaging account chain transaction blocks (e.g., Figure 1 , Figure 2 and Figure 3 Blocks D3, D7, and D in the genesis block constitute the guardian chain. The guardian chain is initiated by the genesis block G. The guardian blocks mainly contain information such as header and body. The header mainly contains information such as 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 transaction blocks.

[0041] When a guardian block is generated on the guardian chain, it includes the latest transaction block from the account chain for the current epoch, establishing a reference relationship with the block on the account chain. When an account block is generated on the account chain, it points to the latest guardian block on that account chain through this reference relationship to obtain the current state and complete the witnessing of that block. The reference relationship between the guardian block and the transaction blocks on the account chain is called a cross-link bond. The guardian chain primarily witnesses the current account lattice state, while the account chain records guardian blocks, forming a final stable lattice structure through cross-link bonds.

[0042] The Guardian Chain primarily consists of two types of nodes: consensus nodes and witness nodes. Consensus nodes are responsible for sorting smart contract transactions within the Guardian Chain and packaging them into Guardian blocks. Witness nodes are full nodes in the Guardian Chain, composed of authoritative and trusted nodes. They perform functions such as block verification, block witnessing, block uploading, block broadcasting, and block storage. The operations of witness nodes are monitored by other nodes, and any violations will result in penalties such as loss of witnessing privileges and deduction of deposit.

[0043] like Figure 1 As shown, smart contract generation and deployment are the tasks of ordinary nodes and witness nodes in each account chain. Ordinary nodes in the account chain determine the contract text and generate a contract deployment block, which is then broadcast to the witness nodes in the account chain for witnessing. At this point, the state (C1) of the contract deployment block is in the sent stage. Upon receiving the broadcast, the account chain witness nodes witness the contract. When a certain number of account chain witness nodes reach consensus on witnessing the contract deployment block, the contract deployment block is successfully uploaded to the account chain that generated the transaction block. At this point, the state (C2) of the contract deployment block is in the pending deployment stage, completing the smart contract generation and deployment process.

[0044] Contract deployment is the task of the consensus nodes and witness nodes in the guardian chain. The consensus nodes sort and package the received contract deployment blocks to generate a guardian block (D3). Then, the witness nodes execute the smart contract according to the consensus nodes' sorting order, thus witnessing the process. After witnessing is complete, the contract deployment block is uploaded to the guardian chain along with the guardian block. At this point, the contract deployment block is in the deployed state, completing the contract deployment process.

[0045] When an account on the account chain needs to invoke a smart contract transaction deployed on the guardian chain, a regular node on the account chain generates a contract execution block and broadcasts it to the witness nodes in the account chain for witnessing. At this time, the state (E5) of the contract execution block is in the sent stage. Once a certain number of witness nodes have completed the witnessing consensus for the contract execution block, the contract execution block is successfully uploaded to the account chain that generated the transaction block. At this point, the state (E6) of the contract execution block is in the pending execution stage. Then, after being sorted and packaged by the guardian chain consensus nodes, a guardian block (D7) is generated. After the guardian chain witness nodes perform the witnessing, the state of the contract execution block changes from pending execution to executed, completing the process of the account chain account invoking the smart contract.

[0046] The generation and invocation of smart contracts are initiated by ordinary nodes on the account chain. During the generation and invocation of a smart contract, data within the smart contract and the blockchain state are read or modified. Because the account chain is a multi-chain parallel transaction structure, when different accounts simultaneously invoke a smart contract, situations may arise where the same smart contract data or blockchain state is read or modified concurrently, making it impossible to confirm the final state. This process is called a multi-chain parallel contract invocation scenario.

[0047] To address the uncertainty of the final state caused by concurrent contract calls across multiple chains, this invention addresses situations where smart contracts experience simultaneous access, identical data read / write, or contract transfers. Instead, the account chain node generates a corresponding contract transaction block, initiates a smart contract deployment and execution request, and then delegates the task to the guardian chain node to complete the actual deployment and execution. During this process, the smart contracts are ordered according to a predetermined procedure, ensuring a fixed order where all nodes follow the same sequence.

[0048] This invention provides two sorting methods as follows:

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

[0050] In this method, when packaging a guardian block, the consensus node gathers the latest transaction blocks from the account chains that need to be packaged in the transaction pool, anchors the account chain order, and records the current block height of each account chain. Then, based on the anchored account chain order and the block height of each account chain, the consensus node sequentially traces back to the contract transaction blocks to be executed on each account chain, and selects these contract transaction blocks for execution. Once the guardian block is packaged, the consensus node broadcasts the process. Upon receiving the broadcast, the witness nodes on the guardian chain, based on the anchored account chain order and the recorded block height of the guardian block, sequentially trace back to the contract transaction blocks to be executed on each account chain, and execute them, completing the witness verification.

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

[0052] It should be noted that the non-incremental sorting execution method mentioned here, and the scenario setting applicable to the case where no new transactions are included after the guardian block has been packaged, does not mean that incremental sorting is not allowed, nor does it mean that new contract transactions cannot be included after the block has been packaged. It simply means that when using the non-incremental sorting execution method, if incremental sorting is required to continue including new contract transactions, and if the new contract transactions cannot be sorted to the end, the consensus node needs to re-execute all contract transaction blocks from the beginning, which affects efficiency.

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

[0054] For example, to ensure that a block can be produced within the specified time, the guardian chain consensus node always prepares a guardian block to package the account chain transaction block. Before the block production time, as long as there is a new transaction block on the account chain, the guardian chain consensus node can package it into the guardian block and update the block.

[0055] If the first non-incremental ordering method is used, the consensus node only records the order of the account chain and the block height. When tracing the contract transaction blocks of the account chain, these newly added contract transaction blocks are very likely not to be directly ordered at the end. In order to ensure the consistency of the execution order between 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 the packaging time, which seriously affects the running efficiency.

[0056] In this scenario, the present invention provides a second method for incremental transaction sorting execution as follows: Smart contract records (Instructions) are added to the guardian block. Consensus nodes record the sorting results of the contract transaction blocks in the smart contract records (Instructions). If new transactions need to be packaged into the guardian block, the consensus node can then record the sorting results of the new contract transaction blocks sequentially after the original sorting results in the smart contract records (Instructions).

[0057] Once the consensus node has packaged the guardian block, the smart contract instructions are fixed within it. Subsequent witness nodes can retrieve the smart contract instructions from the guardian block and execute the contract transaction blocks sequentially according to the instructions, thus completing the witness verification.

[0058] Because the smart contract instructions record the order of all contract transaction blocks, the consensus nodes and witness nodes execute in the order recorded in the smart contract instructions, ensuring consistency in execution order. Thus, when a new contract transaction block is added, the consensus nodes do not need to re-execute from the first contract transaction block.

[0059] The following is combined Figure 2 and Figure 3 The two sorting methods described above will be explained in detail.

[0060] like Figure 2 As shown, this is the non-incremental sorting execution method. After the first-generation (Epoch 1) guardian block is uploaded to the chain, the packaging process for the second-generation (Epoch 2) guardian block begins. The consensus nodes of the guardian chain gather the latest transactions of the account chains, obtain the current block height of each account chain, and record it in the current guardian block. Before the new contract execution block AE3 is uploaded to the account chains, the account chain order anchored by the consensus nodes and the recorded account chain block heights are: Account chain A AS2, Account chain B BE2, Account chain C CE3, and Account chain D DS3.

[0061] Then, the consensus node will, based on the anchored account chain order and account chain block height, sequentially trace and execute the contract transaction blocks to be executed on each account chain. At this point, the consensus node first traces account chain A and executes contract execution block AE1. Since contract execution block AE3 of account chain A is not yet on the chain, account chain A at height AS2 only has one block to be executed, AE1. After tracing and executing account chain A, the consensus node continues to trace account chain B and executes contract execution block BE2. After tracing and executing account chain B, it continues to trace account chain C and executes contract execution blocks CE2 and CE3 in sequence. Then, it traces account chain D and executes contract execution block DE2.

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

[0063] Once the guardian block is packaged, the consensus node broadcasts it. Upon receiving the broadcast, the witness nodes on the guardian chain, based on the account chain order anchored to the guardian block and the recorded block height, sequentially trace and execute the contract transaction blocks to be executed on each account chain, thus completing the witness verification. Because the account chain order traced by the consensus node and the witness nodes, as well as the block height of each account chain, are consistent, the order in which the consensus node and the witness nodes execute the contract transaction blocks is completely identical.

[0064] Before the consensus node broadcasts, if a new contract execution block AE3 is added to the chain, and the consensus node wants to include this block in the guardian blocks of this generation (Epoch 2), the final execution order will be: AE1-BE2-CE2-CE3-DE2-AE3. However, the witness nodes will execute the blocks retroactively according to the account chain order anchored to the guardian blocks and the recorded account chain block heights, resulting in a final execution order of: AE1-AE3-BE2-CE2-CE3-DE2. This will cause a discrepancy between the execution order of the consensus node and the witness nodes. To maintain a consistent execution order across all nodes, the consensus node needs to re-anchor the account chain order and re-record the block heights of each account chain, and then re-execute the contract transaction blocks from the beginning. That is, the re-anchored account chain order and block heights are: Account A chain AE3, Account B chain BE2, Account C chain CE3, and Account D chain DS3. The final execution order of the consensus nodes is: AE1-AE3-BE2-CE2-CE3-DE2. This ensures that the execution order of subsequent witness nodes remains consistent with that of the consensus nodes.

[0065] like Figure 3 The diagram illustrates the incremental transaction sorting execution method. After the first-generation (Epoch 1) guardian block is uploaded to the chain, the second-generation (Epoch 2) guardian block packaging process begins. During the second-generation guardian block packaging period, if new account chain transaction blocks are uploaded to the chain, their transaction hashes are stored in the consensus node's transaction pool. The guardian chain's consensus node consolidates the latest transactions from the account chain and records the transaction hashes of the contract transaction blocks in the guardian block's smart contract record (Instructions). Then, the consensus node sorts these transaction hashes (i.e., sorts the contract transaction blocks) and, based on the sorting result, quickly traces and locates the contract transaction blocks sequentially using their transaction hashes, and executes them.

[0066] Before the new contract execution block AE3 is uploaded to the account chain, the consensus node consolidates the transactions on the account chain. It records the transaction hashes of contract transaction blocks AE1, BE2, CE2, CE3, and DE2 from the transaction pool into the smart contract record (Instructions), and then sorts them. The resulting sorted order is: AE1-BE2-CE2-CE3-DE2. Alternatively, it can be done as follows: Figure 3As shown, the transaction hashes of the corresponding contract transaction blocks are added to the smart contract record (Instructions) sequentially according to their arrival time, resulting in a sorted result: AE1-DE2-CE2-CE3-BE2. Alternatively, transaction hashes can be added in other ways, and then sorted according to rules or not, as long as a sequential result is formed. This sequential result is also called the "sorted result." Therefore, the "sorted result" does not necessarily have to undergo a rule-based sorting process.

[0067] Then, based on the sorting result, the consensus nodes will trace back to the corresponding contract transaction blocks through the transaction hash and execute them.

[0068] Once the guardian block is packaged, the consensus node broadcasts it. Upon receiving the broadcast, the witness nodes on the guardian chain, based on the order recorded in the guardian block's smart contract instructions, trace back to the contract transaction blocks on the account chain using transaction hashes and execute them, completing the witness verification. Because both the consensus node and the guardian node execute according to the order recorded in the smart contract instructions, it effectively ensures that all nodes execute in a unified order.

[0069] Before the consensus node broadcasts, if a new contract execution block AE3 is added to the chain, and the consensus node wants to include this block in the guardian blocks of this generation (Epoch 2), the consensus node can record the transaction hash of this contract execution block in the smart contract record (Instructions). Since the consensus node does not want to re-execute the previous contract transaction blocks, it will sort the latest contract transaction block after the original order in the smart contract record (Instructions), i.e., as shown below. Figure 3 As shown, the sorting result in the smart contract records (Instructions) is: AE1-DE2-CE2-CE3-BE2-AE3. Then the consensus node will execute the newly added contract transaction blocks.

[0070] It should be noted that the above only describes the case of a single new block being added to the blockchain. If there are multiple account chains, multiple new blocks being added to the blockchain, and the consensus nodes want to include all of these new blocks in the guardian blocks, the consensus nodes will still record the transaction hashes of these new contract transaction blocks in the smart contract record (Instructions), and place these new contract transaction blocks at the end of the original sorting result. Then, the consensus nodes will execute the newly added contract transaction blocks according to the sorting result.

[0071] Subsequent witness nodes execute in the order recorded in the modified smart contract, ensuring that the execution order of all nodes is consistent.

[0072] It's important to note that consensus nodes can execute contract transaction blocks either before or after the sorting results are formed. For example, a consensus node can execute the contract transaction blocks first, then add the transaction hashes of the blocks to the smart contract record (Instructions) according to the execution order, thus forming the sorting result; alternatively, it can execute the blocks while simultaneously adding the transaction hashes to the smart contract record (Instructions), also forming the sorting result. Neither approach affects overall operational consistency. In other words, as long as both consensus nodes and witness nodes execute the contract transaction blocks according to the sorting results in the smart contract record, overall operational consistency can be guaranteed.

[0073] It should be noted that in the above description, the smart contract instructions record the order of transaction hashes and are used for tracing and locating transactions. In fact, transaction hashes are not the only basis for recording; any content that can identify a transaction block can be used as an effective means to record in the smart contract instructions. Then, this content is sorted, and based on the sorting result, the contract transaction block can be traced and executed.

[0074] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of the invention according to actual needs, and no restrictions are imposed here.

[0075] Example 2: In addition, this embodiment of the invention also proposes a smart contract incremental sorting execution system based on an account chain and a guardian chain DAG structure, including a smart contract recording module, which records the sorting results of contract transaction blocks.

[0076] The smart contract incremental sorting and execution system also includes an execution module, which executes the contract transaction blocks of the account chain according to the sorting results. The execution module includes a consensus node execution module and a witness node execution module.

[0077] The smart contract incremental sorting execution system also includes a request module, which is set in the account chain node. The request module initiates deployment and execution requests for smart contracts.

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

[0079] It should be noted that the inclusion relationship of the modules above indicates that the upper-level module includes the lower-level module, but does not mean that it is composed only of the lower-level module. In fact, the upper-level module can include many other lower-level modules, which can be added by those skilled in the art as needed.

[0080] Furthermore, this embodiment is merely a basic description of the smart contract incremental sorting execution system of the present invention. For technical details not described in detail in this embodiment, please refer to the methods provided in any embodiment of the present invention, which will not be repeated here.

[0081] Example 3: Those skilled in the art will clearly understand that the systems and methods of the above embodiments can be implemented using software plus necessary general-purpose hardware platforms. Of course, they can also be implemented using 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. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, node packaging device, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0082] Therefore, the present invention also provides a smart contract incremental sorting execution device based on an account chain and a guardian chain DAG structure, comprising: a memory, a processor, and a smart contract incremental sorting execution program based on an account chain and a guardian chain DAG structure stored on the memory and executable on the processor, wherein the smart contract incremental sorting execution program based on an account chain and a guardian chain DAG structure is configured to implement a smart contract incremental sorting execution method based on an account chain and a guardian chain DAG structure.

[0083] In addition, the present invention also provides a storage medium storing a smart contract incremental sorting execution program based on a DAG structure of account chain and guardian chain.

[0084] In reality, when deploying equipment or programs, a program may execute all steps, or it may execute only one step, with multiple programs working together to achieve the full process.

[0085] Therefore, the smart contract incremental sorting execution program based on the DAG structure of the account chain and the guardian chain, when executed, implements all or some of the processes in the smart contract incremental sorting execution method based on the DAG structure of the account chain and the guardian chain.

[0086] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. The smart contract incremental sorting execution method based on the DAG structure of the account chain and the guardian chain is characterized by: The account chain is a chain structure formed by each account being recorded separately, with a single transaction as a single block, and each account forms an account chain; the account chain includes ordinary nodes and witness nodes; the guardian chain includes consensus nodes and witness nodes; the consensus nodes in the guardian chain generate guardian blocks by packaging account chain blocks to form a guardian chain; 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 specific steps are as follows: The ordinary node of the account chain generates a contract deployment block. After the witness node of the account chain completes the witness consensus of the contract deployment block, the guardian chain consensus node sorts and packages the contract deployment block to generate a guardian block. Then the guardian chain witness node executes the smart contract once according to the sorting of the guardian chain consensus node for witnessing. The ordinary node of the account chain generates a contract execution block. After the witness node of the account chain completes the witness consensus of the contract execution block, it is sorted and packaged by the guardian chain consensus node to generate a guardian block, and then the guardian chain witness node performs execution witnessing; Set up smart contract records, which record the sorting results of contract transaction blocks. Guardian chain consensus nodes and guardian chain witness nodes execute contract transaction blocks in the order of the sorting results; When the guardian chain consensus node needs to include a newly added contract transaction block, the sorting results of the newly added contract transaction block will be recorded in sequence behind the original sorting results; the contract transaction block includes a contract deployment block and a contract execution block.

2. The smart contract incremental sorting execution system based on the DAG structure of the account chain and the guardian chain is characterized by: The account chain is a chain structure formed by each account being recorded separately, with a single transaction as a single block, and each account forms an account chain; the account chain includes ordinary nodes and witness nodes; the guardian chain includes consensus nodes and witness nodes; the consensus nodes in the guardian chain generate guardian blocks by packaging account chain blocks to form a guardian chain; 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 a smart contract; the system further includes a smart contract recording module and an execution module, and the smart contract recording module records the sorting result of the contract transaction block, and the execution module executes the contract transaction block of the account chain according to the sorting result; the execution module includes a consensus node execution module and a witness node execution module; 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 specific steps are as follows: The ordinary node of the account chain generates a contract deployment block. After the witness node of the account chain completes the witness consensus of the contract deployment block, the guardian chain consensus node sorts and packages the contract deployment block to generate a guardian block. Then the guardian chain witness node executes the smart contract once according to the sorting of the guardian chain consensus node for witnessing. The ordinary node of the account chain generates a contract execution block. After the witness node of the account chain completes the witness consensus of the contract execution block, it is sorted and packaged by the guardian chain consensus node to generate a guardian block, and then the guardian chain witness node performs execution witnessing; When the guardian chain consensus node needs to include a newly added contract transaction block, the sorting results of the newly added contract transaction block will be recorded in sequence behind the original sorting results; the contract transaction block includes a contract deployment block and a contract execution block.

3. Smart contract incremental sorting execution device based on the DAG structure of account chain and guardian chain, characterized by: include: A memory, a processor, and a smart contract incremental sorting execution program based on the DAG structure of an account chain and a guardian chain stored in the memory and executable on the processor. The smart contract incremental sorting execution program based on the DAG structure of an account chain and a guardian chain is configured to implement the smart contract incremental sorting execution method based on the DAG structure of an account chain and a guardian chain as described in claim 1.

4. A storage medium, characterized in that The storage medium stores an incremental sorting execution program for smart contracts under the DAG structure based on the account chain and the guardian chain. When the incremental sorting execution program for smart contracts under the DAG structure based on the account chain and the guardian chain is executed, the 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