Dependency definition method and device for parallel execution of smart contract, storage medium and computer program product

Abstract

The invention discloses a dependency relationship definition method and device for parallel execution of an intelligent contract, a storage medium and a computer program product, relates to the technical field of block chains, is applied to a client, and comprises the following steps: receiving user-defined dependency group definition information input by a user, calling a parallel dependency definition interface provided by a block chain node, and determining a parallel dependency relationship between the block chain node and the user-defined dependency group definition information; and uploading the dependency group definition information to the parallel dependency definition interface, so that the block chain node analyzes and stores the dependency group definition information, and executes the smart contract in parallel. The dependency relationship definition of the parallel execution of the intelligent contract transaction is directly realized by calling an overall implementation mode of a block chain node interface, and a simple and feasible high-universality dependency relationship definition method is provided for the block chain.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a method, device, storage medium, and computer program product for defining dependencies for parallel execution of smart contracts. Background Art

[0002] In the field of blockchain technology, parallel execution of smart contracts is a key technical means of improving system throughput. To achieve consistent results from parallel execution, precise analysis of transaction dependencies is required to determine the execution order. Currently, dependency analysis can be performed by obtaining read / write sets from pre-execution transactions, analyzing the read / write relationships of state variables based on smart contract source code, or determining read / write operation information through transaction configuration within the smart contract. However, whether generating read / write sets pre-execution, performing transaction configuration, or analyzing the read / write relationships of state variables through the compiler, obtaining dependency information for parallel smart contract execution is generally expensive, complex, and lacks universal applicability.

[0003] Therefore, how to provide a simple, easy-to-use, and highly versatile dependency definition method for blockchain has become an urgent problem that needs to be solved in this application.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a dependency definition method, device, storage medium and computer program product for parallel execution of smart contracts, aiming to provide a simple, easy and highly versatile dependency definition method for blockchain.

[0006] To achieve the above objectives, this application proposes a dependency definition method for parallel execution of smart contracts, which is applied to the client. The dependency definition method includes:

[0007] Receive user-entered custom dependency group definition information;

[0008] Call the parallel dependency definition interface provided by the blockchain node, and upload the dependency group definition information to the parallel dependency definition interface, so that the blockchain node can parse and store the dependency group definition information and execute the smart contract in parallel.

[0009] In one embodiment, the dependency grouping definition information includes dependency relationship reset parameters and dependency group parameters, wherein the dependencies in the dependency group parameters include contract name, function action name, and function parameter name, and the dependency relationship reset parameters include at least one of the contract name, function action name, and function parameter name.

[0010] In one embodiment, after the step of calling the parallel dependency definition interface provided by the blockchain node and uploading the dependency group definition information to the parallel dependency definition interface, the step further includes:

[0011] Distributing the dependency group definition information to the next blockchain node;

[0012] Calling the parallel dependency definition interface provided by the next blockchain node, so that the next blockchain node performs node processing on the dependency group definition information and returns the node processing result;

[0013] Set the return message according to the node processing result.

[0014] In addition, to achieve the above objectives, this application also proposes a dependency definition method for parallel execution of smart contracts, which is applied to blockchain nodes. The dependency definition method includes:

[0015] Receiving dependency group definition information uploaded by a client through a parallel dependency definition interface, wherein the dependency group definition information is input by a user, and the parallel dependency definition interface is called by the client;

[0016] Parse and store the dependency grouping definition information for parallel execution of the smart contract.

[0017] In one embodiment, the step of parsing and storing the dependency grouping definition information for parallel execution of the smart contract includes:

[0018] Parsing the dependency group definition information according to the internal execution logic of the parallel dependency definition interface, and determining whether the dependency relationship reset parameter is empty according to the parsed result;

[0019] If the dependency relationship reset parameter is not empty, traverse the dependencies in the dependency relationship reset parameter, and clean up dependency prefix matching records in the reset dependency relationship table according to the traversal result;

[0020] Traverse the dependencies in the dependency group parameter and assign corresponding dependency group numbers to the dependencies;

[0021] If the dependency relationship reset parameter is empty, directly execute the steps of: traversing the dependencies in the dependency group parameter and assigning corresponding dependency group numbers to the dependencies;

[0022] The dependency group number and the dependency are stored in the dependency relationship table in the form of key-value pairs for the combined execution of the smart contract.

[0023] In one embodiment, the step of traversing the dependencies in the dependency relationship reset parameter and clearing dependency prefix matching records in the reset dependency relationship table according to the traversal result includes:

[0024] Traverse the dependency relationship and reset the dependencies in the parameters;

[0025] If the dependency only includes the contract name, all dependencies under the smart contract corresponding to the contract name are cleaned and reset;

