CN116188016A - Transaction execution method and device in blockchain system - Google Patents

Abstract

The embodiment of this specification provides a transaction execution method and device in a blockchain system. Smart contracts are deployed in the blockchain system, and this method is applied to nodes in the blockchain system, including: receiving the first transaction, which invokes the smart contract, and includes the total amount of resources corresponding to the first transaction; During a transaction, update the resource balance corresponding to the first transaction based on the sum of the resource consumption corresponding to each first instruction in the first basic block currently to be executed in the first contract code of the smart contract; determine Whether the updated resource balance is less than zero; if the determined result is no, execute the first instructions sequentially.

Description

Transaction execution method and device in blockchain system

technical field

The embodiments of this specification belong to the technical field of blockchain, and in particular relate to a transaction execution method and device in a blockchain system.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.

Contents of the invention

The purpose of the present invention is to provide a transaction execution scheme in the blockchain system, which can effectively reduce the performance overhead brought by resource billing to the execution of smart contracts.

The first aspect of this specification provides a transaction execution method in a blockchain system, in which smart contracts are deployed, and the method is applied to nodes in the blockchain system, including: receiving the first transaction, the first transaction calls the smart contract, and includes the total amount of resources corresponding to the first transaction; in the process of executing the first transaction, the first contract code based on the smart contract is currently executed update the resource balance corresponding to the first transaction; determine whether the updated resource balance is less than zero; if the determination result is no, Then execute the first instructions sequentially in sequence.

The second aspect of this specification provides a transaction execution device in a blockchain system, where a smart contract is deployed in the blockchain system, and the device is applied to a node in the blockchain system, including: a receiving unit, configured to receive a first transaction, the first transaction invokes the smart contract, and includes the total amount of resources corresponding to the first transaction; the updating unit is configured to, during the execution of the first transaction, based on the The sum of resource consumption corresponding to each first instruction in the first basic block currently to be executed in the first contract code of the smart contract, and updating the resource balance corresponding to the first transaction; the determining unit is configured as It is determined whether the updated resource balance is less than zero; the execution unit is configured to execute the first instructions sequentially if the determination result of the determination unit is no.

A third aspect of the present specification provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computer, the computer is instructed to execute the method described in the first aspect.

A fourth aspect of the specification provides a computing device, including a memory and a processor, where executable codes are stored in the memory, and when the processor executes the executable codes, the method described in the first aspect is implemented.

A fifth aspect of the specification provides a computer program, wherein, when the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

In the solution provided by the embodiment of this specification, the contract code of the smart contract can be divided into basic blocks, and resource billing can be performed based on the basic blocks during the execution of the smart contract, without separate resource billing for each instruction. Compared with resource billing based on instructions, this scheme significantly reduces the frequency of resource billing in the execution of smart contracts, thereby effectively reducing the performance overhead brought by resource billing to the execution of smart contracts, and effectively reducing the impact on smart contracts. The impact of smart contract execution speed.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. , for those skilled in the art, other drawings can also be obtained according to these drawings without paying creative labor.

Fig. 1 is a blockchain architecture diagram in an embodiment;

Fig. 2 is a schematic diagram of an application scenario to which the embodiment of this specification can be applied;

Fig. 3 is a flow chart of the transaction execution method in the block chain system in the embodiment of this specification;

Fig. 4 is a schematic diagram of the basic block division process;

Fig. 5 is a schematic diagram of the basic block division process;

Fig. 6 is a flow chart of the transaction execution method in the blockchain system in the embodiment of this specification;

Fig. 7 is a schematic diagram of the second instruction insertion process;

Fig. 8 is a schematic structural diagram of the transaction execution device in the blockchain system in the embodiment of this specification.

Detailed ways

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 The embodiments are only some of the embodiments in this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

Fig. 1 shows a block chain architecture diagram in an embodiment. In the blockchain architecture diagram shown in FIG. 1 , the blockchain 100 includes N nodes, and FIG. 1 schematically shows nodes 1 - 8 . The connection between the nodes schematically represents a P2P (Peer to Peer, point-to-point) connection, and the connection may be, for example, a TCP connection, etc., and is used to transmit data between the nodes. These nodes can store a full amount of books, that is, store the status of all blocks and all accounts. Wherein, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.

