Smart contract debugging method and device, equipment and storage medium

Abstract

The invention discloses a smart contract debugging method and device, equipment and a storage medium, and relates to the technical field of computers. The method is executed by a computer device, at least one cloud computing unit is created in the computer device, and the cloud computing unit comprises a service container and an execution container; the method comprises the following steps: a business container receives a contract debugging request sent by a client, wherein the contract debugging request is used for requesting to debug a smart contract in a cloud computing unit; the business container compiles the smart contract to obtain the compiled smart contract; the business container stores the compiled smart contract in a shared cloud disk; and the execution container executes the compiled smart contract to obtain a debugging result of the smart contract. According to the method, the user can remotely debug the smart contract only by submitting the contract debugging request without installing and configuring the environment parameters by himself / herself after completing the compiling of the smart contract, and the operation of debugging the smart contract by the user is simplified.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for debugging smart contracts. Background Technology

[0002] Currently, blockchain technology is widely used in various fields, such as finance, resource sharing, and the Internet of Things. Developing a blockchain is a crucial first step before its application.

[0003] In related technologies, integrated development environments (IDEs) are used for blockchain development. These IDEs provide functions such as writing, compiling, and debugging smart contracts. A smart contract is an automated contract written in code and executed on a blockchain network. Before developing a blockchain application, the blockchain IDE environment needs to be installed and configured on the local host. When debugging the written smart contracts, the local host's computing resources are used to execute and debug them.

[0004] In related technologies, only by correctly installing a blockchain IDE can smart contracts be debugged on the blockchain IDE. However, the process of installing and configuring a blockchain IDE is quite complex. It requires the installation of multiple components and dependent tools, as well as the configuration of corresponding environment parameters based on the relevant parameters of the local host. Therefore, it is easy to cause problems that affect smart contract debugging due to errors in the process. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for debugging smart contracts. The technical solution provided by this application is as follows:

[0006] According to one aspect of the embodiments of this application, a method for debugging a smart contract is provided. The method is executed by a computer device, which creates at least one cloud computing unit. The cloud computing unit includes a business container and an execution container. The business container is used to provide services to clients, and the execution container is used to provide an execution environment for the smart contract. The method includes:

[0007] The business container receives a contract debugging request sent by the client, the contract debugging request being used to request debugging of the smart contract in the cloud computing unit;

[0008] The business container compiles the smart contract to obtain a compiled smart contract, wherein the smart contract includes at least one contract command;

[0009] The business container stores the compiled smart contract in a shared cloud disk, and the data in the shared cloud disk is shared with the at least one cloud computing unit;

[0010] The execution container executes the compiled smart contract and obtains the debugging results of the smart contract.

[0011] According to one aspect of an embodiment of this application, a computer device is provided, wherein at least one cloud computing unit is created in the computer device, the cloud computing unit including a business container and an execution container, the business container being used to provide services to clients, and the execution container being used to provide an execution environment for the smart contract; the computer device includes:

[0012] The request receiving module is used to receive a contract debugging request sent by the client through the business container. The contract debugging request is used to request debugging of the smart contract in the cloud computing unit.

[0013] A contract compilation module is used to compile the smart contract through the business container to obtain a compiled smart contract, wherein the smart contract includes at least one contract command;

[0014] A contract storage module is used to store the compiled smart contract in a shared cloud disk through the business container, wherein the data in the shared cloud disk is shared with the at least one cloud computing unit;

[0015] The contract execution module is used to execute the compiled smart contract through the execution container and obtain the debugging results of the smart contract.

[0016] According to one aspect of an embodiment of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described debugging method for smart contracts.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the above-described debugging method for smart contracts.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described debugging method for smart contracts.

[0019] The technical solutions provided in this application have at least the following beneficial effects:

[0020] By creating at least one cloud computing unit in a computer device, the cloud computing unit includes a business container and an execution container. After receiving a contract debugging request from a client, the business container compiles the smart contract to obtain a compiled smart contract. The business container stores the compiled smart contract in a shared cloud disk. The execution container executes the compiled smart contract to obtain the debugging result of the smart contract. This method deploys the smart contract debugging process in the cloud computing unit and runs the smart contract debugging service on the cloud computing unit. This allows users to remotely debug smart contracts after completing the writing of the smart contract by simply submitting a contract debugging request, without having to install and configure environment parameters themselves. This simplifies the user's smart contract debugging operation.

[0021] In addition, by separating the compilation and execution processes of smart contracts, this method enables risk checks on smart contracts during compilation, reducing the risk of malicious code injection, vulnerability exploitation, and information leakage during execution, thereby improving the security of remote debugging of smart contracts. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the implementation environment of a solution provided in one embodiment of this application;

[0023] Figure 2 This is a schematic diagram of the architecture of a cloud computing unit provided in one embodiment of this application;

[0024] Figure 3 This is a flowchart illustrating the execution of a local host smart contract according to an embodiment of this application;

