Smart contract debugging method and device, computer equipment, storage medium and computer program product

Abstract

The invention relates to an intelligent contract debugging method and device, computer equipment, a storage medium and a computer program product. The method comprises the steps of determining a to-be-debugged target contract in a block chain network, and entering a debugging stage of the target contract; creating a first snapshot and a second snapshot associated with the target contract; storing data generated by an on-chain actual operation related to the target contract to the first snapshot, and storing data generated by an on-chain debugging operation related to the target contract to the second snapshot; and if the debugging for the target contract is completed, updating a state database of the block chain network based on data stored in the first snapshot. By adopting the method, the maintainability of the smart contract and the stability of on-chain operation can be improved through the debugging accuracy of the smart contract.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a smart contract debugging method, apparatus, computer equipment, storage medium, and computer program product. Background Art

[0002] Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. With the promotion and application of blockchain, the businesses it connects to are becoming increasingly complex. Smart contracts are computer protocols designed to communicate, verify, or execute contracts in an information-based manner. As a key business module within blockchain, they support increasingly complex real-world business needs.

[0003] However, since smart contracts are composed of code, any coding errors may lead to transaction failures, wasting a lot of manpower, material resources and time. Therefore, it is necessary to debug smart contracts to ensure that operators can quickly and accurately find and resolve errors when errors occur.

[0004] Currently, smart contracts are usually debugged by setting up a specific debugging environment. However, the debugging environment often cannot completely replicate the status and data of the actual production environment. As a result, some problems cannot be reproduced in the debugging environment, or the repair solution does not perform as expected in the actual production environment, which increases the risk of deploying smart contracts to the production environment. Summary of the Invention

[0005] Based on this, it is necessary to provide a smart contract debugging method, device, computer equipment, computer-readable storage medium and computer program product that can improve the accuracy of smart contract debugging to improve the maintainability of smart contracts and the stability of on-chain operations in order to address the above technical problems.

[0006] In a first aspect, the present application provides a smart contract debugging method. The method comprises:

[0007] Determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract;

[0008] creating a first snapshot and a second snapshot associated with the target contract;

[0009] Store the data generated by the actual on-chain operations related to the target contract in the first snapshot, and store the data generated by the on-chain debugging operations related to the target contract in the second snapshot;

[0010] If debugging of the target contract is completed, the state database of the blockchain network is updated based on the data stored in the first snapshot.

[0011] In a second aspect, the present application also provides a smart contract debugging device. The device includes:

[0012] A target contract determination module is used to determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract;

[0013] a snapshot creation module, configured to create a first snapshot and a second snapshot associated with the target contract;

[0014] A storage module, configured to store data generated by on-chain actual operations related to the target contract in the first snapshot, and store data generated by on-chain debugging operations related to the target contract in the second snapshot;

[0015] An update module is configured to update a status database of the blockchain network based on the data stored in the first snapshot if debugging of the target contract is completed.

[0016] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above-mentioned smart contract debugging method when executing the computer program.

[0017] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-mentioned smart contract debugging method.

[0018] In a fifth aspect, the present application further provides a computer program product, comprising a computer program that, when executed by a processor, implements the steps of the above-mentioned smart contract debugging method.

[0019] The above-described smart contract debugging method, apparatus, computer device, storage medium, and computer program product identify a target contract to be debugged in a blockchain network and enter the debugging phase of the target contract, i.e., directly debugging the target contract on the blockchain network. A first snapshot and a second snapshot are further created associated with the target contract, whereby the first snapshot stores data generated by actual on-chain operations related to the target contract, and the second snapshot stores data generated by on-chain debugging operations related to the target contract. Upon completion of debugging of the target contract, the blockchain network's state database is updated based on the data stored in the first snapshot. First, unlike traditional off-chain debugging (debugging outside the blockchain network), the present solution debugs the target contract in a real on-chain environment, providing access to complete on-chain data and state, enabling more accurate diagnosis and repair of issues within the target contract. Second, the creation of the first and second snapshots effectively separates debugging operations from real-time on-chain operations, allowing debugging and testing of the target contract without affecting main-chain data, while ensuring that debugging operations do not interfere with real-time on-chain operations. Finally, after debugging is completed, by updating the data generated by the actual on-chain operations in the first snapshot into the state database, it is ensured that the data generated by the actual on-chain operations during the debugging process can be accurately recorded and reflected on the chain. Through this optimized data synchronization and merging operation, the maintainability of the target contract and the stability of on-chain operations are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a diagram of an application environment of a smart contract debugging method in one embodiment;

[0021] Figure 2 This is a schematic diagram of the structure of a blockchain node in one embodiment;

[0022] Figure 3 This is a schematic diagram of the structure of a blockchain node in another embodiment;

[0023] Figure 4 1. A flowchart of a smart contract debugging method according to an embodiment;

[0024] Figure 5 This is a schematic diagram of the structure of a blockchain node in another embodiment;

[0025] Figure 6 A flowchart of a smart contract debugging method in another embodiment;

[0026] Figure 7 This is a schematic diagram of the structure of a blockchain node in another embodiment;

[0027] Figure 8A flowchart of a process for conducting a business query for a real transaction in one embodiment;

[0028] Figure 9 A flowchart of a process for launching a business query for a debugging transaction in one embodiment;

[0029] Figure 10 A schematic diagram of snapshot changes in an embodiment;

[0030] Figure 11 A schematic diagram of snapshot changes in another embodiment;

[0031] Figure 12 1 is a flowchart of a smart contract debugging method in another embodiment;

[0032] Figure 13 1 is a flowchart of a smart contract debugging method in another embodiment;

[0033] Figure 14 A schematic diagram of snapshot changes in another embodiment;

[0034] Figure 15 1 is a flowchart of a smart contract debugging method in another embodiment;

[0035] Figure 16 This is a structural block diagram of a smart contract debugging device in one embodiment;

[0036] Figure 17 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] Before going into details, let’s introduce blockchain technology:

[0039] Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of online transactions, used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product and service layer, and the application service layer.

[0040] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between the user's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first adapts the interface to parse and authenticate the request (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration, issuance, triggering and execution of contracts. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the contract logic is triggered by calling keys or other events to trigger execution. The contract logic is completed and the contract upgrade and cancellation functions are also provided. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarms, network status detection, and monitoring of node equipment health.

[0041] The platform's product service layer provides the basic capabilities and implementation framework for typical applications. Developers can build on these basic capabilities, overlay business features, and complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0042] The following is an introduction to some of the terms used in this application:

[0043] Smart contract: A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, which are traceable and irreversible.

[0044] Blockchain ledger: The blockchain is the core data structure in a blockchain system, used to store and manage all confirmed blocks. Organized in a chain-like structure, each block contains a set of transactions, a block header (including the hash value of the previous block, metadata such as a timestamp), and other information. The blockchain provides a public, immutable record of transaction history, ensuring transparency and consistency.

[0045] State data: State data is a data structure used in blockchain systems to represent the current state of the system. This data includes the balances of all accounts, the status of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security.

[0046] Transaction Pool: A transaction pool (also known as a memory pool or mem pool) is a data structure within a blockchain network that stores pending transactions that have not yet been included in a block. When a user submits a new transaction to the blockchain network, it first enters the transaction pool. When a blockchain node prepares to generate a new block, it selects a certain number of transactions from the transaction pool for inclusion. The transaction pool helps improve the processing capacity of the blockchain network.

[0047] Process Pool: A process pool is a computer resource management technology used to manage and optimize the creation and allocation of processes. In a process pool, the system pre-creates a certain number of processes and keeps them in an idle state, awaiting tasks. When a new task arrives, an idle process from the pool is quickly assigned to handle it, rather than creating a new process each time a task arrives. This approach reduces the overhead of creating and destroying processes, improving system responsiveness and efficiency. In the context of blockchain smart contracts, process pools can be used to manage smart contract execution and improve smart contract processing efficiency.

[0048] Dual Snapshot: Dual snapshot is a data management technique that involves creating two independent data snapshots for different purposes. In the context of blockchain smart contract debugging, dual snapshots refer to the creation of two parallel snapshot versions: one for recording actual on-chain transaction data, and the other for recording transaction data during debugging. This allows smart contracts to be debugged and tested without affecting mainchain data, while ensuring that debugging activities do not interfere with live transactions.

[0049] On-chain debugging: On-chain debugging refers to the process of debugging smart contracts directly on the blockchain network. Unlike traditional off-chain debugging (which occurs outside the blockchain network), on-chain debugging allows developers to test and fix code in the actual running environment of the smart contract. This debugging method provides developers with access to the full on-chain data and state, allowing for more accurate diagnosis of issues. On-chain debugging is a relatively new technology, as it requires specialized tools and mechanisms to ensure that the debugging process does not interfere with the normal operation of the network.

