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

Abstract

The invention relates to a smart contract debugging method and device, computer equipment, a storage medium and a computer program product, which can be applied to various scenes such as cloud technology, artificial intelligence, smart traffic and auxiliary driving, and the method comprises the following steps: receiving a smart contract debugging request sent by a terminal through a cloud server, the intelligent contract debugging request carries a contract identifier and a contract method; in response to the smart contract debugging request, registering a monitoring event in the cloud server; starting the container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier according to the contract method in the started container to obtain contract execution data; and when the contract execution data is monitored through the monitoring event, returning service response data of the intelligent contract debugging request to the terminal according to the contract execution data. By adopting the method, the operation and maintenance cost in the intelligent contract debugging process can be saved.

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] With the development of computer technology, blockchain technology has emerged. Blockchain is a data structure composed of several blocks connected by hash values. Smart contracts can be deployed in blockchain. Smart contracts are contracts written in code that can be automatically executed on blockchain to achieve various functions, such as transfer, identity verification, and creation of digital identities. To ensure the correct execution of smart contracts, smart contracts need to be debugged.

[0003] In related technologies, users usually use the local environment to debug smart contracts. The local environment is generally a real host. The smart contract can be executed directly in the host as a process. This method relies on the local host environment and has high operation and maintenance costs. Summary of the invention

[0004] 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 save operation and maintenance costs during smart contract debugging in response to the above technical problems.

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

[0006] Receiving a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method;

[0007] In response to the smart contract debugging request, registering a monitoring event in the cloud server;

[0008] Starting a container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0009] When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

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

[0011] A debugging request receiving module, used to receive a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method;

[0012] A monitoring event registration module, configured to register a monitoring event in the cloud server in response to the smart contract debugging request;

[0013] A smart contract execution module, used to start a container in the cloud server, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0014] The business response data returning module is used to return the business response data of the smart contract debugging request to the terminal according to the contract execution data when the contract execution data is monitored through the monitoring event.

[0015] In some embodiments, the smart contract debugging request is received through the business service in the cloud server; a monitoring event registration module is used to respond to the smart contract debugging request, send a monitoring event registration request to the remote call service in the cloud server through the business service, and the monitoring event registration request carries the contract identifier and contract method; receive the monitoring event registration request through the remote call service, and register the monitoring event in the cloud server according to the contract identifier and contract method carried in the monitoring event registration request.

[0016] In some embodiments, the business service runs in a started container; the smart contract execution module is used to call the command line tool of the started container through the business service to send a container startup command; when the container startup command is received through the container management service of the started container, the container nested image is obtained through the container management service, and the container is started in the started container using the container nested image.

[0017] In some embodiments, the business service runs in a first resource object of the cloud server, the started container runs in a second resource object of the cloud server, and the first resource object and the second resource object are different resource objects.

[0018] In some embodiments, the smart contract execution module is also used to call the command line tool of the started container through the business service to generate a container startup command, and carry the IP address of the resource object management service of the second resource object in the container startup command; according to the IP address, the container startup command is sent to the resource object management service of the second resource object, and the container startup command is used to instruct the resource object management service of the second resource object to receive the container startup command and forward the container startup command to the container management service of the started container.

[0019] In some embodiments, the container startup command also carries a preset port number, and the container startup command is used to instruct the resource object management service of the second resource object to forward the container startup command to the preset port corresponding to the preset port number; the smart contract debugging device of the present application also includes: a port monitoring module, which is used to monitor the preset port through the container management service of the started container; when a container startup command sent to the preset port is monitored, the container startup command is received through the container management service of the started container.

[0020] In some embodiments, the monitoring event and the started container run on different resource objects in the cloud server, the smart contract debugging request is received through the business service in the cloud server, and the container is triggered and started by a container startup command sent by the business service, and the container startup command carries the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event; a business response data returning module is used to send the contract execution data to the port monitored by the monitoring event in the resource object where the monitoring event runs according to the IP address and the port number of the resource object where the monitoring event runs, so that the monitoring event monitors the contract execution data; when the contract execution data is monitored through the monitoring event, the contract execution data is sent to the business service; and through the business service, according to the contract execution data, the business response data of the smart contract debugging request is returned to the terminal.

[0021] In some embodiments, the container startup command also carries the contract identifier and the request identifier of the smart contract debugging request, and the container startup command indicates the resource object run by the started container, and carries the contract identifier and the request identifier in the contract execution data; the business response data return module is also used to determine the smart contract debugging request corresponding to the contract execution data through the business service according to the contract identifier and the request identifier carried in the contract execution data; convert the format of the contract execution data through the business service to obtain the business response data of the smart contract debugging request; and return the business response data to the terminal through the business service.

[0022] In some embodiments, the debugging request receiving module is used to forward the smart contract debugging request to the smart contract integrated development service of the cloud server when the external request access agent of the cloud server receives the smart contract debugging request; forward the smart contract debugging request to the business service of the cloud server through the smart contract integrated development service; and receive the smart contract debugging request through the business service of the cloud server.

[0023] In some embodiments, the business service and the started container run on different resource objects in the cloud server; the smart contract debugging device of the present application also includes: a dynamic adjustment module, used to count the number of smart contract debugging requests received by the business service; based on the counted number of smart contract debugging requests, determine a first number of resource objects used to run the business service and a second number of resource objects used to run the started container; based on the first number, adjust the actual number of resource objects used to run the business service; based on the second number, adjust the actual number of resource objects used to run the started container.

[0024] In some embodiments, when multiple smart contract debugging requests are received, the smart contract execution module is also used to determine the parallel contract methods from the contract methods carried by the multiple smart contract debugging requests according to a pre-established contract method registry; divide the contract method groups according to the parallel contract methods, and determine the execution order of each contract method group; according to the execution order, serially execute the smart contracts corresponding to each of the contract methods according to each of the contract method groups; wherein, during the serial execution process, when any contract method group includes multiple contract methods, the smart contracts corresponding to each of the contract methods are executed in parallel according to the included contract methods.

[0025] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0026] Receiving a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method;

[0027] In response to the smart contract debugging request, registering a monitoring event in the cloud server;

[0028] Starting a container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0029] When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0031] Receiving a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method;

[0032] In response to the smart contract debugging request, registering a monitoring event in the cloud server;

[0033] Starting a container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0034] When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0035] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0036] Receiving a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method;

[0037] In response to the smart contract debugging request, registering a monitoring event in the cloud server;

[0038] Starting a container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0039] When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0040] The above-mentioned smart contract debugging method, device, computer equipment, storage medium and computer program product receive the smart contract debugging request sent by the terminal through the cloud server, the smart contract debugging request carries the contract identifier and the contract method, responds to the smart contract debugging request, registers the monitoring event in the cloud server, starts the container in the cloud server, obtains the smart contract identified by the contract identifier through the started container, and executes the smart contract identified by the contract identifier in the started container according to the contract method to obtain the contract execution data. When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data, thereby realizing the debugging of the smart contract in the cloud server, avoiding the user's cumbersome environment installation and resource costs, not only with high debugging efficiency, but also saving the operation and maintenance costs during the smart contract debugging process. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is an application environment diagram of the smart contract debugging method in some embodiments;

[0042] Figure 2 A flowchart of a smart contract debugging method in some embodiments;

[0043] Figure 3 A flowchart of a smart contract debugging method in some other embodiments;

[0044] Figure 4 A schematic diagram of starting a container using a container nested image in some embodiments;

[0045] Figure 5 A timing diagram of a smart contract debugging method in some embodiments;

[0046] Figure 6 A schematic diagram of the deployment relationship between business services and Docker deamon in some embodiments;

[0047] Figure 7 A schematic diagram of the deployment relationship between business services and Docker deamon in some other embodiments;

[0048] Figure 8 A schematic diagram of a process for returning contract execution data in some embodiments;

[0049] Fig. 9 is a schematic flow chart of the dynamic adjustment step in some embodiments;

