Smart contract security processing method and device, electronic equipment and storage medium

Abstract

The invention relates to a security processing method and device for a smart contract, electronic equipment and a storage medium. The method comprises the following steps: under the condition that a contract remote debugging request is received, performing parameter analysis on the contract remote debugging request to obtain a first contract name and a first account identifier of the request; splicing the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory; under the condition that a first smart contract corresponding to the first contract name belongs to the smart contract of the first account identifier and the target contract directory exists, setting a resource access permission of the contract remote debugging request as a preset access permission, so that the first account identifier cannot access system resources on a physical host; and calling the contract container in the resource object to run the first smart contract under the preset access permission so as to perform remote simulation debugging on the first smart contract. According to the technical scheme provided by the invention, the security of simulating and debugging the smart contract can be improved.

Description

Technical Field

[0001] The present application relates to the field of security technology of smart contracts in blockchain, and in particular to a method, device, electronic device and storage medium for secure processing of smart contracts. Background Art

[0002] Currently, blockchain IDEs (Integrated Development Environments, or IDEs) offer two approaches to contract simulation debugging. One approach involves using a local or user-created environment, which is independent, user-controllable, and free from network sniffing issues. The other approach involves pre-deploying contracts to corresponding public or test blockchain networks for debugging, mitigating system security issues through public blockchain mechanisms. While the former requires downloading and installing an IDE, which is secure but complex, the latter requires pre-deploying contracts to the corresponding blockchain and incurs a fee. This approach is suitable for scenarios where contracts have already been debugged, but not for those in the early stages of contract development. For example, if a contract requires multiple adjustments, it will require multiple re-debugging. This not only requires multiple deployments to the blockchain, complicating contract debugging operations but also leads to higher debugging costs. Summary of the Invention

[0003] This application provides a method, device, electronic device, and storage medium for securely processing smart contracts to at least address the related art issue of how to improve security protection against Trojan horse implants during remote debugging of smart contracts. The technical solution of this application is as follows:

[0004] According to a first aspect of an embodiment of the present application, a secure processing method for smart contract processing is provided, which is applied to a resource object running on a physical host, wherein the resource object is provided with a contract container; the method comprises:

[0005] Upon receiving a contract remote debugging request, performing parameter parsing on the contract remote debugging request to obtain a first contract name and a first account identifier that triggers the contract remote debugging request;

[0006] Concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory;

[0007] If the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists, set the resource access permission for the contract remote debugging request to the preset access permission;

[0008] Under the preset access permission, the contract container in the resource object is called to run the first smart contract to perform remote simulation debugging on the first smart contract.

[0009] According to a second aspect of an embodiment of the present application, a secure processing device for smart contract processing is provided, which is applied to a resource object running on a physical host, wherein the resource object is provided with a contract container; the device includes:

[0010] A debugging request parsing module is used to parse parameters of a contract remote debugging request upon receiving the contract remote debugging request, and obtain the first contract name and the first account identifier that triggers the contract remote debugging request;

[0011] a target contract directory acquisition module, configured to concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory;

[0012] a permission adjustment module, configured to set the resource access permission for the contract remote debugging request to a preset access permission if the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists;

[0013] A contract debugging module is used to call the contract container in the resource object to run the first smart contract under the preset access permission to perform remote simulation debugging on the first smart contract.

[0014] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a method as described in any one of the first aspects above.

[0015] According to the fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by the processor of an electronic device, the electronic device can execute any method described in the first aspect of the embodiments of the present application.

[0016] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, comprising computer instructions, which, when executed by a processor, enable a computer to execute any one of the methods according to the first aspect of the embodiment of the present application.

[0017] The technical solutions provided by the embodiments of this application bring at least the following beneficial effects:

[0018] By receiving a contract remote debugging request, parsing the contract remote debugging request parameters to obtain the first contract name and the first account identifier that triggers the contract remote debugging request, and concatenating the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory; and when the first smart contract corresponding to the first contract name belongs to the smart contract of the first account identifier, and the target contract directory exists, setting the resource access permission of the contract remote debugging request to the preset access permission, the preset access permission indicates that the first account identifier can access resources other than the system resources on the physical host; under the preset access permission, calling the contract container in the resource object to run the first smart contract to perform remote simulation debugging of the first smart contract. In this way, by setting the contract container in the resource object running on the physical host, it is possible to implement simulation debugging of smart contracts based on the blockchain IDE, without the need for environment installation and contract deployment on the chain. After the contract is built, the contract can be simulated and debugged, which is more convenient; and by setting verification of whether the target contract directory and contract name belong to the account, it is possible to effectively prevent the risk of malicious accounts implanting Trojans during contract simulation execution, thereby providing the account with a free, convenient and secure contract simulation debugging function.