[0026] If the dependencies include contract names and function action names, then clean and reset all dependencies under the contract function action corresponding to the function action name;

[0027] If the dependencies include contract names, function action names, and function parameter names, then the dependencies matching the function parameter names are cleaned and reset.

[0028] In one embodiment, the step of traversing the dependency items in the dependency group parameter and assigning corresponding dependency group numbers to the dependency items includes:

[0029] Traversing the dependencies in the dependency group parameter, querying the existing dependency group number of each dependency in the dependency relationship table;

[0030] If the existing dependency group number exists in the dependency item, setting the dependency group number of the dependency item to the minimum value of the existing dependency group numbers;

[0031] If the existing dependency group number does not exist in the dependency item, a new incremented dependency group number is allocated to the dependency item.

[0032] In addition, to achieve the above-mentioned purpose, the present application also proposes a dependency definition device for parallel execution of smart contracts, the device including: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the dependency definition method as described above.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the dependency definition method described above are implemented.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the dependency definition method as described above.

[0035] One or more technical solutions proposed in this application have at least the following technical effects:

[0036] The system receives user-entered custom dependency group definition information, calls the parallel dependency definition interface provided by the blockchain node, and uploads the dependency group definition information to the parallel dependency definition interface for the blockchain node to parse and store, allowing the smart contract to be executed in parallel. By directly calling the parallel dependency definition interface provided by the blockchain node to receive the dependency group definition information, pre-execution or compiler static analysis is avoided, simplifying the operational process and reducing the computing resource consumption of the blockchain node. User-defined dependencies can accurately cover complex scenarios such as cross-contract calls and dynamic parameter associations. The overall implementation model of defining dependency relationships for parallel execution of smart contract transactions directly by calling the blockchain node interface provides a simple, highly versatile dependency definition method for the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0039] Figure 1 A flowchart of the first embodiment of the dependency definition method of this application is provided;

[0040] Figure 2 A flowchart of the third embodiment of the dependency definition method of this application is provided;

[0041] Figure 3 A flowchart of the fourth embodiment of the dependency definition method of this application is provided;

[0042] Figure 4 Schematic diagram of a single smart treaty provided for this application;

[0043] Figure 5 Schematic diagram of the dual smart treaty provided for this application;

[0044] Figure 6 This is a schematic diagram of the module structure of the dependency definition device according to an embodiment of the present application;

[0045] Figure 7 Schematic diagram of the device structure of the hardware operating environment involved in the dependency definition method in the embodiment of the present application.

[0046] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0048] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0049] The main solution of the embodiment of the present application is to call the standardized parallel dependency definition interface provided by the blockchain node and receive customized dependency group definition information uploaded by the user through the client. The dependency group definition information includes dependency relationship reset parameters and dependency group parameters. The dependency relationship reset parameters are used to clean up old dependencies in a specified scope (contract level, function level, parameter level), and the dependency group parameters define multiple groups of dependencies with execution order dependencies. Furthermore, according to the internal execution logic of the parallel dependency definition interface, the dependency group definition information is stored in the form of key-value pairs for parallel execution of the smart contract.

[0050] In this embodiment, for ease of description, the following description is made with the dependency definition device as the execution subject.

[0051] The embodiments of this application take into account that in the field of blockchain technology, the parallel execution of smart contracts is a key technical means to improve system throughput. In order to achieve consistency in the results of parallel execution, the dependencies between transactions need to be accurately analyzed to determine the execution order. Currently, dependency definitions can be obtained by obtaining read-write sets as the basis for dependency analysis through pre-execution transactions, analyzing the read-write relationship of state variables based on the smart contract source code as the basis for dependency analysis, and determining read-write operation information through transaction configuration in the smart contract as the basis for dependency analysis. However, whether it is pre-execution to generate read-write sets, perform transaction configuration, or analyze the read-write relationship of state variables through the compiler, the cost of obtaining the dependency basis for parallel execution of smart contracts is generally high, the operation is relatively complex, and the versatility is low.

[0052] Therefore, the present application provides a solution that receives user-entered custom dependency group definition information; calls the parallel dependency definition interface provided by the blockchain node, and uploads the dependency group definition information to the parallel dependency definition interface for the blockchain node to parse and store the dependency group definition information and execute the smart contract in parallel. By directly calling the parallel dependency definition interface provided by the blockchain node to receive the dependency group definition information, pre-execution or compiler static analysis is avoided, the operation process is simplified, and the computing resource consumption of the blockchain node is reduced. User-defined dependencies can accurately cover complex scenarios such as cross-contract calls and dynamic parameter associations. The dependency relationship definition of the parallel execution of smart contract transactions is directly implemented by calling the blockchain node interface, providing a simple and easy-to-use, highly versatile dependency relationship definition method for the blockchain.

