A debugging method and device for a smart contract

Abstract

A debugging method and device for a smart contract, the debugging method comprising: obtaining a replay record file obtained by replaying a transaction calling the smart contract on a blockchain, the replay record file including on-chain data read in a process of executing the smart contract on the blockchain; and debugging the smart contract based on the replay record file.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a debugging method and apparatus for smart contracts. Background Technology

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. The emergence of smart contracts in the Blockchain 2.0 era has elevated the application scope of blockchain to a new level. With smart contracts, blockchain can do more than just simple transfer transactions; it can also invoke code, which can be customized by the user. Summary of the Invention

[0003] The purpose of this invention is to provide a method and apparatus for debugging smart contracts, which can debug smart contracts off-chain based on real on-chain data.

[0004] The first aspect of this specification provides a method for debugging smart contracts, including:

[0005] Obtain a replay record file obtained by replaying an exchange that invokes a smart contract on the blockchain; the replay record file includes on-chain data read during the execution of the smart contract on the blockchain;

[0006] The smart contract is debugged based on the playback record file.

[0007] A second aspect of this specification provides a debugging apparatus for smart contracts, comprising:

[0008] An acquisition unit is used to acquire a replay record file obtained by replaying an exchange that invokes a smart contract on the blockchain; the replay record file includes on-chain data read during the execution of the smart contract on the blockchain;

[0009] The debugging unit is used to debug the smart contract based on the playback record file.

[0010] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon that, when executed in a computer, causes the computer to perform the method described thereon.

[0011] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used 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 those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram illustrating the creation and deployment of smart contracts in a blockchain network in one embodiment;

[0014] Figure 2 This is a schematic diagram illustrating the creation, deployment, and invocation of smart contracts in a blockchain network in one embodiment;

[0015] Figure 3 This is a schematic diagram illustrating the creation, deployment, and invocation of smart contracts in a blockchain network in one embodiment;

[0016] Figure 4 This is a schematic diagram of the bytecode structure and virtual machine module in one embodiment;

[0017] Figure 5 This is a flowchart of a method for obtaining playback record files in one embodiment;

[0018] Figure 6 This is a schematic diagram illustrating the changes in contract state data in one embodiment;

[0019] Figure 7 This is a flowchart of a debugging method for smart contracts in one embodiment;

[0020] Figure 8 This is a schematic diagram of a debugging device for smart contracts in one embodiment. Detailed Implementation

[0021] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] A smart contract is a computer contract that executes automatically based on defined triggering rules; it can also be seen as a digital version of a traditional contract. The concept of smart contracts was first proposed in 1994 by Nick Szabo, a legal scholar and cryptographer working across disciplines. This technology was initially hindered from practical industrial applications due to a lack of programmable digital systems and related technologies, until the emergence of blockchain technology and Ethereum provided a reliable execution environment. Because blockchain technology uses a block-chain ledger, the generated data is immutable and cannot be deleted, and the entire ledger continuously adds data, ensuring the traceability of historical data; at the same time, the decentralized operating mechanism avoids the influence of centralized factors. Smart contracts based on blockchain technology not only leverage the advantages of smart contracts in terms of cost and efficiency but also prevent malicious interference with the normal execution of contracts. By writing smart contracts digitally into the blockchain, the characteristics of blockchain technology ensure that the entire process of storage, retrieval, and execution is transparent, traceable, and tamper-proof.

[0023] A smart contract is essentially a program that can be executed by a computer. Like widely used computer programs, smart contracts can be written in high-level languages. For example, Ethereum and some Ethereum-based consortium blockchains typically provide native smart contracts written in high-level languages ​​such as Solidity, Serpent, and LLL. These high-level smart contracts can include various complex logics to implement various business functions. At the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), which can be run by every Ethereum node. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented using it. Users publish and invoke smart contracts in Ethereum, which run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in bytecode form.