[0019] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0021] Figure 1 It is a schematic diagram showing an application environment according to an exemplary embodiment.

[0022] Figure 2 The present invention is a flowchart of a security protection method for Trojan horse implantation in smart contract processing according to an exemplary embodiment.

[0023] Figure 3 The figure is a schematic diagram showing isolation of a Docker file namespace according to an exemplary embodiment.

[0024] Figure 4 The figure is a schematic diagram of a simulation debugging process of a smart contract according to an exemplary embodiment.

[0025] Figure 5 The figure is a schematic diagram showing mounting a contract directory according to an exemplary embodiment.

[0026] Figure 6 The figure is a flow diagram of contract writing according to an exemplary embodiment.

[0027] Figure 7 The figure is another flow diagram of writing a contract according to an exemplary embodiment.

[0028] Figure 8 The present invention is a block diagram of a secure processing device for a smart contract according to an exemplary embodiment.

[0029] Figure 9 This is a block diagram of an electronic device illustrating a security protection method for Trojan horse implantation in smart contract processing based on an exemplary embodiment.

[0030] Figure 10 It is a block diagram of an electronic device showing a security protection method for Trojan horse implantation in smart contract processing according to an exemplary embodiment. DETAILED DESCRIPTION

[0031] Various exemplary embodiments, features, and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0032] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0033] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0034] In addition, numerous specific details are provided in the detailed description below to better illustrate the present application. Those skilled in the art will appreciate that the present application can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main purpose of the present application.

[0035] Before introducing the method embodiments provided in the present application, a brief introduction is first given to the application scenarios, relevant terms or nouns that may be involved in the method embodiments of the present application to facilitate understanding by technical personnel in the field of the present application.

[0036] A pod is the smallest deployable computing unit that can be created and managed in Kubernetes (k8s). It can be called a resource object in k8s and is a group of (one or more) containers. These containers share storage, networks, and declarations on how to run these containers. The contents of a pod can be collocated and scheduled together to run in a shared context. A 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.

[0037] A Service in Kubernetes is a way to expose a network application running on one or a group of pods as a network service.

[0038] A pod in k8s is generally composed of a docker container or a group of docker containers.

[0039] Docker is a software platform that allows you to quickly build, test, and deploy applications. Docker packages software into standardized units called containers that have all the functionality needed to run the software, including libraries, system tools, code, and more. Docker allows you to quickly deploy and scale applications to any environment. Docker works by providing a standard way to run code. Docker is an operating system for containers, and similar to how virtual machines are hardware used to virtualize (without the need for direct management) servers, containers are operating systems for virtualized servers. Docker is installed on every server and provides simple commands that can be used to build, start, or stop containers.

[0040] See also Figure 1 , Figure 1 A schematic diagram of an application system provided according to an embodiment of the present application is shown. The application system can be used in the security protection method for Trojan horse implantation in the smart contract processing of the present application. Figure 1As shown, the application system may at least include a physical host, a resource object pod running on the physical host, and smart contracts (such as contract A, contract B, and contract C) stored in a remote hard disk (or called a remote file system or cloud file system). The contract directory of the smart contract in the remote hard disk can be mounted into the pod so that the pod can remotely access the contract file corresponding to the smart contract in the remote hard disk, thereby realizing the construction and remote debugging of the smart contract. Among them, the physical host can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a terminal. The remote file system can be a cloud server that provides cloud services such as cloud database and cloud storage. The pod can be a resource object that runs a containerized application on k8s, such as Figure 1 As shown, two containers can run in a pod. The ide container, i.e., the ide business service, can be used to provide contract IDE interface services. The dind container can be a container running a docker environment, used to provide the docker-go container (contract container) running environment.

[0041] In the present application, refer to Figure 1 , multiple pods can be run on a physical host, and each pod can be composed of an IDE container (business container) and a dind container, which is not limited in this application. The IDE container can receive a contract remote debugging request as a business service. For example, when the IDE container receives a contract remote debugging request, it can start a docker-go container through the docker run command, and mount the contract file directory in the remote hard disk by the network file system, so that the dind container can access the contract file of the smart contract in the remote hard disk and run the contract file to realize remote debugging of the smart contract. In one possible implementation, the above-mentioned docker run command can be sent to the dind container through shared volume communication. For example, the docker run command can be sent to the docker deamon through the emptyDi r shared volume file sock, and the docker deamon starts the docker-go container in the dind container to run the smart contract that needs to be debugged and perform contract debugging. Optionally, the contract debugging result can be obtained, and the contract debugging result can be returned to the contract debugger.

