A method of executing a smart contract, a blockchain node and a node device

Abstract

The specification provides a method for executing a smart contract, a blockchain node and a node device. A method for executing a smart contract includes: a blockchain node receiving a request for creating a smart contract, the request including code of the smart contract, the code of the smart contract including hotspot code marked by a hotspot identifier; after the blockchain node completes deployment of the smart contract, starting to compile the code of the smart contract into machine code by JIT and storing the hotspot code marked by the hotspot identifier; when the blockchain node executes the deployed smart contract, if the machine code corresponding to the code of the smart contract is stored locally, executing the machine code. Through the above embodiment of the specification, the blockchain node can greatly improve the speed of executing the smart contract.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a method for executing a smart contract, a blockchain node and a node device. BACKGROUND

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. In the era of Blockchain 2.0, smart contracts appear, which promote the application range of blockchains to a new height. With smart contracts, blockchains can do not only single transfer transactions, but also can call a piece of code, which can be customized by users. SUMMARY

[0003] The present specification provides a method for executing a smart contract, a blockchain node and a node device.

[0004] The method for executing a smart contract, the blockchain node and the node device provided by the embodiment of the present specification are implemented in the following way:

[0005] A method for executing a smart contract, comprising:

[0006] A blockchain node receives a request for creating a smart contract, wherein the request includes a code of the smart contract, and the code of the smart contract includes hot spot code marked by a hot spot identifier;

[0007] After the blockchain node completes the deployment of the smart contract, the blockchain node starts to compile the code of the smart contract into machine code by JIT and stores the hot spot code marked by the hot spot identifier;

[0008] When the blockchain node executes the deployed smart contract, if the machine code corresponding to the code of the smart contract is stored locally, the machine code is executed.

[0009] A method for executing a smart contract, wherein the code of the smart contract includes hot spot code marked by a hot spot identifier, the method comprising:

[0010] After a blockchain node deploys the code of the smart contract, the blockchain node starts to compile the code of the smart contract into machine code by JIT and stores the hot spot code marked by the hot spot identifier;

[0011] When the blockchain node executes the deployed smart contract, if the machine code corresponding to the code of the smart contract is stored locally, the machine code is executed.

[0012] A blockchain node for executing a smart contract, which executes the above method.

[0013] A blockchain node for executing a smart contract, comprising:

[0014] a processor,

[0015] a memory storing a program, wherein the processor executes the program to perform the method described above.

[0016] A storage medium for storing a program, wherein the program performs the operations of the method described above when executed.

[0017] Through the above embodiments of the present specification, in the case where the blockchain node stores the machine code of the smart contract, since the machine code itself can be directly executed by the CPU, the speed of executing the smart contract of the blockchain node can be greatly improved. By including the hotspot code marked with the hotspot identifier in the code of the smart contract, the hotspot code will be inevitably JIT compiled into machine code by the blockchain node and stored, thereby flexibly JIT compiling the code of the smart contract. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0019] Figure 1 is a schematic diagram of the principle of compilation execution and interpretation execution in an embodiment;

[0020] Figure 2 is a schematic diagram of the principle of interpretation execution and JIT compilation in an embodiment;

[0021] Figure 3 is a diagrammatic process of creating a smart contract in an embodiment;

[0022] Figure 4 is a diagrammatic process of calling a smart contract in an embodiment;

[0023] Figure 5 is a schematic diagram of creating a smart contract and calling a smart contract in an embodiment;

[0024] Figure 6-1 is a flowchart of executing a smart contract in an embodiment;

[0025] Figure 6-2 is a flowchart of executing a smart contract in another embodiment;

[0026] Figure 7 is a module structure diagram of a blockchain node in an embodiment;

[0027] Figure 8 is a schematic diagram of creating and calling a smart contract in an embodiment;

[0028] Figure 9 is a schematic diagram of a process of creating and calling a smart contract in an embodiment, including a virtual machine execution process. DETAILED DESCRIPTION

[0029] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in combination with the drawings in the specification. Obviously, the described embodiments are only part of the embodiments of the specification, not all. Based on the embodiments in the specification, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the specification.

[0030] The blockchain 1.0 era usually refers to the period between 2009 and 2014, during which the blockchain application represented by Bitcoin was developed, and they were mainly committed to solving the problem of decentralization of currency and payment means. Since 2014, developers have paid more and more attention to solving the technical and scalability problems of Bitcoin. In late 2013, Vitalik Buterin released the white paper of Ethereum, “Ethereum: Next-Generation Smart Contract and Decentralized Application Platform”, which introduced smart contracts into blockchain and opened up the application of blockchain beyond the field of currency, thus starting the blockchain 2.0 era.

[0031] A smart contract is a computer contract that can be automatically executed based on specified trigger rules, and can also be regarded as a digital version of a traditional contract. The concept of smart contract was first proposed by Nick Szabo, a cross-disciplinary legal scholar and cryptography researcher, in 1994. This technology was once not used in practical industries due to the lack of programmable digital systems and related technologies, until the emergence of blockchain technology and Ethereum provided a reliable execution environment. Because of the block chain account book adopted by the blockchain technology, the generated data cannot be tampered with or deleted, and the entire account book will continue to add account book data, thus ensuring the traceability of historical data; at the same time, the decentralized operation mechanism avoids the influence of centralized factors. Based on the blockchain technology, the smart contract can not only play the advantages of smart contract in cost and efficiency, but also can avoid the interference of malicious behavior on the normal execution of the contract. The smart contract is written in a digital form into the blockchain, and the characteristics of the blockchain technology guarantee the transparency and traceability of the storage, reading and execution process, and the process cannot be tampered with.

[0032] A smart contract is essentially a program that can be executed by a computer. A smart contract, like a computer program that is widely used today, can be written in a high-level language (for example, C language, C++ language, etc.). The program code of a smart contract written in a high-level language can generally be converted into "machine code" that can be recognized and run by the CPU of a computer through a "compiler", and then the CPU can execute such machine code (or referred to as "microprocessor instructions"). This way is generally referred to as "compiling execution".

[0033] Compiling execution generally does 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 x86 instruction set, ARM instruction set, etc., and the instruction sets supported by the same manufacturer, the same brand but different generations of CPUs (such as different generations of Intel CPUs) are also not completely the same, therefore, the same program code written in the same high-level language may be different machine code converted by the compiler on different CPUs. Specifically, the compiler will combine the characteristics of the specific CPU instruction set (such as vector instruction set, etc.) to optimize the program execution speed during the conversion of the program code written in the high-level language to the machine code, and such optimization is often related to the specific CPU hardware. In this way, the same machine code can run on an x86, but another machine code may not run on an ARM; even on the same x86 platform, the instruction set is constantly enriched and expanded over time, which leads to different generations of x86 platforms running different machine codes. Machine codes of the same hardware platform can be compatible with each other, but since the program (such as machine code) running on the operating system needs to rely on the basic library of the operating system, and the basic library of different operating systems may be different (such as different versions of the basic library, etc.), it may cause the executable file of the program and the binary interface of the basic library to be incompatible, resulting in the program unable to run or running crash, so at this time, the machine code needs to be adjusted according to the difference of the operating system, thereby causing the machine code that can be supported and run to be different on the same hardware but different operating systems.