[0053] Based on this, the embodiment of the present application provides a dependency definition method for parallel execution of smart contracts, which is applied to the client, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the dependency definition method for parallel execution of smart contracts in this application.

[0054] In this embodiment, the parallel dependency definition interface provided by the EOS (Enterprise Operation System, commercial distributed) blockchain node is used as an example for illustration. It is understandable that by changing the calling method or interface form, this application can be applied to other system blockchains. The dependency definition method includes steps S10 to S20:

[0055] Step S10, receiving user-defined dependency group definition information input;

[0056] In complex blockchain networks, as the application scale of smart contracts expands, the relationships between contracts, the relationship between state operations within a contract and the input parameters of contract functions, and the control logic, as well as their parallel dependencies, are only best understood by the user themselves and can be analyzed in advance. However, machine analysis of these dependencies has its limitations.

[0057] Therefore, this application pre-sets the parameter format and dependency format, and the user can customize the dependency group definition information through the client by following the corresponding format. The client receives the dependency group definition information and uploads the dependency group definition information to the parallel dependency definition interface according to the client command.

[0058] Step S20: Call the parallel dependency definition interface provided by the blockchain node, and upload the dependency group definition information to the parallel dependency definition interface, so that the blockchain node can parse and store the dependency group definition information and execute the smart contract in parallel.

[0059] The EOS blockchain node provides a standardized parallel dependency definition interface for defining parallel transaction dependencies of smart contracts. After deploying a smart contract, this interface is called through client commands to upload the relevant dependency group definition information of the smart contract.

[0060] Dependency group definition information is structured data uploaded by the client through the parallel dependency definition interface of the blockchain node. Its core function is to dynamically define the dependencies required for the parallel execution of smart contracts. It includes dependency relationship reset parameters and dependency group parameters. The dependency relationship reset parameter can be expressed as the reset parameter, and the dependency group parameter can be expressed as the depend_groups parameter. The reset parameter can be set to clear dependencies at different scopes (contract level, function level, action parameter level) through different parameter settings. The depend_groups parameter uses a two-dimensional array to set multiple dependency groups. Dependencies within a group are dependencies with dependencies, while groups are independent of each other.

[0061] The blockchain node provides an interface method definition for smart contract parallel transaction dependency definitions. Its ultimate goal is to store dependency group definition information in the form of key-value pairs, providing a basis for contract transaction parallel dependency analysis.

[0062] Specifically, according to the internal execution logic of the parallel dependency definition interface, the reset parameter and the depend_groups parameter in the dependency group definition information are extracted, and after verifying the legality of their formats, a temporary transaction is created for subsequent operations to ensure the atomicity of the stored procedure.

[0063] Furthermore, the reset parameter is parsed to clean up dependencies. This cleanup is completed within the transaction and rolled back if it fails, preventing data inconsistencies caused by partial deletions. The depend_groups parameter is parsed to assign dependency group numbers. If there are already stored dependencies in the subarray (not cleaned up by the reset call), their group numbers are forcibly overwritten with the newly assigned numbers to ensure real-time updates of dependencies.

[0064] After parameter parsing is completed, the dependency item is used as the key (Key) and the dependency group number is used as the value (Value). The mapping relationship between each dependency item and the group number is written into the world state table of the EOS blockchain node in the form of a key-value pair. The smart contract parallel execution uses this world state table as the basis for dependency analysis.

[0065] This embodiment provides a method for defining dependencies for parallel execution of smart contracts. The method receives user-entered custom dependency group definition information, calls a parallel dependency definition interface provided by a blockchain node based on client commands, and uploads the dependency group definition information to the parallel dependency definition interface for the blockchain node to parse and store, thereby executing the smart contract in parallel. By directly calling the parallel dependency definition interface provided by the blockchain node to receive the dependency group definition information, pre-execution or compiler static analysis is avoided, the operational process is simplified, and the computational resource consumption of the blockchain node is reduced. User-defined dependencies can accurately cover complex scenarios such as cross-contract calls and dynamic parameter associations. The overall implementation model of defining dependencies for parallel execution of smart contract transactions directly by calling the blockchain node interface provides a simple, easy-to-use, and highly versatile dependency definition method for blockchains.

[0066] Based on the first embodiment of the present application, the second embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those of the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereafter.

[0067] In this embodiment, the dependency grouping definition information includes dependency relationship reset parameters and dependency group parameters, wherein the dependencies in the dependency group parameters include contract name, function action name, and function parameter name, and the dependency relationship reset parameters include at least one of the contract name, function action name, and function parameter name.