[0042] In the embodiments of this specification, a blockchain IDE remote simulation contract debugging or a prevention solution for Trojan horse implantation when writing contracts is proposed. As an example, during the remote simulation debugging process, the Zhixin Chain IDE can be used to provide an online contract remote simulation debugging function. Compared with the Changan Chain IDE and other IDEs that provide tool-type simulation contract debugging using the user's local environment, the Zhixin Chain IDE provides a sass service. Accounts can log in to the Xinlian open alliance chain platform to edit and simulate debugging contracts online. The service runs in a cloud cluster, avoiding the cumbersome environment installation and resource costs of the account. The remote simulation contract debugging can be achieved by starting a docker container in the background, which is similar to the Changan Chain's docker-go virtual machine. In this way, remote simulation contract debugging does not require actual chain, and no gas fees are generated. The contract can be debugged after it is built, which is more convenient.

[0043] In addition, it should be noted that Figure 1 What is shown is only one application environment of the security protection method for Trojan horse implantation in smart contract processing provided by this application.

[0044] In the embodiments of this specification, the pod and the remote hard disk may be connected directly or indirectly via wired or wireless communication, which is not limited in this application.

[0045] In a specific embodiment, when the physical host is a distributed system, the distributed system can be a blockchain system. Blockchain is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (to prevent counterfeiting) and generate the next block. Blockchain can include the blockchain underlying platform, the platform product service layer, and the application service layer.

[0046] The underlying blockchain platform can include processing modules such as account management, basic services, smart contracts, and operation monitoring. Among them, the account management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between the account's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management), and then encrypts the business information before encrypting it. After encryption, it is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored; 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 certain programming language and publish it to the blockchain after simulation debugging (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution to complete the contract logic. At the same time, 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 operation during the product release process, such as alarm, network status monitoring, node equipment health status monitoring, etc.

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

[0048] It should be noted that in the specific implementation of this application, account-related data is involved. When the following embodiments of this application are applied to specific products or technologies, account permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0049] Figure 2 This is a flowchart of a method for securely processing a smart contract according to an exemplary embodiment, which can be applied to a resource object running on a physical host, wherein the resource object is provided with a contract container. Figure 2 As shown, the method may include the following steps.

[0050] Step S201: When a contract remote debugging request is received, the contract remote debugging request is parsed to obtain a first contract name and a first account identifier that triggers the contract remote debugging request.

[0051] In the embodiments of this specification, the contract debugger can simulate debugging the constructed smart contract, which can trigger the generation of a contract remote debugging request to the pod, that is, the resource object running on the physical host. When the contract debugger triggers the simulated debugging, the contract name for the simulated debugging can be specified. For example, the contract name to be simulated debugged can be carried in the contract remote debugging request. For example, the contract remote debugging request can be triggered online, which is not limited in this application. Accordingly, the pod can receive the contract remote debugging request. When the contract remote debugging request is received, in order to verify the contract directory of the smart contract requested to be debugged by the contract remote debugging request to improve the security of the contract debugging, the contract remote debugging request can be parameter parsed to obtain the first contract name and the first account identifier that triggers the contract remote debugging request, which can be used for the subsequent splicing of the contract directory.

[0052] For example, after a smart contract is built, it can be stored in the cloud file system. There is no need to pre-deploy the smart contract to the corresponding public chain network or test chain network for debugging. That is, in the early stage of contract writing, the contract remote debugging request can be safely and conveniently triggered to realize remote debugging of the smart contract.

[0053] Among them, the first contract name can refer to the name of the smart contract requested for debugging, such as Contract A, Contract B, etc. This application does not limit this, as long as it can identify the smart contract. The first account identifier can refer to the account identifier that triggers the contract remote debugging request. For example, if a contract debugger triggers a contract remote debugging request, the first account identifier can refer to the account identifier corresponding to the contract debugger. The account identifier is used to distinguish different accounts. Since the smart contracts constructed by each account will be associated with each account and stored, there is a corresponding relationship between the account and the smart contract. This can be used to distinguish the smart contracts belonging to different accounts, avoiding the account debugging other smart contracts that do not belong to the account, resulting in lower security of contract debugging.

[0054] Step S203: Concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory.

[0055] In the embodiments of this specification, the preset contract directory format may be pre-set, and this application does not limit this. For example, the preset contract directory format may be used to indicate the hierarchical order of contract names and account identifiers in the contract directory. For example, the preset contract directory format may be: / workspace / userId / contractname / , where userId refers to the account identifier and contractname may refer to the contract name. This is merely an example of the preset contract directory format and does not limit the embodiments of this application.

[0056] In actual applications, after parsing to obtain the first contract name and the first account identifier, the first contract name and the first account identifier can be concatenated according to the preset contract directory format to obtain the target contract directory. That is, the first contract name and the first account identifier can be concatenated according to the preset contract directory format to obtain the target contract directory. For example, taking the above-mentioned preset contract target format / workspace / user Id / contractname / as an example, if the first account identifier is 1 and the first contract name is A, then the 1 of the first account identifier can be filled in the user Id field of the preset contract directory format, and the A of the first contract name can be filled in the contractname field of the preset contract directory format, resulting in the target contract directory being: / workspace / 1 / A / .

