Block chain smart contract deployment method, calling method, related device and medium

Abstract

The invention provides a block chain smart contract deployment method, a calling method, a related device, electronic equipment and a medium. The block chain smart contract deployment method comprises the steps of obtaining a contract abstract of a target smart contract; in the target smart contract, identifying at least one general function segment main body; determining an index corresponding to the general function segment main body by utilizing the general function segment library; replacing the general function segment main body in the target smart contract with the index to obtain a simplified smart contract; and sending the simplified smart contract and the contract abstract to other consensus nodes for consensus, so that the simplified smart contract is stored on the target block chain, the contract abstract is used to update the bottom layer node of the target tree, and the security of the target smart contract is verified by using the target tree. According to the embodiment of the invention, the storage resources occupied by the intelligent contract of the block chain can be reduced on the premise of keeping the uplink security of the intelligent contract. The embodiment of the invention can be applied to various scenes such as block chain electronic invoice processing.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain, and in particular to a method for deploying and invoking blockchain smart contracts, as well as related devices and media. Background Technology

[0002] A blockchain smart contract is a computer program that automatically controls the execution of blockchain transactions under certain conditions. In other words, certain blockchain transactions are executed according to the blockchain smart contract. A blockchain smart contract is a program that executes entirely according to the settings of its creator, and is executed by the code carried within the blockchain smart contract.

[0003] Both blockchain transactions and blockchain smart contract code are currently stored on the blockchain, consuming a large amount of storage space. Summary of the Invention

[0004] This disclosure provides a method for deploying and invoking blockchain smart contracts, related devices, electronic devices, and media, which can reduce the storage resources occupied by storing blockchain smart contracts while maintaining the security of smart contracts on the blockchain.

[0005] According to one aspect of this disclosure, a method for deploying a blockchain smart contract is provided, comprising:

[0006] Obtain the contract summary of the target smart contract;

[0007] In the target smart contract, at least one general function segment body is identified;

[0008] Using the general function segment library, determine the index corresponding to the main body of the general function segment;

[0009] The simplified smart contract is obtained by replacing the general function segment body in the target smart contract with the index.

[0010] The simplified smart contract and the contract digest are sent to other consensus nodes for consensus, so that the simplified smart contract can be stored on the target blockchain. The bottom nodes of the target tree are updated with the contract digest, and the security of the target smart contract is verified using the target tree. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level nodes until the root node is obtained.

[0011] According to one aspect of this disclosure, a blockchain smart contract deployment apparatus is provided, comprising:

[0012] The first acquisition unit is used to acquire the contract summary of the target smart contract;

[0013] The identification unit is used to identify at least one general function segment body in the target smart contract;

[0014] The determining unit is used to determine the index corresponding to the general function segment body using the general function segment library;

[0015] A replacement unit is used to replace the general function segment body in the target smart contract with the index to obtain a simplified smart contract;

[0016] The first processing unit is used to send the simplified smart contract and the contract digest to other consensus nodes for consensus, so as to store the simplified smart contract on the target blockchain, update the bottom nodes of the target tree with the contract digest, and use the target tree to verify the security of the target smart contract. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level nodes until the root node is obtained.

[0017] Optionally, the identification unit is specifically used for:

[0018] In the target smart contract, candidate code segment bodies are identified, and the first semantics of the candidate code segment bodies are obtained;

[0019] Obtain the second semantics of the general function segment body in the general function segment library;

[0020] If the first semantic is the same as the second semantic of a general function segment body in the general function segment library, the candidate code segment body is determined as the identified general function segment body.

[0021] Optionally, the identification unit is specifically used for:

[0022] Extract the first keyword from the main body of the candidate code segment;

[0023] Extract the second keyword of each general function segment body from the general function segment body in the general function segment library;

[0024] The general function segment body that matches the second keyword with the first keyword is identified as the matching general function segment body;

[0025] Obtain the second semantics of the matching general function segment body in the general function segment library.

[0026] Optionally, the blockchain smart contract deployment device further includes:

[0027] The second acquisition unit is used to acquire the size of the general function segment body;

[0028] The third acquisition unit is used to acquire the usage frequency of the main body of the general function segment;

[0029] A filtering unit is used to filter the general function segment body based on the size and the frequency of use.

[0030] Optionally, the third acquisition unit is specifically used for:

[0031] Obtain the first occurrence count of the general function segment body in the target smart contract;

[0032] Obtain the second occurrence count of the general function segment body in the first smart contract deployment history of the target consensus node, where the target consensus node is the consensus node that deploys the target smart contract;

[0033] Obtain the third occurrence count of the general function segment body in the second smart contract deployment history of the consensus node network;

[0034] The frequency of use is determined based on the first occurrence count, the second occurrence count, and the third occurrence count.

[0035] Optionally, the third acquisition unit is specifically used for:

[0036] Obtain the first number of code segments in the target smart contract;

[0037] Based on the first occurrence count and the first number, the first usage sub-frequency is determined;

[0038] Obtain the second number of code segment bodies in the deployment history of the first smart contract;

[0039] Based on the second occurrence frequency and the second number, the second usage sub-frequency is determined;

[0040] Obtain the third number of code segments in the deployment history of the second smart contract;

[0041] Based on the third occurrence frequency and the third number, the third usage sub-frequency is determined;

[0042] The usage frequency is determined based on the first usage sub-frequency, the second usage sub-frequency, and the third usage sub-frequency.

[0043] Optionally, the identification unit is specifically used for:

[0044] In the target smart contract, identify at least one general function segment;

[0045] Extract the main body of the general function segment from the general function segment.

[0046] Optionally, the general function segment includes the general function segment body and general function segment variables;

[0047] The identification unit is specifically used for:

[0048] The general function segment is divided into the general function segment body and the general function segment variables;

[0049] The replacement unit is specifically used for:

[0050] Keeping the general function segment variables in the general function segment unchanged, and replacing the general function segment body in the general function segment with the index, the simplified smart contract is obtained.

[0051] Optionally, the general function segment library contains multiple associated items, each of which contains a general function segment body and an index corresponding to the general function segment body;

[0052] The determining unit is specifically used for:

[0053] In the general function segment library, search for the associated item that contains the main body of the general function segment;

[0054] If the associated item is found, the index in the found associated item is determined as the index corresponding to the general function segment body.

[0055] Optionally, the determining unit is specifically used for:

[0056] If the associated item is not found, assign the index corresponding to the main body of the general function segment;

[0057] In the general function segment library, the associated item is added, wherein the added associated item includes the general function segment body and the assigned index.

[0058] Optionally, each consensus node in the consensus node network maintains its own general function segment library;

[0059] The determining unit is specifically used for:

[0060] Adding the associated item to the general function segment library includes adding the associated item to the general function segment library of the target consensus node.

[0061] Optionally, the blockchain smart contract deployment device further includes:

[0062] The second sending unit is used to periodically send the general function segment library of the target consensus node to other consensus nodes, so that the other consensus nodes can respond to the scheduling request for the target smart contract, use the general function segment library of the target consensus node to restore the simplified smart contract on the target blockchain to the target smart contract, and execute the target smart contract.

[0063] Optionally, the first processing unit is specifically used for:

[0064] Obtain the first address on the target blockchain for storing the simplified smart contract;

[0065] Map the first address to the bottom-level node identifier of the target tree;

[0066] Based on the contract summary, update the underlying node corresponding to the underlying node identifier.

[0067] Optionally, the first processing unit is specifically used for:

[0068] Based on the updated underlying nodes, calculate the first contract digest corresponding to the root node of the target tree;

[0069] Obtain the second contract digest corresponding to the root node calculated by the other consensus nodes;

[0070] If the first contract digest matches the second contract digest, the target smart contract is determined to be secure.

[0071] Optionally, the identification unit is specifically used for:

[0072] Obtain the storage capacity of the target consensus node where the target smart contract is deployed;

[0073] Based on the storage capacity, determine the size of the general function segment body;

[0074] Based on the size of the general function segment body, at least one general function segment body is identified in the target smart contract.

[0075] According to one aspect of this disclosure, a blockchain smart contract invocation device is provided, comprising:

[0076] A receiving unit is configured to receive a scheduling request for a target smart contract, the scheduling request having a first address on the target blockchain;

[0077] The first acquisition unit is used to acquire the simplified smart contract on the target blockchain based on the first address;

[0078] An identification unit is used to identify the indexes in the simplified smart contract;

[0079] The second acquisition unit is used to acquire the general function segment body corresponding to the index in the general function segment library;

[0080] A replacement unit is used to replace the index in the simplified smart contract with the general function segment body to obtain the target smart contract;

[0081] An execution unit is used to execute the target smart contract.

[0082] Optionally, the scheduling request may also include the variable values ​​of general function segment variables;

[0083] The identification unit is specifically used for:

[0084] Identify the index in the simplified smart contract and the general function segment variable corresponding to the index;

[0085] The execution unit is specifically used for:

[0086] The variable value is substituted into the general function segment variable to run the general function segment body, thereby executing the target smart contract.

[0087] Optionally, the replacement unit is specifically used for:

[0088] The index in the simplified smart contract is replaced by the general function segment body, and the general function segment body and the general function segment variable corresponding to the index are combined to form the general function segment;

[0089] The target smart contract is synthesized using the general function segment.

[0090] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain smart contract deployment method as described above.

[0091] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain smart contract invocation method as described above.

[0092] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain smart contract deployment method as described above.

[0093] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain smart contract scheduling method as described above.

[0094] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain smart contract deployment method as described above.

[0095] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain smart contract scheduling method as described above.

[0096] Smart contracts contain many generic function segments, which appear in many different smart contracts. Storing the full text of each smart contract on the blockchain would be a significant waste of consensus nodes' storage resources. Therefore, this embodiment of the disclosure sets up a generic function segment library, which stores the main body of each generic function segment and its corresponding index. When a target smart contract needs to be deployed, the main body of the generic function segment is identified, and the main body of the generic function segment in the target smart contract is replaced with the corresponding index in the generic function segment library, resulting in a simplified smart contract. Storing the simplified smart contract on the target blockchain greatly reduces the storage resources required to store the smart contract. However, since only the simplified smart contract is on the target blockchain at this time, other consensus nodes do not have the target consensus node's generic function segment library, and cannot restore the simplified smart contract to the target smart contract, nor can they verify whether the target smart contract is correctly uploaded to the chain. To enable other consensus nodes to correctly verify the target smart contract, this embodiment of the disclosure sends the contract digest of the target smart contract to other consensus nodes, and each consensus node maintains a target tree. Each consensus node stores the contract digest in the bottom-level node of the target tree. Each non-bottom-level node in the target tree further calculates a digest from the concatenated results of the contract digests of the next lower-level nodes until the root node is obtained. If the target smart contract exhibits cheating behavior, the contract digests obtained by the various consensus nodes will be inconsistent, and the calculated root nodes will also be inconsistent, thus revealing the cheating when the target smart contract was uploaded to the blockchain. This disclosed embodiment can reduce the storage resources occupied by storing blockchain smart contracts while maintaining the security of smart contract uploading to the blockchain.

[0097] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0098] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0099] Figure 1 This is a system architecture diagram of a blockchain smart contract deployment method applied according to embodiments of this disclosure;

[0100] Figures 2A-2B This is a schematic diagram illustrating the application of a blockchain smart contract deployment method according to embodiments of this disclosure to an electronic invoice scenario;

[0101] Figures 3A-3C This is a schematic diagram illustrating the application of a blockchain smart contract deployment method according to embodiments of the present disclosure to a food traceability contract scenario;

[0102] Figures 4A-4B This is a schematic diagram illustrating the application of a blockchain smart contract deployment method according to embodiments of the present disclosure to a home smart contract scenario;

[0103] Figure 5 This is a schematic diagram of a target tree in a blockchain smart contract deployment method according to an embodiment of the present disclosure;

[0104] Figure 6 This is a schematic diagram of a consensus node network applied to a blockchain smart contract deployment method according to an embodiment of the present disclosure;

[0105] Figure 7 This is a general flowchart of a blockchain smart contract deployment method according to an embodiment of the present disclosure;

[0106] Figure 8 This is a schematic diagram illustrating the transformation process from a target smart contract to a simplified smart contract according to one embodiment of this disclosure;

[0107] Figure 9 yes Figure 7 A detailed flowchart of step 720;

[0108] Figure 10 yes Figure 9 Another specific flowchart for step 920;

[0109] Figure 11 yes Figure 7A detailed flowchart following step 720;

[0110] Figure 12 yes Figure 7 A detailed flowchart following step 720;

[0111] Figure 13 yes Figure 7 A detailed flowchart following step 720;

[0112] Figure 14 yes Figure 12 A specific flowchart of step 723;

[0113] Figure 15 yes Figure 12 Another specific flowchart for step 723;

[0114] Figure 16 yes Figure 12 Another specific flowchart for step 723;

[0115] Figure 17 yes Figure 12 Another specific flowchart for step 723;

[0116] Figure 18 yes Figure 17 A detailed flowchart of step 1740;

[0117] Figure 19 yes Figure 7 Another specific flowchart for step 720;

[0118] Figure 20 yes Figure 7 Another specific flowchart for step 720;

[0119] Figure 21 yes Figure 7 Another specific flowchart for step 720;

[0120] Figure 22 yes Figure 7 A detailed flowchart of step 730;

[0121] Figure 23 yes Figure 7 Another specific flowchart for step 730;

[0122] Figure 24 yes Figure 7 A detailed flowchart of step 730;

[0123] Figure 25 yes Figure 7 A specific flowchart following the replacement of steps 720 and 740;

[0124] Figure 26 yes Figure 7 A detailed flowchart of step 750;

[0125] Figure 27 yes Figure 7 Another specific flowchart for step 750;

[0126] Figure 28 yes Figure 25 The basis also includes a specific flowchart of step 760;

[0127] Figure 29 This is a general flowchart of a blockchain smart contract invocation method according to an embodiment of the present disclosure;

[0128] Figure 30 This is a schematic diagram illustrating the transformation process from a simplified smart contract to a target smart contract according to one embodiment of this disclosure;

[0129] Figure 31 yes Figure 29 A specific flowchart after replacing steps 2930 and 2960 based on the existing flowchart;

