CN114201116A

CN114201116A - Intelligent contract deployment method, device, equipment, medium and program product

Info

Publication number: CN114201116A
Application number: CN202111553143.1A
Authority: CN
Inventors: 毛嘉宇; 范瑞彬; 张开翔; 张龙; 储雨知; 王越
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2021-12-17
Filing date: 2021-12-17
Publication date: 2022-03-18
Anticipated expiration: 2041-12-17

Abstract

The application provides an intelligent contract deployment method, an intelligent contract deployment device, equipment, media and a program product, wherein a contract deployment request comprising a contract bytecode corresponding to an intelligent contract is obtained; segmenting the contract byte code according to each functional attribute contained in the contract byte code so as to determine each code block and the connection sequence of each code block; and inquiring whether each code block exists in a storage medium of the block chain node, and storing the code blocks which are not stored and the connection sequence into the storage medium, so that when the intelligent contract is called, the contract byte codes can be restored from each code block stored in the storage medium according to the connection sequence, and further the intelligent contract is inquired and/or executed. The method solves the technical problem that the storage space of the blockchain node is seriously occupied when the intelligent contracts of the same content or similar contents are repeatedly deployed in the prior art. The method achieves the technical effects of improving the reuse rate of the intelligent contract codes and saving the storage space of the block chain link points.

Description

Intelligent contract deployment method, device, equipment, medium and program product

Technical Field

The present application relates to the field of financial technology (Fintech), and in particular, to a method, apparatus, device, medium, and program product for intelligent contract deployment.

Background

With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually shifting to financial technology (Fintech). The application of the block chain technology in the field of financial technology is also gradually popularized.

At present, a block chain node generally uses an intelligent contract to complete a transaction request initiated by a client, and in order to speed up transaction processing efficiency of the block chain node, the intelligent contract with the same content or only a few parameters different is often repeatedly deployed on the block chain node for many times. And each time the intelligent contract is deployed, the code corresponding to the intelligent contract is stored on the block chain node, which seriously occupies the storage space of the block chain node, so that the efficiency of data processing such as storage, query and the like of the block chain node is reduced.

Namely, the technical problem that the storage space of the blockchain node is seriously occupied when the intelligent contracts with the same content or similar contents are repeatedly deployed exists in the prior art.

Disclosure of Invention

The application provides an intelligent contract deployment method, an intelligent contract deployment device, equipment, media and a program product, which are used for solving the technical problem that the storage space of a block chain node is seriously occupied when intelligent contracts with the same content or similar content are repeatedly deployed in the prior art.

In a first aspect, the present application provides an intelligent contract deployment method, including:

acquiring a contract deployment request, wherein the contract deployment request comprises: the contract byte code that intelligent contract corresponds, the contract byte code includes: when the intelligent contract is called, the binary code is inquired and/or executed by the block chain virtual machine;

segmenting the contract byte code according to each functional attribute contained in the contract byte code to determine each code block and the connection sequence of each code block, wherein each code block corresponds to at least one functional attribute;

and inquiring whether each code block exists in a storage medium of the block chain node, and storing the code blocks which are not stored and the connection sequence into the storage medium, so that when the intelligent contract is called, the contract byte codes can be restored from each code block stored in the storage medium according to the connection sequence, and further the intelligent contract is inquired and/or executed.

In one possible design, the code block includes: a head code block, a tail code block, and at least one functional or default configuration code block;

the head code block is used for performing memory allocation on a virtual machine, and the virtual machine corresponds to the intelligent contract;

the tail code block includes meta-information of the intelligent contract, the meta-information including: the intelligent contract compiling method comprises the steps of switch identification of experiment attributes and verification fingerprint information, wherein the switch identification is used for representing a compiling mode of a compiler for an intelligent contract;

the function or default constructor code block includes at least one function or default constructor corresponding to each operation code, and the function or default constructor is used for characterizing the logic function or default constructor of the intelligent contract.

In one possible design, slicing the contract bytecode according to the functional attributes included in the contract bytecode to determine the code blocks and the connection order of the code blocks, including:

according to a first code corresponding to the memory allocation instruction, a header code block is divided from the contract byte code, and the header code block is deleted from the contract byte code to determine a first contract byte code;

traversing the first contract byte code, determining a section of code meeting any one identification rule in the identification rule set as a tail code block, and deleting the tail code block from the first contract byte code to determine a second contract byte code;

and according to a second code corresponding to the function selection instruction, segmenting the second contract byte code into at least one function or default construction code block.

In one possible design, the splitting the second contract bytecode into at least one functional or default configuration code block according to a second encoding corresponding to the function-optional instruction includes:

removing the defined part of the constructor in the second contract bytecode to determine a third contract bytecode, and converting the third contract bytecode into an assembly operation code;

grouping the assembly operation codes according to preset grouping codes to determine an operation code group set consisting of a plurality of operation code groups;

dividing the operation code group set into a plurality of operation code fragments according to the calling codes of the functions or the default constructors, wherein each operation code fragment comprises at least one operation code group;

and reducing each operation code fragment into each fourth contract byte code, and determining the fourth contract byte code as a function or default construction code block.

In one possible design, partitioning the opcode group set into a plurality of opcode tiles according to a function or default constructor call encoding includes:

if the operation code group contains the calling code of the function or the default structure function, the operation code group is used as a single operation code fragment;

groups of adjacent opcodes that do not contain a call code are combined into a single opcode tile.

In one possible design, querying a storage medium of a blockchain node whether each code block exists already, and storing the code blocks which are not stored and the connection order in the storage medium includes:

comparing each code block with each original code block stored in a storage medium to screen out one or more target code blocks different from the original code blocks from each code block;

and storing the target code block into a contract code linked list of the storage medium according to the connection sequence and a preset storage mode.

In one possible design, storing the target code block in a contract code linked list of the storage medium according to the connection order and a preset storage mode includes:

calculating a hash value of the target code block;

combining the hash value and the corresponding code block into a key value pair;

the key-value pairs are stored in a contract code linked list according to the connection order.

In a second aspect, the present application provides an intelligent contract deployment apparatus, comprising:

the acquisition module is used for acquiring a contract deployment request, and the contract deployment request comprises: the contract byte code that intelligent contract corresponds, the contract byte code includes: when the intelligent contract is called, the binary code is inquired and/or executed by the block chain virtual machine;

a processing module to:

In a third aspect, the present application provides an electronic device comprising:

a memory for storing program instructions;

and the processor is used for calling and executing the program instructions in the memory to execute any one of the possible intelligent contract deployment methods provided by the first aspect.

In a fourth aspect, the present application provides a storage medium, where a computer program is stored in the storage medium, where the computer program is used to execute any one of the possible intelligent contract deployment methods provided in the first aspect.

In a fifth aspect, the present application further provides a computer program product comprising a computer program that, when executed by a processor, implements any one of the possible intelligent contract deployment methods provided by the first aspect.

The application provides an intelligent contract deployment method, an intelligent contract deployment device, equipment, media and a program product, wherein a contract deployment request comprising a contract bytecode corresponding to an intelligent contract is obtained; segmenting the contract byte code according to each functional attribute contained in the contract byte code to determine each code block and the connection sequence of each code block; and inquiring whether each code block exists in a storage medium of the block chain node, and storing the code blocks which are not stored and the connection sequence into the storage medium, so that when the intelligent contract is called, the contract byte codes can be restored from each code block stored in the storage medium according to the connection sequence, and further the intelligent contract is inquired and/or executed. The method solves the technical problem that the storage space of the blockchain node is seriously occupied when the intelligent contracts of the same content or similar contents are repeatedly deployed in the prior art. The method achieves the technical effects of improving the reuse rate of the intelligent contract codes and saving the storage space of the block chain link points.

Drawings

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

Fig. 1 is a schematic view of an application scenario of an intelligent contract deployment method according to an embodiment of the present application;

fig. 2 is a schematic flow chart of an intelligent contract deployment method provided in the present application;

FIG. 3 is a schematic flow chart diagram illustrating another intelligent contract deployment method provided in the practice of the present application;

fig. 4 is a schematic structural diagram of an intelligent contract deployment apparatus according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of an electronic device provided in the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, including but not limited to combinations of embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any inventive step are within the scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The following explanations are made for terms to which this application refers:

bytecode (Binary): a Solidity contract compiler compiles the complete bytecode result to a Solidity smart contract. The bytecode is similar to an assembly instruction. The intelligent contract defines a complete set of instructions and these binary byte codes are the set of virtual machine EVM instructions. The bytecode includes two parts: initialization (Creation Code) and runtime (contract bytecode).

Contract Bytecode (Runtime byte): the contract runtime bytecode is stored on the blockchain when the contract is deployed, and can be queried and executed through the blockchain virtual machine when the contract is invoked. Where the contract bytecode is typically a substring of the contract run binary code described above.

Deployment binary (deployment binary): and the binary code of the deployment contract comprises information such as contract constructor instructions and global variables.

It should be noted that the bytecode generally includes contract bytecode and deployment binary code.

Application Binary Interface definition (ABI for ABI): an application program interface for identifying which functions are provided by the contract for external calls.

Operation code (OPCODE) OPCODE is a low-level readable instruction of an intelligent contract program. All opcodes have corresponding hexadecimal values, e.g., in the identity smart contract language, "MSTORE" is "0 x52," SSTORE "is" 0x55, "and so on. The specific opcode value may be referenced to the identity correlation data.

A blockchain, such as a federation chain, is a machine that executes as a state through an EVM (Embedded Virtual machine) Virtual machine in the execution of an existing blockchain intelligent contract. The input is binary instructions compiled by the intelligent contract language solid and state data of the block chain nodes, and the output is the change of the point state of the block chain nodes.

In a traditional intelligent contract engine, contracts are deployed and executed in the following ways:

contract deployment process:

1. and the client side compiles the intelligent contract to obtain a binary byte code. The client fills the bytecode into the transaction and attaches initialization parameters. The client sends the transaction to the blockchain node.

The parameters of a transaction include:

from: the encoded transaction sender.

To: the transaction sends a contract address.

Input: passing binary code for virtual machine only, based on abi information encoding calling functions and parameters

Transaction signature: and the caller signs the transaction result so as to verify the validity of the transaction by the block chain common node.

Transaction version number: the type and version number of the transaction. The version number of the blockchain transaction protocol is labeled.

Trade HASH. HASH is computed over the transaction code.

If the destination parameter to is null, the transaction is a deployment transaction. To distinguish between different transactions, a nonce value must be appended to the transaction. The different transaction nonce values may be accumulated to distinguish between repeated transactions.

2. And verifying the signature, the validity and the like of the transaction by the block chain nodes, then packaging the transaction, and performing consensus.

3. Each node of the block chain network executes the "default binary" part of the bytecode.

And each node of the block chain network calculates the address of the new contract and returns the address to the client. Creating a contract address using the following calculation: keccak (RLP (call _ addr, nonce)) [12: ]. That is, RLP () encoding is performed on the address and nonce of the transaction initiator, and then a Keccak hash value is calculated, and the last 20 bytes are taken as the address of the contract.

Each node of the block chain creates a corresponding stateObject according to the contract address, and then stores the contract code included in the transaction. Each node of the blockchain network stores the "contract bytecode" portion of the bytecode locally, i.e., the data code portion of the graph. The code cannot be changed once stored. All state changes of the contract are stored in a storage trie and finally stored in a stateDB state database in a form of Key-Value, namely Key-Value pairs. The content in the storage trie can be modified by calling the contract. This is followed by the parameters that need to be provided to invoke the function, which is of variable length.

Contract function call flow:

1. and the client encapsulates information such as an address, a target function, an execution parameter and the like of a contract to be called and sends the information to the blockchain node. Wherein the sent objective function and the execution parameters are encapsulated into the input field. The first 4 bytes are called "4-byte signature" and are the first 4 bytes of the Keccak hash value signed by a function, which serves as the unique identifier of the function.

If the execution request modifies the node state, the block chain link points are commonly known, otherwise, the common knowledge is not needed.

