A blockchain contract checking method, blockchain contract compilation method and device
By AOT compiling the blockchain contract on the client, a contract machine code that does not contain direct execution instructions is generated, and security checks and replacements are performed on the blockchain node, the machine code generated after AOT compilation may include The problem of dangerous code has achieved the effect of improving the security of blockchain contract execution.
Patent Information
- Application Number
- CN202210181995.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-02-25
- Publication Date
- 2025-02-25
- Estimated Expiration
- 2042-02-25
AI Technical Summary
The machine code generated after the AOT of the existing blockchain contract may contain memory access instructions that can be directly executed, resulting in system security risks.
AOT compilation of contracts is performed on the client side, and a contract binary code does not contain real machine code preset instructions are generated. Before executing the contract, the blockchain node scans the contract machine code to confirm that it does not contain the above preset instructions. If included, it is judged as dangerous code and will not be executed. Then, a legitimacy check and an out-of-bounds check of the preset instructions are performed, and the placeholder instructions are replaced to ensure safe execution.
Through this method, the systemic security risks caused by unsecure machine codes generated by non-trusted clients are avoided, and the execution security of blockchain contracts is improved, while ensuring the execution efficiency of contracts is ensured.
Smart Images

Figure CN114546407B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a blockchain contract checking method, a blockchain contract compilation method and a device. Background Art
[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. Blockchain contracts, or smart contracts, refer to computer codes deployed on blockchain that can automatically execute protocols. Using blockchain contracts to implement established protocols or rules can improve the execution efficiency of protocols or rules, and can avoid subjective cheating in execution, and has a wide range of application scenarios. Summary of the invention
[0003] The purpose of the present invention is to provide a blockchain contract compilation and checking scheme to improve the security of blockchain contract execution.
[0004] In a first aspect, the present specification provides a blockchain contract checking method, the method being executed by a blockchain node, the method comprising:
[0005] Obtaining a contract machine code, wherein the contract machine code includes a first preset instruction, wherein the first preset instruction is used to indicate: performing a legitimacy check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legitimacy check passes;
[0006] Check whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable.
[0007] A second aspect of this specification provides a blockchain contract compilation method, the method comprising:
[0008] Get the contract code;
[0009] The contract code is compiled to generate a contract machine code, wherein the contract machine code includes a first preset instruction and does not include a second preset instruction; the first preset instruction is used to indicate: performing a legitimacy check corresponding to the second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legitimacy check passes.
[0010] A third aspect of the present specification provides a blockchain contract checking device, which is deployed on a blockchain node and includes:
[0011] A preset instruction acquisition unit is configured to acquire a contract machine code, wherein the contract machine code includes a first preset instruction, and the first preset instruction is used to indicate: performing a legality check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legality check passes;
[0012] The execution judgment unit is configured to check whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable.
[0013] A fourth aspect of this specification provides a blockchain contract compilation device, the device comprising:
[0014] A code acquisition unit, configured to acquire a contract code;
[0015] The machine code generation unit is configured to compile the contract code to generate a contract machine code, wherein the contract machine code includes a first preset instruction and does not include a second preset instruction; the first preset instruction is used to indicate: performing a legitimacy check corresponding to the second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legitimacy check passes.
[0016] In a fifth aspect, a computer-readable storage medium is provided, on which a computer program or instruction is stored. When the computer program or instruction is executed in a computer, the computer executes the method described in the first and second aspects.
[0017] In a sixth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores a computer program or instructions, and the processor implements the methods described in the first and second aspects when executing the computer program or instructions. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0019] Figure 1 A diagram showing a blockchain architecture in one embodiment is shown;
[0020] Figure 2 is a schematic diagram of the AOT machine code in an embodiment of this specification;
[0021] Figure 3 is a schematic diagram of a machine code after replacing a preset indication in an embodiment of the present specification;
[0022] Figure 4 is a flowchart of a blockchain contract checking method in an embodiment of this specification;
[0023] Figure 5 is a schematic diagram of an AOT machine code that is preset as a placeholder instruction in an embodiment of the present specification;
[0024] Figure 6 is a schematic diagram of a machine code after replacing a placeholder instruction in an embodiment of the present specification;
[0025] Figure 7 is a schematic diagram of an AOT machine code that is preset as a placeholder in an embodiment of the present specification;
[0026] Figure 8 It is a schematic diagram of an AOT machine code that is preset to indicate a blockchain function call in an embodiment of this specification;
[0027] Fig. 9 This is a flowchart of a blockchain contract compilation method in an embodiment of this specification;
[0028] Fig.10 This is an architectural diagram of a blockchain contract checking device in an embodiment of this specification;
[0029] Fig.11 This is an architectural diagram of a blockchain contract compilation device in an embodiment of this specification; DETAILED DESCRIPTION
[0030] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.
[0031] Figure 1 FIG. 1 shows a blockchain architecture diagram in an embodiment. Figure 1As shown, the blockchain 100 includes, for example, 6 nodes. The lines between the nodes schematically represent P2P (Peer to Peer) connections. These nodes can store the full amount of ledgers, that is, store the status of all blocks and all accounts. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database. It can be understood that Figure 1 Although it is shown that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as Byzantine nodes can exist inside the blockchain, but the blockchain does not reflect Byzantine behavior to the outside. In general, some Byzantine fault tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).
[0032] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case where the transaction is a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case where the transaction calls a smart contract in the blockchain, the From field indicates the account address that initiates the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract, and the incoming parameters of the function, etc., which are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.
[0033] The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in Ethereum is to initiate a transaction pointing to the smart contract address, so that each node in the Ethereum network can run the smart contract code in a distributed manner. It should be noted that in addition to being able to create smart contracts by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some data structures, parameters, properties and methods of the blockchain network can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts).
[0034] In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e. deploying a contract) to Figure 1 In the blockchain shown, the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined, and each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, so that the contract is successfully created.
[0035] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In the blockchain shown, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is reached in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.
[0036] There are usually two ways to compile existing blockchain contracts. The first is JIT compilation (just-in-time compilation), which refers to deploying contract code (such as WSAM bytecode, i.e. WebAssembly bytecode) on the blockchain, and dynamically translating it into local machine code when the contract code is executed for the first time. JIT compilation is a generalized dynamic compilation, i.e. a type of runtime compilation. The disadvantage of this method is that JIT often takes a long time, and before JIT is completed, the contract can only be executed by interpreting the execution method, which has poor execution efficiency. The second is ahead-of-time compilation (AOT for short), or static compilation. That is, the contract is compiled into the local machine code of the blockchain node in advance and deployed to the blockchain. Since the local machine code is deployed, the advantage of this method is that the execution efficiency is high. However, this method also has the following problems: Since AOT contracts are usually compiled and generated on the client side, that is, the compilation tool is on the user side, the user can modify the compiler so that the generated AOT machine code breaks the restrictions of Web Assembly, such as memory access boundaries. Executing such AOT machine code will cause systemic security risks.
[0037] In order to solve the above technical problems, the embodiment of this specification provides a blockchain contract checking method. The core idea is: AOT compilation of the contract is performed on the client, and the contract binary code obtained after AOT compilation does not contain the real machine code preset instructions (such as memory access instructions). Before the blockchain executes the contract, the contract binary code (machine code) is scanned to confirm that it does not contain the above preset instructions. If the above instructions are included, it is judged as a dangerous code and will not be executed. After that, the preset instructions are checked for legality, and the code for executing the preset instructions after the check is passed (for example, memory access instructions that have been checked for address out-of-bounds) is filled into the contract binary code for execution. Using this method, if the AOT contract deployed on the blockchain is not generated by a legal compilation tool, it will be checked and found before the contract is executed and will not be executed, and the instructions in the contract that may cause systemic risks are checked for security by the code provided by the blockchain node, which can avoid causing systemic security risks. Figure 2 Schematic diagram of AOT machine code in an embodiment of this specification. Figure 2 As shown, for example, when the client compiles the AOT machine code, for example, the memory access instruction, the actual memory instruction on the target execution machine is not used, but the corresponding instruction indication (such as the replacement instruction) is used instead. The instruction does not actually execute the memory access instruction, but only includes the execution parameters of the instruction, such as the address to be accessed, and may also include parameters or method descriptions required for, for example, address out-of-bounds checking. Figure 3 FIG. 1 is a schematic diagram of a machine code after replacing a preset indication in an embodiment of the present specification. Figure 3 As shown, before loading and executing the contract on the blockchain, the contract binary code (machine code) is scanned to confirm that the code does not contain real memory access instructions, but only contains the corresponding instructions of the above memory access instructions, otherwise it can be judged as illegal code and not executed. In addition, during the code scanning process, the above instruction instructions are replaced with codes that perform address access out-of-bounds checks on memory access instructions according to execution parameters, and execute the memory access instructions (actually supported by the blockchain hardware device) after the check passes.
[0038] The blockchain contract compilation and checking scheme provided by the embodiments of this specification has the following advantages: On the one hand, the blockchain node is prohibited from including preset instructions such as memory access instructions that can be directly executed by the processor in the contract compiled by AOT. All memory access instructions are inserted by the blockchain node during execution, or implemented by calling the node local code, and the memory access instructions generated by the platform are all executed before the execution of the cross-bounds check. The execution legality check eliminates the problem of unsafe machine code caused by untrusted client compilation and ensures the security of contract execution on the blockchain node. On the other hand, to ensure the security of contract execution, only the AOT machine code needs to be disassembled and replaced, with low logical complexity and high execution speed, that is, the cost of ensuring the security of contract execution is very small, ensuring the efficiency of contract execution.
[0039] The detailed process of this method is further explained below.
[0040] Figure 4 is a flow chart of a blockchain contract checking method in one embodiment of this specification. The method is executed by a blockchain node, such as Figure 4 The method comprises the following steps S41 and S42. Figure 4 The steps shown.
[0041] First, in step S41, the contract machine code is obtained, and the contract machine code includes a first preset instruction. The first preset instruction is used to indicate: a legality check corresponding to a second preset instruction is performed through the first machine code provided by the blockchain node, and the second preset instruction is executed after the legality check passes.
[0042] According to different implementations, different specific methods can be used to obtain the contract machine code, which is not limited in this specification. For example, in one implementation, when executing a transaction to deploy a contract, it can be determined whether the contract machine code included in the transaction can be deployed to the blockchain. In this case, the contract machine code can be obtained from the transaction to deploy the contract. In another implementation, when executing a transaction to call a contract, it can be determined whether the contract code is executable before executing the contract code, and the contract machine code can be obtained from the state storage of the contract in the state database of the blockchain node.
[0043] Contract machine code, that is, machine code compiled by AOT, such as machine code compiled on the client, or machine code compiled on other untrusted blockchain nodes. The binary instructions included in the conventional AOT-compiled machine code are binary instructions supported by the target execution machine (blockchain node). In the embodiment of this specification, when compiling a contract, the client should replace the preset instruction (second preset instruction) on the target machine with the corresponding preset instruction indication (first preset instruction) so that the obtained contract machine code does not include the preset instruction. The instruction indication may, for example, include the execution parameters of the instruction, but not the binary instruction itself. Therefore, the contract machine code obtained by the blockchain node in step S41 should not include the above-mentioned preset instruction, but only include the preset instruction indication used to replace it, for example Figure 2 shown.
[0044] According to different implementations, the first preset instruction may have different specific forms. In one implementation, the first preset instruction may be a first placeholder instruction corresponding to the second preset instruction. Figure 5 Schematic diagram of AOT machine code in an embodiment of this specification. Figure 5 As shown, for example, in the AOT machine code compiled by the client, the real memory access instruction InstructionA (the second preset instruction) is not included, but only a placeholder instruction (the first placeholder instruction) is included to replace it. In one example, the placeholder instruction can, for example, carry execution parameters and parameters describing the specific method of the out-of-bounds access check. In a specific embodiment, the out-of-bounds access check can be performed based on the execution parameters and check method parameters carried by the placeholder instruction. In a specific embodiment, the length of the placeholder instruction can be pre-agreed.
[0045] In another embodiment, the first preset indication may also be a first placeholder space corresponding to the second preset instruction. The second machine code may be filled in the first placeholder space in the contract machine code; and the second machine code includes the first machine code and the second preset instruction. Figure 6 Schematic diagram of AOT machine code that is preset as a placeholder in an embodiment of this specification. Figure 6 As shown, for example, in the AOT machine code compiled by the client, the real memory access instruction (InstructionA) is not included, but only the placeholder space (first placeholder space) corresponding to the instruction is included. In one example, the placeholder space can be filled with execution parameters and a description of the specific method of the access out-of-bounds check.
[0046] In another embodiment, the first preset instruction may also be a call to a first function. The first function is a function provided by a blockchain node, and the first function includes the first machine code and the second preset instruction. Figure 7 Schematic diagram of the AOT machine code that is preset as a blockchain function call in an embodiment of this specification. Figure 7 As shown, for example, in the AOT machine code compiled by the client, the real memory access instruction (InstructionA) is not included, but only the call to the blockchain node local function corresponding to the instruction. In one example, the function call can carry the instruction execution parameters and the specific method of the access out-of-bounds check. When the blockchain node executes the security contract, the local function is directly used to check the instruction for access out-of-bounds, and the real memory access instruction is executed after the check passes.
[0047] In addition, according to different implementations, the second preset instruction may be an instruction of different specific types. In one implementation, the second preset instruction may be a memory access instruction, and the legitimacy check performed on it may be a memory access out-of-bounds check. In another implementation, the second preset instruction may also be an indirect branch instruction, and the legitimacy check performed on it may be a jump address legitimacy check.
[0048] Step S32, checking whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable.
[0049] As described above, the contract machine code compiled by a legal compiler does not include the second preset instruction, so when the acquired contract machine code includes the second preset instruction, it can be determined that the contract machine code is compiled by an illegal compiler. To avoid the systemic risk caused by this, in one embodiment, if the contract machine code includes the second preset instruction, it can be determined that the contract machine code is not executable.
[0050] According to the implementation method of using placeholder instructions in the above-mentioned contract machine code, after determining that the contract machine code does not include the second preset instruction, the first placeholder instruction in the contract machine code can be replaced with the second machine code; the second machine code includes the first machine code and the second preset instruction. Figure 8 FIG. 1 is a schematic diagram of the machine code after replacing the placeholder instruction in an embodiment of the present specification. Figure 8 As shown, before the blockchain node executes the security contract, the first placeholder instruction in the AOT machine code is replaced with a code (e.g., a second machine code) that performs an out-of-bounds access check on the memory access instruction corresponding to the first placeholder instruction, and executes the memory access instruction after the access is successful. The code that performs the out-of-bounds access check is, for example, the first machine code.
[0051] In a specific implementation, for example, the substitution instructions RRD_INST and RWR_INST correspond to the memory read instruction RD_INST and the memory write instruction WR_INST on the target machine of the blockchain node, respectively.
[0052] For example, on the target machine, the code block that performs a memory out-of-bounds check on the register indicated address and executes RD_INST after passing the check is:
[0053] PUSH REGtmp / / Save the value of temporary register REGtmp
[0054] LOAD REGtmp, LOW_RANGE / / LOW_RANGE stores the lower limit of the legal address range, and assigns the value of LOW_RANGE to REGtmp
[0055] CMP REGtmp,REGs / / Compare the values of REGtmp and REGs. Assume that before the address check (after AOT), the final memory unit address to be accessed is stored in register REGs
[0056] JB 1f / / If the value of REGs is less than REGtmp, the address is considered illegal (less than the lower limit) and jumps to the label corresponding to 1
[0057] LOAD REGtmp,HIGH_RANGE / / The upper limit of the legal address range is stored in the register HIGH_RANGE
[0058] CMP REGs,REGtmp / / Compare the values of REGs and REGtmp.
[0059] JB 1f / / If the value of register REGtmp is less than REGs, the address is considered illegal (exceeds the upper limit)
[0060] POP REGtmp / / Restore temporary register REGtmp
[0061] RD_INST REGs / / Use the memory access instructions supported by the machine to access the memory corresponding to REGs
[0062] JMP 2f / / Jump to the label corresponding to 2, that is, jump to the end of the code block
[0063] 1:CALL ReportError / / Report address out of bounds 2:
[0065] In one example, if the instruction on the target machine is a fixed-length 4-byte instruction, and the above code block includes 11 instructions, the memory read substitution instruction RRD_INST for the target machine can be 4*11 bytes. The first 4 bytes included can be, for example, 0x55 0x66 0x77 0x88, which is used to indicate that the instruction type is a memory read substitution instruction, and the bytes thereafter can be used, for example, to describe the number of registers REGs. Therefore, before executing the contract, the target machine can use the above code block to replace the position of the memory read substitution instruction RRD_INST in the contract machine code. In another example, the 4*11-byte memory write substitution instruction RRD_INST for the target machine can also be obtained based on a similar method, which will not be repeated here. In other specific embodiments, other memory access verification methods can also be used, and this specification does not limit this.
[0066] According to the implementation method of using a placeholder space in the contract machine code, after determining that the contract machine code does not include the second preset instruction, before executing the security contract, the blockchain node can replace the first placeholder space in the AOT machine code with a code that performs an out-of-bounds check on the memory access instruction corresponding to the first placeholder instruction and executes the memory access instruction after the access is successful, for example Figure 3 In a specific implementation, the out-of-bounds access check may be performed according to the execution parameters and the check method description in the occupancy space.
[0067] According to the implementation method of using function calls in the blockchain in the above-mentioned contract machine code, after determining that the contract machine code does not include the second preset instruction, since the access out-of-bounds check code for, for example, memory access instructions is implemented in the function provided by the blockchain, the contract machine code can be directly executed.
[0068] According to an embodiment of another aspect, a blockchain contract compilation method is also provided. Fig. 9 This is a flowchart of a blockchain contract compilation method in one embodiment of this specification. Figure 7 As shown, the method comprises the following steps:
[0069] Step S91, obtain the contract code.
[0070] According to different implementations, the contract code obtained may be a contract code of different specific types that can be compiled into a contract machine code, and this specification does not limit this. In one implementation, for example, it may be a Solidity code. In another implementation, for example, it may be a Serpent code.
[0071] Step S92, compile the contract code to generate a contract machine code, wherein the contract machine code includes a first preset instruction and does not include a second preset instruction; the first preset instruction is used to indicate: perform a legitimacy check corresponding to the second preset instruction through the first machine code provided by the blockchain node, and execute the second preset instruction after the legitimacy check passes.
[0072] In this step, the generated contract machine code, the first preset instruction, the first machine code, and the second preset instruction are similar to the contract machine code, the first preset instruction, and the first machine code, and the second preset instruction in the above step S41. The specific description of the parameters for step S41 will not be repeated here.
[0073] In one implementation, the first preset instruction may be a placeholder instruction, such as Figure 5 In one embodiment, the first preset indication may be a placeholder space, such as Figure 6 In one implementation, the first preset instruction may be a function call, such as Figure 7 shown.
[0074] According to another embodiment, a blockchain contract checking device is also provided. Fig.10 As shown, the device 1000 is deployed in a blockchain node and includes:
[0075] The preset instruction acquisition unit 101 is configured to acquire a contract machine code, wherein the contract machine code includes a first preset instruction, and the first preset instruction is used to indicate: performing a legality check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legality check passes;
[0076] The execution determination unit 102 is configured to check whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable.
[0077] In one implementation, the execution judgment unit may be further configured to determine that the contract machine code is not executable if the contract machine code includes the second preset instruction.
[0078] In one embodiment, the first preset instruction is a first placeholder instruction corresponding to the second preset instruction.
[0079] The device may also include:
[0080] A code replacement unit is configured to replace a first placeholder instruction in the contract machine code with a second machine code; the second machine code includes the first machine code and the second preset instruction.
[0081] In one embodiment, the first preset indication is a first placeholder space corresponding to the second preset instruction.
[0082] The device may also include:
[0083] A code filling unit is configured to fill a second machine code in a first placeholder space in the contract machine code; the second machine code includes the first machine code and the second preset instruction.
[0084] In one embodiment, the first preset instruction is a call to a first function.
[0085] The first function is a function provided by the blockchain node, and the first function includes the first machine code and the second preset instruction.
[0086] In one implementation, the second preset instruction may be a memory access instruction, and the legality check may be a memory access out-of-bounds check.
[0087] In one implementation, the second preset instruction may be an indirect branch instruction, and the legality check may be a jump address legality check.
[0088] According to an embodiment of another aspect, a blockchain contract compilation device is also provided. Fig. 9 1 is an architectural diagram of a blockchain contract compilation device 1100 in one embodiment of this specification. Fig.11 As shown, the device 1100 includes:
[0089] The code acquisition unit 111 is configured to acquire a contract code;
[0090] The machine code generation unit 112 is configured to compile the contract code to generate a contract machine code, wherein the contract machine code includes a first preset instruction, and the first preset instruction is used to indicate: performing a legitimacy check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legitimacy check passes.
[0091] In one implementation, the first preset indication may be one of a placeholder instruction, a placeholder space, or a function call.
[0092] On another aspect, the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute any one of the above methods.
[0093] On another aspect, the present specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, any one of the above methods is implemented.
[0094] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.
[0095] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers 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. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.
[0096] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
[0097] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.
[0098] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0099] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, 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 device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0100] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0101] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0102] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0103] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.
[0104] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
[0105] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0106] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.
[0107] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.
[0108] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.
Claims
1. A blockchain contract checking method, the method being executed by a blockchain node, the method comprising: Acquire a contract machine code, wherein the contract machine code includes a first preset instruction, wherein the first preset instruction is used to instruct: perform a legality check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and execute the second preset instruction after the legality check passes; Checking whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable; If the contract machine code includes the second preset instruction, it is determined that the contract machine code is not executable.
2. The method according to claim 1, wherein: The first preset instruction is a first placeholder instruction corresponding to the second preset instruction, The method further comprises: The first placeholder instruction in the contract machine code is replaced with a second machine code; the second machine code includes the first machine code and the second preset instruction.
3. The method according to claim 1, wherein: The first preset indication is a first placeholder space corresponding to the second preset instruction, The method further comprises: A second machine code is filled in a first placeholder space in the contract machine code; the second machine code includes the first machine code and the second preset instruction.
4. The method according to claim 1, wherein: The first preset indication is a call to the first function, The first function is a function provided by the blockchain node, and the first function includes the first machine code and the second preset instruction.
5. The method according to claim 1, wherein: The second preset instruction is a memory access instruction, and the legality check is a memory access out-of-bounds check.
6. The method according to claim 1, wherein: The second preset instruction is an indirect branch instruction, and the legality check is a jump address legality check.
7. A blockchain contract compilation method, the method comprising: Get the contract code; The contract code is compiled to generate a contract machine code, wherein the contract machine code includes a first preset instruction and does not include a second preset instruction; the first preset instruction is used to indicate: performing a legitimacy check corresponding to the second preset instruction through a first machine code provided by a blockchain node, and executing the second preset instruction after the legitimacy check passes.
8. The method according to claim 7, wherein: The first preset indication is one of a placeholder instruction, a placeholder space or a function call.
9. A blockchain contract checking device, the device being deployed on a blockchain node, the device comprising: A preset instruction acquisition unit is configured to acquire a contract machine code, wherein the contract machine code includes a first preset instruction, and the first preset instruction is used to indicate: performing a legality check corresponding to a second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legality check passes; an execution judgment unit, configured to check whether the contract machine code includes the second preset instruction to confirm whether the contract machine code is executable; If the contract machine code includes the second preset instruction, it is determined that the contract machine code is not executable.
10. The device according to claim 9, wherein: The first preset instruction is a first placeholder instruction corresponding to the second preset instruction, The device also includes: A code replacement unit is configured to replace a first placeholder instruction in the contract machine code with a second machine code; the second machine code includes the first machine code and the second preset instruction.
11. The device according to claim 9, wherein: The first preset indication is a first placeholder space corresponding to the second preset instruction, The device also includes: A code filling unit is configured to fill a second machine code in a first placeholder space in the contract machine code; the second machine code includes the first machine code and the second preset instruction.
12. The device according to claim 9, wherein: The first preset indication is a call to the first function, The first function is a function provided by the blockchain node, and the first function includes the first machine code and the second preset instruction.
13. The device according to claim 9, wherein: The second preset instruction is a memory access instruction, and the legality check is a memory access out-of-bounds check.
14. The device according to claim 9, wherein: The second preset instruction is an indirect branch instruction, and the legality check is a jump address legality check.
15. A blockchain contract compilation device, the device comprising: A code acquisition unit, configured to acquire a contract code; The machine code generation unit is configured to compile the contract code to generate a contract machine code, wherein the contract machine code includes a first preset instruction and does not include a second preset instruction; the first preset instruction is used to indicate: performing a legitimacy check corresponding to the second preset instruction through the first machine code provided by the blockchain node, and executing the second preset instruction after the legitimacy check passes.
16. The device according to claim 15, wherein: The first preset indication is one of a placeholder instruction, a placeholder space or a function call.
17. A computer-readable storage medium having a computer program or instruction stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 8.
18. A computing device, comprising a memory and a processor, wherein the memory stores a computer program or instructions, and the processor implements the method according to any one of claims 1 to 8 when executing the computer program or instructions.
Citation Information
Patent Citations
Method and device for caching and executing smart contract
CN111045792A
Process updating method and device, storage medium and electronic equipment
CN111782302A