[0050] Key Transformation Service: A key transformation service is a database service that transforms or maps key values ​​when querying data. In the context of blockchain, the key transformation service can be used to manage and access data in different snapshots. For example, when using dual-snapshot technology for smart contract debugging, the key transformation service can help distinguish and access snapshots containing real transaction data from snapshots containing debug transaction data. By transforming key values ​​with specific prefixes or suffixes, this service ensures that the correct data is queried and operated on, while maintaining data isolation and integrity.

[0051] The smart contract debugging method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown in FIG. Among them, the blockchain network can be composed of multiple blockchain nodes, such as Figure 1 The illustrated application environment includes multiple blockchain nodes, such as blockchain node 102, blockchain node 104, and blockchain node 106. Each blockchain node can communicate with each other via a network. Each blockchain node can rotate as a master node. For example, blockchain node 102 can rotate as the master node, while blockchain nodes 104 and 106 can be slave nodes in the blockchain network. The master node can receive a debug transaction request from a transaction processing requester and, based on the transaction data in the debug transaction request, determine the target contract to be debugged in the blockchain network and enter the debugging phase for the target contract. The master node can also create a first snapshot and a second snapshot associated with the target contract. Data generated by actual on-chain operations related to the target contract can be stored in the first snapshot, and data generated by on-chain debugging operations related to the target contract can be stored in the second snapshot. Once debugging of the target contract is complete, the blockchain network's status database can be updated based on the data stored in the first snapshot. Furthermore, during the debugging phase of the target contract, the data stored in the second snapshot can be used to record debugging data, enabling more efficient problem location and debugging status determination. After debugging is complete, the data in the second snapshot can be deleted to free up storage space and optimize storage resources.

[0052] In some embodiments, as Figure 2 As shown in the figure, it is a schematic diagram of the structure of the blockchain node in the blockchain. For each blockchain node in the blockchain, the following can be deployed Figure 2 The architecture shown. Figure 2 In the blockchain, the nodes can specifically include multiple functional modules such as network module, verification module, transaction pool module, scheduling module, consensus module and storage module.

[0053] The network module is responsible for handling communication between blockchain nodes, including sending and receiving transactions, consensus information, block data, and other network messages. It handles communication between nodes and handles network connections and data synchronization. It ensures that information in the blockchain network can be transmitted and synchronized between nodes.

[0054] The verification module is responsible for verifying the certificates and permissions of transactions to ensure the legitimacy and security of transactions.

[0055] The transaction pool module is responsible for storing pending transactions and providing transaction data to blockchain nodes. It manages and stores transactions that have not yet been included in blocks. It maintains a transaction queue and selects transactions for block inclusion based on specific policies (such as fee and timestamp).

[0056] The scheduling module is responsible for obtaining transactions from the transaction pool module and scheduling their execution.

[0057] Consensus module: Responsible for implementing the consensus mechanism in the blockchain network, such as Proof of Work (PoW), Proof of Stake (PoS), etc. It ensures that all nodes reach a consensus on the network status and verifies the legitimacy of the block.

[0058] Storage module: The storage module is responsible for managing the data storage of blockchain nodes, including block ledgers and status data.

[0059] In other embodiments, reference Figure 3 FIG. 1 is a schematic diagram of the structure of a blockchain node in another embodiment. Figure 3 In the , further functional refinement was carried out for some modules of the blockchain node, including:

[0060] The verification module can include a certificate verification module and an authority verification module. The certificate verification module is responsible for verifying the source of transactions or blocks, ensuring that they come from legal and trusted nodes, and ensuring the legitimacy of transactions by checking the digital certificate and signature of the transaction processing requester; the authority verification module is responsible for checking whether the transaction processing requester has the authority to execute the transaction, such as whether the smart contract call is initiated by a legal account.

[0061] The scheduling module is the core of the blockchain node, responsible for coordinating various tasks and processes. It contains the following submodules:

[0062] Block generator: responsible for generating new blocks and packaging transactions in the transaction pool module into blocks.

[0063] Block transaction scheduling module: responsible for managing and scheduling the execution process of ordinary transactions.

[0064] Debug transaction scheduling module: specifically responsible for managing and scheduling the execution process of debug transactions.

[0065] Contract repository: stores and manages smart contract codes and related information.

[0066] Contract transaction process pool: provides process resources for executing smart contract transactions and optimizes execution efficiency.

[0067] Contract debugging process pool: provides dedicated process resources for executing smart contract debugging transactions.

[0068] The storage module can consist of the following two main parts:

[0069] State database: stores the current state of the blockchain, such as account balances, smart contract status, etc.

[0070] Blockchain ledger: stores all blocks that have been agreed upon by the network and appended to the blockchain, forming an unalterable transaction history record.

[0071] Among them, the state database contains two sub-modules:

[0072] Key transformation service: Transforms key values ​​during querying to support data isolation in dual snapshot technology.

[0073] State storage: responsible for storing and managing state data, such as account information and storage variables of smart contracts.

[0074] Blockchain nodes can be various types of computer devices, specifically terminals or servers. Terminals can include, but are not limited to, desktop computers, laptops, smartphones, tablets, IoT devices, portable wearable devices, intelligent voice interaction devices, smart home appliances, in-vehicle terminals, aircraft, and the like. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smart watches, smart bracelets, and head-mounted devices. Servers can be implemented as standalone servers or server clusters consisting of multiple servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communications. The embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0075] In one embodiment, Figure 4 As shown, a smart contract debugging method is provided, which is applied to Figure 1 Taking any blockchain node that rotates to be the master node as an example, the following steps are included:

[0076] Step 402: Determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract.

[0077] The target contract is the smart contract that is designated for debugging within the pending transaction data received by the blockchain node. The debugging phase of the target contract is the phase in the blockchain network where the target contract is tested, adjusted, and optimized.

[0078] Specifically, the blockchain node's network module can receive transaction data sent by the transaction request processor. The blockchain node's authentication module can verify the legitimacy of the transaction data and store verified transaction data in the blockchain node's transaction pool module. The blockchain node's scheduling module can retrieve and execute pending transaction data from the transaction pool module, obtaining the processing results. Furthermore, the blockchain node's consensus module can initiate consensus based on the transaction data and processing results. Once consensus is reached, the blockchain node's storage module stores and updates the data. Furthermore, the blockchain node can determine the target contract to debug based on the pending transaction data. The transaction data can include various information, including the contract name to be debugged, version information, contract methods, parameters, timestamps, and caller information.

[0079] In some embodiments, transaction data is generated and sent to a blockchain node by a transaction request handler. Specifically, the transaction request handler may send a debug transaction request containing the transaction data to the blockchain node. For example, the transaction request handler may initiate a debug transaction request when it determines that a smart contract deployed on a blockchain node has caused online data errors or other inexplicable issues after the blockchain network has been running for a period of time. Alternatively, the debug transaction request may be initiated by the transaction request handler when the debug interval set for the smart contract has expired.

[0080] In some embodiments, a transaction processing requester refers to the party that initiates a business data processing request during a blockchain-based business process. This requester can be a terminal device, such as a mobile phone used by a user that can receive user operation information, or an application or mini-program. Furthermore, the terminal device can also be a terminal used by an organization or institution, such as a computer used by an institution to authenticate the characteristic information provided by a plaintiff, or a computer used by an employer to authenticate the certificate provided by an applicant.

[0081] In some embodiments, for transaction data received by the network module, the verification module can perform certificate verification and authority verification on the received transaction data. When performing certificate verification, the digital certificate and signature of the transaction generator in the transaction data can be checked. If the digital certificate and signature are legal, the certificate verification is passed. When performing authority verification on the received transaction data, the authority level and access rights of the transaction generator in the transaction data can be verified. If it is determined that the transaction generator has the authority to execute the transaction, the authority verification is passed. When both certificate verification and authority verification indicate that the verification is passed, it is determined that the validity verification is passed.

[0082] In other embodiments, when either the certificate verification or the permission verification result indicates a failure, the execution process of the transaction data is terminated. Specifically, if the certificate verification fails, a certificate verification failure result is returned, and the execution process of the transaction data is terminated; if the permission verification fails, a permission verification failure result is returned, and the execution process of the transaction data is terminated.

[0083] Step 404: Create a first snapshot and a second snapshot associated with the target contract.

[0084] The snapshot refers to a data snapshot used to record or store data generated during the debugging phase. The first snapshot and the second snapshot are two independent snapshots, each used to store data generated by different operations during the debugging phase.

[0085] Specifically, after determining the target contract to be debugged in the blockchain network, the blockchain node may suspend entering data related to the target contract into the state database and create a first snapshot and a second snapshot associated with the target contract. The first and second snapshots created are empty snapshots.

[0086] In some embodiments, during the debugging phase, the blockchain node may process real transactions related to the target contract, and may also process debugging transactions related to the target contract. The first snapshot is used to store relevant data generated by processing real transactions, and the second snapshot is used to store relevant data generated by processing debugging transactions.

