WO2022237590A1 - Procédé de mise à niveau de contrat intelligent et système de chaîne de blocs - Google Patents

Procédé de mise à niveau de contrat intelligent et système de chaîne de blocs Download PDF

Info

Publication number
WO2022237590A1
WO2022237590A1 PCT/CN2022/090384 CN2022090384W WO2022237590A1 WO 2022237590 A1 WO2022237590 A1 WO 2022237590A1 CN 2022090384 W CN2022090384 W CN 2022090384W WO 2022237590 A1 WO2022237590 A1 WO 2022237590A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
blockchain
bytecode
transaction
upgrade
Prior art date
Application number
PCT/CN2022/090384
Other languages
English (en)
Chinese (zh)
Inventor
林志平
Original Assignee
支付宝(杭州)信息技术有限公司
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2022237590A1 publication Critical patent/WO2022237590A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/4552—Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM

Definitions

  • This manual relates to the blockchain field, in particular to a smart contract upgrade method and a blockchain system.
  • blockchain nodes in related technologies need to receive instruction information sent by users before they can perform corresponding operations.
  • the user needs to participate in at least two interactions, and the efficiency of contract upgrade is low.
  • one or more embodiments of this specification provide a smart contract upgrade method and a blockchain system.
  • a blockchain system 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.
  • 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. 5 is an interaction diagram of a smart contract upgrade method shown in an exemplary embodiment of this specification.
  • 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.
  • the specific CPU instruction set such as the vector instruction set, etc.
  • 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.
  • 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.
  • the Java source code is compiled into a standard bytecode (bytecode) through a Java compiler.
  • 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.
  • Java virtual machine 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. .
  • 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.
  • 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.
  • 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.
  • HLLVM High-Level Language Virtual Machine
  • 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).
  • 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.
  • JIT Just-In-TimeCompiler
  • 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.
  • JIT technology another core module in JIT technology is compilation optimization (or called optimized compilation).
  • 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.
  • JIT Java bytecode
  • 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 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).
  • OS operating system
  • 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.
  • JIT compiler compilation may be time-consuming.
  • 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.
  • JIT compilation has become an important means to improve the efficiency of program execution.
  • 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.
  • 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.
  • 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.
  • this specification needs to prioritize the deployment of bytecodes of smart contracts.
  • 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.
  • each blockchain node needs to JIT compile the bytecode by itself, which takes up more blockchain processing. resource.
  • 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.
  • 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.
  • 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.
  • 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.
  • the aforementioned blockchain node responsible for JIT compiling the smart contract is referred to as the first blockchain node.
  • the first blockchain node can determine whether to perform JIT compilation on the smart contract in the contract deployment transaction according to actual needs.
  • 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.
  • the process of JIT compilation is controlled by the user, which improves the controllability of the contract upgrade.
  • 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.
  • 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.
  • 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.
  • timing for performing JIT compilation can also be determined according to actual conditions.
  • 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.
  • 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.
  • the bytecode of the smart contract can be JIT compiled when the first blockchain node does not need to process transactions.
  • the JIT compilation for bytecode and contract deployment operations can be performed in parallel.
  • the first blockchain node can simultaneously perform JIT compilation on the bytecode in the contract deployment transaction.
  • the machine code of the smart contract can be quickly obtained, and then the deployed bytecode can be upgraded in a timely manner.
  • the first blockchain node 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.
  • 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.
  • 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.
  • 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.
  • the user 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.
  • 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.
  • 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.
  • smart contracts deployed in the blockchain network may be invoked by users at any time.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • this specification needs to prioritize the deployment of the bytecode of the smart contract.
  • 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.
  • the blockchain node responsible for JIT compiling the smart contract in this specification can be any node in the blockchain system.
  • any blockchain node may be node 41 in FIG. 4 , that is, node 41 is the first blockchain node in the previous embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • smart contracts deployed in the blockchain system may be invoked by users at any time.
  • 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.
  • 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.
  • each blockchain node 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the client may contain a contract deployment control, so that the user can initiate a contract deployment request to the client through the control.
  • 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.
  • 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.
  • the first blockchain node 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.
  • Step 503 the first blockchain node performs JIT compilation on the bytecode in the contract deployment transaction to obtain the corresponding machine code.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first blockchain node 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 .
  • the first blockchain node 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.
  • the blockchain node 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.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • 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.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

Procédé de mise à niveau de contrat intelligent et nœud de chaîne de blocs. Le procédé comprend les étapes suivantes : tous les nœuds de chaîne de blocs dans un réseau de chaîne de blocs obtiennent respectivement une transaction de déploiement de contrat comprenant un code à octets, et déploient un contrat intelligent correspondant sur la base de la transaction de déploiement de contrat (302) ; un premier nœud de chaîne de blocs dans le réseau de chaîne de blocs effectue une compilation JIT sur le code à octets pour obtenir un code machine du contrat intelligent, et génère une transaction de mise à niveau de contrat pour le contrat intelligent sur la base du code machine (304) ; tous les nœuds de chaîne de blocs dans le réseau de chaîne de blocs obtiennent respectivement la transaction de mise à niveau de contrat, et mettent à niveau, sur la base de la transaction de mise à niveau de contrat, un code de contrat correspondant au contrat intelligent à partir du code à octets en code machine (306).
PCT/CN2022/090384 2021-05-11 2022-04-29 Procédé de mise à niveau de contrat intelligent et système de chaîne de blocs WO2022237590A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110510125.9 2021-05-11
CN202110510125.9A CN113220326B (zh) 2021-05-11 2021-05-11 智能合约升级方法及区块链系统

