WO2022237590A1

WO2022237590A1 - Smart contract upgrading method and blockchain system

Info

Publication number: WO2022237590A1
Application number: PCT/CN2022/090384
Authority: WO
Inventors: 林志平
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-05-11
Filing date: 2022-04-29
Publication date: 2022-11-17
Also published as: CN113220326A; CN113220326B

Abstract

A smart contract upgrading method and a blockchain node. The method comprises: all blockchain nodes in a blockchain network respectively obtain a contract deployment transaction comprising a bytecode, and deploy a corresponding smart contract on the basis of the contract deployment transaction (302); a first blockchain node in the blockchain network performs JIT compilation on the bytecode to obtain a machine code of the smart contract, and generates a contract upgrade transaction for the smart contract on the basis of the machine code (304); all the blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and upgrade, on the basis of the contract upgrade transaction, a contract code corresponding to the smart contract from the bytecode to the machine code (306).

Description

Smart contract upgrade method and blockchain system

technical field

This manual relates to the blockchain field, in particular to a smart contract upgrade method and a blockchain system.

Background technique

Blockchain technology (also known as distributed ledger technology) is a decentralized distributed database technology, which has many characteristics such as decentralization, openness and transparency, non-tamperable, and trustworthy, and is suitable for many In application scenarios with high reliability requirements. And JIT (Just-In-Time Compiler, just-in-time compilation) is a compilation method that can improve the efficiency of program code execution. How to apply JIT compilation to the blockchain to improve the execution efficiency of smart contracts has become an urgent technical problem to be solved.

Related technologies When applying JIT compilation to the blockchain, it is usually necessary to JIT-compile the bytecode by each blockchain node after deploying the bytecode of the smart contract to each blockchain node, and then The deployed bytecode is upgraded to compiled machine code. Since this method requires each blockchain node to JIT-compile the bytecode separately, it takes up a lot of blockchain processing resources.

In addition, when deploying smart contracts and upgrading smart contracts, blockchain nodes in related technologies need to receive instruction information sent by users before they can perform corresponding operations. In other words, from the deployment operation of the contract to the upgrade operation of the contract, the user needs to participate in at least two interactions, and the efficiency of contract upgrade is low.

Contents of the invention

In view of this, one or more embodiments of this specification provide a smart contract upgrade method and a blockchain system.

One or more embodiments of this specification provide technical solutions as follows: According to the first aspect of one or more embodiments of this specification, a smart contract upgrade method is proposed, including: all blockchain nodes in the blockchain network are respectively Obtain a contract deployment transaction containing bytecode, and deploy a corresponding smart contract based on the contract deployment transaction; the first blockchain node in the blockchain network JIT compiles the bytecode to obtain the The machine code of the smart contract, and generate a contract upgrade transaction for the smart contract based on the machine code; all blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and based on the contract upgrade The transaction upgrades the contract code corresponding to the smart contract from the bytecode to the machine code.

According to the second aspect of one or more embodiments of this specification, a blockchain system is proposed, including: a plurality of blockchain nodes; wherein, each blockchain node in the blockchain system obtains a The contract deployment transaction of the bytecode, and deploy the corresponding smart contract based on the contract deployment transaction; any blockchain node in the blockchain network JIT compiles the bytecode to obtain the smart contract machine code, and generate a contract upgrade transaction for the smart contract based on the machine code; all blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and based on the contract upgrade transaction, The contract code corresponding to the smart contract is upgraded from the bytecode to the machine code.

Description of drawings

Fig. 1 is a schematic diagram of the principle of compiling execution and interpreting execution in an embodiment.

Figure 2 is a schematic diagram illustrating execution and JIT in one embodiment.

Fig. 3 is a flow chart of a smart contract upgrade method shown in an exemplary embodiment of this specification.

Fig. 4 is a blockchain system shown in an exemplary embodiment of this specification.

Fig. 5 is an interaction diagram of a smart contract upgrade method shown in an exemplary embodiment of this specification.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of the present specification as recited in the appended claims.

The terms used in this specification are for the purpose of describing particular embodiments only, and are not intended to limit the specification. As used in this specification and the appended claims, the singular forms "a", "the", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The blockchain 1.0 era usually refers to the development stage of blockchain applications represented by Bitcoin between 2009 and 2014. They are mainly dedicated to solving the decentralization of currency and means of payment. Beginning in 2014, developers have increasingly focused on addressing Bitcoin's technical and scalability deficiencies. At the end of 2013, Vitalik Buterin released the Ethereum white paper "Ethereum: Next-Generation Smart Contract and Decentralized Application Platform", which introduced smart contracts into the blockchain, opened up the application of the blockchain outside the currency field, and thus opened the blockchain Chain 2.0 era.