[0130] Figure 32 yes Figure 29 A detailed flowchart of step 2950;

[0131] Figure 33 This is a block diagram of a blockchain smart contract deployment apparatus according to an embodiment of the present disclosure;

[0132] Figure 34 This is a block diagram of a blockchain smart contract invocation device according to an embodiment of the present disclosure;

[0133] Figure 35 An embodiment of the present disclosure is shown. Figure 7 The diagram shows the server architecture for deploying blockchain smart contracts. Detailed Implementation

[0134] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0135] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0136] Blockchain: A chain-like data structure that combines data blocks sequentially in chronological order, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable.

[0137] A smart contract is a program running on the blockchain. It's a series of codes and data at a specific address on the blockchain. A smart contract is also an account, meaning it can be the object of transactions. However, it cannot be manually manipulated. It's a program deployed to the blockchain world state through blockchain transactions. Users can interact with smart contracts by submitting transactions and executing portions of their code. Smart contracts can define rules like regular contracts and be automatically enforced through code. Typically, smart contracts cannot be deleted after deployment, and interactions with them are irreversible.

[0138] World state: This refers to the blockchain world state repository maintained by the blockchain ledger program. It stores a cache of the current values ​​of a set of ledger states, including information such as smart contract code.

[0139] The general function segment library is a database where each blockchain node stores the main body of the general function segment after function partitioning and its index. For example, it may include two columns: one column is the index FID composed of UI nt16 elements, and the other column is the general function segment body FBODY composed of bytes elements. Alternatively, it may include two rows: one row is the index FID composed of UI nt16 elements, and the other row is the general function segment body FBODY composed of bytes elements. This disclosure does not limit how the relational database stores the general function segment body and its index.

[0140] Natural Language Processing (NLP) is an important field within computer science and artificial intelligence. It studies the theories and methods for enabling effective communication between humans and computers using natural language. NLP is a science that integrates linguistics, computer science, and mathematics. Therefore, research in this field involves natural language—the language people use in daily life—and thus it is closely related to linguistics, but also has important differences. NLP does not simply study natural language in general; rather, it focuses on developing computer systems, especially the software systems, that can effectively achieve natural language communication. Therefore, it is a part of computer science. NLP is mainly applied to machine translation, public opinion monitoring, automatic summarization, opinion extraction, text classification, question answering, text semantic comparison, speech recognition, Chinese OCR, and semantic recognition.

[0141] Currently, smart contracts contain many generic function segments, which appear in many different smart contracts. Storing the entire code of each smart contract on the blockchain wastes the storage resources of consensus nodes. For example, in blockchain e-invoice smart contracts, different invoice issuers will fill in different invoice headers and tax numbers, so the corresponding smart contracts are also different, and the e-invoices issued to each invoice issuer are not exactly the same. For blockchain e-invoices already stored on the blockchain, although the invoice headers and tax numbers are different, there is still a lot of identical content. For example, multiple blockchain e-invoices issued by the same merchant will have the same format of merchant name, merchant tax number, location, etc. in each blockchain e-invoice. This format is reflected in the smart contract using the same generic function segment code. Therefore, the blockchain stores a large amount of duplicate generic function segment code, and the code redundancy between smart contracts leads to high storage costs.

[0142] Although technologies have emerged to split and deduplicate the contract code of smart contracts, they only prevent the uploading of duplicate contract code from various smart contracts. While this reduces the amount of contract code that needs to be uploaded to the blockchain to some extent, it still consumes a lot of storage space, resulting in high storage costs.

[0143] The embodiments disclosed herein can reduce the storage resources occupied by storing blockchain smart contracts while maintaining the security of smart contracts on the blockchain.

[0144] System architecture and scenario description of the embodiments disclosed herein

[0145] Figure 1 This is a system architecture diagram of the blockchain smart contract deployment method according to embodiments of this disclosure. Figure 1 This is an optional structural diagram of the consensus node network 100 according to an embodiment of the present disclosure. It consists of multiple consensus nodes 110, and any two consensus nodes 110 can communicate and share data. In the consensus node network 100, any server can join the consensus node network 100 and become a new consensus node. Any consensus node 110 in the consensus node network 100 can communicate with the user terminal 200, and the user terminal 200 can deploy smart contracts in the consensus node network 100 through the consensus node 110 with which it communicates.

[0146] The embodiments disclosed herein can be applied in various scenarios, such as Figures 2A-2B The scenario shown is a blockchain electronic invoice. Figures 3A-3C The scenario shown is a food traceability contract. Figures 4A-4B The scenario shown is a smart home contract.

[0147] (a) Scenarios for issuing blockchain electronic invoices

[0148] Currently, with the rapid development of smart contract technology, blockchain e-invoices, as a type of blockchain smart contract, have replaced traditional e-invoices. In traditional e-invoice schemes, e-invoices are managed by a central institution that issues the invoice. While this solves the problems of paper invoices being easily lost and forged, the issuance process is still controlled by the central institution's staff, making third-party supervision impossible, and the issuer still needs to complete a manual reimbursement process. Therefore, blockchain e-invoices can track the entire transaction process while maintaining the original invoice attributes, allowing the e-invoice to be under third-party supervision and automatically completing the invoicing and reimbursement processes, saving time and resources. When consensus nodes process e-invoices for issuance or reimbursement, they need to call the corresponding smart contracts. Since different types of enterprises require different smart contracts for e-invoice processing, when there are many types of enterprises, a large number of smart contracts need to be stored on the blockchain, consuming significant storage resources.

[0149] The embodiments of this disclosure solve this problem. It utilizes consensus node 110 to generate a streamlined smart contract with a smaller footprint. When a smart contract is needed to store an electronic invoice for a certain type of enterprise on the blockchain, the streamlined smart contract is generated and deployed to the blockchain according to the blockchain smart contract deployment method of this disclosure. This reduces the space required to store the smart contract on the blockchain, lowering storage costs.

[0150] like Figure 2A As shown, in order to complete the transaction processing for helping enterprises complete electronic invoices, consensus node 1 needs to obtain various smart contracts for handling electronic invoice transactions of various types of enterprises in advance and deploy them on the blockchain. These smart contracts may share the same function segments. Assuming that the smart contracts are recorded on the blockchain, they require 2.5MB of storage space for consensus node 1. According to the blockchain smart contract deployment method of this disclosure embodiment, consensus node 1 simplifies the identical function segments in the generated smart contracts before deployment, such as... Figure 2B As shown, it requires 1MB of storage space on consensus node 1, saving 1.5MB of storage resources.

[0151] It should be noted that the storage space occupied here is for illustrative purposes only. The storage space occupied will vary depending on the content of the smart contract, and no specific limit is given here.

[0152] (II) Scenarios of Food Traceability Contracts

[0153] Currently, with the rapid development of smart contract technology, food traceability contracts, as a type of smart contract, are widely used. Food traceability contracts aim to verify food origin information and supply chain information, tracing the source and transportation of food to ensure food safety. Food traceability information is recorded on the blockchain. Food traceability contracts are used to verify the food traceability information recorded on the blockchain. For example... Figure 3A As shown, when faced with different traceability codes 1-3 on different products, the terminal scans them and sends the results to consensus node 1 for verification of food traceability information. Figure 3B As shown, the terminal's graphic code scanning function is used to scan the traceability code on the product to obtain the storage address of the food traceability information stored on the blockchain. Then, the relevant food traceability information is retrieved on the blockchain based on the storage address, and the food traceability contract is used for verification.

[0154] Before scanning food traceability codes and verifying them using food traceability contracts, the food traceability contracts must first be deployed on the blockchain. Since different types of food may correspond to different food traceability contracts, a large number of these contracts need to be stored on the blockchain. For example, food traceability contract 1 for verifying the traceability information of watermelons needs to be recorded on the blockchain, food traceability contract 2 for verifying the traceability information of apples needs to be recorded on the blockchain, and so on. Recording all these different food traceability contracts on the blockchain results in a significant consumption of storage resources.

[0155] These food traceability smart contracts may share the same function segments. Simplifying these identical function segments before storing them on the blockchain can significantly reduce storage resource consumption. In this scenario, consensus node 1, according to the blockchain smart contract deployment method of this disclosure, simplifies the identical function segments in the food traceability smart contracts before deployment, such as... Figure 3C As shown, this greatly reduces the storage resource consumption caused by putting food traceability contracts on the blockchain.

[0156] (III) Scenarios of Smart Home Contracts

[0157] Currently, with the rapid development of smart contract technology, smart contracts have been applied in the Internet of Things (IoT). In traditional IoT architectures, data is typically uploaded from local terminal devices to cloud servers, where it is then processed and distributed. However, in this architecture, the server's handling of data processing and distribution can lead to the leakage of user information. Furthermore, data interconnection relies on the network; when the server fails, the IoT system cannot function. Therefore, smart contracts are used to manage IoT devices. For example, smart contracts can be used to manage smart home devices, distributing data processing capabilities across various smart home devices: predefined smart contracts are deployed on a suitable blockchain. Consensus nodes then use the smart contracts stored on the blockchain to exchange data and collaboratively control the various smart home devices used in a home or company, and record the data generated during the use of these devices on the blockchain. For instance, when a household has a large number of smart home devices of various types, the number of smart contracts that need to be stored for that household becomes very large. While a single home smart contract occupies limited storage resources, the total storage resources required by all home smart contracts can become substantial when the number or types of smart home devices in a household reach a certain level. Furthermore, consensus nodes have limited storage resources. Therefore, there is a need to reduce the storage resource usage of home smart contracts, thereby conserving storage resources for consensus nodes.

[0158] The embodiments of this disclosure solve this problem. It utilizes consensus node 1 to generate a simplified home smart contract with a smaller footprint. The home smart contract can control different smart home devices; for example, it can control a smart air conditioner. For each new smart home device added, consensus node 1 might normally need to generate a complete home smart contract and deploy it to the blockchain. Smart home devices include: smart water heaters, smart water dispensers, smart curtain boxes, smart TVs, etc. Automated control can be achieved when the corresponding home smart contract is satisfied. The home smart contracts of different smart home devices contain many common function segments, such as startup program segments. According to the blockchain smart contract deployment method of this disclosure, these common function segments can be simplified to generate a simplified home smart contract stored on the consensus node network. This reduces the storage resources consumed by the terminal storing all home smart contracts in the smart home device, lowering storage costs.

[0159] like Figure 4AAs shown, a household (corresponding to consensus node 1) includes a smart air conditioner and a smart robot vacuum cleaner. To provide a better user experience, the smart air conditioner corresponds to a home smart contract 1, and the smart robot vacuum cleaner corresponds to a home smart contract 2. Taking home smart contract 1 as an example, when the smart air conditioner detects the presence of people in the current environment and detects that the current temperature exceeds a threshold, for example, when the ambient temperature reaches 30°C, it automatically controls the smart air conditioner to start through home smart contract 1 and adjusts the ambient temperature to 25°C, improving the comfort of the environment. Both the complete home smart contract 1 and the complete home smart contract 2 contain a lot of code used to represent the format content. Assume that a complete home smart contract 1 requires 2MB of storage space on consensus node 1. When the generated home smart contract is simplified according to the blockchain smart contract deployment method of this disclosure embodiment, as follows... Figure 4B As shown, deploying the simplified smart home contract and contract summary to the blockchain requires 1MB of storage space on consensus node 1, saving 1MB of storage resources.

[0160] General Description of Embodiments in this Disclosure

[0161] According to one embodiment of this disclosure, a method for deploying blockchain smart contracts is provided.

[0162] A contract digest is a summary value of the complete code of each smart contract, used by other consensus nodes in the blockchain network to securely verify the smart contract generated by the current consensus node. In essence, a smart contract is an automatically executable program stored on the blockchain. This program integrates various information and functions required by the smart contract. Therefore, a smart contract contains a lot of functional code to implement various functions and content code to record various information. These functional or content codes are implemented through function segments. These function segments are divided into dedicated function segments and general function segments. Dedicated function segments exist only in a single smart contract. General function segments exist in multiple smart contracts.

[0163] Blockchain is a chain-like data structure that combines data blocks sequentially in chronological order. Consensus nodes are nodes authorized to generate blocks and record them on the blockchain. Consensus nodes can be servers, a subset of servers, or a cluster of servers. The collection of consensus nodes is called a consensus node network. Before a consensus node adds a block to the blockchain, it must reach a consensus with other consensus nodes in the network. Each consensus node maintains its own blockchain. Every block to be recorded on the blockchain undergoes consensus among all consensus nodes before being added to its own blockchain by each node. This ensures that the blockchains maintained by each consensus node are consistent, preventing tampering. Furthermore, smart contracts are also recorded on the blockchains maintained by their respective consensus nodes after consensus is reached.

[0164] In this embodiment of the disclosure, the consensus node for which smart contracts need to be deployed is referred to as the target consensus node, and the consensus nodes other than the target consensus node are referred to as other consensus nodes. Each consensus node in the consensus node network maintains an accounting program, a target tree that records the contract digests of each smart contract to verify the security of the smart contracts, and a general function segment library.

[0165] The target tree and the general function segment library will be explained in detail below.

[0166] Since this embodiment only stores the simplified smart contract on the blockchain, and other consensus nodes do not possess the general function segment library of the target consensus node (explained in detail later), they cannot reconstruct the simplified smart contract into the target smart contract, and therefore cannot verify whether the target smart contract has been correctly uploaded to the blockchain. Therefore, this embodiment verifies whether the target smart contract has been correctly uploaded to the blockchain through a target tree.

[0167] The target tree is a tree structure that records the summaries of each smart contract uploaded to the blockchain. It allows verification of whether a contract was correctly uploaded. At the bottom layer of the tree, the summaries of each smart contract are recorded in the order they were uploaded. For example, if eight smart contracts are uploaded to the blockchain, arranged in chronological order of upload time, the result would be: Contract 1, Contract 2, Contract 3, Contract 4, Contract 5, Contract 6, Contract 7, and Contract 8. Therefore, the bottom layer of the tree would have eight nodes from left to right: Contract 1 summary, Contract 2 summary, Contract 3 summary, Contract 4 summary, Contract 5 summary, Contract 6 summary, Contract 7 summary, and Contract 8 summary. Any digest algorithm can be used. If the digest algorithm is a hash algorithm, the digest is a hash value.