2. The block chain node loads corresponding codes from the stateDB according to the contract address based on the function to be called, namely the 'contract byte code' corresponding to the contract address, and then the corresponding codes can be sent to the interpreter for execution.

In the "contract bytecode" part code, a code block of the objective function is matched. The matching process comprises the following steps: and sending the 4-byte function signature to the input from the client, and comparing the analyzed 4-byte function signature with the function signature contained in the contract byte code one by one.

3. And each node of the block chain network returns the return value of the code block to the client.

Through the analysis of the steps, the fact that in the prior art, once the intelligent contracts are deployed on the chain, the binary codes of the intelligent contracts are solidified and are difficult to modify and edit is found, and the intelligent contracts cannot be updated and upgraded.

As can be seen from the above procedure of contract deployment and invocation, the existing intelligent contracts have the following problems:

there is a lot of waste of blockchain storage space

In existing solutions, blockchain intelligent contract code would be saved onto the chain. Even if a plurality of identical blockchain intelligent contracts are deployed, contract codes of the contracts are saved on a chain after each deployment. If N identical intelligent contracts are deployed, the binary byte codes of the contracts are saved on the block chain by N, and thus, the waste of storage resources is serious.

In practice, however, it is a very common scenario that the same blockchain intelligence is deployed in large numbers around the chain. For example, in a common scenario of a federation chain, a typical implementation is as follows: a certified contract is written. Each deposit certificate of the user is re-linked in a contract-deploying mode, namely the contract structure and the code of each deposit certificate are the same, and only specific variables are different. As described in the previous section, each node of the blockchain network stores the "contract bytecode" portion of the bytecode locally, i.e., the data code portion of the graph. The code cannot be changed once stored. All the state changes of the contract are stored in a storage trie and finally stored in a stateDB in a form of Key-Value.

This is equivalent to every time there is a new credit of judicial data added, based on the blockchain consensus algorithm and stored to the design, the code of the intelligent contract needs to be re-uploaded, consensus and stored on all nodes of the blockchain network. The contract byte code part of each judicial data certificate is the same, and the difference is the state of different certificates. Thus, this machine is made very wasteful, greatly reducing the efficiency of blockchain storage.

Furthermore, on blockchains, there are a large number of intelligent contracts of highly similar code structure, content, etc. For example, in smart contracts, new contracts may be written based on historical contracts being extended, inherited, modified, and so on. Similarly, a situation may arise where the "contract bytecode" portion described above is highly similar. In the present situation, the contract bytecode is stored repeatedly and independently regardless of the similarity of the contract bytecode.

From the perspective of the existing business practice, a large amount of redundant and highly similar contents exist in the Code field of StateObject stored in the blockchain, so that the capacity performance of the blockchain is greatly reduced, and the execution and processing efficiency of the blockchain is slowed down.

There is a lot of waste of blockchain network bandwidth

Since the blockchain contract requires to upload the bytecode from the chain to the chain in many links such as deployment, calling, and updating, the full amount of the intelligent contract binary code needs to be copied and transmitted each time, and thus a large amount of traffic is consumed each time the blockchain contract is confirmed by the blockchain consensus algorithm. This would cause a huge waste of blockchain network traffic.

In order to solve the above problems, the inventive concept of the present application is:

first, the technical characteristics of the existing block chain determine that optimized storage cannot be performed on a single block link point. Because the blockchain network has the distributed characteristic, the storage of a certain node is independently modified, and the overall data and result of the blockchain cannot be changed. Therefore, the results of smart contract deployment cannot be achieved by modifying the storage of only one node. The codes and parameters of the intelligent contract are subject to multi-party consensus and witness of all nodes of the block chain network, block chain data are stored in a block chain mode, and the block data comprise data of a parent block, so that the intelligent contract has the characteristic of being not falsifiable. The input of the intelligent contract voice solid is a binary instruction compiled by intelligent contract voice solid and state data of a block chain node, the output is the change of the point state of the block chain node, and the final output result is stored on a block chain network.

Second, the currently generally used technical approach is to index and store according to a single contract. For example, a hash of the "contract bytecode" of the storage contract is saved, and the hash and this piece of code are stored on the chain. If only one hash is uploaded the next time the same contract is deployed, the previously saved code can be directly obtained from the chain based on the hash.

However, there is a significant problem with doing so. That is, the contract is compiled under different intelligent contract versions, compiler software versions and environments, and the generated contract byte codes are slightly different. Then the hash it computed must also be different. This renders the present approach unusable. Furthermore, this solution does not solve the problem of storage non-multiplexing between highly similar contracts.

Finally, a further technical idea is to slice the "contract bytecode" of the blockchain intelligent contract. But the idea still has the design difficulty of the slicing algorithm. For example, how to compute the hash of a slice, and index and store the slice as a base dimension. However, it is difficult to determine the accuracy of the slicing in this way. If the fragmentation is too thin, the storage index is inefficient to store, and the search for the recall or recovery of the contract bytecode is too long. The most extreme mode is byte granularity, which undoubtedly greatly increases the task amount of block link point operation and reduces the efficiency of program operation. If the fragmentation is too coarse, it also results in wasted blockchain storage. The most extreme way is to divide the wafer into 1 wafer, which is equivalent to the non-wafer in the prior art, and the defects are still existed.

Therefore, the method and the device adopt a strategy of carrying out fragmentation according to the logic function or the default structure function in the intelligent contract, and independently divide each function or the default structure function into one code block, so that the granularity of the fragmentation not only meets the requirement of multiplexing the intelligent contract codes, but also meets the requirement of the processing efficiency of the subsequent reduction contract byte codes. After the same intelligent contract code is deployed, only one code is deployed on the chain, and the storage space on the block chain is greatly saved. Meanwhile, the method and the device can also save bandwidth resources of the network of the block chain.

In summary, the intelligent contract deployment method provided by the application can improve the operation efficiency of block chain link point storage and a network system, and effectively improve the performance of a block chain network.

The following specifically explains the intelligent contract deployment method provided by the present application:

fig. 1 is a schematic view of an application scenario of an intelligent contract deployment method provided by the present application. As shown in fig. 1, a contract byte code 100 obtained after an intelligent contract is compiled is partitioned according to a preset partitioning manner to obtain a plurality of code blocks 101 with different sizes, hash values of the code blocks 101 are calculated, the hash values are connected to form a hash value linked list, and the hash value linked list is stored in a storage medium 103 of a block link node in a key value pair form (code block hash value, code block). In this way, each time the block link point calls the intelligent contract, the corresponding code block is taken out from the storage medium 103, and the round contract bytecode 100 is spliced and restored, so that the intelligent contract can be viewed and/or executed. And when the intelligent contract is updated, the contract byte code of the new intelligent contract is segmented in the same way, whether the obtained hash value of each code block 101 is consistent with the hash value of the code block 101 stored in the storage medium 103 is compared, if so, the two are proved to be the same, repeated storage is not needed, if not, the code block is proved to be required to be stored, or the code block 101 stored in the storage medium 103 is replaced by the code block 101 according to the corresponding connection sequence of each code block 101, namely the position of the code block 101 in the contract byte 100, or the original intelligent contract is updated by inserting the new code block 101 into the data linked list in an extended form, so that the new intelligent contract is obtained. Thus, the code of the multiplexing intelligent contract is realized, and the utilization rate of the storage space of the storage medium 103 of the blockchain node is improved.

The specific implementation flow of the intelligent contract deployment method provided by the application is as follows:

fig. 2 is a schematic flowchart of an intelligent contract deployment method according to an embodiment of the present application. As shown in fig. 2, the specific steps of the intelligent contract deployment method include:

s201, acquiring a contract deployment request.

In this step, the contract deployment request includes: the contract byte code that intelligent contract corresponds, the contract byte code includes: and when the intelligent contract is called, the binary code is inquired and/or executed by the block chain virtual machine.

In this embodiment, the contract bytecode includes a binary code obtained by compiling the source code of the intelligent contract by a compiler. The essence of the blockchain node invoking the intelligent contract is that these binaries are queried and/or executed by the blockchain virtual machine.

S202, segmenting the contract byte code according to the function attributes contained in the contract byte code to determine the code blocks and the connection sequence of the code blocks.

In this step, each code block corresponds to at least one functional attribute.

In this embodiment, the code block includes: a head code block, a tail code block, and at least one functional or default configuration code block; the head code block is used for performing memory allocation on a virtual machine, and the virtual machine corresponds to the intelligent contract; the tail code block includes meta-information of the intelligent contract, the meta-information including: the intelligent contract compiling method comprises the steps of switch identification of experiment attributes and verification fingerprint information, wherein the switch identification is used for representing a compiling mode of a compiler for an intelligent contract; the function or default constructor code block includes at least one function or default constructor corresponding to each operation code, and the function or default constructor is used for characterizing the logic function or default constructor of the intelligent contract.

It can be understood that, a part of a general contract bytecode at the beginning generally corresponds to an instruction of virtual machine memory allocation, and a part of the tail generally corresponds to a definition part of a characteristic attribute of the intelligent contract, for example, an experimental attribute is opened or closed, for a compiler, different compiling modes are adopted, so that a difference occurs in an end part of the obtained binary code, that is, the contract bytecode, and the verification fingerprint information includes verification compilation hash information and a length of the verification information stored in the end part, and a digital signature of a deployer of the intelligent contract can be placed in the verification fingerprint information, thereby facilitating subsequent query or verification.

It should be noted that the tail part, i.e., the tail code block, may obtain different binary codes due to different intelligent contract versions or different compilers, but since the versions of the intelligent contract are limited, the type of the compiler may also be known in advance, so that an identification rule set for the tail code block may be set, and the binary codes corresponding to all tail code blocks are stored in the identification rule set in an enumeration mapping manner in advance, so that the tail code block may be identified only by traversing the contract byte codes to perform a fast comparison.

Therefore, in this step, specifically, the head code block and the tail code block may be identified first, and then the binary codes corresponding to the two in the contract bytecode are deleted, and the remaining contract bytecode is each instruction corresponding to each function logic corresponding to the intelligent contract execution logic. Therefore, the function or default construction code block corresponding to each functional logic step can be respectively identified only according to the function corresponding to the logic function or default construction function or the identification corresponding to the default construction function.

Different from the conventional method for segmenting codes by fixed size in other fields, the embodiment of the application segments each logic function or default structure function in the intelligent contract, so that the code blocks obtained after segmentation correspond to the functions or default structure functions one by one, and the problem that the codes corresponding to the same function are divided into two code blocks by fixed size segmentation is avoided. Because the splitting mode in the prior art is not suitable for splitting the intelligent contract, the code blocks which do not need to be updated or replaced originally can be influenced by other changes because the code blocks do not correspond to the function or the default constructor, and even if the code blocks are changed into the code blocks which need to be updated and replaced, the significance of multiplexing the contract byte codes of the intelligent contract is lost.

According to the method and the device, the problem can be well solved according to the function splitting mode, the code blocks correspond to the function attributes, and therefore when the intelligent contract is updated, only the corresponding code blocks need to be updated without replacing or storing a plurality of unchanged code blocks, the code reuse rate maximization of the contract byte codes of the intelligent contract is achieved, and the storage space of the block chain nodes is saved.

S203, inquiring whether each code block exists in the storage medium of the block chain node, and storing the code blocks which are not stored and the connection sequence in the storage medium.

In this step, each code block used for composing the contract bytecode is stored in the storage medium of the block chain node, and when the intelligent contract needs to be called at the block chain node, the contract bytecode can be restored by directly using the code blocks and the connection order corresponding to the code blocks, and then the contract bytecode is executed, so that the query and/or execution of the intelligent contract can be realized. When the intelligent contract is called, the block link points can restore the contract byte codes from each code block stored in the storage medium according to the connection sequence, and further realize the query and/or the execution of the intelligent contract.

Specifically, the contract deployment request can be divided into three cases: firstly, a brand-new intelligent contract is newly deployed, the intelligent contract can be used as a template of other intelligent contracts and is also called as a parent contract, and under the condition, contract byte codes corresponding to all the parent contracts need to be stored in block link points; secondly, updating a sub-contract formed by partial parameters in the parent contract, and under the condition, only some code blocks need to be replaced or some code blocks are inserted or deleted to obtain a new intelligent contract; thirdly, all code blocks of the contract bytecode corresponding to the intelligent contract to be deployed are stored in the block chain node, and the contract bytecode can be obtained by recovering only by extracting the code blocks from the storage medium and connecting the code blocks according to the connection order obtained in the step S202.