A transaction in the blockchain field may refer to a unit of tasks performed and recorded in the blockchain. A transaction usually includes a sending field (From), a receiving field (To) and a data field (Data). Among them, when the transaction is a transfer transaction, the From field indicates the account address that initiated the transaction (that is, initiates a transfer task to another account), the To field indicates the account address that received the transaction (that is, received the transfer), and the Data field Include the transfer amount.

The function of smart contracts can be provided in the blockchain. Smart contracts on the blockchain are contracts that can be triggered by transactions on the blockchain system. Smart contracts can be defined in the form of code. Invoking a smart contract in the blockchain is to initiate a transaction pointing to the address of the smart contract, so that each node in the blockchain runs the smart contract code in a distributed manner.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (that is, deploying a contract) to the blockchain shown in Figure 1, and the data field of the transaction includes the code of the contract to be created ( Such as bytecode or machine code), 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..." is determined, each node adds the 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 stores Contract code, save the hash value of the contract code in the state storage of the contract, so that the contract is created successfully.

In the scenario of calling the contract, for example, Bob sends a transaction for calling the smart contract to the blockchain shown in Figure 1, the from field of the transaction is the address of the account of the transaction initiator (ie Bob), The to field is the above "0x6f8ae93...", which is the address of the called smart contract, and the data field of the transaction includes the method and parameters of calling the smart contract. After consensus is reached on the transaction in the blockchain, each node in the blockchain can respectively execute the transaction, thereby respectively executing the contract, and updating the state database based on the execution of the contract.

One of the decentralized features of blockchain technology that distinguishes it from traditional technologies is that bookkeeping is performed on each node, or called distributed bookkeeping, rather than traditional centralized bookkeeping. In order for the blockchain system to become a decentralized, honest and credible system that is difficult to break, open, and cannot be tampered with data records, it is necessary to make distributed data records safe, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, the aforementioned consensus mechanism. For example, a block-granularity consensus mechanism can be implemented between blockchain nodes. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a consensus mechanism of transaction granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, Each node that approves the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and finally can ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) in the entire network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm etc. Among them, in various consensus algorithms, usually after a preset number of nodes reach an agreement on the data to be consensused (that is, the consensus proposal), it is determined that the consensus on the consensus proposal is successful. Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes among the N consensus nodes reach a consensus, the consensus can be determined to be successful.

A smart contract is usually a program submitted by users to the blockchain system and executed on each node of the blockchain system. According to the undecidability of the halting problem, we cannot predict whether the smart contract submitted by the user will fall into an infinite loop. If the smart contract falls into an infinite loop, the computing resources of all nodes on the chain will be fully occupied, and the service will become unavailable. In order to avoid this situation, the smart contract virtual machine detects the amount of computing resources consumed by the contract in real time during execution. This process can be called gas billing. Smart contracts are generally based on some kind of virtual machine instruction set, such as EVM (Ethereum Virtual Machine, Ethereum Virtual Machine) instruction set or WebAssembly (wasm) instruction set. Depending on the complexity of the instruction execution logic, different instructions often have different gas costs. The virtual machine needs to calculate the total gas cost based on the instructions actually executed by the contract, and stop execution immediately when the predetermined amount is exceeded.

The traditional gas billing scheme is based on the instruction executed by the smart contract, that is, the gas fee is calculated every time an instruction is executed, and whether it is exceeded is checked. EVM virtual machines and wasm virtual machines usually do this. The advantage of this is that it is simple to implement, but the disadvantage is that the performance overhead is high, especially for blockchain nodes whose computing resources are already very tight.

In order to reduce the performance overhead brought by gas billing to the execution of the smart contract, the embodiment of this specification provides a transaction execution scheme in the blockchain system.

Referring to FIG. 2 , it is a schematic diagram of an application scenario to which the embodiment of this specification can be applied. In the application scenario shown in FIG. 2 , a user device 21 of a user User1 and a blockchain system 22 may be included. The blockchain system 22 may include N nodes (as shown schematically in FIG. 2 , node 1 - node 8 ), and a smart contract A is deployed. Wherein, for the explanation of the N nodes, reference may be made to relevant descriptions above, and details are not repeated here.