[0168] Each non-bottom-level node in the target tree is a further summary of the concatenation result of the summaries of the summaries of the nodes connected to it at the next lower level. In one embodiment, two adjacent nodes at the next lower level can be considered as a pair of nodes connected to a current-level node. The summary of this current-level node is the summation value obtained by further summarizing the concatenation result of the summaries of the two connected nodes at the next lower level. Figure 5 As shown, concatenating the summaries of Contract 1 and Contract 2, and then summarizing the concatenation result, yields the first node summary 1-2 of the third layer. Concatenating the summaries of Contract 3 and Contract 4, and then summarizing the concatenation result, yields the second node summary 3-4 of the third layer. Concatenating the summaries of Contract 5 and Contract 6, and then summarizing the concatenation result, yields the third node summary 5-6 of the third layer. Concatenating the summaries of Contract 7 and Contract 8, and then summarizing the concatenation result, yields the fourth node summary 7-8 of the third layer. Concatenating summaries 1-2 and 3-4 of the third layer, and then summarizing the concatenation result, yields the first node summary 1-4 of the second layer. Concatenating summaries 5-6 and 7-8 of the third layer, and then summarizing the concatenation result, yields the second node summary 5-8 of the second layer. Concatenating summaries 1-4 and 5-8 of the second layer, and then summarizing the concatenation result, yields summary 1-8, which is the root node. If new contracts are added to the blockchain, such as contract 9 and contract 10, then two more nodes will be added sequentially after the digest of contract 8 at the underlying node: the digests of contract 9 and contract 10. After the above calculations, the root node will be updated.

[0169] In the above embodiment, two adjacent lower-level nodes are grouped together as a pair and connected to a current-level node. In other embodiments, three adjacent lower-level nodes can be grouped together as a set and connected to a current-level node, or other numbers of adjacent lower-level nodes can be grouped together as a set and connected to a current-level node. Furthermore, the number of lower-level nodes in each group can be variable. For example, the first group may have three lower-level nodes, the second group may have four lower-level nodes, and so on.

[0170] The general function segment library is a database that records the correspondence between general function segment bodies and their indexes. A general function segment includes a general function segment body and general function segment variables. The general function segment body is the program code within the general function segment. For example, COMP(A, B) is a function segment that compares whether two corpora A and B are completely identical. The general function segment body is the program code that compares whether two corpora A and B are completely identical. General function segment variables are the variables needed by the general function segment body at runtime. For COMP(A, B), A and B are general function segment variables, indicating the addresses of the two corpora to be compared for consistency.

[0171] An index is a unique identifier assigned to the general function segment body. Since different general function segment bodies are assigned different indices, they can be used to distinguish between them. Because its length is significantly shorter than the general function segment body, it is used to replace the general function segment body in the target smart contract, resulting in a simplified smart contract. Storing the simplified smart contract on the blockchain, instead of storing the smart contract itself, can greatly reduce the storage space occupied by smart contract deployment.

[0172] In one embodiment, the general function segment library is shown in Table 1. This general function segment library includes two columns: an index and a general function segment body. The index can be composed of `ui nt16` elements, and the function body is composed of `bytes` elements. In Table 1, the first row indicates that the index corresponding to the general function segment body 0xaabb… is 0. The second row indicates that the index corresponding to the general function segment body 0xccdd… is 1. The third row indicates that the index corresponding to the general function segment body 0xeeff… is 2. The fourth row indicates that the index corresponding to the general function segment body 0xgghh… is 3.

[0173] Index FID General function segment body FBODY 0 0xaabb… 1 0xccdd… 2 0xeeff… 3 0xgghh… …… ……

[0174] Table 1

[0175] Since each consensus node maintains a... Figure 5 The target tree shown illustrates how, when a contract is added to the blockchain, its summary is synchronized to all consensus nodes. Each consensus node then records the summary of the new contract at the end of its underlying nodes and recalculates the upper-level nodes. Since all consensus nodes receive the same summary of the new contract, the root node of their respective target trees should be identical. If all smart contracts are correctly uploaded to the blockchain, the root nodes in the target trees maintained by each consensus node should be consistent. Based on this, it is possible to verify whether the target smart contract has been correctly uploaded to the blockchain. That is, once the underlying nodes are updated, the consensus nodes can recalculate the value of the aforementioned root node based on the updated underlying nodes and obtain the value of the aforementioned root node calculated by other consensus nodes based on their own target trees. If the two are consistent, it indicates that the target smart contract has been correctly uploaded to the blockchain. Otherwise, it indicates that the target smart contract has not been correctly uploaded to the blockchain.

[0176] As mentioned above, each consensus node in a blockchain network maintains a ledger program, a target tree, and a library of general-purpose function segments. For example, Figure 6The diagram illustrates three consensus nodes: Node A, Node B, and Node C. Each node stores an accounting program, a target tree, and a general function segment library. Specifically, Node A stores accounting program A, target tree A, and general function segment library A; Node B stores accounting program B, target tree B, and general function segment library B; and Node C stores accounting program C, target tree C, and general function segment library C. Accounting programs A, B, and C are always consistent. After consensus is reached among nodes A, B, and C, the blockchain maintained by each node remains consistent. Target trees A, B, and C also remain consistent after consensus is reached among nodes A, B, and C. General function segment libraries A, B, and C can be the same or different; this is not a limitation here.

[0177] The blockchain smart contract deployment method of this disclosure can be executed on the consensus node.

[0178] like Figure 7 As shown, a blockchain smart contract deployment method according to an embodiment of this disclosure includes:

[0179] Step 710: Obtain the contract summary of the target smart contract;

[0180] Step 720: Identify at least one general function segment body in the target smart contract;

[0181] Step 730: Use the general function segment library to determine the index corresponding to the general function segment body;

[0182] Step 740: Replace the general function segment body in the target smart contract with the index to obtain the simplified smart contract;

[0183] Step 750: Send the simplified smart contract and contract digest to other consensus nodes for consensus, so that the simplified smart contract can be stored on the target blockchain. Update the bottom nodes of the target tree with the contract digest, and use the target tree to verify the security of the target smart contract. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level nodes until the root node is obtained.

[0184] First, a brief description of steps 710-750 above will be given.

[0185] In step 710, the contract summary of the target smart contract is obtained. The target smart contract here is a smart contract generated according to the needs of the use case. For example, the target smart contract could be an electronic invoice smart contract needed to process electronic invoices, a food traceability contract, a home smart contract, or a smart contract from other use cases; there are no limitations on this.

[0186] A contract digest is a summary of the complete code of a target smart contract. The contract digest is used to ensure that no errors occur when the target consensus node and other consensus nodes reach consensus, thus ensuring the secure deployment of the target smart contract. The target consensus node is the consensus node currently deploying the target smart contract. Because the code and size of each smart contract are not completely identical, they need to be converted into fixed-size data. For example, using the SHA-256 or SHA3-256 digest algorithm, the complete code of each target smart contract is converted into a 256-bit contract digest, so that each consensus node in the consensus node network can check the security of the target smart contract based on the contract digest of each target smart contract.

[0187] After obtaining the contract summary of the target smart contract, in step 720, at least one general function segment body can be identified in the target smart contract.

[0188] To identify the general function segment body in the complete code of the target smart contract, different parsing tools can be used to identify the function segment body according to the identification granularity corresponding to the tool. The identification granularity corresponding to each parsing tool can be the same or different. For example, for the same target smart contract, parsing tool 1 can identify multiple general function segment entities such as general function segment entity A, general function segment entity B, general function segment entity C, and general function segment entity D. Parsing tool 2 can identify multiple general function segment entities such as general function segment entity A1, general function segment entity A2, general function segment entity B1, general function segment entity B2, general function segment entity C1, general function segment entity C2, general function segment entity D1, and general function segment entity D2. Among them, general function segment entities A1 and A2 can form general function segment entity A, general function segment entities B1 and B2 can form general function segment entity B, general function segment entities C1 and C2 can form general function segment entity C, and general function segment entities D1 and D2 can form general function segment entity D. Therefore, the identification granularity of parsing tool 1 is greater than that of parsing tool 2. Each parsing tool corresponds to a recognition standard, which can be a keyword standard or a semantic standard. It can identify general function segments with the same semantics according to the semantic standard, or it can identify general function segments with the same keywords according to the keyword standard.

[0189] After identifying at least one general function segment body, in step 730, the index corresponding to the general function segment body can be determined using the general function segment library.

[0190] As mentioned earlier, the general function segment library is pre-set, storing general function segment bodies and their corresponding indexes. Thus, when determining the index corresponding to each general function segment body, each identified general function segment body can be compared one-to-one with the general function segment bodies stored in the library to obtain the index of each identified general function segment body. After determining the index corresponding to the general function segment body, in step 740, the index can be used to replace the general function segment body in the target smart contract, resulting in a simplified smart contract.

[0191] Related technologies merely omit repetitive code segment slices or divide complete code segments into smaller code segment slices. However, in this embodiment, the target smart contract needs to replace the general function segment body with an index. The general function segment body is the smallest execution unit of code. The reuse rate of the general function segment body is higher than that of code segment slices, resulting in a larger number of general function segment bodies (code segments) that need to be replaced. Replacing the general function segment body will save more storage space. Theoretically, the storage space occupied by the index should be smaller than that occupied by the general function segment body to reduce the size of the target smart contract after replacement. Therefore, it is necessary to limit the size of the index, i.e., set the number of bits in the index. Preferably, this disclosure uses 16-bit unsigned integers to form the index, with a value range of 0 to 65535, which can correspond to a maximum of 65536 general function segment bodies, covering various commonly used general function segment bodies. If the number of general function segments to be replaced is small, an 8-bit unsigned integer index can be used, with values ​​ranging from 0 to 255, corresponding to a maximum of 256 general function segments. However, this is insufficient if the number of general function segments to be covered exceeds 256. Alternatively, a 32-bit unsigned integer index can be used, with values ​​ranging from 0 to 4,294,967,295, corresponding to a maximum of 4,294,967,296 general function segments, far exceeding the number of general function segments to be replaced. Furthermore, 32-bit unsigned integers occupy a significant amount of storage, impacting storage resource efficiency. Therefore, considering all factors, this disclosure uses a 16-bit unsigned integer index.

[0192] After determining the index corresponding to the general function segment body, in step 750, the simplified smart contract and contract digest can be sent to other consensus nodes for consensus, so that the simplified smart contract can be stored on the target blockchain. The bottom nodes of the target tree are updated with the contract digest, and the security of the target smart contract is verified by the target tree. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level node until the root node is obtained.

[0193] The target consensus node that generates the simplified smart contract needs to reach consensus with other consensus nodes in the same blockchain network. Different consensus nodes in the same consensus node network each maintain a target tree, and all target trees are consistent. The structure of the target tree has been described in detail above, so it will not be repeated here.

[0194] An example of the transformation process from the target smart contract to the simplified smart contract in steps 710-750 above is as follows: Figure 8 As shown, because the main body of the stored general function segment is transformed into a smaller index, it consumes less storage resources. This significantly reduces the storage resources consumed by the target smart contract, provided that other consensus nodes can perform security verification of the simplified smart contract based on the contract digest.

[0195] Detailed description of step 710

[0196] In one embodiment, step 710 may include: obtaining a contract summary of the target smart contract in response to receiving a request to upload the target smart contract to the blockchain. The target smart contract is the smart contract to be recorded on the blockchain. The request to upload the target smart contract to the blockchain may be sent by a user terminal that needs to use the target smart contract to the consensus node executing steps 710-750. For example, in the previous scenario of electronic invoices, the user terminal may be the terminal of a merchant that needs to use electronic invoices. Merchants using electronic invoices need the consensus node to process and upload the electronic invoices to the blockchain. Therefore, the target smart contract for electronic invoice processing is sent to the consensus node in advance, requesting the consensus node to upload the target smart contract to the blockchain first, so that when an electronic invoice request is received subsequently, the consensus node can process it according to the target smart contract. The advantage of this embodiment is that the contract is deployed immediately after receiving the request to upload the target smart contract to the blockchain, which improves the real-time performance and efficiency of contract deployment.

[0197] In another embodiment, steps 710-750 above can be executed periodically. A time period is preset. Then, steps 710-750 are executed once every time period. For example, the time period is set to 10 minutes. Every 10 minutes, steps 710-750 are executed once to deploy the simplified smart contract. In this case, step 710 may include: periodically obtaining the contract summary of the target smart contract. In this embodiment, when a smart contract to be added to the blockchain is received, it cannot be added to the blockchain immediately, but is cached in a specific cache. Whenever the fixed period arrives, the cached target smart contracts are retrieved from the cache, and the process of steps 710-750 is executed.

[0198] The advantage of periodically obtaining the contract summary of the target smart contract is that, since steps 710-750 are only triggered at the end of each period, the target smart contracts received in that period can be accumulated and deployed together, reducing the network resources required for deployment and improving network resource utilization.

[0199] In one embodiment, steps 710-750 can be triggered by a triggering event.

[0200] At this point, step 710 may include: obtaining the contract digest of the target smart contract in response to a triggering event. The advantage of obtaining the contract digest in response to a triggering event is that the contract digest is calculated based on the complete code of the target smart contract only when the triggering event occurs, thereby deploying the target smart contract. If no triggering event occurs, even if a smart contract is added, it is not deployed immediately. This reduces unnecessary computational overhead, and the event-responsive approach is more real-time, improving processing real-time performance in scenarios with stringent real-time requirements.

[0201] A triggering event is an event used to trigger the execution of the blockchain smart contract deployment method of the embodiments of this disclosure.

[0202] It can include, but is not limited to, the following events:

[0203] The consensus node's occupied storage space exceeds the predetermined space size;

[0204] The priority of the target smart contract to be added to the blockchain is lower than the predetermined priority.