Compared with the prior art, the method has the advantages that the corresponding contract byte codes are repeatedly stored in the block link points every time the intelligent contracts are deployed, and a large amount of storage space is occupied. By the intelligent contract deployment method provided by the embodiment of the application, the code blocks with commonality can be multiplexed, only the code blocks containing new parameters need to be updated and replaced, and then the contract byte codes corresponding to the new intelligent contracts are obtained through reverse reduction, so that the storage space of the block chain nodes can be greatly saved, and the processing efficiency of inquiring data by the block chain nodes is improved.

The embodiment of the application provides an intelligent contract deployment method, which comprises the steps of obtaining a contract deployment request containing contract byte codes corresponding to an intelligent contract; segmenting the contract byte code according to each functional attribute contained in the contract byte code to determine each code block and the connection sequence of each code block; and inquiring whether each code block exists in a storage medium of the block chain node, and storing the code blocks which are not stored and the connection sequence into the storage medium, so that when the intelligent contract is called, the contract byte codes can be restored from each code block stored in the storage medium according to the connection sequence, and further the intelligent contract is inquired and/or executed. The method solves the technical problem that the storage space of the blockchain node is seriously occupied when the intelligent contracts of the same content or similar contents are repeatedly deployed in the prior art. The method achieves the technical effects of improving the reuse rate of the intelligent contract codes and saving the storage space of the block chain link points.

Fig. 3 is a schematic flow chart of another intelligent contract deployment method provided in the present application. As shown in fig. 3, the specific steps of the intelligent contract deployment method include:

s301, acquiring a contract deployment request.

Specifically, when the contract deployment request is to deploy a completely new intelligent contract, i.e., a parent contract:

the client generates and sends a contract deployment request to the blockchain nodes, wherein the contract deployment request comprises: and deploying a brand-new binary run code data of the intelligent contract, namely contract byte codes.

The deployer packages the transaction and attaches a plurality of field data, including: block header, transaction list, signature, etc. Wherein, the detailed information of each transaction is defined in the transaction list.

Then, each node in the block chain network verifies the deployer signature and the manager signature, analyzes the transaction message, packages the transaction, and performs consensus.

Next, each node in the blockchain network parses the transaction content, acquires and parses the contract bytecode, analyzes the structural content thereof, parses the code of the contract, and divides the intelligent contract according to the algorithm defined below, divides a code file into an ordered set of a plurality of code segments (i.e., code blocks), the ordered set including a plurality of code blocks and the connection order of each code block. Namely, steps S302 to S307 are executed.

When the contract deployment request is to upgrade or extend a parent contract:

the client compiles the source code corresponding to the new intelligent contract to obtain the corresponding contract byte code, and then the client passes through S302-S307. And then comparing the obtained code block with the code blocks in the block chain node and stored code blocks, finding out the target code block which is not stored, and sending the target code block to the block chain node for storage. Optionally, after receiving the target code block, that is, the connection order corresponding to the intelligent contract, the block link point performs secondary inspection on the target code block, because the client determines whether the target code block exists, the block link point may have been updated, so that secondary inspection needs to be performed on the block link node, and if the target code block is not stored by any block link point, the target code block is stored in the state storage medium and is subjected to consensus broadcast.

In one possible design, the client may also send the contract bytecode to the blockchain node, and the blockchain node performs S302 to S307.

S302, according to the first code corresponding to the memory allocation instruction, a header code block is divided from the contract byte code, and the header code block is deleted from the contract byte code to determine the first contract byte code.

In this step, the part of the contract bytecode that allocates the memory is identified and extracted as a first fragment, which is denoted as P0, and is deleted from the contract bytecode to obtain a first contract bytecode.

It should be noted that the first partition of the contract bytecode includes an instruction of memory allocation of the intelligent contract virtual machine. In general, in a fixed contract version, the instructions are the same, or the memory allocation instructions correspond to the contract version.

In this embodiment, assume that the contract bytecode is:

60806040526201093260005534801561001757600080fd5b5060405160208061012f83398101806040528101908080519060200190929190505050806000819055505060df806100506000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063cdcd77c0146044575b600080fd5b348015604f57600080fd5b50607e600480360381019080803563ffffffff1690602001909291908035151590602001909291905050506098565b604051808215151515815260200191505060405180910390f35b600060208363ffffffff16118060ab5750815b9050929150505600a165 627a7a72305820e869662d188a28b3dbe4b7c9e54bc031fa8f4cbe6d9b2dc600ffd4d01bc759 d60029。

suppose the corresponding P0 is 6080604052, i.e., P0 corresponds to 6080604052 binary code of a memory allocation instruction. Then the first contract bytecode is:

6201093260005534801561001757600080fd5b5060405160208061012f83398101806040528101908080519060200190929190505050806000819055505060df806100506000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063cdcd77c0146044575b600080fd5b348015604f57600080fd5b50607e600480360381019080803563ffffffff1690602001909291908035151590602001909291905050506098565b604051808215151515815260200191505060405180910390f35b600060208363ffffffff16118060ab5750815b9050929150505600a165627a7a7230 5820e869662d188a28b3dbe4b7c9e54bc031fa8f4cbe6d9b2dc600ffd4d01bc759d60029。

s303, traversing the first contract byte code, determining a section of code meeting any one identification rule in the identification rule set as a tail code block, and deleting the tail code block from the first contract byte code to determine a second contract byte code.

In this step, the last slice of the contract bytecode is identified and extracted, denoted as PL, and deleted from the bytecode. In the contract bytecode, the last part is meta-information of the contract bytecode: and defining whether the contract starts the experiment attribute, the stored verification compiling hash information, the verification information length and the like.

