Smart contract test method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a smart contract test method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving a to-be-tested target smart contract sent by a contract test container in a cloud server; the method comprises the following steps: selecting a target sub-container for running a target smart contract from a plurality of sub-containers contained in a contract running container in a cloud server, testing the target smart contract in the target sub-container, and then testing the target smart contract in the target sub-container. And obtaining a target data packet sent by the target sub-container according to the target smart contract, and discarding the target data packet when the destination network address of the target data packet is not matched with the network address of the contract test container. According to the technical scheme, the testing flexibility and safety can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and more specifically, to a testing method and device for a smart contract, an electronic device, a storage medium, and a program product. Background Art

[0002] A smart contract is a computer protocol designed to disseminate, verify or execute contracts in an information-based manner, allowing trusted transactions without a third party. These transactions are viewable and irreversible, and all users on the blockchain can see blockchain-based smart contracts.

[0003] In scenarios such as smart contract development and debugging, it is necessary to test the smart contract to determine whether the smart contract meets the requirements. In related technologies, a local environment (i.e., a real host) is usually used to run the smart contract to test the smart contract. However, in this method, the test environment of the smart contract needs to be pre-deployed in the local environment, which increases the complexity of smart contract testing and reduces the flexibility of smart contract testing. Summary of the invention

[0004] The embodiments of the present application provide a method and device for testing a smart contract, an electronic device, a storage medium, and a program product, which can improve the testing flexibility and security of smart contracts.

[0005] According to one aspect of an embodiment of the present application, a method for testing a smart contract is provided, the method comprising:

[0006] Receive the target smart contract to be tested sent by the contract test container in the cloud server;

[0007] Selecting a target sub-container for running the target smart contract from a plurality of sub-containers included in the contract running container in the cloud server, and testing the target smart contract in the target sub-container;

[0008] In the process of testing the target smart contract, obtaining a target data packet sent by the target sub-container according to the target smart contract;

[0009] In response to the destination network address of the target data packet not matching the network address of the contract test container, the target data packet is discarded.

[0010] According to one aspect of an embodiment of the present application, a method for testing a smart contract is provided, the method comprising:

[0011] Receive a contract test request sent by the requester, and obtain the target smart contract to be tested according to the contract test request;

[0012] The target smart contract is sent to the contract running container in the cloud server, so that the contract running container selects a target sub-container for running the target smart contract from the multiple sub-containers contained therein, and tests the target smart contract in the target sub-container. During the testing of the target smart contract, if a target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0013] According to one aspect of an embodiment of the present application, a testing device for a smart contract is provided, which is configured in a cloud server, and the device includes:

[0014] A receiving module, configured to receive a target smart contract to be tested sent by a contract test container in a cloud server;

[0015] A testing module is configured to select a target subcontainer for running the target smart contract from a plurality of subcontainers included in the contract running container in the cloud server, and test the target smart contract in the target subcontainer;

[0016] an acquisition module, configured to acquire a target data packet sent by the target sub-container according to the target smart contract during the process of testing the target smart contract;

[0017] The discarding module is configured to discard the target data packet in response to the destination network address of the target data packet not matching the network address of the contract test container.

[0018] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the network address of each sub-container is different from the network address of the contract test container, the device also includes a comparison module, configured to: compare the destination network address with the network addresses of other sub-containers among the multiple sub-containers except the target sub-container; if the destination network address matches the network addresses of the other sub-containers, it is determined that the destination network address does not match the network address of the contract test container.

[0019] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a sending module, configured to send the target data packet to the contract test container in response to the destination network address matching the network address of the contract test container; wherein the target data packet includes test data of the target smart contract.

[0020] In an exemplary embodiment, the sending module is configured to: obtain the transmission protocol of the target data packet in response to the destination network address matching the network address of the contract test container; compare the transmission protocol of the target data packet with the specified transmission protocol; if the transmission protocol of the target data packet matches the specified transmission protocol, send the target data packet to the contract test container.

[0021] In an exemplary embodiment, based on the aforementioned scheme, the sending module is configured as follows: if the transmission protocol of the target data packet matches the specified transmission protocol, the destination port of the target data packet is obtained; the destination port is compared with the specified port; wherein the specified port is a port among multiple ports allocated to the contract test container and matching the specified transmission protocol; if the destination port matches the specified port, the target data packet is sent to the specified port.

[0022] In an exemplary embodiment, based on the aforementioned scheme, under the condition that a virtual bridge is included in the contract execution container and each sub-container is connected to the virtual bridge, the discard module is configured as follows: after receiving the target data packet through the connection between the virtual bridge and the target sub-container, the destination network address of the target data packet is compared with the network address of the contract execution container to obtain a comparison result; a target transmission rule that matches the comparison result is selected from multiple transmission rules pre-configured by the virtual bridge; if it is determined according to the target transmission rule that the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0023] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the contract execution container and the contract test container belong to the same container group, and the contract execution container and the contract test container share the network address of the container group, the discard module is configured as: if the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, select the first transmission rule from the multiple transmission rules as the target transmission rule; compare the destination network address of the target data packet with the isolated network address included in the first transmission rule; wherein the isolated network address includes all network addresses; if the destination network address of the target data packet matches the isolated network address in the first transmission rule, discard the target data packet.

[0024] In an exemplary embodiment, based on the aforementioned scheme, the sending module is configured as follows: if the comparison result indicates that the destination network address of the target data packet matches the network address of the container group, then select a second transmission rule from the multiple transmission rules as the target transmission rule; obtain a specified transmission protocol and a specified port from the second transmission rule; wherein the specified port is a port among multiple ports allocated to the contract test container and matching the specified transmission protocol; compare the transmission protocol of the target data packet with the specified transmission protocol, and compare the destination port of the target data packet with the designated port; if the transmission protocol of the target data packet matches the specified transmission protocol, and the destination port matches the designated port, then transmit the target data packet to the designated port through the virtual bridge.

[0025] In an exemplary embodiment, based on the aforementioned scheme, the test module is configured to: search for a sub-container that is not currently running a smart contract from a plurality of sub-containers contained in the contract execution container; if no sub-container that is not currently running a smart contract is found, create a sub-container in the contract execution container, and connect the created sub-container to the virtual gateway; obtain an unoccupied network address from the subnet corresponding to the virtual gateway, and assign the obtained network address to the created sub-container; and use the created sub-container as the target sub-container.

[0026] In an exemplary embodiment, based on the aforementioned scheme, the discarding module is further configured to: receive a data packet to be forwarded sent by any container, and match the destination network address of the data packet to be forwarded with the network address of the target sub-container; if the destination network address of the data packet to be forwarded matches the network address of the target sub-container, discard the data packet to be forwarded.

[0027] According to one aspect of an embodiment of the present application, a testing device for a smart contract is provided, which is configured in a cloud server, and the device includes:

[0028] An acquisition module is configured to receive a contract test request sent by a requester, and acquire a target smart contract to be tested according to the contract test request;

[0029] A sending module is configured to send the target smart contract to a contract running container in a cloud server, so that the contract running container selects a target sub-container for running the target smart contract from a plurality of sub-containers contained therein, and tests the target smart contract in the target sub-container. During the process of testing the target smart contract, if a target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0030] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the contract test container and the contract execution container are deployed in the same container group, the sending module is: storing the target smart contract in the shared volume corresponding to the container group, so that the contract execution container obtains the target smart contract from the shared volume.

[0031] According to one aspect of an embodiment of the present application, there is provided an electronic device, including:

[0032] one or more processors;

[0033] A memory for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the smart contract testing method as described above.

[0034] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor of an electronic device, the electronic device implements the testing method of the smart contract as described above.

[0035] According to one aspect of an embodiment of the present application, a computer program product is provided, including a computer program, which implements the testing method of the smart contract as described above when executed by a processor.

[0036] In the technical solution provided in the embodiment of the present application, after receiving the target smart contract to be tested sent by the contract test container in the cloud server, the target sub-container for running the target smart contract is first selected from the multiple sub-containers contained in the contract running container in the cloud server, and the target smart contract is tested in the target sub-container. Then, in the process of testing the target smart contract, the target sub-container is obtained according to the target smart contract. The target data packet sent by the target sub-container is discarded in response to the mismatch between the destination network address of the target data packet and the network address of the contract test container; on the one hand, the smart contract is tested by the contract test container and the contract running container in the cloud server, which improves the test flexibility, and the acquisition of the smart contract and the test of the smart contract are executed through different containers, which improves the test efficiency; on the other hand, the smart contract is tested by the sub-container in the contract running container, which is not only convenient for restricting the network of the sub-container, but also can improve the test parallelism by expanding the sub-container, and by discarding the data packet sent by the sub-container whose destination network address is not the network address of the contract test container, the network of the sub-container is restricted, thereby ensuring that the test data can be transmitted to the contract test container, avoiding the situation where the smart contract attacks other services in the network during the test, and improving the test security.

[0037] 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

[0038] Figure 1 It is a schematic diagram of the structure of the blockchain network;

[0039] Figure 2 It is a schematic diagram of the connection relationship between blocks in the blockchain;

[0040] Figure 3 is a schematic diagram of an implementation environment shown in an exemplary embodiment of the present application;

[0041] Figure 4 is a flow chart of a method for testing a smart contract shown in an exemplary embodiment of the present application;

[0042] Figure 5 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0043] Figure 6 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0044] Figure 7 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0045] Figure 8 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0046] Fig. 9 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0047] Fig.10 is a data transmission flow chart of a rule chain shown in another exemplary embodiment of the present application;