[0068] The dependency group depend_groups parameter is in a two-dimensional array format. Each element represents a group of dependencies. Each dependency group has dependencies with dependencies. The depend_groups parameter defines the relationship between dependencies in a two-dimensional data format, as described in the following formula:

[0069] [[D 11 ,…D 1m1 ],

[0070] [D 21 ,…D 2m2 ],

[0071] …

[0072] [D n1 ,…D nmn ]]

[0073] Each group in the depend_groups parameter represents a list of dependencies with a dependency relationship. The definition of each dependency is in the parameter-level format of "contract name::function action name:function parameter name". When different contract transactions are running in parallel, the values ​​of the dependencies in the same group cannot overlap.

[0074] Therefore, the dependency group parameter can only be marked as valid if the depend_groups parameter includes not only the contract name, but also the function action name and the function parameter name. It is understandable that in order to prevent illegal formats from passing validation, the depend_groups parameter also includes the layer separator [::], and each dependency must strictly conform to the layer format.

[0075] In the dependency definition for the reset parameter, the default dependency definition format is: contract name:: function action name:: function parameter name, where the contract name is required. The function action name and parameter name can be omitted. If the function action name is missing, it refers to the entire contract; if the parameter name is missing, it refers to the entire action under the contract.

[0076] The reset parameter of dependency relationship reset is in array format. Each element in the array is a dependency, which is used to reset the relationship of the dependency and clean up and reset the dependency contained in all dependency groups.

[0077] Each dependency in the reset parameter must be defined in at least one of the following formats:

[0078] Contract level: [Contract name::], which means cleaning up the dependencies of the entire contract;

[0079] Function level: [contract name::function action name::], which means cleaning up the dependencies of the specified function;

[0080] Parameter level: [contract name::function action name::function parameter name], which means cleaning up the dependencies of a single parameter.

[0081] To summarize, the reset parameter must at least include the contract name to be marked as valid. This means that to prevent illegal formats from passing validation, the reset parameter must at least include the hierarchical separator [::], and each dependency in the reset parameter must strictly conform to the hierarchical format.

[0082] In this example, user-defined parameters such as reset and depend_groups allow direct definition of dependencies, completely avoiding the overhead of pre-execution or compilation analysis and reducing computing resource consumption. Different definition formats at the contract, function, and parameter levels support dependencies across contracts or across multiple functions within the same contract.

[0083] Based on the first embodiment and / or the second embodiment of the present application, the third embodiment of the present application is proposed. In the third embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be repeated hereafter.

[0084] On this basis, reference Figure 2 ,like Figure 2 As shown, Figure 2 This is a flow chart of the third embodiment of the present application.

[0085] In this embodiment, the step S20 of calling the parallel dependency definition interface provided by the blockchain node according to the client command and uploading the dependency group definition information to the parallel dependency definition interface further includes steps S30 to S50:

[0086] Step S30: Distribute the dependency group definition information to the next blockchain node;

[0087] Encapsulates the dependency group definition information (reset and depend_groups parameters) submitted by the client into a blockchain transaction, and broadcasts the transaction to adjacent nodes in the blockchain network through the P2P (peer-to-peer) network.

[0088] Step S40: calling the parallel dependency definition interface provided by the next blockchain node, so that the next blockchain node performs node processing on the dependency group definition information and returns the node processing result;

[0089] After receiving the transaction, the next node checks the reset and depend_groups parameters for conformance to the hierarchical format. If so, it executes the same processing logic as the initiating node: clearing the dependencies specified by the reset parameter; assigning a group number; and storing the key-value pair in the local world state table. The next blockchain node returns the processing result (success / failure) to the initiating node.

[0090] Step S50: Setting a return message according to the node processing result.

[0091] The initiating node collects the processing results of all adjacent nodes and returns the transaction hash, effective block height and successful node list based on the node processing results, or returns the error cause and failed node list.

[0092] In this embodiment, the dependency group definition information is distributed to the next blockchain node; the parallel dependency definition interface provided by the next blockchain node is called to perform node processing on the dependency group definition information and return the node processing result; a return message is set according to the node processing result to ensure that the parallel execution logic of the smart contract is consistent across the entire network, and that a single node failure does not affect the service of the entire network, so that other nodes can continue to process transactions. When verification of some nodes fails, the initiating node can rebroadcast or perform targeted repairs.

[0093] The embodiment of the present application also provides a method for defining dependency relationships for parallel execution of smart contracts, using blockchain nodes, referring to Figure 3 , Figure 3 A flowchart illustrating a fourth embodiment of a method for defining dependencies for applying for parallel execution of smart contracts.

[0094] In this embodiment, the dependency definition method includes steps A10 to A20:

[0095] Step A10: receiving dependency group definition information uploaded by the client through a parallel dependency definition interface, wherein the dependency group definition information is input by the user and the parallel dependency definition interface is called by the client;

[0096] The EOS blockchain node provides a standardized parallel dependency definition interface for defining parallel transaction dependencies of smart contracts. After deploying a smart contract, this interface is called through client commands to upload the relevant dependency group definition information of the smart contract.

[0097] Dependency group definition information is structured data uploaded by the client through the parallel dependency definition interface of the blockchain node. Its core function is to dynamically define the dependencies required for the parallel execution of smart contracts. It includes dependency relationship reset parameters and dependency group parameters. The dependency relationship reset parameter can be expressed as the reset parameter, and the dependency group parameter can be expressed as the depend_groups parameter. The reset parameter can be set to clear dependencies at different scopes (contract level, function level, action parameter level) through different parameter settings. The depend_groups parameter uses a two-dimensional array to set multiple dependency groups. Dependencies within a group are dependencies with dependencies, while groups are independent of each other.

[0098] Step A20: Parse and store the dependency group definition information for parallel execution of the smart contract.

[0099] The blockchain node provides an interface method definition for smart contract parallel transaction dependency definitions. Its ultimate goal is to store dependency group definition information in the form of key-value pairs, providing a basis for contract transaction parallel dependency analysis.

[0100] Specifically, according to the internal execution logic of the parallel dependency definition interface, the reset parameter and the depend_groups parameter in the dependency group definition information are extracted, and after verifying the legality of their formats, a temporary transaction is created for subsequent operations to ensure the atomicity of the stored procedure.

[0101] Furthermore, the reset parameter is parsed to clean up dependencies. This cleanup is completed within the transaction and rolled back if it fails, preventing data inconsistencies caused by partial deletions. The depend_groups parameter is parsed to assign dependency group numbers. If there are already stored dependencies in the subarray (not cleaned up by the reset call), their group numbers are forcibly overwritten with the newly assigned numbers to ensure real-time updates of dependencies.

[0102] After parameter parsing is completed, the dependency item is used as the key (Key) and the dependency group number is used as the value (Value). The mapping relationship between each dependency item and the group number is written into the world state table of the EOS blockchain node in the form of a key-value pair. The smart contract parallel execution uses this world state table as the basis for dependency analysis.

[0103] This embodiment provides a method for defining dependencies for the parallel execution of smart contracts. The method receives dependency group definition information uploaded by a client through a parallel dependency definition interface. The dependency group definition information is user-defined and input. The parallel dependency definition interface is called by the client according to client commands. The method then parses and stores the dependency group definition information for parallel execution of the smart contract. By directly calling the parallel dependency definition interface provided by the blockchain node to receive the dependency group definition information, pre-execution or compiler static analysis is avoided, the operational process is simplified, and the computing resource consumption of the blockchain node is reduced. User-defined dependencies can accurately cover complex scenarios such as cross-contract calls and dynamic parameter associations. Key-value storage does not require a customized storage engine, is compatible with mainstream blockchain architectures, and is highly versatile. The dependency relationship definition for the parallel execution of smart contract transactions is directly implemented by calling the blockchain node interface, providing a simple, easy-to-use, and highly versatile dependency definition method for the blockchain.

[0104] Based on the fourth embodiment of the present application, the fifth embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those of the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereafter.

[0105] In this embodiment, step A20 of parsing and storing the dependency group definition information for parallel execution of the smart contract may include steps A21 to A25:

[0106] Step A21, parsing the dependency group definition information according to the internal execution logic of the parallel dependency definition interface, and determining whether the dependency relationship reset parameter is empty according to the parsing result;

[0107] The dependency group definition information includes the dependency relationship reset reset parameter and the dependency group depend_groups parameter. The parallel dependency definition interface parses the dependency group definition information, extracts the reset and depend_groups parameters, and determines whether the dependency relationship reset reset parameter is empty. If the reset parameter is empty, the cleanup operation is skipped and the depend_groups parameter is processed directly; if the reset parameter is not empty, the cleanup process is entered.

[0108] Step A22: If the dependency relationship reset parameter is not empty, traverse the dependencies in the dependency relationship reset parameter, and clear the dependency prefix matching records in the reset dependency relationship table according to the traversal result;

[0109] The dependency relationship is reset. If the reset parameter is not empty, the reset parameter is traversed and prefix matching is performed on each dependency according to the traversal result. For example, the contract-level cleanup operation is: [contract name::], deleting all dependencies with the contract name as the prefix.

[0110] Step A23, traversing the dependency items in the dependency group parameter, and assigning corresponding dependency group numbers to the dependency items;