[0034] Unlike compiling execution, there is also a "interpretive execution" program running way. For example, Java language, Java source code is compiled into standard bytecode through Java compiler. Here, the compiler is not for the instruction set of any actual hardware processor, but defines a set of abstract standard instruction set. The standard bytecode compiled cannot be directly run on the hardware CPU, so a virtual machine, JVM, is introduced, which runs on a specific hardware processor to interpret and execute the compiled standard bytecode.

[0035] JVM is the abbreviation of Java Virtual Machine, which is a kind of imaginary computer, often realized by simulating various computer functions on actual computers. JVM masks the information related to specific hardware platforms, operating systems, etc., so that Java programs only need to be generated standard bytecode that can run on the Java virtual machine, and can run on multiple platforms without modification.

[0036] One of the most important features of Java language is platform independence. And using Java virtual machine is the key to achieve this feature. Generally, if a high-level language wants to run on different platforms, it needs to be compiled into different object codes. After the introduction of Java language virtual machine, Java language does not need to be recompiled when running on different platforms. Java language uses Java virtual machine to mask the information related to specific platforms, so that Java language compiler only needs to generate object code (bytecode) that runs on the Java virtual machine, and can run on multiple platforms without modification. When the Java virtual machine executes the bytecode, it interprets the bytecode into machine instructions for the specific platform. This is the reason why Java can "compile once and run anywhere".

[0037] JVM runs on a specific hardware processor, responsible for interpreting and executing bytecode for the specific processor it runs on, and shielding these underlying differences from the developer to present a standard development specification. When JVM executes bytecode, it ultimately still interprets bytecode into machine instructions for the specific platform. Specifically, after receiving the input bytecode, JVM interprets each instruction sentence by sentence and translates it into machine code suitable for the current machine to run. These processes are interpreted and executed by an interpreter called Interpreter. In this way, developers who write Java programs do not need to consider which hardware platform the program code will run on. The development of JVM itself is done by professional developers of Java organizations to adapt JVM to different processor architectures. So far, there are only a few mainstream processor architectures, such as X86, ARM, RISC-V, and MIPS. Professional developers will port JVM to platforms that support these specific hardware. In theory, Java programs can run on all machines. JVM porting work is usually provided by professional personnel of Java development organizations, which greatly reduces the burden of Java application developers.

[0038] Interpretation and execution brings cross-platform portability, but because the execution of bytecode goes through the intermediate translation process in JVM, the execution efficiency is not as high as the above-mentioned compilation and execution efficiency. The difference in efficiency can sometimes reach tens of times.

[0039] Figure 1 The commonalities and differences between the compilation execution and the interpretation execution are shown. Regardless of the interpretation execution or the compilation execution, and regardless of the physical machine or the virtual machine, the machine cannot read, understand, and then obtain the execution capability as a human being does for an application. Most of the program code needs to go through Figure 1 each step in the process shown in FIG. 1. Figure 1 The branch from the top to the left in FIG. 1 is the generation process of 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 the interpretation execution. Nowadays, the languages based on the physical machine, the Java virtual machine, or the virtual machine of other high-level languages (HLLVM) mostly follow this idea based on the modern classic compilation principle, and the source code of the program is processed by the lexical analysis and the syntax analysis before the execution, and the source code is converted into the abstract syntax tree (AST). For the implementation of a specific language, the lexical analysis, the syntax analysis, and the subsequent optimizer and the target code generator can be selected to be independent of the execution engine, and a complete compiler is formed to implement the language, and the representative is the C or C++ language. A part of the steps (such as the steps before the generation of the abstract syntax tree) can be selected to be implemented as a semi-independent compiler, and the representative is the Java language. Or all the steps and the execution engine are encapsulated in a closed black box, such as most JavaScript executors.

[0040] In order to give consideration to the cross-platform portability and the high performance as much as possible, the concept of the just-in-time compiler (JIT) is proposed. The core idea of the JIT is “how to efficiently avoid the repeated work of the interpretation instruction”. There is a large amount of repeated execution code in the computer program, such as some calculation “functions” that can be called many times in a loop in the process of the program execution. If the interpretation execution is used, the byte code to the machine code translation needs to be performed for the function in each execution of the loop. However, the actual situation is that the machine code produced by the translation of the function in tens of times is exactly the same. Naturally, after the first translation, the translated machine code of the function is cached, and in the subsequent execution process, the cached code is directly used without the need for the translation again, so that the execution efficiency is improved.

[0041] On the contrary, some functions are executed only once during the program running period (such as starting initialization), and thus these functions do not need to be cached and are directly interpreted and executed once. Therefore, a core module in the JIT technology is "hot spot analysis", that is, through analysis of which code is executed multiple times during program execution, the translated machine code is cached. For operations with a small number of executions, caching is not needed. In this way, a balance between execution efficiency and memory overhead can be achieved.

[0042] In addition, another core module in the JIT technology is compilation optimization (or called optimized compilation). Directly translated machine code is not optimized in combination with the context, and only high-frequency machine code is cached, and the performance improvement is limited. If better performance is to be obtained, the compiler can be further optimized. The way of compilation optimization generally needs relatively more time to implement.

[0043] The working principle of JIT is shown in, for example, Figure 2 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 hot spot analysis. The code judged as a hot spot (high-frequency execution) is compiled by the JIT compiler to obtain machine code, which is cached and executed, generally by the CPU under the control of the operating system (OS). The low-frequency enters the interpreter (Interpreter), is translated into machine code, and is executed by the CPU under the control of the OS.

[0044] Due to the correlation of the program code itself, there is a large optimization space in the compilation process. The execution efficiency of the optimized machine code will be much higher than that of the directly translated machine code. If better performance is to be obtained, the optimization of the compiler is necessary. The compilation process of the JIT compiler can be time-consuming. In particular, the process of the JIT compiler in compiling the bytecode for the first time can be very time-consuming, and even not as good as the interpretation execution. Then, for some java programs, if the hot spot is not very prominent, that is, the overall execution frequency is not very high, and the overall execution flow is very long, the JIT is very difficult to play the advantage of compiled execution.