[0205] The purpose of replacing the general function segment body in the target smart contract with an index for on-chain processing in this embodiment is to reduce the occupation of storage resources. If the occupied storage space of the consensus node is not greater than the predetermined space size, there is still a lot of usable storage space in the consensus node, so the need to reduce the occupation of storage space may not be urgent. In this case, steps 710-750 can still be omitted. When the occupied storage space of the consensus node is greater than the predetermined space size, the usable storage space in the consensus node becomes less, so it is necessary to replace the general function segment body in the target smart contract with an index for on-chain processing, thereby reducing the occupation of storage space. In this case, steps 710-750 are executed. This embodiment can improve the flexibility of consensus node storage space usage. When there is still some storage space, the complete smart contract can be on-chain, and when storage space is insufficient, only a simplified smart contract is on-chain, thus flexibly adapting to various situations.

[0206] Furthermore, whether to upload the simplified smart contract to the blockchain may depend on the priority of the target smart contract. Higher-priority target smart contracts require high real-time performance during execution. If only the simplified smart contract is stored on the blockchain, when a transaction execution request is received and the smart contract needs to be scheduled to execute the transaction, the simplified smart contract must be restored to the target smart contract, increasing processing overhead and waiting time. Therefore, for high-priority, high-real-time target smart contracts, the entire target smart contract can be uploaded to the blockchain. Only for lower-priority, lower-real-time target smart contracts, the simplified smart contract is uploaded. This method satisfies the real-time requirements of high-real-time services while reducing the storage space occupied by consensus nodes.

[0207] To obtain the contract digest of a target smart contract, one can first obtain a digest algorithm, and then use that algorithm to calculate the digest of the target smart contract. An example of a digest algorithm is a hash algorithm. However, there are other digest algorithms known in the art. Any digest algorithm that can be used to calculate a digest can be used as the digest algorithm in the embodiments of this disclosure.

[0208] Detailed description of step 720

[0209] In step 720, at least one general function segment body is identified in the target smart contract.

[0210] The general function segment here refers to the operational code portion of the contract code that can perform element-level operations on arrays. For example, `search(A, B)` is a function segment that searches for keyword B in corpus A. Here, corpus A is an array, and B is an element. Below is an example of the function segment `search(A, B)`;

[0211] search(A,B):

[0212] A:=xxxx, B:=xxx;

[0213] {xxxxxxxxxxxxxxxxxxx;

[0214] xxxxxxxxxxxxxxxxxxxxxx;

[0215] ...

[0216] xxxxxxxxxxxxx}.

[0217] In the function segment above, apart from the part "A:=xxxx,B:=xxx" which gives the definition of the variables used in the function segment, the part in {} gives the operation code in the function segment. They all belong to the general function segment body.

[0218] As mentioned earlier, the general function segment library can be pre-configured, storing general function segment bodies and their corresponding indexes. Therefore, in one embodiment, the general function segment library can be used to identify the general function segment bodies. The general function segment bodies in the library can be matched one by one with the target smart contract. If a portion in the target smart contract is found that completely matches a general function segment body in the library, then it is determined that a general function segment body has been identified in the target smart contract.

[0219] In the example above, if the following general function segment body is found in the general function segment library, then it is determined that the general function segment body search(x,x) has been identified in the target smart contract:

[0220] Search():

[0221] ...

[0222] {xxxxxxxxxxxxxxxxxxx;

[0223] xxxxxxxxxxxxxxxxxxxxxx;

[0224] ...

[0225] xxxxxxxxxxxxx} (The operation code is exactly the same as the search(A,B) above).

[0226] By using the method described above to find the general function segment library, the main body of the general function segment can be quickly and efficiently identified in the target smart contract. Considering that a small piece of operation code in the target smart contract may differ slightly in statement from the main body of the general function segment in the general function segment library, but the function implemented is completely identical, in another embodiment, semantic recognition is used to improve the accuracy of the identification of the main body of the general function segment.

[0227] In this embodiment, it can be achieved through, as follows Figure 9 The method shown identifies the body of the general function segment. For example... Figure 9 As shown, step 720 may include:

[0228] 910. In the target smart contract, identify the main body of the candidate code segment and obtain the first semantics of the main body of the candidate code segment;

[0229] 920. Obtain the second semantics of the general function segment body in the general function segment library;

[0230] 930. If the first semantic is the same as the second semantic of a general function segment body in the general function segment library, the candidate code segment body is determined as the identified general function segment body.

[0231] Steps 910-930 are described in detail below.

[0232] The candidate code segment body is an operational code fragment that is likely to become the code segment body. In the example above, the candidate code segment bodies are all enclosed in curly braces {}, and the curly braces are preceded by a code pattern such as "function body name():" one or more lines below. Therefore, in one embodiment, "function body name():" can be searched in the target smart contract. Once the pattern "function body name():" is found, the searcher can check if curly braces {} are present one or more lines below. If curly braces are present, the content within the curly braces is identified as the candidate code segment body. Since the patterns of candidate code segment bodies differ in different programming languages, the above embodiment is merely an example. Those skilled in the art can determine the patterns of candidate code segment bodies by combining the programming language itself, and thus formulate rules for identifying candidate code segment bodies in the target smart contract.

[0233] There are several ways to obtain the primary semantics of candidate code segments. One approach is to perform semantic analysis on each candidate code segment using a pre-trained semantic model to obtain its primary semantics. The primary semantics is generally represented by the semantic vector output by the semantic model. The semantic model is primarily trained using Natural Language Processing (NLP), specifically employing methods such as Hidden Markov Models or Abstract Syntax Trees (ASTs). The appropriate semantic model can be selected based on actual needs and training effectiveness; this disclosure does not impose any limitations on this approach.

[0234] In step 920, the second semantics of the general function segment body in the general function segment library is obtained. The process of identifying the second semantics is similar to that of identifying the first semantics. The semantic model used in identifying the first semantics is the same as that used in identifying the second semantics; that is, a preset semantic model can be used to identify the first semantics of the candidate code segment body, and then the same semantic model can be used to identify the second semantics of the general function segment body in the general function segment library. This embodiment of the present disclosure uses a first identification order: identifying the second semantics after identifying the first semantics. This embodiment of the present disclosure can also perform semantic identification according to a second identification order: identifying the second semantics before identifying the first semantics. The choice can be made based on the actual situation. This embodiment of the present disclosure uses the first identification order for explanation. When the second identification order is used, because all the general function segment bodies in the general function segment library have been pre-set, or most of the general function segment bodies that need to be matched have been pre-stored in the general function segment library, with a small portion not stored, when an unstored general function segment body is identified, it only needs to be added to the general function segment library. Therefore, the second semantics corresponding to the body of each general function segment in the general function segment library can be generated in advance and stored in the second semantics table. When it is necessary to obtain the second semantics of the body of the general function segment in the general function segment library, the second semantics table can be queried directly. An example of the second semantics table is as follows.

[0235] General function segment body FBODY Second semantics search() (1,0,0,1,0,0,1……1,1,0,0,1,0) subtract() (1,1,0,1,0,1,1……1,0,0,0,1,1) summary() (0,0,0,1,0,1,1……1,0,0,0,0,1) divide() (1,1,1,1,0,1,0……1,1,0,1,0,1) …… ……

[0236] Table 2

[0237] It is also understandable that the mapping relationship between the general function segment body and the second semantics maintained in Table 2 can be used as part of the general function segment library. That is, the general function segment library stores the general function segment body, the corresponding index, and the corresponding second semantics. As shown in Table 3, by adding a column to Table 1 to represent the second semantics, we obtain the general function segment library shown in Table 3.

[0238] Index FID General function segment body FBODY Second semantics 0 search() (1,0,0,1,0,0,1……1,1,0,0,1,0) 1 subtract() (1,1,0,1,0,1,1……1,0,0,0,1,1) 2 summary() (0,0,0,1,0,1,1……1,0,0,0,0,1) 3 divide() (1,1,1,1,0,1,0……1,1,0,1,0,1) …… …… ……

[0239] Table 3

[0240] In step 930, if the first semantic is the same as the second semantic of a general function segment body in the general function segment library, the candidate code segment body is determined as the identified general function segment body.

[0241] If the first semantic is the same as the second semantic of any general function segment body in the general function segment library, then it can be determined that the candidate code segment body corresponding to the first semantic is the general function segment body corresponding to the same second semantic. For example, if the first semantic of a candidate code segment body is (1,0,0,1,0,0,1……1,1,0,0,1,0), and the general function segment library stores a general function segment body search() with the second semantic (1,0,0,1,0,0,1……1,1,0,0,1,0), and the first and second semantics are the same, then the candidate code segment body is determined to be the general function segment body search().

[0242] The advantage of steps 910-930 is that it can identify candidate function segment subjects with the same semantics as the same general function segment subject. Without changing the function of the target smart contract, it increases the probability of identifying general function segment subjects, expands the replacement range of general function segment subjects by index, and thus has a greater probability of saving more storage resources.

[0243] When obtaining the second semantics of the general function segment body in the general function segment library in step 920, the second semantics can be obtained for each general function segment body in the general function segment library. In another embodiment, only general function segment bodies whose keywords match the keywords of the candidate code segment bodies can be selected, their second semantics can be obtained, and then matched with the first semantics of the candidate code segment bodies.

[0244] In this embodiment, such as Figure 10 As shown, step 920 includes:

[0245] 1010. Extract the first keyword from the main body of the candidate code segment;

[0246] 1020. Extract the second keyword from the main body of each general function segment in the general function segment library;

[0247] 1030. Determine the general function segment body that matches the second keyword with the first keyword, and use it as the matching general function segment body;

[0248] 1040. Obtain the second semantics that matches the body of the general function segment in the general function segment library.

[0249] During the second semantic recognition process, because the general function segment library stores a large number of general function segment subjects, to improve recognition efficiency and reduce unnecessary semantic recognition, it is only necessary to obtain the second semantics of general function segment subjects that are closely related to the candidate code segment subjects. Close association can be reflected in having the same or similar keywords. For example, the candidate code segment subject for searching a word in a paragraph is `search()`, and the keywords extracted from it might be "search", "compare", "same", etc. The general function segment subject for performing addition operations, `add()`, might extract keywords like "add" and "sum". Since the two have no shared keywords, it means that these two function segments are not related, and therefore, there is no need to obtain the second semantics of the general function segment subjects for comparison with the first semantics.

[0250] The first keyword is extracted from the body of the candidate code segment, such as "search", "compare", and "same" above. The second keyword is extracted from the body of the general function segment in the general function segment library, such as "add" and "sum" above.

[0251] In one embodiment, matching the second keyword with the first keyword means that all the first keywords extracted from the candidate code segment body match all the second keywords extracted from the general function segment body in the general function segment library. For example, the first keywords extracted from the candidate code segment body are "search", "compare", and "same". The second keywords extracted from the general function segment body in the general function segment library are also "search", "compare", and "same".

[0252] In one embodiment, matching the second keyword with the first keyword means that a first keyword extracted from the candidate code segment body matches a second keyword extracted from the general function segment body in the general function segment library. For example, the first keywords extracted from the candidate code segment body are "search", "compare", and "same". The second keywords extracted from the general function segment body in the general function segment library are also "compare" and "different".

[0253] In one embodiment, a second keyword matching the first keyword means that a predetermined percentage or higher of the second keywords extracted from the general function segment body of the general function segment library are consistent with the first keywords extracted from the candidate code segment body. For example, the first keywords extracted from the candidate code segment body are "search", "compare", and "same". The second keywords extracted from the general function segment body of the general function segment library are also "compare", "different", and "same", where "compare" and "same" are consistent with the first keywords, accounting for 67% of the total number of second keywords. The predetermined percentage is 50%. Therefore, the second keyword matches the first keyword.

[0254] In this embodiment, keyword matching is first performed on each general function segment body in the general function segment library and the candidate code segment body. Only when the second keyword matches the first keyword will the general function segment body corresponding to the second keyword be identified for the second semantic. This narrows down the range of general function segment bodies in the general function segment library that need to be identified for the second semantic, and improves the efficiency of identifying at least one general function segment body in the target smart contract.

[0255] In another embodiment, such as Figure 11 As shown, after step 720, the following may also be included:

[0256] 721. Obtain the size of the general function segment body;

[0257] 722. Filter the main body of general function segments based on size.

[0258] In step 721, the size of the general function segment body mainly refers to the number of bytes occupied by the general function segment body. Different general function segment bodies correspond to different functions, therefore, the amount of code required to complete the corresponding functions also varies. It is understandable that if the size of a general function segment is very small, storing it entirely on the blockchain would not occupy much storage resources, so it can be filtered out and does not need to proceed to the subsequent step of replacing the general function segment body with an index, thereby reducing the computational load and overhead of subsequent steps.

[0259] In step 722, in one embodiment, if the size of a general function segment body is less than a predetermined size, it can be filtered out without proceeding to subsequent steps. In another embodiment, if the general function segment body ranks Nth from the bottom in size, it can be filtered out without proceeding to subsequent steps, where N is a positive integer. For example, in a target smart contract with 8 general function segment bodies, the 8 general function segment bodies are sorted by size, and the three general function segment bodies ranked last are not proceeded to the subsequent step of replacing general function segment bodies with indices to obtain a simplified smart contract. In another embodiment, if the general function segment body ranks Nth from the bottom in size and its size is less than a predetermined size, it can be filtered out.

[0260] The advantage of this embodiment is that the size of the general function segment body can be used as the basis for judging whether it is worthwhile to replace it. After filtering the general function segment bodies according to size, those general function segment bodies that have a significant effect after being replaced by index are replaced, while those general function segment bodies that do not have a significant effect after being replaced by index are not replaced, thus improving the flexibility of contract simplification.

[0261] In another embodiment, such as Figure 12 As shown, after step 720, the following may also be included:

[0262] 723. Obtain the usage frequency of the main body of the general function segment;

[0263] 724. Filter the main body of general function segments based on usage frequency.

[0264] In step 723, frequency of use is a measure of how often the body of a general function segment is used. Its calculation method is described in detail below. Understandably, if a general function segment is not frequently used, there is little need to replace the body of the general function segment with an index, as its probability of occurrence is low, and setting up a dedicated replacement step for it would increase subsequent computational overhead.

[0265] In step 724, in one embodiment, if the usage frequency is less than a predetermined frequency, it can be filtered out without proceeding to subsequent steps. In another embodiment, if the usage frequency ranks N places lower than the predetermined frequency, it can be filtered out without proceeding to subsequent steps, where N is a positive integer. In yet another embodiment, if the usage frequency of the general function segment body ranks N places lower than the predetermined frequency and is also less than the predetermined frequency, it can be filtered out. This is similar to the case in step 722, and therefore will not be described in detail.