[0025] Figure 4 This is a flowchart of a smart contract debugging method provided in one embodiment of this application;

[0026] Figure 5 This is a schematic diagram illustrating risk checking based on IDE services according to an embodiment of this application;

[0027] Figure 6 This is a flowchart illustrating a risk check based on IDE services, provided in one embodiment of this application.

[0028] Figure 7 This is a schematic diagram of a risk checking method based on a replacement standard library provided in one embodiment of this application;

[0029] Figure 8 This is a flowchart of a risk checking method based on a replacement standard library provided in one embodiment of this application;

[0030] Figure 9 This is a flowchart of a risk check method based on a global scan of smart contracts provided in one embodiment of this application;

[0031] Figure 10 This is a block diagram of a computer device provided in one embodiment of this application;

[0032] Figure 11 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0035] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring and control. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration and issuance, as well as contract triggering and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring and control module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, monitoring and controlling network conditions, and monitoring and controlling the health status of node devices.

[0036] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0037] Please refer to Figure 1 The diagram illustrates an implementation environment provided in one embodiment of this application. This implementation environment can be implemented as a blockchain integrated development system. The implementation environment may include a terminal device 10 and a server 20.

[0038] Terminal device 10 includes, but is not limited to, mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs (Personal Computers), in-vehicle terminals, smart home appliances, AR (Augmented Reality) devices, VR (Virtual Reality) devices, and other electronic devices. Terminal device 10 can run a client of the target application (such as an IDE application, hereinafter referred to as an IDE client). This target application client is used to provide users with functions such as editing, compiling, running, and debugging smart contracts. Optionally, the target application can be an application that needs to be downloaded and installed, or it can be a webpage or a mini-program; this application does not limit this.

[0039] Server 20 provides services to clients of the target application in terminal device 10. Optionally, server 20 includes at least one of the following computer devices: physical server, physical machine, virtual machine, cloud server, etc., but is not limited to these. The cloud server provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. For example, server 20 can be a standalone computer device, or a server cluster or distributed system composed of multiple computer devices. Optionally, the above services may include, but are not limited to, the following services: background services, debugging services, compilation services, database management services, project management services, smart contract management, etc., which are not limited in this application.

[0040] In some embodiments, at least one cloud computing unit is created in the computer device, the cloud computing unit including a business container and an execution container, the business container being used to provide services to the client 10, and the execution container being used to provide an execution environment for smart contracts.

[0041] A cloud computing unit is a computing resource unit with a certain computing capacity, used to run applications, process data, and perform computing tasks. Optionally, a cloud computing unit can be a virtualized computer system, such as a virtual server instance, a virtual container instance, or other computing resources. At least one cloud computing unit within a computer device allocates and schedules the computing resources of the computer device; each cloud computing unit can be considered an independent computer. At least one container runs within a cloud computing unit. Optionally, a cloud computing unit can be the smallest deployable computing unit (Pod) created and managed in Kubernetes (K8s), consisting of one container or a group of containers. Kubernetes is an open-source system for automatically deploying, scaling, and managing containerized applications.

[0042] A container is a lightweight, portable software packaging method used to encapsulate an application and all its dependencies and configuration files for deployment and operation in different computing environments. A container packages an application, runtime environment, and all dependencies into a single, portable unit called a container image. Optionally, containers can be created, run, and managed by a container engine, such as Docker, containerd, Rocket (RKT), etc., which are not limited in this application. Optionally, a container orchestration tool can be used to manage and schedule multiple container instances, such as Kubernetes, Docker Swarm, Apache Mesos, etc., which are not limited in this application.

[0043] Please refer to Figure 2 This illustration shows a schematic diagram of the architecture of a cloud computing unit provided in one embodiment of this application. For any computer device in server 20, one or more cloud computing units can be deployed, and each cloud computing unit includes a container or a group of containers. Figure 2As shown, any cloud computing unit includes an execution container and a business container. The business container includes an IDE service and a file system provided to the user. Optionally, the IDE service may include compilation services, debugging services, project management services, etc., which are not limited in this application. The execution container includes a contract container, a runtime container, and a file system. The contract container provides the execution environment for smart contracts, while the runtime container manages container objects, such as container images, containers, networks, and shared volumes, and also communicates with the business container. The file systems of the business container and the execution container are mounted on the same shared cloud disk. The runtime container has special host privileges (such as root privileges) on the computer device. Therefore, if smart contracts are allowed to execute system commands arbitrarily, such as network commands like ping, traceroute, and curl, and file operation commands like rm and mount, it could lead to attacks on the cloud hosts or computing resources in server 20 and the leakage of information.

[0044] Terminal device 10 and server 20 can communicate with each other via a network. This network can be a wired network or a wireless network.