[0111] Furthermore, after completing the reset parameter traversal, the dependency items in the dependency group depend_groups parameter are traversed, and corresponding dependency group numbers are assigned to the dependency items. For example, the group numbers can be incremented starting from 1.

[0112] Step A24: if the dependency relationship reset parameter is empty, directly execute the steps of: traversing the dependencies in the dependency group parameter and assigning corresponding dependency group numbers to the dependencies;

[0113] If the reset parameter is empty, the dependencies in the dependency_group parameter are directly iterated over, assigning them corresponding dependency group numbers. Specifically, the group numbers are incremented starting from the current maximum group number + 1. For example, if the current maximum group number is 2, the new group number is 3. In addition, if the old group number already exists for a dependency, it is forcibly overwritten with the new one.

[0114] Step A25: Store the dependency group number and the dependency in the dependency relationship table in the form of a key-value pair for combined execution of the smart contract.

[0115] The dependency is used as the key and the dependency group number as the value. The mapping relationship between each dependency and group number is written into the world state table of the EOS blockchain node in the form of a key-value pair. The parallel execution of smart contracts uses this world state table as the basis for dependency analysis.

[0116] In this embodiment, the internal execution logic of the parallel dependency definition interface parses dependency group definition information and performs hierarchical processing based on the parsed results. Different processing flows for when the dependency relationship reset parameter is not null and when it is null are used. This allows users to choose whether to clean up old dependencies and delete redundant data at different granularities as needed, avoiding unnecessary resource consumption. Assigning numbers to dependency groups provides the basis for determining the execution order of transactions in each parallel thread, thereby ensuring subsequent dependency analysis.

[0117] Specifically, in a feasible implementation, step A22 may include steps A221 to A224:

[0118] Step A221, traverse the dependency relationship and reset the dependencies in the parameters;

[0119] The blockchain node iterates over each dependency in the reset parameter. The dependency definition format is: contract name:: function action name:: function parameter name, where the contract name is required. The function action name and parameter name can be omitted. If the function action name is missing, it represents the entire contract; if the parameter name is missing, it represents the entire action under the contract.

[0120] Step A222: If the dependency definition format only includes the contract name, all dependencies under the smart contract corresponding to the contract name are cleaned and reset;

[0121] If the dependency definition format only includes the contract name, that is, it is represented as contract name::, all dependencies under the smart contract corresponding to the contract name will be cleaned and reset.

[0122] For example, if the reset parameter is reset:["token::"], it means deleting all dependencies starting with token::, such as token::transfer::from and token::store::from, thereby efficiently deleting the dependencies of the entire contract and avoiding one-by-one operations.

[0123] Step A223: If the dependency includes a contract name and a function action name, clean and reset all dependencies under the contract function action corresponding to the function action name;

[0124] If the dependency definition format includes both the contract name and the function action name, that is, the dependency definition format is: contract name:: function action name::, clean and reset all dependencies under the contract function action corresponding to the function action name.

[0125] For example, if the reset parameter is reset:["token::transfer::"], all related dependencies such as token::transfer::from and token::transfer::to will be deleted, all dependencies under the specified function will be cleaned up, and the dependencies of other functions will be retained. A single operation will cover multiple parameter dependencies, reducing the number of database accesses.

[0126] Step A224: If the dependencies include contract names, function action names, and function parameter names, then clean and reset the dependencies that match the function parameter names.

[0127] If the dependency definition format includes both the contract name, the function action name, and the function parameter name, that is, the dependency definition format is contract name::function action name::function parameter name, then the dependencies that match the function parameter name are cleaned and reset.

[0128] For example, if the reset parameter is reset:["token::transfer::from"], only token::transfer::from is deleted, that is, the dependency definition format is: retain other parameters under the same function, such as token::transfer::to.

[0129] Specifically, in a feasible implementation, step A23 may include steps A231 to A233:

[0130] Step A231, traverse the dependencies in the dependency group parameter, and query the existing dependency group number of each dependency in the dependency relationship table;

[0131] Iterate over the dependencies of the depend_groups parameter, for example:

[0132]

[0133]

[0134] token::transfer::from is the dependency in the dependency group parameter, ["token::transfer::from", "token::transfer::to"] is a dependency group in the dependency group parameter. A key-value query is performed on each dependency to obtain its existing dependency group number (Value) in the dependency table. The purpose of this step is to confirm whether the dependency has been defined to avoid duplicate allocation or conflict.

[0135] Step A232: If the existing dependency group number exists in the dependency item, the dependency group number of the dependency item group is set to the minimum value of the existing dependency group numbers;