However, in different environments, i.e. in different versions of compiled software and whether to turn on the experimental properties, etc., the lengths and rules are different. However, the software version is limited due to the smart contracts. Each particular version may establish deterministic identification rules. To this end, we can identify the last fragment with a particular version, establish a set of identification rules, and preset a store of enumeration mappings to traverse the identification of the last fragment. Assuming that the intelligent contract has released n software versions in total, the number of recognition rule sets is less than or equal to n x 2.

Taking the first contract bytecode as an example, the experiment attribute is not opened, and the specific solidity compiled version is V0.4.25, and the corresponding "a 165" represents that the experiment attribute is not opened, so the ending part is identified as:

a165627a7a72305820e869662d188a28b3dbe4b7c9e54bc031fa8f4cbe6d9b2dc600ffd4d01bc759d60029。

dividing the code into tail code blocks, and deleting the tail code blocks from the first contract byte code to obtain a second contract byte code:

6201093260005534801561001757600080fd5b5060405160208061012f83398101806040528101908080519060200190929190505050806000819055505060df806100506000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063cdcd77c0146044575b600080fd5b348015604f57600080fd5b50607e600480360381019080803563ffffffff1690602001909291908035151590602001909291905050506098565b604051808215151515815260200191505060405180910390f35b600060208363ffffffff16118060ab5750815b9050929150505600。

s304, removing the defined part of the constructor in the second contract bytecode to determine a third contract bytecode, and converting the third contract bytecode into an assembly operation code.

In the present embodiment, assuming that the identification of the defined part of the constructor is the binary code '6004' corresponding to the Opcode "PUSH 10 x 4", an identification rule is set: in the second contract bytecode, in order to find the position of the binary code '6004' corresponding to the first Opcode "PUSH 10 x 4", and remove the previous part, the third contract bytecode is obtained:

60043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063cdcd77c0146044575b600080fd5b348015604f57600080fd5b50607e600480360381019080803563ffffffff1690602001909291908035151590602001909291905050506098565b604051808215151515815260200191505060405180910390f35b600060208363ffffffff16118060ab5750815b9050929150505600。

the third contract bytecode is then converted into an Opcode. I.e. the binary bytecode according to the intelligent contract is translated into opcode. For example, 60 corresponds to push1, and e0 represents the parameters carried by push 1. The assembly operation code obtained after the third contract bytecode conversion is:

PUSH1 0x4 CALLDATASIZE LT PUSH1 0x3F JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCDCD77C0 EQ PUSH1 0x44 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH1 0x4F JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x7E PUSH1 0x4 DUP1 CALLDATASIZE SUB DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD PUSH4 0xFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 DUP1 CALLDATALOAD ISZERO ISZERO SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP PUSH1 0x98 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x0 PUSH1 0x20 DUP4 PUSH4 0xFFFFFFFF AND GT DUP1 PUSH1 0xAB JUMPI POP DUP2 JUMPDEST SWAP1 POP SWAP3 SWAP2 POP POP JUMP STOP。

s305, grouping the assembly operation codes according to preset grouping codes so as to determine an operation code group set consisting of a plurality of operation code groups.

In this embodiment, opcodes are grouped according to JUMPDEST as an operator, i.e., a preset group code.

The opcodes in the above example can be partitioned into the following 7 sets according to JUMPDEST:

1、PUSH1 0x4 CALLDATASIZE LT PUSH1 0x3F JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCDCD77C0 EQ PUSH10x44 JUMPI

2、PUSH1 0x0 DUP1 REVERT

3、CALLVALUE DUP1 ISZERO PUSH1 0x4F JUMPI PUSH1 0x0 DUP1 REVERT

4、POP PUSH1 0x7E PUSH1 0x4 DUP1 CALLDATASIZE SUB DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD PUSH4 0xFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 DUP1 CALLDATALOAD ISZERO ISZERO SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP PUSH1 0x98 JUMP

5、PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN

6、PUSH1 0x0 PUSH1 0x20 DUP4 PUSH4 0xFFFFFFFF AND GT DUP1 PUSH1 0xAB JUMPI POP DUP2

7、SWAP1 POP SWAP3 SWAP2 POP POP JUMP STOP

the meanings of the corresponding code fragments are respectively as follows:

1. and detecting whether the function calling parameter is legal or not, and providing a function hash jump address.

2. No abnormal jump operation of the function is detected.

3. Function header entry initialization detection code is assigned according to the parameter call.

4. And a function baz operation part.

5. And a function baz operation part.

6. The function baz state operates the part.

7. The function baz returns to the operation section.

S306, the operation code group set is divided into a plurality of operation code fragments according to the calling codes of the functions or the default constructors, and each operation code fragment comprises at least one operation code group.

In this step, if the operation code group contains the calling code of the function or default constructor, the operation code group is taken as a single operation code segment; groups of adjacent opcodes that do not contain a call code are combined into a single opcode tile.

In this embodiment, for each set of Opcode operation codes, it is determined whether there is an EQ present therein and the value followed by the corresponding next PUSH1 instruction is fetched. If there are multiple EQs, then the values followed by multiple PUSH1 instructions are fetched. The sets of opcodes described above may be sliced based on the value of the following.

For example, in this embodiment, if there is an EQ in the first set of opcodes and the value following the corresponding PUSH1 command is 0X44, it indicates that there is a function or default constructor, and the following 2 nd to 7 th sets of opcodes can be divided into two independent opcode fragments based on 0X 44. For example, the example code described above may be divided into three opcode fragments: i.e. the first group is a first opcode fragment, the second group is a second opcode fragment and the 3 rd to 7 th groups are third opcode fragments.

It should be noted that, a person skilled in the art may set a specific fragmentation rule according to an actual scene need, and this embodiment is merely an exemplary introduction, and is not limited to the unique fragmentation manner.

S307, each operation code fragment is restored into each fourth contract byte code, and the fourth contract byte code is determined as a function or default construction code block.

In this embodiment, the corresponding Opcode fragments are reduced to corresponding contract bytecodes, which can be recorded as ordered sets R. Typically, R contains a number of code blocks equal to the number of functions or default constructors +2, and a contract will have at least one function or default constructor. If two functions or default constructors are defined in the contract bytecode, a total of 4 slices can be divided.

In the present embodiment, the set R is { Line1, Line2, Line3 }.