[0057] In step S205, when the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists, the resource access permission of the contract remote debugging request is set to the preset access permission, which indicates that the first account identification can access resources other than system resources on the physical host.

[0058] In actual applications, Docker is a virtualization technology. The system runs in a Docker container and can be distinguished from the host system. However, in essence, the Docker container is a process managed by the Docker daemon process running on the physical host. The file namespace isolation technology in the underlying Linux kernel is used to virtualize the Docker container file system, but it still relies on the kernel system of the physical host. For example, Figure 3As shown. Among them, the background starts the docker container implementation, which is similar to the docker-go virtual machine of Changan Chain. Based on this, the KVM (Kernel-based Virtual Machine) in the Linux kernel can be used. The full virtualization solution based on the Linux kernel allows multiple virtual machines to run on one physical host. However, the isolation protection measures provided at the Linux kernel level are limited, and some key contents are still not completely isolated, such as key directories for system resource operation (such as / proc, / sys, etc.), pseudo file systems, etc. If these directories are implanted with Trojans and exploited by malicious accounts, they will cause harm to the security of the host system and even threaten the resource security of the entire cloud. In addition, in the embodiment of this specification, the docker-go container mounts the file system of the dind container, but the dind container runs in the pod, and the pod runs on the physical host. In essence, they are all processes on the physical host. Therefore, the system resources of the docker-go container ultimately share the file system resources of the physical host with other business pods. In summary, choose to control the permissions of the docker-go container, and cannot access the system directory of the docker-go container, that is, choose to set it so that the system resources on the physical host cannot be accessed to protect the security of the system resources.

[0059] In the examples of this specification, see Figure 4 After the contract directories are spliced, it can be determined whether the target contract directory exists and whether the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account. If both are yes, that is, the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account, and the target contract directory exists, the resource access rights of the contract remote debugging request can be set to the preset access rights. The preset access rights indicate that the first account identifier can access resources other than system resources on the physical host, that is, the preset access rights indicate that the system resources on the physical host cannot be accessed. Compared with the root permission, the preset access rights can be regarded as ordinary account permissions lower than the root permission. By setting the resource access rights of the contract remote debugging request to the preset access rights, the contract debugging process triggered by the contract remote debugging request cannot access the system resources on the physical host, thereby avoiding damage to the physical host, such as implanting a Trojan horse in the system resources.

[0060] Optionally, if the target contract directory does not exist or the first smart contract corresponding to the first contract name does not belong to the smart contract identified by the first account, an error indicating that the operator has no permission to operate the contract may be directly returned.

[0061] Among them, whether the target contract directory exists may refer to whether the target contract directory exists in the contract directory mounted on the pod. Based on this, the target contract directory can be searched in the contract directory mounted on the pod. If the target contract directory is found, it can be determined that the target contract directory exists; if the target contract directory is not found, it can be determined that the target contract directory does not exist.

[0062] Step S207: Under the above-mentioned preset access rights, call the contract container in the resource object to run the first smart contract to perform remote simulation debugging on the first smart contract.

[0063] In the embodiment of this specification, the above-mentioned preset access rights can be used to constrain the contract debugging process, that is, under the above-mentioned preset access rights, the contract container in the resource object can be called to run the first smart contract to perform remote simulation debugging on the first smart contract. For example, refer to Figure 1 , you can call the d ind container in the pod to run the first smart contract to perform remote simulation debugging on the first smart contract, and you can get the contract debugging results and return them to the contract debugger, such as Figure 4 As shown. Using the above-mentioned preset access rights to constrain the contract debugging process can include: pausing the contract container's operation when the contract container triggers access to system resources, thereby achieving the purpose of ensuring contract debugging security through preset access rights. In one example, resource access when the contract container runs the first smart contract can be monitored in real time. If the accessed resource is detected to be a system resource, the contract container's operation can be suspended.