[0048] Fig.11 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0049] Fig.12 is a schematic block diagram of data packet transmission shown in another exemplary embodiment of the present application;

[0050] Fig.13 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0051] Fig.14 is a schematic block diagram of data packet transmission shown in another exemplary embodiment of the present application;

[0052] Fig.15 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0053] Fig.16 is a schematic block diagram of a container group shown in another exemplary embodiment of the present application;

[0054] Fig.17 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0055] Fig.18 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0056] Fig.19 is a flow chart of a method for testing a smart contract shown in another exemplary embodiment of the present application;

[0057] Fig. 20 is a schematic diagram of an application environment shown in an exemplary embodiment of the present application;

[0058] Fig.21 is an interaction diagram of a smart contract testing method shown in an exemplary embodiment of the present application;

[0059] Fig. 22 It is a structural schematic diagram of a testing device for a smart contract shown in an exemplary embodiment of the present application;

[0060] Fig.23 is a structural schematic diagram of a testing device for a smart contract shown in another exemplary embodiment of the present application;

[0061] Fig.24 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0062] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0063] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0064] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0065] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0066] The technical solution of the embodiment of the present application can be applied to the field of blockchain technology. Before introducing the technical solution of the embodiment of the present application, a brief introduction to blockchain technology is first given.

[0067] Blockchain: A distributed ledger in the field of information technology. It is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks (i.e. 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. Consensus mechanisms include but are not limited to POW (Proof of Work), POS (Proof of Stake), DPOS (Delegated Proof-of-Stake Consensus), PBFT (Practical Byzantine Fault Tolerance), etc.

[0068] As mentioned above, blockchain is essentially a decentralized database, and blockchain is maintained by blockchain nodes in the blockchain network. Nodes are the smallest unit involved in blockchain maintenance and are the deployment and operation units of blockchain node programs. For example, see Figure 1 ,exist Figure 1 The blockchain network 10 shown may include multiple blockchain nodes 101. Each blockchain node 101 can receive input information when performing normal work, and maintain the shared data in the blockchain network based on the received input information. In order to ensure the information intercommunication in the blockchain network, there can be an information connection between each blockchain node in the blockchain network, and information can be transmitted between blockchain nodes through the above information connection. For example, when any blockchain node in the blockchain network receives input information, other blockchain nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as shared data, so that the data stored on all blockchain nodes in the blockchain network are consistent. Since the block is consensus-based on the blockchain nodes, it has the characteristics of being tamper-proof, traceable, and jointly maintained.

[0069] Each blockchain node in the blockchain network has a corresponding node identifier, and each blockchain node in the blockchain network can store the node identifiers of other blockchain nodes, so that the generated blocks can be broadcast to other blockchain nodes in the blockchain network according to the node identifiers of other blockchain nodes. A node identifier list can be maintained in each blockchain node, and the node name and node identifier are stored in the node identifier list accordingly. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the blockchain node.

[0070] Each node in the blockchain network stores the same blockchain. Figure 2 As shown, the blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version numbers, timestamps, and difficulty values, and the block body stores input information. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores input information feature values ​​of the current block, feature values ​​of the block header of the parent block, version numbers, timestamps, and difficulty values, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, thereby ensuring the security of the input information in the block.

[0071] It is understandable that each node in the blockchain network can be a server or a terminal device. Among them, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing (Cloud Computing), cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and basic cloud computing services such as big data and intelligent platforms. Among them, the terminal device can be a smart phone, a tablet computer, a laptop, a desktop computer, a smart speaker, a smart watch, a terminal used in a car (on-board terminal), an aircraft, etc., but is not limited to this. Each node can be directly or indirectly connected by wired or wireless communication, and this application is not limited here.

[0072] The technical solution of the embodiment of the present application can be applied to blockchain technology. The technical solution of the embodiment of the present application is described in detail below:

[0073] In the related art, in order to test smart contracts, a local environment (i.e., a real host) is usually used to run smart contracts to test the smart contracts. However, in this method, it is necessary to pre-deploy the test environment of the smart contract in the local environment, etc., which increases the test complexity of the smart contract and reduces the test flexibility of the smart contract. Based on this, the embodiments of the present application provide a test method and device for a smart contract, an electronic device, a storage medium, and a program product, which can improve the test flexibility and security of the smart contract.

[0074] See also Figure 3 , Figure 3 3 is a schematic diagram of an implementation environment involved in the present application, the implementation environment includes a cloud server 310, a contract test container 311 and a contract running container 312 are deployed in the cloud server 310, and the contract running container 312 includes multiple sub-containers 313; wherein the contract test container 311 and the contract running container 312 can be deployed in different cloud servers 310, and can also be deployed in the same cloud server 310. Figure 3 The number of cloud servers 310, contract test containers 311 and contract running containers 312 is merely illustrative, and any number of cloud servers 310, contract test containers 311 and contract running containers 312 may be provided according to actual needs.

[0075] It should be noted that cloud servers are used to provide cloud computing services. Cloud computing is a computing model that distributes computing tasks on a resource pool consisting of a large number of computers, allowing various application systems to obtain computing power, storage space and information services as needed. The network that provides resources is called a "cloud". From the user's perspective, the resources in the "cloud" are infinitely expandable and can be obtained at any time, used on demand, expanded at any time, and paid for by use.

[0076] As a provider of basic cloud computing capabilities, a cloud computing resource pool (referred to as a cloud platform, generally referred to as an IaaS (Infrastructure as a Service) platform) will be established, and various types of virtual resources will be deployed in the resource pool for external customers to choose to use. The cloud computing resource pool mainly includes: computing devices (virtualized machines, including operating systems), storage devices, and network devices.

[0077] According to the logical function division, the PaaS (Platform as a Service) layer can be deployed on the IaaS (Infrastructure as a Service) layer, and the SaaS (Software as a Service) layer can be deployed on the PaaS layer. SaaS can also be deployed directly on IaaS. PaaS is a platform for software operation, such as databases, web containers, etc. SaaS is a variety of business software, such as web portals, SMS mass senders, etc. Generally speaking, SaaS and PaaS are upper layers relative to IaaS.

[0078] In an exemplary embodiment, the smart contract testing method provided by the embodiment of the present application can be jointly executed by a contract test container 311 and a contract running container 312. Correspondingly, after the contract test container 311 is introduced to the contract test request from the requester, it obtains the target smart contract to be tested according to the contract test request, and sends the target smart contract to the contract running container 312; the contract running container 312 selects a target sub-container for running the target smart contract from the multiple sub-containers 313 contained in it, and tests the target smart contract in the target sub-container. In the process of testing the target smart contract, the target data packet sent by the target sub-container according to the target smart contract is obtained, and the target data packet is discarded because the destination network address of the target data packet does not match the network address of the contract test container. On the one hand, by testing smart contracts through the contract test container and contract running container in the cloud server, there is no need to deploy the test environment in the local environment, which improves the test flexibility, and the acquisition of smart contracts and the testing of smart contracts are executed through different containers, which improves the test efficiency; on the other hand, by testing smart contracts through sub-containers in the contract running container, it is not only convenient to restrict the network of the sub-container, but also to improve the test parallelism by expanding the sub-container, and by discarding data packets sent by the sub-container whose destination network address is not the network address of the contract test container, the network of the sub-container can be restricted. This ensures that the test data can be transmitted to the contract test container, thereby avoiding the situation where the smart contract attacks other services in the network during the test, thereby improving the test security.

[0079] It should be noted that the above-mentioned smart contract testing method can be applied to various scenarios where smart contracts need to be tested, for example, it can be applied to smart contract testing scenarios, smart contract debugging scenarios, etc. This application involves user-related data such as smart contracts. When the method of this application is applied to specific products or technologies, it is all with the permission or consent of the user, and the extraction, use and processing of relevant data comply with local security standards and local laws and regulations.

[0080] See also Figure 4 , Figure 4 is a flowchart of a smart contract testing method shown in an exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0081] like Figure 4 As shown, in an exemplary embodiment, the testing method of the smart contract may include: Step S410-Step S440, which are described in detail as follows:

[0082] Step S410, receiving the target smart contract to be tested sent by the contract test container in the cloud server.

[0083] It should be noted that the target smart contract refers to the smart contract currently to be tested.

[0084] The contract test container refers to a container used to provide smart contract testing services, which can obtain the target smart contract. Optionally, the contract test container can receive a contract test request and obtain the target smart contract based on the contract test request, wherein the contract test request may include the target smart contract, or the identification information of the target smart contract. The contract test request can be initiated by the requester (for example, the developer of the smart contract, etc.) in the contract test container. Among them, the contract test container is deployed in the cloud server, that is, the contract test container is a container created using cloud resources; the contract test container can be a container created based on kubernetes (an open source containerized application for managing multiple hosts in a cloud platform), or a container created based on other methods.

[0085] It should be understood that the test of a smart contract refers to running the smart contract, obtaining the running result, and obtaining the test result based on the running result. In order to improve the test efficiency, the acquisition of the smart contract and the running of the smart contract are executed through different containers. Therefore, after the contract test container obtains the target smart contract, the target smart contract can be sent to the contract running container, so that the contract running container runs the target smart contract to test the target smart contract.

[0086] Optionally, in order to facilitate smart contract developers to test smart contracts, smart contract testing services are usually deployed in smart contract development services. Therefore, the contract testing container can also be a contract development container that can provide smart contract testing services, wherein smart contract development services are deployed in the contract development container. For example, the contract development container can deploy an IDE (Integrated Development Environment) for smart contracts to facilitate smart contract developers to develop and test smart contracts in the contract development container.