[0136] If at least one dependency in a dependency group has an existing group number, the minimum of all existing numbers is used as the unified number for the group. For example, the dependency group ["token::transfer::from(group 1)","token::transfer::to(group 2)"] has a unified number of 1.

[0137] Step A233: If the existing dependency group number does not exist in the dependency item, a new incremented dependency group number is allocated to the dependency item.

[0138] If the dependency group number does not exist in the dependency and the reset parameter is not empty: the group number is incremented starting from 1 (e.g., the first call generates group 1 and group 2);

[0139] If the existing dependency group number does not exist in the dependency and the reset parameter is empty: the group number is incremented from the current maximum group number + 1 (for example, if the current maximum group number is 2, the new group number is 3).

[0140] The following will be combined Figure 4 The single smart contract shown details the cleanup and reset operations and the assignment of dependency group numbers, as well as how they are stored in the form of key-value pairs.

[0141] like Figure 4 For a single smart contract shown in the figure, if all functions in the contract are called independently and there is no mutual calling relationship between them, then the dependency group definition information uploaded to the parallel dependency definition interface is:

[0142]

[0143]

[0144] The parallel dependency definition interface cleans up and resets all dependencies under the smart contract token through the reset parameter according to its internal execution logic, namely token::transfer::from, token::transfer::to, and token::store::from.

[0145] Furthermore, the depend_groups parameter is parsed and all dependencies in the depend_groups parameter are traversed. Among them, ["token::transfer::from", "token::transfer::to"] is numbered 1, and ["token::store::from"] is numbered 2. Therefore, the storage result in the form of key-value pairs is:

[0146] Key (dependency) Value (dependency group number) token::transfer::from 1 token::transfer::to 1 token::store::from 2

[0147] like Figure 4 For a single smart contract shown in the figure, if the store method in the contract is both open to the outside world and may be called independently and is also called within the transfer method, the dependency group definition information uploaded to the parallel dependency definition interface is:

[0148]

[0149] According to the above logic, after receiving the information, the blockchain node stores it internally as follows:

[0150] Key (dependency) Value (dependency group number) token::transfer::from 2 token::transfer::to 2 token::store::from 2

[0151] In addition, if the user separates the record method into another public contract, it will form the following Figure 4 Schematic diagram of two smart contracts shown.

[0152] like Figure 5 As shown, if these two contract methods are uploaded smart contracts that are called independently, the information of the parallel dependency interface is as follows:

[0153]

[0154]

[0155] After receiving the information, the blockchain node stores it internally as follows:

[0156] Key (dependency) Value (dependency group number) token::transfer::from 3 token::transfer::to 3 record::store::from 4

[0157] If the transfer method in the token contract calls the evidence storage method across contracts, the uploaded smart contract parallel dependency interface information is as follows:

[0158]

[0159] After receiving the information, the blockchain node stores it internally as follows:

[0160] Key (dependency) Value (dependency group number) token::transfer::from 3 token::transfer::to 3 record::store::from 3

[0161] It should be noted that the above examples are only to help understand the internal execution logic of the parallel dependency definition interface of this application, and do not mean that the analysis based on the internal execution logic of the parallel dependency definition interface is limited to the above four situations. Instead, it can be flexibly processed according to different dependency group definition information.

[0162] This application also provides a dependency definition device, please refer to Figure 6 , the dependency definition device includes:

[0163] The dependency grouping definition information receiving module 10 is configured to receive user-defined dependency grouping definition information input by the user;

[0164] The interface internal logic execution module 20 is used to call the parallel dependency definition interface provided by the blockchain node and upload the dependency group definition information to the parallel dependency definition interface so that the blockchain node can parse and store the dependency group definition information and execute the smart contract in parallel.

[0165] The dependency definition device provided in this application utilizes the dependency definition method described in the aforementioned embodiments to address the technical issues surrounding dependency definition. Compared to the prior art, the dependency definition device provided in this application offers the same beneficial effects as the dependency definition method described in the aforementioned embodiments. Other technical features of the dependency definition device are the same as those disclosed in the aforementioned embodiments and are not further elaborated upon here.

[0166] The present application provides a dependency definition device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the dependency definition method in the above-mentioned embodiment one.

[0167] Reference below Figure 7, which shows a schematic diagram of the structure of a dependency definition device suitable for implementing the embodiments of the present application. The dependency definition device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The dependency definition device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0168] like Figure 7 As shown, the dependency definition device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the dependency definition device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the dependency definition device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a dependency definition device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems can be implemented or have alternatively.