[0045] In addition, an idea has been proposed, that is, AoT (Ahead of Time). AoT is equivalent to a pre-compiled execution method. Before the program runs, the bytecode is compiled once for the target execution environment to obtain machine code, and then the machine code is deployed to the target machine for execution, for example, Figure 8The running efficiency of AoT can achieve the effect of compiling execution, but the hardware, instruction set architecture and system of the target system need to be known in advance when AoT, to ensure that the compiled code can run. Moreover, in general, the number of statements required to express the same function in machine code is greater than that in bytecode, and greater than that in high-level language code. Therefore, the size of the program with the same content in machine code is likely to be greater than that in bytecode, and greater than that in high-level language code. Under the premise of knowing the hardware, instruction set architecture and system of the target system, bytecode can be compiled into machine code through AoT. At the same time, the machine code of different categories of target systems is different, so in order to have corresponding machine code that can be executed correctly on various target systems, it may be necessary to provide different versions of machine code. Therefore, the total size of machine code is generally greater than that of bytecode or high-level language code.

[0046] For example, Android uses Dalvik virtual machine before version 5.0, and uses ART virtual machine after version 5.0. Dalvik uses JIT compiler to interpret bytecode, while ART is an AoT mechanism. ART pre-compiles bytecode (the installation process of Android App is actually the installation of the bytecode of the program) into machine code when the application is installed. After removing the interpretation code, the application program on Android executes more efficiently and starts faster.

[0047] As a decentralized distributed system in blockchain, it needs to maintain distributed consistency. Specifically, a group of nodes in a distributed system each has a state machine built-in. Each state machine needs to execute the same instructions in the same order from the same initial state, keeping each state change the same, so as to ensure that the final state is consistent. However, it is difficult for each node device participating in the same blockchain network to have the same hardware configuration and software environment. Therefore, in Ethereum, a representative of blockchain 2.0, in order to ensure that the process and result of executing a smart contract on each node are the same, a virtual machine similar to JVM, Ethereum Virtual Machine (EVM), is adopted. Through EVM, the differences in hardware configuration and software environment of each node can be shielded. In this way, developers can develop a set of smart contract code based on a high-level language, and upload the bytecode obtained by compiling the smart contract code locally to the blockchain. Alternatively, developers can directly upload the smart contract code based on a high-level language to the blockchain, and the blockchain nodes further compile the corresponding bytecode through a compiler. After each node executes the same bytecode through the same EVM in the same initial state, the same final result and intermediate result can be obtained, and the differences in the underlying hardware and environment of different nodes can be shielded. In this way, the emergence of decentralized blockchain technology enables the implementation of smart contracts proposed as early as 1994, and further processing of smart contracts in an interpretation execution manner is necessary to ensure that the same execution result can be obtained on different hardware and running environment machines in a decentralized manner.

[0048] EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it, which is one of the biggest improvements of Ethereum as a representative of blockchain 2.0 over blockchain 1.0. The smart contract published and called by the user in Ethereum can run on EVM. As mentioned earlier, EVM directly runs bytecode, and the smart contract deployed on the blockchain can be in the form of bytecode or in the form of a high-level language.

[0049] As shown in Figure 3 , after Bob sends a transaction containing information for creating a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. Figure 3 The data field of the transaction can save bytecode, and the to field of the transaction can be an empty address. After the nodes reach an agreement through a consensus mechanism, the contract is successfully created, and subsequent users can call the contract.

[0050] After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, contract code and account storage can be saved in the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract causes the virtual account containing the contract code and the account storage to appear on the blockchain.

[0051] In Ethereum, as mentioned earlier, the data field containing the transaction creating the smart contract can save the bytecode of the smart contract. Bytecode is composed of a series of bytes, each byte can indicate an operation. Based on development efficiency, readability and other considerations, developers can not directly write bytecode, but choose a high-level language to write smart contract code. The smart contract code written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed to the blockchain. Ethereum supports many high-level languages, such as Solidity, Serpent, LLL language, etc.

[0052] Take Solidity language as an example, the contract written in it is very similar to the class (Class) in object-oriented programming language, and multiple members can be declared in a contract, including state variables, functions, function modifiers, events, etc. State variables are values permanently stored in the account storage of the smart contract, used to save the state of the contract.

[0053] The following is an example 1 of a simple smart contract written in Solidity language:

[0054]

[0055] Generally, after the contract is deployed on the blockchain, the "balance" state variable can be a new asset type defined in the contract. The function C() function can define the balance change operation, and the function getbalance() returns (int) function can define the operation of taking the current balance value and returning.

[0056] In addition, as Figure 4 shown, still taking Ethereum as an example, after Bob sends a transaction containing the information of calling the smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate the corresponding contract instance. Figure 4The from field of the transaction is the address of the account that initiates the call to the smart contract, the "0x692a70d2…" in the to field represents the address of the called smart contract, the value field is the value of the ether in Ethereum, and the data field of the transaction saves the method and parameters of the call to the smart contract. After calling the smart contract, the value of the balance may change. Subsequently, a client can view the current value of the balance through a certain blockchain node.

[0057] The smart contract can be executed independently in a specified manner in each node of the blockchain network, and all execution records and data are saved on the blockchain, so that when the transaction is completed, the transaction voucher saved on the blockchain cannot be tampered with and will not be lost.

[0058] The schematic diagram of creating and calling a smart contract is shown in Figure 5 In Ethereum, to create a smart contract, the following processes need to be performed: writing a smart contract in a high-level language, converting it into bytecode (for example, compiling it into bytecode using a compilation tool such as Solc or C++), and deploying it to the blockchain. In Ethereum, calling a smart contract involves initiating a transaction that points to the address of the smart contract (the address of the smart contract can be pointed to through the to field in the transaction), and the smart contract code is distributed and runs in the virtual machine of each node in the Ethereum network.