[0024] Furthermore, as a decentralized distributed system, blockchain requires maintaining distributed consistency. Specifically, in a distributed system, each of the nodes in a group has a built-in state machine. Each state machine needs to start from the same initial state, execute the same instructions in the same order, and keep each state change the same to ensure a consistent final state. However, it's difficult for the devices of the nodes participating in the same blockchain network to have the same hardware configuration and software environment. Therefore, in Ethereum, a representative of blockchain 2.0, to ensure that the process and results of executing smart contracts on all nodes are the same, a virtual machine similar to the JVM—the Ethereum Virtual Machine (EVM)—is used. The EVM can shield the differences in hardware configuration and software environment among nodes, and this sandbox-like environment can also ensure that the execution of smart contracts does not affect the blockchain platform code, other programs, or operating system on the host machine. In this way, developers can develop a set of smart contract code, compile the smart contract code locally, and then upload the compiled bytecode to the blockchain. After all nodes execute the same bytecode through the same EVM with the same initial state, they can obtain the same final result and the same intermediate result, while shielding the underlying hardware and environment differences between different nodes.

[0025] For example Figure 1 As shown, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, Node 1's EVM can execute the transaction and generate the corresponding contract instance. The transaction's `data` field can store the contract's bytecode, and the `to` field can be an empty address. After the nodes reach an agreement through the consensus mechanism, the smart contract can be successfully created on the blockchain. Figure 1 The "0x6f8ae93…" in the code represents the address of a successfully created smart contract, which users can subsequently use to invoke the contract. After the contract is created, a contract account corresponding to the "0x6f8ae93…" contract address appears on the blockchain. The contract code and account storage can be stored in this contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, smart contracts enable the creation of a virtual account on the blockchain that contains contract code and account storage.

[0026] As mentioned earlier, the `data` field of a transaction containing the creation of a smart contract can store the bytecode of that smart contract. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose to write smart contract code in a high-level language instead of directly writing bytecode. The smart contract code written in a high-level language is compiled by a compiler to generate bytecode, which can then be packaged into the initiated transaction and deployed to the blockchain through the consensus and execution processes mentioned above. Figure 2 As shown.

[0027] like Figure 2 and Figure 3 As shown, still using Ethereum as an example, after Bob sends a transaction containing information about calling a smart contract to the Ethereum network, the EVM of node 1 can execute this transaction and generate the corresponding contract instance. In Figure 3, the `from` field of the transaction is the address of the account initiating the smart contract call, the "0x6f8ae93…" in the `to` field represents the address of the called smart contract, and the `data` field of the transaction stores the method and parameters for calling the smart contract. After calling the smart contract, the value of `balance` may change. Subsequently, a client can view the current value of `balance` through a specific blockchain node. Smart contracts can be executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0028] As mentioned earlier, the transaction for creating a smart contract is sent to the blockchain. After consensus is reached, each node on the blockchain can execute the transaction. Specifically, this can be done by the EVM virtual machine of the blockchain node. At this point, a contract account corresponding to the smart contract appears on the blockchain (including, for example, a contract account counter Nonce, a balance, the hash value of the contract bytecode Codehash, and the root storage of the contract Storage), and has a specific address. The contract code and account storage can be stored in the storage of this contract account, such as... Figure 4As shown. The behavior of a smart contract is controlled by its contract code, while the smart contract's account storage preserves the contract's state. In other words, smart contracts create virtual accounts on the blockchain that contain contract code and account storage. For contract deployment or update transactions, the Codehash value is generated or changed. Subsequently, blockchain nodes can receive transaction requests to invoke the deployed smart contract. These requests can include the address of the invoked contract, the functions within the invoked contract, and the input parameters. Generally, after consensus is reached, each blockchain node can independently execute the specified invoked smart contract.

[0029] Figure 4 The left side shows an example of a smart contract written in Solidity. This smart contract is compiled by a compiler to generate bytecode. `solc` in the diagram is Solidity's command-line compiler. Ethereum smart contracts written in Solidity can be compiled using the parameterized command-line tool `solc` to generate bytecode that can run on the EVM. After the above... Figure 1 , Figure 2 The process of deploying a smart contract involves successfully creating one on the blockchain. After deployment, a contract account corresponding to the smart contract is generated on the blockchain. This contract account includes, for example, a contract account counter (Nonce), a balance, the hash value of the contract bytecode (Codehash), and the root storage location (StorageRoot), and has a specific address. The contract code and account storage can be stored in the storage of this contract account. The Codehash is generally the hash value of the contract bytecode. After the contract is deployed, the Codehash is the hash value of the contract bytecode. When the contract is updated, the hash of the contract bytecode generally changes, and the Codehash is also generally updated.