[0064] In actual applications, when debugging a contract, it is necessary to mount the contract file directory into the docker-go container to allow contract debugging. At this time, the docker-go container needs read and write permissions for the mounted contract file directory. At the same time, attention should be paid to the security of the mounted file directory to prevent the docker-go container from installing Trojan programs and attacking the host system through the mounted directory, such as the system resources of the physical host. Based on this, in the embodiment of this specification, it is chosen to mount a remote file system into the container to avoid system security issues caused by mounting files on the physical host. The remote file system, also known as the cloud file system, is essentially a remote storage device, such as Figure 1The remote hard disk in the cloud can provide a secure, network-isolated file storage system, and use the network file protocol to read and write files through the network file system NFS (Network File System). The storage of the cloud file system does not support the environment in which the program runs, and needs to be mounted to the physical host system to run. Trojan programs cannot run on the cloud file system, which can avoid attacks on the cloud file system, thereby avoiding such attacks on the physical host using file mounting methods and protecting the security of the physical host. Based on this, you can refer to Figure 5 , execute contract debugging by mounting the contract directory. On this basis, in a possible implementation, the above-mentioned calling of the contract container in the resource object to run the first smart contract to perform remote simulation debugging on the first smart contract may include: reading the contract file directory in the remote file system through the network file system of the contract container, and mounting the contract file directory to the contract container; thereby calling the contract container to read the contract file corresponding to the first smart contract from the remote file system based on the contract file directory, and running the contract file in the contract container to realize debugging of the first smart contract. Optionally, refer to Figure 5 , you can also mount the contract file directory into the business container for use in the above contract directory verification process.

[0065] In an optional implementation, based on the aforementioned cloud file system, considering that the cloud file system can isolate storage space, each account's storage space is independent and does not affect the storage of other accounts on the cloud. If malicious code is found in an account, the corresponding storage space in the cloud file system can be specifically cleared to protect the security of the entire cloud file system. Based on this, the method can also include: if unsafe code is detected during the execution of the contract file, the storage space corresponding to the contract file in the remote file system can be cleared to protect the security of the entire cloud file system.

[0066] Upon receiving a contract remote debugging request, the contract name and account identification parameters of the contract remote debugging request are parsed to obtain a first contract name and a first account identification that triggers the contract remote debugging request, and the first contract name and the first account identification are spliced ​​according to a preset contract directory format to obtain a target contract directory; and when the first smart contract corresponding to the first contract name belongs to the smart contract of the first account identification and the target contract directory exists, the resource access permission of the contract remote debugging request is set to a preset access permission, where the preset access permission indicates that the first account identification can access resources other than system resources on the physical host; under the preset access permission, the contract container in the resource object is called to run the first smart contract to perform remote simulation debugging on the first smart contract. In this way, by setting up a contract container in the resource object running on the physical host, it is possible to implement simulation debugging of smart contracts based on the blockchain IDE. There is no need for cumbersome environment installation, nor is there any need to deploy the contract on the chain. After building the contract, the contract can be simulated and debugged, which is more convenient. Moreover, by setting up verification of the target contract directory and whether the contract name belongs to the account, it can effectively prevent the risk of malicious accounts implanting Trojans during contract simulation execution, that is, it can effectively prevent the account that triggers the debugging of the smart contract from implanting Trojans, making IDE remote contract debugging possible, thereby providing the account with free and convenient contract simulation debugging functions.

[0067] Reference Figure 1 In one possible implementation, the resource access rights for the contract remote debugging request are set to the preset access rights, which can be achieved through the following steps, including: calling the business container in the resource object to generate a startup command for the contract container according to the preset access rights; the startup command carries the preset access rights. Figure 1 In the example, the docker-go container is started by the ide container using the docker run command. You can then increase the account permissions for the executable file of the docker-go container during startup to prohibit access to the system resources of the physical host. For example, the startup command with increased account permissions can be as follows:

[0068] / usr / bin / docker run --name 104050_0-dv / root / wide / workspaces / 104050 / exec: / contract-w / contract --network bridge-u 6667:6667--memory 128M--cpus0.4centos:8. / proxyContract

[0069] Among them, use a normal account (6667, the minimum permission account, which only supports read operations on the contract directory) to run the contract file, avoiding the possibility of using the default root permission (root permission has all permissions of the docker-go container and can do anything in docker-go, and the permissions are somewhat large) to infiltrate the system into the d ind container, or even the physical host, which will cause a significant system impact. Therefore, during the operation and debugging of the first smart contract, it is necessary to change the permissions of the first account identifier from root permissions to those of a normal account. The permissions of a normal account are limited to the home directory and its own files, and it has no permission to operate on system resources, which can effectively avoid the risk of infiltrating the physical host system.

[0070] Accordingly, the above-mentioned calling of the contract container in the resource object to run the first smart contract under the preset access rights to perform remote simulation debugging of the first smart contract may include: using the business container to send a start command to the contract container; and calling the contract container to respond to the start command, parsing the preset access rights from the start command, and using the contract container to run the first smart contract under the preset access rights.

[0071] In the embodiments of this specification, refer to Figure 6 In addition to the above-mentioned contract debugging, the processing of smart contracts can also include contract compilation, that is, writing contracts. In actual applications, when writing contracts, a contract directory will be specified. Malicious accounts can be implanted into the system or other accounts' smart contracts through the directory, causing damage to the system. Based on this, the embodiment of this specification chooses to verify the permission to write to the contract directory. Based on this, the method can also include:

[0072] In response to the contract write request, the contract write request is parsed to obtain the specified write directory, the second contract name, and the second account identifier that triggered the contract write request;