[0045] Based on the blockchain integrated development system described above, after writing a smart contract in the IDE client, the user sends a request to server 20 to use IDE services, such as the compilation and debugging services mentioned above. Upon receiving the request from the IDE client, server 20 allocates the request to one or more cloud computing units within its computer devices. Once the cloud computing unit receives the request, its business container can start the corresponding container or service as needed, ultimately returning the processing result to the IDE client.

[0046] In related technologies, users download and install a blockchain IDE on their local host machine. When simulating the execution of smart contracts, the user's host machine is used. Please refer to [reference needed]. Figure 3This document illustrates a flowchart of a local host simulating smart contract execution according to an embodiment of this application. When a user initiates a request to the IDE service to execute a smart contract, the host with the blockchain IDE installed directly accesses the local contract file system as a contract process to find and execute the corresponding smart contract. Alternatively, a container runtime environment can be pre-configured and installed on the host, and the smart contract can be executed as a container. The smart contract is stored in the local contract file system, which the container can directly access or access by mounting the contract file system onto the container. Although creating the host and local files in the local environment by the user ensures the security, independence, and controllability of the local system, creating a local environment for simulating smart contract execution requires configuring local environment parameters, development tools, and dependencies. Therefore, developing smart contracts in a local environment is relatively complex, and because different parameters need to be configured for different local environments, the portability of the developed blockchain project is poor, and errors are prone to occur when actually deploying the smart contract.

[0047] Please refer to Figure 4 The diagram illustrates a flowchart of a smart contract debugging method provided in one embodiment of this application. The execution entity for each step of this method can be... Figure 1 The server 20 shown may be a computer device within the server 20, where the execution entity for each step can be a computer device. The method may include at least one of the following steps (410-440):

[0048] Step 410: The business container receives a contract debugging request sent by the client, which is used to request debugging of the smart contract in the cloud computing unit.

[0049] At least one cloud computing unit is created on the aforementioned computer equipment. This cloud computing unit includes a business container and an execution container. The business container is a container that provides IDE services and can communicate with IDE clients (hereinafter referred to as "clients") and execution containers. For example, the client can obtain IDE services through the IDE interface. Alternatively, the business container and the execution container can communicate through a shared volume. A shared volume is a storage volume that can be mounted and accessed by multiple containers simultaneously. The execution container is used to execute smart contracts.

[0050] A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without a third party, and these transactions are traceable and irreversible. A smart contract can execute the terms of a contract through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to automate transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic funds to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0051] Before deploying a smart contract to the blockchain, users need to write, debug, and deploy the smart contract code.

[0052] On the client side, users write smart contract code based on project requirements and business logic. This smart contract code defines the behavior and rules of the smart contract, including data structures, functions, and events. Optionally, it can be written in different smart contract programming languages, such as Go, Solidity, Vyper, Bamboo, Liquidity, etc., or other smart contract programming languages; this application does not limit this choice. The client refers to… Figure 1 The IDE client running on the terminal device 10 shown.

[0053] Smart contract debugging refers to the process of simulating the execution of a smart contract during its development to discover and fix errors, vulnerabilities, or anomalies. Debugging smart contracts helps users identify and fix potential problems, improving the quality and stability of the smart contract. After debugging, the smart contract is deployed to the blockchain network to ensure its proper functioning. The smart contract debugging process may include, but is not limited to, the following: running tests, viewing logs, power-off settings, variable observation, code coverage analysis, etc., which are not limited in this application.

[0054] In some embodiments, the client sends a contract debugging request to the server through the IDE service interface. This contract debugging request is used to invoke the contract debugging service in the IDE service.

[0055] In some embodiments, the client stores the smart contract to a shared cloud disk. A shared cloud disk refers to storage space shared among multiple nodes in a cluster, used to store shared resources such as data, configuration files, and logs within the cluster. In this embodiment, the shared cloud disk refers to storage space shared among multiple computer devices in server 20. At least one cloud computing unit of any of the multiple computer devices can also share this shared cloud disk.

[0056] It is understandable that smart contracts written by users can be stored in this shared cloud disk, and smart contracts compiled by the business container can also be stored in this shared cloud disk.

[0057] Correspondingly, the server receives the contract debugging request and assigns it to one of the multiple cloud computing units deployed on the server for processing.

[0058] A contract debugging request includes at least one of the following: a smart contract, a smart contract method, parameters of the smart contract method, and user identification information. The smart contract method refers to a function or operation defined in the smart contract that can be called externally. It defines the behavior and functionality of the smart contract and can be invoked externally to perform different operations. The parameters of the smart contract method refer to the input values ​​used to pass information or data provided by the user to the smart contract method. These parameters can include at least one of the following data types: integers, floating-point numbers, characters, strings, addresses, arrays, structures, etc., and may also be other data types, which are not limited in this application. The user identification information is used to distinguish different users and can be a user's username, unique identifier (ID), email address, mobile phone number, etc., or other information used to uniquely identify a user, which is not limited in this application.

[0059] In some embodiments, the smart contract in the above contract debugging request may be the identification information of the smart contract, such as the address and number of the smart contract.