Line1：

60043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063cdcd77c0146044575b

Line 2：

600080fd

Line 3：

5b348015604f57600080fd5b50607e600480360381019080803563ffffffff1690602001909291908035151590602001909291905050506098565b604051808215151515815260200191505060405180910390f35b600060208363ffffffff16118060ab5750815b9050929150505600

Finally, we get 5 code blocks, which are: { P0, Line1, Line2, Line3, PL }.

And S308, comparing each code block with each original code block stored in the storage medium to screen one or more target code blocks different from the original code block from each code block.

And S309, storing the target code block into a contract code linked list in the storage medium according to the connection sequence and the preset storage mode.

The method specifically comprises the following steps: calculating a hash value of the target code block; combining the hash value and the corresponding code block into a key value pair; the key-value pairs are stored in a contract code linked list according to the connection order.

In this embodiment, for steps S308 and S309, when all code blocks obtained after splitting of one intelligent contract do not find the same original code block in the storage medium of the block chain node, the hash of each code block is calculated. In the above example, there are 5 code blocks, which are denoted as (c1, c2, c3, c4, c5), and the hash data calculated are (h1, h2, h3, h4, h5), respectively. This code segment is stored into a contract code linked list under the contract account. For example, the code block is stored in the stateDB state database of the blockchain as a key-value pair of (code block Hash, code block). E.g., (h1, c1) are stored in the underlying storage of blockchain nodes as key-value pairs. The grouped code blocks are hash organized into a linked list and are connected with each other. For example, the intelligent contract stores code data as a linked list, which stores values of h1 → h2 → h3 → h4 → h 5.

It should be noted that the code key value pairs related to the block chain are stored in a database of storage media such as StateDB of the block link point in a KV key value pair data structure. The stored key value is the hash value of the code segment, and the stored value is the specific code segment. During the storing, if the corresponding hash value already exists, the storing is skipped.

And finally, completing tray falling of each block link point and returning a result. And (3) storing the byte codes, namely contract byte codes, of each node in the running process into each block chain node, and returning the storage address corresponding to the intelligent contract to the client.

When only part of the code blocks cut out from the new intelligent contract are target code blocks, the code blocks of the new intelligent contract are assumed to be represented by ordered sets (c1, c2, c3, c7, c6 and c5), and the corresponding code hash sets are represented by (h1, h2, h3, h7, h6 and h 5).

And the block chain client acquires the code hash set structure of the original contract from the chain and compares the difference of the code hash set of the original contract on the chain.

From the above example, the new code structure is increased by h7 and h6 compared to the original code, i.e. the corresponding code is increased by c7 and c 6.

When the old contract needs to be upgraded, the block chain client transmits parameters of the upgrade contract, the address of the upgraded original contract, and a new compiled incremental binary byte code segment and the hash thereof. The blockchain node signs the signature of the original contract deployer and sends the signed signature to the blockchain network node.

Firstly, in order to control the contract modification authority, when the block chain client side upgrades the contract, the original contract deployer signature needs to be completed and assigned to the uplink transaction field.

After the completion, the block chain client side is subjected to parameter transmission on the deployed byte codes and the original contract addresses.

For example, in the example, the new code structure, i.e., (h1, h2, h3, h7, h6, h5) and the incremental code (c7, c6) need to be used as parameters and subsequently sent to the blockchain node.

Secondly, when the old contract is upgraded, the address of the old contract and the type of the upgraded old contract (the type can be identified in the transaction protocol version number) must be transmitted into the message.

And finally, the block chain client sends the message to the block chain node.

And verifying the signature of the deployer by the block chain network node, packaging the transaction, and performing consensus.

Each node of the block chain network analyzes the binary byte codes and executes the command of updating the contract of the byte codes. The corresponding contract address pair code on the chain is updated based on the address of the incoming upgrade contract.

The block link point obtains an identification of the upgraded old contract and an address of the old contract. The code hash chain in the contract address is then updated. This code segment is stored into a contract code linked list under the contract account.

For example, the code linked list under the contract address in the example is updated to (h1, h2, h3, h7, h6, h 5).

And simultaneously, storing the newly added code hash and the KV structure pair of the code into the block link point storage. For example, (h7, c7) and (h6, c6) are stored in the tile link point store in the example.

And each node of the block chain network stores and diskettes the running byte codes.

The intelligent contract is deployed through the process.

It should be further noted that, after the above deployment, the intelligent contract can be invoked by the following steps:

1. the user constructs a transaction. The user transmits contract address, contract parameter and other information to construct transaction protocol message and send to the block chain node.

2. The block chain nodes verify the deployer signatures, package transactions, and agree.

3. And the block link points load corresponding code hash sets from the StateDB according to the contract addresses based on the functions to be called, namely code hash linked lists corresponding to the contract addresses, and restore the original execution codes according to the linked lists.

Based on the contract address, the block link points find the set of all contracts for that contract address. For example, the linked list of codes is (h1, h2, h3, h7, h8, h 6). Next, the blockchain node acquires the corresponding code segment (c1, c2, c3, c7, c8, c6) from the blockchain storage StateDB according to the (h1, h2, h3, h7, h8, h6) key value and restores the original execution code.

4. The block chaining node executes the code block.

And finally, calculating the invoked methodID by the block chain node through the signature of the function in the message, matching and searching the position of the code corresponding to the function, and completing the invocation of the contract.

The intelligent contract deployment method has the following beneficial effects:

1. saving storage on the blockchain. In an existing blockchain, there is a scenario where contracts are repeatedly deployed in a massive amount. For example, in the forensic business scenario, there are hundreds of millions of identical standardized forensic contracts created and stored on the blockchain, and seriously, the binary byte code of the contract is also stored hundreds of millions of times, causing a serious waste of storage resources. Furthermore, a large number of different contracts, whose large number of bytecodes is highly similar, also results in a waste of huge resources. The invention can slice the approximate binary byte code according to the preset algorithm rule, thereby effectively saving the storage memory and improving the integral operation performance of the block chain.

Contracts of more than 90% are duplicated, according to test data applied to a certain blockchain. After the scheme is adopted, the accumulated saving rate of the block link point storage is over 93 percent.