[0059] The transaction for creating a smart contract is sent to the blockchain, and after consensus, each node of the blockchain can execute the transaction. Specifically, the transaction can be executed by the EVM or WASM of the blockchain node. As mentioned earlier, at this time, a contract account corresponding to the smart contract appears on the blockchain (including, for example, the identity of the account, the hash value of the contract Codehash, and the root of the contract storage StorageRoot), and has a specific address, contract code, and account storage. The contract code and account storage can be saved in the storage of the contract account, as shown in Figure 9 The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract causes a virtual account containing the contract code and the account storage to appear on the blockchain. For a contract deployment transaction or a contract update transaction, the value of Codehash can be generated or changed. Subsequently, the blockchain node can receive a transaction request for calling the deployed smart contract, which can include the address of the called contract, the function in the called contract, and the input parameters. Generally, after consensus, each node of the blockchain can independently execute the specified called smart contract. Specifically, as shown in Figure 9As shown, the node can load the bytecode of the contract from the storage into the virtual machine (EVM or WASM) according to the address of the contract, and of course if the deployed is a contract code in the form of a high-level language, the contract code needs to be compiled into bytecode first, and then the bytecode is loaded into the virtual machine; then, the interpreter (Interpreter) interprets and executes, for example, including parsing the bytecode of the called contract to obtain the operation code (OPcode), and storing these OPcodes in the Memory of the virtual machine, and also obtaining the address of the called function; after calculating the gas consumed by executing the contract and the gas is sufficient, jump to the corresponding address of the Memory to obtain the OPcode of the called function and start execution, and perform data computation, push / pop stack and other operations on the data operated by the OPcode of the called function, thereby completing data computation. During this process, some contract context (Context) information may also be needed, such as block number, information of the initiator of the called contract, etc., which can be obtained (Get operation) from the Context. Finally, the generated state is stored in the storage through the storage interface. It should be noted that during the creation of the contract, the interpretation and execution of some functions in the contract may also be generated, such as the function of the initialization operation, at which time the code is parsed, the jump instruction is generated and stored in the Memory, and the data is operated in the Stack. During the above-mentioned interpretation and execution process, in general, functions that are repeatedly executed are not cached, and even for functions that are executed multiple times, the virtual machine needs to repeat the parsing and execution process.

[0060] As mentioned earlier, the JVM has the advantage of cross-platform portability and the need to improve performance, similarly, the EVM in the blockchain can also use JIT and AoT and other technologies to improve the performance of smart contract execution. When compiling the code of the smart contract through JIT, if the execution frequency of the code is completely counted and the hot code is analyzed through the "hot spot analysis" capability of JIT, it may not be flexible to meet the user's demand, for example, the user may want some code with less execution frequency to be executed efficiently.

[0061] The present specification provides a method embodiment for executing a smart contract, as shown, comprising: Figure 6-1 As shown, comprising:

[0062] S611: The blockchain node receives a request to create a smart contract, wherein the request includes the code of the smart contract, and the code of the smart contract includes hot code marked by a hot spot identifier.

[0063] The code of the smart contract can be code written in a high-level language, such as the aforementioned Solidity language, etc. A user can write the code of the smart contract in a high-level language locally on the user's side. The user can also write the code of the smart contract in a high-level language on the aforementioned blockchain node. The user can also write the code of the smart contract in a high-level language on another blockchain node different from the aforementioned blockchain node. The user can add the code of the smart contract in a high-level language to a transaction through a client and send the transaction to the blockchain network, for example, directly to the aforementioned blockchain node or first to another blockchain node and then forwarded to the aforementioned blockchain node. Correspondingly, upon receiving the aforementioned code of the smart contract in a high-level language, the aforementioned blockchain node can also compile the smart contract written in a high-level language using a compiler, generate bytecode, and then deploy the bytecode.

[0064] After a user writes the code of a smart contract in a high-level language locally on the user's side or on a certain blockchain node, the user can compile the code written in a high-level language using a compiler locally on the user's side or on the certain blockchain node, to generate bytecode. Then, the user can add the bytecode of the smart contract obtained by the compilation to a transaction through a client, send the transaction to the blockchain network, and deploy the bytecode in the transaction by a blockchain node.

[0065] The format of a transaction generated by a client is shown in the following formula (1), for example, where the code of a smart contract to be created can be stored in the data field of the transaction. Figures 3 to 5

[0066] S613: After the deployment of the smart contract is completed by the blockchain node, the blockchain node starts to compile the code of the smart contract into machine code through JIT and stores the hotspot code marked by the hotspot identifier.

[0067] In an Ethereum or similar public chain, consortium chain, or private chain system, a blockchain node can initiate consensus for a batch of transactions. The batch of transactions can include the transaction for creating a smart contract. After the consensus, generally, each consensus node locally stores the bytecode of the smart contract to be created. Each consensus node can execute the transaction for creating a smart contract to create a corresponding contract account, and create an address for the smart contract account according to the same rule. The addresses created by each consensus node for the same contract are the same. In this way, the deployment of the contract is completed.

[0068] ​The blockchain node can start to compile the bytecode of the smart contract into machine code through JIT and store it after completing the creation of the smart contract, i.e. after deploying the smart contract. The blockchain node can start to compile the bytecode of the smart contract through JIT immediately after completing the creation of the smart contract. This is because, after deploying the smart contract, there can be a business request to initiate a call to the deployed smart contract soon. In addition, JIT requires relatively more system resources and time, and allocating system resources for JIT when the business load of the blockchain node is heavy can affect the processing of the business; therefore, the blockchain node can also compile the bytecode of the smart contract through JIT during a relatively idle period, so as to reduce or avoid the impact on the processing of the business. In addition, the blockchain node can also compile the bytecode of the smart contract through JIT after receiving a transaction request to call the created smart contract.

[0069] The blockchain nodes compile the same smart contract bytecode through JIT locally, and each node only needs to adjust to its own processor architecture, running environment, etc., without the need to compile multiple versions of machine code. In this way, the size of the machine code stored on the node device can be greatly reduced, thereby reducing the storage overhead.

[0070] Preferably, the storage is a cache, which can make subsequent responses faster by being cached to the memory. Specifically, the memory can be a cache area opened in the virtual machine. Of course, even if it is stored to the disk, the response speed can be improved to a certain extent in many cases.

[0071] By adding a hot spot identifier in the code of the smart contract, the hot spot identifier can mark at least part of the code of the smart contract as hot code. Then, for the code (method or function) that the user wants to improve the execution efficiency, even if it is not a large number of repeated execution in all the code of the smart contract (such as not meeting the definition of “hot code” in JIT compilation), it can still be actively marked as hot code through the hot spot identifier, so that these codes can be compiled into machine code through JIT and stored, and the blockchain node can directly execute the stored machine code without interpreting and executing these codes.

[0072] The hotspot identifier can be an identifier specially indicating that the code needs to be a hotspot code, for example, indicated by the keyword Hotspot. Then, if the code of a certain method or function in the smart contract needs to be a hotspot code, the hotspot identifier Hotspot can be added in front of the method or function. In this way, the hotspot code that is expected to be generated can be indicated by the prefix Hotspot. Of course, in addition to Hotspot, any other hotspot identifier can also be used, and the present specification does not limit this; and in addition to being used as a prefix, the hotspot identifier can also be used as a suffix or in other ways, and the present specification does not limit this.

[0073] For example, for the above-mentioned code example 1, if the code of the function "function C()" needs to be a hotspot code, the hotspot identifier Hotspot can be used to indicate the function "function C()" (of course, the hotspot identifier Hotspot can also be placed in other positions), as shown in the following code example 2 (the underlined part represents the hotspot identifier):

[0074]