[0266] The advantage of this embodiment is that the frequency of use of general function segments can be used as the basis for judging whether it is worthwhile to replace the main body of the general function segment. After filtering the main body of the general function segment according to the frequency of use, the main body of the general function segment that has a significant effect after being replaced by index is replaced, while the main body of the general function segment that does not have a significant effect after being replaced by index is not replaced, thereby improving the flexibility of contract simplification.

[0267] In another embodiment, such as Figure 13 As shown, after step 720, the following may also be included:

[0268] 725. Obtain the size of the general function segment body;

[0269] 726. Obtain the usage frequency of the main body of the general function segment;

[0270] 727. Filter the main body of general function segments based on size and frequency of use.

[0271] The following is a detailed description of steps 725-727 above.

[0272] Step 725 is similar to step 721, so it will not be described in detail.

[0273] Step 726 is similar to step 723, so it will not be described in detail.

[0274] In one embodiment, step 727 may include:

[0275] Determine the first fraction based on the size of the general function segment body;

[0276] The second score is determined based on the frequency of use of the main body of the general function segment;

[0277] Based on the first score and the second score, determine the total score of the general function segment body;

[0278] Based on the total score, filter the main body of the general function segment.

[0279] The first score indicates the degree to which the general function segment body is worth retaining, considering its size. If the general function segment body is large, replacing it with an index can significantly reduce storage resource consumption. Retaining the general function segment body and allowing it to participate in subsequent index replacement is highly recommended, resulting in a higher first score. Conversely, if the general function segment body is small, replacing it with an index reduces storage resource consumption less significantly. Retaining it and allowing it to participate in subsequent index replacement is less necessary and can be filtered out, resulting in a lower first score.

[0280] The first fraction can be determined based on the size of the general function segment, either by using a lookup table or a formula.

[0281] Table 4 shows the correspondence between the size range of the general function segment body and the first fraction.

[0282] Size range of the general function segment body First score 100 bytes 100 50-99 bytes 90 30-49 bytes 80 16-29 bytes 70 …… ……

[0283] Table 4

[0284] For example, the main body size of general function segment A is 35 bytes, and by looking up the table, the corresponding first score is 80.

[0285] When using the formula method, Formula 1 shows the formula for how the first fraction changes with the size of the general function segment:

[0286] S1=a·H Formula 1

[0287] In the above formula, S1 is the first fraction, H is the size of the general function segment, and a is a first coefficient representing the change of the first fraction with the size of the general function segment, for example, 0.6 / byte. If H is 50, then S1 = 30.

[0288] The second score represents the degree to which the general function segment body is worth retaining, based on its usage frequency. If the general function segment body is used frequently, replacing it with an index can result in a significant reduction in storage resource consumption. Retaining the general function segment body and allowing it to participate in subsequent index replacement is highly recommended, resulting in a higher first score. Conversely, if the general function segment body is used infrequently, replacing it with an index will have a less significant effect on reducing storage resource consumption. Retaining it and allowing it to participate in subsequent index replacement is less necessary and can be filtered out, resulting in a lower first score.

[0289] The second fraction is determined based on the frequency of use of the general function segment, or it can be determined using a lookup table or a formula. Since the method for determining the first fraction is similar, it will not be elaborated further.

[0290] Based on the first and second scores, the total score of the general function segment body is determined, which can be achieved using the sum, average, or weighted average method. When using the weighted average method, different weights are assigned to the first and second scores. These weights reflect the different impacts of the size and frequency of use of the general function segment body on its filtering. This provides greater flexibility in the filtering settings, allowing for adjustments to whether to replace the general function segment body with an index based on actual circumstances, thus improving the versatility of the scenario.

[0291] There are several ways to filter general function segments based on their total score. One approach retains general function segments with total scores above a predetermined threshold, while filtering out the rest. Another approach retains the top N general function segments by total score (ranked from highest to lowest), while filtering out the rest. Yet another approach retains general function segments with total scores ranking in the top N and exceeding a predetermined threshold, while filtering out the rest.

[0292] The advantage of steps 725-727 is that it allows for a comprehensive assessment of whether it is worthwhile to replace the general function segment based on its size and frequency of use, thus improving the accuracy of contract simplification.

[0293] The following section discusses in detail how to obtain the frequency of use.

[0294] In one embodiment, the frequency of use can be determined based on the first occurrence of the general function segment body in the target smart contract and the second occurrence of the general function segment body in the first smart contract deployment history of the target consensus node. Figure 14 As shown, step 723 includes:

[0295] 1410. Obtain the first occurrence count of the general function segment body in the target smart contract;

[0296] 1420. Obtain the second occurrence count of the general function segment body in the first smart contract deployment history of the target consensus node, where the target consensus node is the consensus node that deploys the target smart contract;

[0297] 1430. Determine the frequency of use based on the first and second occurrence counts.

[0298] The main consideration in this embodiment is that if a certain general function segment appears multiple times in the target smart contract, it proves that the general function segment is used frequently; otherwise, it would not appear multiple times in the same smart contract. This is considered from the perspective of a single contract. Additionally, it can also be considered from the perspective of a single consensus node. A consensus node has historically deployed many other smart contracts. If a certain general function segment is frequently used in the smart contracts historically deployed by the consensus node, it indicates that the general function segment has a high usage frequency, at least for that consensus node. By comprehensively considering both the perspectives of a single smart contract and a single consensus node, the resulting usage frequency reflects the results from multiple different perspectives, improving the accuracy of determining the usage frequency.

[0299] In step 1410, for a single target smart contract, it is necessary to determine the number of times the general function segment body appears in this target smart contract, i.e., the first occurrence count. The first occurrence count reflects the frequency of use of the general function segment body from the perspective of a single smart contract. For example, in smart contract A, the general function segment body divide() appears 3 times, and the first occurrence count of divide() is 3.

[0300] In step 1420, the target consensus node is the consensus node that deploys the target smart contract. The first smart contract deployment history refers to the record of all smart contracts historically deployed by the target consensus node. This is considered from the perspective of a single consensus node. For example, consensus node A has historically deployed three smart contracts H1-H3. In smart contract H1, the general function segment `divide()` appears 1 time. In smart contract H2, the general function segment `divide()` appears 5 times. In smart contract H3, the general function segment `divide()` appears 2 times. The second occurrence count is 1 + 5 + 2 = 8 times.

[0301] In step 1430, the frequency of use is determined based on the first occurrence count and the second occurrence count.

[0302] In one embodiment, the usage frequency can be obtained by adding the first occurrence count and the second occurrence count. The main consideration in this embodiment is that, from the perspective of a single smart contract, the greater the first occurrence count of the general function segment body, the greater the usage frequency should be. Similarly, from the perspective of a single consensus node, the greater the second occurrence count of the general function segment body, the greater the usage frequency should be. Therefore, adding the first and second occurrence counts to obtain the usage frequency is a simpler method and improves the efficiency of usage frequency determination.

[0303] In another embodiment, considering the different bases for the statistics of the first and second occurrences, the frequency of use is not simply summed. Instead, it is determined based on the ratio of the first occurrence to the total number of code segments in the target smart contract and the ratio of the second occurrence to the total number of code segments in the deployment history of the first smart contract. In this embodiment, step 1430 includes:

[0304] Get the first number of code segments in the target smart contract;

[0305] Based on the first occurrence count and the first number, the first usage sub-frequency is determined;

[0306] Obtain the second number of code segment bodies in the deployment history of the first smart contract;

[0307] The second usage frequency is determined based on the second occurrence frequency and the second number;

[0308] The usage frequency is determined based on the first and second usage sub-frequency.

[0309] The first number is the total number of code segment bodies in the target smart contract. The general function segment bodies considered in the first occurrence count are only a part of the code segment bodies in the target smart contract. Dividing the number of general function segment bodies by the total number of code segment bodies in the target smart contract gives the frequency of that general function segment body in the target smart contract, i.e., the first usage sub-frequency.

[0310] The second number is the total number of code segment bodies in the first smart contract deployment history. The general function segment bodies considered in the second occurrence count are only a part of the code segment bodies in the first smart contract deployment history. Dividing the number of general function segment bodies by the total number of code segment bodies contained in the first smart contract deployment history yields the frequency of the general function segment body appearing in the first smart contract deployment history, i.e., the second usage sub-frequency.

[0311] The frequency of use is determined based on the first and second usage sub-frequency, and there are multiple ways to implement this.

[0312] In one embodiment, the average of the first and second usage sub-frequency can be used as the usage frequency. In this embodiment, it is assumed that the dimensions of the smart contract and the first smart contract deployment history contribute equally to the determination of the usage frequency. For example, if the first usage sub-frequency is 80% and the second usage sub-frequency is 40%, the resulting usage frequency is (80% + 40%) / 2 = 60%. The advantage of this embodiment is its simplicity and low overhead.

[0313] In another embodiment, the weighted average of the first and second usage sub-frequencys can be used as the usage frequency. In this embodiment, different weights are assigned to the first and second usage sub-frequencys. This embodiment assumes that the dimensions of the smart contract and the first smart contract deployment history contribute unequally to the determination of the usage frequency. Therefore, this embodiment adapts to different practical needs by flexibly adjusting the weights assigned to the first and second usage sub-frequencys. For example, if the weight assigned to the first usage sub-frequency is 60% and the weight assigned to the second usage sub-frequency is 40%, the first usage sub-frequency is 80% and the second usage sub-frequency is 40%, resulting in a usage frequency of 80% × 60% + 40% × 40% = 64%. The advantage of this embodiment is its flexibility in adapting to various practical needs and its high calculation accuracy.

[0314] The advantage of the above embodiment of determining usage frequency based on the first usage sub-frequency and the second usage sub-frequency is that it fully considers the different bases for the statistics of the first occurrence and the second occurrence, thereby improving the objectivity and accuracy of the usage frequency determination.

[0315] In another embodiment, the frequency of use can be determined based on the first occurrence of the general function segment body in the target smart contract and the third occurrence of the general function segment body in the second smart contract deployment history of the consensus node network. For example... Figure 15 As shown, step 723 includes:

[0316] 1510. Obtain the first occurrence count of the general function segment body in the target smart contract;

[0317] 1520. Obtain the third occurrence of the general function segment body in the second smart contract deployment history of the consensus node network;

[0318] 1530. Determine the frequency of use based on the first and third occurrences.

[0319] Since steps 1510 and 1410 are the same, they will not be described again.

[0320] In step 1520, the second smart contract deployment history refers to the sum of all smart contract records deployed by each consensus node in the consensus network throughout history. This is considered from the perspective of all consensus nodes. For example, there is a consensus node AC in the consensus network. Consensus node A has historically deployed three smart contracts H1-H3. In smart contract H1, the general function segment body di vi de() appeared 1 time. In smart contract H2, the general function segment body di vi de() appeared 5 times. In smart contract H3, the general function segment body di vi de() appeared 2 times. Consensus node B has historically deployed one smart contract H4. In smart contract H4, the general function segment body di vi de() appeared 4 times. Consensus node C has historically deployed two smart contracts H5-H6. In smart contract H5, the general function segment body di vi de() appeared 2 times. In smart contract H6, the general function segment body di vi de() appeared 1 time. The third occurrence count is 1+5+2+4+2+1=15 times.

[0321] The determination of usage frequency in step 1530 based on the first and third occurrence counts is similar to the determination of usage frequency based on the first and second occurrence counts in step 1430, and can be implemented by referring to step 1430. To save space, it will not be described in detail again.

[0322] The advantage of this embodiment is that, since the first occurrence count reflects the frequency of use in a single contract dimension and the third occurrence count reflects the frequency of use in all consensus node dimensions, this determination method takes into account various perspectives and improves the accuracy of the frequency of use determination.

[0323] In another embodiment, the frequency of use can also be determined based on the second number of times the general function segment body appears in the first smart contract deployment history of the target consensus node and the third number of times the general function segment body appears in the second smart contract deployment history of the consensus node network. For example... Figure 16 As shown, step 723 includes:

[0324] 1610. Obtain the second occurrence count of the general function segment body in the first smart contract deployment history of the target consensus node, where the target consensus node is the consensus node that deploys the target smart contract;

[0325] 1620. Obtain the third occurrence of the general function segment body in the second smart contract deployment history of the consensus node network;

[0326] 1630. Determine the frequency of use based on the second and third occurrences.

[0327] Since steps 1610 and 1420 are the same, and steps 1620 and 1520 are the same, they will not be repeated here.

[0328] The determination of usage frequency in step 1630 based on the second and third occurrence counts is similar to the determination of usage frequency based on the first and second occurrence counts in step 1430, and can be implemented by referring to step 1430. To save space, it will not be described in detail again.

[0329] The advantage of this embodiment is that, since the second occurrence count reflects the usage frequency at the single consensus node dimension and the third occurrence count reflects the usage frequency at all consensus node dimensions, this determination method takes into account various perspectives and improves the accuracy of usage frequency determination.

[0330] In another embodiment, the frequency of use can also be determined based on the first number of times the general function segment subject appears in the target smart contract, the second number of times the general function segment subject appears in the first smart contract deployment history of the target consensus node, and the third number of times the general function segment subject appears in the second smart contract deployment history of the consensus node network.

[0331] In this embodiment, such as Figure 17 As shown, step 723 includes:

[0332] 1710. Obtain the first occurrence count of the general function segment body in the target smart contract;

[0333] 1720. Obtain the second occurrence count of the general function segment body in the first smart contract deployment history of the target consensus node, where the target consensus node is the consensus node that deploys the target smart contract;

[0334] 1730. Obtain the third occurrence of the general function segment body in the second smart contract deployment history of the consensus node network;

[0335] 1740. Determine the frequency of use based on the first occurrence count, the second occurrence count, and the third occurrence count.

[0336] Since steps 1710 and 1410 are the same, steps 1720 and 1420 are the same, and steps 1730 and 1520 are the same, they will not be repeated.

[0337] The determination of usage frequency in step 1740 based on the first occurrence count, the second occurrence count, and the third occurrence count is similar to the determination of usage frequency based on the first occurrence count and the second occurrence count in step 1430.