[0050] Fig.10 A schematic diagram of a process for executing a smart contract in some embodiments;

[0051] Fig.11 It is a flowchart of a smart contract debugging method in some specific embodiments;

[0052] Fig.12 A timing diagram of a smart contract debugging method in some other embodiments;

[0053] Fig.13 It is a structural block diagram of a smart contract debugging device in some embodiments;

[0054] Fig.14 1 is a diagram of the internal structure of a computer device in some embodiments. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0056] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0057] 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 the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, 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 performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. 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 key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. 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 alarm, network status monitoring, node equipment health status monitoring, etc.

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

[0059] The smart contract debugging method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 and the cloud server 104 can communicate through a network, such as a wired or wireless network. The data storage system can store data that the cloud server 104 needs to process. The data storage system can be set separately and can be integrated on the cloud server 104. The terminal 102 can send a smart contract debugging request to the server 104, and the cloud server 104 receives the smart contract debugging request sent by the terminal. The smart contract debugging request carries a contract identifier and a contract method. The cloud server 104 responds to the smart contract debugging request and registers a monitoring event. The cloud server 104 further starts a container, obtains the smart contract identified by the contract identifier through the started container, and executes the smart contract identified by the contract identifier in the started container according to the contract method to obtain the contract execution data. When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal 102 according to the contract execution data.

[0060] The terminals may be, but are not limited to, various desktop computers, laptops, smart phones, tablet computers, IoT devices and portable wearable devices. IoT devices may be intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. Cloud servers may be implemented using independent servers or server clusters consisting of multiple servers.

[0061] The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

[0062] In some embodiments, Figure 2 As shown, a smart contract debugging method is provided, which is applied to Figure 1 Taking the cloud server 104 in the example as an example, the following steps are included:

[0063] Step 204: The cloud server receives a smart contract debugging request sent by the terminal, and the smart contract debugging request carries a contract identifier and a contract method.

[0064] Among them, smart contract is a protocol defined in digital form, which needs to run in a trusted environment, such as blockchain platform. It is transmitted, verified or executed in an information-based manner, read and executed by computers, and has the characteristics of self-service. The decentralization of blockchain and the tamper-proof nature of data determine that smart contracts are more suitable for implementation on blockchain. Smart contract debugging request refers to a request for simulating the call of the smart contract to be debugged in order to debug the smart contract. The smart contract debugging request carries at least a contract identifier and a contract method. The contract identifier is used to uniquely identify a smart contract. Optionally, the contract identifier can be the contract name. Smart contracts include at least one variable and a contract method (function). The contract methods in smart contracts are mainly divided into two types according to their functions, one is read-only and the other is modification. The read-only method will not modify any variables of the contract, but will only query the variables on the contract or do some simple data statistics, etc. This method has no transaction hash after the request, and will directly return the request result, and no miner fee is required. The modification method means that the variable needs to be modified. This type of method needs to generate a transaction hash first and then package it into the transaction queue for execution. This will charge a miner fee. The contract method also has a keyword to configure whether additional payment of main currency is required to call this method. The contract method can also specify a broadcast event, that is, after someone calls this method and it is successfully executed, it will be broadcasted and carry parameters. The contract method carried in the smart contract debugging request can be understood as the contract method identifier. Optionally, the contract method identifier can be the contract method name.

[0065] Specifically, the terminal can send a smart contract debugging request to the cloud service. After receiving the smart contract debugging request, the cloud server can parse and obtain the data carried in the smart contract debugging request. The data carried in the smart contract includes at least a contract identifier and at least one contract method.

[0066] In some specific embodiments, the smart contract debugging request carries a contract method with parameters, that is, the legal method needs to pass in parameters for calling, then the smart contract debugging request can also carry the contract method parameters of the contract method.

[0067] In some specific embodiments, the smart contract debugging request carries a contract method without parameters, that is, the legal method does not need to pass in parameters for calling, so the smart contract debugging request does not need to carry contract method parameters.

[0068] In some specific embodiments, taking into account that the contract method in the smart contract can be debugged multiple times, the smart contract debugging request also carries a request identifier, which is used to identify the smart contract debugging request sent for debugging the smart contract. For example, assuming that the contract method A in the smart contract 1 is debugged three times, the smart contract debugging request sent for the first debugging can carry the number "1" as the request identifier, the smart contract debugging request sent for the second debugging can carry the number "2" as the request identifier, and the smart contract debugging request sent for the third debugging can carry the number "3" as the request identifier.

[0069] In some specific embodiments, the cloud server is a cloud server cluster, and the smart contract debugging method of the present application is implemented through IDE saas, wherein IDE, namely Integrated Development Environment, is an application for providing a program development environment, generally including tools such as code editors, compilers, debuggers, and graphical user interfaces, that is, the integrated development environment integrates code writing functions, analysis functions, compilation functions, debugging functions, and other integrated development software service sets, so all software or software sets (groups) with this feature can be called integrated development environments. SaaS refers to a software delivery model based on cloud computing, where users can use software applications on demand through the Internet. Under the SaaS model, the software provider is responsible for the installation, configuration, maintenance, and data security of the software, and the user only needs to access and use the software through a web browser or mobile application. After Saas, the embodiments of the present application can utilize the mature cluster capabilities of cicd and k8s to debug smart contracts in the cloud server.

[0070] In some specific embodiments, the smart contract debugging of the present application is implemented by a resource object running in a cloud server. The resource object can be a resource deployment unit of a cloud service. For example, the resource object can be a pod. A Pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is a group of (one or more) containers; these containers share storage, network, and declarations of how to run these containers. The contents in a Pod are always colocated and scheduled together, running in a shared context. Pod models an application-specific "logical host" that contains one or more application containers that are relatively tightly coupled together. In a non-cloud environment, applications running on the same physical or virtual machine are similar to cloud applications running on the same logical host. Deployment provides declarative update capabilities for Pods. It is responsible for describing the target state in a Deployment, and the Deployment controller changes the actual state at a controlled rate to make it the desired state. Deployment deploys stateless services, the most commonly used controller. It is generally used to manage and maintain stateless microservices within an enterprise, such as configserver, zuul, and springboot. It can manage multiple copies of Pod to achieve seamless migration, automatic expansion and contraction, automatic disaster recovery, one-click rollback and other functions. Use Deployment to deploy IDE services to achieve statelessness, so that you can take advantage of seamless migration, automatic expansion and contraction, automatic disaster recovery, one-click rollback and other functions.

[0071] In some specific embodiments, the cloud server is a cloud server cluster, and the smart contract debugging request sent by the terminal can be received by the external request access proxy ingress, and ingress forwards the smart contract debugging request to the smart contract integrated development service ide service. A key goal of Service in Kubernetes is to allow users to use unfamiliar service discovery mechanisms without modifying existing applications. Users can run code in Pods without worrying about whether it is code designed for the cloud native world or for containerized old applications. Users can use Service to make a set of Pods available on the network so that clients can interact with them. If users use Deployment to run their applications, Deployment can dynamically create and destroy Pods. Whether it is this moment or the next moment, users do not know how many such Pods are working and whether they are healthy or not; users may not even know how those healthy Pods are named. Kubernetes Pods are created and destroyed to match the expected state of the cluster. Pods are temporary resources (users should not expect a single Pod to be both reliable and durable). Each Pod gets its own IP (Internet Protocol Address) address (Kubernetes expects the network plugin to ensure IP address allocation). For a given Deployment in the cluster, the set of Pods running at one moment may be different from the set of Pods running the application at the next moment.

[0072] Service is a component of Kubernetes. It is an abstraction that helps users expose Pod combinations through the network. Each Service object defines a logical group of endpoints (usually these endpoints are Pods) and a policy for how to access these Pods. Ingress is the entry point for accessing services inside the cluster from outside the Kubernetes cluster. Normally, services and pods can only be accessed through IP addresses in the cluster's internal network. The Ingress configuration provides externally accessible URLs and load balancing. Users access Ingress resources, and Ingress acts as a proxy to forward to services in the cluster.