[0075] In example 2, the user indicates that the code corresponding to the function "function C()" needs to be a hotspot code by using the hotspot identifier Hotspot. Correspondingly, when the above-mentioned contract code written in the Solidity language is compiled into bytecode, the corresponding hotspot identifier will also be included in the bytecode, so as to mark the code corresponding to the function "function C()" as a hotspot code. For example, the keyword Hotspot can also be used as a hotspot identifier in the bytecode, that is, the hotspot code indicated by the hotspot identifier can be included in the code in the form of a high-level language and the code in the form of bytecode. However, those skilled in the art understand that the code in the form of a high-level language and the code in the form of bytecode can include hotspot codes indicated by different hotspot identifiers, for example, the code in the form of a high-level language includes hotspot codes indicated by a first hotspot identifier, and the code in the form of bytecode includes hotspot codes indicated by a second hotspot identifier, and the first hotspot identifier and the second hotspot identifier have a corresponding relationship, so that when the code in the form of a high-level language is compiled into the code in the form of bytecode, the first hotspot identifier can be automatically converted into the second hotspot identifier.

[0076] As mentioned above, by including the hotspot identifier in the code of the smart contract, the hotspot identifier can be used to mark the hotspot code, and when the bytecode of the smart contract is compiled into machine code by JIT, the hotspot code marked by the hotspot identifier can be compiled into machine code and stored. At the same time, as mentioned above, JIT compilation itself has the ability of "hotspot analysis", so in the process of translating and / or executing the code of the smart contract, the non-annotated hotspot code other than the hotspot code annotated by the hotspot identifier can also be identified according to this ability, and the non-annotated hotspot code can be compiled and stored, so that both the individual needs of users and the actual high-frequency code can be compiled into machine code to improve execution efficiency.

[0077] In identifying the non-annotated hotspot code, the number of executions is counted, for example, by a code counter of the JIT engine, so as to analyze which bytecodes are executed multiple times, and the machine code after translation is cached. As for the operations with less execution times, if they are not the hotspot code annotated by the hotspot identifier, they can not be cached, so that the best balance between execution efficiency and memory overhead can be achieved. The way of identifying the hotspot code annotated by the hotspot identifier and the non-annotated hotspot code and caching can make the process of executing the bytecode multiple times, except for the first translation, directly use the cached machine code, so as to avoid the process of translating the bytecode again, thereby reducing the time. The granularity of identifying the number of executions can be the function level, and can also be the code block level. Generally, the code block can be a part of the function, or can be composed of several functions.

[0078] The blockchain node can determine the size of the hotspot code annotated by the hotspot identifier, and if the size of the storage space for storing the machine code exceeds the size of the hotspot code annotated by the hotspot identifier, in the process of translating and / or executing the code of the smart contract, the non-annotated hotspot code other than the hotspot code annotated by the hotspot identifier can be identified, and the non-annotated hotspot code can be compiled and stored. Of course, if there is no size limit for the storage space of the machine code, the size of the hotspot code annotated by the hotspot identifier can not be considered, and the non-annotated hotspot code other than the hotspot code annotated by the hotspot identifier can always be identified by the hotspot analysis ability of JIT compilation, and the non-annotated hotspot code can be compiled and stored.

[0079] Further, the hotspot code annotated with hotspot identifier and / or non-annotated hotspot code can be compiled and / or executed with optimization to achieve better performance, so as to further improve the execution efficiency. Further optimization can be performed in JIT compilation, and the compiled machine code can be cached for subsequent calling. The machine code after compilation optimization generally has higher execution efficiency than the machine code directly translated. On the one hand, the JIT engine can bring the hardware and environment information of the blockchain node performing the compilation, so that the machine code obtained by the compilation has hardware+environment optimization, which can specifically include optimization in machine code generation, including instruction-level optimization, register allocation and optimization, etc. On the other hand, the JIT engine can analyze the context information, such as the branch jump statements executed in the current function, identify which one has the largest jump possibility, and adjust the one with the largest jump possibility to the front, so that the branch statement can be hit with a higher probability when executed. The compiler optimization process can also eliminate dead code through data flow analysis / active variable analysis, such as eliminating branches that will not be taken, and can further include optimizing loop statements, common word expression replacement, etc.

[0080] S615: When the blockchain node executes the deployed smart contract, if the machine code corresponding to the code of the smart contract is stored locally, the machine code is executed.

[0081] After the deployment of the smart contract is completed, the calling of the contract can be provided. In this way, a client (which can be different from the client initiating the creation of the contract transaction in S611) can initiate the calling of the contract. For example, the client initiates a transaction, in which the to field is the address of the aforementioned deployed smart contract, and the data field can include the called contract method and input parameters, so as to realize the calling of the deployed smart contract. Generally, a batch of transactions including the calling contract transaction are consensus, and each consensus node respectively executes the transaction.

[0082] When the blockchain node executes the deployed smart contract, it can first check whether the machine code of the called contract exists locally. If it exists, it means that the bytecode of the smart contract has been JIT compiled locally. Further, the blockchain node can directly execute the machine code corresponding to the called function / code block in the smart contract, and input the input parameters indicated in the aforementioned data field.

[0083] In the case of storing the machine code of the smart contract, since the machine code itself is directly executable by the CPU (under the control of the OS), the blockchain node can greatly improve the speed of executing the smart contract. Moreover, the case of caching the machine code of the smart contract in the memory can further improve the execution speed of the smart contract. Of course, even if it is stored in the disk, the execution speed can be improved to a certain extent.

[0084] The blockchain node executes the machine code, specifically, the machine code corresponding to the called function / code block in the stored smart contract.

[0085] In addition, when the blockchain node executes the deployed smart contract, if there is no machine code of the smart contract stored locally, it can not have to wait for the completion of JIT compilation, but interpret and execute the bytecode of the deployed smart contract. In order to respond to business requests in time, that is, to quickly respond to the business request of initiating the call of the deployed smart contract, the blockchain node can first query whether there is machine code of the called smart contract. If there is, it means that JIT compilation has been completed. If not, it means that JIT compilation has not started or has not been completed. If there is machine code, as described above, when the blockchain node executes the deployed smart contract, it can execute the machine code, thereby greatly improving the speed of executing the smart contract. If there is no machine code, the blockchain node further queries the JIT compilation status of the smart contract bytecode, which can include two cases:

[0086] Case 1: When the blockchain node executes the deployed smart contract, if there is no machine code of the smart contract stored locally, the blockchain node further queries the JIT compilation status of the smart contract bytecode. If it is in JIT compilation, the bytecode of the smart contract is interpreted and executed.

[0087] If there is no machine code of the smart contract stored locally, the blockchain node can query the JIT compilation status of the smart contract bytecode. The query result can be that it is in JIT compilation. For some business requests that call the smart contract, getting a quick response is the first choice, which is also the goal of various blockchain systems to improve the number of transactions per second (TPS). For the case that the called smart contract is in JIT, in order to respond quickly, the blockchain node can not wait for the end of JIT compilation, but interpret and execute the bytecode of the smart contract.