[0060] Step 420: The business container compiles the smart contract to obtain the compiled smart contract, wherein the smart contract includes at least one contract command.

[0061] Before a smart contract can be executed, it needs to be compiled. The IDE service within the business container also provides contract compilation services. The business container integrates a compilation environment for the smart contract programming language, including environment variables related to the smart contract programming language, toolkits for the smart contract programming language, standard library code for the smart contract programming language, and a standard library generated from the standard library code. The compilation environment refers to the set of environments and tools used to convert a smart contract into an executable file or object code.

[0062] Environment variables related to smart contract programming languages ​​refer to those used to configure the compilation process when compiling smart contracts. These variables indicate compiler options, dependency library paths, compilation modes, and other information. The standard library code of a smart contract programming language refers to the concrete implementation code of a series of built-in functions, data structures, and variables. A standard library generated from standard library code refers to the standard library code itself, along with a collection of tools.

[0063] During the process of building the container image of this business container, the standard library code of the smart contract programming language is downloaded and installed into the standard library module in the business container.

[0064] Contract commands are functions or methods that define the behavior and logic of a smart contract.

[0065] A compiled smart contract refers to the executable file corresponding to the smart contract. Optionally, this executable file is a binary file containing the contract bytecode. A binary file is a file encoded in binary form, including machine instructions that a computer can directly execute. The contract bytecode refers to the actual execution code of the smart contract on the blockchain; it contains all the logic and operations of the smart contract.

[0066] Step 430: The business container stores the compiled smart contract in a shared cloud disk, and the data in the shared cloud disk is shared with at least one cloud computing unit.

[0067] In some embodiments, the business container reads the smart contract from a shared cloud disk before compiling the smart contract.

[0068] In some embodiments, the business container sends an execution command to the execution container. The execution command instructs the execution container to execute the compiled smart contract. This execution command may include, but is not limited to, the following information: smart contract identifier, debugging information, debugging configuration, etc., and may also include other information, which this application does not limit. Optionally, the execution command includes the compiled smart contract.

[0069] In some embodiments, the business container sends execution commands to the execution container via sockets in a shared volume. A socket is an inter-process communication mechanism that allows data to be transferred between different processes on the same computer.

[0070] Step 440: Execute the compiled smart contract in the execution container to obtain the debugging results of the smart contract.

[0071] In some embodiments, the execution container reads the compiled smart contract from a shared cloud disk.

[0072] In some embodiments, after receiving an execution command from the business container, the execution container executes the compiled smart contract and obtains the debugging results of the smart contract. The debugging results of the smart contract may include, but are not limited to, at least one of the following: problem location, code coverage, variable observation, event logs, performance analysis, and debugging records, etc., which are not limited in this application.

[0073] Problem localization refers to issues such as logical errors, data anomalies, and inconsistent contract states. Code coverage refers to the frequency with which each function or code block is executed. Variable observation refers to the current values ​​of variables in a smart contract, helping users observe changes in variable state and verify whether the smart contract's behavior matches expectations. Event logs include events triggered during smart contract execution and their parameters, helping users observe the event flow during contract execution and perform related debugging and analysis. Performance analysis refers to the execution performance and resource consumption of the smart contract. Debugging logs refer to the results of all operations during the debugging process, including breakpoint triggering, variable modification, and function calls.

[0074] In some embodiments, the execution container includes a contract container and a background container. The contract container is used to execute smart contracts, and the background container is used to manage container-related resources within the execution container. The container receives execution commands sent by the business container, and the background container starts the contract container. The contract container executes the compiled smart contract and obtains the debugging results of the smart contract.

[0075] Container-related resources refer to containers, container images, networks, and volumes within the execution container, which can communicate with the business container and respond to requests from users or the business container.

[0076] In summary, the technical solution provided in this application creates at least one cloud computing unit in a computer device. This cloud computing unit includes a business container and an execution container. Upon receiving a contract debugging request from a client, the business container compiles the smart contract to obtain a compiled smart contract. The business container stores the compiled smart contract in a shared cloud disk. The execution container executes the compiled smart contract to obtain the debugging result. This method deploys the smart contract debugging process within the cloud computing unit and runs the smart contract debugging service on the cloud computing unit. This allows users to remotely debug smart contracts after completing their writing, simply by submitting a contract debugging request, without needing to install and configure environment parameters themselves. This simplifies the user's smart contract debugging process.

[0077] Based on the above embodiments, the following three solutions are introduced to further improve the security of remote debugging of smart contracts.

[0078] (i) Risk checks based on IDE services

[0079] After executing steps 410-430, when executing the compiled smart contract in step 440, the following risk check is performed. Please refer to [link / reference]. Figure 5 The diagram illustrates a risk check based on IDE services provided in one embodiment of this application.