User1 can send a transaction Tx1 to the blockchain system 22 through the user device 21, and the transaction Tx1 calls the smart contract A, and includes the total amount of resources (such as gas limit) corresponding to the transaction Tx1. Among them, the instructions in the contract code of smart contract A can be configured with corresponding resource consumption. The resource consumption can be understood as the consumption of resources (digital resources/computing resources, such as the gas described above) by the execution of the instruction. Nodes in the blockchain system 22 can call smart contract A by executing transaction Tx1, and perform resource billing based on the basic blocks in the contract code of smart contract A. It should be pointed out that in a computer program, a basic block is usually a linear code sequence (or instruction sequence), which has the following properties: it can only be executed from the entrance of the basic block, and cannot jump to the middle of the basic block to start execution; The code inside the block must be executed sequentially to the end, and cannot jump out from the middle of the basic block.

In the following, in combination with specific embodiments, the solutions provided by the embodiments of this specification are introduced.

Referring to FIG. 3 , it is a flow chart of the transaction execution method in the blockchain system in the embodiment of this specification. Smart contract A can be deployed in the blockchain system. This method can be applied to nodes in a blockchain system. Further, the method can be applied to the virtual machine (such as EVM virtual machine or Wasm virtual machine, etc.) used to execute the smart contract in the node.

As shown in Figure 3, first, in step S301, a transaction Tx1 is received, and the transaction Tx1 calls the smart contract A, and includes the total amount of resources corresponding to the transaction Tx1.

In step S303, in the process of executing transaction Tx1, based on the sum of resource consumption corresponding to each first instruction in the first basic block currently to be executed in the first contract code of smart contract A, update the corresponding resource balance.

In one embodiment, the first contract code may be the contract code (such as contract bytecode) used when deploying the smart contract A. In the process of executing the transaction Tx1, the first contract code can be loaded, and then the first contract code can be divided into basic blocks on the spot by using the properties of the basic block as mentioned above, so as to determine the first basic block to be executed currently. Wherein, the instruction corresponding to the resource consumption in the first basic block may be referred to as the first instruction. The resource balance gas_left corresponding to the transaction Tx1 may be updated based on the sum S of resource consumption corresponding to each first instruction in the first basic block. Specifically, gas_left can be reduced by S. Among them, the initial value of gas_left can be the total amount of resources corresponding to the transaction Tx1.

In another embodiment, a second instruction is inserted at each entry of several basic blocks in the first contract code, and the second instruction is used to determine the corresponding resource consumption based on each first instruction in the basic block. The resource balance corresponding to the sum update transaction. Wherein, the second contract code of smart contract A may be stored in the blockchain system, and the first contract code may be generated based on the second contract code. The second contract code may be the contract code (such as contract bytecode) used when deploying the smart contract A. In one example, after smart contract A is deployed, several basic blocks can be determined in the second contract code, and second instructions can be inserted at the respective entrances of the several basic blocks, so as to obtain the first contract code and store the first contract code. A contract code. Thus, when a transaction calling smart contract A is subsequently executed, the first contract code can be loaded. Based on this, in the process of executing the first contract code based on the transaction Tx1, when the second instruction located at the entry of the first basic block is executed, the second instruction can be executed based on each first basic block in the first basic block. The sum of resource consumption corresponding to each instruction updates the resource balance corresponding to transaction Tx1.

In step S305, it is determined whether the updated resource balance is less than zero.

Wherein, when the updated resource balance is less than zero, it may indicate that the total resource consumption of the transaction Tx1 exceeds the total resources corresponding to the transaction Tx1, and step S309 needs to be executed. When the updated resource balance is not less than zero, it may indicate that the total resource consumption of the transaction Tx1 does not exceed the total resource amount, and step S307 may then be performed.

In step S307, if it is determined that the resource balance after the update is not less than zero, each first instruction in the first basic block is sequentially executed.

In step S309, if it is determined that the updated resource balance is less than zero, the execution of the first contract code ends.

When step S309 is executed to end the execution of the first contract code, it means that the execution of the transaction Tx1 is to be ended, and thus the execution of the transaction Tx1 will fail.

The solution provided by the embodiment corresponding to Fig. 3 can divide the contract code of the smart contract into basic blocks, and can perform resource billing based on the basic blocks during the execution of the smart contract, without separately performing resource billing for each instruction. Compared with resource billing based on instructions, this scheme significantly reduces the frequency of resource billing in the execution of smart contracts, thereby effectively reducing the performance overhead brought by resource billing to the execution of smart contracts, and effectively reducing the impact on smart contracts. The impact of smart contract execution speed.