[0087] In some embodiments, creating a first snapshot and a second snapshot associated with a target contract includes: creating at least two empty snapshots associated with the target contract; adding a first identifier to the created empty snapshot to obtain a first snapshot; adding a second identifier to the created empty snapshot to obtain a second snapshot; the second identifier is different from the first identifier.

[0088] The identifier is used to distinguish different snapshots, so that different snapshots are represented by different identifiers. The identifier can be set using any identifier that can be used for identification, such as letters, numbers, and feature codes, and is not limited here.

[0089] Specifically, a blockchain node can create two empty snapshots, add a first identifier to the created empty snapshot to obtain a first snapshot, and add a second identifier to the created empty snapshot to obtain a second snapshot. When the blockchain node adds the identifier to the created empty snapshot, the identifier and the snapshot can be combined according to a specific format. For example, the identifier can be added to the beginning, end, or middle of the empty snapshot, as long as different snapshots can be distinguished. This embodiment of the present application does not impose any restrictions on this.

[0090] In some embodiments, blockchain nodes can use letters as identifiers. For example, the first identifier can be "tx" and the second identifier can be "debug." When adding identifiers to a created empty snapshot, a blockchain node can start with "tx" to obtain the first snapshot, which can be represented as "tx + empty snapshot." A blockchain node can start with "debug" to obtain the second snapshot, which can be represented as "debug + empty snapshot."

[0091] In the above embodiment, blockchain nodes effectively separate debugging activities from real-time on-chain operations by creating two parallel snapshots: the first snapshot stores data related to processing real transactions, and the second snapshot stores data related to processing debug transactions. This dual-snapshot mechanism not only protects the data integrity of the main chain but also allows developers to debug in a real on-chain environment, enabling more accurate diagnosis and repair of issues in the target contract.

[0092] Step 406: Store the data generated by the actual on-chain operation related to the target contract in the first snapshot, and store the data generated by the on-chain debugging operation related to the target contract in the second snapshot.

[0093] Data generated by on-chain operations refers to the data obtained by processing real transactions on the chain. Real transactions refer to transactions generated by actual business activities in the blockchain network. Data generated by on-chain debugging operations refers to the data obtained by processing debugging transactions generated when debugging smart contracts. Debugging transactions refer to transactions generated during the debugging process to verify the security and functionality of smart contracts.

[0094] Specifically, during the debugging phase of a target contract, a blockchain node can identify whether the transaction data for the target contract originates from a real transaction or a debug transaction. If it originates from a real transaction, the transaction data is processed to obtain data generated by the actual on-chain operation and stored in the first snapshot. If it originates from a debug transaction, the transaction data is processed to obtain data generated by the on-chain debug operation and stored in the second snapshot.

[0095] In some embodiments, a blockchain node can identify a transaction identifier carried in transaction data for a target contract and, based on the transaction identifier, determine whether the transaction data originates from a real transaction or a debug transaction. For example, if the blockchain node's scheduling module identifies a transaction identifier of "A," it indicates that the transaction data originates from a real transaction. If the blockchain node's scheduling module identifies a transaction identifier of "B," it indicates that the transaction data originates from a debug transaction.

[0096] In some embodiments, reference Figure 5 The following is a schematic diagram of the structure of the blockchain node after the snapshot is created. Figure 5 For any blockchain node in the blockchain network, there is a target contract on the blockchain node. For example, for blockchain node 1, contract 1 is the target contract; for blockchain node 2, contract 2 is the target contract; for blockchain node 3, contract 3 is the target contract; and for blockchain node 4, contract 4 is the target contract.

[0097] For each blockchain node that hosts the target contract, two snapshots are created: the first snapshot and the second snapshot. Real transactions correspond to the first snapshot, which stores the data generated by processing real transactions. Debug transactions correspond to the second snapshot, which stores the data generated by processing debug transactions.

[0098] In addition, the state database of each blockchain node contains pre-snapshot data, other contracts, and related data. Pre-snapshot data refers to data before the creation of the first and second snapshots. Other contracts and related data refers to data related to smart contracts that are not in the debugging phase.

[0099] In one specific application, when debugging a smart contract is needed in a blockchain network, the transaction request handler can send a debugging transaction request to the blockchain node that has rotated to become the master node in the blockchain network, effectively launching smart contract debugging on a single node. Furthermore, the blockchain node pauses storing data related to the smart contract in the state database and creates two empty snapshots. One snapshot records data generated by actual on-chain operations related to the smart contract, while the other records data generated by on-chain debugging operations related to the smart contract. With this single-node dual-snapshot mechanism, the debugging transaction request only needs to be sent to the master node in the blockchain network for execution, eliminating the need for all blockchain nodes to participate. This enables isolated single-node debugging of blockchain smart contracts, improving the security of the debugging process and preventing unnecessary interference. Furthermore, by creating two snapshots, debugging activities are effectively separated from real-time on-chain operations. This mechanism not only protects the data integrity of the main chain but also allows debugging to be performed in a real on-chain environment, enabling more accurate diagnosis and repair of smart contract issues. In step 408, if debugging of the target contract is complete, the blockchain network's state database is updated based on the data stored in the first snapshot.

[0100] Specifically, if the debugging of the target contract has been completed, the blockchain node can merge the data stored in the first snapshot into the state database, and the state database can also start to continue entering data for the target contract.

[0101] In some embodiments, if debugging of the target contract is completed, the blockchain node may delete the data in the second snapshot to free up storage space.

[0102] In the above-described smart contract debugging method, a target contract to be debugged is identified in the blockchain network and the debugging phase of the target contract begins, i.e., debugging the target contract directly on the blockchain network. A first snapshot and a second snapshot are further created, associated with the target contract, so that the first snapshot stores data generated by actual on-chain operations related to the target contract, while the second snapshot stores data generated by on-chain debugging operations related to the target contract. Once debugging of the target contract is complete, the blockchain network's state database is updated based on the data stored in the first snapshot. First, unlike traditional off-chain debugging (debugging outside the blockchain network), this solution debugs the target contract in a real on-chain environment, providing access to complete on-chain data and state, enabling more accurate diagnosis and remediation of issues within the target contract. Second, the creation of the first and second snapshots effectively separates debugging operations from real-time on-chain operations, allowing debugging and testing of the target contract without affecting main-chain data, while ensuring that debugging operations do not interfere with real-time on-chain operations. Finally, after debugging is completed, by updating the data generated by the actual on-chain operations in the first snapshot into the state database, it is ensured that the data generated by the actual on-chain operations during the debugging process can be accurately recorded and reflected on the chain. Through this optimized data synchronization and merging operation, the maintainability of the target contract and the stability of on-chain operations are improved.

[0103] In one embodiment, determining a target contract to be debugged in a blockchain network includes: receiving a debugging transaction request; the debugging transaction request carries a contract identifier of the contract to be debugged; performing an on-chain operation on the debugging transaction request, and determining the target contract to be debugged in the blockchain network based on the contract identifier after the on-chain operation is successful.

[0104] A debug transaction request is initiated by the transaction request handler to initiate the debugging phase of a smart contract. Contract identifiers are used to identify different smart contracts. Contract identifiers can be any identifier, including letters, numbers, and signatures, without limitation. The purpose of the on-chain operation is to add the data or contract information associated with the debug transaction request to the blockchain.

[0105] Specifically, the blockchain node's network module can receive debug transaction requests and perform on-chain operations based on them. During this on-chain process, the blockchain node's verification module can perform certificate and permission verification on the transaction data received in the debug transaction request. Once verified, the transaction data can be stored in the transaction pool module. The blockchain node's scheduling module can retrieve the transaction data from the transaction pool module and schedule its execution. The consensus module then reaches consensus, and after reaching consensus, the data is stored in the storage module, completing the on-chain process.

[0106] In some embodiments, in addition to carrying the contract identifier of the contract to be debugged, the debugging transaction request may also carry relevant information such as the contract name and version of the contract to be debugged.

[0107] In the above embodiment, when a blockchain node receives a debugging transaction request, it performs an on-chain operation on the debugging transaction request, and then determines the target contract to be debugged after the on-chain operation is successful, thereby carrying out an on-chain debugging process on the blockchain network. Using on-chain debugging can more effectively locate problems.

[0108] In one embodiment, the on-chain operation is performed for the debugging transaction request, including: verifying the validity and legality of the transaction data in the debugging transaction request; generating a new block based on the transaction data that passes the validity and legality verifications; adding the new block that passes the consensus to the blockchain network, and updating the status database based on the new block.

[0109] Validity verification is the process of verifying the certificate, signature, and authority of transaction data. Legality verification is the process of verifying the legality of debugging transaction data.