[0338] In one embodiment, such as Figure 18 As shown, step 1740 includes:

[0339] 1810. Obtain the first number of code segments in the target smart contract;

[0340] 1820. Based on the first occurrence frequency and the first number, determine the first usage sub-frequency;

[0341] 1830. Obtain the second number of code segment bodies in the deployment history of the first smart contract;

[0342] 1840. Based on the second occurrence frequency and the second number, determine the second usage sub-frequency;

[0343] 1850. Obtain the third number of code segments in the second smart contract deployment history;

[0344] 1860. Based on the number of times the third occurs and the number of third occurrences, determine the frequency of third usage.

[0345] 1870. Determine the usage frequency based on the first usage sub-frequency, the second usage sub-frequency, and the third usage sub-frequency.

[0346] Steps 1810-1840 are the same as the first four steps in step 1430 for determining the frequency of use based on the first and second occurrences, so they will not be repeated here.

[0347] In step 1850, the third number is the total number of code segment bodies in the second smart contract deployment history. The general function segment bodies considered in the third occurrence count are only a part of the code segment bodies in the second smart contract deployment history. In step 1860, dividing the number of general function segment bodies by the total number of code segment bodies contained in the second smart contract deployment history yields the frequency of the general function segment body appearing in the second smart contract deployment history, i.e., the third usage sub-frequency.

[0348] The method for determining the usage frequency based on the first usage sub-frequency, the second usage sub-frequency, and the third usage sub-frequency in step 1870 is similar to the method for determining the usage frequency based on the first usage sub-frequency and the second usage sub-frequency in the previous embodiment, so it will not be described in detail.

[0349] The advantage of this embodiment is that, since the first occurrence count reflects the frequency of use at the single contract dimension, the second occurrence count reflects the frequency of use at the single consensus node dimension, and the third occurrence count reflects the frequency of use at all consensus node dimensions, this determination method takes into account various perspectives and improves the accuracy of determining the frequency of use.

[0350] In another embodiment, it can be done as follows Figure 19 The method shown identifies the body of the general function segment. For example... Figure 19 As shown, step 720, identifying at least one general function segment body in the target smart contract may include:

[0351] 1910. In the target smart contract, identify at least one general function segment;

[0352] 1920. Extract the main body of the general function segment from the general function segment.

[0353] Steps 1910-1920 are described in detail below.

[0354] In step 1910, different smart contract parsing tools are first used to identify the main body of the candidate code segment. The parsing tool can be a mature smart contract analysis tool in the industry. For example, the array Func[] = Parse(FullCode) is used to identify the complete code of the candidate code segment, where Parse() is the parsing function of the smart contract analysis tool, and Func[] is the array obtained from the identification. The smart contract parsing tool can also be called a smart contract function recognizer.

[0355] In step 1920, the general function segment body is extracted from the general function segment.

[0356] As mentioned earlier, step 1920 can be executed using a general function segment library. The general function segment bodies in the library can be matched one by one with the target smart contract. If a part in the target smart contract is found that is completely identical to a general function segment body in the library, then it is determined that a general function segment body has been identified in the target smart contract.

[0357] Assume the generic function segment identified in the target smart contract is Func i = <FuncBody i >, Func i This represents the identified general function segment, FuncBody. i The general function segment is represented by , and 'i' represents the index. For example, assuming two general function segments are identified, Func[] can be represented as Func[Func1, Func2], where Func1 is the first general function segment, represented as Func1=<0xaabb…,val1>, and Func2 is the second general function segment, represented as Func2=<0xccdd…,val2>. 0xaabb… represents the general function segment body of the first general function segment, and 0xccdd… represents the general function segment body of the second general function segment.

[0358] The advantage of steps 1910-1920 is that it can identify general function segments according to preset standards, and the general function segments include the main body of the general function segments, which reduces the difficulty of identification and improves the identification efficiency of the main body of the general function segments.

[0359] In one embodiment, it is also considered that in addition to the general function segment body, the general function segment may also involve related variables, that is, the general function segment includes the general function segment body and general function segment variables, such as Figure 20 As shown, step 1920 may include:

[0360] 2010. The general function segment is divided into the general function segment body and the general function segment variables.

[0361] In step 2010, the general function segment body and general function segment variables are extracted from the general function segment. Each element in the array can be represented as: Func i = <FuncBody i FuncVal i >, Func i This represents the identified general function segment, FuncBody. i Represents the body of the general function segment, FuncVal i Indicates FuncBody iThe variables involved, i represents the index. For example, assuming two general function segments are identified, Func[] can be represented as Func[Func1, Func2], where Func1 is the first general function segment, which can be represented as Func1=<0xaabb…,val1>, where 0xaabb… represents the general function segment body of the first general function segment, and val1 represents the variables involved in the general function segment body 0xaabb….

[0362] The advantage of step 2010 is that it can divide the general function segment into the general function segment body and the general function segment variables according to the preset standard, and identify the general function segment body according to the division of the general function segment, thereby improving the accuracy of identification.

[0363] Function segments often employ nested structures; for example, a function segment may contain an inner function segment, as shown below:

[0364] search(A,B):

[0365] A:=xxxx, B:=xxx;

[0366] {xxxxxxxxxxxxxxxxxxx;

[0367] xxxxxxxxxxxxxxxxxxxxxx;

[0368] comp(C,D):

[0369] C:=xxxx, D:=xxx;

[0370] {xxxxxxxxxxxxxxxxxxx;

[0371] Xxxxxxxxxxxxxx}

[0372] ...

[0373] xxxxxxxxxxxxx}.

[0374] In the above structure, the function segment `search()` nests the function segment `comp()`. The body size of the function segment `search()` is clearly larger than the body size of the function segment `comp()`. `comp()` may also contain other nested function segments. Therefore, determining the level of the generic function segment body identified in the target smart contract in step 720 becomes a question.

[0375] In one embodiment, such as Figure 21 As shown, step 720 may include:

[0376] 2110. Obtain the storage capacity of the target consensus node for deploying the target smart contract;

[0377] 2120. Determine the main size of the general function segment based on storage capacity;

[0378] 2130. Based on the size of the general function segment body, identify at least one general function segment body in the target smart contract.

[0379] If the consensus node has limited storage capacity, there isn't much space left to store the blockchain. In this case, the smart contract needs to be significantly streamlined before being stored on the blockchain. Therefore, the main body of the defined general function segment will be relatively large (e.g., `search()` in the example above). Replacing it with an index will save considerable space. Conversely, if the consensus node has a large storage capacity, there is ample space available for storing the blockchain. In this case, there's no need to significantly streamline the smart contract. Therefore, the main body of the defined general function segment will be relatively small (e.g., `comp()` in the example above), and replacing it with an index won't save much space.

[0380] In one embodiment, step 2120 can be performed by looking up a table. For example, Table 5 below shows the relationship between storage capacity and the size of the general function segment body.

[0381] Storage capacity General function segment body size 10000Gbit or more 10 bytes 1000-10000Gbit 20 bytes 100-1000Gbit 50 bytes 10-100Gbit 200 bytes …… ……

[0382] Table 5

[0383] For example, the target consensus node has a storage capacity of 5000 Gbits, and the corresponding general function segment body size is 20 bytes. In the target smart contract, the size of the aforementioned general function segment body search() is 50 bytes, and the size of comp() is 20 bytes. Therefore, comp() is used as the identified general function segment body.

[0384] The advantage of steps 2110-2130 is that the size of the general function segment body can be set according to the storage capacity of the consensus node, and the general function segment body can be identified according to the size of the general function segment body. For consensus nodes with tight storage resources, it can be simplified more, and for consensus nodes with less tight storage resources, it can be simplified less, which improves the flexibility of simplification and reduces storage space while taking into account processing overhead.

[0385] Detailed description of step 730

[0386] In one embodiment, the generic function segment library contains multiple associated entries, each containing a generic function segment body and an index corresponding to the generic function segment body, such as... Figure 22As shown, step 730, using the general function segment library, may include determining the index corresponding to the general function segment body, which could include:

[0387] 2210. In the general function segment library, find the associated item that contains the general function segment body;

[0388] 2220. If a related item is found, the index in the found related item will be determined as the index corresponding to the general function segment body.

[0389] In steps 2210-2220, the searched related item can be either a row or a column. Table 1 above provides an example where the related item is a row. In the general function segment library of Table 1, the first related item has an index of 0 and a general function segment body of 0xaabb…. If the general function segment body identified in step 720 is exactly 0xaabb…, then the searched related item is the first related item, and its index 0 is used as the index determined in step 730.

[0390] For example, query the target function body FuncBody in the general function segment library. i The general function library is for a relational database, assuming it's a MySQL relational database. The query statement used by this MySQL relational database would be: Row = QUERY("SELECT?FID WHERE FBODY = FuncBody"). i Row represents the rows retrieved, and QUERY is the function that executes the query in MySQL. Inside QUERY is a MySQL statement, which returns the FID value of the row if it exists.

[0391] The advantage of steps 2210-2220 is that by storing the general function segment body and the index in different related items in a one-to-one correspondence, query efficiency is improved.

[0392] In one embodiment, such as Figure 23 As shown, after step 2210, the following may also be included:

[0393] 2230. If no related item is found, assign an index corresponding to the main body of the general function segment;

[0394] 2240. In the general function segment library, add associated items, including the general function segment body and the allocated index.

[0395] In steps 2230-2240, it is checked whether the target general function segment body exists in each associated item. If there is no associated item containing the target general function segment body, then a corresponding index should be allocated for the target general function segment body, and the target general function segment body and the corresponding index should be stored as associated items in the general function segment library.

[0396] For example, query the target function body FuncBody in the general function segment library. i The general function library is for a relational database, assuming it's a MySQL relational database. The query statement used by this MySQL relational database would be: Row = QUERY("SELECT?FID WHERE FBODY = FuncBody"). i Row represents the retrieved rows, and QUERY is the function that executes the query in MySQL. The QUERY contains a MySQL statement; if the query exists, it returns the value of its FID as the result set of Row. When the query result is empty, a related item needs to be inserted. In one embodiment, if the FID in the general function segment library is an auto-incrementing column, then when inserting a related item, an index FID is automatically assigned, and an insert statement is generated.