[0073] Step 206, in response to the smart contract debugging request, register the monitoring event in the cloud server.

[0074] Among them, monitoring events are events used to implement monitoring. Monitoring events can be used to monitor the contract execution data returned after the execution of smart contracts.

[0075] Specifically, the cloud server can respond to the smart contract debugging request, register a monitoring event according to the contract identifier and contract method carried in the smart contract debugging request, and monitor the execution of the smart contract through the monitoring event. Since the execution of the smart contract can be monitored through the monitoring event, the cloud server can process the smart contract debugging request asynchronously. Asynchronous processing of smart contracts can provide a basis for stateless services and improve the debugging efficiency of smart contracts.

[0076] In some specific embodiments, monitoring events can be registered in the cloud server through the RPC (Remote Procedure Call Protocol) service. The RPC protocol assumes the existence of certain transmission protocols, such as TCP or UDP, to carry information data between communication programs. In the OSI network communication model, RPC spans the transport layer and the application layer. RPC makes it easier to develop applications including network distributed multi-programs. RPC works in C / S mode. In an embodiment of the present application, the cloud server can call the RPC client to send a monitoring event registration request to the RPC service. The registration request carries at least a contract identifier and a contract method. After receiving the monitoring event registration request, the RPC service registers the monitoring event.

[0077] Step 208, start the container in the cloud server, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain the contract execution data.

[0078] Among them, contract execution data is the data generated after the execution of the smart contract is completed, which may include contract execution results, world status, contract logs, events and other data. The contract execution results are used to include any one of successful contract execution, failed contract execution or contract execution error.

[0079] Specifically, after the source code of the smart contract to be debugged is compiled, the compiled bytecode can be stored in the database of the cloud server. After successfully registering the monitoring event, the cloud server can start the container. The bytecode of the smart contract identified by the contract identifier carried in the smart contract debugging request can be obtained from the database through the started container. Then, in the started container, the contract method carried in the smart contract debugging request can be called according to the bytecode of the smart contract. After the contract method is run, the contract execution data can be obtained.

[0080] Step 210, when the contract execution data is detected through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0081] Specifically, the contract execution data obtained after the execution of the smart contract can be returned to the monitoring event. After the monitoring event detects the returned contract execution data, the cloud server can convert the format of the contract execution data to obtain business response data, and then return the business response data to the terminal.

[0082] In the above-mentioned smart contract debugging method, a smart contract debugging request sent by a terminal is received through a cloud server. The smart contract debugging request carries a contract identifier and a contract method. In response to the smart contract debugging request, a monitoring event is registered in the cloud server, and a container is started in the cloud server. The smart contract identified by the contract identifier is obtained through the started container, and in the started container, the smart contract identified by the contract identifier is executed according to the contract method to obtain the contract execution data. When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data, thereby realizing the debugging of smart contracts in the cloud server, avoiding the user's cumbersome environment installation and resource costs, not only with high debugging efficiency, but also saving operation and maintenance costs during the smart contract debugging process.

[0083] In some embodiments, a smart contract debugging request is received through a business service in a cloud server; in response to the smart contract debugging request, a monitoring event is registered in the cloud server, including: in response to the smart contract debugging request, a monitoring event registration request is sent to a remote call service in the cloud server through the business service, the monitoring event registration request carries a contract identifier and a contract method; the monitoring event registration request is received through the remote call service, and the monitoring event is registered in the cloud server according to the contract identifier and contract method carried in the monitoring event registration request.

[0084] In this embodiment, the cloud server provides an API backend service to the outside world (i.e., front-end users) through business services, accepts front-end API calls and returns corresponding responses. In addition, the cloud server can respond to the smart contract debugging request and send a monitoring event registration request to the remote call service in the cloud server through the business service. The monitoring event registration request carries the data parsed from the smart contract debugging request. The data parsed from the smart contract debugging request includes at least the contract identifier and the contract method. After receiving the monitoring event registration request, the remote call service parses the monitoring event registration request and can obtain the contract identifier and the contract method. Then, the remote call service registers the monitoring event in the cloud server according to the contract identifier and the contract method. The monitoring event can monitor the contract execution data after the smart contract identified by the contract identifier calls the contract method.

[0085] In some embodiments, when the smart contract debugging request carries a request identifier of the smart contract debugging request, the remote call service registers according to the contract identifier, contract method and the unique code of the request when registering the monitoring event.

[0086] In this embodiment, a monitoring event registration request is sent to a remote call service in the cloud server through a business service. The monitoring event registration request carries a contract identifier and a contract method, so that after receiving the monitoring event registration request, the remote call service registers the monitoring event in the cloud server according to the contract identifier and the contract method carried in the monitoring event registration request. By registering the monitoring event through the remote call service, the debugging of the smart contract can be executed asynchronously, and the business service does not need to wait for the contract debugging result and continues to receive calls from the front end, thereby improving the debugging efficiency.

[0087] In some embodiments, Figure 3 , provides a smart contract debugging method, which can be applied to Figure 1 Taking the cloud server 104 in the example as an example, the following steps are included:

[0088] Step 302: The business service in the cloud server receives a smart contract debugging request sent by the terminal, and the smart contract debugging request carries a contract identifier and a contract method.

[0089] In some specific embodiments, the smart contract debugging request carries a contract method with parameters, that is, the legal method needs to pass in parameters for calling, then the smart contract debugging request can also carry the contract method parameters of the contract method.

[0090] In some specific embodiments, the smart contract debugging request carries a contract method without parameters, that is, the legal method does not need to pass in parameters for calling, so the smart contract debugging request does not need to carry contract method parameters.

[0091] In some specific embodiments, considering that the contract method in the smart contract can be debugged multiple times, the smart contract debugging request also carries a request identifier, which is used to identify the smart contract debugging request sent for debugging the smart contract.

[0092] Step 304, in response to the smart contract debugging request, sends a monitoring event registration request to the remote call service in the cloud server through the business service, and the monitoring event registration request carries the contract identifier and contract method.

[0093] Step 306: Receive a monitoring event registration request through a remote call service, and register the monitoring event in the cloud server according to the contract identifier and contract method carried in the monitoring event registration request.

[0094] Step 308: Call the command line tool in the running and started container through the business service to send a container start command.

[0095] Here, the started container refers to the docker container. The docker container is run through the following steps: first, obtain the dockerfile, which is the source code. You can specify which programs are required and what configurations they depend on in the dockerfile. Then, use the docker build command to "compile" the dockerfile. The generated executable program is the image. Then, you can use the docker run command to run the image. After the image is running, it becomes a docker container.

[0096] Step 310: When a container start command is received through the container management service of the started container, the container nested image is obtained through the container management service, and the container is started in the started container using the container nested image.

[0097] Docker uses the CS architecture, that is, the client-server model. The docker client is responsible for processing various commands entered by the user, such as docker build naming and docker run naming. The server, that is, the container management service docker demon, is the real work. The container nested image is the dind (docker in docker) image.

[0098] In this embodiment, when the cloud server receives a container start command through the container management service docker demon of the started container, it obtains the container nested image, namely the dind image, through the container management service docker demon, and uses the dind image to start the container in the started container.

[0099] For example, Figure 4 As shown in the figure, you can directly run a container management service Docker Daemon in the running container Docker Container, and then use the command line tool Docker CLI in the Container to operate the container. In this way, the Docker Daemon in the container is completely independent of the outside world and has good isolation characteristics. In order to run deckerdeamon, the Dind image uses the privileged mode and sets privileged = true.

[0100] Step 312, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain the contract execution data.

[0101] Specifically, after the source code of the smart contract to be debugged is compiled, the compiled bytecode can be stored in the database of the cloud server. After successfully registering the monitoring event, the cloud server can start the container and obtain the bytecode of the smart contract identified by the contract identifier carried in the smart contract debugging request from the database through the started container. Then, in the started container, the contract method carried in the smart contract debugging request can be called through the bytecode of the smart contract. After the contract method is run, the contract execution data can be obtained.