[0110] Specifically, the verification module of the blockchain node can verify the validity of the transaction data, and the block transaction scheduling module of the blockchain node can verify the legality of the transaction data. The order of validity verification and legality verification can be adaptively adjusted according to actual needs, scenarios, etc. For transaction data that passes the validity verification and legality verification, the block generator of the blockchain node can block the transaction data, generate a new block, and further forward the new block to other blockchain nodes in the blockchain network. The other blockchain nodes verify the transaction data. If the other blockchain nodes also pass the verification, all blockchain nodes in the blockchain network broadcast and reach consensus on the new block. If the consensus is passed, the new block that passes the consensus will be appended to the block ledger in the blockchain network for storage, and the latest status data related to the new block will be updated to the status database.

[0111] In some embodiments, when a blockchain node generates a new block based on transaction data, it may do so based on a batch of transaction data that has passed both validity and legality verifications. This means that the new block may include multiple transactions. Because debugging is performed on a single node and only records are kept on-chain, other blockchain nodes in the blockchain network will skip verifying the debugging-related transaction data when verifying the transaction data in the new block, and only verify the transaction data not used for debugging. This effectively reduces the computational resources of blockchain nodes.

[0112] In some embodiments, during the process of certificate and signature verification of transaction data by the authentication module of the blockchain node, if the certificate and signature verification fail, a verification failure result is returned and the chain-up process of the transaction data is terminated.

[0113] In some embodiments, during the process of the authentication module of the blockchain node performing permission verification on the transaction data, if the permission verification fails, a verification failure result is returned and the transaction data chain process is terminated.

[0114] In the above embodiment, the blockchain node can verify the validity and legality of the transaction data. If the validity verification and the legality verification are passed, a new block is generated based on the transaction data, and the new block that passes the consensus is added to the blockchain network. The status database is updated based on the new block, thereby ensuring the normal operation of the blockchain network and the legality and authenticity of the transaction.

[0115] In one embodiment, the process of legitimacy verification includes: performing debugging legitimacy verification based on transaction data, and determining that the legitimacy verification has passed if the contract to be debugged is not in debugging.

[0116] Specifically, the blockchain node can determine whether the contract to be debugged indicated in the transaction data is being debugged. If the contract to be debugged is not being debugged, it is determined that the legality check has passed; if the contract to be debugged is already being debugged, it is determined that the legality check has not passed. If the legality check has not passed, an error indicating that the contract is currently being debugged is returned.

[0117] In some embodiments, when the legitimacy check fails, the block generator of the blockchain node may also encapsulate the transaction data into blocks, generate a new block, and further forward the new block to other blockchain nodes in the blockchain network, and the other blockchain nodes verify the transaction data. If the other blockchain nodes also pass the verification, all blockchain nodes in the blockchain network broadcast and reach consensus on the new block. If the consensus passes, the new block that passes the consensus will be appended to the block ledger in the blockchain network for storage, and the latest status data related to the new block will be updated to the status database.

[0118] In the above embodiment, the blockchain node determines whether the contract to be debugged is being debugged and conducts legitimacy verification of the contract to be debugged, thereby avoiding the situation where the debugging process of the contract to be debugged is restarted when the contract to be debugged is already being debugged.

[0119] In some embodiments, reference Figure 6 FIG. 1 is a flow chart of determining a target contract in one embodiment. Figure 6 The process of determining the target contract shown can be based on Figure 3The deployment architecture of the blockchain node in the blockchain network can be implemented, and specifically can include the following steps: In the blockchain network, after the target contract determination process begins, the following steps are included:

[0120] S601: The transaction request processor packages the contract name and version information to be debugged.

[0121] S602: The transaction request processor signs the packaged content.

[0122] S603: The transaction request processor sends a contract debugging request, which sends the packaged content and signature to the master node. The master node rotates in the blockchain network.

[0123] S604: The network module of the master node receives the contract debugging request.

[0124] S605: The authentication module of the master node performs certificate and signature verification on the transaction data in the above certificate and signature verification, and determines whether the verification is successful. If the verification is successful, the process proceeds to S624 and returns a result indicating that the signature verification failed. If the verification is successful, the process proceeds to S606.

[0125] S606, the master node's authentication module performs permission verification on the contract debugging request and determines whether the verification is successful. If the verification is successful, the process proceeds to S623 and returns a result indicating that the permission verification failed. If the verification is successful, the process proceeds to S607. The transaction data that passes the certificate and signature verification and permission verification will be stored in the transaction pool module.

[0126] S607: The block generator in the scheduling module of the master node obtains the transaction data from the transaction pool module, prepares to execute the transaction data, and packages it into a new block.

[0127] S608, the transaction scheduling module of the scheduling module executes the transaction data and checks the legitimacy of the debugging;

[0128] S609: The transaction scheduling module determines whether the contract in the transaction data is being debugged. If yes, go to S611; otherwise, go to S610.

[0129] S610, returning a result of successful debugging verification;

[0130] S611, returns the error currently being debugged;

[0131] S612: Add the check result and related information such as contract name and version to the transaction result.

[0132] S613: The block generator module of the master node performs block encapsulation, generates a new block, and forwards the generated new block to the slave node;

[0133] S614: After receiving the new block, the slave node begins verifying transactions. For debugging-related transactions in the new block, verification is skipped because debugging is performed on a single node and only records are kept on the chain.

[0134] S615, all blockchain nodes broadcast and reach consensus on the block;

[0135] S616: Check whether the consensus is passed. If so, proceed to S617; if not, end the process.

[0136] S617, all blockchain nodes append the new block to the block ledger for storage;

[0137] S618: All blockchain nodes update the latest state data into the state database;

[0138] S619: The master node determines the target contract and starts debugging and opening transactions.

[0139] S620, the master node state database suspends data entry of the target contract;

[0140] S621: The master node creates a new empty snapshot, starting with tx, to store subsequent data related to the real transaction.

[0141] S622: The master node creates a new empty snapshot starting with debug to store subsequent data related to the debug transaction.

[0142] S623, returns the result of permission verification failure;

[0143] S624: Return the result indicating signature verification failed.

[0144] In one embodiment, data generated by actual operations on the chain related to the target contract are stored in a first snapshot, and data generated by debugging operations on the chain related to the target contract are stored in a second snapshot, including: obtaining transaction data for the target contract, processing the transaction data to obtain a processing result; if the transaction data comes from a real transaction, determining the data generated by the actual operation on the chain based on the processing result, and storing the data generated by the actual operation on the chain in the first snapshot; if the transaction data comes from a debugging transaction, determining the data generated by the debugging operation on the chain based on the processing result, and storing the data generated by the debugging operation on the chain in the second snapshot.

[0145] Real transactions refer to normal transactions within a blockchain network, i.e., transactions unrelated to debugging. Real transactions may include data such as the contract to be called, its methods, and parameters, used to implement transactions within the blockchain network. Debug transactions, unlike real transactions, are transactions related to debugging operations and are used to perform debugging-related operations.

[0146] Specifically, for the transaction data of the target contract, the blockchain node can determine the source of the transaction data. If the transaction data originates from a real transaction, the blockchain node's block transaction scheduling module processes the transaction data, obtains a processing result, and determines the data generated by the actual on-chain operation based on the processing result, and stores the data generated by the actual on-chain operation in the first snapshot. If the transaction data originates from a debug transaction, the blockchain node's debug transaction scheduling module processes the transaction data, obtains a processing result, and determines the data generated by the on-chain debug operation based on the processing result, and stores the data generated by the on-chain debug operation in the second snapshot.

[0147] In some embodiments, the scheduling module of a blockchain node can identify a transaction identifier carried in the transaction data for a target contract and, based on the transaction identifier, determine whether the transaction data originates from a real transaction or a debug transaction. For example, if the transaction identifier identified by the scheduling module of the blockchain node is "A," it indicates that the transaction data originates from a real transaction. If the transaction identifier identified by the scheduling module of the blockchain node is "B," it indicates that the transaction data originates from a debug transaction.

[0148] In the above embodiment, the blockchain node processes transaction data for the target contract, obtains a processing result, and determines the source of the transaction data. If the transaction data originates from a real transaction, the processing result is used to determine the data generated by the actual on-chain operation and further store it in the first snapshot. If the transaction data originates from a debug transaction, the processing result is used to determine the data generated by the on-chain debugging operation and further store it in the second snapshot. By setting up two snapshots, debugging activities can be securely isolated from real-time on-chain operations. This isolation ensures the stability of the main chain and the uninterrupted processing of transactions, while allowing developers to debug in a secure environment without worrying about the debugging operations negatively impacting the real-time network.

[0149] In one embodiment, processing transaction data to obtain a processing result includes: if the transaction data comes from a real transaction, obtaining a first contract process that matches the target contract from a contract transaction process pool, processing the transaction data through the first contract process, and obtaining a processing result; if the transaction data comes from a debugging transaction, obtaining a second contract process that matches the target contract from a contract debugging process pool, processing the transaction data through the second contract process, and obtaining a processing result.