[0080] In some embodiments, if the execution container executes the first command in the compiled smart contract during the execution of the compiled smart contract, the execution container sends a call request to the business container. The call request is used to call the business container to perform a risk check on the first command. The business container performs a risk check on the first command and obtains the risk check result corresponding to the first command. The business container sends the risk check result corresponding to the first command to the execution container. The execution container executes the compiled smart contract according to the risk check result corresponding to the first command and obtains the debugging result of the smart contract.

[0081] The first command refers to a command that may introduce injection or intrusion risks during the execution of a smart contract. In some embodiments, the first command is a command that calls a specified function. This specified function can be pre-defined by the IDE developer, and this application does not limit its scope. Optionally, the specified function can be a function for calling external commands or system commands, or a function for dynamic address calls, string manipulation, or read / write storage operations. For example, the specified function can be a command function in the Golang language, or other functions, and this application does not limit its scope.

[0082] External commands refer to executable programs or scripts provided by the operating system within a computer system. These programs are not directly provided by the currently running programs or scripts, but rather by the operating system or other external sources. External commands are typically used to perform specific system tasks, manage system resources, or execute system operations.

[0083] System commands are commands executed directly in the operating system's command-line interface or scripts. They are used to perform specific system operations, manage system resources, or invoke system-provided tools. These commands are typically provided by the operating system or system tools and are invoked and executed through command-line or scripting languages. Examples include system commands for file and directory operations such as `mkdir`, `cp`, `mv`, and `rm`, and system commands for network operations such as `ping`, `ifconfig`, and `netstat`.

[0084] Risk checking refers to assessing the security of the first command during execution, such as checking for risks such as code injection, SQL (Structured Query Language) injection, and host intrusion during the execution of the first command.

[0085] The risk result of the first command is used to indicate whether there is a risk in executing the first command. For example, the risk result of the first command can be a single bit. If the bit is "1", the risk result indicates that there is a risk in the first command, and if the bit is "0", the risk result indicates that there is no risk in the first command.

[0086] By using the above methods, when the execution of a contract encounters a potentially risky command, the command is promptly checked to ensure that its execution does not trigger an attack on the server.

[0087] In some embodiments, if the risk check result corresponding to the first command indicates that the first command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract; if the risk check result corresponding to the first command indicates that the first command poses a security risk, the execution container terminates the execution of the compiled smart contract; the execution container obtains the debugging result of the smart contract based on the execution status of the compiled smart contract.

[0088] The execution status of a compiled smart contract refers to the execution information generated during the execution process after the smart contract is executed according to the user's requirements. This includes information such as breakpoint triggering, execution status information, and the gas fees consumed in simulating the execution of the smart contract. Other information is also included, but this application does not limit the scope of such information.

[0089] By using the above method, if there is a risk in the first command, the execution of the smart contract can be terminated, reducing the risk of the server being attacked or intruded upon.

[0090] In some embodiments, the execution container sends a call request to the business container. The call request is used to invoke the risk check interface in the business container to perform a risk check on the first command. The call request includes the input parameters of the first command and service identification information.

[0091] The risk check interface refers to the interface used by the execution container to call the risk check service of the business container. The risk check service is the service within the IDE service used to perform risk checks on the first command.

[0092] Service identification information is an identifier used to identify and distinguish services, including at least one of the following: service name, version number, location, etc. The service name refers to the name of the service, describing the functions or services it provides. The version number indicates the service's version information, used to distinguish differences and compatibility between different versions. The location indicates the location or address of the service, which can be a network address (such as an IP (Internet Protocol) address), hostname, port number, etc.

[0093] In some embodiments, the business container detects the port corresponding to the risk check service; when the business container detects a call request, the business container performs a risk check on the first command.

[0094] For example, when the IDE service starts, it initializes the RPC (Remote Procedure Call) module in the business container, pre-configures the RPC port and IP address of the risk check interface, and detects the port corresponding to the risk check service. At this time, the first command acts as the RPC client, and the IDE service RPC module acts as the RPC server. When the execution container reaches the first command, it obtains the input parameters of the first command and calls the risk check interface.

[0095] RPC is a technology used to enable communication between distributed systems. It allows one computer program to request and call a subroutine or function in another computer program over a network, just as if calling a local function, without needing to know the underlying network communication details.

[0096] By using the above method, the risk check service in the IDE service is invoked to check commands that may have risks, thus separating the execution environment from the environment in which the risk check is performed and reducing the risks associated with executing the command.

[0097] In some embodiments, the business container obtains a blacklist list, which includes at least one risky command; the business container obtains the risk check result corresponding to the first command based on whether the first command exists in the blacklist list.

[0098] A blacklist is a list used to record, manage, and control commands that pose a risk. A risky command is a command that carries a risk.

[0099] In some embodiments, the method name or function name of the first command is matched with the risky commands in the blacklist. If the match is successful, the risk check result for the first command is that the first command has a security risk. If the match fails, the risk check result for the first command is that the first command does not have a security risk.