[0102] Step 314, when the contract execution data is detected through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0103] Specifically, the contract execution data obtained after the execution of the smart contract can be returned to the monitoring event. After the monitoring event detects the returned contract execution data, the cloud server can convert the format of the contract execution data to obtain business response data, and then return the business response data to the terminal.

[0104] In the above embodiment, through the business service, the command line tool of the started container is called to send a container start command. When the container start command is received through the container management service of the started container, the container nested image is obtained through the container management service, and the container is started in the started container using the container nested image. The contract debugging environment can be well isolated, thereby improving the security of the contract debugging process.

[0105] In some embodiments, a smart contract debugging method is provided, such as Figure 5 As shown, this is a timing diagram of the smart contract debugging method, refer to Figure 5 , specifically including the following steps:

[0106] 1. The user sends a simulated contract call through the terminal.

[0107] Specifically, the user can initiate a smart contract debugging request at the terminal and send the smart contract debugging request to the cloud server through the terminal. The smart contract debugging request carries the contract name, contract method, contract method parameters and request identifier.

[0108] 2. The business service registers this call with the RPC service, and RPC starts monitoring events.

[0109] The cloud server receives the smart contract debugging request through the business service, parses the smart contract debugging request, obtains the contract name, contract method, request identifier and other data carried therein, and then generates a monitoring event registration request based on the parsed data, and sends the monitoring event registration request to the RPC service. After receiving the monitoring event registration request, the RPC service registers and starts monitoring the monitoring event.

[0110] Monitoring events are used to monitor the contract execution data returned by smart contracts and return the contract execution data to business services. Because contract simulation calls are asynchronous requests, it is necessary to record the contract simulation call information, namely the contract name, contract method, and request identifier, so that the contract results can be correctly returned to the business service.

[0111] 3. The business service sends the docker run command to the docker deamon.

[0112] The business service can call the docker CLI corresponding to the started container to send the docker run command to the docker deamon of the container, and carry the parameters of this call including the contract name, contract method, contract method parameters and request identifier.

[0113] 4. Docker deamon starts the doceker-go container.

[0114] Specifically, after receiving the docker run command, docker deamon obtains the dind image, and after running the dind image, the doceker-go container can be started.

[0115] 5. Run the contract method in the doceker-go container.

[0116] Specifically, the doceker-go container obtains the bytecode of the smart contract identified by the contract identifier, calls the contract method according to the bytecode, and passes in the contract method parameters. After the call is completed, the contract execution data is obtained.

[0117] 6. Return contract execution data to the RPC service.

[0118] After the smart contract call is completed, the contract execution data is returned to the RPC service.

[0119] 7. The RPC service notifies the business service of the contract execution data.

[0120] The RPC service compares the contract name and request identifier carried in the contract execution data with the contract name and request identifier corresponding to the registered monitoring event. If the comparison is consistent, it means that the contract execution data is successfully monitored, and the RPC service can return the contract execution data to the business service.

[0121] 8. The business service returns business response data to the user terminal.

[0122] Specifically, the business service receives the contract execution data, converts the contract execution data into business response data, and then returns the business response data to the user terminal.

[0123] In the above embodiment, since the monitoring event can be registered through the RPC service, when the monitoring event detects the contract execution data, the contract execution data can be returned to the terminal, so that the cloud server can provide a stateless service to realize the debugging of the smart contract.

[0124] Among them, stateless services do not store persistent data locally. The response results of multiple service instances to the same user request are exactly the same. There is no dependency between these multiple service instances. For example, in a web application, dynamically starting and stopping the pod of a stateless service in the k8s controller will not affect other pods. Stateful services need to store persistent data locally, typically distributed database applications, and there are dependent topological relationships between distributed node instances, such as master-slave relationships. If K8S stops any instance pod in a distributed cluster, it may cause data loss or cluster crash.

[0125] In some embodiments, Figure 6 As shown in the figure, business services, RPC services, docker deamon, and docker-go can be deployed together, that is, business services, RPC services, docker deamon, and docker-go all run in the ide pod.

[0126] In other embodiments, the business service runs in a first resource object of the cloud server, and the container started in the started container runs in a second resource object of the cloud server, and the first resource object and the second resource object are different resource objects.

[0127] refer to Figure 7 In this embodiment, the Dind container is an independent third-party service at the back end of the business service. In this way, the business service can be deployed statelessly and scaled independently. The Dind pod can also scale independently. Since it is foreseeable that the same user request, the dind pod consumes much more resources than the business service resources. Assuming the resource ratio is 1:5, 5 dind resources are required to serve five users. If deployed together (unilateral mode), 5 business services + 5 Dind resources are required, but after separate and independent deployment, only 1 business service + 5 Dind resources are required.

[0128] In some embodiments, calling a command line tool of a started container through a business service to send a container startup command includes: calling a command line tool of a started container through a business service to generate a container startup command, and carrying an IP address of a resource object management service of a second resource object in the container startup command; sending the container startup command to the resource object management service of the second resource object according to the IP address, the container startup command being used to instruct the resource object management service of the second resource object to receive the container startup command and forward the container startup command.

[0129] The resource object management service, namely dind service, is used to expose dind Pod in the cloud server cluster. The resource object management service defines the endpoint of dind Pod and the policy for accessing dind Pod, and can forward requests to dindPod.

[0130] Specifically, in this embodiment, the business service and Dind resources are deployed separately, that is, the business service runs in the first resource object ide pod of the cloud server, and the container started in the started container runs in the second resource object dind Pod of the cloud server. The first resource object and the second resource object are different resource objects. In order to correctly access the dind Pod, when the business in the ide pod calls the command line tool docker CLi to generate a container startup command, the IP address of the resource object management service of the second resource object, namely, dind service, can be carried in the container startup command, and then the dind service can be successfully accessed. The container startup command is sent to the dind service. The dind service receives the container startup command and forwards the container startup command to the docker deamon in the dind pod.

[0131] In the above embodiment, since the IP address of the resource object management service of the second resource object can be carried in the container startup command, the container startup command can be sent to the resource object management service of the second resource object according to the IP address, so that the resource object management service forwards the container startup command to the container management service, thereby realizing remote access of the business service to the container management service.

[0132] In some embodiments, the container startup command also carries a preset port number, and the container startup command is used to instruct the resource object management service of the second resource object to forward the container startup command to the preset port corresponding to the preset port number; the method also includes: monitoring the preset port through the container management service of the started container; when the container startup command sent to the preset port is monitored, receiving the container startup command through the container management service of the started container.

[0133] By default, docker deamon communicates with the client through the local docker.sock file. If you need to make a remote call, you can configure docker deamon to monitor the local tcp port. In the docker configuration file, add -H tcp: / / 0.0.0.0:2375 to the DOCKER_OPTS item. When Docker cli accesses docker deamon, add the -H IP (dindservice domain name) + monitoring port (such as: 2375) command parameters to remotely access docker deamon and start the contract debugging command.

[0134] Specifically, in this embodiment, the business service and Dind resources are deployed separately, that is, the business service runs in the first resource object ide pod of the cloud server, and the container started in the started container runs in the second resource object dind Pod of the cloud server. The first resource object and the second resource object are different resource objects. In order to correctly access the dind Pod, the business service resources in the ide pod can carry the IP address of the resource object management service of the second resource object, namely the dind service, and the port number monitored by the docker deamon in the container startup command when calling the command line tool docker CLi to generate a container startup command, and then the container startup command can be sent to the dind service. After receiving the container startup command, the dindservice forwards the container startup command to the port monitored by the docker deamon in the dind pod, so that the business service can remotely access the docker deamon through the dind service, thereby realizing stateless communication between the business service and the docker deamon.