[0150] The contract process is a process stored in the process pool. The first contract process is used to process transaction data from real transactions and is stored in the contract transaction process pool. The second contract process is used to process transaction data from debug transactions and is stored in the contract debug process pool.

[0151] Specifically, if the transaction data originates from a real transaction, the blockchain node's block scheduling module can retrieve an available contract process from the contract transaction process pool, start the retrieved contract process, and execute the transaction data based on the started contract process. If the transaction data originates from a debug transaction, the blockchain node's debug transaction scheduling module can retrieve an available contract process from the contract debug process pool, start the retrieved contract process, and execute the transaction data based on the started contract process.

[0152] In some embodiments, for on-chain debugging scenarios, blockchain nodes can be configured with dual process pools: corresponding process pools and scheduling modules for real transactions and debug transactions during the debugging phase, respectively. This allows debugging activities to be completely isolated from the mainnet operation. This isolation ensures the stability of the mainchain and undisturbed transaction processing, while allowing developers to debug in a secure environment without worrying about the negative impact of debugging operations on the live network.

[0153] In some embodiments, for the contract transaction process pool, a single contract can have multiple processes associated with it; for the contract debugging process pool, a single contract can have only one process associated with it. This configuration is determined based on the process resource requirements of the actual production and debugging processes. Since production processes may involve highly concurrent transaction processing, more process resources can be allocated to each contract. However, to reduce operational risks and errors during debugging, which generally does not involve concurrent transaction processing, only one process resource can be allocated to each contract. This configuration allows for the optimal allocation of blockchain node resources.

[0154] For example, when a blockchain node determines that transaction data originates from a real transaction, it can determine an idle process from the contract transaction process pool and execute the transaction data based on the idle process.

[0155] In some embodiments, reference Figure 7 The following is a schematic diagram of the structure of a blockchain node in one embodiment: Figure 7 As can be seen, in the contract transaction process pool, contract 1 can correspond to process 1 and process 2; for contract 2, it can correspond to process 3 and process 4. In the contract debugging process pool, contract 1 corresponds to process 1, and contract 2 corresponds to process 2.

[0156] In the above embodiment, blockchain nodes are equipped with corresponding process pools and scheduling modules for both real and debug transactions during the debugging phase, thus completely isolating debugging activities from the mainnet. This isolation ensures the stability of the mainchain and undisturbed transaction processing, while allowing developers to debug in a secure environment without worrying about negative impacts on the live network.

[0157] In one embodiment, the smart contract debugging method also includes: in the process of processing transaction data, if there is a query business and the transaction data comes from a real transaction, then based on the first identifier of the first snapshot and the target keyword of the query business, a target search item is constructed, and a query is performed in the first snapshot based on the target search item to obtain a query result; if there is a query business and the transaction data comes from a debugging transaction, then based on the second identifier of the second snapshot and the target keyword of the query business, a target search item is constructed, and a query is performed in the second snapshot based on the target search item to obtain a query result.

[0158] Query services are services related to querying information in a blockchain network. Keywords are used to identify data. Target keywords can be used to identify query services.

[0159] A search term is a condition or keyword entered to limit the search scope when performing a data query or information retrieval. For blockchain networks using key-value storage, the search term can specifically refer to the key value in the storage module. The target search term is the search term corresponding to the query. The target search term constructed varies depending on the query originating from different transactions. The process of constructing the target search term can be considered a key conversion service, used to convert or map key values ​​when querying data.

[0160] Specifically, during the process of processing transaction data through a blockchain node process, if a query service exists, for example, to read required data from a target contract, a target search term can be constructed. Based on the target search term, a query is performed within the blockchain node's storage module to obtain data matching the target search term. Based on the data matching the target search term, a query result is determined. For different snapshots, the target search term can be constructed based on the snapshot identifier corresponding to each snapshot and the target keyword of the query service.

[0161] In some embodiments, when determining the target search term, the target keyword and the snapshot identifier can be combined according to a set format. For example, the combination can be in the format of target keyword + snapshot identifier, or in the format of snapshot identifier + target keyword, and the embodiments of the present application are not limited thereto. For example, if the combination is in the format of snapshot identifier + target keyword, then for the case where the transaction data is derived from a real transaction, the target search term can be the first identifier - target keyword; and for the case where the transaction data is derived from a debug transaction, the target search term can be the second identifier - target keyword.

[0162] In some embodiments, when no matching data is found based on the target search term, a search can be directly performed in the storage module based on the target keyword of the query service, thereby expanding the scope of the search.

[0163] In a specific application, refer to Figure 8 FIG. 1 is a flowchart of a process for performing a business query on a real transaction in one embodiment.

[0164] from Figure 8 As can be seen, for query services originating from real transactions, there is a corresponding target keyword 1. The blockchain node can construct a target search term "first identifier - target keyword 1" based on target keyword 1 and the first identifier of the first snapshot, and conduct a query in the storage module based on the target search term "first identifier - target keyword 1". If the storage module cannot find the query based on "first identifier - target keyword 1", the storage module can be directly queried based on target keyword 1. Specifically, target keyword 1 can be "c1-key1", the first identifier can be "tx", and the target search term can be "tx-c1-key1".

[0165] In another specific application, reference Figure 9 FIG. 1 is a flowchart of a process for launching a business query for a debugging transaction in one embodiment.

[0166] from Figure 9 As can be seen, for queries originating from debug transactions, which correspond to target keyword 1, the blockchain node can construct the target search term "second identifier-target keyword 1" based on target keyword 1 and the second identifier of the second snapshot, and conduct a query in the storage module based on the target search term "second identifier-target keyword 1". If the storage module cannot find the query based on "second identifier-target keyword 1", the query can be directly conducted in the storage module based on target keyword 1. Specifically, target keyword 1 can be "c1-key1", the first identifier can be "debug", and the target search term can be "debug-c1-key1".

[0167] In the above embodiment, when there is a query business during the transaction processing, the blockchain node constructs corresponding target search items for transaction data from different sources, and conducts a query in the storage module based on the target search items. By adding a specific prefix or suffix to the target keyword to convert the key value, it ensures that the correct data is queried and operated, while maintaining data isolation and integrity.

[0168] In one embodiment, the data generated by the actual operation on the chain is stored in the first snapshot, including: obtaining a first keyword corresponding to the data generated by the actual operation on the chain; obtaining a search item for the data generated by the actual operation on the chain based on the first keyword and the first identifier of the first snapshot; and associating the obtained search item with the data generated by the actual operation on the chain and storing them in the first snapshot.

[0169] Keywords are used to identify data generated during the debugging phase. Keywords can be set using any identifier, such as letters, numbers, or signatures. The first keyword is used to identify data generated by actual operations on the chain.

[0170] Specifically, the blockchain node may obtain a first keyword, combine the first keyword and the first identifier, obtain a search term for the data generated by the actual operation on the chain, and associate the obtained search term with the data generated by the actual operation on the chain and store it in the first snapshot. When combining the first keyword and the first identifier, the blockchain node may combine them in the order of first keyword + first identifier or in the order of first identifier + first keyword, which is not limited in this embodiment of the present application.

[0171] In some embodiments, the first keyword and the first identifier may be composed of letters. The first keyword may be "contract1-key1", the first identifier may be "tx", and the search item composed of the first keyword and the first identifier may be "tx-contract1-key1".

[0172] In some embodiments, reference Figure 10 The following is a schematic diagram of snapshot changes in one embodiment:

[0173] The storage module of the blockchain node may include a search item and data corresponding to the search item. The storage module may include pre-snapshot data, data stored in the first snapshot, and data stored in the second snapshot. The pre-snapshot data is data stored in the storage module before the snapshot is created.

[0174] For the data before the snapshot, it can include keyword 1, keyword 2, keyword 3, keyword 4, and the data corresponding to keyword 1, keyword 2, keyword 3, and keyword 4 respectively; the data stored in the first snapshot can include the first identifier - keyword 1 and its corresponding data, the first identifier - keyword 2 and its corresponding data; the data stored in the second snapshot can include the second identifier - keyword 1 and its corresponding data, the second identifier - keyword 2 and its corresponding data.

[0175] For transaction data derived from real transactions, the blockchain node can determine the first keyword corresponding to the data generated by the actual operation on the chain, and based on the first keyword and the first identifier of the first snapshot, combine the first identifier as a prefix with the first keyword to obtain the search terms for the data generated by the actual operation on the chain, and associate the obtained search terms with the data generated by the actual operation on the chain and store them in the first snapshot. Figure 10 "First identifier - first keyword 3 and its corresponding data 2" in.

[0176] In the above embodiment, the blockchain node can create a first snapshot specifically for recording data generated by actual operations on the chain, thereby effectively separating debugging activities from real-time chain operations.

[0177] In one embodiment, storing data generated by an on-chain debugging operation in a second snapshot includes: obtaining a second keyword corresponding to the data generated by the on-chain debugging operation; obtaining a search item for the data generated by the on-chain debugging operation based on the second keyword and the second identifier of the second snapshot; and associating the obtained search item with the data generated by the on-chain debugging operation and storing them in the second snapshot.