In an implementation manner, several functions in the second contract code may respectively correspond to basic block information, and the basic block information may indicate several basic blocks divided from the function code of the corresponding function. Further, the basic block information may include respective instruction identification ranges of the several basic blocks. Wherein, the instruction identifier may be, for example, a line number or a memory address of the instruction, etc., which are not specifically limited here.

In practice, after the smart contract A is deployed based on the second contract code and before the smart contract A is invoked, the second contract code can be divided into basic blocks. Specifically, the second contract code may include function codes of several functions, the function codes of each of the several functions may be divided into basic blocks, and the basic block information corresponding to the functions may be cached. The basic block information may indicate several basic blocks divided from the function code of the function.

It should be noted that after the blockchain system is restarted, the cached basic block information will generally be lost. Therefore, after restarting the blockchain system, the second contract code can also be divided into basic blocks.

Referring to FIG. 4 , it is a schematic diagram of a basic block division process. The basic block division process can be performed by nodes in the blockchain system. Furthermore, it can be executed by the virtual machine used to execute the smart contract in the node.

As shown in Figure 4, first, in step S401, in the second contract code, for the first function code of any first function among several functions, detect the instruction for jumping and the instruction as the jump target, and Identify detected instructions as basic block boundaries.

Specifically, detected instructions may be marked as basic block boundaries.

In step S403, several instruction identifier ranges are generated based on the respective instruction identifiers of the instructions determined as basic block boundaries in the first function code; wherein, the instruction sequences corresponding to each of the several instruction identifier ranges are all basic blocks, and are used The instruction to jump is the last instruction of the basic block where it is located, and the instruction as the jump target is the first instruction of the basic block where it is located.

In an example, for two adjacent instructions among the instructions determined as the basic block boundary in the first function code, an instruction identifier range R1 can be generated based on the instruction identifiers of the two instructions, and the instruction identifier range R1 starts with the The instruction ID of the earlier instruction among the two instructions is the lower bound and the instruction ID of the later instruction among the two instructions is the upper bound. Wherein, when the preceding instruction is an instruction for jumping, the instruction identification range R1 does not include its lower bound. When the preceding instruction is an instruction to be a jump target, the instruction identification range R1 includes its lower bound. When the following instruction is an instruction for jumping, the instruction identification range R1 includes its upper bound. When the following instruction is a jump target instruction, the instruction identification range R1 does not include its upper bound.

In step S405, basic block information corresponding to the first function and including the ranges identified by the above-mentioned several instructions is generated.

In step S407, the generated basic block information is cached.

Next, with reference to FIG. 5 , the process of dividing the basic blocks shown in FIG. 4 will be described with an example. Wherein, FIG. 5 is a schematic diagram of a basic block division process. Assume that the first function code includes instruction 1-instruction 10 arranged in sequence as shown in Figure 5, wherein instruction 4 is an instruction for jumping, instruction 7 is an instruction as a jump target, and instruction 1 is an instruction The instruction ID of instruction 4 is 4, the instruction ID of instruction 7 is 7, and the instruction ID of instruction 10 is 10. By scanning instruction 1-instruction 10 sequentially to detect instructions for jumping and instructions as jump targets, instruction 4 and instruction 7 can be detected successively, and instruction 4 and instruction 7 are respectively marked as basic block boundaries. Then, based on the respective instruction identifiers of instruction 4 and instruction 7 marked as basic block boundaries, three instruction identifier ranges as shown in FIG. 5 can be generated, that is, [1,4], (4,7), [ 7,10]. Among them, [1,4] contains its lower bound 1 and upper bound 4, and corresponds to an instruction sequence formed by instruction 1-instruction 4, which is a basic block. (4,7) does not contain its lower bound 4 and upper bound 7, and corresponds to the instruction sequence formed by instruction 5-instruction 6, which is a basic block. [7,10] contains its lower bound 7 and upper bound 10, and corresponds to the instruction sequence formed by instruction 7-instruction 10, which is a basic block. Next, basic block information corresponding to the second function and including the three instruction identification ranges may be generated, and the basic block information may be cached.

In one embodiment, a second instruction may be inserted at the entrances of several basic blocks in the first contract code, and the first contract code may be generated based on the second contract code during the execution of the transaction Tx1.