[0073] Concatenate the second contract name and the second account ID according to the preset contract directory format to obtain the written contract directory;

[0074] If the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account, and the contract write directory matches the prefix of the specified write directory, the contract write request is executed. Based on this, the execution result can be returned.

[0075] In one possible implementation, executing the contract write request may include reading a contract file directory in a remote file system through a network file system of the contract container, and mounting the contract file directory into the contract container; thereby writing a second smart contract into a contract file corresponding to a second contract name in the write contract directory or a target write directory through the network file system.

[0076] In one example, when the account corresponding to the second account identifier initiates a contract write request, the request can be parsed to obtain parameters such as the designated write directory, the second contract name, and the second account identifier that triggered the contract write request. The second contract name and the second account identifier can then be concatenated according to a preset contract directory format to obtain the write contract directory. For example, if the second account identifier is 2 and the second contract name is A, the concatenated write contract directory might be / workspace / 2 / A / . If the specified write directory is / workspace / 2 / A / src / main.go, the specified write directory can be regarded as an input parameter, so that the concatenated write contract directory can be used to perform prefix matching with the input parameter. The prefix of the input parameter can be / workspace / 2 / A / , which matches the write contract directory; and it can be judged whether the second smart contract corresponding to the second contract name A belongs to the smart contract of the second account identifier 2. If it does, the second smart contract corresponding to the second contract name belongs to the smart contract of the second account identifier, and the write contract directory matches the prefix of the specified write directory. In this case, the write contract request can be executed, and the execution result can be returned to the second account identifier that triggered the write contract. For example, it can be returned by sending a message or a visual reminder, etc. This application is not limited to this.

[0077] See also Figure 6 Optionally, if the second smart contract corresponding to the second contract name does not belong to the smart contract identified by the second account, or the written contract directory does not match the prefix of the specified write directory, an unauthorized error can be returned as a reminder.

[0078] See also Figure 7 In an optional embodiment, if the designated write directory is a relative path, the designated write directory of the relative path can be first converted to an absolute path, and then the absolute path can be used to perform directory prefix matching to avoid relative path implantation. The relative path implantation can refer to the input relative path, which circumvents the contract directory permission check and causes system risks. Based on this, when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account, and the write contract directory matches the prefix of the designated write directory, before executing the write contract request step, the method can also include: when the designated write directory is a relative path, converting the designated write directory to a target write directory, where the target write directory is an absolute path, for example, an absolute real path in a remote hard disk.

[0079] Correspondingly, the above-mentioned execution of the contract write request when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the write contract directory matches the prefix of the specified write directory may include: executing the contract write request when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the target write directory matches the prefix of the write contract directory.

[0080] The relative path may refer to a path relative to a certain base directory, and the absolute path may refer to a real path in the remote hard disk.

[0081] In the embodiment of this specification, if the relative path is / workspace / 2 / contractname / .. / .. / .. / proc, what it actually accesses is the proc directory. In this way, the system resources of the physical host can be accessed through the relative path, causing malicious accounts to implant Trojan programs in the system through this vulnerability, causing huge harm. For this vulnerability, it is necessary to optimize the prefix matching, that is, the relative path can be converted into an absolute path before the prefix matching. Exemplarily, after parsing the specified write directory parameters, the filepath.Abs ​​interface can be uniformly used to convert them into absolute directories (i.e., absolute paths), such as / workspace / 2 / contractname / .. / .. / .. / proc can be converted into an absolute directory: / proc, and then directory prefix matching is performed to determine whether the account has permission to operate the files under this directory, thereby avoiding relative path Trojan injection and ensuring the safety of the system. When the specified write directory in the write contract request is a relative path, by converting the specified write directory into an absolute directory, it is possible to effectively avoid Trojan implantation by relative path to endanger the system when writing the contract, thereby improving the safety of writing the contract.

[0082] The embodiments of this specification make remote debugging and writing of smart contracts safer and more convenient through multiple protection methods such as account permission adjustment during contract runtime, remote contract directory mounting, contract directory permission access, and relative path implantation.

[0083] Figure 8 This is a block diagram of a security protection device for Trojan horse implantation in smart contract processing according to an exemplary embodiment, which is applied to a resource object running on a physical host, wherein the resource object is provided with a contract container. Figure 8 , the apparatus may include:

[0084] The debugging request parsing module 801 is used to parse the parameters of the contract remote debugging request when receiving the contract remote debugging request to obtain the first contract name and the first account identifier that triggers the contract remote debugging request;

[0085] A target contract directory acquisition module 803 is configured to concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory;

[0086] a permission adjustment module 805 configured to, if the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists, set the resource access permission for the contract remote debugging request to a preset access permission, where the preset access permission indicates that the first account identifier can access resources other than system resources on the physical host;