[0100] By using the above method, commands with security risks in smart contracts are filtered out based on the risky commands in the blacklist, thereby reducing the risks when executing smart contracts.

[0101] In some embodiments, the business container retrieves a blacklist from an external database on the computer device.

[0102] An external database refers to a database deployed outside of computer devices. Optionally, the external database can be accessed by multiple computer devices on server 20. Optionally, the external database can be a database deployed on server 20, or it can be a database deployed on other devices outside of server 20; this application does not limit this.

[0103] Optionally, the blacklist can be maintained by adding, deleting, modifying, and searching for risk commands in an external database.

[0104] In this way, all computer devices on the server can obtain the blacklist, perform risk checks on smart contracts, reduce the amount of computing resources occupied by multiple copies of the blacklist, and lower maintenance costs.

[0105] For example, please refer to Figure 6 The document illustrates a flowchart of a risk check based on an IDE service according to an embodiment of this application. When the execution container executes a first command, it obtains the input parameters from the first command and then calls the risk check interface of the business container. The input parameters of the first command are sent to the business container as interface parameters of the risk check interface. The IDE service in the business container checks these interface parameters. The business container retrieves a blacklist from an external database and checks whether the interface parameter is in the blacklist. If it exists, an error is returned to the client; otherwise, execution continues with the next command after the first command.

[0106] The risk inspection method based on IDE services, as described above, separates the risk inspection process from the smart contract execution process, thereby reducing the risks associated with executing smart contracts.

[0107] (II) Risk Inspection Method Based on Replacement Standard Library

[0108] After executing step 410, when executing the smart contract compiled in step 420, the following risk check is performed. Please refer to... Figure 7 The diagram illustrates a risk checking method based on a replacement standard library provided in one embodiment of this application.

[0109] In some embodiments, the business container uses a modified standard library to compile smart contracts to obtain compiled smart contracts. The modified standard library includes risk check commands, which are commands that include risk check logic. The risk check logic is used to perform risk checks on at least one contract command in the compiled smart contract.

[0110] The risk check command is a command that adds risk check logic to the third command in the original standard library. Replacing the third command in the original standard library with this risk check command yields the modified standard library. Optionally, the third command is the command specified above.

[0111] Risk checking logic refers to a set of rules, algorithms, or methods used to assess, identify, and handle potential security risks. Risk checking logic can be a function or a piece of code within a third command, and this application does not limit its scope. Optionally, risk checking logic may include the aforementioned blacklist.

[0112] After the business container completes the compilation of the smart contract, it continues to execute step 430.

[0113] In some embodiments, during the execution of a compiled smart contract, if the execution container reaches the second command in the compiled smart contract, the execution container performs a risk check logic to obtain the risk check result corresponding to the second command, where the second command is the command that invokes the risk check command. If the risk check result of the risk command corresponding to the second command indicates that the second command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract. If the risk check result of the second command indicates that the second command poses a security risk, the execution container terminates the execution of the compiled smart contract. Based on the execution status of the compiled smart contract, the execution container obtains the debugging result of the smart contract.

[0114] Optionally, the second command is the command specified above.

[0115] This step is similar to step 440, so it will not be repeated here. Please refer to the corresponding section above for a detailed explanation.

[0116] When it is necessary to add or remove risk check commands from the blacklist, the standard library is modified, and the modified standard library is used to replace the standard library in the container image of the business container; the container image of the business container is rebuilt, that is, the modified container image is started; and then the smart contract is recompiled.

[0117] For example, please refer to Figure 8The diagram illustrates a flowchart of a risk check method based on a replacement standard library provided in an embodiment of this application. When the execution container reaches the second command, it obtains the input parameters of the second command, executes the risk check logic, checks whether the input parameters are in the blacklist, returns an error if they exist, and continues to execute the next command of the second command if they do not exist.

[0118] By employing the risk check method described above, which replaces the standard library, and by executing risk check logic, illegal commands are prevented from being executed in the smart contract, thereby protecting the server's security.

[0119] (III) Risk Inspection Method Based on Global Scanning of Smart Contracts

[0120] After executing step 410, when executing the smart contract compiled in step 420, the following method is used to perform risk checks.

[0121] In some embodiments, the business container reads a blacklist from an external database; based on this blacklist, the business container performs a global scan of the smart contract to obtain risk check results. This global scan refers to scanning the smart contract and its dependent packages to determine if any risky commands exist within the smart contract and its dependent packages.

[0122] In some embodiments, if there is no security risk in the smart contract based on the risk check results, steps 420 to 440 are continued.

[0123] For example, please refer to Figure 9 The document illustrates a flowchart of a risk check method based on a global scan of smart contracts provided in an embodiment of this application. After the business container obtains the smart contract, it locks the access permissions to the smart contract and loads the smart contract into the business container's file system. Then, it loads a blacklist from an external database and performs a global scan of the smart contract based on the blacklist. If the smart contract and the packages it depends on contain risky commands, a compilation error is returned; otherwise, the compilation process continues.