A smart contract is an automatically executable computer contract based on prescribed trigger rules, and can also be regarded as a digital version of a traditional contract. The concept of smart contracts was first proposed by Nick Szabo, an interdisciplinary legal scholar and cryptography researcher, in 1994. This technology was once not used in the actual industry due to the lack of programmable digital systems and related technologies, until the emergence of blockchain technology and Ethereum provided a reliable execution environment for it. Due to the blockchain ledger adopted by the blockchain technology, the generated data cannot be tampered with or deleted, and the entire ledger will continue to add ledger data, thus ensuring the traceability of historical data; at the same time, the decentralized operating mechanism avoids central influence of cultural factors. Smart contracts based on blockchain technology can not only give full play to the advantages of smart contracts in terms of cost and efficiency, but also prevent malicious behavior from interfering with the normal execution of contracts. The smart contract is written into the blockchain in a digital form, and the characteristics of the blockchain technology ensure that the entire process of storage, reading, and execution is transparent, traceable, and tamper-proof.

A smart contract is essentially a program that can be executed by a computer. Smart contracts, like computer programs widely used today, can be written in high-level languages (such as C language, C++ language, etc.). The program code of a smart contract written in a high-level language can generally be converted into a "machine code" that the computer's CPU can recognize and run through a "compiler", and then the CPU can execute such machine code (or called "microprocessing"). device command"). This method is generally called "compilation and execution".