[0087] The contract debugging module 807 is used to call the contract container in the resource object to run the first smart contract under the preset access permission to perform remote simulation debugging on the first smart contract.

[0088] Upon receiving a contract remote debugging request, the contract remote debugging request is parsed for parameters to obtain a first contract name and a first account identifier that triggers the contract remote debugging request, and the first contract name and the first account identifier are concatenated according to a preset contract directory format to obtain a target contract directory; and when the first smart contract corresponding to the first contract name belongs to the smart contract of the first account identifier and the target contract directory exists, the resource access permission of the contract remote debugging request is set to a preset access permission, where the preset access permission indicates that the first account identifier can access resources other than system resources on the physical host; under the preset access permission, the contract container in the resource object is called to run the first smart contract to perform remote simulation debugging on the first smart contract. In this way, by setting up a contract container in the resource object running on the physical host, it is possible to implement simulation debugging of smart contracts based on the blockchain IDE. There is no need for cumbersome environment installation, nor is there any need to deploy the contract on the chain. After building the contract, the contract can be simulated and debugged, which is more convenient. Moreover, by setting up verification of the target contract directory and whether the contract name belongs to the account, it can effectively prevent the risk of malicious accounts implanting Trojans during contract simulation execution, that is, it can effectively prevent the account that triggers the debugging of the smart contract from implanting Trojans, making IDE remote contract debugging possible, thereby providing the account with free and convenient contract simulation debugging functions.

[0089] In a possible implementation, a service container is further provided in the resource object, and the permission adjustment module 805 may include:

[0090] a startup command generating unit, configured to call the business container in the resource object to generate a startup command for the contract container according to the preset access permission; the startup command carries the preset access permission;

[0091] The contract debugging module 807 may include:

[0092] a command receiving unit, configured to send the start command to the contract container using the business container;

[0093] A contract debugging unit is configured to call the contract container to respond to the start command, parse the preset access permission from the start command, and use the contract container to run the first smart contract under the preset access permission.

[0094] In a possible implementation, the contract debugging module 807 may include:

[0095] A remote file directory mounting unit, configured to read a contract file directory in a remote file system through the network file system of the contract container, and mount the contract file directory into the contract container;

[0096] A contract file running unit is used to call the contract container and read the contract file corresponding to the first smart contract from the remote file system based on the contract file directory, and run the contract file in the contract container.

[0097] In a possible implementation, the apparatus may further include:

[0098] The storage space clearing module is used to clear the storage space corresponding to the contract file in the remote file system if the implantation of unsafe code is detected during the execution of the contract file.

[0099] In a possible implementation, the apparatus may further include:

[0100] a write request parsing module, configured to respond to a contract write request and parse the contract write request parameters to obtain a designated write directory, a second contract name, and a second account identifier that triggers the contract write request;

[0101] A write contract directory acquisition module is used to concatenate the second contract name and the second account identifier according to the preset contract directory format to obtain a write contract directory;

[0102] A contract writing execution module is configured to execute the contract writing request when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the contract writing directory matches the prefix of the specified writing directory.

[0103] In a possible implementation, the apparatus may further include:

[0104] A path conversion module, configured to convert the designated writing directory into a target writing directory if the designated writing directory is a relative path; the target writing directory is an absolute path;

[0105] The contract writing execution module is further configured to execute the contract writing request when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the contract writing directory matches the prefix of the target writing directory.

[0106] In one possible implementation, the contract execution module may include:

[0107] A contract directory mounting unit, configured to read a contract file directory in a remote file system through the network file system of the contract container, and mount the contract file directory into the contract container;

[0108] A contract writing execution unit is used to write the second smart contract into the contract file corresponding to the second contract name in the designated writing directory or the target writing directory through the network file system.

[0109] In a possible implementation, the contract debugging module 807 may further include:

[0110] An access suspension unit is configured to suspend the operation of the contract container when the contract container triggers access to the system resource.

[0111] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0112] Figure 9 This is a block diagram of an electronic device for a security protection method for Trojan horse implantation in smart contract processing based on an exemplary embodiment. The electronic device can be a terminal, and its internal structure diagram can be as shown in FIG. Figure 9As shown. The electronic device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a security protection method for Trojan horse implantation in smart contract processing is implemented. The display screen of the electronic device can be a liquid crystal display or an electronic ink display screen, and the input device of the electronic device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the electronic device housing, or an external keyboard, touchpad or mouse.

[0113] Those skilled in the art will understand that Figure 9 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 electronic device to which the solution of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0114] Figure 10 This is a block diagram of an electronic device for a security protection method for Trojan horse implantation in smart contract processing according to an exemplary embodiment. The electronic device may be a server, and its internal structure diagram may be as shown in FIG. Figure 10 As shown. The electronic device includes a processor, memory, and a network interface connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When executed by the processor, the computer program implements a security protection method for Trojan horse implantation in smart contract processing.