[0397] Row=QUERY(”INSERT? FBODY=FuncBody i "), indicating that the objective function body FuncBody will be... i Insert into the related item (row). The FID in the general function segment library is an auto-incrementing column, so it does not need to be specified in this insert. If it is not an auto-incrementing column, then the insert statement also needs to specify the allocated target index FID, which will not be elaborated here.

[0398] The advantage of steps 2230-2240 is that for general function segment bodies that do not exist in the general function segment library, corresponding indexes can be assigned and stored, thereby improving the efficiency of identifying and replacing general function segment bodies as the general function segment library is continuously improved during use.

[0399] In one embodiment, each consensus node in the consensus node network maintains its own general function segment library, such as... Figure 24 As shown, step 2240 may include:

[0400] 2410. Add related items to the general function segment library of the target consensus node. The added related items include the general function segment body and the assigned index.

[0401] When each consensus node in the consensus node network maintains its own general function segment library, each node can search for the index corresponding to the main body of a general function segment within its own library. Thus, when a consensus node identifies a general function segment main body that does not belong to its library, it can add a related entry, continuously improving its library. In this embodiment, since each consensus node maintains a different general function segment library, the simplified smart contract is personalized. Because each consensus node's general function segment library cannot be accessed by other consensus nodes, they cannot reconstruct the target smart contract from the simplified smart contract uploaded to the blockchain, improving the security of the uploaded smart contract. However, since each consensus node also maintains a target tree for verifying whether the target smart contract is securely uploaded to the blockchain, and when a consensus node sends the simplified smart contract to other consensus nodes for consensus, it also sends a contract digest to them, allowing other consensus nodes to verify whether the target smart contract is correctly uploaded to the blockchain based on the contract digest and the target tree, thus improving the verifiability of the target smart contract.

[0402] Detailed description of step 740

[0403] In step 740, the generic function segment body in the target smart contract is replaced with an index to obtain a simplified smart contract. By identifying and replacing functions in the smart contract code, identical smart contract code fragments that originally required redundant storage are replaced with indexes based on the generic function segment body, reducing the storage resources and costs consumed by the smart contract.

[0404] The generic function segments in the target smart contract constitute the smallest unit of code execution, and their reuse rate is high, resulting in significant storage space savings after replacement. For example, if the target smart contract contains n generic function segments, it can be represented as follows: <FID1,FID2,FID3,L,FID n > For each general function segment Func i = <FuncBody i FuncVal i The general function segment body in > is replaced with its index, resulting in the simplified array SmallFunc. i = <FID i FuncVal i Therefore, the simplified smart contract is composed of multiple simplified arrays, which can be represented as SmallCode = SmallFunc1:SmallFunc2:L:SmallFuncn, where Func is the number of arrays in the array. i This represents the identified general function segment, FuncBody. iRepresents the body of the general function segment, FuncVal i Indicates FuncBody i The variables involved are: i represents the index, the maximum value of i is n, and n is a positive integer.

[0405] In one embodiment, it is also considered that in addition to the general function segment body, the general function segment may also involve related variables, that is, the general function segment includes the general function segment body and general function segment variables, such as Figure 25 As shown, in step 740, the general function segment body in the target smart contract is replaced with an index to obtain a simplified smart contract, including:

[0406] 2510. Keep the general function segment variables in the general function segment unchanged, and replace the general function segment body in the general function segment with the index to obtain the simplified smart contract.

[0407] The advantage of step 2510 is that while replacing the corresponding general function segment body with the index, the general function segment variables corresponding to the replaced general function segment body remain unchanged. Since the general function segment variable part remains unchanged, and the general function segment variable part reflects the specific variable requirements in each scenario, the storage space used to store the general function segment is greatly reduced while maintaining adaptability to application scenarios.

[0408] Detailed description of step 750

[0409] In step 750, the simplified smart contract and contract digest are sent to other consensus nodes for consensus, so that the simplified smart contract can be stored on the target blockchain. The bottom nodes of the target tree are updated with the contract digest, and the security of the target smart contract is verified using the target tree. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level node until the root node is obtained.

[0410] The simplified smart contract and its contract digest can be sent to other consensus nodes simultaneously, or they can be sent separately. For example, after obtaining the contract digest of the target smart contract, the contract digest is immediately sent to other consensus nodes to update the contract digests stored in the underlying nodes of the target tree. After obtaining the simplified smart contract, it is then sent to other consensus nodes for consensus before being uploaded to the blockchain.

[0411] Because it takes time for other consensus nodes to update the target tree they maintain using the contract digest, receiving a verification request for the target smart contract during the update period will cause an error. Therefore, in the above embodiment, after obtaining the contract digest of the target smart contract, the contract digest is immediately sent to other consensus nodes, so that other consensus nodes have sufficient time to update the target tree and reduce the error caused by the target tree not being updated in time after receiving the verification request.

[0412] In one embodiment, such as Figure 26 As shown, updating the bottom-level nodes of the target tree with a contract summary can include:

[0413] 2610. Obtain the first address on the target blockchain where the simplified smart contract will be stored;

[0414] 2620. Map the first address to the identifier of the bottom-level node of the target tree;

[0415] 2630. Based on the contract summary, update the underlying node corresponding to the underlying node identifier.

[0416] In steps 2610-2630, it is necessary to determine the actual deployment address of the simplified smart contract on the blockchain, i.e., the first address. In one embodiment, the first address can be represented by the height of the block to which the simplified smart contract is deployed. In another embodiment, the first address can be represented by the digest of the block to which the simplified smart contract is deployed (such as the hash value in the block header of that block).

[0417] For example, let the first address be denoted as ADDR. Mapping the first address to the bottom-level node identifier of the target tree involves determining the corresponding bottom-level node (also called a leaf node) in the target tree, thus obtaining the bottom-level node identifier State[ADDR]. For instance, if blocks with heights of 20, 31, and 48 on the blockchain correspond to the first, second, and third bottom-level nodes of the target tree, respectively, then the first address 20 corresponds to index 1, the second address 31 corresponds to index 2, and the third address 48 corresponds to index 3. At this point, other consensus nodes receive a contract digest corresponding to a contract to be stored in block 58 on the blockchain. In this case, the fourth address 58 is assigned to index 4. Therefore, the contract digest is placed at the fourth node position at the bottom of the target tree. This is achieved through methods such as... Figure 5 The method shown generates a summary by generating a summary layer by layer upwards from two (or more) adjacent lower-level nodes, until the root node is generated.

[0418] The simplified smart contract to be deployed in the blockchain (consensus node network) is represented as SmallCode. The underlying node corresponding to the underlying node identifier is updated, that is, the contract digest is written to the node corresponding to the underlying node identifier of the target tree, represented as State[ADDR].Codehash = SHA256(FullCode), where FullCode represents the complete code of the target smart contract to be deployed in the blockchain. There are multiple ways to calculate the contract digest. This disclosure adopts the SHA256 algorithm, and the contract digest is represented as SHA256(FullCode). Codehash represents that the underlying node stores the code hash value. Other digest algorithms can also be used, such as SHA3-256, which is not limited here.

[0419] Writing the simplified smart contract to the first address on the target blockchain can be represented as: State[ADDR].Code = SmallCode, where Code indicates that the blockchain stores code. SmallCode represents the code of the simplified smart contract corresponding to the target smart contract to be deployed on the blockchain.

[0420] The advantage of steps 2610-2630 is that by mapping the first address to the bottom node identifier of the target tree, the bottom node of the target tree can be quickly updated with the contract digest, thereby improving the efficiency of verifying the on-chain security of the target smart contract.

[0421] In one embodiment, such as Figure 27 As shown, verifying the security of a target smart contract using a target tree can include:

[0422] 2710. Based on the updated underlying nodes, calculate the first contract digest corresponding to the root node of the target tree;

[0423] 2720. Obtain the second contract digest corresponding to the root node calculated by other consensus nodes;

[0424] 2730. If the first contract summary is consistent with the second contract summary, the target smart contract is deemed secure.

[0425] In steps 2710-2730, in order to ensure the security of the target smart contract uploaded to the chain, each consensus node maintains a target tree and performs layer-by-layer calculations on the target tree in a bottom-up order. The first contract digest of the root node calculated by the target consensus node is compared with the second contract digest of the root node calculated by other consensus nodes. If they match, it means that the target smart contract is securely uploaded to the chain.

[0426] The advantage of steps 2710-2730 is that, while reducing storage space usage, the verifiability of the target smart contract being securely uploaded to the blockchain is maintained.

[0427] In one embodiment, each consensus node in the consensus node network maintains its own general function segment library, such as... Figure 28 As shown, after step 750, the following may also be included:

[0428] 760. Periodically send the general function segment library of the target consensus node to other consensus nodes so that other consensus nodes can respond to the scheduling request for the target smart contract, use the general function segment library of the target consensus node to restore the simplified smart contract on the target blockchain to the target smart contract, and execute the target smart contract.

[0429] Because each consensus node maintains its own general function segment library, and each node maintains a different library, other consensus nodes cannot reconstruct the simplified smart contract into the target smart contract without access to that node's library. In step 760, by periodically sending the target consensus node's general function segment library to other consensus nodes, these nodes obtain the library and can then reconstruct the simplified smart contract into the target smart contract. This allows the target smart contract to be executed on various consensus nodes, not just the target node, thus expanding the scope of smart contract usage.

[0430] Example of a method for invoking a blockchain smart contract

[0431] According to one embodiment of this disclosure, a method for invoking a blockchain smart contract is provided.

[0432] The blockchain smart contract invocation method of this disclosure embodiment can be executed by a consensus node.

[0433] like Figure 29 As shown, a blockchain smart contract invocation method according to an embodiment of this disclosure includes:

[0434] 2910. Receive a scheduling request for the target smart contract, the scheduling request having a first address on the target blockchain;

[0435] 2920. Based on the first address, obtain the simplified smart contract on the target blockchain;

[0436] 2930. Identify the indexes in the simplified smart contract;

[0437] 2940. In the general function segment library, obtain the general function segment body corresponding to the index;

[0438] 2950. Replace the indexes in the simplified smart contract with the general function segment body to obtain the target smart contract;

[0439] 2960. Execute the target smart contract.

[0440] In step 2910, a scheduling request is a request to schedule the target smart contract to execute related processes. For example, for an e-invoice smart contract, a scheduling request could be an e-invoice reimbursement request. When an e-invoice is reimbursed, the consensus node needs to execute the reimbursement-related processing and then upload the reimbursement result to the blockchain after reaching consensus with other consensus nodes. During the execution of the reimbursement-related processing, the e-invoice smart contract is invoked, generating a scheduling request.

[0441] The scheduling request has a first address on the target blockchain. The scheduling request carries a first address, which stores the simplified smart contract that can be scheduled. The scheduling request can be represented as: Call =<FROM,?TO,INPUT> In this context, Call represents the call instruction, FROM represents the sender of the call instruction, TO represents the address of the code to be called (i.e., the first address), and INPUT represents the input content used to modify the scheduled smart contract accordingly.

[0442] In step 2920, the simplified smart contract stored in the blockchain is retrieved based on the first address from the previous step. The process of retrieving the simplified smart contract can be represented as SmallCode' = State[Call.To].Code, where Call.To represents the actual storage address of the simplified smart contract, i.e., the first address, and SmallCode' represents the downloaded simplified smart contract.

[0443] In step 2930, the downloaded simplified smart contract SmallCode' is traversed to determine the downloaded simplified smart contract SmallCode' =<FID1,FuncVal1> :<FID2,FuncVal2> :L: <FID n FuncVal n any general function segment <FID i FuncVal i The index FID in > i Multiple indexes are obtained. <FID1,FID2,FID3,…,FID n >

[0444] In step 2940, based on the above index <FID1,FID2,FID3,…,FID n In the general function segment library, query each index FID. i The corresponding general function segment body FIDi For example, to query a relational database (e.g., MySQL) within a general function segment library, the query statement would be: Row = QUERY("SELECT ? FBODY WHERE FID = FID"). i Row represents the rows retrieved, QUERY is the function that executes the query in MySQL, and QUERY contains the MySQL statement. If the query exists, it returns the body of the target function segment, FuncBody. i As the result set of Row.

[0445] In step 2950, ​​the FuncBody of each queried objective function segment is used. i Replace the indexes in the simplified smart contract to obtain the target smart contract. The restored target smart contract can be represented as: FullCode' = <funcbody1> : <funcbody2>:L: <FuncBody n >, where 'FullCode' represents the restored target smart contract.

[0446] In steps 2910-2960 above, a scheduling request for the target smart contract is received, and the scheduling request has a first address on the target blockchain; based on the first address, the simplified smart contract on the target blockchain is obtained; the index in the simplified smart contract is identified; in the general function segment library, the general function segment body corresponding to the index is obtained; the index in the simplified smart contract is replaced with the general function segment body to obtain the target smart contract; and the target smart contract is executed. The transformation process from the simplified smart contract to the target smart contract is as follows: Figure 30 As shown. The advantage of steps 2910-2960 is that the simplified smart contract code can be restored to the complete code and the smart contract can be executed, ensuring the usability of the simplified smart contract, that is, maintaining the same usability as traditional blockchain smart contracts. This solves the problem that it is difficult to restore the original smart contract code and call it after the smart contract is divided into different storage fragments by function, thus improving usability.

[0447] In one embodiment, such as Figure 31 As shown, the scheduling request also includes the variable values ​​of general function segment variables. Step 2930, identifying the indexes in the simplified smart contract, may include:

[0448] 3110. Identify the indices and corresponding generic function segment variables in the simplified smart contract.

[0449] For example, the downloaded simplified smart contract is:

[0450] SmallCode'=<FID1,FuncVal1> :<FID2,FuncVal2> :L: <FID n FuncVal n >, where FID i

[0451] That is, the index, FuncVal i That is, the index FID i The corresponding general function segment variable, i represents the index, and the maximum value of i is n, where n is a positive integer. The advantage of step 3110 is that it also identifies and stores the general function variables corresponding to the main body of each general function segment, thus avoiding confusion during synthesis.

[0452] In one embodiment, such as Figure 32 As shown, the scheduling request also includes the variable values ​​of the general function segment variables. In step 2950, ​​the indexes in the simplified smart contract are replaced with the general function segment body to obtain the target smart contract, which may include:

[0453] 3210. Replace the index in the simplified smart contract with the general function segment body, and combine the general function segment body and the general function segment variable corresponding to the index to form a general function segment;

[0454] 3220. Use general function segments to synthesize the target smart contract.

[0455] For example, replacing the index in the simplified smart contract with the general function segment body results in multiple replaced general function segments, since the general function segment includes both the general function segment body and the general function segment variable corresponding to the index.<FuncBody1,FuncVal1> ,<FuncBody2,FuncVal2> , ..., <FuncBody n FuncVal n The target smart contract FullCode' synthesized in sequence is: FullCode' =<FuncBody1,FuncVal1> :<FuncBody2,FuncVal2> :L: <FuncBody n FuncVal n The advantage of steps 3210-3220 is that the positions of the general function variables corresponding to the main body of each general function segment remain unchanged, ensuring the accuracy of restoration during the call.

[0456] In one embodiment, such as Figure 31 As shown, the scheduling request also includes the variable values ​​of general function segment variables. Step 2960, executing the target smart contract may include:

[0457] 3120. Substitute the variable values ​​into the general function segment variables to run the general function segment body, thereby executing the target smart contract.

[0458] The advantage of step 3120 is that when executing the target smart contract, each general function segment variable is substituted into the corresponding general function segment body. Since the general function segment variables reflecting the specific situation of each application scenario are separate from the general function segment body, it ensures the universality of various application scenarios while correctly executing the general function segment.

[0459] Description of apparatus and devices according to embodiments of this disclosure

[0460] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0461] It should be noted that in the various specific embodiments of this disclosure, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when this application embodiment needs to obtain target object attribute information, separate permission or consent from the target object will be obtained through pop-up windows or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of this application embodiment be obtained.

[0462] Reference Figure 33 , Figure 33 This is a schematic diagram of the structure of the blockchain smart contract deployment device 3300 provided in this embodiment of the disclosure. The blockchain smart contract deployment device 3300 includes:

[0463] The first acquisition unit 3310 is used to acquire the contract summary of the target smart contract;

[0464] The identification unit 3320 is used to identify at least one general function segment body in the target smart contract;

[0465] The determining unit 3330 is used to determine the index corresponding to the general function segment body using the general function segment library;

[0466] Replacement unit 3340 is used to replace the general function segment body in the target smart contract with the index to obtain a simplified smart contract;

[0467] The first processing unit 3350 is used to send the simplified smart contract and the contract digest to other consensus nodes for consensus, so as to store the simplified smart contract on the target blockchain, update the bottom nodes of the target tree with the contract digest, and use the target tree to verify the security of the target smart contract. The bottom nodes of the target tree store the contract digests of each smart contract to be uploaded to the target blockchain. Each non-bottom node of the target tree further calculates the digest of the concatenation result of the contract digests of the next lower level nodes until the root node is obtained.

[0468] Optionally, the identification unit 3320 is specifically used for:

[0469] In the target smart contract, candidate code segment bodies are identified, and the first semantics of the candidate code segment bodies are obtained;

[0470] Obtain the second semantics of the general function segment body in the general function segment library;

[0471] If the first semantic is the same as the second semantic of a general function segment body in the general function segment library, the candidate code segment body is determined as the identified general function segment body.

[0472] Optionally, the identification unit 3320 is specifically used for:

[0473] Extract the first keyword from the main body of the candidate code segment;

[0474] Extract the second keyword of each general function segment body from the general function segment body in the general function segment library;

[0475] The general function segment body that matches the second keyword with the first keyword is identified as the matching general function segment body;

[0476] Obtain the second semantics of the matching general function segment body in the general function segment library.

[0477] Optionally, the blockchain smart contract deployment device further includes:

[0478] The second acquisition unit 3360 (not shown) is used to acquire the size of the general function segment body;

[0479] The third acquisition unit 3370 (not shown) is used to acquire the usage frequency of the general function segment body;

[0480] Filtering unit 3380 (not shown) is used to filter the general function segment body based on the size and the frequency of use.

[0481] Optionally, the third acquisition unit 3370 is specifically used for:

[0482] Obtain the first occurrence count of the general function segment body in the target smart contract;

[0483] Obtain the second occurrence count of the general function segment body in the first smart contract deployment history of the target consensus node, where the target consensus node is the consensus node that deploys the target smart contract;

[0484] Obtain the third occurrence count of the general function segment body in the second smart contract deployment history of the consensus node network;

[0485] The frequency of use is determined based on the first occurrence count, the second occurrence count, and the third occurrence count.

[0486] Optionally, the third acquisition unit 3370 is specifically used for:

[0487] Obtain the first number of code segments in the target smart contract;

[0488] Based on the first occurrence count and the first number, the first usage sub-frequency is determined;

[0489] Obtain the second number of code segment bodies in the deployment history of the first smart contract;

[0490] Based on the second occurrence frequency and the second number, the second usage sub-frequency is determined;

[0491] Obtain the third number of code segments in the deployment history of the second smart contract;

[0492] Based on the third occurrence frequency and the third number, the third usage sub-frequency is determined;

[0493] The usage frequency is determined based on the first usage sub-frequency, the second usage sub-frequency, and the third usage sub-frequency.

[0494] Optionally, the identification unit 3320 is specifically used for:

[0495] In the target smart contract, identify at least one general function segment;

[0496] Extract the main body of the general function segment from the general function segment.

[0497] Optionally, the general function segment includes the general function segment body and general function segment variables;

[0498] The identification unit 3320 is specifically used for:

[0499] The general function segment is divided into the general function segment body and the general function segment variables;

[0500] The replacement unit 3340 is specifically used for:

[0501] Keeping the general function segment variables in the general function segment unchanged, and replacing the general function segment body in the general function segment with the index, the simplified smart contract is obtained.

[0502] Optionally, the general function segment library contains multiple associated items, each of which contains a general function segment body and an index corresponding to the general function segment body;

[0503] The determining unit 3330 is specifically used for:

[0504] In the general function segment library, search for the associated item that contains the main body of the general function segment;

[0505] If the associated item is found, the index in the found associated item is determined as the index corresponding to the general function segment body.

[0506] Optionally, the determining unit 3330 is specifically used for:

[0507] If the associated item is not found, assign the index corresponding to the main body of the general function segment;

[0508] In the general function segment library, the associated item is added, wherein the added associated item includes the general function segment body and the assigned index.

[0509] Optionally, each consensus node in the consensus node network maintains its own general function segment library;

[0510] The determining unit 3330 is specifically used for:

[0511] Add the associated item to the general function segment library of the target consensus node.

[0512] Optionally, the blockchain smart contract deployment device further includes:

[0513] The second sending unit 3390 (not shown) is used to periodically send the general function segment library of the target consensus node to other consensus nodes, so that the other consensus nodes can respond to the scheduling request for the target smart contract, use the general function segment library of the target consensus node to restore the simplified smart contract on the target blockchain to the target smart contract, and execute the target smart contract.

[0514] Optionally, the first processing unit 3350 is specifically used for:

[0515] Obtain the first address on the target blockchain for storing the simplified smart contract;

[0516] Map the first address to the bottom-level node identifier of the target tree;

[0517] Based on the contract summary, update the underlying node corresponding to the underlying node identifier.

[0518] Optionally, the first processing unit 3350 is specifically used for:

[0519] Based on the updated underlying nodes, calculate the first contract digest corresponding to the root node of the target tree;

[0520] Obtain the second contract digest corresponding to the root node calculated by the other consensus nodes;

[0521] If the first contract digest matches the second contract digest, the target smart contract is determined to be secure.

[0522] Optionally, the identification unit 3320 is specifically used for:

[0523] Obtain the storage capacity of the target consensus node where the target smart contract is deployed;

[0524] Based on the storage capacity, determine the size of the general function segment body;

[0525] Based on the size of the general function segment body, at least one general function segment body is identified in the target smart contract.

[0526] Reference Figure 34 , Figure 34 This is a schematic diagram of the structure of the blockchain smart contract invocation device 3400 provided in this embodiment of the disclosure. The blockchain smart contract invocation device 3400 includes:

[0527] The receiving unit 3410 is used to receive a scheduling request for a target smart contract, the scheduling request having a first address on the target blockchain;

[0528] The first acquisition unit 3420 is used to acquire the simplified smart contract on the target blockchain based on the first address;

[0529] Identification unit 3430 is used to identify indexes in the simplified smart contract;

[0530] The second acquisition unit 3440 is used to acquire the general function segment body corresponding to the index in the general function segment library;

[0531] Replacement unit 3450 is used to replace the index in the simplified smart contract with the general function segment body to obtain the target smart contract;

[0532] Execution unit 3460 is used to execute the target smart contract.

[0533] Optionally, the scheduling request may also include the variable values ​​of general function segment variables;

[0534] The identification unit 3430 is specifically used for:

[0535] Identify the index in the simplified smart contract and the general function segment variable corresponding to the index;

[0536] The execution unit 3460 is specifically used for:

[0537] The variable value is substituted into the general function segment variable to run the general function segment body, thereby executing the target smart contract.

[0538] Optionally, the replacement unit 3450 is specifically used for:

[0539] The index in the simplified smart contract is replaced by the general function segment body, and the general function segment body and the general function segment variable corresponding to the index are combined to form the general function segment;

[0540] The target smart contract is synthesized using the general function segment.

[0541] Reference Figure 35 , Figure 35 A structural block diagram of a consensus node for implementing the blockchain smart contract deployment or invocation method of this disclosure. Figure 35 In this diagram, consensus node 110 is represented as server 110. Server 110 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 3622 (e.g., one or more processors) and memory 3632, and one or more storage media 3630 (e.g., one or more mass storage devices) for storing applications 3642 or data 3644. The memory 3632 and storage media 3630 can be temporary or persistent storage. The program stored in storage media 3630 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on server 3600. Furthermore, the CPU 3622 may be configured to communicate with storage media 3630 and execute the series of instruction operations in storage media 3630 on server 3600.

[0542] Server 110 may also include one or more power supplies 3626, one or more wired or wireless network interfaces 3650, one or more input / output interfaces 3658, and / or one or more operating systems 3641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0543] The processor in server 110 can be used to execute the blockchain smart contract deployment method or the blockchain smart contract invocation method of the present disclosure embodiments.

[0544] This disclosure also provides a computer-readable storage medium for storing program code, which is used to execute the blockchain smart contract deployment method or invocation method of the foregoing embodiments.

[0545] This disclosure also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain smart contract deployment method or invocation method described above.

[0546] The terms "first," "second," "third," "fourth," etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "including," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0547] It should be understood that in this disclosure, "at least one item" refers to one or more, and "more than one" refers to two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0548] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0549] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0550] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0551] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0552] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0553] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0554] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure. < / funcbody1>

Claims

1. A blockchain smart contract deployment method, characterized in that, The method comprises the following steps: obtaining a contract digest of a target smart contract; identifying at least one general function segment subject in the target smart contract; determining an index corresponding to the general function segment subject by using the general function segment library; replacing the general function segment subject in the target smart contract with the index to obtain a simplified smart contract; sending the simplified smart contract and the contract digest to other consensus nodes for consensus, so as to store the simplified smart contract on a target blockchain, update a bottom node of a target tree with the contract digest, and verify the safety of the target smart contract by using the target tree, wherein the bottom node of the target tree stores contract digests of smart contracts to be chained to the target blockchain, and each non-bottom node of the target tree further calculates a digest of a cascaded result of contract digests of connected lower nodes until a root node is obtained. 2.The method of claim 1, wherein, The method comprises the following steps: identifying a candidate code segment subject in the target smart contract and obtaining a first semantic of the candidate code segment subject; obtaining a second semantic of the general function segment subject in the general function segment library; if the first semantic is the same as the second semantic of one general function segment subject in the general function segment library, determining the candidate code segment subject as the identified general function segment subject. 3.The method of claim 2, wherein, The method comprises the following steps: extracting a first keyword from the candidate code segment subject; extracting a second keyword of each general function segment subject from each general function segment subject in the general function segment library; determining the general function segment subject matching the second keyword and the first keyword as a matching general function segment subject; obtaining a second semantic of the matching general function segment subject in the general function segment library. 4.The method of claim 1, wherein, After identifying at least one general function segment subject in the target smart contract, the method further comprises the following steps: obtaining a size of the general function segment subject; obtaining a usage frequency of the general function segment subject; filtering the general function segment subject based on the size and the usage frequency. 5.The method of claim 4, wherein, The method comprises the following steps: obtaining a first occurrence number of the general function segment subject in the target smart contract; obtaining a second occurrence number of the general function segment subject in a first smart contract deployment history record of a target consensus node, the target consensus node being a consensus node for deploying the target smart contract; obtaining a third occurrence number of the general function segment subject in a second smart contract deployment history record of a consensus node network; determining the usage frequency based on the first occurrence number, the second occurrence number and the third occurrence number. 6.The method of claim 5, wherein, The method comprises the following steps: obtaining a first number of code segment subjects in the target smart contract; determine a first usage sub-frequency based on the first occurrence number and the first number; obtain a second number of code segment subjects in the first smart contract deployment history record; determine a second usage sub-frequency based on the second occurrence number and the second number; obtain a third number of code segment subjects in the second smart contract deployment history record; determine a third usage sub-frequency based on the third occurrence number and the third number; determine the usage frequency based on the first usage sub-frequency, the second usage sub-frequency, and the third usage sub-frequency. 7.The method of claim 1, wherein, The at least one general function segment subject is identified in the target smart contract, including: At least one general function segment is identified in the target smart contract. The general function segment subject is extracted from the general function segment. 8.The method of claim 7, wherein, The general function segment contains the general function segment subject and a general function segment variable; The general function segment subject is extracted from the general function segment, including dividing the general function segment into the general function segment subject and the general function segment variable; The general function segment subject in the target smart contract is replaced with the index to obtain a simplified smart contract, including keeping the general function segment variable in the general function segment unchanged, and replacing the general function segment subject in the general function segment with the index to obtain the simplified smart contract. 9.The method of claim 1, wherein, The general function segment library contains a plurality of association items, and each association item contains a general function segment subject and an index corresponding to the general function segment subject; The index corresponding to the general function segment subject is determined by using the general function segment library, including: The association item containing the general function segment subject is searched in the general function segment library; If the association item is found, the index in the found association item is determined as the index corresponding to the general function segment subject. 10.The method of claim 9, wherein, After searching for the association item containing the general function segment subject in the general function segment library, the blockchain smart contract deployment method further includes: If the association item is not found, an index corresponding to the general function segment subject is allocated; The association item is added in the general function segment library, wherein the added association item includes the general function segment subject and the allocated index. 11.The method of claim 10, wherein, Each consensus node in the consensus node network respectively maintains a general function segment library; The association item is added in the general function segment library, including adding the association item in the general function segment library of a target consensus node.

12. The method of claim 1, wherein, The bottom layer node of the target tree is updated with the contract summary, including: obtaining a first address for storing the simplified smart contract to a target blockchain; mapping the first address to a bottom layer node identifier of the target tree; updating the bottom layer node corresponding to the bottom layer node identifier based on the contract summary. 13.A method for invoking a blockchain smart contract, characterized in that, including: receiving a scheduling request for a target smart contract, the scheduling request having a first address on a target blockchain; obtaining a simplified smart contract on the target blockchain based on the first address; identifying an index in the simplified smart contract; In the universal function segment library, a universal function segment body corresponding to the index is obtained; The target smart contract is obtained by replacing the index in the simplified smart contract with the universal function segment body; The target smart contract is executed. 14.The method of claim 13, wherein, The scheduling request further includes a variable value of a universal function segment variable; The index in the simplified smart contract is identified, including identifying the index in the simplified smart contract and the universal function segment variable corresponding to the index; The target smart contract is executed, including substituting the variable value into the universal function segment variable to run the universal function segment body, thereby executing the target smart contract. 15.The method of claim 14, wherein, The target smart contract is obtained by replacing the index in the simplified smart contract with the universal function segment body, including: The target smart contract is obtained by replacing the index in the simplified smart contract with the universal function segment body, including: The target smart contract is obtained by replacing the index in the simplified smart contract with the universal function segment body, including: 16.A blockchain smart contract deployment apparatus characterized by comprising: A first obtaining unit is configured to obtain a contract digest of a target smart contract; An identifying unit is configured to identify at least one universal function segment body in the target smart contract; A determining unit is configured to determine an index corresponding to the universal function segment body by using the universal function segment library; A replacing unit is configured to replace the universal function segment body in the target smart contract with the index to obtain a simplified smart contract; A first processing unit is configured to send the simplified smart contract and the contract digest to other consensus nodes for consensus, so as to store the simplified smart contract on a target blockchain, update a bottom node of a target tree with the contract digest, and verify the safety of the target smart contract by using the target tree, wherein the bottom node of the target tree stores contract digests of smart contracts to be chained to the target blockchain, and each non-bottom node of the target tree further calculates a digest of a concatenation result of contract digests of connected lower nodes until a root node is obtained. A receiving unit is configured to receive a scheduling request for a target smart contract, the scheduling request having a first address on a target blockchain; 17.A blockchain smart contract calling apparatus, characterized in that, A first obtaining unit is configured to obtain a simplified smart contract on the target blockchain based on the first address; An identifying unit is configured to identify an index in the simplified smart contract; A second obtaining unit is configured to obtain a universal function segment body corresponding to the index in a universal function segment library; A replacing unit is configured to replace the index in the simplified smart contract with the universal function segment body to obtain the target smart contract; An executing unit is configured to execute the target smart contract. The processor executes the computer program to implement the blockchain smart contract deployment method of any one of claims 1 to 12, or the blockchain smart contract calling method of any one of claims 13 to 15. ​ 18. An electronic device, comprising a memory and a processor, the memory storing a computer program, characterized in that, ​ 19. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement the blockchain smart contract deployment method in any one of claims 1 to 12, or the blockchain smart contract calling method in any one of claims 13 to 15.

20. A computer program product comprising a computer program, characterized in that, The computer program is read and executed by a processor of a computer device, so that the computer device executes the blockchain smart contract deployment method in any one of claims 1 to 12, or the blockchain smart contract calling method in any one of claims 13 to 15.

Images