[0135] In some embodiments, the monitoring event and the started container run on different resource objects in the cloud server, the smart contract debugging request is received through the business service in the cloud server, and the container is triggered and started by the container start command sent by the business service, and the container start command carries the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event; when the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data, including: according to the IP address and port number of the resource object where the monitoring event runs, the contract execution data is sent to the port monitored by the monitoring event in the resource object where the monitoring event runs, so that the monitoring event monitors the contract execution data; when the contract execution data is monitored through the monitoring event, the contract execution data is sent to the business service, and the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

[0136] Since the normal service direct call uses the contract execution result to return the domain name of the business service service to be accessed, but the service defaults to calling the subsequent pods in a round-robin manner, there is no guarantee that the returned result is the pod that called the debugging command, resulting in the failure of the returned result processing. Therefore, when executing contract debugging, the RPC service callback address requires the idePod's IP and the port monitored by the monitoring event, rather than the domain name of the business service service.

[0137] Specifically, in this embodiment, in addition to carrying the contract name, contract method, contract parameters and request identifier, the container startup command may also carry the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event. Therefore, after the contract execution is completed, the contract execution data can be sent to the port monitored by the monitoring event in the resource object where the monitoring event runs according to the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event, so that the monitoring event can monitor the contract execution data. When the monitoring event monitors the contract execution data, the contract execution data can be sent to the business service, and the business service returns the business response data of the smart contract debugging request to the terminal according to the contract execution data.

[0138] For example, see Figure 8When the business service in the ide pod initiates remote access to the dind service, it can carry the IP address of the ide pod and the port number of the port monitored by the monitoring event in the docker run command. After dindservice forwards the docker run command to the dind pod, the dind pod can obtain the IP address of the ide pod that initiates the access and the port number of the port monitored by the monitoring event. Then, the dind pod can return the contract execution data according to the IP address of the ide pod and the port number of the port monitored by the monitoring event.

[0139] In the above embodiment, by carrying the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event in the container startup command, the contract execution data can be accurately returned to the monitoring event, so that the monitoring event can return the contract execution data to the business service in a stateless manner.

[0140] In some embodiments, the container startup command also carries a contract identifier and a request identifier of a smart contract debugging request. The container startup command indicates the resource object run by the started container, and carries the contract identifier and the request identifier in the contract execution data; through the business service, according to the contract execution data, returns the business response data of the smart contract debugging request to the terminal, including: through the business service, according to the contract identifier and the request identifier carried in the contract execution data, determining the smart contract debugging request corresponding to the contract execution data; converting the format of the contract execution data through the business service to obtain the business response data of the smart contract debugging request; and returning the business response data to the terminal through the business service.

[0141] Specifically, the monitoring parameters corresponding to the monitoring events registered in the cloud server include the contract identifier and the request identifier. The container startup command also carries the contract identifier and the request identifier of the smart contract debugging request. After the smart contract is executed, the container running the smart contract can carry the contract identifier and the request identifier of the smart contract debugging request in the contract execution data. When the monitoring event monitors the contract execution data, the contract identifier and the request identifier carried therein can be compared with the monitoring parameters corresponding to the monitoring event. When the comparison is consistent, the contract execution data can be sent to the business service. The business service determines the smart contract debugging request corresponding to the contract execution data based on the contract identifier and the request identifier carried in the contract execution data. According to the smart contract debugging request, the terminal that sends the smart contract debugging request can be determined. The business service further converts the format of the contract execution data, obtains the business response data of the smart contract debugging request, and then returns the business response data to the terminal that sends the smart contract debugging request.

[0142] In the above embodiment, since the contract identifier and the request identifier are carried in the contract execution data, the business service can accurately determine the smart contract debugging request corresponding to the contract execution data, so that the business response data can be accurately returned to the terminal to avoid errors in the return of business response data.

[0143] In some embodiments, a smart contract debugging request sent by a terminal is received by a cloud server, including: when an external request access agent of the cloud server receives a smart contract debugging request, forwarding the smart contract debugging request to the smart contract integrated development service of the cloud server; forwarding the smart contract debugging request to the business service of the cloud server through the smart contract integrated development service; receiving the smart contract debugging request through the business service of the cloud server.

[0144] Among them, the external request access proxy of the cloud server can be Ingress. Ingress is the entrance to access the internal services of the cluster from outside the Kubernetes cluster. Normally, services and pods can only be accessed through IP addresses in the internal network of the cluster. The Ingress configuration provides externally accessible URLs and load balancing. Users access Ingress resources, and Ingress acts as a proxy to forward to the services in the cluster. The smart contract integrated development service is the ide service. The Service object defines the endpoints of a logical group (these endpoints are the ide Pods) and the strategy for how to access the ide Pods.

[0145] Specifically, when a user sends a smart contract debugging request to the cloud server through a terminal, the smart contract debugging request is first received by the cloud server's external request access proxy Ingress, which can further forward the smart contract debugging request to the cloud server's smart contract integrated development service ideservice, which can then forward the smart contract debugging request to the idepod in the cloud server, and the business service running in the ide pod can receive the smart contract debugging request.

[0146] In the above embodiment, the external request access agent of the cloud server receives the smart contract debugging request, and forwards the smart contract debugging request to the smart contract integrated development service of the cloud server. The smart contract integrated development service forwards the smart contract debugging request to the business service of the cloud server. The business service receives the smart contract debugging request, so that users can smoothly access the business services in the cloud server, thereby improving the debugging efficiency of the smart contract.

[0147] In some embodiments, the business service and the started container run on different resource objects in the cloud server, see Fig. 9, the smart contract debugging method of the present application also includes a dynamic adjustment step, including:

[0148] Step 902: Count the number of smart contract debugging requests received by the business service.

[0149] Step 904: Determine a first number of resource objects for running the business service and a second number of resource objects for running the started container based on the number of smart contract debugging requests.

[0150] Specifically, the cloud server can count the number of smart contract debugging requests received by the business service when the smart contract debugging requests are concurrent, and determine the first number of resource objects for running the business service based on the business service resources required for one smart contract debugging request. Assuming that 10 smart contract debugging requests need to consume one business service resource, and one business service is run in an ide pod, if the number of smart contract debugging requests obtained by counting is N, then the first number of ide pods is N / 10.

[0151] The cloud server also determines the second number of resource objects used to run the started container based on the dind resources required for a smart contract debugging request. Assuming that two smart contract debugging requests need to consume one dind resource, if the number of smart contract debugging requests obtained by statistics is N, the second number of dind pods is N / 2.

[0152] Step 906: Adjust the actual number of resource objects used to run the business service according to the first number.

[0153] Specifically, when the first number is greater than the actual number of resource objects running the business service, the actual number of resource objects running the business service is reduced, and when the first number is less than the actual number of resource objects running the business service, the actual number of resource objects running the business service is increased.

[0154] Step 908: Adjust the actual number of resource objects used to run the started container according to the second number.

[0155] Specifically, when the second number is greater than the actual number of resource objects used to run the started container, the actual number of resource objects used to run the started container is reduced; and when the second number is less than the actual number of resource objects used to run the started container, the actual number of resource objects used to run the started container is increased.

[0156] In the above embodiment, the actual number of ide pods and dind pods can be determined by counting the concurrent number of smart contract debugging requests and according to the statistically obtained concurrent number, thereby achieving dynamic expansion and contraction and improving the service capability in large concurrent scenarios.

[0157] In some embodiments, the smart contract debugging request carries multiple contract methods, see Fig.10 , execute the smart contract identified by the contract identifier according to the contract method, and obtain the contract execution data, including:

[0158] Step 1002, according to a pre-established contract method registry, determine a parallelizable contract method from the contract methods carried by multiple smart contract debugging requests.

[0159] Step 1004, divide the contract method groups according to the parallelizable contract methods, and determine the execution order of each contract method group.

[0160] Among them, parallel means that they can be executed simultaneously. Parallel contract methods are contract methods that do not have conflicts. Parallel contract methods can be executed simultaneously with other parallel contract methods.