[0124] By separating the compilation and execution processes of smart contracts, this method enables risk checks during compilation, reducing the risk of malicious code injection, vulnerability exploitation, and information leakage during execution, thereby improving the security of remote debugging of smart contracts.

[0125] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0126] Please refer to Figure 10This diagram illustrates a block diagram of a computer device according to an embodiment of this application. The computer device has the function of implementing the above-described smart contract debugging method; this function can be implemented in hardware or by hardware executing corresponding software. The computer device creates at least one cloud computing unit, which includes a business container and an execution container. The business container provides services to clients, and the execution container provides the execution environment for the smart contract. Figure 10 As shown, the device 1000 may include a request receiving module 1010, a contract compilation module 1020, a contract storage module 1030, and a contract execution module 1040.

[0127] The request receiving module 1010 is used to receive a contract debugging request sent by the client through the business container. The contract debugging request is used to request debugging of the smart contract in the cloud computing unit.

[0128] The contract compilation module 1020 is used to compile the smart contract through the business container to obtain the compiled smart contract, wherein the smart contract includes at least one contract command.

[0129] The contract storage module 1030 is used to store the compiled smart contract in a shared cloud disk through the business container, and the data in the shared cloud disk is shared with the at least one cloud computing unit.

[0130] The contract execution module 1040 is used to execute the compiled smart contract through the execution container and obtain the debugging results of the smart contract.

[0131] In some embodiments, the contract execution module 1040 includes a request invocation submodule, a risk check submodule, a result feedback submodule, and a contract execution submodule (in... Figure 10 (Not shown in the image).

[0132] The request call submodule is used to send a call request to the business container when the execution container executes the first command in the compiled smart contract. The call request is used to call the business container to perform a risk check on the first command.

[0133] The risk check submodule is used to perform a risk check on the first command through the business container and obtain the risk check result corresponding to the first command.

[0134] The result feedback submodule is used to send the risk check result corresponding to the first command to the execution container through the business container.

[0135] The contract execution submodule is used to execute the compiled smart contract through the execution container according to the risk check result corresponding to the first command, and obtain the debugging result of the smart contract.

[0136] In some embodiments, the request invocation submodule is used to send an invocation request to the business container through the execution container. The invocation request is used to invoke the risk check interface in the business container to perform a risk check on the first command. The invocation request includes the input parameters and service identification information of the first command.

[0137] In some embodiments, the risk inspection submodule is configured to obtain a blacklist list through the business container, the blacklist list including at least one risky command; the business container obtains the risk inspection result corresponding to the first command based on whether the first command exists in the blacklist list.

[0138] In some embodiments, the risk inspection submodule is further configured to obtain the blacklist from an external database of the computer device via the business container.

[0139] In some embodiments, the contract execution submodule is configured to, if the risk check result corresponding to the first command indicates that the first command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract; if the risk check result corresponding to the first command indicates that the first command poses a security risk, the execution container terminates the execution of the compiled smart contract; and the execution container obtains the debugging result of the smart contract based on the execution status of the compiled smart contract.

[0140] In some embodiments, the contract compilation module 1020 is used to compile the smart contract using the modified standard library through the business container to obtain the compiled smart contract. The modified standard library includes risk check commands, which are commands that include risk check logic. The risk check logic is used to perform risk checks on at least one contract command in the compiled smart contract.

[0141] In some embodiments, the contract execution module 1040 is configured to, during the execution of the compiled smart contract by the execution container, if the execution reaches the second command in the compiled smart contract, the execution container executes the risk check logic to obtain the risk check result corresponding to the second command, where the second command is the command that calls the risk check command; if the risk check result of the risk command corresponding to the second command indicates that the second command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract containing the second command; if the risk check result of the second command indicates that the second command poses a security risk, the execution container terminates the execution of the compiled smart contract; and the execution container obtains the debugging result of the smart contract based on the execution status of the compiled smart contract.

[0142] In summary, the technical solution provided in this application creates at least one cloud computing unit in a computer device. This cloud computing unit includes a business container and an execution container. Upon receiving a contract debugging request from a client, the business container compiles the smart contract to obtain a compiled smart contract. The business container stores the compiled smart contract in a shared cloud disk. The execution container executes the compiled smart contract to obtain the debugging result. This method deploys the smart contract debugging process within the cloud computing unit and runs the smart contract debugging service on the cloud computing unit. This allows users to remotely debug smart contracts after completing their writing, simply by submitting a contract debugging request, without needing to install and configure environment parameters themselves. This simplifies the user's smart contract debugging process.

[0143] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0144] Please refer to Figure 11 This diagram illustrates a structural block diagram of a computer device 1100 provided in one embodiment of this application, used to implement the smart contract debugging method provided in the above embodiment. Specifically:

[0145] Typically, computer device 1100 includes a processor 1110 and a memory 1120.