Specifically, refer to FIG. 6 , which is a flow chart of the transaction execution method in the blockchain system in the embodiment of this specification. Smart contract A can be deployed in the blockchain system. This method can be applied to nodes in a blockchain system. Further, the method can be applied to the virtual machine (such as EVM virtual machine or Wasm virtual machine, etc.) used to execute the smart contract in the node.

As shown in Figure 6, first, in step S601, a transaction Tx1 is received, and the transaction Tx1 invokes the smart contract A, and includes the total amount of resources corresponding to the transaction Tx1.

In step S603, the second contract code of the smart contract A is loaded during the execution of the transaction Tx1.

In step S605, several basic blocks are determined in the second contract code, and second instructions are inserted at the respective entrances of the several basic blocks, thereby obtaining the first contract code; wherein, the second instruction is used to The resource balance corresponding to the transaction Tx1 is updated by the sum of the resource consumption corresponding to each of the first instructions.

According to the foregoing description, several functions in the second contract code may respectively correspond to basic block information, and the basic block information may indicate several basic blocks divided from the function code of the corresponding function. Based on this, several basic blocks can be determined in the second contract code based on the basic block information corresponding to the several functions, and a second instruction can be inserted at the respective entrances of the several basic blocks, thereby obtaining the first contract code.

Referring to FIG. 7 , it is a schematic diagram of the second instruction insertion process. Wherein, the left part in Fig. 7 schematically shows an original basic block in the second contract code, which includes three instructions arranged in sequence, that is, "i32" shown in Fig. 7 .const 123", "i32.const 456", and "i32.add". Assuming that the sum of the resource consumption corresponding to these three instructions is 300, a second instruction for reducing the resource balance corresponding to transaction Tx1 by 300 can be inserted at the entry of the original basic block, such as "gas_sub 300", thus Then the converted basic block as shown in the right part of Fig. 7 can be obtained.

After obtaining the first contract code, the first contract code can be executed normally, and when the second instruction is executed, resource billing can be performed by executing the second instruction.

Specifically, in step S607, when the second instruction in the first contract code is executed, by executing the second instruction, based on the sum of resource consumption corresponding to each first instruction in the first basic block where it is located, Update the resource balance corresponding to transaction Tx1.

In step S609, it is determined whether the updated resource balance is less than zero.

In step S611, if it is determined that the resource balance after the update is not less than zero, each first instruction in the first basic block is sequentially executed.

In step S613, if it is determined that the updated resource balance is less than zero, the execution of the first contract code ends.

In the solution provided by the embodiment corresponding to Figure 6, at the stage of loading the second contract code of the smart contract A based on the transaction Tx1, the second contract can be converted to The code is converted into the first contract code. Thus, the first contract code can be executed, and when the second instruction in the first contract code is executed, by executing the second instruction, based on the corresponding The sum of resource consumption, update the resource balance corresponding to transaction Tx1. In this way, resource billing can be implemented in units of basic blocks, compared to resource billing in units of instructions, which can significantly reduce the performance overhead that resource billing brings to the execution of smart contracts.

Fig. 8 is a schematic structural diagram of the transaction execution device in the blockchain system in the embodiment of this specification. Smart contracts are deployed in the blockchain system. The device can be applied to nodes in a blockchain system. In one example, the device may be, for example, a virtual machine (such as an EVM virtual machine or a Wasm virtual machine, etc.) for executing smart contracts.

As shown in FIG. 8 , the transaction execution device 800 in the blockchain system in the embodiment of this specification may include: a receiving unit 801 , an updating unit 802 , a determining unit 803 and an executing unit 804 . Wherein, the receiving unit 801 is configured to receive the first transaction, the first transaction invokes the smart contract, and includes the total amount of resources corresponding to the first transaction; the updating unit 802 is configured to, during the execution of the first transaction, based on the first The sum of the resource consumption corresponding to each first instruction in the first basic block currently to be executed in a contract code updates the resource balance corresponding to the first transaction; the determination unit 803 is configured to determine whether the updated resource balance is is less than zero; the execution unit 804 is configured to execute each first instruction in the first basic block sequentially if the determination result of the determination unit 803 is no.

In some embodiments, the execution unit 804 may also be configured to: if the determination result of the determination unit 803 is yes, end the execution of the first contract code.