[0087] Step S420, select a target sub-container for running the target smart contract from multiple sub-containers contained in the contract execution container in the cloud server, and test the target smart contract in the target sub-container.

[0088] The contract running container refers to a container used to run smart contracts to test smart contracts. The contract running container is also deployed in the cloud server, that is, the contract running container is a container created using cloud resources. Among them, the contract running container and the contract test container can be deployed in different cloud servers; or, in order to improve the data transmission efficiency between the contract running container and the contract test container, the contract running container and the contract test container can be deployed in the same cloud server. Under the condition that the contract running container and the contract test container are deployed on the same cloud server, the contract running container and the contract test container can be deployed in different container groups, or, in order to improve the data transmission efficiency between the contract running container and the contract test container, the contract running container and the contract test container can be deployed in the same container group. It should be understood that the container group (Pod) is the smallest deployment unit, and a container group contains one or more containers, and one or more containers in a container group share a network namespace. The contract running container can be a container created based on kubernetes (an open source containerized application for managing multiple hosts in a cloud platform), or it can be a container created based on other methods.

[0089] In order to test multiple smart contracts at the same time, the contract running container contains multiple sub-containers, each of which can be used to run smart contracts to test smart contracts. It should be noted that the "sub" in the sub-container is only used to indicate that it is a container deployed in the contract running container, and is not used to limit the form of the container. Optionally, a sub-container can be created in the contract running container based on the DIND technology. DIND refers to Docker-in-Docker, which is a way to run a container in a container.

[0090] After obtaining the target smart contract, a target sub-container for running the target smart contract can be selected from the contract running container, so as to run the target smart contract based on the target sub-container to test the target smart contract.

[0091] Among them, the specific method of selecting the target sub-container can be flexibly set according to actual needs. Optionally, an idle sub-container can be randomly selected from multiple sub-containers contained in the contract running container as the target sub-container, or a sub-container with the most cloud resources can be selected from the idle sub-containers as the target sub-container.

[0092] Step S430, during the process of testing the target smart contract, obtain the target data packet sent by the target sub-container according to the target smart contract.

[0093] During the operation of the target smart contract, the target sub-container needs to send the test data of the target smart contract (for example, at least one of the operation results, operation logs, world status, events occurring during the operation, etc. of the target smart contract) to the contract test container. Therefore, during the testing of the target smart contract, the target sub-container will send a data packet (i.e., a target data packet) outward according to the target smart contract.

[0094] In step S440 , in response to the destination network address of the target data packet not matching the network address of the contract test container, the target data packet is discarded.

[0095] A network address, namely an IP (Internet Protocol) address, is a logical address of a node on the Internet. The node can be addressed based on the network address.

[0096] After obtaining the target data packet sent by the target sub-container, the destination network address of the target data packet can be extracted from the target data packet, and it can be determined whether the destination network address of the target data packet matches the network address of the contract test container. If they do not match, it indicates that the target data packet is not the test data sent to the contract test container, and its purpose may be to perform network sniffing and attack other services in the network. Therefore, the target data packet is discarded, thereby improving the security of the cloud service during the testing of smart contracts in the cloud service.

[0097] exist Figure 4In the illustrated embodiment, on the one hand, the smart contract is tested through the contract test container and the contract running container in the cloud server, which improves the test flexibility, and the acquisition of the smart contract and the test of the smart contract are executed through different containers, which improves the test efficiency; on the other hand, the smart contract is tested through the sub-container in the contract running container, which is not only convenient for restricting the network of the sub-container, but also can improve the test parallelism by expanding the sub-container, and by discarding the data packets sent by the sub-container whose destination network address is not the network address of the contract test container, the network of the sub-container is restricted, thereby ensuring that the test data can be transmitted to the contract test container, avoiding the situation where the smart contract attacks other services in the network during the test, thereby improving the test security.

[0098] In an exemplary embodiment, see Figure 5 , Figure 5 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0099] like Figure 5 As shown, under the condition that the network address of each sub-container is different from the network address of the contract test container, the smart contract testing method may include: steps S410 to S430, steps S510 to S520, and step S440; wherein, the detailed description of steps S510 to S520 is as follows:

[0100] Step S510: compare the destination network address with the network addresses of other sub-containers in the plurality of sub-containers except the target sub-container.

[0101] It should be noted that since the sub-container is deployed in the contract running container, the network address of the sub-container is different from the network address of the contract test container.

[0102] In order to prevent the target smart contract from performing network sniffing on other sub-containers in the contract running container except the target sub-container during the test of the target smart contract, thereby attacking the services in other sub-containers, the destination network address of the target data packet can be compared with the container addresses of other sub-containers.

[0103] Step S520: If the destination network address matches the network addresses of other sub-containers, it is determined that the destination network address does not match the network address of the contract test container.

[0104] Since the network address of the sub-container is different from the network address of the contract test container, if the destination network address of the target data packet matches the network address of other sub-containers, it means that the network address of the target data packet does not match the network address of the contract test container, and the target data packet is discarded, thereby isolating the target sub-container from the other sub-containers to prevent the target smart contract from attacking the business in other sub-containers during the testing of the target smart contract.

[0105] It should be noted that Figure 5 The specific implementation details of steps S410 to S440 shown in FIG. Figure 4 Steps S410 to S440 shown are not repeated here.

[0106] exist Figure 5 In the illustrated embodiment, under the condition that the destination network address of the target data packet matches the network addresses of other sub-containers except the target sub-container among multiple sub-containers, the target data packet is discarded, so that the target sub-container is isolated from the other sub-container networks, thereby avoiding the situation where the smart contract attacks the services in other sub-containers during the test, thereby improving network security.

[0107] In an exemplary embodiment, see Figure 6 , Figure 6 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0108] like Figure 6 As shown, the testing method of the smart contract may include: steps S410 to S440, and step S610; wherein, the detailed description of step S610 is as follows:

[0109] Step S610, in response to the destination network address matching the network address of the contract test container, sending the target data packet to the contract test container; wherein the target data packet includes the test data of the target smart contract.

[0110] It should be noted that after testing the target smart contract, test data will be obtained. The target sub-container needs to send the test data to the contract test container so that the contract test container outputs the test data to the requester, so that the requester can debug the target smart contract according to the test data.

[0111] Therefore, if the destination network address of the target data packet matches the network address of the contract test container, it indicates that the target data packet contains the test data of the target smart contract, and therefore, the target data packet can be sent to the contract test container.

[0112] It should be noted that Figure 6 The specific implementation details of steps S410 to S440 shown in FIG. Figure 4 Steps S410 to S440 shown are not repeated here.

[0113] exist Figure 6 In the illustrated embodiment, if the destination network address of the target data packet matches the network address of the contract test container, the target data packet is sent to the contract test container, and the target data packet includes the test data of the target smart contract, so that the contract test container obtains the test data of the target smart contract and sends the test data to the requester.

[0114] In an exemplary embodiment, see Figure 7 , Figure 7 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0115] like Figure 7 As shown, the testing method of the smart contract may include: steps S410 to S440, and steps S710 to S730; wherein, the detailed description of steps S710 to S730 is as follows:

[0116] In step S710, in response to the destination network address matching the network address of the contract test container, a transmission protocol of the target data packet is obtained.

[0117] Under the condition that the destination network address of the target data packet matches the network address of the contract test container, in order to prevent the target smart contract from attacking the contract test container, the transmission protocol of the target data packet can be obtained first.

[0118] Among them, the destination network address of the target data packet matches the network address of the contract test container means that the destination network address of the target data packet is the same as the network address of the contract test container. For example, assuming that the network address of the contract test container is 10.10.0.170, if the destination network address of the target data packet is 10.10.0.170, then the destination network address of the target data packet matches the network address of the contract test container; if the destination network address of the target data packet is 10.10.0.172, then the destination network address of the target data packet does not match the network address of the contract test container.

[0119] The transport protocol refers to the communication protocol of the transport layer, for example, TCP (Transmission Control Protocol), UDP (User Datagram Protocol), etc. The five-tuple information of the data packet includes the source IP address, source port, destination IP address, destination port and transport protocol. Therefore, in an optional example, the transport protocol of the target data packet can be obtained from the five-tuple information of the target data packet.

[0120] Step S720, comparing the transmission protocol of the target data packet with the specified transmission protocol.

[0121] It should be noted that the specified transmission protocol is a pre-set protocol for transmitting test data between the target sub-container and the contract test sub-container. Among them, the specific protocol of the specified transmission protocol can be flexibly set according to actual needs. In an optional example, the real blockchain network usually includes a contract management module, and each blockchain node contains a container for deploying smart contracts. Therefore, in order to simulate the communication of smart contracts in the blockchain, the specified transmission protocol can be a protocol for data transmission between the contract management module in the blockchain network and the container in the blockchain node. For example, the data transmission between the contract management module and the container in the blockchain node is usually based on the TCP protocol. Therefore, the specified transmission protocol can be the TCP protocol.

[0122] In order to determine whether the target data packet contains the test data, the transmission protocol of the target data packet may be compared with the specified transmission protocol.

[0123] Step S730: If the transmission protocol of the target data packet matches the specified transmission protocol, the target data packet is sent to the contract test container.

[0124] If the transmission protocol of the target data packet matches the specified transmission protocol, it indicates that the target data packet contains test data, and therefore, the target data packet can be sent to the contract test container.

[0125] Optionally, if the transmission protocol of the target data packet does not match the specified transmission protocol, it indicates that the target data packet does not contain test data. In order to avoid the target smart contract attacking the contract test container, the target data packet can be discarded.