[0161] Specifically, the pre-established contract method registry stores the parallelizable contract methods corresponding to each contract method. Therefore, by querying the pre-established contract method registry, the parallelizable contract methods can be determined from multiple contract methods, and the parallelizable contract methods can be divided into a contract method group, and the non-parallelizable contract methods can be divided into a separate contract method group. For example, assuming that 4 smart contract debugging requests are received, carrying 4 contract methods, namely contract method 1, contract method 2, contract method 3 and contract method 4, of which contract method 1 and contract method 4 are parallelizable contract methods, then contract method 1 and contract method 4 are divided into a contract method group, and contract method 2 is divided into a separate contract method group, and contract method 3 is divided into a separate contract method group, thereby obtaining 3 contract method groups.

[0162] Further, the cloud server may determine the execution order of each contract method group. Optionally, the execution order of each contract method group may be determined according to the receiving time of each smart contract debugging request.

[0163] Step 1006, in accordance with the execution order, serially execute the smart contracts corresponding to each contract method according to each contract method group; wherein, during the serial execution process, when any contract method group includes multiple contract methods, the smart contracts corresponding to each contract method are executed in parallel according to the included contract methods.

[0164] Among them, the smart contract corresponding to the contract method refers to the smart contract identified by the contract identifier carried in the smart contract debugging request carrying the contract method.

[0165] Specifically, the cloud server can execute smart contracts serially according to the execution order and each contract method group. During the serial execution process, when the contract method group includes only one contract method, a single thread is started to call the contract method according to the bytecode of the smart contract to execute the smart contract corresponding to the contract method. When the contract method group includes only one contract method, multiple threads are started to call these contract methods in parallel according to the bytecodes of the smart contracts corresponding to these contract methods to execute these smart contracts in parallel.

[0166] In the above embodiment, by determining the contract methods that can be executed in parallel, in the process of serially executing each contract method group, when any contract method group includes multiple contract methods, the smart contracts corresponding to each contract method are executed in parallel according to the included contract methods, thereby improving the execution efficiency of the smart contract and thus improving the contract debugging efficiency.

[0167] In a specific embodiment, Fig.11 , provides a smart contract debugging method, which can be applied to Figure 1 Taking the cloud server 104 in the example as an example, the following steps are included:

[0168] Step 1102, when the external request access agent of the cloud server receives the smart contract debugging request, the smart contract debugging request is forwarded to the smart contract integrated development service of the cloud server.

[0169] Step 1104, forwarding the smart contract debugging request to the business service of the cloud server through the smart contract integrated development service.

[0170] Among them, the external request access proxy can be ingress, and the smart contract integrated development service can be ideservice. Service is a component of Kubernetes. It is an abstraction that helps users expose Pod combinations through the network. Each Service object defines a logical group of endpoints (usually these endpoints are Pods) and a policy for how to access these Pods. Ingress is the entry point for accessing services inside the cluster from outside the Kubernetes cluster. Normally, services and pods can only be accessed through IP addresses in the cluster's internal network. The Ingress configuration provides externally accessible URLs and load balancing. Users access Ingress resources, and Ingress acts as a proxy to forward to services in the cluster.

[0171] Step 1106: Receive the smart contract debugging request sent by the terminal through the business service running in the first resource object of the cloud server. The smart contract debugging request carries the contract identifier and the contract method.

[0172] Step 1108, in response to the smart contract debugging request, a monitoring event registration request is sent to the remote call service in the cloud server through the business service, and the monitoring event registration request carries the contract identifier and contract method.

[0173] In some specific embodiments, the smart contract debugging request carries a contract method with parameters, that is, the legal method needs to pass in parameters for calling, then the smart contract debugging request can also carry the contract method parameters of the contract method.

[0174] In some specific embodiments, the smart contract debugging request carries a contract method without parameters, that is, the legal method does not need to pass in parameters for calling, so the smart contract debugging request does not need to carry contract method parameters.

[0175] In some specific embodiments, considering that the contract method in the smart contract can be debugged multiple times, the smart contract debugging request also carries a request identifier.

[0176] Step 1110: Receive a monitoring event registration request through a remote call service, and register the monitoring event in the first resource object according to the contract identifier and contract method carried in the monitoring event registration request.

[0177] Step 1112: Call the command line tool of the started container through the business service to generate a container startup command.

[0178] Among them, the container startup command carries the IP address of the resource object management service of the second resource object, the preset port number, the IP address of the resource object where the monitoring event runs, the port number of the port monitored by the monitoring event, the contract identifier, and the request identifier of the smart contract debugging request.

[0179] The preset port number is the port number of the preset port, which is the local TCP port monitored by the container management service in the second resource object, and can be pre-configured in the configuration file of the started container.

[0180] Step 1114: Send the container startup command to the resource object management service of the second resource object according to the IP address carried in the container startup command.

[0181] The container startup command is used to instruct the resource object management service in the second resource object to forward the container startup command to a preset port corresponding to the preset port number.

[0182] Step 1116: When the container management service of the started container monitors the container start command sent to the preset port, the container management service of the started container receives the container start command.

[0183] Specifically, the preset port is monitored by the container management service of the started container, and when a container start command sent to the preset port is monitored, the container start command is received by the container management service of the started container.

[0184] Step 1118: Obtain the container nested image through the container management service, and use the container nested image to start the container in the started container.

[0185] Step 1120, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data.

[0186] Step 1122, according to the IP address and port number of the resource object where the monitoring event runs, the contract execution data is sent to the port monitored by the monitoring event in the resource object where the monitoring event runs, so that the monitoring event monitors the contract execution data.

[0187] Step 1124, when contract execution data is detected through monitoring events, the contract execution data is sent to the business service, and the contract identifier and request identifier are carried in the contract execution data.

[0188] Step 1126, through business services, determine the smart contract debugging request corresponding to the contract execution data according to the contract identifier and request identifier carried in the contract execution data.

[0189] Step 1128, convert the format of the contract execution data through the business service, obtain the business response data of the smart contract debugging request, and return the business response data to the terminal corresponding to the determined smart contract debugging request.

[0190] In the above embodiment, debugging the smart contract in the cloud server avoids the user's cumbersome environment installation and resource costs. Not only is the debugging efficiency high, but it can also save the operation and maintenance costs during the smart contract debugging process. In addition, since monitoring events can be registered through remote call services, business services and container management services can communicate statelessly. The contract execution data obtained after the contract is executed can also be returned to the business service statelessly through the remote call service, thereby simulating contract calls statelessly on the cloud, improving the concurrency and expansion capabilities of the service, reducing the resource costs used by the service, and making it easier to upgrade and iterate the service, providing users with a better product experience.

[0191] In one embodiment, the present application also provides an application scenario, in which the blockchain IDE Saas stateless service simulation debugging is realized through the solution of the present application. Zhixin Chain IDE provides the function of an online blockchain IDE. Compared with Changan Chain IDE and other contract IDEs (Remix IDE), which provide tool-type IDEs and use the user's local environment, Zhixin Chain IDE provides saas services. Users log in to the Zhixin Chain open alliance chain platform to edit and simulate debugging contracts online. The service runs in a cloud cluster, avoiding the user's cumbersome environment installation and resource costs. Simulated contract debugging will not actually be chained, so no gas fees will be incurred. The contract can be debugged after the contract is built. The principle is to start the docker container in the background and simulate the execution of the contract code, similar to the docker-go virtual machine of Changan Chain.

[0192] In the related technologies, blockchain IDEs, such as Changan Chain's open-source smartEditor, Remix IDE, and AntDAO, use IDEs in two ways: one is the user's local environment or the user's self-built environment, which is a stateful service that relies on the local environment system. In the user's local environment, users need to download and install the IDE, which is complex to operate and has high operating costs; the other is to provide stateful functions, which reduces the concurrency and scalability of the service.