In some embodiments, a second instruction is inserted at the entry of the first basic block; and the update unit 802 may be further configured to: by executing the second instruction, each first instruction in the first basic block corresponds to The sum of the resource consumption of , and update the resource balance corresponding to the first transaction.

In some embodiments, the second contract code of the smart contract is stored in the blockchain system, and the first contract code is generated based on the second contract code.

In some embodiments, the above device 800 may further include a loading unit (not shown in the figure). In the process of executing the first transaction, the loading unit can be configured to load the second contract code, determine several basic blocks in the second contract code, and insert second instructions at the respective entrances of the several basic blocks, so as to obtain The first contract code; wherein, the second instruction is used to update the resource balance corresponding to the first transaction based on the sum of resource consumption corresponding to each of the first instructions in the basic block.

In some embodiments, several functions in the second contract code respectively correspond to basic block information, and the basic block information indicates several basic blocks divided from the function code of the corresponding function.

In some embodiments, the above-mentioned apparatus 800 may further include: a detection unit (not shown in the figure), configured to, in the second contract code, for the first function code of any first function among several functions, detect the Instructions based on jumps and instructions as jump targets, and the detected instructions are determined as basic block boundaries; the generation unit (not shown in the figure) is configured to be determined as basic block boundaries based on the first function code The respective instruction identifiers of the respective instructions generate several instruction identifier ranges; wherein, the instruction sequences corresponding to each of the several instruction identifier ranges are basic blocks, and the instruction used for jumping is the last instruction of the basic block where it is located, as a jump The instruction of the transfer target is the first instruction of the basic block; the generation unit may also be configured to: generate basic block information corresponding to the first function and including the identification range of the several instructions.

In some embodiments, the foregoing apparatus 800 may further include: a caching unit (not shown in the figure), configured to cache the basic block information generated by the foregoing generating unit.

In some embodiments, the generating unit may be further configured to: for two adjacent instructions among the instructions determined as the basic block boundary in the first function code, generate the first instruction based on the instruction identifiers of the two instructions Instruction identification range, the first instruction identification range takes the instruction identification of the previous instruction in the two instructions as the lower bound and takes the instruction identification of the subsequent instruction in the two instructions as the upper boundary; wherein, when the previous instruction When it is an instruction for jumping, the first instruction identification range does not include its lower bound; when the previous instruction is an instruction as a jump target, the first instruction identification range includes its lower bound; when the following instruction is When an instruction is used for jumping, the range identified by the first instruction includes its upper bound; when the subsequent instruction is an instruction as a jump target, the identified range of the first instruction does not include its upper bound.

In the device embodiment corresponding to FIG. 8 , for further explanations of each unit, reference may be made to relevant descriptions in related method embodiments above, and details are not repeated here.

The embodiment of this specification also provides a computer-readable storage medium, on which a computer program is stored, wherein, when the computer program is executed in a computer, the computer is instructed to execute the method described in any of the above method embodiments.

The embodiment of this specification also provides a computing device, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the method described in any of the above method embodiments is implemented .

The embodiment of the present specification also provides a computer program, wherein, when the computer program is executed in a computer, the computer is caused to execute the method described in any of the above method embodiments.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, and its logic function is determined by programming the device by a user. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when writing programs. The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of 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., currently the most commonly used is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers, and embedded microcontrollers, 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 memory's control logic. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of future computer technology, the computer that realizes the functions of the above embodiments can 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 , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

Although one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, product, or apparatus comprising a set of elements includes not only those elements, but also other elements not expressly listed elements, or also elements inherent in such a process, method, product, or apparatus. Without further limitations, it is not excluded that there are additional identical or equivalent elements in a process, method, product or device comprising said elements. For example, if the words first, second, etc. are used, they are used to indicate names and do not indicate any particular order.

For the convenience of description, when describing the above devices, functions are divided into various modules and described separately. Of course, when implementing one or more of the present specification, the functions of each module can be realized in the same or more software and/or hardware, and the modules that realize the same function can also be realized by a combination of multiple submodules or subunits, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

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

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

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

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

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

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

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

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

In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment and

In other words, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant information, please refer to the description of Part 0 of the method embodiment. In the description of this specification, reference is made to the terms "one embodiment", "some embodiments", "example",

The description of "specific examples" or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiments or examples are included in at least one embodiment or example in this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, no particular feature, structure, material, or characteristic described