[0169] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0170] The dependency definition device provided in this application utilizes the dependency definition method described in the aforementioned embodiment to resolve the technical issues surrounding dependency definition. Compared to the prior art, the beneficial effects of the dependency definition device provided in this application are the same as those of the dependency definition method described in the aforementioned embodiment. Other technical features of the dependency definition device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0171] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0172] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0173] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, and the computer-readable program instructions are used to execute the dependency definition method in the above embodiment.

[0174] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0175] The computer-readable storage medium may be included in the dependency definition device, or may exist independently without being assembled into the dependency definition device.

[0176] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the dependency definition device, the dependency definition device: receives custom dependency grouping definition information input by the user; calls the parallel dependency definition interface provided by the blockchain node, and uploads the dependency grouping definition information to the parallel dependency definition interface, so that the blockchain node can parse and store the dependency grouping definition information and execute the smart contract in parallel.

[0177] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0178] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0179] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0180] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the above-described dependency definition method, thereby resolving the technical issues surrounding dependency definition. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the dependency definition method provided in the above-described embodiments, and are not further elaborated here.

[0181] The present application also provides a computer program product, comprising a computer program, which implements the steps of the dependency definition method described above when executed by a processor.

[0182] The computer program product provided in this application can solve the technical problem of dependency definition. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the dependency definition method provided in the above embodiment, and will not be repeated here.

[0183] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for defining dependencies for parallel execution of smart contracts, characterized in that: Applied to the client, the dependency definition method includes: Receive user-entered custom dependency group definition information; Call the parallel dependency definition interface provided by the blockchain node, and upload the dependency group definition information to the parallel dependency definition interface, so that the blockchain node can parse and store the dependency group definition information and execute the smart contract in parallel.

2. The dependency definition method according to claim 1, wherein: The dependency grouping definition information includes dependency relationship reset parameters and dependency group parameters, wherein the dependencies in the dependency group parameters include contract name, function action name, and function parameter name, and the dependency relationship reset parameters include at least one of the contract name, function action name, and function parameter name.

3. The dependency definition method according to claim 1, wherein: After the step of calling the parallel dependency definition interface provided by the blockchain node and uploading the dependency group definition information to the parallel dependency definition interface, the following step further includes: Distributing the dependency group definition information to the next blockchain node; Calling the parallel dependency definition interface provided by the next blockchain node, so that the next blockchain node performs node processing on the dependency group definition information and returns the node processing result; Set the return message according to the node processing result.

4. A method for defining dependencies for parallel execution of smart contracts, characterized in that: Applied to blockchain nodes, the dependency definition method includes: Receiving dependency group definition information uploaded by a client through a parallel dependency definition interface, wherein the dependency group definition information is input by a user, and the parallel dependency definition interface is called by the client; Parse and store the dependency grouping definition information for parallel execution of the smart contract.

5. The dependency definition method according to claim 4, wherein: The step of parsing and storing the dependency group definition information for parallel execution of the smart contract includes: Parsing the dependency group definition information according to the internal execution logic of the parallel dependency definition interface, and determining whether the dependency relationship reset parameter is empty according to the parsed result; If the dependency relationship reset parameter is not empty, traverse the dependencies in the dependency relationship reset parameter, and clean up dependency prefix matching records in the reset dependency relationship table according to the traversal result; Traverse the dependencies in the dependency group parameter and assign corresponding dependency group numbers to the dependencies; If the dependency relationship reset parameter is empty, directly execute the steps of: traversing the dependencies in the dependency group parameter and assigning corresponding dependency group numbers to the dependencies; The dependency group number and the dependency are stored in the dependency relationship table in the form of key-value pairs for the combined execution of the smart contract.

6. The dependency definition method according to claim 5, wherein: The steps of traversing the dependencies in the dependency relationship reset parameter and clearing dependency prefix matching records in the reset dependency relationship table according to the traversal result include: Traverse the dependency relationship and reset the dependencies in the parameters; If the dependency only includes the contract name, clean up and reset the dependencies under the smart contract corresponding to the contract name; If the dependencies include a contract name and a function action name, clean and reset the dependencies under the contract function action corresponding to the function action name; If the dependencies include contract names, function action names, and function parameter names, then the dependencies matching the function parameter names are cleaned and reset.

7. The dependency definition method according to claim 5, wherein: The step of traversing the dependency items in the dependency group parameter and assigning corresponding dependency group numbers to the dependency items comprises: Traversing the dependencies in the dependency group parameter, querying the existing dependency group number of each dependency in the dependency relationship table; If the dependency item has the existing dependency group number, setting the dependency group number of the dependency item to the minimum value of the existing dependency group numbers; If the dependency item does not have the existing dependency group number, a new incremented dependency group number is allocated to the dependency item.

8. A dependency definition device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the dependency definition method according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the dependency definition method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the dependency definition method according to any one of claims 1 to 7 are implemented.

Images