[0030] The execution of the contract can be specifically as follows: Figure 4As shown. For example, a transaction calling a contract is sent to the blockchain network, and after consensus is reached, each node can execute the transaction. The `to` field of the transaction indicates the address of the contract being called. Any node can find the storage of the contract account based on the contract address, and then read the Codehash from the storage of the contract account, thereby finding the corresponding contract bytecode based on the Codehash. The node can load the contract bytecode from storage into the virtual machine. Then, the interpreter interprets and executes it, including parsing the bytecode of the called contract (such as Push, Add, SGET, SSTORE, Pop, etc.), obtaining the opcode and function, and storing these opcodes in the memory space allocated by the virtual machine (alloc, corresponding to the memory release operation after program execution, as shown in Free in the figure), and also obtaining the jump code of the called function in the memory space. Generally, after calculating the Gas required to execute the contract and ensuring sufficient Gas, the system jumps to the corresponding address in Memory to retrieve the OPcode of the called function and begins execution. It then performs data computation, pushes / pops data from the stack, and other operations to complete the computation. During this process, some contract context information may be needed, such as the block number and information about the initiator of the call; this information can be obtained from the context (using a Get operation). Finally, the resulting state is stored in the database storage by calling the storage interface. It should be noted that during contract creation, certain functions within the contract may also be executed, such as initialization functions. In this case, code parsing, jump instructions are generated, data is stored in Memory, and data is manipulated within the stack.

[0031] In reality, high-level languages ​​such as C, C++, Java, Go, and Python each have their own advantages. For example, C has higher execution efficiency; C++ and Java have a wide audience, a large number of developers, and mature communities and tools; Go is more modern; and Python is relatively simpler and easier to use. Currently, various blockchain platforms are expanding their smart contract types to support smart contracts developed in high-level languages ​​such as C, C++, Java, Go, and Python. One way to expand to support smart contracts developed in these high-level languages ​​is to compile them into WASM (WebAssembly) format bytecode. WebAssembly is an open standard developed by the W3C community group. It is a secure, portable low-level code format designed for efficient execution and compact representation, achieving near-native performance and providing a compilation target for languages ​​such as C, C++, Java, and Go. The WASM virtual machine was initially designed to solve the increasingly serious performance problems of web applications. Due to its superior characteristics, it has been increasingly adopted by non-web projects, such as replacing the EVM smart contract execution engine. The WebAssembly virtual machine (also known as the Wasm virtual machine or Wasm runtime environment, which is a virtual machine runtime environment that executes WASM bytecode), implemented according to the W3C community open standard, is implemented by loading and interpreting Wasm bytecode at runtime. The execution process of Wasm bytecode in the Wasm virtual machine is similar to the EVM process described above, such as... Figure 4 As shown in the image.

[0032] For example, for smart contracts written in C++, the developer can generate corresponding source files, typically with a .cpp extension, after writing the smart contract. The .cpp files of the contract code can be compiled by a compiler to generate Wasm format bytecode. The Wasm format bytecode can then be encapsulated in a .wasc file. Similarly, for smart contracts written in Java, the developer can generate corresponding source files, typically with a .java extension, after writing the smart contract. The .java files of the contract code can be compiled by a compiler to generate Wasm format bytecode. The Wasm format bytecode can then be encapsulated in a .wasc file. .wasc is a file that combines bytecode and the ABI (Application Binary Interface).

[0033] It should be noted that for smart contracts published on the blockchain, when problems or errors occur, they can be debugged using off-chain debuggers. Here, a debugger refers to a computer program and tool used to debug other programs. It allows code to be checked for runtime issues and selectively executed in the runtime environment for troubleshooting and debugging.

[0034] In traditional technologies, smart contracts are usually debugged based on simulated data. However, this method cannot obtain on-chain data such as transaction hashes, block information, and contract storage data at the time of transaction execution. It is difficult to locate problems in complex contracts and can only debug simple smart contracts.

[0035] The inventors of this application have discovered through research that smart contracts deployed on a blockchain typically exhibit the following characteristics when replayed:

[0036] First, each replay execution uses the same context information and stored data. The context information here refers to information such as the transaction hash and block height provided before the transaction is executed, which can be constructed based on the basic information of the transaction to be replayed. Furthermore, the stored data refers to contract state data.

[0037] This feature is achieved based on the following requirements of blockchain itself: blockchain requires that blocks on the chain can be re-verified multiple times, and that the verification results are consistent each time. This re-verification is also called block replay, specifically referring to replaying each transaction in the block in sequence. The execution of a transaction during replay is consistent with its initial execution. That is, when replaying a transaction, the written storage data is maintained in the write cache, and the read storage data is maintained in the read cache. Therefore, each time storage data is read, it is first read from the write cache, then from the read cache, and if neither is found, it is read from the state tree corresponding to the previous block. For example, when replaying the first transaction of block 10001, if reading storage data is needed during contract execution, the storage data corresponding to block 10000 is read and returned.

[0038] The replay of a smart contract transaction described in this specification refers to replaying the block to which the transaction belongs, thereby possessing the aforementioned characteristics.

[0039] Secondly, the steps for calling the HostAPI that interacts with the outside of the virtual machine are exactly the same in each replay execution. The parameters, return results, and modifications to the linear memory area during the call process are all exactly the same.

[0040] Regarding the aforementioned linear memory region, it can be created before the Wasm virtual machine executes the bytecode of the smart contract. This linear memory region is a part of the physical memory managed by the operating system and is managed and controlled by the Wasm virtual machine. Specifically, the Wasm virtual machine can abstract another layer on top of the physical memory managed by the operating system, resulting in a linear memory region whose address starts from, for example, 0 (also called the base address of the linear memory region), and can control access to the linear memory region based on offsets. That is, other addresses in the linear memory are equivalent to offsets relative to the base address. Thus, address 'a' in the linear memory corresponds to the base address of the linear memory in the operating system plus the offset 'a' in the linear memory. By abstracting the operating system memory in this way, the Wasm virtual machine can better manage and use memory.

[0041] Given the characteristics of each smart contract replay as described above, this solution proposes to record the return results of the HostAPI and the changes in the linear memory region into a replay log file during the smart contract replay process. The smart contract can then be debugged based on this replay log file, thereby achieving the goal of debugging the smart contract based on real on-chain data.

[0042] The following explains the method for obtaining the aforementioned playback record files.

[0043] Figure 5 This is a flowchart of a method for obtaining playback record files in one embodiment, such as... Figure 5 As shown, the method may include the following steps:

[0044] Step S502: Send a transaction replay request to the nodes in the blockchain.

[0045] The transaction replay request can be initiated by a user through their user device to a node in the blockchain, and can include the transaction hash of the transaction to be replayed.

[0046] In one embodiment, the user equipment may be a device equipped with a debugger.

[0047] Step 504: The nodes in the blockchain retrieve the transactions of the smart contract to be replayed based on the transaction hash and re-execute them.

[0048] For example, a node in a blockchain can first determine the corresponding block information (such as block height or block number) based on the transaction hash, and then obtain the corresponding transaction and re-execute it based on the block information and the transaction hash.

[0049] Step 506: During the re-execution of the transaction, intercept the first call result of the smart contract to the host interface and record it in the replay log file.

[0050] It should be noted that the contract state data obtained during the re-execution of the transaction is not stored.

[0051] The file format of the aforementioned playback record file can be, for example, JSON, PNG, or CSV format, and this manual does not limit this.

[0052] The aforementioned host interface (also known as the host API) is a method provided by the blockchain platform to the virtual machine for smart contracts to read and write data. Specifically, the virtual machine here can be the Wasm virtual machine.

[0053] It should be understood that the first call result of the host interface recorded in the replay log file in this scheme includes the return result (also known as the return value) of the host interface and / or the change record of the linear memory region.

[0054] The host interface returns two parts: on-chain data (such as block height) and an indication of whether the interface call was successful (0 or 1). The data type of the returned result can be integer or floating-point.

[0055] The change record for the aforementioned linear memory region can be one or multiple records. Each change record may include the starting address and size (also known as the offset) of the changed segment in the linear memory region, as well as the new data in the changed segment.