[0178] Among them, the second keyword is a keyword used to identify data generated by the on-chain debugging operation.

[0179] Specifically, the blockchain node may obtain a second keyword, combine the second keyword and the second identifier, obtain a search term for the data generated by the actual operation on the chain, and associate the obtained search term with the data generated by the actual operation on the chain and store it in the second snapshot. When combining the second keyword and the second identifier, the blockchain node may combine them in the order of second keyword + second identifier or in the order of second identifier + second keyword, which is not limited in this embodiment of the present application.

[0180] In some embodiments, the second keyword and the second identifier may be composed of letters. The second keyword may be "contract1-key1", the second identifier may be "debug", and the search item composed of the second keyword and the second identifier may be "debug-contract1-key1".

[0181] In some embodiments, reference Figure 11 The following is a schematic diagram of snapshot changes in one embodiment:

[0182] The storage module of the blockchain node may include a search item and data corresponding to the search item. The storage module may include pre-snapshot data, data stored in the first snapshot, and data stored in the second snapshot. The pre-snapshot data is data stored in the storage module before the snapshot is created.

[0183] For the data before the snapshot, it can include keyword 1, keyword 2, keyword 3, keyword 4, and the data corresponding to keyword 1, keyword 2, keyword 3, and keyword 4 respectively; the data stored in the first snapshot can include the first identifier-keyword 1 and its corresponding data, the first identifier-keyword 2 and its corresponding data, the first identifier-keyword 3 and its corresponding data; the data stored in the second snapshot can include the second identifier-keyword 1 and its corresponding data, the second identifier-keyword 2 and its corresponding data.

[0184] For transaction data from debugging transactions, the blockchain node can determine the second keyword corresponding to the data generated by the on-chain debugging operation, and based on the second keyword and the second identifier of the second snapshot, use the second identifier as a prefix and combine it with the second keyword to obtain a search term for the data generated by the on-chain debugging operation, and associate the obtained search term with the data generated by the on-chain debugging operation and store it in the second snapshot. Figure 11 "Second identifier - second keyword 3 and its corresponding data 3" in.

[0185] In the above embodiment, the blockchain node can create a second snapshot specifically for recording data generated by on-chain debugging operations, thereby effectively separating debugging activities from real-time on-chain operations.

[0186] In some embodiments, reference Figure 12 The figure below is a flow chart of processing transaction data from real transactions during the debugging phase of the target contract, where: Figure 12 The process shown can be based on Figure 3 The deployment architecture of the blockchain node in the , can specifically include the following steps:

[0187] During the debugging phase of the blockchain network, after the process of processing transaction data from real transactions begins, the following steps are included:

[0188] S1201: The transaction request processor may package and encapsulate information such as the contract name, function name, parameters, and normal transaction identifier to be called;

[0189] S1202: The transaction request processor signs the packaged content.

[0190] S1203: The transaction request processor may send a transaction processing request, and send the packaged content and signature to the master node through the transaction processing request; wherein, the master node is rotated;

[0191] S1204: The network module of the master node receives the transaction processing request.

[0192] In step S1205, the authentication module of the blockchain node master node verifies the certificate and signature of the transaction processing request to determine whether the verification is successful. If the verification is successful, the process proceeds to step S1206; if the verification is unsuccessful, the process proceeds to step S1226, where a signature verification failure result is returned.

[0193] S1206: The authentication module verifies the permissions of the transaction processing request to determine whether it passes. If the verification passes, the process proceeds to S1207; if the verification fails, the process proceeds to S1225 and returns a result indicating that the permission verification fails. The transaction data that passes the certificate and signature verification and permission verification will be stored in the transaction pool module.

[0194] S1207: The block generator of the scheduling module obtains a batch of transaction data from the transaction pool module, executes the transaction data in the batch, and prepares to package it into a new block;

[0195] S1208: The transaction scheduling module of the scheduling module obtains the process of the contract from the contract transaction process pool and passes the above transaction to execute;

[0196] S1209: During the transaction execution, the process determines whether there is a data query request for the current transaction. If there is a data query request, the process proceeds to S1210; if not, the process proceeds to S1214.

[0197] S1210, whether the current contract is being debugged in the current blockchain node, if so, go to S1211, if not, go to S1212;

[0198] S1211, the key conversion service of the storage module adds a prefix of the first identifier to the request for querying data and then performs the query, specifically, adding a prefix of tx and then performing the query, and determines whether the query results are found. If the query results are found, the process goes to S1213; if not, the process goes to S1212;

[0199] S1212: The storage module queries directly, i.e., without adding the tx prefix;

[0200] S1213, the storage module returns the query result;

[0201] S1214: The block generator of the scheduling module waits for all transactions to be executed and packages the results into a block.

[0202] S1215, the master node block generator module forwards the block to the slave node;

[0203] S1216, after receiving the block from the node, the transaction is also executed for transaction verification;

[0204] S1217, if the contract on a node is being debugged and has a query service, tx prefix query is also prioritized;

[0205] S1218, all blockchain nodes broadcast and reach consensus on the block;

[0206] S1219: Check whether the consensus is passed. If so, proceed to S1220; if not, the transaction data processing flow ends.

[0207] S1220, all blockchain nodes append the latest block to the block ledger for storage;

[0208] S1221, all blockchain nodes update the latest state data into the state database;

[0209] S1222: All blockchain nodes check the transaction identifier to confirm that the transaction data comes from a real transaction, and further determine whether the current contract is being debugged on the current blockchain node. If so, go to S1224; if not, go to S1223.

[0210] S1223, the state database stores it in the state record;

[0211] S1224; The state database stores it in the record of the tx prefix.

[0212] S1225, returns the result of permission verification failure;

[0213] S1226, returns the result that the signature verification failed.

[0214] In some embodiments, reference Figure 13 The figure shows a flow chart of processing transaction data from debugging transactions during the debugging phase of the target contract, where: Figure 13 The process shown can be based on Figure 3 The deployment architecture of the blockchain node in the , can specifically include the following steps:

[0215] During the debugging phase of a blockchain network, after the process of processing transaction data from debugging transactions begins, the following steps are included:

[0216] S1301: The transaction request processor can package and encapsulate the contract name, function name, parameters, normal transaction identifier, and other information to be called;

[0217] S1302: The transaction request processor signs the packaged content.

[0218] S1303: The transaction request processor may send a transaction processing request, and send the packaged content and signature to the master node through the transaction processing request. The master node is rotated.

[0219] S1304: The network module of the master node receives the transaction processing request.

[0220] S1305: The authentication module of the blockchain node master node verifies the certificate and signature of the transaction processing request to determine whether the verification is successful. If the verification is successful, the process proceeds to S1306; if the verification is unsuccessful, the process proceeds to S1316 and returns a result that the signature verification failed.

[0221] S1306: The authentication module verifies the permissions of the transaction processing request to determine whether the verification is successful. If the verification is successful, the process proceeds to S1307; if the verification is unsuccessful, the process proceeds to S1315 and returns a result indicating that the permission verification failed. The transaction data that has passed the certificate and signature verification and permission verification will be stored in the transaction pool module.

[0222] S1307: The block generator of the scheduling module obtains a batch of transaction data from the transaction pool module, executes the transaction data in this batch, and prepares to package it into a new block.

[0223] S1308: The debugging transaction scheduling module of the scheduling module obtains the process of the contract from the debugging transaction process pool and passes the above transaction to execute;

[0224] S1309: During the transaction execution, the process determines whether there is a data query request for the current transaction. If there is a data query request, the process proceeds to S1310; if not, the process proceeds to S1314.

[0225] S1310, whether the current contract is being debugged in the current blockchain node, if so, go to S1311, if not, go to S1312;

[0226] S1311, the key conversion service of the storage module adds a second identifier prefix to the request for querying data and then performs the query, specifically, adding the prefix debug and then performing the query, and determines whether the query results are found. If the query results are found, the process goes to S1313; if not, the process goes to S1312;

[0227] S1312: The storage module is queried directly, i.e., the debug prefix is ​​not added.

[0228] S1313, the storage module returns the query result;

[0229] S1314: After the transaction is executed, the blockchain node checks that the transaction is identified as a debug transaction, and the state database stores it in a record with the debug prefix.

[0230] S1315: Return the result of permission verification failure;

[0231] S1316: Return the result indicating signature verification failed.

[0232] In one embodiment, the smart contract debugging method further includes: during the debugging phase of the target contract, if a debugging shutdown request for the target contract is obtained, performing an on-chain operation for the debugging shutdown request, and closing the debugging of the target contract after the on-chain operation is successful.

[0233] The debug shutdown request is initiated by the transaction request processor and is used to close the debugging phase of the target contract.