[0126] It should be noted that Figure 7 The specific implementation details of steps S410 to S440 shown in FIG. Figure 4 Steps S410 to S440 shown are not repeated here.

[0127] exist Figure 7In the illustrated embodiment, by limiting the transmission protocol between the sub-container and the contract test container, it is possible to avoid the situation where the smart contract attacks the service in the contract test container during the test process, thereby improving network security.

[0128] In an exemplary embodiment, see Figure 8 , Figure 8 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0129] like Figure 8 As shown, the testing method of the smart contract may include: steps S410 to S440, steps S710 to S720, and steps S810 to S830; wherein, the detailed description of steps S810 to S830 is as follows:

[0130] Step S810: If the transmission protocol of the target data packet matches the specified transmission protocol, the destination port of the target data packet is obtained.

[0131] Under the condition that the destination network address of the target data packet matches the network address of the contract test container, and the transmission protocol of the target data packet matches the specified transmission protocol, in order to prevent the target smart contract from attacking the contract test container, the destination port of the target data packet can be obtained first.

[0132] Step S820, comparing the destination port with the designated port; wherein the designated port is a port among a plurality of ports allocated to the contract test container and matching the designated transmission protocol.

[0133] It should be noted that for the contract test container, multiple ports are allocated for transmitting data packets of the specified transmission protocol, and different ports are used to transmit data packets corresponding to different services. Among them, the designated port refers to the port used to transmit test data among these multiple ports. The specific port of the designated port can be flexibly set according to actual needs. In an optional example, in order to truly simulate the communication of smart contracts in the blockchain, the designated port can be the port used for data transmission between the contract management module in the blockchain network and the container in the blockchain node. For example, the contract management module and the container in the blockchain node usually transmit data based on RPC (Remote Procedure Call), so the designated port can be an RPC port.

[0134] In order to determine whether the target data packet contains the test data, the destination of the target data packet may be compared with the designated port.

[0135] Step S830: If the destination port matches the designated port, the target data packet is sent to the designated port.

[0136] If the destination port of the target data packet matches the specified port, it indicates that the target data packet contains test data, and therefore, the target data packet can be sent to the contract test container.

[0137] Optionally, if the destination port of the target data packet does not match the specified port, it indicates that the target data packet does not contain test data. In order to prevent the target smart contract from attacking the contract test container, the target data packet can be discarded.

[0138] Among them, the port is usually identified by the port number. Therefore, in an optional example, the destination port matches the designated port may mean that the port number of the destination port is the same as the port number of the designated port, and the destination port does not match the designated port may mean that the port number of the destination port is different from the port number of the designated port. For example, assuming that the port number of the designated port is 160, if the port number of the destination port is 160, the destination port matches the designated port; if the port number of the destination port is 168, the destination port does not match the designated port.

[0139] It should be noted that Figure 8 The specific implementation details of steps S410 to S440 shown in FIG. Figure 4 Steps S410 to S440 are shown. Figure 8 The specific implementation details of steps S710 to S720 shown in FIG. Figure 7 Steps S710 to S720 shown are not repeated here.

[0140] exist Figure 8 In the illustrated embodiment, by limiting the transmission protocol and port between the sub-container and the contract test container, it is possible to avoid the situation where the smart contract attacks the service in the contract test container during the test process, thereby improving network security.

[0141] In an exemplary embodiment, see Fig. 9 , Fig. 9 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0142] like Fig. 9As shown, under the condition that the contract running container includes a virtual bridge and each sub-container is connected to the virtual bridge, the testing method of the smart contract may include: steps S410 to S430, and steps S910 to S920; wherein, the detailed description of steps S910 to S920 is as follows:

[0143] Step S910, after receiving the target data packet through the connection between the virtual bridge and the target sub-container, the destination network address of the target data packet is compared with the network address of the contract running container to obtain a comparison result.

[0144] In order to control the network of multiple sub-containers contained in the contract running container, a virtual bridge can be deployed in the contract running container, and each sub-container is connected to the virtual bridge. The virtual bridge is used to assign network addresses to sub-containers and control the communication of sub-containers, wherein data packets transmitted between sub-containers and data packets transmitted between sub-containers and containers outside the contract running container need to be forwarded through the virtual bridge, that is, an intranet containing multiple sub-containers is constructed through the virtual bridge. Optionally, the virtual gateway can be created by the docker deamon module in the contract running container when the contract running container is started, which is used to assign network addresses to sub-containers and control the communication of sub-containers. Among them, the docker deamon module is the daemon process of the container, and its main functions include image management, image building, identity authentication, security, core network and orchestration.

[0145] In the virtual gateway, different transmission rules are usually configured for filtering data packets according to whether it is local communication (that is, whether the destination address is the network address of the contract running container). Optionally, the specific method of configuring the transmission rules can be flexibly set according to actual needs. In an example, the transmission rules can be configured in the virtual gateway based on the netfilter / iptables technology, where netfilter / iptables (abbreviated as iptables) is a technology that constitutes a packet filtering firewall. iptables is a user-mode command line tool, and netfilter is a kernel module that implements packet filtering. Netfilter can be controlled based on the iptables command line tool to meet specific network filtering requirements. Netfilter contains five chains, namely INPUT chain, OUTPUT chain, FORWARD chain, PREROUTING chain, and POSTROUTING chain; among them, see Fig.10As shown in the figure, the PREROUTING chain is used to filter data packets after entering the network protocol stack but before routing decision is made; the INPUT chain is used to filter data packets sent to the local after routing decision; the FORWARD chain is used to filter data packets not sent to the local after routing decision; the OUTPUT chain is used to receive data packets sent by local services and filter them before routing decision is made; the POSTROUTING chain is used to filter data packets after routing decision.

[0146] Therefore, after the target sub-container generates a target data packet, the target data packet can be sent to the virtual gateway for forwarding through the connection between the target sub-container and the virtual gateway. After receiving the target data packet, the virtual gateway compares the destination network address of the target data packet with the network address of the contract running container to select the corresponding transmission rule based on the comparison result.

[0147] Step S920, selecting a target transmission rule that matches the comparison result from the multiple transmission rules pre-configured by the virtual bridge, and if it is determined according to the target transmission rule that the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0148] The target transmission rule stipulates that the data packets whose corresponding destination network addresses do not match the network address of the contract test container are discarded. According to the target transmission rule, it can be determined whether the destination network address of the target data packet matches the network address of the contract test container. If they do not match, the target data packet is discarded.

[0149] It should be noted that Fig. 9 The specific implementation details of steps S410 to S430 shown in FIG. Figure 4 Steps S410 to S430 shown are not repeated here.

[0150] exist Fig. 9 In the illustrated embodiment, by configuring transmission rules in the virtual gateway of the contract execution container, network restrictions on the sub-container are implemented, thereby improving network security.

[0151] In an exemplary embodiment, see Fig.11 , Fig.11 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0152] like Fig.11As shown, under the condition that the contract running container and the contract test container belong to the same container group, and the contract running container and the contract test container share the network address of the container group, the smart contract testing method may include: steps S410 to S430, step S910, and steps S1110 to S1130; wherein, the detailed description of steps S1110 to S1130 is as follows:

[0153] Step S1110: If the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, a first transmission rule is selected from the plurality of transmission rules as the target transmission rule.

[0154] The first transmission rule refers to a transmission rule corresponding to a data packet whose destination network address does not match the network address of the container group, that is, a transmission rule corresponding to a data packet that is not transmitted locally.

[0155] Under the condition that the contract running container and the contract test container belong to the same container group, since one or more containers in a container group share a network namespace, the contract running container and the contract test container share the network address of the container group, that is, the network address of the contract running container and the contract test container are the same. In other words, comparing the destination network address of the target data packet with the network address of the contract running container is equivalent to comparing the destination network address of the target data packet with the network address of the container group to which the contract running container belongs (that is, the network address of the contract test container). If the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, it is equivalent to that the destination network address of the target data packet does not match the network address of the contract running container, that is, the target data packet is not sent locally, so the first transmission rule is selected as the target transmission rule.

[0156] Step S1120, comparing the destination network address of the target data packet with the isolated network address included in the first transmission rule; wherein the isolated network address includes all network addresses.

[0157] The first transmission rule is configured with an isolation network address, which is used to instruct to discard data packets whose corresponding destination network addresses match the isolation network address.

[0158] Therefore, after the first transmission rule is selected, the destination network address of the target data packet may be compared with the isolation network address to determine whether to discard the target data packet.

[0159] Since the first transmission rule is selected only when the network address of the destination network address container group matches, and the contract running container and the contract test container share the network address of the container group, if the first transmission rule is selected according to the network address of the target data packet, it means that the destination network address of the target data packet does not match the network address of the contract test container, and the target data packet needs to be discarded. Therefore, the isolated network address of the first transmission rule can include all network addresses, that is, the isolated network address in the first transmission rule can be set to 0.0.0.0 / 0, so that as long as the data packet hits the first transmission rule, it needs to be discarded. Among them, the specific method of configuring the first transmission rule can be flexibly set according to actual needs. In an optional example, the first transmission rule can be configured through iptables. For example, the first transmission rule can be configured by configuring the following instructions in the FORWARD chain:

[0160] iptables-I DOCKER-USER-d 0.0.0.0 / 0-i docker0-j REJECT

[0161] Among them, -I DOCKER-USER: represents adding packet filtering rules to the DOCKER-USER chain (user rule chain) of the FORWARD chain.