[0056] In practical applications, the aforementioned replay log file may also include the maximum gas allowed for the replay transaction and / or the maximum linear memory area allowed for the virtual machine to use for the replay transaction, etc., which are not limited in this specification.

[0057] In one embodiment, the content of the playback log file described above may be as follows:

[0058]

[0059]

[0060] The aforementioned smart contract includes the method `set_data()`, which is often referred to as the smart contract's interface function. Within the `set_data()` method, four HostAPI functions are called: `GetBlockNum()`, `GetBlockHash()`, `GetStorage()`, and `SetStorage()`. Specifically, `GetBlockNum()` retrieves the block height of the previous block, `GetBlockHash()` retrieves the block hash of a specific block, `GetStorage()` retrieves the old Storage value, and `SetStorage()` sets the new value.

[0061] The smart contract described above is used to implement the following functions: first, obtain the block height of the previous block, then concatenate the block hashes of the most recent n blocks into a string, and save it to Storage along with the old Storage value.

[0062] For the aforementioned smart contract, assuming there are already two transactions on the blockchain that call the smart contract, one transaction is represented as: set_data(1), where "1" is the contract parameter; the other transaction is represented as: set_data(2), where "2" is the contract parameter. If these two transactions are packaged in blocks with block heights of 1001 and 1003 respectively, and assuming the block hashes of blocks with block heights of 1000 to 1003 are 'b1', b2', 'b3', 'b4' respectively, then the changes in the contract state data after calling the above two transactions can be seen in [reference needed]. Figure 6 As shown.

[0063] Figure 6 In the process, after executing the first transaction: set_data(1), the contract status data is: mydata = "b1". After that, after executing the second transaction: set_data(2), the contract status data is: mydata = "b1,b3,b2".

[0064] Now, assuming we want to debug the second transaction: set_data(2), the content of the replay log file after replaying the second transaction on the blockchain can be as follows:

[0065]

[0066]

[0067] As shown above, for a single HostAPI, multiple call results can be recorded based on the number of times it is called. In other words, the replay log file records the result of each call to each HostAPI. Furthermore, in this example, except for the return value of SetStorage(), the return values ​​of other HostAPIs can all be considered as read on-chain data.

[0068] It should be noted that the replay log files described in this specification record not only the read on-chain data but also the indication results and change records to maximize the reproduction of the on-chain execution environment; however, these two are not mandatory. In practical applications, only on-chain data can be recorded, and the smart contract can be debugged based on this data, thereby achieving better debugging accuracy than debugging the smart contract based on simulated data.

[0069] It should be understood that, based on the playback log file recorded above, the smart contract can be debugged off-chain. The debugging process is explained below.

[0070] Figure 7 This is a flowchart of a debugging method for smart contracts in one embodiment, such as... Figure 7 As shown, the method may include the following steps:

[0071] Step S702: Obtain the replay record file obtained by replaying the smart contract call on the blockchain.

[0072] When replaying smart contracts on-chain, the execution methods of smart contracts support interpreted execution, just-in-time (JIT) compilation execution, or statically compiled AOT execution.

[0073] In interpreted execution, bytecode instructions are interpreted and executed sequentially, which is typically inefficient. In Just-In-Time (JIT) execution, bytecode is compiled into machine code at runtime, and the compiled machine code is then executed. JIT compilation can involve the conversion of source code or bytecode to machine code. Systems implementing JIT compilation can continuously analyze the executing code and identify certain parts where the performance improvement from compilation or recompilation outweighs the overhead of compiling that code. Compared to interpreted execution, JIT execution can offer orders of magnitude efficiency, potentially approaching the performance level of the system's native executable. In Ahead-of-Time (AOT) execution, bytecode is pre-compiled into machine code before execution, and the resulting machine code is then executed, avoiding runtime JIT compilation. AOT execution can also offer orders of magnitude efficiency compared to interpreted execution, approaching the performance level of the system's native executable.

[0074] As described above, the replay log file here includes on-chain data read during the execution of smart contracts on the blockchain. It also includes indications of whether host interface calls were successful and / or records of changes to linear memory regions.

[0075] Since the aforementioned on-chain data is also obtained by calling the host interface, the above indication results and on-chain data are collectively referred to as the return results of the host interface, and the return results of the host interface and the change records of the linear memory region are collectively referred to as the call results of the host interface.