[0115] Those skilled in the art will understand that Figure 10 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 electronic device to which the solution of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0116] In an exemplary embodiment, an electronic device is also provided, comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a security protection method for Trojan horse implantation in smart contract processing as in an embodiment of the present application.

[0117] In an exemplary embodiment, a computer-readable storage medium is also provided. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the security protection method for preventing Trojan horse implantation in smart contract processing in the embodiments of the present application. The computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0118] In an exemplary embodiment, a computer program product containing instructions is also provided, which, when run on a computer, enables the computer to execute the security protection method for Trojan horse implantation in smart contract processing in the embodiment of the present application.

[0119] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, which 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 memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0120] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0121] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for securely processing smart contracts, characterized in that: Applied to a resource object running on a physical host, wherein the resource object is provided with a contract container; the method comprises: Upon receiving a contract remote debugging request, performing parameter parsing on the contract remote debugging request to obtain a first contract name and a first account identifier that triggers the contract remote debugging request; Concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory; If the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists, set the resource access permission for the contract remote debugging request to the preset access permission; Under the preset access permission, the contract container in the resource object is called to run the first smart contract to perform remote simulation debugging on the first smart contract.

2. The method according to claim 1, characterized in that The resource object is further provided with a business container, and the resource access rights for the contract remote debugging request are set to preset access rights, including: Calling the business container in the resource object to generate a startup command for the contract container according to the preset access permission; the startup command carries the preset access permission; The step of calling the contract container in the resource object to run the first smart contract under the preset access permission to perform remote simulation debugging on the first smart contract includes: Using the business container, sending the start command to the contract container; The contract container is called to respond to the start command, the preset access permission is parsed from the start command, and the first smart contract is run using the contract container under the preset access permission.

3. The method according to claim 1, characterized in that The calling the contract container in the resource object to run the first smart contract to perform remote simulation debugging on the first smart contract includes: Read the contract file directory in the remote file system through the network file system of the contract container, and mount the contract file directory into the contract container; The contract container is called and the contract file corresponding to the first smart contract is read from the remote file system based on the contract file directory, and the contract file is run in the contract container.

4. The method according to claim 3, characterized in that The method further comprises: During the execution of the contract file, if the implantation of unsafe code is detected, the storage space corresponding to the contract file in the remote file system is cleared.

5. The method according to claim 1, wherein The method further comprises: In response to the contract write request, performing parameter parsing on the contract write request to obtain a designated write directory, a second contract name, and a second account identifier that triggered the contract write request; Concatenate the second contract name and the second account identifier according to the preset contract directory format to obtain a written contract directory; If the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the write contract directory matches the prefix of the specified write directory, execute the write contract request.

6. The method according to claim 5, characterized in that When the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account, and the contract writing directory matches the prefix of the specified writing directory, before executing the step of executing the contract writing request, the method further includes: In the case where the designated writing directory is a relative path, converting the designated writing directory into a target writing directory; the target writing directory is an absolute path; The step of executing the contract write request when the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the contract write directory matches the prefix of the specified write directory includes: If the second smart contract corresponding to the second contract name belongs to the smart contract identified by the second account and the write contract directory matches the prefix of the target write directory, execute the write contract request.

7. The method according to claim 5, characterized in that The executing the contract writing request includes: Read the contract file directory in the remote file system through the network file system of the contract container, and mount the contract file directory into the contract container; The second smart contract is written into the contract file corresponding to the second contract name in the contract writing directory or the target writing directory through the network file system.

8. The method according to claim 1, characterized in that The calling of the contract container to run the first smart contract under the preset access rights includes: When the contract container triggers access to system resources on the physical host, the operation of the contract container is suspended.

9. A secure processing device for smart contracts, characterized in that: Applied to a resource object running on a physical host, wherein the resource object is provided with a contract container; the device comprises: A debugging request parsing module is used to parse parameters of a contract remote debugging request upon receiving the contract remote debugging request, and obtain the first contract name and the first account identifier that triggers the contract remote debugging request; a target contract directory acquisition module, configured to concatenate the first contract name and the first account identifier according to a preset contract directory format to obtain a target contract directory; a permission adjustment module, configured to set the resource access permission for the contract remote debugging request to a preset access permission if the first smart contract corresponding to the first contract name belongs to the smart contract identified by the first account and the target contract directory exists; A contract debugging module is used to call the contract container in the resource object to run the first smart contract under the preset access permission to perform remote simulation debugging on the first smart contract.

10. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the secure processing method of the smart contract as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the secure processing method for smart contracts as described in any one of claims 1 to 8.

12. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, cause the computer to execute the secure processing method for a smart contract as claimed in any one of claims 1 to 8.

Images