[0162] -d 0.0.0.0 / 0: indicates whether the destination network address of the data packet matches 0.0.0.0 / 0. 0.0.0.0 / 0 represents all network addresses.

[0163] -i docker0: represents the data packets received by the virtual bridge.

[0164] -j REJECT: means discarding the data packet.

[0165] The whole instruction means: if the data packet received by the virtual bridge hits the FORWARD forwarding rule chain, the destination network address of the data packet is compared with 0.0.0.0 / 0. If they match, the data packet is discarded.

[0166] Step S1130: If the destination network address of the target data packet matches the isolated network address in the first transmission rule, the target data packet is discarded.

[0167] Since the destination network address of the target data packet matches the isolated network address, it indicates that the network corresponding to the destination network address needs to be isolated, so the target data packet is discarded. Fig.12As shown, assuming that the first transmission rule is configured by configuring instructions in the FORWARD chain, the container group includes a contract running container, the contract running container includes sub-container 1, sub-container 2 and virtual gateway docker0, sub-container 1 and sub-container 2 are connected to docker through the virtual network card eth0 respectively, after sub-container 1 transmits the data packet to docker0, if the data packet hits the FORWARD chain, since the instruction corresponding to the first transmission rule is configured in the user rule chain of the FORWARD chain, the data packet is discarded, that is, it is prohibited to send the data packet to sub-container 1, and it is also prohibited to send the data packet to the external network through the virtual network card eth0 of the contract running container.

[0168] It should be noted that Fig.11 The specific implementation details of steps S410 to S430 shown in FIG. Figure 4 Steps S410 to S430 are shown. Fig.11 The specific implementation details of step 910 shown can be referred to Fig. 9 Step 910 shown is not repeated here.

[0169] exist Fig.11 In the illustrated embodiment, if the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, the first transmission rule is selected from the multiple transmission rules as the target transmission rule, and the destination network address of the target data packet is compared with the isolation network address included in the first transmission rule, wherein the isolation network address includes all network addresses; if the destination network address of the target data packet matches the isolation network address in the first transmission rule, the target data packet is discarded, thereby implementing isolation between the sub-container and the network other than the container group network by discarding the data packet whose destination network address does not match the network address of the container group, thereby improving network security; and, by configuring the transmission rules in the virtual gateway to implement network isolation, the difficulty of network isolation is reduced, network isolation of multiple sub-containers is implemented, and the effectiveness of network isolation is improved.

[0170] In an exemplary embodiment, see Fig.13 , Fig.13 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0171] like Fig.13As shown, the testing method of the smart contract may include: steps S410 to S430, step S910, step S1110 to S1130, and step S1310 to S1340; wherein, the detailed description of steps S1310 to S1340 is as follows:

[0172] Step S1310: If the comparison result indicates that the destination network address of the target data packet matches the network address of the container group, a second transmission rule is selected from the plurality of transmission rules as the target transmission rule.

[0173] The second transmission rule refers to a transmission rule corresponding to a data packet whose destination network address matches the network address of the container group, that is, a transmission rule corresponding to a data packet transmitted locally.

[0174] Since the contract running container and the contract testing container share the network address of the container group, if the destination network address of the target data packet matches the network address of the container group, it is equivalent to that the destination network address of the target data packet matches the network address of the contract running container, that is, the target data packet is sent to the local area. Therefore, the second transmission rule is selected as the target transmission rule.

[0175] Step S1320, obtaining a designated transmission protocol and a designated port from the second transmission rule; wherein the designated port is a port among a plurality of ports allocated to the contract test container and matching the designated transmission protocol.

[0176] The second transmission rule is configured with a specified transmission protocol and a specified port, which are used to instruct that the data packets whose transmission protocol matches the specified transmission protocol and whose destination port matches the specified port are transmitted to the destination network address, that is, the data packets whose transmission protocol does not match the specified transmission protocol are discarded, and the data packets whose destination port does not match the specified port are discarded. For the specific introduction of the specified transmission protocol and the specified port, please refer to the description of the aforementioned embodiment, which will not be repeated here. The specific method of configuring the second transmission rule can be flexibly set according to actual needs. In an optional example, the first transmission rule can be configured through iptables. For example, taking the specified transmission protocol as TCP protocol and the specified port as port 50052 as an example, the second transmission rule can be configured by configuring the following instructions in the INPUT forwarding rule chain:

[0177] iptables -I INPUT -p TCP! --dport 50052-i docker0-j REJECT

[0178] Among them, -I INPUT: represents adding packet filtering rules to the INPUT chain.

[0179] -p TCP!: Determine whether the transmission protocol of the data packet is non-TCP protocol.

[0180] --dport 50052: indicates whether the destination port of the data packet is not port 50052.

[0181] -i docker0: represents the data packets received by the virtual bridge.

[0182] -j REJECT: means discarding the data packet.

[0183] The whole statement means: if the data packet received by the virtual bridge hits the INPUT chain, the data packet whose transport protocol is not TCP will be discarded, and the data packet whose destination port is not port 50052 will be discarded.

[0184] Therefore, after the second transmission rule is selected, the designated transmission protocol and the designated port can be obtained from the second transmission rule.

[0185] Step S1330, comparing the transmission protocol of the target data packet with the designated transmission protocol, and comparing the destination port of the target data packet with the designated port.

[0186] The transmission protocol of the target data packet is compared with the specified transmission protocol in the second transmission rule, and the destination port of the target data packet is compared with the specified port to determine whether to discard the target data packet.

[0187] Step S1340: If the transmission protocol of the target data packet matches the designated transmission protocol, and the destination port matches the designated port, the target data packet is transmitted to the designated port through the virtual bridge.

[0188] If the transmission protocol of the target data packet matches the specified transmission protocol in the second transmission rule, and the destination port of the target data packet matches the specified port, the target data packet will not be discarded, and the target data packet will be transmitted to the specified port through the virtual bridge. In other words, by configuring the second transmission rule in the virtual bridge, Figure 8 Steps S810-S830 in .

[0189] Optionally, if the transmission protocol of the target data packet does not match the specified transmission protocol in the second transmission rule, or the destination port of the target data packet does not match the specified port, the target data packet is discarded. Fig.14As shown, it is assumed that the second transmission rule is configured by configuring instructions in the INPUT chain, the transmission protocol is specified as TCP, the port is specified as 50052, the container group includes a contract running container, the contract running container includes sub-container 1, sub-container 2 and virtual gateway docker0, sub-container 1 and sub-container 2 are connected to docker through the virtual network card eth0 respectively, after sub-container 1 or sub-container 2 transmits the data packet to docker0, if the data packet hits the INPUT chain, since the instructions corresponding to the second transmission rule are configured in the INPUT chain, if the transmission protocol of the data packet is TCP and the destination port is 50052, the data packet is sent to the contract test container, if the transmission protocol of the data packet is TCP, but the destination port is not 50052, the data packet is discarded, and if the transmission protocol of the data packet is not TCP, the data packet is discarded regardless of the destination port.

[0190] It should be noted that Fig.13 The specific implementation details of steps S410 to S430 shown in FIG. Figure 4 Steps S410 to S430 are shown. Fig.13 The specific implementation details of step 910 shown can be referred to Fig. 9 Step 910 shown, Fig.13 The specific implementation details of steps S1110 to S1130 shown in FIG. Fig.11 Steps S1110 to S1130 shown are not repeated here.

[0191] exist Fig.13 In the illustrated embodiment, by configuring transmission rules in the virtual gateway, data packets whose destination network address matches the network address of the contract test container, whose transmission protocol matches the specified transmission protocol, and whose destination port matches the specified port are transmitted to the contract test container, and data packets whose destination network address matches the network address of the contract test container but whose transmission protocol does not match the specified transmission protocol, or whose destination port matches the specified port are filtered out, which not only ensures the security of the contract test container, but also ensures the effectiveness of network isolation.

[0192] In an exemplary embodiment, see Fig.15 , Fig.15 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0193] like Fig.15As shown, the testing method of the smart contract may include: step S410, step S1510-step S1540, step S430, and step S910-step S920; wherein, the detailed description of step S1510-step S1540 is as follows:

[0194] Step S1510, searching for a sub-container that is not currently running a smart contract from multiple sub-containers contained in the contract execution container.

[0195] The contract running container contains multiple sub-containers, each of which can be used to run the smart contract to be tested to test the smart contract. After receiving the target smart contract, a sub-container needs to be allocated to the target smart contract. Therefore, it is necessary to find a sub-container that is not currently running a smart contract from the multiple sub-containers contained in the contract running container, that is, a sub-container that is in an idle state.

[0196] Step S1520: If no sub-container that is not currently running a smart contract is found, a sub-container is created in the contract running container, and the created sub-container is connected to the virtual gateway.

[0197] To improve the test efficiency, if there is no idle sub-container in the contract running container, you can create a sub-container in the contract running container and connect the created sub-container to the virtual gateway in the contract running container.

[0198] In an optional example, in order to prevent the contract running container from occupying too many cloud resources, under the condition that there are no idle sub-containers in the contract running container, it is possible to first determine whether the number of sub-containers contained in the contract running container is greater than the set sub-container number threshold. If so, it indicates that the contract running container occupies more cloud resources, and then you can wait until the contract running container contains an idle sub-container and allocate the idle sub-container to the target smart contract; if not, it indicates that the contract running container occupies fewer cloud resources, and then you can create a sub-container.

[0199] Step S1530: Obtain an unoccupied network address from the subnet corresponding to the virtual gateway, and allocate the obtained network address to the created sub-container.