[0088] Case two: when the blockchain node executes the deployed smart contract, if the local does not store the machine code of the smart contract, the blockchain node also queries the current JIT compilation of the bytecode of the smart contract, if the JIT compilation has not started, it starts the JIT compilation, and interprets and executes the bytecode of the smart contract.

[0089] Similar to case one, for the case that the JIT of the called smart contract has not started, in order to respond quickly, the blockchain node can interpret and execute the bytecode of the smart contract. And for the case that the JIT has not started, the blockchain node can start the JIT compilation.

[0090] The blockchain node interprets and executes the bytecode of the smart contract can be to translate the bytecode of the smart contract sentence by sentence by EVM, and execute the translated machine code piece by piece. In addition to EVM, it can also be WASM (Web Assembly) virtual machine, JSVM (JavaScript Virtual Machine), etc. Here, EVM is mainly taken as an example for illustration.

[0091] After the blockchain node completes the JIT compilation of the smart contract, the compiled machine code is executed to perform the storage operation. In this way, when the blockchain node executes the deployed smart contract, if the local exists the machine code obtained after the JIT compilation of the called contract, it means that the local has completed the JIT compilation of the bytecode of the smart contract. Further, the blockchain node can directly execute the machine code obtained after the JIT compilation of the corresponding function called in the smart contract, and input the input parameter indicated by the aforementioned data field.

[0092] It should be noted that the blockchain node in S611 above can be different from the blockchain node in S613 and S615. This is because, as a distributed system, the nodes receiving transactions, the nodes initiating consensus and the nodes executing transactions can be different nodes, of course, they can also be the same nodes.

[0093] The following will be combined Figure 6-2 Another embodiment of the method for executing a smart contract is introduced, the code of the smart contract includes hot code marked by a hot spot identifier, and the method comprises:

[0094] S621: After the blockchain node deploys the code of the smart contract, it starts to compile the code of the smart contract into machine code by JIT and stores the hot code marked by the hot spot identifier.

[0095] The code of the smart contract is bytecode generated by compiling a high-level language; or, in the case that the code of the smart contract is written in the high-level language, the blockchain node compiles the code written in the high-level language using a compiler to generate bytecode.

[0096] The code in the high-level language form includes hotspot code marked by a first hotspot identifier, and the code in the bytecode form includes hotspot code marked by a second hotspot identifier.

[0097] After the blockchain node deploys the code of the smart contract, the code of the smart contract is compiled into machine code by JIT, which can specifically include:

[0098] The blockchain node starts JIT compiling of the code of the smart contract immediately after the smart contract is created; or,

[0099] The blockchain node uses a relatively idle time period to JIT compile the code of the smart contract after the smart contract is created; or,

[0100] The blockchain node receives a transaction request for calling the created smart contract and JIT compiles the code of the smart contract.

[0101] The code of the smart contract is compiled into machine code by JIT and stored, which includes:

[0102] In the process of translating and / or executing the code of the smart contract, non-marked hotspot code other than the hotspot code marked by the hotspot identifier is identified, and the non-marked hotspot code is compiled and stored.

[0103] In the process of translating and / or executing the code of the smart contract, non-marked hotspot code other than the hotspot code marked by the hotspot identifier is identified, and the non-marked hotspot code is compiled and stored, which includes:

[0104] If the size of the storage space for storing the machine code exceeds the size of the hotspot code marked by the hotspot identifier, in the process of translating and / or executing the code of the smart contract, non-marked hotspot code other than the hotspot code marked by the hotspot identifier is identified, and the non-marked hotspot code is compiled and stored.

[0105] The code of the smart contract is compiled into machine code by JIT, which includes:

[0106] Optimized compiling is performed in the process of translating and / or executing the hotspot code marked by the hotspot identifier and / or the non-marked hotspot code.

[0107] The granularity of identifying the non-labeled hot code includes a function level or a code block level.

[0108] S623: When the blockchain node executes the deployed smart contract, if the machine code corresponding to the code of the smart contract is stored locally, the machine code is executed.

[0109] The blockchain node executes the machine code can be to execute the machine code corresponding to the called function or code block in the stored smart contract.

[0110] In addition, when the blockchain node executes the deployed smart contract, if the machine code of the smart contract is not stored locally, the code of the smart contract can be interpreted and executed.

[0111] The specific storage manner can be caching. By caching to the memory, subsequent responses can be faster. Of course, even if stored to the disk, the response speed can be improved to a certain extent in many cases.

[0112] The blockchain node interprets and executes the code of the smart contract can include:

[0113] The blockchain node interprets and executes the code corresponding to the called function in the smart contract.

[0114] When the blockchain node executes the deployed smart contract, if the machine code of the smart contract is not stored locally, the code of the smart contract is interpreted and executed, which can specifically include:

[0115] When the blockchain node executes the deployed smart contract, if the machine code of the smart contract is not stored locally, the blockchain node further queries the JIT compilation status of the code of the smart contract, and if the JIT compilation is in progress, the code of the smart contract is interpreted and executed.

[0116] Or,

[0117] When the blockchain node executes the deployed smart contract, if the machine code of the smart contract is not stored locally, the blockchain node further queries the JIT compilation status of the code of the smart contract, and if the JIT compilation is in progress, the code of the smart contract is interpreted and executed.

[0118] The following introduces an embodiment of a blockchain node for executing a smart contract in the specification, which, as shown in Figure 7 includes:

[0119] The receiving unit 71 is configured to receive a request for creating a smart contract, wherein the request comprises code of the smart contract, and the code of the smart contract comprises hotspot code marked by a hotspot identifier;

[0120] The deployment unit 72 is configured to deploy the smart contract according to the request for creating the smart contract received by the receiving unit 71.

[0121] The compiling unit 73 is configured to start to compile the hotspot code marked by the hotspot identifier in the code of the smart contract into machine code by JIT after the deployment unit 72 completes the deployment.

[0122] The storage unit 74 is configured to store the machine code compiled by the compiling unit 73.

[0123] The execution unit 75 is configured to execute the machine code stored in the storage unit 74 when receiving a transaction request for invoking the deployed smart contract.

[0124] The code of the smart contract is bytecode generated by compiling a high-level language; or, the compiling unit 73 further compiles the code written in the high-level language into bytecode by using a compiler when the code of the smart contract is written in the high-level language.

[0125] The code in the form of the high-level language comprises hotspot code marked by a first hotspot identifier, the code in the form of the bytecode comprises hotspot code marked by a second hotspot identifier, and the first hotspot identifier corresponds to the second hotspot identifier.