[0146] Processor 1110 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1110 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). Processor 1110 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1110 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1110 may also include an AI processor for handling computational operations related to machine learning.

[0147] The memory 1120 may include one or more computer-readable storage media, which may be non-transitory. The memory 1120 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1120 is used to store a computer program configured to be executed by one or more processors to implement the above-described smart contract debugging method.

[0148] Those skilled in the art will understand that Figure 11 The structure shown does not constitute a limitation on the computer device 1100 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0149] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the above-described debugging method for the smart contract. Optionally, the computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), solid-state drives (SSDs), or optical discs, etc. The random access memory may include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0150] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the above-described debugging method for the smart contract.

[0151] It should be noted that the collection and processing of relevant data (such as smart contracts) in this application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0152] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0153] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for debugging smart contracts, characterized in that, The method is executed by a computer device that creates at least one cloud computing unit, the cloud computing unit including a business container and an execution container. The business container is used to provide services to clients, and the execution container is used to provide the execution environment for the smart contract. The method includes: The business container receives a contract debugging request sent by the client, the contract debugging request being used to request debugging of the smart contract in the cloud computing unit; The business container compiles the smart contract to obtain a compiled smart contract, wherein the smart contract includes at least one contract command; The business container stores the compiled smart contract in a shared cloud disk, and the data in the shared cloud disk is shared with the at least one cloud computing unit; The execution container executes the compiled smart contract and obtains the debugging results of the smart contract.

2. The method according to claim 1, characterized in that, The execution container executes the compiled smart contract and obtains the debugging results of the smart contract, including: If the execution container executes the first command in the compiled smart contract during the execution of the compiled smart contract, the execution container sends a call request to the business container. The call request is used to call the business container to perform a risk check on the first command. The business container performs a risk check on the first command and obtains the risk check result corresponding to the first command. The business container sends the risk check result corresponding to the first command to the execution container; The execution container executes the compiled smart contract based on the risk check result corresponding to the first command, and obtains the debugging result of the smart contract.

3. The method according to claim 2, characterized in that, The execution container sends a call request to the business container, including: The execution container sends a call request to the business container, the call request being used to invoke the risk check interface in the business container to perform a risk check on the first command; The call request includes the input parameters of the first command and service identification information.

4. The method according to claim 2, characterized in that, The business container performs a risk check on the first command and obtains the risk check result corresponding to the first command, including: The business container obtains a blacklist list, which includes at least one risky command. The business container obtains the risk check result corresponding to the first command based on whether the first command exists in the blacklist.

5. The method according to claim 4, characterized in that, The business container obtains the blacklist list, including: The business container retrieves the blacklist from an external database of the computer device.

6. The method according to claim 2, characterized in that, The execution container executes the compiled smart contract based on the risk check result corresponding to the first command, and obtains the debugging result of the smart contract, including: If the risk check result corresponding to the first command indicates that the first command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract containing the first command; If the risk check result corresponding to the first command indicates that the first command has a security risk, the execution container will terminate the execution of the compiled smart contract. The execution container obtains the debugging results of the smart contract based on the execution status of the compiled smart contract.

7. The method according to claim 1, characterized in that, The business container compiles the smart contract to obtain the compiled smart contract, including: The business container uses a modified standard library to compile the smart contract, resulting in the compiled smart contract. The modified standard library includes risk check commands, which are commands that include risk check logic. The risk check logic is used to perform risk checks on at least one contract command in the compiled smart contract.

8. The method according to claim 7, characterized in that, The execution container executes the compiled smart contract and obtains the debugging results of the smart contract, including: If the execution container executes the second command in the compiled smart contract during the execution of the compiled smart contract, the execution container executes the risk check logic to obtain the risk check result corresponding to the second command. The second command is the command that calls the risk check command. If the risk check result of the risk command corresponding to the second command is that the second command does not pose a security risk, the execution container continues to execute the next command contained in the compiled smart contract containing the second command; If the risk check result corresponding to the second command indicates that the second command has a security risk, the execution container will terminate the execution of the compiled smart contract. The execution container obtains the debugging results of the smart contract based on the execution status of the compiled smart contract.

9. A computer device, characterized in that, The computer device contains at least one cloud computing unit, which includes a business container and an execution container. The business container is used to provide services to clients, and the execution container is used to provide the execution environment for the smart contract. The computer device includes: The request receiving module is used to receive a contract debugging request sent by the client through the business container. The contract debugging request is used to request debugging of the smart contract in the cloud computing unit. A contract compilation module is used to compile the smart contract through the business container to obtain a compiled smart contract, wherein the smart contract includes at least one contract command; A contract storage module is used to store the compiled smart contract in a shared cloud disk through the business container, and the data in the shared cloud disk is shared with the at least one cloud computing unit; The contract execution module is used to execute the compiled smart contract through the execution container and obtain the debugging results of the smart contract.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as claimed in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, which a processor reads from and executes to implement the method as described in any one of claims 1 to 8.

Images