[0193] Through this embodiment, the stateless simulation debugging deployment solution after IDE SaaS can be realized, the concurrency and expansion capabilities of the service can be improved, the resource cost of the service can be reduced, the same resource consumption can serve more users, and the IDE cloud solution has more economic advantages. At the same time, after being stateless, the service is easier to upgrade and iterate, providing users with a better product experience.

[0194] refer to Fig.12 , which is a timing diagram of the smart contract debugging method provided in this embodiment, refer to Fig.12 , including the following steps:

[0195] 1. The user operates the simulated contract call function on the ide page and calls the ide business service running in the ide pod through the http interface.

[0196] Specifically, the user can operate the simulated contract call function on the terminal ide page, initiate a smart contract debugging request, and send a smart contract debugging request through the terminal to access the HTTP interface of the cloud server to call the ide business service. The smart contract debugging request carries the contract name, contract method, contract method parameters and request identifier.

[0197] 2. The business service parses the call request parameters and registers the monitoring event of this call to the RPC service running in the ide pod. The monitoring parameters corresponding to the registered monitoring event include: contract name, contract method, and request unique code. The RPC service registers and starts the monitoring event, and the monitoring result is returned.

[0198] The business service receives the smart contract debugging request, parses the smart contract debugging request, obtains the contract name, contract method, request identifier and other data carried therein, and then generates a monitoring event registration request based on the parsed data, and sends the monitoring event registration request to the RPC service. After the RPC service receives the monitoring event registration request, it registers the monitoring event and starts monitoring.

[0199] Monitoring events are used to monitor the contract execution data returned by smart contracts and return the contract execution data to business services. Because contract simulation calls are asynchronous requests, it is necessary to record the contract simulation call information, namely the contract name, contract method, and request identifier, so that the contract results can be correctly returned to the business service.

[0200] 3. The business service sends the docker run command to the dind service through the remote docker command. The dindservice forwards it to the docker deamon in the dind pod and carries the parameters of this call.

[0201] The business service can call the docker CLI of the started container to send the docker run command to the docker deamon of the container, and carry the parameters of this call including the contract name, contract method, contract method parameters, request identifier, the IP address of the ide pod to be accessed, the port number of the port monitored by the monitoring event, the domain name of the dind srevice, and the port number of the port monitored by the docker deamon. In this embodiment, since the business service and the docker deamon run in different pods, the business service needs to initiate remote access to the docker deamon.

[0202] 4. Docker Deamond starts the docker-go container.

[0203] Specifically, after receiving the docker run command, docker deamon obtains the dind image, and after running the dind image, the doceker-go container can be started.

[0204] 5. Start the docker-go container to execute the user contract.

[0205] Specifically, the doceker-go container obtains the bytecode of the smart contract identified by the contract identifier, calls the contract method according to the bytecode, and passes in the contract method parameters. After the call is completed, the contract execution data is obtained.

[0206] 6. After the docker-go container executes the contract, it directly accesses the ide pod through the docker-go contract (the IP is carried in the request) to return the contract execution data to the RPC service.

[0207] Specifically, after the smart contract call is completed, the contract execution data can be returned to the RPC service. The contract execution data includes the contract execution result, world status, contract log, and events. The contract execution data packet also carries the contract name and request identifier.

[0208] 7. The RPC service reads the contract execution result and notifies the request thread corresponding to the business service. And cancels the monitoring.

[0209] Specifically, the RPC service can compare the contract name and request identifier carried in the contract execution data with the contract name and request identifier corresponding to the registered monitoring event. If the comparison is consistent, it means that the contract execution data is successfully monitored, and the RPC service can return the contract execution data to the business service.

[0210] 8. The business service receives the contract execution result, converts it into business response data, and returns it to the user's ide page.

[0211] Specifically, the business service receives the contract execution data, converts the contract execution data into business response data, and then returns the business response data to the user terminal.

[0212] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0213] Based on the same inventive concept, the embodiment of the present application also provides a smart contract debugging device for implementing the smart contract debugging method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more smart contract debugging device embodiments provided below can refer to the limitations of the smart contract debugging method above, and will not be repeated here.

[0214] In some embodiments, Fig.13 As shown, a smart contract debugging device 1300 is provided, including:

[0215] The debugging request receiving module 1302 is used to receive the smart contract debugging request sent by the terminal through the cloud server, and the smart contract debugging request carries the contract identifier and the contract method;

[0216] A monitoring event registration module 1304 is used to register monitoring events in the cloud server in response to a smart contract debugging request;

[0217] The smart contract execution module 1306 is used to start a container in the cloud server, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data;

[0218] The business response data returning module 1308 is used to return the business response data of the smart contract debugging request to the terminal according to the contract execution data when the contract execution data is monitored through the monitoring event.

[0219] The above-mentioned smart contract debugging device receives the smart contract debugging request sent by the terminal through the cloud server. The smart contract debugging request carries the contract identifier and the contract method. In response to the smart contract debugging request, a monitoring event is registered in the cloud server, and a container is started in the cloud server. The smart contract identified by the contract identifier is obtained through the started container, and in the started container, the smart contract identified by the contract identifier is executed according to the contract method to obtain the contract execution data. When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data, thereby realizing the debugging of the smart contract in the cloud server, avoiding the user's cumbersome environment installation and resource costs, not only with high debugging efficiency, but also saving operation and maintenance costs during the smart contract debugging process.

[0220] In some embodiments, a smart contract debugging request is received through a business service in a cloud server; a monitoring event registration module is used to respond to the smart contract debugging request, send a monitoring event registration request to a remote call service in a cloud server through a business service, and the monitoring event registration request carries a contract identifier and a contract method; the monitoring event registration request is received through a remote call service, and the monitoring event is registered in the cloud server according to the contract identifier and contract method carried in the monitoring event registration request.

[0221] In some embodiments, the business service runs in a started container; the smart contract execution module is used to call the command line tool of the started container through the business service to send a container startup command; when the container startup command is received through the container management service of the started container, the container nested image is obtained through the container management service, and the container is started in the started container using the container nested image.

[0222] In some embodiments, the business service runs in a first resource object of the cloud server, and the started container runs in a second resource object of the cloud server, and the first resource object and the second resource object are different resource objects.

[0223] In some embodiments, the smart contract execution module is also used to call the command line tool of the started container through the business service to generate a container startup command, and carry the IP address of the resource object management service of the second resource object in the container startup command; according to the IP address, the container startup command is sent to the resource object management service of the second resource object, and the container startup command is used to instruct the resource object management service of the second resource object to receive the container startup command and forward the container startup command to the container management service of the started container.

[0224] In some embodiments, the container startup command also carries a preset port number, and the container startup command is used to instruct the resource object management service of the second resource object to forward the container startup command to the preset port corresponding to the preset port number; the smart contract debugging device of the present application also includes: a port monitoring module, which is used to monitor the preset port through the container management service of the started container; when a container startup command sent to the preset port is monitored, the container startup command is received through the container management service of the started container.

[0225] In some embodiments, the monitoring event and the started container run on different resource objects in the cloud server, the smart contract debugging request is received through the business service in the cloud server, and the container is triggered and started by the container startup command sent by the business service, and the container startup command carries the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event; the business response data return module is used to send the contract execution data to the port monitored by the monitoring event in the resource object where the monitoring event runs according to the IP address and port number of the resource object where the monitoring event runs, so that the monitoring event monitors the contract execution data; when the contract execution data is monitored through the monitoring event, the contract execution data is sent to the business service; and the business response data of the smart contract debugging request is returned to the terminal through the business service according to the contract execution data.

[0226] In some embodiments, the container startup command also carries a contract identifier and a request identifier of a smart contract debugging request. The container startup command indicates the resource object run by the started container, and carries the contract identifier and the request identifier in the contract execution data; the business response data return module is also used to determine the smart contract debugging request corresponding to the contract execution data through business services according to the contract identifier and the request identifier carried in the contract execution data; convert the format of the contract execution data through the business service to obtain the business response data of the smart contract debugging request; and return the business response data to the terminal through the business service.