[0200] After creating a sub-container, the virtual gateway can select an unoccupied network address from its corresponding subnet and assign it to the created sub-container. The network address and subnet of the virtual gateway are assigned to the virtual gateway when it is created.

[0201] Optionally, when creating a docker0 virtual gateway in the contract running container, an IP address and subnet can be allocated to docker0 based on the private IP segment defined in RFC1918 (Address Allocation for Private Network Address Allocation). When creating a subcontainer in the contract running container, docker0 allocates an unoccupied IP address from the subnet to the subcontainer. For example, in one example, see Fig.16 As shown, the contract running container in the container group includes sub-container 1, sub-container 2 and virtual gateway docker0, wherein the IP address of the virtual network card eth0 of the contract running container is 10.10.0.186 / 24, and the IP address 172.17.0.1 / 16 and the network segment 172.17.0.0 / 16 are allocated to docker0. docker0 allocates the IP address 172.17.0.2 / 16 in the network segment 172.17.0.0 / 16 to sub-container 1, and allocates the IP address 172.17.0.3 / 16 to sub-container 2.

[0202] Step S1540: Use the created sub-container as the target sub-container, and test the target smart contract in the target sub-container.

[0203] After assigning a network address to the created sub-container, the created sub-container is used as the target sub-container for running the target smart contract.

[0204] It should be noted that Fig.15 The specific implementation details of step S410 and step S430 shown in FIG. Figure 4 Step S410 and step S430 shown in FIG. Fig.15 The specific implementation details of steps S910 to S920 shown in FIG. Fig. 9 Steps S910 to S920 shown are not repeated here.

[0205] exist Fig.15 In the illustrated embodiment, after receiving the target smart contract, if there is no sub-container in the contract running container that does not run the smart contract, a sub-container is created in the contract running container as the target sub-container for running the target smart contract, thereby achieving expansion of the sub-container and improving the parallelism and flexibility of the smart contract test.

[0206] In an exemplary embodiment, see Fig.17 , Fig.17 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract execution container 312 in the implementation environment shown executes.

[0207] like Fig.17 As shown, the testing method of the smart contract may include: steps S410 to S440, and steps S1710 to S1720; wherein, the detailed description of steps S1710 to S1720 is as follows:

[0208] Step S1710: receiving a data packet to be forwarded sent by any container, and matching a destination network address of the data packet to be forwarded with a network address of a target sub-container.

[0209] Any container can be any container except the target subcontainer.

[0210] In order to prevent other containers from attacking the target sub-container, after receiving a data packet (ie, a data packet to be forwarded) sent by any container, the destination network address of the data packet to be forwarded may be compared with the network address of the target sub-container.

[0211] Step S1720: If the destination network address of the data packet to be forwarded matches the network address of the target sub-container, the data packet to be forwarded is discarded.

[0212] If the data packet to be forwarded is sent to the target sub-container, the target sub-container is discarded, thereby preventing other containers from attacking the target sub-container.

[0213] Optionally, steps S1710 to S1720 may be implemented by configuring transmission rules in the virtual gateway of the contract execution container.

[0214] It should be noted that Fig.17 The specific implementation details of steps S410 to S440 shown in FIG. Figure 4 Steps S410 to S440 shown are not repeated here.

[0215] exist Fig.17 In the illustrated embodiment, the target sub-container is restricted from receiving data packets, thereby preventing other containers from attacking the target sub-container and improving the security of smart contract testing.

[0216] See also Fig.18 , Fig.18 is a flowchart of a smart contract testing method shown in an exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract test container 311 executes in the implementation environment shown.

[0217] like Fig.18 As shown, in an exemplary embodiment, the testing method of the smart contract may include: Step S1810-Step S1820, which are described in detail as follows:

[0218] Step S1810, receiving a contract test request sent by the requester, and obtaining the target smart contract to be tested according to the contract test request.

[0219] A contract test container refers to a container used to provide smart contract testing services. The requester (for example, a smart contract developer, etc.) can initiate a contract test request in the contract test container. The contract test container obtains the smart contract to be tested, i.e., the target smart contract, based on the contract test request.

[0220] For the detailed introduction of the contract test container, please refer to the description in the aforementioned embodiment, which will not be repeated here.

[0221] Step S1820, sending the target smart contract to the contract running container in the cloud server, so that the contract running container selects a target sub-container for running the target smart contract from the multiple sub-containers contained therein, and tests the target smart contract in the target sub-container. During the testing of the target smart contract, if the target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0222] It should be understood that the test of a smart contract refers to running the smart contract, obtaining the running result, and obtaining the test result based on the running result. Therefore, after the contract test container obtains the target smart contract, it can send the target smart contract to the contract running container so that the contract running container runs the target smart contract to test the target smart contract.

[0223] After receiving the target smart contract, the contract running container selects a target subcontainer for running the target smart contract from the multiple subcontainers it contains, and tests the target smart contract in the target subcontainer. During the test of the target smart contract, if the contract running container obtains the target data packet sent by the target subcontainer according to the target smart contract, in order to prevent the target smart contract from attacking other businesses, the destination network address of the target data packet is compared with the network address of the contract test container. If the two do not match, the target data packet is discarded. For a detailed description, please refer to the records of the aforementioned embodiment, which will not be repeated here.

[0224] exist Fig.18In the illustrated embodiment, on the one hand, the smart contract is tested through the contract test container and the contract running container in the cloud server, which improves the test flexibility, and the receiving contract test request and the testing smart contract are executed through different containers, which improves the test efficiency; on the other hand, the smart contract is tested through the sub-container in the contract running container, which is not only convenient for restricting the network of the sub-container, but also can improve the test parallelism by expanding the sub-container, and by discarding the data packets sent by the sub-container whose destination network address is not the network address of the contract test container, the network of the sub-container is restricted, thereby ensuring that the test data can be transmitted to the contract test container, avoiding the situation where the smart contract attacks other services in the network during the test, thereby improving the test security.

[0225] In an exemplary embodiment, see Fig.19 , Fig.19 is a flowchart of a method for testing a smart contract shown in another exemplary embodiment of the present application. The method can be applied to Figure 3 The implementation environment shown, which can be Figure 3 The contract test container 311 executes in the implementation environment shown.

[0226] like Fig.19 As shown, under the condition that the contract test container and the contract running container are deployed in the same container group, the smart contract testing method may include: step S1810, and step S1910; wherein, step S1910 is described in detail as follows:

[0227] Step S1910, stores the target smart contract in the shared volume corresponding to the container group, so that the contract running container obtains the target smart contract from the shared volume, selects the target sub-container for running the target smart contract from the multiple sub-containers contained therein, and tests the target smart contract in the target sub-container. During the testing of the target smart contract, if the target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0228] It should be noted that when creating a container group, the specified storage volume can be used as a shared volume, and all containers in the container group can access the shared volume, thereby allowing the containers in the container group to share data. Therefore, under the condition that the contract running container and the contract test container are deployed in the same container group, the contract running container and the contract test container will share the shared volume corresponding to the container group, and the contract test container can store the target smart contract in the shared volume corresponding to the container group, so that the contract running container can access the shared volume to obtain the target smart contract.

[0229] It should be noted that Fig.19The specific implementation details of step S1810 shown can be referred to Fig.18 The step S1810 shown is not repeated here.

[0230] exist Fig.19 In the illustrated embodiment, under the condition that the contract test container and the contract running container are deployed in the same container group, the target smart contract is transferred from the contract test container to the contract running container through the shared volume corresponding to the container group, thereby improving the transmission efficiency and security.

[0231] In an exemplary embodiment, the testing method of the smart contract is applied to Fig. 20 The application scenario shown in the figure is used as an example to illustrate. Fig. 20 As shown, the application scenario includes a container group deployed in a cloud server, which includes a contract development container (corresponding to a contract test container) and a DIND container (corresponding to a contract running container). The DIND container includes a docker deamon and multiple docker containers (corresponding to sub-containers). The docker container can be developed based on the go language. When creating a container group, a shared volume is allocated to the container group, and both the contract development container and the DIND container in the container group can access the shared volume. In the process of creating a DIND container, a virtual gateway docker0 is created in the DIND container through the docker deamon in the DIND container, and an IP address and a subnet are allocated to docker0. Docker0 is used to connect to the docker container and allocate an IP address to the docker container from the subnet.

[0232] based on Fig. 20 The application environment shown is shown in Fig.21 As shown, the testing method of the smart contract includes steps S2101 to S2108, which are described in detail as follows:

[0233] Step S2101, the contract development container receives a contract test request initiated by the requester, and obtains the target smart contract to be tested according to the contract test request.

[0234] An integrated development environment is deployed in the contract development container, which provides an integrated development service interface for the contract. Developers can use this interface to develop, test, and debug smart contracts.

[0235] The contract development container can receive a contract test request initiated by a requester (e.g., a developer), and thereby determine the smart contract to be tested, i.e., the target smart contract, based on the request.

[0236] Step S2102: The contract development container sends the target smart contract to the DIND container through the shared volume.

[0237] Optionally, the contract development container can send a docker run command to the DIND container, so that the docker deamon in the DIND container selects a target docker container based on the docker run command, and starts the target docker container to run the target smart contract.

[0238] Optionally, the contract development container can send the docker run command to the DIND container through the emptyDir sock file. Among them, a temporary directory in the life cycle of the emptyDir container group can be used as a shared volume of the container group; mount the docker run command to the emptyDir sock file, and the DIND container will detect the sock file to obtain the docker run command.

[0239] Step S2103, the DIND container selects a target docker container for running the target smart contract from the multiple docker containers contained therein, and tests the target smart contract in the target docker container.