Points may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may refer to different embodiments or examples and the features of different embodiments or examples described in this specification without conflicting with each other.

Combine and combine.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description.

Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims (13)

1. A transaction execution method in a blockchain system having an intelligent contract deployed therein, the method being applied to nodes in the blockchain system, comprising:

Receiving a first transaction, wherein the first transaction invokes the intelligent contract and comprises a total amount of resources corresponding to the first transaction;

in the process of executing the first transaction, updating the resource balance corresponding to the first transaction based on the sum of the resource consumption amounts corresponding to each first instruction in a first basic block to be executed currently in a first contract code of the intelligent contract;

determining whether the updated resource balance is less than zero;

and if the result is negative, executing the first instructions in sequence.

2. The method of claim 1, further comprising:

and if the determination result is yes, ending the execution of the first contract code.

3. The method of claim 1, wherein the entry of the first basic block is inserted with a second instruction; and

the updating the resource balance corresponding to the first transaction based on the sum of the respective corresponding resource consumption amounts of each first instruction in the first basic block to be executed currently in the first contract code of the intelligent contract comprises the following steps:

and updating the resource balance corresponding to the first transaction based on the sum of the resource consumption corresponding to each first instruction by executing the second instruction.

4. The method of claim 3, wherein a second contract code for the smart contract is stored in the blockchain system, the first contract code being generated based on the second contract code.

5. The method of claim 4, wherein in performing the first transaction, further comprising:

loading the second contract code;

determining a plurality of basic blocks in the second contract code, and inserting a second instruction at the respective inlets of the basic blocks so as to obtain the first contract code; wherein the second instruction is used for updating the resource balance corresponding to the first transaction based on the sum of the respective corresponding resource consumption amounts of the first instructions in the basic block.

6. The method of claim 4, wherein the functions in the second contract code correspond to basic block information indicating basic blocks divided from function codes of the corresponding functions, respectively.

7. The method of claim 6, wherein prior to the receiving the first transaction, further comprising:

in the second contract code, for a first function code of any of the functions, detecting an instruction for jump and an instruction as a jump target, and determining the detected instruction as a basic block boundary;

Generating a plurality of instruction identification ranges based on respective instruction identifications of the instructions which are determined to be basic block boundaries in the first function code; the instruction sequences corresponding to the instruction identification ranges are basic blocks, the instruction for jumping is the last instruction of the basic block, and the instruction serving as a jumping target is the first instruction of the basic block;

basic block information is generated corresponding to the first function and including the number of instruction identification ranges.

8. The method of claim 7, further comprising:

the generated basic block information is cached.

9. The method of claim 7, wherein the generating a plurality of instruction identification ranges based on respective instruction identifications of the instructions determined to be basic block boundaries in the first function code comprises:

for two adjacent instructions in the instructions determined to be basic block boundaries, generating a first instruction identification range based on instruction identifications of the two instructions, wherein the first instruction identification range has the instruction identification of a preceding instruction in the two instructions as a lower bound and has the instruction identification of a following instruction in the two instructions as an upper bound; wherein,

When the previous instruction is an instruction for jump, the first instruction identification range does not contain its lower bound;

when the previous instruction is an instruction as a jump target, the first instruction identification range includes a lower bound thereof;

when the following instruction is an instruction for jump, the first instruction identification range contains an upper bound thereof;

when the following instruction is an instruction that is a jump target, the first instruction identification range does not include an upper bound thereof.

10. Method according to one of the claims 1-9, wherein a virtual machine for executing the smart contract is comprised in the node, in particular by the virtual machine.

11. A transaction execution device in a blockchain system having a smart contract deployed therein, the device being applied to a node in the blockchain system, comprising:

a receiving unit configured to receive a first transaction, the first transaction invoking the smart contract and including a total amount of resources corresponding to the first transaction;

an updating unit configured to update a resource balance corresponding to the first transaction based on a sum of resource consumption amounts respectively corresponding to each first instruction in a first basic block to be currently executed in a first contract code of the smart contract in a process of executing the first transaction;

A determining unit configured to determine whether the updated resource balance is less than zero;

and the execution unit is configured to execute the first instructions sequentially according to the sequence if the determination result of the determination unit is negative.

12. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-10.

13. A computing device comprising a memory having executable code stored therein and a processor, which when executing the executable code, implements the method of any of claims 1-10.

Images