Compilation and execution generally do not have cross-platform scalability. Because there are different manufacturers, different brands and different generations of CPUs, and the instruction sets supported by these different CPUs are different in many cases, such as the x86 instruction set, ARM instruction set, etc., and the same manufacturer of the same brand but different generations of CPUs ( For example, the instruction sets supported by different generations of Intel CPUs are not exactly the same. Therefore, the same program code written in the same high-level language may have different machine codes converted by compilers on different CPUs. Specifically, in the process of converting the program code written in the high-level language to the machine code, the compiler will combine the characteristics of the specific CPU instruction set (such as the vector instruction set, etc.) It is related to the specific CPU hardware. In this way, the same machine code, one can run on x86, but the other may not run on ARM; even the same x86 platform, with the passage of time, the instruction set is constantly enriched and expanded, which leads to different generation codes. The machine code that the x86 platform runs is also different. Moreover, since the execution of machine codes requires the CPU to be scheduled by the operating system kernel, even the same hardware may support different machine codes running under different operating systems.

Different from compilation and execution, there is also a program running mode of "interpretation and execution". For example, in the Java language, the Java source code is compiled into a standard bytecode (bytecode) through a Java compiler. Here, the compiler does not target any actual hardware processor instruction set, but defines a set of abstract standard instruction sets. . The compiled standard bytecode generally cannot run directly on the hardware CPU, so a virtual machine, namely JVM, is introduced. The JVM runs on a specific hardware processor to interpret and execute the compiled standard bytecode.

JVM is the abbreviation of Java Virtual Machine (Java Virtual Machine). It is a fictional computer, which is often realized by simulating various computer functions on an actual computer. JVM shields information related to specific hardware platforms, operating systems, etc., so that Java programs only need to be generated standard bytecodes that can run on Java virtual machines, and can run on multiple platforms without modification.

A very important feature of the Java language is its independence from the platform. The use of Java virtual machine is the key to realize this feature. If a general high-level language is to be run on different platforms, at least it needs to be compiled into different object codes. After the introduction of the Java language virtual machine, the Java language does not need to be recompiled when running on different platforms. The Java language uses the Java virtual machine to shield the information related to the specific platform, so that the Java language compiler only needs to generate the object code (byte code) that runs on the Java virtual machine, and it can run on various platforms without modification. . When the Java virtual machine executes the bytecode, it interprets the bytecode into machine instructions on a specific platform for execution. This is why Java can "compile once, run everywhere".

The JVM runs on a specific hardware processor, is responsible for interpreting and executing the bytecode for the specific processor it is running on, and shields these underlying differences upwards, presenting standard development specifications to developers. When the JVM executes the bytecode, it actually interprets the bytecode into machine instructions on a specific platform for execution. Specifically, after the JVM receives the input bytecode, it interprets each instruction sentence by sentence, and translates it into a machine code suitable for the current machine to run. These processes are interpreted and executed by an interpreter called Interpreter, for example. In this way, developers who write Java programs do not need to consider which hardware platform the written program code will run on. The development of the JVM itself is done by professional developers of the Java organization to adapt the JVM to different processor architectures. So far, there are only a limited number of mainstream processor architectures, such as X86, ARM, RISC-V, and MIPS. After professional developers port the JVM to platforms that support these specific hardware, Java programs can theoretically run on all machines. The transplantation of JVM is usually provided by professional personnel of Java development organization, which greatly reduces the burden of Java application developers.

Interpretation execution brings cross-platform portability, but because the execution of bytecode has gone through the process of JVM intermediate translation, the execution efficiency is not as high as the above-mentioned compilation execution efficiency, and the difference in efficiency can sometimes even reach dozens of times.

Figure 1 shows the similarities and differences between compiled execution and interpreted execution. Regardless of whether it is interpreted or compiled, or whether it is a physical machine or a virtual machine, it is impossible for a machine to read and understand an application program like a human, and then obtain the ability to execute it. Most of the program code needs to go through the steps in Figure 1 before reaching the target code of the physical machine or the instruction set that the virtual machine can execute. The branch from the top to the left in Figure 1 is the generation process from the program code to the target machine code in the traditional compilation principle, and the branch from the top to the right is the process of interpretation and execution. Nowadays, languages based on physical machines, Java virtual machines, or other non-Java high-level language virtual machines (High-Level Language Virtual Machine, HLLVM) mostly follow this idea based on modern classic compilation principles, and compile the program before execution. The source code is processed by lexical analysis and syntax analysis, and the source code is converted into an abstract syntax tree (Abstract SyntaxTree, AST). For the implementation of a specific language, lexical analysis, syntax analysis, and subsequent optimizers and object code generators can be selected independently of the execution engine to form a complete compiler for implementation. This type of representative is C/C++ language. It is also possible to choose to implement some of the steps (such as the steps before generating the abstract syntax tree) as a semi-independent compiler, which is represented by the Java language. Or these steps and the execution engine are all encapsulated in a closed black box, such as most JavaScript executors.

In order to take into account cross-platform portability and high performance as much as possible, the concept of just-in-time compiler (Just-In-TimeCompiler, JIT) was proposed. The core idea of JIT is "how to efficiently avoid the repeated work of interpreting instructions". There are a lot of codes that are repeatedly executed in computer programs. For example, some calculation "functions" may be called repeatedly many times during the execution of a program. If it is interpreted execution, each execution of the loop process needs to translate the function from bytecode to machine code. However, the actual situation is that the machine code generated by this function in dozens of translations is exactly the same. Naturally, after the first translation, the machine code of the translated function is cached. In the process of subsequent re-execution, there is no need to translate again, but the cached code is directly used, which can improve execution efficiency.

On the contrary, some functions are executed only once during the program running cycle (such as startup initialization), then such functions do not need to be cached, and can be directly interpreted and executed once. Therefore, a core module in JIT technology is "hot spot analysis", that is, to analyze which codes have been executed multiple times during program execution, so as to cache the translated machine code. For operations that are executed infrequently, no caching is required. This achieves the best balance between execution efficiency and memory overhead.

In addition, another core module in JIT technology is compilation optimization (or called optimized compilation). The directly translated machine code is not optimized in combination with the context, but only caches the high-frequency machine code, and the performance improvement is limited. If you want to get better performance, you can make further optimizations to the compiler. The way of compiling optimization generally takes relatively more time to implement.

The working principle of JIT is shown in Figure 2 for example. The Java source code is compiled by the Java compiler to generate a piece of Java bytecode, which is distributed to two execution paths (JIT Compiler and Interpreter) after hotspot analysis. The code judged as a hotspot (high-frequency execution) is compiled by the JIT compiler to obtain machine code, cached and executed, and is generally executed by the CPU under the control of the operating system (OS). The low frequency enters the interpreter (Interpreter), and after being translated into machine code, it is executed by the CPU under the control of the OS.

Due to the contextuality of the program code itself, there is often a large room for optimization in the compilation process. The optimized machine code has much higher execution efficiency than the directly translated machine code. If you want to get better performance, compiler optimization is a must. The process of JIT compiler compilation may be time-consuming. In particular, JIT Compiler may take a long time in the process of compiling bytecode for the first time, which is not even as good as interpreting and executing. Then, for some java programs, if the hot spots are not very prominent, that is, the overall execution frequency is not very high, and the overall execution process is very long, it will be difficult for JIT to take advantage of compilation and execution.

In view of the above advantages, outside the blockchain, JIT compilation has become an important means to improve the efficiency of program execution. However, due to the consistency requirements of blockchain technology for each node, "how to integrate JIT compilation into the blockchain, To improve the execution efficiency of smart contracts" has become an urgent problem in the blockchain field.

In related technologies, if it is necessary to JIT compile the smart contract in the blockchain network, it is usually necessary for each blockchain node to perform JIT compilation after deploying the bytecode of the smart contract to each blockchain node. And after the JIT compilation is completed, the deployed bytecode is upgraded to the machine code obtained by JIT compilation. Since this method requires each blockchain node to JIT-compile the bytecode separately, it takes up a lot of blockchain processing resources.

In addition, smart contracts in the blockchain are usually compiled by users themselves, and deployed by sending contract deployment transactions. Furthermore, when it is necessary to upgrade the deployed smart contract, it is necessary to further send a contract upgrade transaction to each blockchain node, so that each blockchain node can upgrade the deployed bytecode to the machine code compiled by JIT . It can be seen that in the process of contract deployment and contract upgrade, related technologies require users to interact with blockchain nodes multiple times, and the efficiency of contract upgrade is low.

For this reason, this manual proposes a smart contract upgrade method, so that when JIT compilation is applied to blockchain technology, it does not need to occupy a large amount of blockchain processing resources, nor does it require users to interact with blockchain nodes multiple times .

Fig. 3 is a flow chart of a smart contract upgrade method shown in an exemplary embodiment of this specification. The method may include the following steps: Step 302, all blockchain nodes in the blockchain network respectively obtain contract deployment transactions containing bytecodes, and deploy corresponding smart contracts based on the contract deployment transactions.

Similar to related technologies, this specification needs to prioritize the deployment of bytecodes of smart contracts. In actual operation, users can compile the bytecode of the smart contract by themselves, and send a contract deployment request to the client they use, so that the client generates a contract deployment transaction based on the bytecode. The client can send the generated contract deployment transaction to any blockchain node, so that any blockchain node can implement a transaction consensus on the contract deployment transaction, so that after the consensus is passed, each blockchain node will separately The bytecode contained therein is deployed.

From the above content, we can see that in related technologies, after each blockchain node deploys the bytecode, each blockchain node needs to JIT compile the bytecode by itself, which takes up more blockchain processing. resource. In addition, when the deployed bytecode needs to be upgraded, the user also needs to send an upgrade instruction for the smart contract to the blockchain node, which reduces the efficiency of the contract upgrade. Among them, it should be pointed out that since the JIT compilation is performed by each blockchain node in the related technology, when the user sends an upgrade instruction, he needs to send an upgrade instruction to each blockchain node to ensure that each blockchain node The contract upgrade operation can be completed. It can be seen that this method not only increases the number of interactions, but also occupies a large amount of transmission resources.

In view of this, in this manual, each blockchain node no longer executes JIT compilation separately, but a node in the blockchain network performs JIT compilation, and then sends the compiled machine code to the blockchain Each blockchain node in the network, so that each blockchain node does not need to perform JIT compilation operations separately, reducing the occupation of blockchain processing resources during the JIT compilation process. At the same time, in order to avoid the problem of low upgrade efficiency due to the high number of interactions between the user and the blockchain node, and the problem of occupying more transmission resources, this manual no longer controls the contract upgrade operation by the user, but by After the blockchain node completes the JIT compilation, it will upgrade the deployed bytecode to machine code by itself.

Step 304, the first blockchain node in the blockchain network performs JIT compilation on the bytecode to obtain the machine code of the smart contract, and generates a contract for the smart contract based on the machine code Upgrade deals.

In this specification, the aforementioned blockchain node responsible for JIT compiling the smart contract is referred to as the first blockchain node.

In practice, not all smart contracts need to be compiled into machine code. Therefore, the first blockchain node can determine whether to perform JIT compilation on the smart contract in the contract deployment transaction according to actual needs.

In an embodiment, the first block chain node may, after receiving the instruction information sent by the user for instructing to compile the bytecode of the smart contract into machine The section code is JIT compiled to obtain the machine code of the smart contract. In this embodiment, the process of JIT compilation is controlled by the user, which improves the controllability of the contract upgrade.

In another embodiment, the first blockchain node may, upon receiving a smart contract deployment transaction, determine whether the smart contract transaction contains an indication flag for instructing to compile the bytecode of the smart contract into machine code , and JIT-compile the bytecode contained in the contract deployment transaction when the indication is included. In this embodiment, the user only needs to add a corresponding indicator in the contract deployment transaction to inform the first blockchain node that "the bytecode in the contract deployment transaction needs to be JIT compiled", without the need to Send additional instructions.

In yet another embodiment, the first blockchain node may determine whether to JIT compile the bytecode in the contract deployment transaction according to the initiator of the contract deployment transaction or the type of business data contained in the contract deployment transaction. Specifically, the first blockchain node can JIT compile the bytecode in the contract deployment transaction when it is determined that the received contract deployment transaction is initiated by a predefined specific user; or, the first blockchain node When the node determines that the business data contained in the received contract deployment transaction belongs to a predefined business type, it can perform JIT compilation on the bytecode in the contract deployment transaction.

In this specification, the timing for performing JIT compilation can also be determined according to actual conditions.

In an embodiment, the first blockchain node may start to JIT compile the bytecode of the smart contract after determining that the bytecode of the smart contract is deployed. This method is equivalent to sequentially executing bytecode deployment and bytecode JIT compilation.

In another embodiment, the first blockchain node may use relatively idle time to perform JIT compilation on the bytecode of the smart contract when it is determined that the bytecode of the smart contract has been deployed. For example, the bytecode of the smart contract can be JIT compiled when the first blockchain node does not need to process transactions.

In yet another embodiment, the JIT compilation for bytecode and contract deployment operations can be performed in parallel. In other words, when the bytecode in the contract deployment transaction is deployed to each blockchain node, the first blockchain node can simultaneously perform JIT compilation on the bytecode in the contract deployment transaction. In this embodiment, since the two operations are executed in parallel, the machine code of the smart contract can be quickly obtained, and then the deployed bytecode can be upgraded in a timely manner.

In this specification, when the first blockchain node JIT compiles the bytecode of the smart contract, it can compile all bytecodes in the contract deployment transaction; or, the first blockchain node can use JIT compilation The characteristics of the hotspot analysis of the bytecode in the contract deployment transaction are given priority, and then the hotspot bytecode determined by the hotspot analysis (bytecode executed frequently) is compiled; or, due to the contract code itself Relevance, there is usually a large room for optimization. Therefore, when the first blockchain node performs JIT compilation on the bytecode of the smart contract, it can optimize the compilation of the bytecode contained in the contract deployment transaction to improve the compilation. The resulting machine code execution efficiency.

Step 306, all blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and based on the contract upgrade transaction, upgrade the contract code corresponding to the smart contract from the bytecode to the machine code.

What needs to be declared is that, as mentioned above: the smart contracts deployed in the blockchain are usually compiled by users themselves, and the deployment is completed by submitting contract deployment transactions. In other words, the ownership of the smart contract belongs to the individual user. Therefore, in related technologies, after the blockchain node compiles the smart contract into machine code, the user usually needs to send an upgrade instruction to the corresponding blockchain node to indicate that the bytecode is allowed to be upgraded to machine code. The block chain node can perform the operation of upgrading the deployed bytecode to machine code. However, in related technologies, since each blockchain node needs to perform JIT compilation operations separately, when sending an upgrade instruction, the user also needs to send an upgrade instruction to each blockchain node, which takes up a lot of transmission resources.

For this reason, the first blockchain node in this manual can obtain the contract upgrade authorization of the sender of the contract deployment transaction in advance, so that the first blockchain node can generate the The contract upgrade transaction of the machine code, and then upgrade the deployed bytecode.

It should be understood that in actual operation, after compiling the bytecode, the user usually sends the contract deployment transaction containing the bytecode to any node in the blockchain network to deploy the smart contract. In other words, the blockchain nodes responsible for JIT compilation are usually not fixed. Therefore, users usually grant contract upgrade authorization to all nodes in the blockchain network, so that when any node is responsible for JIT compilation, contract upgrade transactions can be generated based on the compiled machine code.

In practice, the blockchain network is usually maintained by the provider of the blockchain technology (also known as the platform that provides the blockchain technology). Therefore, in the actual authorization process, the user only needs to grant the provider the contract upgrade authorization, which is equivalent to granting the contract upgrade authorization to each node in the blockchain network.

In this manual, when any blockchain node in the blockchain network upgrades the bytecode to machine code, it needs to first determine the contract address of the smart contract, and then replace the deployed bytecode corresponding to the contract address It is the machine code to realize the upgrade of the smart contract.

In practical applications, smart contracts deployed in the blockchain network may be invoked by users at any time. When the deployed smart contract is invoked, the smart contract may not have been upgraded and is still deployed in the corresponding contract address in the form of bytecode; it may also have been upgraded and deployed in the form of machine code in the corresponding contract address. It should be understood that for smart contracts deployed in different forms, calls need to be made in different ways.

Specifically, when the second blockchain node in the blockchain network receives an invocation transaction for a smart contract, all nodes in the blockchain network can conduct a transaction consensus on the invocation transaction, and if the consensus is passed , all blockchain nodes can determine the contract address of the smart contract to be called according to the call transaction, so as to obtain the contract code of the called smart contract through the contract address. Among them, when the obtained contract code is a bytecode, each blockchain node can interpret and execute the bytecode to realize the call of the smart contract; and when the obtained contract code is a machine code Under this condition, each blockchain node can directly execute the obtained machine code. Wherein, the third block chain node may be the same node as the first block chain node, or may be a different node.

What needs to be declared is that when the obtained contract code is machine code, it is not necessary to execute all the obtained machine codes, but the machine code to be executed can be determined according to the called function/code block contained in the calling transaction . In other words, only the machine code corresponding to the called function/code block in the acquired contract code of the smart contract can be executed.

In addition, in order to enable each blockchain node in the blockchain network to perform a contract upgrade operation on the corresponding smart contract in the received contract upgrade transaction, the chain code run by each blockchain node usually contains Contract upgrade logic code, the contract upgrade logic code is used to generate a contract upgrade transaction for the smart contract when it is determined that the JIT compilation has been completed, so as to upgrade the deployed contract code from bytecode to machine through the contract upgrade transaction code.

It should be emphasized that the technical solutions in this specification can be applied to the traditional architecture of blockchain technology, that is, all blockchain nodes in the blockchain network are formed by deploying blockchain codes on corresponding physical devices, In most cases, each node corresponds to a physical device; the technical solution in this manual can also be applied to the BaaS (Blockchain as a Service) architecture in the blockchain technology, that is, all nodes in the blockchain network pass Cloud services are formed by deploying blockchain codes on virtual machines implemented in the cloud, and blockchain nodes do not need to correspond to corresponding physical devices one by one.

Among them, when the technical solution of this specification is applied to the BaaS architecture, it is equivalent to the first blockchain node being installed in a virtual machine. At this time, the JIT compilation service can be pre-deployed in the virtual machine corresponding to the first blockchain node. Used to JIT compile the bytecode of the smart contract.

It can be seen from the above technical solutions that after the blockchain network in this specification obtains the contract deployment transaction, on the one hand, it deploys the bytecode in the contract deployment transaction to each blockchain node; The first blockchain node of JIT compiles the bytecode in the contract deployment transaction to obtain the machine code of the corresponding smart contract. On this basis, the first blockchain node can send the contract upgrade transaction containing the compiled machine code to each blockchain node after the JIT compilation has been completed, so that each blockchain node can Upgrade deployed bytecode to machine code.

It should be understood that the technical solution in this manual is equivalent to JIT compiling the bytecode of the smart contract through only one node in the blockchain network, and after the compilation is completed, the compiled The machine code of the blockchain is synchronized to each blockchain node, so that each blockchain node can upgrade the bytecode to machine code. Apparently, through the technical solution in this manual, the situation in related technologies that requires each blockchain node to perform JIT compilation operation separately is avoided, and the occupation of blockchain processing resources by JIT compilation is reduced.

Furthermore, the blockchain nodes in this manual can obtain the contract upgrade authorization granted by the user in advance, so that the blockchain nodes in this manual can generate contract upgrade transactions based on the compiled machine code after JIT compilation is completed. , and then complete the contract upgrade operation for smart contracts, avoiding the need for users to send upgrade instructions to each blockchain node in related technologies, and then solving the problem of low upgrade efficiency due to the large number of interactions in related technologies , and the problem of occupying a large amount of transmission resources.

In order to realize the above smart contract upgrade method, this specification also proposes a blockchain system. The blockchain system is used to implement the above solution, and most of the operation methods are similar to the previous embodiment. How to perform JIT compilation, how to generate contract upgrade transactions, etc., can refer to the introduction of the previous embodiment, and will not be discussed in the next embodiment. repeat.

Figure 4 is a block chain system shown in an exemplary embodiment of this specification, as shown in Figure 4, the block chain system 4 includes: a plurality of block chain nodes; wherein, in the block chain system Each block chain node respectively obtains the contract deployment transaction containing the bytecode, and deploys the corresponding smart contract based on the contract deployment transaction; any block chain node in the block chain network executes the bytecode JIT compilation to obtain the machine code of the smart contract, and generate a contract upgrade transaction for the smart contract based on the machine code; all blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, And based on the contract upgrade transaction, the contract code corresponding to the smart contract is upgraded from the bytecode to the machine code.

As mentioned above, this specification needs to prioritize the deployment of the bytecode of the smart contract. In actual operation, users can compile the bytecode of the smart contract by themselves, and send a contract deployment request to the client they use, so that the client generates a contract deployment transaction based on the bytecode. The client can send the generated contract deployment transaction to any blockchain node in the blockchain system 4, so that any blockchain node can achieve a transaction consensus on the contract deployment transaction, and after the consensus is passed, the Each blockchain node deploys the bytecode contained therein respectively.

As mentioned above, the blockchain node responsible for JIT compiling the smart contract in this specification can be any node in the blockchain system. For example, any blockchain node may be node 41 in FIG. 4 , that is, node 41 is the first blockchain node in the previous embodiment.

As mentioned above, the first blockchain node may, after receiving the instruction information sent by the above-mentioned user for instructing to compile the bytecode of the smart contract into machine code, then deploy the bytecode contained in the above-mentioned contract The code is JIT compiled to obtain the machine code of the smart contract. Alternatively, the first blockchain node may, upon receiving the smart contract deployment transaction, determine whether the smart contract transaction contains an instruction flag for instructing the bytecode of the smart contract to be compiled into machine code, and If the flag is indicated, JIT compiles the bytecode contained in the contract deployment transaction. Alternatively, the first blockchain node may determine whether to JIT-compile the bytecode in the contract deployment transaction according to the initiator of the contract deployment transaction or the type of business data contained in the contract deployment transaction.

As mentioned above, the first blockchain node can start to JIT compile the bytecode of the smart contract after determining that the bytecode of the smart contract is deployed. The first blockchain node can also use relatively free time to JIT compile the bytecode of the smart contract when it is determined that the bytecode of the smart contract has been deployed.

As mentioned above, the blockchain nodes in this manual can obtain the contract upgrade authorization of the sender of the contract deployment transaction in advance, so that after the blockchain node completes the JIT compilation for the smart contract, it can generate the compiled machine code by itself. The contract upgrade transaction of , and then upgrade the deployed bytecode.

As mentioned above, smart contracts deployed in the blockchain system may be invoked by users at any time. When the deployed smart contract is invoked, the smart contract may not have been upgraded and is still deployed in the corresponding contract address in the form of bytecode; it may also have been upgraded and deployed in the form of machine code in the corresponding contract address. Specifically, when the second blockchain node in the blockchain network receives an invocation transaction for a smart contract, all nodes in the blockchain network can conduct a transaction consensus on the invocation transaction, and if the consensus is passed , all blockchain nodes can determine the contract address of the smart contract to be called according to the call transaction, so as to obtain the contract code of the called smart contract through the contract address. Among them, when the obtained contract code is a bytecode, each blockchain node can interpret and execute the bytecode to realize the call of the smart contract; and when the obtained contract code is a machine code Under this condition, each blockchain node can directly execute the obtained machine code. Wherein, the second block chain node can be the same node as the first block chain node, such as node 41; the second block chain node can also be a different node from the first block chain node, such as Node 42.

As mentioned above, the above-mentioned blockchain system can be based on the traditional architecture of blockchain technology, that is, all blockchain nodes in the blockchain system are formed by deploying blockchain codes on corresponding physical devices, and in most cases Next, each node corresponds to a physical device; the above blockchain system can also be based on the BaaS (Blockchain as a Service) architecture in blockchain technology, that is, all nodes in the blockchain system are distributed in the cloud through cloud services. It is formed by deploying the blockchain code on the realized virtual machine, and the blockchain nodes do not need to correspond to the corresponding physical devices one by one.

It can be seen from the above blockchain system that after obtaining the contract deployment transaction, the blockchain system in this specification deploys the bytecode in the contract deployment transaction to each blockchain node on the one hand; The included first blockchain node performs JIT compilation on the bytecode in the contract deployment transaction to obtain the machine code of the corresponding smart contract. On this basis, the first blockchain node can send the contract upgrade transaction containing the compiled machine code to each blockchain node after JIT compilation is completed, so that each blockchain node can respectively Deployed bytecode is upgraded to machine code. In this manner, the problem of wasting blockchain processing resources caused by the need to perform JIT compilation in each blockchain node in the related art is avoided.

Among them, the first blockchain node can obtain the contract upgrade authorization granted by the user in advance, so that the blockchain node in this manual can generate the contract upgrade transaction based on the machine code obtained by JIT compilation after the JIT compilation is completed, and then Upgrading the deployed bytecode to machine code avoids the problem of occupying a large amount of transmission resources in related technologies that require users to send upgrade instructions to each blockchain node.

Next, the technical solution of this specification is introduced through specific embodiments.

Fig. 5 is an interaction diagram of a smart contract upgrade method shown in an exemplary embodiment of this specification. The method may include the following steps: Step 501, the client sends a contract deployment transaction to the first blockchain node in the blockchain network.

In this embodiment, the user can compile the bytecode of the smart contract to be deployed on the client used by the user. After compiling the bytecode of the smart contract, the user can initiate a deployment instruction for the smart contract to the client, so that the client can generate a contract deployment transaction based on the bytecode of the smart contract under the instruction of the deployment instruction.

In practical applications, the client may contain a contract deployment control, so that the user can initiate a contract deployment request to the client through the control. Specifically, when the client detects that the contract deployment control is triggered, it can determine that the user needs to deploy the corresponding smart contract to the blockchain network. Therefore, the contract deployment transaction can be generated based on the bytecode compiled by the user , and send it to the first blockchain node in the blockchain network, so as to deploy the bytecode of the smart contract to each blockchain node through the first blockchain node. Wherein, the first blockchain node is any node in the blockchain network.

Step 502, the first blockchain node and other nodes in the blockchain network conduct a transaction consensus on the contract deployment transaction, so that each blockchain node deploys the bytecode contained in the contract deployment transaction.

It should be understood that after the first blockchain node receives the contract deployment transaction, it needs to give priority to the transaction consensus on the contract deployment transaction, and if the consensus is passed, then send the contract deployment transaction to each blockchain Nodes, so that the bytecode contained in the transaction is deployed by each blockchain node.

What needs to be declared is that after each blockchain node receives the above-mentioned contract deployment transaction, it will save the bytecode contained in the transaction to the corresponding contract address to complete the deployment of the smart contract.

Step 503, the first blockchain node performs JIT compilation on the bytecode in the contract deployment transaction to obtain the corresponding machine code.

In this embodiment, the JIT compilation can be performed while the bytecode of the smart contract is being deployed; or the JIT compilation can be performed after the bytecode of the smart contract is compiled. Specifically, how to JIT compile the bytecode of the smart contract can be determined by those skilled in the art according to actual needs.

Step 504, the first blockchain node generates a contract upgrade transaction based on the compiled machine code.

In this embodiment, the blockchain network is maintained by the provider of the blockchain technology, and the user can pre-grant the provider "contract upgrade authorization for smart contracts", so that any block in the blockchain network After the chain node completes the JIT compilation of the bytecode of the smart contract, it can generate a contract upgrade transaction based on the machine code obtained by JIT compilation.

Of course, this embodiment is only introduced by taking the first blockchain node in charge of JIT compilation to be responsible for generating contract upgrade transactions as an example. In practical applications, the blockchain node responsible for generating contract upgrade transactions and the blockchain node responsible for JIT compilation can also be different nodes. Specifically, after the first blockchain node completes JIT compilation, it can convert the compiled The machine code is sent to the blockchain node responsible for generating the contract upgrade transaction, so that the blockchain node generates the contract upgrade transaction. Furthermore, the provider of the blockchain technology can set up a server for the blockchain network to maintain the blockchain network through the server. On this basis, the user can only grant the server contract upgrade authorization. Therefore, After the first blockchain node completes JIT compilation, it can also send the compiled machine code to the server, so that the server is responsible for generating contract upgrade transactions. Specifically how to generate a contract upgrade transaction can be determined by those skilled in the art according to the actual situation.

Step 505, the first blockchain node and other nodes in the blockchain network conduct a transaction consensus on the contract upgrade transaction, so that each blockchain node upgrades the deployed bytecode to the machine code contained in the contract upgrade transaction .

In this embodiment, after the first blockchain node generates a contract upgrade transaction, it can conduct transaction consensus with other nodes in the blockchain network, and when the consensus is passed, the contract upgrade transaction is sent to other nodes , so that each blockchain node replaces the deployed bytecode in the contract address with the machine code in the contract upgrade transaction, and then completes the upgrade for the smart contract.

It can be seen from the above technical solution that after the user sends the compiled smart contract to the blockchain node, on the one hand, the blockchain node will conduct a transaction consensus with other nodes on the contract deployment transaction containing the smart contract, so that when the consensus is passed Next, each blockchain node deploys the bytecode of the smart contract; on the other hand, the blockchain node JIT compiles the bytecode to obtain the machine code of the smart contract. Among them, the blockchain node has obtained the user's contract upgrade authorization in advance, so that the blockchain node can directly generate a contract upgrade transaction based on the compiled machine code after completing the JIT compilation, so that the deployed The bytecode is upgraded to the compiled machine code. Obviously, through this method, it is not necessary to perform JIT compilation by each blockchain node separately as in related technologies, which reduces the occupation of blockchain processing resources. Furthermore, since the blockchain nodes have pre-obtained the contract upgrade authorization granted by the user, it avoids the need for the user to send an upgrade instruction to each blockchain node in related technologies, and reduces the occupation of transmission resources.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification may be provided as a method, system or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A smart contract upgrade method, including:

All blockchain nodes in the blockchain network respectively obtain contract deployment transactions containing bytecodes, and deploy corresponding smart contracts based on the contract deployment transactions;

The first blockchain node in the blockchain network performs JIT compilation on the bytecode to obtain the machine code of the smart contract, and generates a contract upgrade transaction for the smart contract based on the machine code;

All blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and upgrade the contract code corresponding to the smart contract from the bytecode to the machine code based on the contract upgrade transaction.
According to the method according to claim 1, the first blockchain node in the blockchain network performs JIT compilation on the bytecode, comprising:

The first blockchain node performs JIT compilation on the bytecode in the contract deployment transaction in response to the instruction message sent by the user for instructing to compile the bytecode of the smart contract into machine code; or,

When the first block chain node determines that the contract deployment transaction contains an instruction flag for instructing to compile the bytecode of the smart contract into machine code, the byte code in the contract deployment transaction code for JIT compilation; or,

When the first blockchain node determines that the contract deployment transaction is initiated by a predefined specific user, JIT compiles the bytecode in the contract deployment transaction; or,

When the first blockchain node determines that the business data included in the contract deployment transaction belongs to a predefined business type, JIT compiles the bytecode in the contract deployment transaction.
According to the method according to claim 1, the first blockchain node in the blockchain network performs JIT compilation on the bytecode, comprising:

After the first blockchain node determines that the bytecode of the smart contract is deployed, it starts to JIT compile the bytecode of the smart contract; or,

When the first blockchain node determines that the bytecode of the smart contract has been deployed, it uses a relatively idle time period to perform JIT compilation on the bytecode.
According to the method according to claim 1, the first blockchain node in the blockchain network performs JIT compilation on the bytecode, comprising:

The first blockchain node compiles all bytecodes contained in the contract deployment transaction; and/or,

The first blockchain node performs hotspot analysis on the bytecode contained in the contract deployment transaction, and compiles the obtained hotspot bytecode; and/or,

The first blockchain node optimizes and compiles the bytecode contained in the contract deployment transaction.
According to the method according to claim 1, any blockchain node in the blockchain network upgrades the contract code corresponding to the smart contract from the bytecode to the machine code based on the contract upgrade transaction ,include:

Any blockchain node in the blockchain network determines the contract address of the smart contract, and replaces the deployed bytecode in the contract address with the machine code.
The method according to claim 1, further comprising:

The second block chain node in the block chain network receives the calling transaction for the smart contract; the second block chain node and the first block chain node are the same node or different nodes;

All the blockchain nodes determine the contract address of the smart contract according to the calling transaction, so as to obtain the contract code of the smart contract;

When all the blockchain nodes determine that the contract code is the bytecode, they interpret and execute the bytecode;

When all the blockchain nodes determine that the contract code is the machine code, they directly execute the machine code.
According to the method according to claim 6, said all blockchain nodes directly execute said machine code, comprising:

All the blockchain nodes execute the machine code corresponding to the called function/code block in the smart contract.
According to the method according to claim 1, the first block chain node has obtained the contract upgrade authorization of the sender of the contract deployment transaction in advance.
According to the method according to claim 1, the chain code of the first blockchain node includes a contract upgrade logic code, which is used to instruct to generate a contract for the smart contract when it is determined that the JIT compilation has been completed Upgrade transactions.
According to the method according to claim 1, the first blockchain node is mounted on a virtual machine, a JIT compilation service is pre-deployed in the virtual machine, and the JIT compilation for the smart contract is completed by calling the JIT compilation service .
A blockchain system, comprising: a plurality of blockchain nodes; wherein,

Each blockchain node in the blockchain system respectively obtains a contract deployment transaction including bytecode, and deploys a corresponding smart contract based on the contract deployment transaction;

Any blockchain node in the blockchain network performs JIT compilation on the bytecode to obtain the machine code of the smart contract, and generates a contract upgrade transaction for the smart contract based on the machine code;

All blockchain nodes in the blockchain network respectively obtain the contract upgrade transaction, and upgrade the contract code corresponding to the smart contract from the bytecode to the machine code based on the contract upgrade transaction.