[0076] It should be noted that, in order to distinguish it from the off-chain call results for the host interface, in the following description, the call results of the host interface recorded in the replay log file are referred to as the first call results, the return results in the first call results are referred to as the on-chain return results, and the change records of the linear memory regions therein are referred to as the change records of the linear memory regions created on-chain.

[0077] Step S704: Debug the smart contract based on the playback log file.

[0078] Specifically, the smart contract is executed off-chain, and based on the first call result of the host interface recorded in the replay log file, the second call result of the host interface during the off-chain execution of the smart contract is determined.

[0079] This includes using the on-chain return results recorded in the replay log file as the return results of calling the host interface during the execution of the smart contract off-chain; and / or determining the corresponding target segment from the linear memory region created off-chain based on the starting address and size recorded in the replay log file, and writing the modified new data recorded in the replay log file into the target segment.

[0080] For the smart contract in the aforementioned example, when executing it off-chain, it's typically necessary to first determine the methods and parameters to be called. One approach is to directly pass the `set_data()` method and its parameter 2 (i.e., n=2). Another approach is to use an entry function to match methods like `set_data()` and the parameter 2 to functions within the contract. The pseudocode for this entry function is as follows:

[0081]

[0082]

[0083] In this pseudocode snippet, `get_calldata_length()` and `get_calldata()` are also HostAPI functions. `get_calldata_length()` is used to get the length of the input parameter for `calldata()`, `malloc()` is used to allocate a linear memory region, `get_calldata()` is used to read data from memory, `decode()` is used to decode the data to obtain the input parameter `n`, the functionality of `set_data()` is described above, and `set_result()` is used to store the return result of `set_data()`.

[0084] Assuming the `set_data()` method and its second input parameter are determined by executing the entry function, the off-chain execution process of the aforementioned smart contract is as follows:

[0085] When the code on line 6 of the aforementioned entry function is executed, the execution jumps to the `set_data()` method. Then, when the `GetBlockNum()` function call on line 4 of the `set_data()` method is executed, the block height 1002 recorded in the replay log file is assigned as the return value to `latestBlockNum`. Afterwards, when the `GetBlockHash()` function call on line 5 of the `set_data()` method is executed for the first time, the record "b3" in the replay log file is written to a segment of length 2 starting from 33000 in the off-chain linear memory region. This data can then be read and assigned to `blockhash`, resulting in `ss = "b3,"`. Similarly, when the `GetBlockHash()` function call on line 5 of the `set_data()` method is executed for the second time, the record "b2" from the replay log file is written into a segment of length 2 starting from 34000 in the off-chain linear memory region. This data can then be read and assigned to `blockhash`, resulting in `ss = "b3,b2,"`, thus ending the loop. Next, when the `GetStorage()` function call on line 8 of the `set_data()` method is executed, the record "b1," from the replay log file is written into a segment of length 3 starting from 35000 in the off-chain linear memory region. This data can then be read and assigned to `oldStorage`. Finally, when the `SetStorage()` function call on line 9 of the `set_data()` method is executed, `oldStorage` and the `result` value (based on the value of `ss`) are concatenated, and the concatenated result is assigned to `mydata`, resulting in `mydata = "b1,b3,b2,"`. This obtains the same contract state data as on-chain.

[0086] Furthermore, when executing smart contracts off-chain (i.e., debugging smart contracts), the bytecode can include debugging information. Specifically, developers can compile the source code in debug mode to obtain bytecode containing debugging information. This debugging information includes the mapping between line numbers in the smart contract's source code and line numbers in the bytecode, as well as function list information. The function list information includes at least one of the following: function name, function lexical scope, variable name, variable data type, variable lexical scope, variable index, parameter name, and parameter index.

[0087] Finally, it should be noted that because the compilation optimization of smart contracts does not affect the calling order and parameters of the HostAPI (a characteristic of general programming language compilers), this solution also allows the deployment and invocation of highly compiled and optimized contract bytecode on the blockchain, or the use of a JIT virtual machine to execute smart contracts. When stepping through the code, using the unoptimized version of the contract bytecode with debugging information can achieve the same functionality except for gas.