Publications (1)

Publication Number Publication Date
WO2022237590A1 true WO2022237590A1 (fr) 2022-11-17

Family

ID=77094607

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090384 WO2022237590A1 (fr) 2021-05-11 2022-04-29 Procédé de mise à niveau de contrat intelligent et système de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN113220326B (fr)
WO (1) WO2022237590A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113220326B (zh) * 2021-05-11 2022-09-16 支付宝(杭州)信息技术有限公司 智能合约升级方法及区块链系统
CN114553912A (zh) * 2022-02-24 2022-05-27 平安国际智慧城市科技股份有限公司 基于区块链的健康档案共享方法、系统、设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190278767A1 (en) * 2017-08-23 2019-09-12 Zhongan Information Technology Service Co., Ltd. Smart contract upgrade method and system based on alliance chain
US20200119905A1 (en) * 2018-10-15 2020-04-16 Adobe Inc. Smart contract platform for generating and customizing smart contracts
CN111770206A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种部署智能合约的方法、区块链节点和存储介质
CN111768184A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法及区块链节点
CN111814202A (zh) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点和存储介质
CN112596754A (zh) * 2021-03-01 2021-04-02 腾讯科技（深圳）有限公司 区块链智能合约部署方法及装置
CN113220327A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约升级方法及区块链系统
CN113220326A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约升级方法及区块链系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019120316A2 (fr) * 2019-03-26 2019-06-27 Alibaba Group Holding Limited Système et procédé pour implémenter différents types de contrats à chaîne de blocs
SG11202004455UA (en) * 2019-06-28 2020-06-29 Alibaba Group Holding Ltd System and method for executing different types of blockchain contracts
CN110413304B (zh) * 2019-07-31 2023-07-14 中国工商银行股份有限公司 基于区块链网络的智能合约热升级方法及装置
CN111538521B (zh) * 2020-04-24 2024-02-09 中国工商银行股份有限公司 智能合约部署、交易方法及装置
CN111736954B (zh) * 2020-06-24 2024-01-05 陈鹏 多智能合约虚拟机实现方法、多智能合约虚拟机及系统
CN113872948A (zh) * 2020-08-31 2021-12-31 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点和节点设备
CN112866392B (zh) * 2020-08-31 2023-06-30 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点、系统和存储介质
CN111770116B (zh) * 2020-08-31 2020-12-15 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点、存储介质
CN111770204B (zh) * 2020-08-31 2021-10-22 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点和存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190278767A1 (en) * 2017-08-23 2019-09-12 Zhongan Information Technology Service Co., Ltd. Smart contract upgrade method and system based on alliance chain
US20200119905A1 (en) * 2018-10-15 2020-04-16 Adobe Inc. Smart contract platform for generating and customizing smart contracts
CN111770206A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种部署智能合约的方法、区块链节点和存储介质
CN111768184A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法及区块链节点
CN111814202A (zh) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法、区块链节点和存储介质
CN112596754A (zh) * 2021-03-01 2021-04-02 腾讯科技（深圳）有限公司 区块链智能合约部署方法及装置
CN113220327A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约升级方法及区块链系统
CN113220326A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约升级方法及区块链系统

Also Published As

Publication number Publication date
CN113220326B (zh) 2022-09-16
CN113220326A (zh) 2021-08-06

Similar Documents

Publication Publication Date Title
CN111770113B (zh) 一种执行智能合约的方法、区块链节点和节点设备
CN111814202B (zh) 一种执行智能合约的方法、区块链节点和存储介质
CN111770205B (zh) 一种执行智能合约的方法、区块链节点、系统和存储介质
WO2022237590A1 (fr) Procédé de mise à niveau de contrat intelligent et système de chaîne de blocs
CN111770116B (zh) 一种执行智能合约的方法、区块链节点、存储介质
EP3961973B1 (fr) Procédés, n uds de chaîne de blocs et supports d'enregistrement pour déployer un contrat intelligent
CN111815310B (zh) 一种执行智能合约的方法、区块链节点和存储介质
CN111770204B (zh) 一种执行智能合约的方法、区块链节点和存储介质
EP3961460B1 (fr) Procédés, noeuds de chaîne de blocs et supports d'enregistrement pour déployer un contrat intelligent
EP3961390A1 (fr) Procédé d'exécution de contrat intelligent et noeud de chaîne de blocs
EP3961438B1 (fr) Procédé d'exécution de contrat intelligent, noeud de chaîne de blocs et support d'informations
CN111768200A (zh) 一种部署智能合约的方法、区块链节点和存储介质
CN111770202B (zh) 一种执行智能合约的方法、区块链节点和存储介质
CN113220327B (zh) 智能合约升级方法及区块链系统
You et al. A static region‐based compiler for the Dalvik virtual machine

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22806558

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22806558

Country of ref document: EP

Kind code of ref document: A1