[0234] Specifically, when the transaction request processor determines that the debugging end conditions of the target contract have been met, it sends a debugging shutdown request to the blockchain node. The debugging shutdown request can carry the contract information to be closed for debugging. The blockchain node performs an on-chain operation based on the received debugging shutdown request and closes the debugging of the target contract after the on-chain operation is successful.

[0235] In some embodiments, after the chain is successfully uploaded, the blockchain node can determine the target contract to be closed for debugging based on the contract name to be closed for debugging in the contract information, and then close the target contract.

[0236] In some embodiments, reaching the debugging end condition may mean that the blockchain node has completed the verification of a certain function of the target contract, or has completed the correction of a certain error in the target contract, or has reached the debugging time of the target contract. The embodiments of the present application are not limited here.

[0237] In some embodiments, reference Figure 14 , which is a schematic diagram of snapshot changes after debugging in an embodiment:

[0238] The storage module of the blockchain node may include a search item and data corresponding to the search item. The storage module may include pre-snapshot data, data stored in the first snapshot, and data stored in the second snapshot. The pre-snapshot data is data stored in the storage module before the snapshot is created.

[0239] After debugging is completed, the blockchain node will delete the data stored in the second snapshot, that is, it will delete all snapshot data starting with the second identifier; for the data stored in the first snapshot, the blockchain node will remove the first identifier and merge it with the data before the snapshot. For example, the data stored in the first snapshot can be used to update the data before the snapshot.

[0240] In the above embodiment, after debugging is complete, blockchain nodes can merge the data changes in the first snapshot back into the state database securely and efficiently. This strategy ensures that all valuable changes made during the debugging process are accurately recorded and reflected on-chain, while avoiding unnecessary interference with ongoing transactions and operations. This optimized data synchronization and merging improves the maintainability of smart contracts and the stability of on-chain operations.

[0241] In some embodiments, reference Figure 15 FIG. 1 is a flow chart of shutting down the debugging phase of a target in one embodiment. Figure 15 The process shown for shutting down the debug phase of a target can be based on Figure 3 The deployment architecture of the blockchain node in the , can specifically include the following steps:

[0242] In a blockchain network, after closing the debugging phase of a target, the following steps are included:

[0243] S1501: The transaction request processor packages the contract name and version information to be closed for debugging.

[0244] S1502: The transaction request processor signs the packaged content.

[0245] S1503: The transaction request processor sends a contract debugging shutdown request, which sends the packaged content and signature to the master node. The master node rotates in the blockchain network.

[0246] S1504: The master node's network module receives the contract debugging shutdown request. The master node's authentication module performs certificate and signature verification on the transaction data in the certificate and signature verification, and determines whether the verification passes. If the verification passes, the process proceeds to S1523, returning a signature verification failure result. If the verification passes, the process proceeds to S1505.

[0247] S1505: The master node's authentication module verifies the permission of the contract debugging shutdown request and determines whether the verification is successful. If the verification is successful, the process proceeds to S1523 and returns a result indicating that the permission verification failed. If the verification is successful, the process proceeds to S1506. The transaction data that has passed the certificate and signature verification and permission verification will be stored in the transaction pool module.

[0248] S1506: The block generator in the scheduling module of the master node obtains transaction data from the transaction pool module, prepares to execute the transaction data, and packages it into a new block.

[0249] S1507, the transaction scheduling module system contract of the scheduling module executes the transaction data and checks the legitimacy of the debugging;

[0250] S1508, the transaction scheduling module determines whether the contract in the transaction data is being debugged. If so, the process goes to S1509; otherwise, the process goes to S1510;

[0251] S1509, returns the result of successful debugging verification;

[0252] S1510, returns that the system is not currently debugging;

[0253] S1511: Put the check result and related information of contract name and version into the transaction result;

[0254] S1512: The block generator module of the master node performs block encapsulation, generates a new block, and forwards the generated new block to the slave node;

[0255] S1513: After receiving the new block, the slave node begins verifying transactions. Since debugging is performed on a single node and only records are kept on the chain, verification of debugging-related transactions in the new block is skipped.

[0256] S1514, all blockchain nodes broadcast and reach consensus on the block;

[0257] S1515: Check whether the consensus is passed. If so, proceed to S1516; if not, end the process.

[0258] S1516, all blockchain nodes append the new block to the block ledger for storage;

[0259] S1517, all blockchain nodes update the latest state data into the state database;

[0260] S1518: The master node determines the target contract to be closed and starts executing the debug close transaction.

[0261] S1519, the master node merges the snapshot of the target contract starting with tx into the state database to store the subsequent normal transaction data;

[0262] S1520, the master node deletes the snapshot of the target contract starting with debug;

[0263] S1521, the master node state database begins to enter data of the target contract that ends the debugging process;

[0264] S1522: Return the result of permission verification failure;

[0265] S1523, returns the result that the signature verification failed.

[0266] In some embodiments, this application also provides an application scenario that applies the above-mentioned smart contract debugging method. Specifically, the following uses an actual application scenario as an example to explain the smart contract debugging of this application in detail, where the actual application scenario can be a scenario of smart contract development and maintenance.

[0267] For smart contract development and maintenance scenarios, during the development phase of a smart contract, developers can use the smart contract debugging method provided in this application to perform on-chain debugging to ensure the correctness of the smart contract logic and optimize performance. After the contract is deployed, if unexpected behavior or vulnerabilities occur, developers can also use the smart contract debugging method provided in this application to perform on-chain debugging to quickly locate and fix the problem without having to withdraw the contract off-chain or suspend network services.

[0268] Traditional off-chain debugging environments often fail to fully replicate the state and data of production environments. This can result in certain issues being impossible to reproduce in test environments, or fixes not performing as expected in production. This inconsistency can extend debugging cycles and increase the risk of deploying smart contracts to production. In traditional approaches, debugging is often isolated from actual on-chain operations. This means developers may not be able to observe the behavior of smart contracts as they interact with live on-chain data and other contracts. As a result, even if a smart contract performs well in a test environment, it may exhibit unexpected behavior or vulnerabilities after deployment to production. Traditional debugging methods often require manually syncing changes to the production environment after debugging is complete. This process can introduce human error, leading to data inconsistencies or deployment errors. Furthermore, manually deploying updated smart contracts to production can cause service interruptions or other runtime issues, increasing operational risk.

[0269] The smart contract debugging method provided in this application provides a method for single-node isolated debugging of smart contracts in a blockchain network. In the scenario of smart contract development and maintenance, by creating two parallel snapshots—one for recording actual on-chain transaction data and the other specifically for recording debugging transaction data—this effectively separates debugging activities from real-time on-chain operations. This mechanism not only protects the data integrity of the main chain but also allows developers to debug in a real on-chain environment, thereby more accurately diagnosing and fixing problems in smart contracts. Furthermore, after debugging is completed, the actual on-chain transaction data is updated to the state database to maintain data consistency and integrity.

[0270] In addition to smart contract development and maintenance, the smart contract debugging method provided in this application can also be applied in the following scenarios: 1. Decentralized Application (DApp) Upgrades and Iterations: For decentralized applications already deployed on a blockchain, when functional upgrades or performance optimizations are required, developers can use the smart contract debugging method provided in this application to perform on-chain debugging and testing of the smart contract to ensure a smooth transition to the new version of the contract without impacting existing users and transactions. 2. Blockchain Platform Troubleshooting and Recovery: When a smart contract on a blockchain platform exhibits abnormal behavior or failures, platform operations and maintenance personnel can use the smart contract debugging method provided in this application to perform on-chain debugging of the problematic contract, analyze the cause of the problem, and verify the remediation measures. This helps reduce system downtime and ensure the stable operation of the blockchain platform. 3. Smart Contract Security Audits: When conducting security audits of smart contracts, security auditors can use the smart contract debugging method provided in this application to simulate various attack scenarios on-chain to verify the security of the contract. Access to complete on-chain data makes the audit process more accurate and helps identify potential security vulnerabilities. 4. Education and Research: In the field of blockchain technology education and research, users can use the smart contract debugging method provided in this application to learn and study the behavior of smart contracts.

[0271] Through these application scenarios, the smart contract debugging method provided in this application can greatly improve the development efficiency, security and reliability of smart contracts, while providing strong support for the further development and popularization of blockchain technology.

[0272] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0273] Based on the same inventive concept, embodiments of the present application also provide a smart contract debugging device for implementing the aforementioned smart contract debugging method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more smart contract debugging device embodiments provided below can be found in the aforementioned limitations of the smart contract debugging method and will not be further elaborated here.

[0274] In one embodiment, Figure 16 As shown, a smart contract debugging device is provided, including: a target contract determination module 1602, a snapshot creation module 1604, a storage module 1606 and an update module 1608, wherein:

[0275] The target contract determination module 1602 is used to determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract.

[0276] The snapshot creation module 1604 is configured to create a first snapshot and a second snapshot associated with the target contract.