[0088] In summary, the debugging method for smart contracts provided in this specification can debug smart contracts based on replay log files obtained by replaying the smart contract calls on-chain. Since these replay log files can include on-chain data read during the execution of the smart contract, this solution can reproduce the actual on-chain data state during off-chain smart contract debugging, thereby enabling more accurate debugging of the smart contract.

[0089] Figure 8 This is a schematic diagram of a debugging device for smart contracts in one embodiment. Specifically, this device executes, as follows: Figure 7 The method shown enables debugging of smart contracts, and includes:

[0090] The acquisition unit 802 is used to acquire a replay record file obtained by replaying an exchange that calls a smart contract on the blockchain. The replay record file includes on-chain data read during the execution of the smart contract on the blockchain.

[0091] Debug unit 804 is used to debug smart contracts based on playback log files.

[0092] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 5 or Figure 7 The method shown.

[0093] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 5 or Figure 7 The method shown.

[0094] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0095] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), 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 Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0096] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0097] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0098] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0099] This 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 will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0100] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0101] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function 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] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0104] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0105] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this 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 can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0107] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0108] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for debugging smart contracts, comprising: Obtain the replay record file obtained by replaying the smart contract call on the blockchain; The playback record file includes on-chain data read during the execution of the smart contract on the blockchain; Debug the smart contract based on the playback record file; The playback log file is obtained through the following steps: A transaction replay request is sent to a node in the blockchain, causing the node to re-execute the transaction. During the re-execution of the transaction, the first call result of the smart contract to the host interface is intercepted and recorded in the replay record file. The host interface is a method provided by the blockchain to the virtual machine for the smart contract to read and write data.

2. The method according to claim 1, wherein, The debugging of the smart contract includes: The smart contract is executed off-chain, and based on the first call result of the host interface recorded in the replay log file, the second call result of the host interface during the off-chain execution of the smart contract is determined; wherein the first call result includes the on-chain data.

3. The method according to claim 2, wherein, The virtual machine is a WASM virtual machine.

4. The method according to claim 1, wherein, During the re-execution of the transaction, the obtained contract state data is not stored.

5. The method according to claim 2, wherein, The first call result also includes an indication of whether the call was successful or not and / or a change record of the linear memory region created on the chain, wherein the indication result and the on-chain data constitute the on-chain return result of the host interface.

6. The method according to claim 5, wherein, The data types of the results returned on the chain include integer or floating-point types.

7. The method according to claim 5, wherein, The change record of the linear memory region created on the chain includes the starting address and size of the changed segment in the linear memory region created on the chain, as well as the new data after the change in the changed segment.

8. The method according to claim 7, wherein, The determination of the second call result of the host interface during the off-chain execution of the smart contract includes: The on-chain return results recorded in the replay file are used as the return results of calling the host interface during the off-chain execution of the smart contract; and / or, Based on the starting address and size recorded in the replay record file, the corresponding target segment is determined from the linear memory region created off-chain, and the modified new data recorded in the replay record file is written into the target segment.

9. The method according to claim 2, wherein, The execution of the smart contract off-chain includes: The bytecode of the smart contract, including debugging information, is executed off-chain. The debugging information includes mapping information between the line numbers of the smart contract's source code and the line numbers of the bytecode, as well as function list information. The function list information includes at least one of the following: the name of a function in the smart contract, the lexical scope of the function, the name of a variable, the data type of the variable, the lexical scope of the variable, the index of the variable, the name of a parameter, and the index of the parameter.

10. The method according to claim 1, wherein, The replay log file also includes the maximum gas allowed for the execution of the smart contract and / or the maximum linear memory area allowed for the virtual machine.

11. A debugging device for smart contracts, comprising: The acquisition unit is used to acquire replay record files obtained by replaying smart contract calls on the blockchain. The playback record file includes on-chain data read during the execution of the smart contract on the blockchain; A debugging unit is used to debug the smart contract based on the playback record file; The playback log file is obtained through the following steps: A transaction replay request is sent to a node in the blockchain, causing the node to re-execute the transaction. During the re-execution of the transaction, the first call result of the smart contract to the host interface is intercepted and recorded in the replay record file. The host interface is a method provided by the blockchain to the virtual machine for the smart contract to read and write data.

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

13. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-10.

Images