[0240] After DIND selects the target docker container, it runs the target smart contract in the target docker container.

[0241] Step S2104, during the process of testing the target smart contract, the DIND container receives the target data packet sent by the target docker container according to the target smart contract through the connection between docker0 and the target docker container.

[0242] During the testing of the target smart contract, the test data of the target smart contract can be obtained, and a target data packet can be generated based on the test data. The target docker container can send the target data packet to the contract development container. Since the communication of the target docker container needs to pass through docker0, docker0 receives the target data packet.

[0243] Step S2105 , the DIND container compares the destination IP address of the target data packet with the IP address of the container group.

[0244] In this embodiment, different transmission rules are configured based on whether the data packet is sent to the local area (ie, the container group). Therefore, the destination IP address of the target data packet needs to be compared with the IP address of the container group.

[0245] Step S2106, if the destination IP address of the target data packet does not match the IP address of the container group, the DIND container discards the target data packet according to the FORWARD chain configured in docker0.

[0246] In order to avoid attacks on other services during the testing of smart contracts, the INPUT chain and FORWARD chain are configured in docker0 based on iptables. If the destination IP address of the data packet forwarded to docker0 does not match the IP address of the container group, the FORWARD chain is hit; if it matches the IP address of the container group, the INPUT chain is hit.

[0247] The FORWARD chain is configured with the "iptables-I DOCKER-USER-d 0.0.0.0 / 0-idocker0-jREJECT" command, which instructs to discard the data packets that hit the FORWARD chain, thereby isolating the docker container from the network outside the container group and isolating the network between the docker containers in the container group.

[0248] Therefore, if the destination IP address of the target data packet does not match the IP address of the container group, the target data packet hits the FORWARD chain, and therefore, the target data packet is discarded.

[0249] Step S2107, if the destination IP address of the target data packet matches the IP address of the container group, the DIND container compares the transport protocol of the target data packet with the specified transport protocol contained in the INPUT chain configured in docker0, and compares the destination port of the target data packet with the specified port contained in the INPUT chain.

[0250] In order to ensure that the docker container and the contract development container can only transmit through the specified transport protocol and the specified port, the docker container's INPUT chain is configured with the specified transport protocol and the specified port to indicate that the data packets whose transport protocol does not match the specified transport protocol are discarded, and the data packets whose destination port does not match the specified port are discarded. For example, assuming that the specified transport protocol is TCP and the specified port is 50052, the "iptables-I INPUT-p TCP! --dport 50052-i docker0-jREJECT" command is configured in the INPUT chain to discard data packets whose transport protocol is not TCP and whose destination port is not 50052.

[0251] Step S2108, if the transport protocol of the target data packet matches the specified transport protocol contained in the INPUT chain configured in docker0, and the destination port of the target data packet matches the specified port contained in the INPUT chain, the DIND container sends the target data packet to the specified port through docker0.

[0252] The designated port is the port assigned to the contract development container. Since the contract development container shares the network resources of the container group with the DIND container, the designated port is also the port assigned to the DIND container, that is, the DIND container and the contract development container share the designated port. Under the condition that the transmission protocol of the target data packet matches the designated transmission protocol contained in the INPUT chain configured in docker0, and the destination port of the target data packet matches the designated port contained in the INPUT chain, the target data packet is sent to the designated port through docker0, and the contract development container detects the target data packet from the designated port, thereby obtaining the target data packet.

[0253] Optionally, after obtaining the target data packet, the contract development container may send the test data of the target smart contract contained in the target data packet to the requester, so that the requester can debug the target smart contract according to the test data.

[0254] Optionally, if the transport protocol of the target data packet does not match the specified transport protocol contained in the INPUT chain configured in docker0, or the destination port of the target data packet does not match the specified port contained in the INPUT chain, the target data packet is discarded.

[0255] It should be noted that Fig.21 The implementation details of steps S2101 to S2108 have been described in detail in the above embodiments and will not be repeated here.

[0256] exist Fig.21 In the illustrated embodiment, on the one hand, by deploying a contract development container and a DIND container in a container group, and deploying multiple docker containers for testing smart contracts in the DIND container, remote testing of smart contracts is achieved, testing flexibility is improved, and contract development services and contract testing services are executed through different containers, thereby improving testing efficiency; on the other hand, smart contracts are tested through the docker container in the DIND container, and network isolation of the docker container is achieved through the virtual gateway in the DIND container. Based on the scalability of the docker container, the test parallelism can be increased, and under the condition that the test data can be transmitted to the contract development container for transmission on the requesting party, the situation where the smart contract attacks other services in the network during the test can be avoided, thereby improving test security.

[0257] See also Fig. 22 , Fig. 22 FIG. 1 is a block diagram of a testing device for a smart contract shown in an exemplary embodiment of the present application, which is deployed in a cloud server. Fig. 22 As shown, the device comprises:

[0258] The receiving module 2201 is configured to receive a target smart contract to be tested sent by a contract test container in a cloud server;

[0259] The testing module 2202 is configured to select a target subcontainer for running a target smart contract from a plurality of subcontainers included in the contract running container in the cloud server, and test the target smart contract in the target subcontainer;

[0260] An acquisition module 2203 is configured to acquire a target data packet sent by a target sub-container according to a target smart contract during testing of the target smart contract;

[0261] The discard module 2204 is configured to discard the target data packet in response to the destination network address of the target data packet not matching the network address of the contract test container.

[0262] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the network address of each sub-container is different from the network address of the contract test container, the device also includes a comparison module, configured to: compare the destination network address with the network addresses of other sub-containers among the multiple sub-containers except the target sub-container; if the destination network address matches the network addresses of the other sub-containers, it is determined that the destination network address does not match the network address of the contract test container.

[0263] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a sending module, configured to send a target data packet to the contract test container in response to the destination network address matching the network address of the contract test container; wherein the target data packet includes test data of the target smart contract.

[0264] In an exemplary embodiment, the sending module is configured to: obtain the transmission protocol of the target data packet in response to the destination network address matching the network address of the contract test container; compare the transmission protocol of the target data packet with the specified transmission protocol; if the transmission protocol of the target data packet matches the specified transmission protocol, send the target data packet to the contract test container.

[0265] In an exemplary embodiment, based on the aforementioned scheme, the sending module is configured as follows: if the transmission protocol of the target data packet matches the specified transmission protocol, the destination port of the target data packet is obtained; the destination port is compared with the specified port; wherein the specified port is a port among multiple ports allocated to the contract test container and matching the specified transmission protocol; if the destination port matches the specified port, the target data packet is sent to the specified port.

[0266] In an exemplary embodiment, based on the aforementioned scheme, a virtual bridge is included in the contract running container, and under the condition that each sub-container is connected to the virtual bridge, the discard module 2204 is configured as follows: after receiving the target data packet through the connection between the virtual bridge and the target sub-container, the destination network address of the target data packet is compared with the network address of the contract running container to obtain a comparison result; a target transmission rule that matches the comparison result is selected from multiple transmission rules pre-configured by the virtual bridge; if it is determined according to the target transmission rule that the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0267] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the contract running container and the contract testing container belong to the same container group, and the contract running container and the contract testing container share the network address of the container group, the discard module 2204 is configured as follows: if the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, then select the first transmission rule from multiple transmission rules as the target transmission rule; compare the destination network address of the target data packet with the isolated network address included in the first transmission rule; wherein the isolated network address includes all network addresses; if the destination network address of the target data packet matches the isolated network address in the first transmission rule, then discard the target data packet.

[0268] In an exemplary embodiment, based on the aforementioned scheme, the sending module is configured as follows: if the comparison result indicates that the destination network address of the target data packet matches the network address of the container group, then select a second transmission rule from multiple transmission rules as the target transmission rule; obtain a specified transmission protocol and a specified port from the second transmission rule; wherein the specified port is a port among multiple ports allocated to the contract test container and matching the specified transmission protocol; compare the transmission protocol of the target data packet with the specified transmission protocol, and compare the destination port of the target data packet with the specified port; if the transmission protocol of the target data packet matches the specified transmission protocol, and the destination port matches the designated port, then transmit the target data packet to the designated port through a virtual bridge.

[0269] In an exemplary embodiment, based on the aforementioned scheme, the test module 2202 is configured to: search for a sub-container that is not currently running a smart contract from multiple sub-containers contained in the contract running container; if no sub-container that is not currently running a smart contract is found, create a sub-container in the contract running container, and connect the created sub-container to the virtual gateway; obtain an unoccupied network address from the subnet corresponding to the virtual gateway, and assign the obtained network address to the created sub-container; and use the created sub-container as the target sub-container.

[0270] In an exemplary embodiment, based on the aforementioned scheme, the discarding module 2204 is further configured to: receive a data packet to be forwarded sent by any container, and match the destination network address of the data packet to be forwarded with the network address of the target sub-container; if the destination network address of the data packet to be forwarded matches the network address of the target sub-container, discard the data packet to be forwarded.

[0271] It should be noted that Fig. 22 The execution steps of the contract running container in the provided testing device for smart contracts and the testing method for smart contracts provided in the above embodiments belong to the same concept, wherein the specific manner in which each module and unit executes the operation has been described in detail in the method embodiment and will not be repeated here.

[0272] See also Fig.23 , Fig.23 FIG. 1 is a block diagram of a testing device for a smart contract shown in an exemplary embodiment of the present application, which is configured in a cloud server. Fig.23 As shown, the device comprises:

[0273] The acquisition module 2301 is configured to receive a contract test request sent by a requester, and acquire a target smart contract to be tested according to the contract test request;