2. The utilization rate of the storage resources is improved to the maximum extent. If adopt traditional according to the sliced mode of fixed size, can't be accurate slice data, must cause the waste of data. And cannot be split in a fixed-length manner if the dimensions of the code slices are not uniform per se. On the one hand, empirical values are difficult to control to the most reasonable size. On the other hand, there must be a certain number of unique fragments, resulting in the multiplexing of only partial code fragments. The method can bring the 'greatest common divisor' fragment into play to the utmost extent, and the optimal storage compression rate is obtained.

Fig. 4 is a schematic structural diagram of an intelligent contract deployment apparatus according to an embodiment of the present application. The intelligent contract deployment apparatus 400 may be implemented by software, hardware, or a combination of both.

As shown in fig. 4, the intelligent contract deployment apparatus 400 includes:

an obtaining module 401, configured to obtain a contract deployment request, where the contract deployment request includes: contract byte codes corresponding to the intelligent contracts;

a processing module 402 for:

In one possible design, the processing module 402 is configured to:

calculating a hash value of the target code block;

It should be noted that the apparatus provided in the embodiment shown in fig. 4 can execute the method provided in any of the above method embodiments, and the specific implementation principle, technical features, term explanation and technical effects thereof are similar and will not be described herein again.

Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 5, the electronic device 500 may include: at least one processor 501 and memory 502. Fig. 5 shows an electronic device as an example of a processor.

The memory 502 is used for storing programs. In particular, the program may include program code including computer operating instructions.

Memory 502 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.

Processor 501 is configured to execute computer-executable instructions stored in memory 502 to implement the methods described in the method embodiments above.

The processor 501 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

Alternatively, the memory 502 may be separate or integrated with the processor 501. When the memory 502 is a device independent from the processor 501, the electronic device 500 may further include:

a bus 503 for connecting the processor 501 and the memory 502. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. Buses may be classified as address buses, data buses, control buses, etc., but do not represent only one bus or type of bus.

Alternatively, in a specific implementation, if the memory 502 and the processor 501 are integrated on a chip, the memory 502 and the processor 501 may communicate through an internal interface.

An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium may include: various media that can store program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and in particular, the computer-readable storage medium stores program instructions for the methods in the above method embodiments.

An embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements the method in the foregoing method embodiments.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. An intelligent contract deployment method, comprising:

acquiring a contract deployment request, wherein the contract deployment request comprises: contract bytecode corresponding to an intelligent contract, the contract bytecode including: when the intelligent contract is called, the intelligent contract is queried and/or executed by a block chain virtual machine;

segmenting the contract bytecode according to each functional attribute contained in the contract bytecode to determine each code block and the connection order of each code block, wherein each code block corresponds to at least one functional attribute;

and inquiring whether each code block exists in a storage medium of a block chain node, and storing the code blocks which are not stored and the connection sequence into the storage medium, so that when the intelligent contract is called, the contract byte codes can be restored from each code block stored in the storage medium according to the connection sequence, and the intelligent contract is inquired and/or executed.

2. The intelligent contract deployment method of claim 1 wherein the code block comprises: a head code block, a tail code block, and at least one functional or default configuration code block;

the tail code block includes meta-information of the intelligent contract, the meta-information including: the intelligent contract compiling method comprises a switch identification of experiment attributes and verification fingerprint information, wherein the switch identification is used for representing a compiling mode of a compiler for the intelligent contract;

3. The intelligent contract deployment method according to claim 2, wherein the slicing the contract bytecode according to the functional attributes contained in the contract bytecode to determine the code blocks and the connection order of the code blocks comprises:

according to a first code corresponding to a memory allocation instruction, dividing the header code block from the contract byte code, and deleting the header code block from the contract byte code to determine a first contract byte code;

traversing the first contract bytecode, determining a section of code meeting any one identification rule in an identification rule set as the tail code block, and deleting the tail code block from the first contract bytecode to determine a second contract bytecode;

4. The intelligent contract deployment method of claim 3, wherein said selecting a second code corresponding to an instruction according to a function, and splitting the second contract bytecode into at least one functional or default configuration code block comprises:

removing a defined portion of a constructor in the second contract bytecode to determine a third contract bytecode and converting the third contract bytecode into an assembly operation code;

and reducing each of the opcode tiles to each fourth contract bytecode, and determining the fourth contract bytecode as the functional or default configuration code block.

5. The intelligent contract deployment method of claim 4, wherein the partitioning the set of opcode groups into opcode fragments according to the call encoding of the function or default constructor comprises:

if the operation code group contains the calling code of the function or the default constructor, the operation code group is taken as an independent operation code fragment;

combining the adjacent opcode groups without the invocation encoding into a single opcode fragment.

6. The intelligent contract deployment method according to any one of claims 1-5, wherein the querying whether each of the code blocks exists in a storage medium of a block chain node, and storing the code blocks that have not been stored and the connection order in the storage medium, comprises:

comparing each code block with each original code block stored in the storage medium to screen out one or more target code blocks different from the original code blocks from each code block;

and storing the target code block into a contract code linked list in the storage medium according to the connection order and a preset storage mode.

7. The intelligent contract deployment method according to claim 6, wherein the storing the target code block into a contract code linked list in the storage medium according to the connection order and a preset storage mode comprises:

calculating a hash value of the target code block;

combining the hash value with the corresponding code block into a key value pair;

and storing the key-value pairs into the contract code linked list according to the connection order.

8. An intelligent contract deployment apparatus, comprising:

an obtaining module, configured to obtain a contract deployment request, where the contract deployment request includes: contract bytecode corresponding to an intelligent contract, the contract bytecode including: when the intelligent contract is called, the intelligent contract is queried and/or executed by a block chain virtual machine;

a processing module to:

9. An electronic device, comprising:

a processor; and the number of the first and second groups,

a memory for storing a computer program for the processor;

wherein the processor is configured to perform the smart contract deployment method of any one of claims 1 to 7 via execution of the computer program.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the intelligent contract deployment method of any one of claims 1 to 7.

11. A computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the intelligent contract deployment method of any of claims 1 to 7.