[0227] In some embodiments, the debugging request receiving module is used to forward the smart contract debugging request to the smart contract integrated development service of the cloud server when the external request access agent of the cloud server receives the smart contract debugging request; forward the smart contract debugging request to the business service of the cloud server through the smart contract integrated development service; and receive the smart contract debugging request through the business service of the cloud server.

[0228] In some embodiments, the business service and the started container run on different resource objects in the cloud server; the smart contract debugging device of the present application also includes: a dynamic adjustment module, used to count the number of smart contract debugging requests received by the business service; based on the counted number of smart contract debugging requests, determine the first number of resource objects used to run the business service and the second number of resource objects used to run the started container; based on the first number, adjust the actual number of resource objects used to run the business service; based on the second number, adjust the actual number of resource objects used to run the started container.

[0229] In some embodiments, when multiple smart contract debugging requests are received, the smart contract execution module is also used to determine the parallel contract methods from the contract methods carried by the multiple smart contract debugging requests according to a pre-established contract method registry; divide the contract method groups according to the parallel contract methods, and determine the execution order of each contract method group; according to the execution order, serially execute the smart contracts corresponding to each contract method according to each contract method group; wherein, in the process of serial execution, when any contract method group includes multiple contract methods, the smart contracts corresponding to each contract method are executed in parallel according to the included contract methods.

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

[0231] In some embodiments, a computer device is provided, which may be a cloud server, and its internal structure diagram may be as follows: Fig.14 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, 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 the computer program in the non-volatile storage medium. The database of the computer device is used to store smart contract data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a smart contract debugging method is implemented.

[0232] Those skilled in the art will understand that Fig.14 The 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 those shown in the figure, or combine certain components, or have a different arrangement of components.

[0233] In some embodiments, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the above-mentioned smart contract debugging method when executing the computer program.

[0234] In some embodiments, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above-mentioned smart contract debugging method are implemented.

[0235] In some embodiments, a computer program product is provided, including a computer program, which implements the steps of the above-mentioned smart contract debugging method when executed by a processor.

[0236] 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 relevant laws, regulations and standards of relevant countries and regions.

[0237] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and 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 embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present 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), magnetoresistive 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0238] The technical features of the above embodiments may 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.

[0239] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A smart contract debugging method, characterized in that: The method comprises: Receiving a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method; In response to the smart contract debugging request, registering a monitoring event in the cloud server; Starting a container in the cloud server, obtaining the smart contract identified by the contract identifier through the started container, and executing the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data; When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data.

2. The method according to claim 1, characterized in that The smart contract debugging request is received through a business service in the cloud server; The step of registering a monitoring event in the cloud server in response to the smart contract debugging request includes: In response to the smart contract debugging request, sending a monitoring event registration request to the remote call service in the cloud server through the business service, wherein the monitoring event registration request carries the contract identifier and the contract method; The monitoring event registration request is received through the remote call service, and the monitoring event is registered in the cloud server according to the contract identifier and contract method carried in the monitoring event registration request.

3. The method according to claim 2, characterized in that The business service runs in the started container; and starting the container in the cloud server includes: By using the business service, the command line tool of the started container is called to send a container start command; When the container start command is received through the container management service of the started container, the container nested image is obtained through the container management service, and the container is started in the started container using the container nested image.

4. The method according to claim 3, characterized in that The business service runs in a first resource object of the cloud server, and the started container runs in a second resource object of the cloud server, and the first resource object and the second resource object are different resource objects.

5. The method according to claim 4, characterized in that The calling, through the business service, of a command line tool of the started container to send a container start command includes: By using the business service, calling the command line tool of the started container to generate a container startup command, and carrying the IP address of the resource object management service of the second resource object in the container startup command; According to the IP address, the container startup command is sent to the resource object management service of the second resource object, where the container startup command is used to instruct the resource object management service of the second resource object to receive the container startup command and forward the container startup command to the container management service of the started container.

6. The method according to claim 5, characterized in that The container startup command also carries a preset port number, and the container startup command is used to instruct the resource object management service of the second resource object to forward the container startup command to a preset port corresponding to the preset port number; The method further comprises: Monitoring the preset port through a container management service of the started container; When a container start command sent to the preset port is detected, the container start command is received through the container management service of the started container.

7. The method according to claim 1, characterized in that The monitoring event and the started container run on different resource objects in the cloud server, the smart contract debugging request is received through the business service in the cloud server, and the container is triggered and started by the container start command sent by the business service, and the container start command carries the IP address of the resource object where the monitoring event runs and the port number of the port monitored by the monitoring event; When the contract execution data is monitored through the monitoring event, the business response data of the smart contract debugging request is returned to the terminal according to the contract execution data, including: According to the IP address and the port number of the resource object where the monitoring event is running, the contract execution data is sent to the port monitored by the monitoring event in the resource object where the monitoring event is running, so that the monitoring event monitors the contract execution data; When the contract execution data is monitored through the monitoring event, the contract execution data is sent to the business service; The business service returns the business response data of the smart contract debugging request to the terminal according to the contract execution data.

8. The method according to claim 7, characterized in that The container startup command also carries the contract identifier and the request identifier of the smart contract debugging request, the container startup command indicates the resource object run by the started container, and carries the contract identifier and the request identifier in the contract execution data; The returning the business response data of the smart contract debugging request to the terminal through the business service according to the contract execution data includes: Determining, through the business service, the smart contract debugging request corresponding to the contract execution data according to the contract identifier and the request identifier carried in the contract execution data; The contract execution data is formatted through the business service to obtain business response data of the smart contract debugging request; The business response data is returned to the terminal through the business service.

9. The method according to any one of claims 1 to 8, characterized in that: The step of receiving the smart contract debugging request sent by the terminal through the cloud server includes: When the external request access agent of the cloud server receives the smart contract debugging request, forwarding the smart contract debugging request to the smart contract integrated development service of the cloud server; Forwarding the smart contract debugging request to the business service of the cloud server through the smart contract integrated development service; The smart contract debugging request is received through the business service of the cloud server.

10. The method according to claim 9, characterized in that The business service and the started container run on different resource objects in the cloud server; the method further includes: Count the number of smart contract debugging requests received by the business service; Determine, according to the statistical number of the smart contract debugging requests, a first number of resource objects used to run the business service and a second number of resource objects used to run the started container; adjusting the actual number of resource objects used to run the business service according to the first number; According to the second quantity, the actual quantity of resource objects used to run the started container is adjusted.

11. The method according to any one of claims 1 to 8, characterized in that: When multiple smart contract debugging requests are received, the smart contract identified by the contract identifier is executed according to the contract method to obtain contract execution data, including: Determine, according to a pre-established contract method registry, a contract method that can be run in parallel from the contract methods carried by the multiple smart contract debugging requests; Divide the contract method groups according to the parallelizable contract methods and determine the execution order of each contract method group; According to the execution order, the smart contracts corresponding to each of the contract methods are executed serially according to each of the contract method groups; wherein, during the serial execution process, when any contract method group includes multiple contract methods, the smart contracts corresponding to each of the contract methods are executed in parallel according to the included contract methods.

12. A smart contract debugging device, characterized in that: The device comprises: A debugging request receiving module, used to receive a smart contract debugging request sent by a terminal through a cloud server, wherein the smart contract debugging request carries a contract identifier and a contract method; A monitoring event registration module, configured to register a monitoring event in the cloud server in response to the smart contract debugging request; A smart contract execution module, used to start a container in the cloud server, obtain the smart contract identified by the contract identifier through the started container, and execute the smart contract identified by the contract identifier in the started container according to the contract method to obtain contract execution data; The business response data returning module is used to return the business response data of the smart contract debugging request to the terminal according to the contract execution data when the contract execution data is monitored through the monitoring event.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: 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