[0274] The sending module 2302 is configured to send the target smart contract to the contract running container in the cloud server, so that the contract running container selects a target sub-container for running the target smart contract from the multiple sub-containers contained therein, and tests the target smart contract in the target sub-container. During the testing of the target smart contract, if the target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

[0275] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the contract test container and the contract execution container are deployed in the same container group, the sending module 2302 is: storing the target smart contract in the shared volume corresponding to the container group, so that the contract execution container obtains the target smart contract from the shared volume.

[0276] It should be noted that Fig.23 The provided smart contract testing device and the execution steps of the contract testing container in the smart contract testing method provided in the above embodiment belong to the same concept, and the specific manner in which each module and unit executes the operation has been described in detail in the method embodiment and will not be repeated here.

[0277] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more computer programs, and when the one or more computer programs are executed by one or more processors, the electronic device implements the testing method of the smart contract provided in the above-mentioned embodiments.

[0278] Fig.24 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0279] It should be noted that Fig.24 The computer system 2400 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0280] like Fig.24 As shown, the computer system 2400 includes a central processing unit (CPU) 2401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 2402 or a computer program loaded from a storage part 2408 to a random access memory (RAM) 2403, such as executing the test method of the smart contract in the above embodiment. In RAM 2403, various computer programs and data required for system operation are also stored. CPU 2401, ROM 2402 and RAM 2403 are connected to each other via a bus 2404. An input / output (I / O) interface 2405 is also connected to the bus 2404.

[0281] In some embodiments, the following components are connected to the I / O interface 2405: an input section 2406 including a keyboard, a mouse, etc.; an output section 2407 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 2408 including a hard disk, etc.; and a communication section 2409 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 2409 performs communication processing via a network such as the Internet. A drive 2410 is also connected to the I / O interface 2405 as needed. A removable medium 2411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 2410 as needed, so that a computer program read therefrom is installed into the storage section 2408 as needed.

[0282] In particular, according to an embodiment of the present application, a computer program for implementing a testing method for a smart contract may be carried on a computer-readable medium, which may be downloaded and installed from a network via the communication part 2409 , and / or installed from a removable medium 2411 .

[0283] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a computer program, which may be used by an instruction execution system, device or device or used in combination with it. The computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried, and the propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer program contained in the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, etc., or any suitable combination of the foregoing.

[0284] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0285] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0286] Another aspect of the present application further provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor of an electronic device, the electronic device implements the above-mentioned smart contract testing method. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0287] Another aspect of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the testing method of the smart contract provided in each of the above embodiments is implemented. The computer program can be stored in a computer-readable storage medium.

[0288] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A testing method for smart contracts, It is characterized in that The method comprises: Receive the target smart contract to be tested sent by the contract test container in the cloud server; Selecting a target sub-container for running the target smart contract from a plurality of sub-containers included in the contract running container in the cloud server, and testing the target smart contract in the target sub-container; In the process of testing the target smart contract, obtaining a target data packet sent by the target sub-container according to the target smart contract; In response to the destination network address of the target data packet not matching the network address of the contract test container, the target data packet is discarded.

2. The method according to claim 1, It is characterized in that The network address of each sub-container is different from the network address of the contract test container; the method further includes: Compare the destination network address with network addresses of other sub-containers among the multiple sub-containers except the target sub-container; If the destination network address matches the network address of the other sub-container, it is determined that the destination network address does not match the network address of the contract test container.

3. The method according to claim 1, It is characterized in that The method further comprises: In response to the destination network address matching the network address of the contract test container, the target data packet is sent to the contract test container; wherein the target data packet includes test data of the target smart contract.

4. The method according to claim 3, It is characterized in that In response to the destination network address matching the network address of the contract test container, sending the target data packet to the contract test container includes: In response to the destination network address matching the network address of the contract test container, obtaining a transmission protocol of the target data packet; Comparing the transmission protocol of the target data packet with the specified transmission protocol; If the transmission protocol of the target data packet matches the specified transmission protocol, the target data packet is sent to the contract test container.

5. The method according to claim 4, It is characterized in that If the transmission protocol of the target data packet matches the specified transmission protocol, sending the target data packet to the contract test container includes: If the transmission protocol of the target data packet matches the specified transmission protocol, obtaining the destination port of the target data packet; Comparing the destination port with a designated port; wherein the designated port is a port among a plurality of ports allocated to the contract test container and matching the designated transmission protocol; If the destination port matches the designated port, the target data packet is sent to the designated port.

6. The method according to claim 1, It is characterized in that The contract execution container includes a virtual bridge, and each sub-container is connected to the virtual bridge; In response to the destination network address of the target data packet not matching the network address of the contract test container, discarding the target data packet includes: After receiving the target data packet through the connection between the virtual bridge and the target sub-container, comparing the destination network address of the target data packet with the network address of the contract running container to obtain a comparison result; A target transmission rule matching the comparison result is selected from a plurality of transmission rules pre-configured by the virtual bridge, and if it is determined according to the target transmission rule that the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

7. The method according to claim 6, It is characterized in that The contract running container and the contract testing container belong to the same container group, and the contract running container and the contract testing container share the network address of the container group; The selecting a target transmission rule that matches the comparison result from a plurality of transmission rules pre-configured by the virtual bridge, and discarding the target data packet if it is determined according to the target transmission rule that the destination network address of the target data packet does not match the network address of the contract test container, comprises: If the comparison result indicates that the destination network address of the target data packet does not match the network address of the container group, selecting a first transmission rule from the multiple transmission rules as the target transmission rule; Comparing the destination network address of the target data packet with the isolated network address included in the first transmission rule; wherein the isolated network address includes all network addresses; If the destination network address of the target data packet matches the isolated network address in the first transmission rule, the target data packet is discarded.

8. The method according to claim 7, It is characterized in that The method further comprises: If the comparison result indicates that the destination network address of the target data packet matches the network address of the container group, selecting a second transmission rule from the plurality of transmission rules as the target transmission rule; Acquire a designated transmission protocol and a designated port from the second transmission rule; wherein the designated port is a port among a plurality of ports allocated to the contract test container and matching the designated transmission protocol; Compare the transmission protocol of the target data packet with the specified transmission protocol, and compare the destination port of the target data packet with the specified port; If the transmission protocol of the target data packet matches the designated transmission protocol, and the destination port matches the designated port, the target data packet is transmitted to the designated port through the virtual bridge.

9. The method according to claim 6, It is characterized in that The step of selecting a target sub-container from a plurality of sub-containers included in the contract execution container includes: Searching for a sub-container that is not currently running a smart contract from multiple sub-containers contained in the contract running container; If no sub-container that is not currently running a smart contract is found, a sub-container is created in the contract running container, and the created sub-container is connected to the virtual gateway; Obtain an unoccupied network address from the subnet corresponding to the virtual gateway, and assign the obtained network address to the created sub-container; The created subcontainer is used as the target subcontainer.

10. The method according to claim 1, It is characterized in that The method further comprises: Receive a data packet to be forwarded sent by any container, and match the destination network address of the data packet to be forwarded with the network address of the target sub-container; If the destination network address of the data packet to be forwarded matches the network address of the target sub-container, the data packet to be forwarded is discarded.

11. A smart contract testing method, It is characterized in that The method comprises: Receive a contract test request sent by the requester, and obtain the target smart contract to be tested according to the contract test request; The target smart contract is sent to the contract running container in the cloud server, so that the contract running container selects a target sub-container for running the target smart contract from the multiple sub-containers contained therein, and tests the target smart contract in the target sub-container. During the testing of the target smart contract, if a target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

12. The method according to claim 11, It is characterized in that The contract test container and the contract running container are deployed in the same container group; The step of sending the target smart contract to a contract execution container in a cloud server includes: The target smart contract is stored in the shared volume corresponding to the container group, so that the contract execution container obtains the target smart contract from the shared volume.

13. A testing device for smart contracts, It is characterized in that Configured in a cloud server, the device includes: A receiving module, configured to receive a target smart contract to be tested sent by a contract test container in a cloud server; A testing module is configured to select a target subcontainer for running the target smart contract from a plurality of subcontainers included in the contract running container in the cloud server, and test the target smart contract in the target subcontainer; an acquisition module, configured to acquire a target data packet sent by the target sub-container according to the target smart contract during the process of testing the target smart contract; The discarding module is configured to discard the target data packet in response to the destination network address of the target data packet not matching the network address of the contract test container.

14. A testing device for smart contracts, It is characterized in that Configured in a cloud server, the device includes: An acquisition module is configured to receive a contract test request sent by a requester, and acquire a target smart contract to be tested according to the contract test request; A sending module is configured to send the target smart contract to a contract running container in a cloud server, so that the contract running container selects a target sub-container for running the target smart contract from a plurality of sub-containers contained therein, and tests the target smart contract in the target sub-container. During the process of testing the target smart contract, if a target data packet sent by the target sub-container according to the target smart contract is obtained, and the destination network address of the target data packet does not match the network address of the contract test container, the target data packet is discarded.

15. An electronic device, It is characterized in that include: one or more processors; A storage device for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the smart contract testing method described in any one of claims 1-12.

16. A computer-readable storage medium, It is characterized in that A computer program is stored thereon, and when the computer program is executed by a processor of an electronic device, the electronic device implements the testing method for the smart contract described in any one of claims 1-12.

17. A computer program product, It is characterized in that It includes a computer program, which, when executed by a processor, implements the testing method for the smart contract described in any one of claims 1 to 12.

Images