[0277] The storage module 1606 is used to store the data generated by the actual operation on the chain related to the target contract in the first snapshot, and store the data generated by the on-chain debugging operation related to the target contract in the second snapshot.

[0278] The update module 1608 is configured to update the state database of the blockchain network based on the data stored in the first snapshot if debugging of the target contract is completed.

[0279] In some embodiments, the target contract determination module 1602 is also used to receive a debugging transaction request; the debugging transaction request carries the contract identifier of the contract to be debugged; the debugging transaction request is uploaded to the chain, and after the upload is successful, the target contract to be debugged in the blockchain network is determined based on the contract identifier.

[0280] In some embodiments, the target contract determination module 1602 is also used to verify the validity and legality of the transaction data in the debugging transaction request; generate a new block based on the transaction data that passes the validity check and the legality check; add the new block that passes the consensus to the blockchain network, and update the status database based on the new block.

[0281] In some embodiments, the target contract determination module 1602 is further used to perform debugging legitimacy verification based on transaction data. If the contract to be debugged is not being debugged, it is determined that the legitimacy verification has passed.

[0282] In some embodiments, the snapshot creation module 1604 is further used to create at least two empty snapshots associated with the target contract; add a first identifier to the created empty snapshot to obtain a first snapshot; add a second identifier to the created empty snapshot to obtain a second snapshot; the second identifier is different from the first identifier.

[0283] In some embodiments, the storage module 1606 is also used to obtain transaction data for the target contract, process the transaction data to obtain a processing result; if the transaction data comes from a real transaction, the data generated by the actual operation on the chain is determined based on the processing result, and the data generated by the actual operation on the chain is stored in the first snapshot; if the transaction data comes from a debugging transaction, the data generated by the debugging operation on the chain is determined based on the processing result, and the data generated by the debugging operation on the chain is stored in the second snapshot.

[0284] In some embodiments, the storage module 1606 includes a processing module; the processing module is used to obtain a first contract process that matches the target contract from the contract transaction process pool if the transaction data comes from a real transaction, process the transaction data through the first contract process, and obtain a processing result; if the transaction data comes from a debugging transaction, obtain a second contract process that matches the target contract from the contract debugging process pool, process the transaction data through the second contract process, and obtain a processing result.

[0285] In some embodiments, the processing module is also used to, in the process of processing transaction data, if there is a query business and the transaction data comes from a real transaction, construct a target search item based on the first identifier of the first snapshot and the target keyword of the query business, and perform a query in the first snapshot based on the target search item to obtain a query result; if there is a query business and the transaction data comes from a debugging transaction, construct a target search item based on the second identifier of the second snapshot and the target keyword of the query business, and perform a query in the second snapshot based on the target search item to obtain a query result.

[0286] In some embodiments, the storage module 1606 is also used to obtain a first keyword corresponding to the data generated by the actual operation on the chain; obtain a search item for the data generated by the actual operation on the chain based on the first keyword and the first identifier of the first snapshot; and associate the obtained search item and the data generated by the actual operation on the chain and store them in the first snapshot.

[0287] In some embodiments, the storage module 1606 is also used to obtain a second keyword corresponding to the data generated by the on-chain debugging operation; obtain a search item for the data generated by the on-chain debugging operation based on the second keyword and the second identifier of the second snapshot; and associate the obtained search item and the data generated by the on-chain debugging operation and store them in the second snapshot.

[0288] In some embodiments, the smart contract debugging device also includes a debugging shutdown module; the debugging shutdown module is used to, during the debugging phase of the target contract, if a debugging shutdown request for the target contract is obtained, perform an on-chain operation for the debugging shutdown request, and close the debugging of the target contract after the on-chain operation is successful.

[0289] Each module in the smart contract debugging device described above can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0290] In one embodiment, a computer device is provided. The computer device may be a server or a terminal. The internal structure diagram thereof may be as follows: Figure 17 As shown. The computer device includes a processor, memory, an input / output (I / O) interface, and a communication interface. The processor, memory, and I / O interface are connected via a system bus, and the communication interface is connected to the system bus via the I / O interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store transaction data. The I / O interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a smart contract debugging method.

[0291] Those skilled in the art will understand that Figure 17The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0292] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0293] In one embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the steps in the above-mentioned method embodiments when executed by a processor.

[0294] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0295] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0296] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0297] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0298] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A smart contract debugging method, characterized in that: The method comprises: Determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract; creating a first snapshot and a second snapshot associated with the target contract; Store the data generated by the actual on-chain operations related to the target contract in the first snapshot, and store the data generated by the on-chain debugging operations related to the target contract in the second snapshot; If debugging of the target contract is completed, the state database of the blockchain network is updated based on the data stored in the first snapshot.

2. The method according to claim 1, characterized in that Determining the target contract to be debugged in the blockchain network includes: Receive a debugging transaction request; the debugging transaction request carries the contract identifier of the contract to be debugged; An on-chain operation is performed for the debugging transaction request, and after the on-chain operation is successfully completed, a target contract to be debugged in the blockchain network is determined based on the contract identifier.

3. The method according to claim 2, characterized in that The on-chain operation for the debugging transaction request includes: Performing validity and legality verification on the transaction data in the debugging transaction request; Generate a new block based on transaction data that has passed the validity check and the legality check; New blocks that pass consensus are added to the blockchain network, and the state database is updated based on the new blocks.

4. The method according to claim 3, characterized in that The process of legitimacy verification includes: The debugging legitimacy verification is performed based on the transaction data. If the contract to be debugged is not being debugged, it is determined that the legitimacy verification has passed.

5. The method according to claim 1, wherein The creating a first snapshot and a second snapshot associated with the target contract includes: Creating at least two empty snapshots associated with the target contract; Adding a first identifier to the created empty snapshot to obtain a first snapshot; A second identifier is added to the created empty snapshot to obtain a second snapshot; the second identifier is different from the first identifier.

6. The method according to claim 1, wherein Storing data generated by actual operations on the chain related to the target contract in the first snapshot, and storing data generated by debugging operations on the chain related to the target contract in the second snapshot, includes: Acquiring transaction data for the target contract, and processing the transaction data to obtain a processing result; If the transaction data originates from a real transaction, determining data generated by actual operations on the chain based on the processing result, and storing the data generated by actual operations on the chain in the first snapshot; If the transaction data originates from a debugging transaction, data generated by an on-chain debugging operation is determined based on the processing result, and the data generated by the on-chain debugging operation is stored in the second snapshot.

7. The method according to claim 6, characterized in that The processing of the transaction data to obtain a processing result includes: If the transaction data originates from a real transaction, obtaining a first contract process that matches the target contract from a contract transaction process pool, processing the transaction data through the first contract process, and obtaining a processing result; If the transaction data comes from a debugging transaction, a second contract process matching the target contract is obtained from a contract debugging process pool, and the transaction data is processed by the second contract process to obtain a processing result.

8. The method according to claim 6, characterized in that The method further comprises: During the processing of the transaction data, if a query business exists and the transaction data is derived from a real transaction, constructing a target search term based on the first identifier of the first snapshot and a target keyword of the query business, and performing a query in the first snapshot based on the target search term to obtain a query result; If there is a query business and the transaction data comes from a debugging transaction, a target search term is constructed based on the second identifier of the second snapshot and the target keyword of the query business, and a query is performed in the second snapshot based on the target search term to obtain a query result.

9. The method according to claim 6, characterized in that Storing the data generated by the actual operation on the chain into the first snapshot includes: Obtaining a first keyword corresponding to data generated by the actual operation on the chain; Obtaining, according to the first keyword and the first identifier of the first snapshot, a search item for data generated by the actual operation on the chain; The obtained search terms and the data generated by the actual operation on the chain are associated and stored in the first snapshot.

10. The method according to claim 6, characterized in that Storing the data generated by the on-chain debugging operation into the second snapshot includes: Obtaining a second keyword corresponding to data generated by the on-chain debugging operation; Obtaining, according to the second keyword and the second identifier of the second snapshot, a search item for the data generated by the on-chain debugging operation; The obtained search item and the data generated by the on-chain debugging operation are associated and stored in the second snapshot.

11. The method according to claim 1, wherein The method further comprises: During the debugging phase of the target contract, if a debugging shutdown request for the target contract is obtained, an on-chain operation is performed for the debugging shutdown request, and debugging of the target contract is closed after the on-chain operation is successful.

12. A smart contract debugging device, characterized in that: The device comprises: A target contract determination module is used to determine the target contract to be debugged in the blockchain network and enter the debugging phase of the target contract; a snapshot creation module, configured to create a first snapshot and a second snapshot associated with the target contract; A storage module, configured to store data generated by on-chain actual operations related to the target contract in the first snapshot, and store data generated by on-chain debugging operations related to the target contract in the second snapshot; An update module is configured to update a status database of the blockchain network based on the data stored in the first snapshot if debugging of the target contract is completed.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 11 are implemented.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Images