[0126] The compiling unit 73 starts to compile the code of the smart contract into machine code by JIT after the deployment unit 72 completes the deployment of the smart contract, comprising:

[0127] The compiling unit 73 starts to compile the code of the smart contract by JIT immediately after the deployment unit 72 completes the creation of the smart contract; or,

[0128] The compiling unit 73 compiles the code of the smart contract by JIT by using a relatively idle time period after the deployment unit 72 completes the creation of the smart contract; or,

[0129] The compiling unit 73 compiles the code of the smart contract by JIT after the execution unit 75 receives a transaction request for invoking the created smart contract.

[0130] The storage unit 74 can be a memory or a disk storage.

[0131] The execution unit 75 executes the machine code, including that the execution unit 75 executes the machine code corresponding to the called function / code block in the stored smart contract.

[0132] In the process of translating and / or executing the code of the smart contract, the compiling unit 73 also identifies non-labeled hotspot code other than the hotspot code labeled by the hotspot identifier and compiles the non-labeled hotspot code; and the storage unit 74 also stores the non-labeled hotspot code.

[0133] In the process of translating and / or executing the code of the smart contract, the compiling unit 73 identifies non-labeled hotspot code other than the hotspot code labeled by the hotspot identifier and compiles the non-labeled hotspot code when the size of the storage space for storing the machine code exceeds the size of the occupied space of the hotspot code labeled by the hotspot identifier.

[0134] The granularity of the non-labeled hotspot code identified by the compiling unit 73 can include function level or code block level.

[0135] The compiling unit 73 can perform optimized compilation in the process of translating and / or executing the hotspot code labeled by the hotspot identifier and / or the non-labeled hotspot code.

[0136] When the execution unit 75 executes the deployed smart contract, if the storage unit 74 does not store the machine code of the smart contract, the code of the smart contract is interpreted and executed.

[0137] The execution unit 75 interprets and executes the code of the smart contract, including:

[0138] The execution unit 75 interprets and executes the code corresponding to the called function in the smart contract.

[0139] When the deployment unit 72 executes the deployed smart contract, if the storage unit 74 does not store the machine code of the smart contract, the execution unit 75 interprets and executes the code of the smart contract, including:

[0140] When the execution unit 75 executes the deployed smart contract, if the storage unit 74 does not store the machine code of the smart contract, the execution unit 75 also queries the JIT compilation status of the code of the smart contract, and if it is in JIT compilation, the code of the smart contract is interpreted and executed.

[0141] Or,

[0142] When the execution unit 75 executes the deployed smart contract, if the storage unit 74 does not store the machine code of the smart contract, the execution unit 75 further queries the JIT compilation status of the code of the smart contract, and if the AoT compilation has not started, the JIT compilation is started, and the code of the smart contract is executed by interpretation.

[0143] In addition, the blockchain node that executes the smart contract can also execute the method of S621 to S623.

[0144] The specification also provides a blockchain node embodiment, comprising:

[0145] a processor,

[0146] a memory storing a program, wherein when the processor executes the program, the smart contract is executed in the manner described above.

[0147] The specification also provides a storage medium embodiment for storing a program, wherein the program, when executed, executes the foregoing method.

[0148] In the 1990s, it was relatively easy to distinguish whether an improvement in a technology was a hardware improvement (e.g., an improvement in the circuit structure of a diode, transistor, switch, etc.) or a software improvement (an improvement in a method flow). However, as technology has evolved, many improvements in method flows today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flows into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using hardware entity modules. For example, a programmable logic device (PLD) such as a field programmable gate array (FPGA) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming the PLD, rather than by ordering a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented using "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, by simply logically programming a method flow using the above-mentioned hardware description languages and programming it into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0149] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0150] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present specification does not exclude that with the development of computer technology in the future, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, electronic mail devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0151] Although the method operations of the embodiments of the present disclosure are described in a particular, sequential order, one or more of the method operations can be omitted, or the method operations can be performed in an order other than the described order. Additionally, one or more of the method operations can be performed concurrently, or with partial concurrence. Furthermore, one or more of the method operations can be performed by different entities, or over different time periods. The term "including" as used herein is intended to mean "comprising," such that the process, method, article, or apparatus that includes elements in addition to those specified. As used in this description, the term "coupled" means a direct or indirect connection, which can be physical or logical. The term "coupled" does not relate to a direct connection or wiring.

[0152] For the sake of description, the above-described apparatus is described as various modules to describe the functions of the apparatus. Of course, when implementing one or more embodiments of the present disclosure, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same functions can be combined into a plurality of sub-modules or sub-units. The apparatus embodiments described above are merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0153] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of one or more flows or one or more blocks in the flowcharts and / or block diagrams can be implemented by an apparatus. Figure 1 The functions of one or more flows or one or more blocks in the flowcharts and / or block diagrams can be implemented by an apparatus.

[0154] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0155] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

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

[0157] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0158] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules 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 discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0159] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0160] The one or more embodiments described herein can 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. The one or more embodiments described herein can 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 can be located in both local and remote computer storage media including memory storage devices.

[0161] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific feature, structure, material or characteristic being described in connection with that embodiment or example is included in at least one embodiment or example in the specification. Illustrative representations of the above terms in the specification are not necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics being described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine features of different embodiments or examples and characteristics of different embodiments or examples in a manner that is not mutually contradictory.

[0162] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1.A method for executing a smart contract, applied to a virtual machine running on a blockchain node, comprising: receiving a request for creating a smart contract, the request including code of the smart contract, the code of the smart contract including hotspot code marked by a hotspot identifier; after completing deployment of the smart contract, starting to compile the code of the smart contract into machine code by JIT, and storing machine code of the hotspot code marked by the hotspot identifier; when executing the deployed smart contract, if the JIT compilation is completed, executing the compiled and stored machine code. 2.The method of claim 1, wherein the code of the smart contract is bytecode generated by compiling code written in a high-level language; or in the case that the code of the smart contract is code written in a high-level language, using a compiler to compile the code written in the high-level language to generate bytecode. The method further comprises: 3.The method of claim 2, wherein the code of the smart contract is written by a user, and the writing location includes one of the following: a local device of the user, the blockchain node, and another blockchain node different from the blockchain node. 4.The method of claim 2, wherein the code written in the high-level language includes hotspot code marked by a first hotspot identifier, the bytecode generated by compiling the code written in the high-level language includes hotspot code marked by a second hotspot identifier, and the first hotspot identifier corresponds to the second hotspot identifier. 5.The method of claim 1, wherein after completing deployment of the smart contract, starting to compile the code of the smart contract into machine code by JIT, comprises: starting to compile the code of the smart contract by JIT after completing creation of the smart contract; or starting to compile the code of the smart contract by JIT using a relatively idle time period after completing creation of the smart contract; or starting to compile the code of the smart contract by JIT after receiving a transaction request for calling the created smart contract. 6.The method of claim 1, further comprising: in the process of translating and / or executing the code of the smart contract, identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier, and compiling and storing the non-marked hotspot code. 7.The method of claim 6, wherein in the process of translating and / or executing the code of the smart contract, identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier, and compiling and storing the non-marked hotspot code, comprises: if a size of storage space for storing the machine code exceeds a size of occupied space of the hotspot code marked by the hotspot identifier, then in the process of translating and / or executing the code of the smart contract, identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier, and compiling and storing the non-marked hotspot code. 8.The method of claim 6, wherein the granularity of identifying non-marked hotspot code includes a function level or a code block level. ​ 9.The method of claim 6, wherein the compiling the code of the smart contract into machine code by JIT comprises: optimizing the compiling in the process of translating and / or executing the hot code marked by the hot spot identifier and / or the non-marked hot code. 10.The method of claim 9, wherein the optimizing the compiling comprises at least one of: compiling in combination with the context information of the code and the context information of the blockchain node, the context information of the blockchain node comprising hardware information and environment information of the blockchain node; eliminating dead code by data flow analysis or live variable analysis; optimizing loop statements in the code; replacing common dictionary expressions in the code. 11.The method of claim 1, wherein the executing the machine code comprises: executing the machine code corresponding to the called function or code block in the stored smart contract. 12.The method of claim 1, further comprising: if the JIT compiling is not completed when the deployed smart contract is executed, interpreting and executing the code of the smart contract. 13.The method of claim 12, wherein the interpreting and executing the code of the smart contract comprises: interpreting and executing the code corresponding to the called function in the smart contract. 14.The method of claim 12, wherein if the JIT compiling is not completed when the deployed smart contract is executed, the interpreting and executing the code of the smart contract comprises: if the JIT compiling is not completed when the deployed smart contract is executed, further querying the JIT compiling status of the code of the smart contract, and if the JIT compiling is in progress, interpreting and executing the code of the smart contract; or if the JIT compiling is not completed when the deployed smart contract is executed, further querying the JIT compiling status of the code of the smart contract, and if the JIT compiling has not started, starting the JIT compiling and interpreting and executing the code of the smart contract. 15.The method of claim 1, wherein the storing is caching. 16.The method of claim 1, wherein the virtual machine comprises at least one of: JVM, WASM, Dalvik, and ART. 17.The method of claim 1, wherein the blockchain node belongs to a public chain, a private chain, or a consortium chain. 18.A method for executing a smart contract, applied to a virtual machine running on a blockchain node, the code of the smart contract comprising hot code marked by a hot spot identifier, the method comprising: after deploying the code of the smart contract, starting to compile the code of the smart contract into machine code by JIT, and storing the machine code of the hot code marked by the hot spot identifier; when the deployed smart contract is executed, if the JIT compiling is completed, executing the machine code obtained by compiling and stored. 19.The method of claim 18, wherein the code of the smart contract is bytecode generated by compiling code written in a high-level language; or ​ ​ The method further comprises: In the case that the code of the smart contract is written in a high-level language, a compiler is employed to compile the code written in the high-level language to generate bytecode. 20.The method of claim 19, wherein the code of the smart contract is written by a user, and the writing location comprises one of: a local device of the user, the blockchain node, and another blockchain node different from the blockchain node. 21.The method of claim 19, wherein the code written in the high-level language comprises hotspot code marked by a first hotspot identifier, and the bytecode generated by compiling the code written in the high-level language comprises hotspot code marked by a second hotspot identifier, and the first hotspot identifier corresponds to the second hotspot identifier. 22.The method of claim 18, wherein the compiling the code of the smart contract by JIT to generate machine code comprises: starting the JIT compiling of the code of the smart contract after the smart contract is created; or, starting the JIT compiling of the code of the smart contract by using a relatively idle time period after the smart contract is created; or starting the JIT compiling of the code of the smart contract after receiving a transaction request for invoking the created smart contract. 23.The method of claim 18, further comprising: identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier and compiling and storing the non-marked hotspot code during the translating and / or executing of the code of the smart contract. 24.The method of claim 23, wherein the identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier and compiling and storing the non-marked hotspot code during the translating and / or executing of the code of the smart contract comprises: identifying non-marked hotspot code other than the hotspot code marked by the hotspot identifier and compiling and storing the non-marked hotspot code during the translating and / or executing of the code of the smart contract if a size of a storage space for storing the machine code exceeds a size of a space occupied by the hotspot code marked by the hotspot identifier. 25.The method of claim 23, wherein the granularity of identifying the non-marked hotspot code comprises a function level or a code block level. 26.The method of claim 23, wherein the compiling the code of the smart contract by JIT to generate machine code comprises: optimizing the compiling during the translating and / or executing of the hotspot code marked by the hotspot identifier and / or the non-marked hotspot code. 27.The method of claim 26, wherein the optimizing the compiling of the code comprises at least one of: compiling in combination with a front and back correlation of the code, the front and back correlation comprising hardware information and environment information of the blockchain node and context information of the code; eliminating dead code by data flow analysis or live variable analysis; optimizing a loop statement in the code; replacing a common word expression in the code. 28.The method of claim 18, wherein the executing the machine code comprises: executing the stored machine code corresponding to the called function or code block in the smart contract. 29.The method of claim 18, further comprising: when the deployed smart contract is executed, if the JIT compilation is not completed, then interpreting the code of the smart contract. 30.The method of claim 29, wherein the interpreting the code of the smart contract comprises: interpreting the code corresponding to the called function in the smart contract. 31.The method of claim 29, wherein when the deployed smart contract is executed, if the JIT compilation is not completed, then interpreting the code of the smart contract comprises: when the deployed smart contract is executed, if the JIT compilation is not completed, then further querying the JIT compilation status of the code of the smart contract, if the JIT compilation is in progress, then interpreting the code of the smart contract; or, when the deployed smart contract is executed, if the JIT compilation is not completed, then further querying the JIT compilation status of the code of the smart contract, if the JIT compilation has not started, then starting the JIT compilation and interpreting the code of the smart contract. 32.The method of claim 18, wherein the storing is caching. 33.The method of claim 18, wherein the virtual machine comprises one of: JVM, WASM, Dalvik, ART. 34.The method of claim 18, wherein the blockchain node belongs to one of: public chain, private chain, or consortium chain. 35.A blockchain node for executing a smart contract, comprising: a processor, a memory storing a program, wherein when the processor executes the program, the method of any one of claims 1-17 or 18-34 is performed. 36.A storage medium for storing a program, wherein when the program is executed by a processor, the operations of any one of claims 1-17 or 18-34 are performed.

Images