Block chain test method, device and equipment and readable storage medium

By inserting instrumentation code into the source code of the relay node to generate test code, simulating the tampering of signature information, solving the test problems caused by tampering of signature information during resource transfer between blockchains, and improving testing efficiency and accuracy.

CN119226127APending Publication Date: 2024-12-31TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310799171.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-06-30
Publication Date
2024-12-31

AI Technical Summary

Technical Problem

When transferring resources between blockchains, tampering of signature information will cause resource transfer to fail, and it is difficult for the prior art to efficiently simulate tampering of signature information for testing.

Method used

By obtaining the source code of the relay node, inserting the instrumentation code to generate test code, simulate the tampering of signature information, thereby generating the tampered signature information on the relay node, and testing the resource transfer scenario.

Benefits of technology

It improves the efficiency of blockchain testing, can effectively simulate the tampering of signature information, and ensures the accuracy and comprehensiveness of the test.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119226127A_ABST
    Figure CN119226127A_ABST
Patent Text Reader

Abstract

The invention discloses a block chain testing method and device, equipment and a readable storage medium, and belongs to the technical field of block chains. The method comprises the steps of obtaining a resource transfer case, wherein the resource transfer case is used for describing a scene in which a first object belonging to a first block chain performs resource transfer to a second object belonging to a second block chain; obtaining a source code of the relay node, wherein the source code is used for obtaining reference content related to the signature information; inserting an instrumentation code into the source code to obtain a test code, the instrumentation code being used for tampering the reference content to obtain tampered content, and the test code being used for generating first signature information based on the tampered content according to the source code; under the condition that the relay node generates first signature information based on the test code, testing a scene of resource transfer from the first object to the second object to obtain a first test result; and determining a block chain test result based on the first test result. The test difficulty can be reduced, and the test efficiency can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of blockchain technology, and in particular to a blockchain testing method, device, equipment, and readable storage medium. Background Art

[0002] Blockchain is a technology that uses cryptography to ensure the security of resource transmission and access. Generally, resources can be transferred within the same blockchain or between different blockchains.

[0003] If a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain, the first node of the first blockchain can store the resources in the resource pool of the first blockchain in response to the resource transfer operation of the first object. The relay node generates signature information in response to the event that the resources are stored in the resource pool, and sends a voting request for the signature information to the second node of the second blockchain. The second node sends the voting request to other nodes in the second blockchain and receives the voting results sent by other nodes. If the second node confirms that the vote is passed based on the voting results sent by other nodes, the resources are allocated to the second object from the resource pool of the second blockchain.

[0004] From the above content, we can know that for the case of resource transfer between different blockchains, the signature information generated by the relay node is crucial. If the signature information is tampered with, the resource transfer will fail. Based on this, how to test the blockchain by simulating the tampering of the signature information has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present application provides a blockchain testing method, device, equipment and readable storage medium, which can be used to test the blockchain and improve the testing efficiency of the blockchain. The technical solution includes the following contents.

[0006] In one aspect, a method for testing a blockchain is provided, the method comprising:

[0007] Obtain a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain;

[0008] Obtaining source code of the relay node, wherein the source code is used to obtain reference content related to the signature information;

[0009] Inserting a stub code into the source code to obtain a test code, wherein the stub code is used to tamper with the reference content obtained through the source code to obtain a tampered content, and the test code is used to generate first signature information based on the tampered content according to the source code;

[0010] When the relay node generates the first signature information based on the test code, testing a scenario in which the first object transfers resources to the second object to obtain a first test result;

[0011] Based on the first test result, a blockchain test result is determined.

[0012] On the other hand, a blockchain testing device is provided, the device comprising:

[0013] an acquisition module, used to acquire a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain;

[0014] The acquisition module is further used to acquire source code of the relay node, and the source code is used to acquire reference content related to the signature information;

[0015] an insertion module, configured to insert a stub code into the source code to obtain a test code, wherein the stub code is used to tamper with the reference content obtained through the source code to obtain a tampered content, and the test code is used to generate first signature information based on the tampered content according to the source code;

[0016] a testing module, configured to test a scenario in which the first object transfers resources to the second object when the relay node generates the first signature information based on the test code, and obtain a first test result;

[0017] A determination module is used to determine a blockchain test result based on the first test result.

[0018] In a possible implementation manner, the reference content includes a private key, a signature algorithm, and resource transfer information of the relay node;

[0019] The insertion module is used to obtain a configuration file, wherein the configuration file includes the insertion code and the insertion position of the insertion code in the source code, and the insertion code is used to tamper with at least one of the private key, the signature algorithm and the resource transfer information; based on the insertion position, the insertion code is inserted into the source code to obtain the test code.

[0020] In one possible implementation, the test module is used to generate a test executable file based on the test code; deploy the test executable file on the relay node; and when the relay node generates the first signature information based on the test executable file, test the scenario of resource transfer from the first object to the second object to obtain a first test result.

[0021] In one possible implementation, the test module is used to obtain a first instruction for activating the stub code in the test code; generate a first intermediate file based on the first instruction and the test code, the first intermediate file being used to describe the source code, the test code, and modifications made when the stub code is inserted into the source code; and determine the test executable file based on the first intermediate file.

[0022] In a possible implementation, the test module is used to obtain a second instruction for running an executable file corresponding to the plug-in code, and the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the plug-in code; when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the plug-in code based on the second instruction to generate the first signature information, a scenario of resource transfer from the first object to the second object is tested to obtain a first test log, and the first test log is used to describe at least one of the running information of the node in the first blockchain, the running information of the relay node, and the running information of the node in the second blockchain when the executable file corresponding to the plug-in code is run; based on the first test log, the first test result is determined.

[0023] In a possible implementation manner, the test code is further used to generate the second signature information based on the reference content according to the source code;

[0024] The determination module is used to test the scenario of resource transfer from the first object to the second object when the relay node generates the second signature information based on the test code to obtain a second test result; and determine the blockchain test result based on the first test result and the second test result.

[0025] In a possible implementation, the determination module is used to obtain a third instruction for stopping the execution of the executable file corresponding to the plug-in code, and the test code is used to generate a test executable file deployed on the relay node, and the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the plug-in code; when the relay node runs the executable file corresponding to the source code based on the third instruction to generate the second signature information, a scenario of resource transfer from the first object to the second object is tested to obtain a second test log, and the second test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the execution of the executable file corresponding to the plug-in code is stopped; based on the second test log, the second test result is determined.

[0026] In a possible implementation, the acquisition module is further used to acquire a fourth instruction for clearing the plug-in code in the test code based on the blockchain test result indicating that a result of the resource transfer from the first object to the second object meets a reference condition;

[0027] The device also includes:

[0028] A generating module, configured to generate a second intermediate file based on the fourth instruction and the test code, wherein the second intermediate file is used to describe the source code;

[0029] The determination module is further used to determine the executable file corresponding to the source code based on the second intermediate file, and the executable file corresponding to the source code is used to be deployed on the relay node and executed by the relay node to generate the second signature information.

[0030] On the other hand, an electronic device is provided, comprising a processor and a memory, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor so that the electronic device implements any of the above-mentioned blockchain testing methods.

[0031] On the other hand, a computer-readable storage medium is also provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor so that an electronic device can implement any of the above-mentioned blockchain testing methods.

[0032] On the other hand, a computer program is also provided, wherein the computer program is at least one, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned blockchain testing methods.

[0033] On the other hand, a computer program product is also provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor so that an electronic device can implement any of the above-mentioned blockchain testing methods.

[0034] The technical solution provided by this application brings at least the following beneficial effects:

[0035] In the technical solution provided by the present application, the source code of the relay node is used to obtain reference content related to the signature information, and the stub code is used to tamper with the reference content obtained through the source code to obtain the tampered content. By inserting the stub code into the source code to obtain the test code, the test code can generate the first signature information based on the tampered content according to the source code, thereby simulating the tampering of the signature information and laying the foundation for testing the blockchain. Since the acquisition of the stub code is easy, and the implementation difficulty of inserting the stub code into the source code to obtain the test code is low, the acquisition efficiency of the test code is high, so that when the relay node generates the first signature information based on the test code, the test efficiency can be improved when testing the scenario of transferring resources from the first object to the second object. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0037] Figure 1 It is a schematic diagram of an implementation environment of a blockchain testing method provided in an embodiment of the present application;

[0038] Figure 2 This is a flowchart of a blockchain testing method provided by an embodiment of the present application;

[0039] Figure 3 It is a schematic diagram of a framework for realizing cross-chain resource transfer through cross-chain bridge technology provided by an embodiment of the present application;

[0040] Figure 4 This is a schematic diagram of a cross-chain resource transfer process provided by an embodiment of the present application;

[0041] Figure 5 is a schematic diagram of a display interface provided in an embodiment of the present application;

[0042] Figure 6 This is a test flow chart of a blockchain provided in an embodiment of the present application;

[0043] Figure 7 This is another blockchain testing flowchart provided by an embodiment of the present application;

[0044] Figure 8 It is a structural schematic diagram of a blockchain testing device provided in an embodiment of the present application;

[0045] Fig. 9 It is a structural diagram of a terminal device provided in an embodiment of the present application;

[0046] Fig.10 It is a structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0048] Figure 1 : is a schematic diagram of an implementation environment of a blockchain testing method provided in an embodiment of the present application, such as Figure 1 As shown, the implementation environment includes a first blockchain 01, a second blockchain 02, a relay node 03 and a test device 04. Among them, the test method of the blockchain in the embodiment of the present application is executed by the test device 04.

[0049] The first blockchain 01 includes multiple nodes. For any node in the first blockchain 01, the node is connected to at least one node in the first blockchain 01, that is, any two nodes in the first blockchain 01 may be connected to each other or not. For example, Figure 1 It is shown that the first blockchain 01 includes nodes 1 to 4, and each two nodes are connected in communication. It can be understood that the two nodes can be connected in communication through a wired network or a wireless network.

[0050] Similarly, the second blockchain 02 also includes multiple nodes. For any node in the second blockchain 02, the node is communicatively connected with at least one node in the second blockchain 02, that is, any two nodes in the second blockchain 02 may be communicatively connected or not. For example, Figure 2 It is shown that the second blockchain 02 includes nodes 1 to 5, and each two nodes are communicatively connected.

[0051] It should be noted that in blockchain technology, any device such as a server, a terminal device, etc. can join the blockchain and become a node in the blockchain. That is to say, any node in the first blockchain 01 or the second blockchain 02 can be a server 101, or a smart phone 102, a desktop computer 103, a game console, a tablet computer, a laptop portable computer, a smart TV, a smart car device, an intelligent voice interaction device, a smart home appliance, and any other terminal device. The server 101 can be a single server, or a server cluster composed of multiple servers, or any one of a cloud computing platform and a virtualization center. In addition, the server 101 can have functions such as data processing, data storage, and data transmission and reception, which are not limited in the embodiments of the present application.

[0052] The relay node 03 can be a server 101, or it can be any terminal device such as a smart phone 102, a desktop computer 103, a game console, a tablet computer, a laptop computer, a smart TV, a smart car device, an intelligent voice interaction device, a smart home appliance, etc. The relay node 03 can communicate with any node in the first blockchain 01 through a wired network or a wireless network, and can also communicate with any node in the second blockchain 02 through a wired network or a wireless network. The embodiment of the present application does not limit the number of relay nodes 03, that is, the relay node 03 can be one or more. The relay node 03 can have functions such as data processing, data storage, and data transmission and reception, which are not limited in the embodiment of the present application.

[0053] The test device 04 can be a server 101, or a smart phone 102, a desktop computer 103, a game console, a tablet computer, a laptop computer, a smart TV, a smart car device, an intelligent voice interaction device, a smart home appliance, or any other terminal device. The test device 04 and any node in the first blockchain 01, any node in the second blockchain 02, and the relay node 03 are connected to each other through a wired network or a wireless network. The test device 04 can have functions such as data processing, data storage, and data transmission and reception, which are not limited in the embodiments of the present application.

[0054] In an exemplary embodiment, the test device 04 is any node in the first blockchain 01, or the test device 04 is any node in the first blockchain 02, or the test device 04 is a relay node 03.

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

[0056] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation review. Among them, the user management module is responsible for the information management of all blockchain participants, including the maintenance of public and private key generation (account management), key management, and the maintenance of the correspondence between user information and blockchain addresses (authority management), etc., and with authorization, supervises and audits the transactions of certain users and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices (that is, the nodes mentioned above) to verify the validity of business requests, and records the valid requests to the storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management), after encryption, it is completely and consistently transmitted to the shared ledger (network communication), and recorded and stored; the smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other event trigger execution is called to complete the contract logic. At the same time, it also provides the function of contract upgrade and cancellation; the operation viewing module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as: alarm, network status check, node device health status check, etc.

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

[0058] In the field of blockchain technology, resources can be transferred between different blockchains. For example, see Figure 1, if the first object belonging to the first block 01 transfers resources to the second object belonging to the second blockchain 02, the first node of the first blockchain 01 (the first node can be any node in the first blockchain 01, for example, the first node is node 2 in the first blockchain 01) can store the resources in the resource pool of the first blockchain 01 in response to the operation of the first object transferring resources. In response to the event that the resources are stored in the resource pool, the relay node 03 generates signature information and sends a voting request for the signature information to the second node of the second blockchain 02 (the second node can be any node in the second blockchain 02, for example, the second node is node 5 in the second blockchain 02). The second node sends the voting request to other nodes in the second blockchain 02 (if the second node is node 5 in the second blockchain 02, the other nodes include at least one of nodes 1 to 4 in the second blockchain 02) and receives the voting results sent by the other nodes. If the second node confirms that the vote is passed based on the voting results sent by the other nodes, the resources are allocated to the second object from the resource pool of the second blockchain 02.

[0059] In the case of transferring resources between different blockchains, the signature information generated by the relay node 03 is crucial. If the signature information is tampered with, the resource transfer will fail, that is, the resources of the first object cannot be transferred to the second object. Based on this, it is necessary to test the blockchain by simulating the tampering of the signature information. In the related art, there are at least two ways to tamper with the signature information, which are respectively referred to as related technology 1 and related technology 2.

[0060] Related technology 1, the test equipment can intercept any data packet sent by the relay node 03, and determine whether the data packet includes a voting request for the signature information based on the protocol information of the relay node 03. If the data packet includes a voting request for the signature information, the data packet is subjected to packet parsing processing such as unpacking, subpackaging, and grouping to obtain the signature information, and the private key, signature algorithm, and resource transfer information are obtained based on the signature information. By tampering with at least one of the private key, signature algorithm, and resource transfer information, and using the tampered content and other untampered content to generate the tampered signature information. This method of tampering with the signature information requires the test equipment to understand the protocol information of the relay node 03. In addition, it also involves packet parsing technology, signature parsing technology, etc., which makes the technology difficult to implement, resulting in low testing efficiency of the blockchain.

[0061] Related technology 2, additional deployment of relay nodes that can tamper with signature information, which can be called abnormal relay nodes. In other words, it is necessary to encode the source code that can tamper with the signature information, and deploy the abnormal relay node based on the source code, so that the abnormal relay node can tamper with the signature information. This method of additionally deploying abnormal relay nodes is not only costly to implement, but also takes a long time to encode the source code, resulting in low efficiency in blockchain testing.

[0062] The embodiment of the present application provides a blockchain testing method, which can be applied to the above implementation environment, and can test the scenario of resource transfer from a first object belonging to a first blockchain to a second object belonging to a second blockchain, thereby improving the testing efficiency. Figure 2 The flowchart of a blockchain testing method provided in the embodiment of the present application is shown as an example. The method provided in the embodiment of the present application is executed by the testing device 04, wherein the electronic device mentioned below refers to the testing device 04. Figure 2 As shown, the method includes the following steps.

[0063] Step 201: Obtain a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain.

[0064] The embodiments of the present application do not limit the method for obtaining resource transfer use cases. Exemplarily, the electronic device can obtain the resource transfer use cases input by the test object, or the electronic device can read the resource transfer use cases from the storage device, or the electronic device can receive the resource transfer use cases sent by other devices.

[0065] The resource transfer use case includes the information of the first blockchain, the information of the first object, the information of the second blockchain, the information of the second object, and the number of target resources. This information describes the scenario of resource transfer (i.e., cross-chain resource transfer) between two objects belonging to different chains, and the target resource is the resource transferred from the first object to the second object. Among them, the information of the first blockchain includes at least one of the number of nodes in the first blockchain, the protocol information supported by the first blockchain, and the number of resources in the resource pool of the first blockchain. The information of the first object includes at least one of the identification information of the first object, the number of resources held by the first object, and the information that the first object belongs to the first blockchain. Similarly, the information of the second blockchain includes at least one of the number of nodes in the second blockchain, the protocol information supported by the second blockchain, and the number of resources in the resource pool of the second blockchain. The information of the second object includes at least one of the identification information of the second object, the number of resources held by the second object, and the information that the second object belongs to the second blockchain.

[0066] Step 202: Obtain source code of the relay node, where the source code is used to obtain reference content related to the signature information.

[0067] In the embodiment of the present application, the electronic device is configured with project management software, wherein the function, name, etc. of the project management software are not limited in the embodiment of the present application. The electronic device can obtain the project file of the relay node through the project management software, and the project file includes the source code of the relay node. The source code can obtain the reference content related to the signature information, and generate the second signature information according to the reference content, and the second signature information is the signature information before tampering. Among them, the information of the reference content and the generation method of the second signature information are described below, which will not be repeated here.

[0068] In general, an executable file corresponding to the source code can be generated based on the source code of the relay node, and the executable file corresponding to the source code can be deployed on the relay node. In each optional embodiment of the present application, the executable file corresponding to the source code can be referred to as an original executable file. The original executable file is a binary file corresponding to the source code that can be loaded and run by the operating system of the relay node. The original executable file has the same function as the source code. Therefore, when the relay node runs the original executable file, it can obtain the reference content and generate the second signature information according to the reference content.

[0069] Step 203: inserting a stub code into the source code to obtain a test code, wherein the stub code is used to tamper with the reference content obtained through the source code to obtain a tampered content, and the test code is used to generate first signature information based on the tampered content according to the source code.

[0070] In an embodiment of the present application, the stub code may tamper with the reference content to obtain the tampered content. The embodiment of the present application does not limit the tampering method. For example, the tampered content may be configured as a set value. In this case, the reference content may be tampered with to the set value, for example, the reference content may be tampered with to 100 or 00. The association relationship between the tampered content and the reference content may also be configured. In this case, the tampered content may be generated based on the reference content. For example, the reference content may be multiplied by a set weight to obtain the tampered content, and then the reference content may be tampered with to the tampered content. The tampered content may also be randomly generated, and the reference content may be tampered with to the tampered content.

[0071] It is understandable that the test code is obtained by inserting the stub code into the source code, so that the test code includes the source code and the stub code. The source code can obtain the reference content and generate the second signature information based on the reference content. After the stub code tampers the reference content obtained through the source code to obtain the tampered content, the source code can generate the first signature information based on the tampered content, the first signature information is the signature information after the tampering, and the second signature information is the signature information before the tampering. In other words, the test code can obtain the reference content, tamper the reference content into the tampered content, and generate the first signature information based on the tampered content.

[0072] In a possible implementation, the reference content includes the private key, signature algorithm and resource transfer information of the relay node, and step 203 includes steps 2031 to 2032 (not shown in the figure).

[0073] In the embodiment of the present application, the relay node can generate a key pair through a key algorithm, and the key pair includes a public key and a private key, wherein the public key of the relay node is made public, while the private key of the relay node is not made public. In other words, any node in the first blockchain, any node in the second blockchain, the test equipment, etc. can obtain the public key of the relay node, but cannot obtain the private key of the relay node. The embodiment of the present application does not limit the key algorithm.

[0074] The signature algorithm is an algorithm used to generate signature information. The embodiment of the present application does not limit the signature algorithm. Exemplarily, the signature algorithm can be any one of the Rivest-Shamir-Adleman (RSA) algorithm, the Message-Digest Algorithm 5 (MD5), and the Digital Signature Algorithm (DSA).

[0075] The resource transfer information is used to describe the resource transfer from the first object to the second object. Optionally, the resource transfer information includes at least one item of information such as information of the first blockchain, information of the second blockchain, information of the first object, information of the second object, the number of target resources, and the type of target resources. Such information can be found in the description of step 201 and will not be repeated here.

[0076] Step 2031, obtaining a configuration file, the configuration file including the stub code and the insertion position of the stub code in the source code, the stub code is used to tamper with at least one of the private key, the signature algorithm and the resource transfer information.

[0077] The embodiments of the present application do not limit the method for obtaining the configuration file. Exemplarily, the electronic device may obtain an input configuration file, or the electronic device may read the configuration file from a storage device, or the electronic device may receive a configuration file sent by other devices.

[0078] Optionally, the configuration file includes an instrumentation code. The instrumentation code may tamper with the private key of the relay node, for example, the instrumentation code may tamper with the private key of the relay node into setting data or into the private key of the test device. The instrumentation code may also tamper with the signature algorithm, for example, the instrumentation code may tamper with the RSA algorithm into the DSA algorithm. The instrumentation code may also tamper with the resource transfer information, that is, the instrumentation code may tamper with at least one of the information of the first object, the information of the second object, the information of the first blockchain, the information of the second blockchain, the number of target resources, the type of target resources, etc.

[0079] By tampering at least one of the private key, signature algorithm and resource transfer information through the stub code, a combination of multiple tampering scenarios can be achieved. In subsequent testing based on the stub code, various tampering scenarios can be tested, making the test more comprehensive and more accurate.

[0080] One possible instrumentation code is shown below.

[0081]

[0082] The above-mentioned plug-in code is used to tamper with the resource transfer information. Optionally, DepositNonce is used to refer to the number of target resources, so the above-mentioned plug-in code is used to tamper with the number of target resources to a fixed value of 1. In addition, relayer_sign_content_error in the above-mentioned plug-in code is the name of the plug-in code.

[0083] Optionally, the configuration file also includes the insertion position of the stub code in the source code. In an exemplary embodiment, the insertion position includes the file name of the source code, the function name in the source code, the number of lines in the function corresponding to the function name, etc. The source code is located by the file name of the source code, and the position of the stub code when it is inserted into the source code is located by the function name in the source code and the number of lines in the corresponding function. For example, the insertion position includes the function name VoteProposal in the source code and the number of lines in the function 8, indicating that the stub code is inserted after the 8th line of code in the VoteProposal function of the source code.

[0084] It is understandable that the configuration file may also include other information besides the plug-in code and the insertion position. For example, the configuration file may also include the name of the plug-in code, the function name in the plug-in code, the function of the plug-in code, etc.

[0085] Step 2033: insert the stub code into the source code based on the insertion position to obtain the test code.

[0086] In the embodiment of the present application, the insertion position is used to locate the position of the plug-in code when it is inserted into the source code. Therefore, the plug-in code can be inserted into the source code based on the insertion position to obtain the source code after the plug-in code is inserted. The source code after the plug-in code is inserted is the test code. A possible test code is shown below.

[0087]

[0088] Step 204: When the relay node generates the first signature information based on the test code, a scenario of transferring resources from the first object to the second object is tested to obtain a first test result.

[0089] In an embodiment of the present application, a test environment can be configured by a test device, and the test environment includes a first blockchain, a second blockchain, and a relay node. The first blockchain includes multiple nodes, any node in the first blockchain and any node other than the node in the first blockchain can be connected or not connected, and any node in the first blockchain is connected to at least one node other than the node in the first blockchain. The second blockchain includes multiple nodes, any node in the second blockchain and any node other than the node in the second blockchain can be connected or not connected, and any node in the second blockchain is connected to at least one node other than the node in the second blockchain. There is at least one node in the first blockchain connected to the relay node, and any node in the first blockchain is connected or not connected to the relay node, there is at least one node in the second blockchain connected to the relay node, and any node in the second blockchain is connected or not connected to the relay node.

[0090] In an exemplary embodiment, the test environment also includes other information in addition to the first blockchain, the second blockchain, and the relay node. Optionally, the test environment also includes smart contracts used by the first blockchain, smart contracts used by the second blockchain, etc. Among them, a smart contract is a computer protocol designed to propagate, verify, or execute a contract in an information-based manner. When any node in the first blockchain transfers resources to a node other than the node in the first blockchain (which may be a node in the first blockchain or a node in the second blockchain), it is necessary to construct a resource transfer event based on the smart contract used by the first blockchain. Similarly, when any node in the second blockchain transfers resources, it is also necessary to construct a resource transfer event based on the smart contract used by the second blockchain. This part of the content can be seen in Figure 3 , Figure 4 The description of is not repeated here.

[0091] Optionally, the test device is configured with test management software, which can be used to configure the test environment. The name, identification, number of nodes, smart contracts used, and other information of the first blockchain can be entered in the test management software to configure the first blockchain. Similarly, the name, identification, number of nodes, smart contracts used, and other information of the second blockchain can be entered in the test management software to configure the second blockchain. In addition, the name, identification, and other information of the relay node can be entered in the test management software to configure the relay node. Since then, the test environment has been configured through the test device.

[0092] Then, the test is performed based on the test code and the resource transfer case on the basis of the test environment through the test device to obtain the first test result. In the embodiment of the present application, the test code is used to generate the first signature information, and the test code can be deployed on the relay node. The resource transfer case is used to describe the scenario of resource transfer from the first object to the second object. Therefore, the test is performed based on the test code and the resource transfer case on the basis of the test environment, which is equivalent to testing the scenario of resource transfer from the first object to the second object when the relay node generates the first signature information based on the test code.

[0093] Since the first object belongs to the first blockchain and the second object belongs to the second blockchain, the present application embodiment involves the content of cross-chain resource transfer. In blockchain technology, cross-chain resource transfer can be achieved through cross-chain bridge technology. In order to facilitate the understanding of the content of cross-chain resource transfer, the following is combined with Figure 3 and Figure 4 To explain.

[0094] See also Figure 3 , Figure 3 It is a framework diagram of a cross-chain resource transfer realized through a cross-chain bridge technology provided by an embodiment of the present application, including a first blockchain, a second blockchain, a relay node and a terminal device, wherein the relay node is communicatively connected with the first blockchain and the second blockchain, and the terminal device is communicatively connected with the first blockchain and the second blockchain.

[0095] In the embodiment of the present application, the software framework related to the cross-chain service on the terminal device can be roughly divided into a cross-chain service front end and a cross-chain service back end, wherein the cross-chain service includes interfaces, programs, codes, pages, etc. related to resource transfer. The cross-chain service front end is used to provide a display page to the user object, so that the user object can interact with the terminal device on the basis of the display page and perform related operations of cross-chain resource transfer. The cross-chain service back end includes programs, codes, interfaces, etc. that support the cross-chain service front end. In the embodiment of the present application, the cross-chain service back end includes a smart contract deployment unit and a smart contract distinguishing unit. The smart contract deployment unit is used to deploy various smart contracts. The smart contract distinguishing unit is used to distinguish different smart contracts.

[0096] The user object can perform cross-chain resource transfer related operations on the terminal device. The terminal device can be a node in the first blockchain. In this case, the user object is an object belonging to the first blockchain, that is, the user object is the first object mentioned above. The terminal device can also be a node in the second blockchain. In this case, the user object is an object belonging to the second blockchain, that is, the user object is the second object mentioned above.

[0097] If the object to be used is the first object, when the object to be used performs the related operations of cross-chain resource transfer to the second object on the terminal device, it is equivalent to the object to authorize the first blockchain to initiate a cross-chain task. If the object to be used is the second object, when the object to be used performs the related operations of cross-chain resource transfer to the first object on the terminal device, it is equivalent to the object to authorize the second blockchain to initiate a cross-chain task. It should be noted that the cross-chain task mentioned in the embodiment of the present application refers to the transfer of resources between two objects belonging to different blockchains, for example, the first object belonging to the first blockchain transfers resources to the second object belonging to the second blockchain.

[0098] In the embodiment of the present application, a cross-chain bridge refers to a network connecting two different blockchains. The service that realizes resource transfer between two objects belonging to different blockchains through a cross-chain bridge is called a cross-chain bridge service, and the relay node supports the cross-chain bridge service. The cross-chain bridge service includes cross-chain message acquisition, cross-chain task processing, cross-chain task management, etc. Among them, cross-chain message acquisition is to obtain messages about cross-chain tasks sent by the first blockchain or the second blockchain. Cross-chain task processing is to perform operations related to cross-chain tasks, such as generating signature information, sending voting requests for signature information, etc. Cross-chain task management is to manage cross-chain tasks, including storing and recording cross-chain tasks, judging whether cross-chain tasks are completed, etc. Optionally, there is at least one cross-chain task, and whether the cross-chain task is completed can be judged randomly or in the order in which the cross-chain tasks are generated.

[0099] For any node in the first blockchain, the software framework of the node includes a cross-chain bridge contract, which is a proxy contract for the cross-chain bridge service. The node supports registering the management unit (Handler) contract of the smart contract in the cross-chain bridge contract, and supports upgrading the Handler contract of the smart contract. Of course, the node also supports releasing the Handler contract of the smart contract in the cross-chain bridge contract. The cross-chain bridge contract supports multi-signature management. Multi-signature management is to manage the signature information generated by different signature algorithms, including signature verification, storage records, etc. The node can verify the signature through multi-signature management and forward the message to the corresponding management unit after the signature verification passes (that is, it is determined that the signer has the authority).

[0100] There is at least one smart contract, and each smart contract corresponds to a management unit Handler. Figure 3 , smart contract 1 and its corresponding management unit 1, smart contract 2 and its corresponding management unit 2 are shown. The management unit of the smart contract can receive the cross-chain message of the corresponding smart contract and call the corresponding smart contract for casting processing.

[0101] It should be noted that any node in the second blockchain is similar to any node in the first blockchain, and will not be repeated here.

[0102] based on Figure 3 The framework diagram shown is as follows. The following describes the content of cross-chain resource transfer. Figure 4 , Figure 4 It is a flow chart of a cross-chain resource transfer provided in an embodiment of the present application, and the flow includes steps 1 to 15 as shown below.

[0103] Step 1. The first object performs a resource transfer operation to the second object on the first node. In this case, the first node can enable the cross-chain bridge contract to obtain the target resource.

[0104] Step 2. After the first node enables the cross-chain bridge contract to obtain the target resource, it records the target resource in the cross-chain bridge contract.

[0105] Step 3. The first node determines the type of the target resource based on the cross-chain bridge contract, determines the smart contract corresponding to the target resource based on the type of the target resource, and enables the management unit corresponding to the smart contract to obtain the target resource.

[0106] Step 4. After the first node enables the management unit to obtain the target resource, it records the target resource.

[0107] Step 5. The first node enables the management unit to interact with the smart contract so that the smart contract can obtain the target resources.

[0108] Step 6. The first node stores the target resource in the resource pool of the first blockchain through a smart contract.

[0109] Step 7. The first node generates feedback information through a smart contract and enables the management unit to obtain the feedback information. The feedback information is information about the feedback target resource stored in the resource pool of the first blockchain, which is equivalent to a resource transfer event.

[0110] Step 8. The first node enables the management unit to interact with the cross-chain bridge contract so that the cross-chain bridge contract can obtain feedback information.

[0111] Step 9. The first node sends feedback information to the first object through the cross-chain bridge contract.

[0112] Step 10. The relay node communicates with the cross-chain bridge contract of the first node through the cross-chain bridge service. When the cross-chain bridge contract receives feedback information, it is equivalent to the cross-chain bridge contract receiving a resource transfer event. At this time, the relay node captures the resource transfer event through the communication between the cross-chain bridge service and the cross-chain bridge contract.

[0113] Step 11. The relay node generates signature information through the cross-chain bridge service and sends a voting request for the signature information to the cross-chain bridge contract of the second node.

[0114] Step 12. The second node forwards the voting request to other nodes in the second blockchain except the second node through the cross-chain bridge contract and waits for other nodes to feedback the voting results.

[0115] Step 13. The second node receives the voting results fed back by other nodes through the cross-chain bridge contract, and determines the voting pass information based on the voting results fed back by other nodes. In this case, the cross-chain bridge contract communicates with the management unit of the second node, so that the management unit of the second node receives the voting pass information. It can be understood that when cross-chain resource transfer is performed, the management unit of the second node and the management unit of the first node correspond to the same smart contract.

[0116] Step 14. The management unit of the second node sends voting approval information to the smart contract of the second node.

[0117] Step 15. The second node allocates the target resource from the resource pool of the second blockchain to the second object through the smart contract. At this point, it is equivalent to the first object transferring the target resource to the second object.

[0118] From steps 1 to 15, it can be concluded that the first node receives the target resource through the cross-chain bridge contract, management unit and smart contract, stores the target resource in the resource pool of the first blockchain, and generates a resource transfer event, which describes the transfer of the target resource from the first object to the second object, and the target resource has been stored in the resource pool of the first blockchain. The relay node captures the resource transfer event generated by the first node through the cross-chain bridge service, generates signature information and sends a voting request for the signature information to the second node. The second node receives and forwards the voting request, receives the voting result and allocates the target resource from the resource pool of the second blockchain to the second object after the vote is passed through the cross-chain bridge contract, management unit and smart contract.

[0119] In the embodiment of the present application, if the relay node deploys the test code, the relay node can generate the first signature information based on the test code. In this case, testing the scenario of resource transfer from the first object to the second object is equivalent to Figure 3 , Figure 4Based on the content of cross-chain resource transfer, the first test result is obtained.

[0120] In a possible implementation, step 204 includes steps 2041 to 2043 (not shown in the figure).

[0121] Step 2041, generating a test executable file based on the test code.

[0122] In the embodiment of the present application, the test device can receive the user's compile operation for the test code, compile the test code, and obtain a test executable file. The code in the test executable file is binary code, which is the basis for electronic equipment to process data and store data. Therefore, the test executable file is a file corresponding to the test code that can be loaded and executed by the operating system of the relay node.

[0123] In a possible implementation, step 2041 includes steps 20411 to 20413 (not shown in the figure).

[0124] Step 20411, obtain the first instruction for activating the stub code in the test code.

[0125] In an embodiment of the present application, the electronic device may obtain a first instruction input by a user, or the electronic device may receive an operation by a user to activate the plug-in code in the test code, and generate the first instruction in response to the operation. For example, the electronic device displays an activation control, and when the user triggers the activation control, it is equivalent to the user performing an operation to activate the plug-in code in the test code, and the electronic device may obtain the operation and respond to generate the first instruction.

[0126] The embodiment of the present application does not limit the content of the first instruction. Exemplarily, the first instruction includes a part for indicating the instrumentation code and a part for indicating the activation operation, and the instrumentation code in the test code is activated through these two parts. For example, the first instruction is: $GOPATH / src / github.com / pingcap / failpoint / bin / failpoint-ctlenable. Among them, "failpoint" is the name of the instrumentation code, which is the part used to indicate the instrumentation code. "enable" is an enable instruction, and "failpoint-ctl enable" is used to activate the instrumentation code. Therefore, "failpoint-ctl enable" is the part used to indicate the activation operation of the instrumentation code.

[0127] Step 20412: Generate a first intermediate file based on the first instruction and the test code, where the first intermediate file is used to describe the source code, the test code, and the modifications made when the stub code is inserted into the source code.

[0128] In an embodiment of the present application, the electronic device runs the test code based on the first instruction to generate a first intermediate file, which is an intermediate representation generated after analyzing the test code based on the first instruction. The first intermediate file includes multiple sub-files, and the contents of some sub-files are used to describe the source code, the test code, and the modifications made when the stub code is inserted into the source code. Exemplarily, the first intermediate file includes the sub-files shown below.

[0129] binding_failpoint_binding_go

[0130] chain_voter.go

[0131] chain_router.go

[0132] chain_watcher.go

[0133] events.go

[0134] relayer.go

[0135] utils.go

[0136] utils.go_failpoint_stash_

[0137] Among them, the "binding_failpoint_binding_go" subfile and the "utils.go_failpoint_stash_" subfile include content for describing the source code, content for describing the test code, and content for describing the modifications made when the stub code is inserted into the source code.

[0138] Step 20413, determine the test executable file based on the first intermediate file.

[0139] In an embodiment of the present application, the electronic device displays a compilation control. When the user triggers the compilation control, it is equivalent to the user triggering an operation to compile the first intermediate file. The electronic device generates a test executable file in response to the operation to compile the first intermediate file.

[0140] Step 2042, deploy the test executable file on the relay node.

[0141] In an embodiment of the present application, the test executable file can be input into the test management software, and the relay node and the test executable file can be associated, so as to realize the deployment of the test executable file on the relay node. The test executable file is a binary file corresponding to the test code and can be loaded and run by the operating system of the relay node, and the test executable file has the same function as the test code. Therefore, when the test executable file is deployed on the relay node, when the relay node runs the test executable file, it is equivalent to the relay node executing the running logic of the test code, and the reference content can be obtained, the reference content is tampered to obtain the tampered content, and the first signature information is generated according to the tampered content.

[0142] Step 2043: When the relay node generates the first signature information based on the test executable file, a scenario of transferring resources from the first object to the second object is tested to obtain a first test result.

[0143] In the embodiment of the present application, the resource transfer case can be input into the test management software, and the first blockchain, the second blockchain and the relay node can be associated, so as to realize the deployment of the resource transfer case in the test environment, so as to execute the resource transfer from the first object belonging to the first blockchain to the second object belonging to the second blockchain in the test environment. The log information generated by the node in the first blockchain, the log information generated by the node in the second blockchain and the log information generated by the relay node during the resource transfer process are obtained, and the aforementioned log information is analyzed to obtain the first test result.

[0144] See also Figure 5 , Figure 5 It is a schematic diagram of a display interface provided in an embodiment of the present application. Figure 5 The display interface shown includes a document display area, a use case display area, and a result display area.

[0145] The document display area is used to display at least one document, such as Figure 5 It is shown that the document display area displays documents 1 to 4. For any document, if the document includes at least one sub-document, the sub-documents included in any document can be displayed in the document display area, for example Figure 5 The document 4 displayed in the document display area includes sub-document 1, sub-document 2 and a document of a resource transfer use case. It is understandable that by clicking the expansion control ">" corresponding to any document, the sub-documents included in the document can be displayed in the document display area. At this time, the expansion control ">" corresponding to the document is changed to a folding control "∨". It is also possible to click the folding control "∨" corresponding to any document to display only the document in the document display area without displaying the sub-documents included in the document. At this time, the folding control "∨" corresponding to the document is changed to an expansion control ">".

[0146] The use case display area is used to display resource transfer use cases. For example, Figure 5 The use case display area shows a resource transfer use case, and the resource transfer use case is used to describe the transfer 200 of the A chain user2 (corresponding to the first object mentioned above) to the B chain user2 (corresponding to the second object mentioned above). It should be noted that, Figure 5 The resource transfer use case shown is for illustration only, and the content of the resource transfer use case may not represent an actual resource transfer use case.

[0147] The result display area is used to display the test results. For example, Figure 5 The result display area shows that before the transfer, the balance of user2 in chain A is 378 (corresponding to the number of resources held by the first object before the resource transfer), before the transfer, the balance of user2 in chain B is 530 (corresponding to the number of resources held by the second object before the resource transfer), after the transfer, the balance of user2 in chain A is 178 (corresponding to the number of resources held by the first object after the resource transfer), before the transfer, the balance of user2 in chain B is 730 (corresponding to the number of resources held by the second object after the resource transfer). It should be noted that Figure 5 The test results shown are for illustration only, and the content of the test results may not represent the actual test results.

[0148] In implementation method A, step 2043 includes steps A1 to A3 (not shown in the figure).

[0149] Step A1, obtaining a second instruction for running an executable file corresponding to the stub code, wherein the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the stub code.

[0150] In an embodiment of the present application, the electronic device may obtain a second instruction input by a user, or the electronic device may receive an operation triggered by a user to run an executable file corresponding to the plug-in code in the test executable file, and generate a second instruction in response to the operation. For example, the electronic device displays a run control, and when the user triggers the run control, it is equivalent to the user triggering an operation to run the executable file corresponding to the plug-in code, and the electronic device generates a second instruction in response to the operation.

[0151] The embodiments of the present application do not limit the content of the second instruction. Exemplarily, the second instruction includes at least one of a part for indicating a test executable file, a part for indicating an instrumentation code, a part for indicating running an executable file corresponding to the instrumentation code, a part for indicating an executable file corresponding to the instrumentation code, and a part for indicating issuing a network request. The execution of the executable file corresponding to the instrumentation code in the test executable file is indicated by at least one of the foregoing parts.

[0152] For example, the second instruction is: curl-XPUT-d'return(true)'{yourproject} / {package} / relayer_sign_content_error. Among them, "curl" is the part used to indicate the issuance of a network request, which can be regarded as a Uniform Resource Locator (URL) tool in the client (Client, C), which is used to issue a network request and receive data returned based on the network request. XPUT refers to running a complete document. Since the test executable file includes the executable file corresponding to the instrumentation code, running a complete document includes running the executable file corresponding to the instrumentation code in the test executable file, that is, XPUT is the part used to indicate the execution of the executable file corresponding to the instrumentation code. d'return(true)' represents the return of running data (Data). yourproject is the part used to indicate the test executable file, and yourproject can be the file name of the test executable file. package is the part used to indicate the executable file corresponding to the instrumentation code, wherein the executable file corresponding to the instrumentation code is a data packet, so package can be the package name of the data packet corresponding to the instrumentation code. relayer_sign_content_error is a portion for indicating the instrumentation code, and relayer_sign_content_error is the name of the instrumentation code mentioned above.

[0153] Step A2, when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the plug-in code based on the second instruction to generate the first signature information, the scenario of resource transfer from the first object to the second object is tested to obtain a first test log, and the first test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the executable file corresponding to the plug-in code is run.

[0154] In the embodiment of the present application, after the test device obtains the second instruction, it can forward the second instruction to the relay node. Based on the second instruction, the relay node runs the executable file corresponding to the source code and the executable file corresponding to the stub code in the process of running the test executable file.

[0155] In the case where the relay node runs the executable file corresponding to the source code and the executable file corresponding to the plug-in code, the test device can receive the test operation triggered by the test object, and in response to the test operation, send an instruction to run the resource transfer use case to the first node in the first blockchain. Since the resource transfer use case is used to describe the scenario of transferring resources from the first object to the second object, the first node stores the target resource in the resource pool of the first blockchain in response to the instruction to run the resource transfer use case. In this process, the first node can generate log information. For the sake of distinction, the log information generated by the first node in this process is called the first log information. The first log information is the running information of the node (i.e., the first node) in the first blockchain when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the plug-in code. The running information includes the information of the first node obtaining the resource transfer operation and the content of the first node storing the target resource in the resource pool of the first blockchain.

[0156] Next, the relay node generates the first signature information in response to the event that the resource is stored in the resource pool, and sends a voting request for the first signature information to the second node of the second blockchain. During this process, the relay node can generate log information. For the sake of distinction, the log information generated by the relay node in this process is called the second log information. The second log information is the running information of the relay node when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the stub code. The running information includes the content of the first signature information generated by the relay node and the content of the voting request sent by the relay node to the node in the second blockchain (i.e., the second node) for the first signature information.

[0157] Afterwards, the second node sends a voting request to other nodes in the second blockchain except the second node. After receiving the voting request, the other nodes verify the first signature information based on the public key of the relay node. If the verification is successful, the other nodes send a vote of approval to the second node, that is, the voting result sent by the other nodes to the second node represents approval. If the verification fails, the other nodes send a vote of opposition to the second node, that is, the voting result sent by the other nodes to the second node represents opposition. There are multiple other nodes, and the second node counts the relationship between the number of votes of approval and the number of other nodes. If the number of votes of approval and the number of other nodes meet the consensus requirements, the second node confirms that the vote is passed and divides the target resources from the resource pool of the second blockchain to the second object. If the number of votes of approval and the number of other nodes do not meet the consensus requirements, the second node confirms that the vote is not passed. At this time, the second node can feedback information about the unsuccessful resource transfer to the relay node. In this process, the second node can generate log information. For the sake of distinction, the log information generated by the second node in this process is called the third log information. The third log information is the operation information of the node (i.e., the second node) in the second blockchain when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the stub code. The operation information includes the content of the second node sending a voting request to other nodes, the content of the second node receiving the voting results sent by other nodes, the content of the second node counting the relationship between the number of affirmative votes and the number of other nodes, and the content of the second node dividing the target resources from the resource pool of the second blockchain to the second object, or the second node feedbacks the information of unsuccessful resource transfer to the relay node.

[0158] The embodiments of the present application do not limit the consensus requirements. For example, the consensus requires Byzantine Fault Tolerance (BFT) consensus. Byzantine Fault Tolerance consensus is a consensus algorithm. Assuming that a distributed system has n nodes, when the number of abnormal nodes in the distributed system does not exceed m (n≥3m+1), the distributed system can operate normally; when the number of abnormal nodes in the distributed system exceeds m, the distributed system cannot operate normally. In other words, for a distributed system with n nodes, a maximum of n / 3 nodes are allowed to be abnormal. In an embodiment of the present application, if the number of other nodes is n, when the number of negative votes does not exceed m, that is, the number of votes in favor is greater than nm, the second node confirms that the vote is passed; when the number of negative votes exceeds m, that is, the number of votes in favor is not greater than nm, the second node confirms that the vote is not passed.

[0159] It is understandable that if the second node feeds back information about unsuccessful resource transfer to the relay node, it means that the second node confirms that the vote for the first signature information has not passed. At this time, the relay node can feed back information about unsuccessful resource transfer to the first node. After the first node receives the information, it can divide the target resource from the resource pool of the first blockchain to the first object. In this case, the first log information may also include the first node receiving information about unsuccessful resource transfer and the first node dividing the target resource from the resource pool of the first blockchain to the first object. The second log information may also include the relay node receiving information about unsuccessful resource transfer sent by the second node and the relay node sending information about unsuccessful resource transfer to the first node.

[0160] Optionally, the source code of the relay node includes a blocking function for cross-chain resource transfer. The blocking function is used to return blocking information after the relay node obtains that the vote for the first signature information fails, and the blocking information is used to indicate that the resource transfer is unsuccessful. A possible blocking function is shown below.

[0161] if err! = nil{

[0162] logger.Errorf("wait for tx recipe error: %v", err)

[0163] return err

[0164] }

[0165] In an embodiment of the present application, the first test log includes at least one of the first log information, the second log information, and the third log information mentioned above. It is understandable that the first test log may also include fourth log information, and the fourth log information is the running information of other nodes when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the stub code. The running information of other nodes includes the content of the first signature information verified by other nodes based on the public key of the relay node, the voting results sent by other nodes based on the verification results, etc.

[0166] Step A3: determining a first test result based on the first test log.

[0167] In an embodiment of the present application, the electronic device can analyze the first test log to obtain a first analysis result, where the first analysis result includes at least one of the following: the number of resources held by the first object before resource transfer, the number of resources held by the first object after resource transfer, the number of resources held by the second object before resource transfer, the number of resources held by the second object after resource transfer, the number of resources in the resource pool of the first blockchain before resource transfer, the number of resources in the resource pool of the first blockchain after resource transfer, the number of resources in the resource pool of the second blockchain before resource transfer, the number of resources in the resource pool of the second blockchain after resource transfer, the change in resources held by the first object before and after resource transfer, the change in resources held by the second object before and after resource transfer, the change in resources in the resource pool of the first blockchain before and after resource transfer, and the change in resources in the resource pool of the second blockchain before and after resource transfer.

[0168] In the embodiment of the present application, the first analysis result can be used as the first test result. Alternatively, the first test result is determined based on the first analysis result, and the first test result indicates whether the test passes or fails when the executable file corresponding to the source code and the executable file corresponding to the stub code are run by the relay node to generate the first signature information.

[0169] The embodiment of the present application does not limit the method of determining the first test result based on the first analysis result. Exemplarily, if the number of target resources is not 0, and the decrease in the resources held by the first object before and after the resource transfer is 0, the increase in the resources in the resource pool of the first blockchain before and after the resource transfer is 0, the increase in the resources held by the second object before and after the resource transfer is 0, and the decrease in the resources in the resource pool of the second blockchain before and after the resource transfer is 0, then the first test result indicates that the test is passed when the executable file corresponding to the source code and the executable file corresponding to the plug-in code are run by the relay node to generate the first signature information. If the number of target resources is 0, or the change in the resources before and after the resource transfer is not 0, for example, the resources held by the second object before and after the resource transfer increase by 10, and the resources in the resource pool of the second blockchain before and after the resource transfer increase by 10, then the first test result indicates that the test is not passed when the executable file corresponding to the source code and the executable file corresponding to the plug-in code are run by the relay node to generate the first signature information.

[0170] Step 205: Determine the blockchain test result based on the first test result.

[0171] In the embodiment of the present application, the first test result can be used as the blockchain test result, or, when the first test result is the first analysis result, the blockchain test result can be determined based on the first test result. The blockchain test result represents whether the test passed or failed. Among them, the method for determining the blockchain test result is similar to the method for determining the first test result based on the first analysis result mentioned above, and will not be repeated here.

[0172] In implementation B, the test code is also used to generate second signature information based on the source code and the reference content. Step 205 includes steps 2051 to 2052 (not shown in the figure).

[0173] Step 2051: When the relay node generates the second signature information based on the test code, a scenario of transferring resources from the first object to the second object is tested to obtain a second test result.

[0174] Since the relay node deploys the test code, and the test code includes the source code. Since the source code is used to obtain the reference content and generate the second signature information based on the reference content, the relay node can generate the second signature information based on the test code. In this case, testing the scenario of resource transfer from the first object to the second object is equivalent to Figure 3 , Figure 4 Based on the content of cross-chain resource transfer, the second test result is obtained.

[0175] In a possible implementation, step 2051 includes steps B1 to B3 (not shown in the figure).

[0176] Step B1, obtaining a third instruction for stopping the execution of the executable file corresponding to the stub code, the test code is used to generate a test executable file deployed on the relay node, the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the stub code.

[0177] In an embodiment of the present application, the electronic device may obtain a third instruction input by a user, or the electronic device may receive an operation triggered by a user to stop the execution of an executable file corresponding to the plug-in code in the test executable file, and generate a third instruction in response to the operation. For example, the electronic device displays a stop operation control, and when the user triggers the stop operation control, it is equivalent to the user triggering an operation to stop the execution of the executable file corresponding to the plug-in code, and the electronic device generates a third instruction in response to the operation.

[0178] The embodiments of the present application do not limit the content of the third instruction. Exemplarily, the third instruction includes at least one of a part for indicating a test executable file, a part for indicating an instrumentation code pair, a part for indicating stopping running the executable file corresponding to the instrumentation code, a part for indicating the executable file corresponding to the instrumentation code, and a part for indicating issuing a network request. The at least one of the foregoing parts is used to indicate stopping running the executable file corresponding to the instrumentation code in the test executable file.

[0179] For example, the third instruction is: curl-XDELETE-d{yourproject} / {package} / relayer_sign_content_error. Among them, "curl" is the part used to indicate the issuance of a network request, which can be regarded as a Uniform Resource Locator (URL) tool in the client (Client, C), used to issue a network request and receive data returned based on the network request. XDELETE refers to deleting a document. In the third instruction, it refers to deleting the executable file corresponding to the plug-in code in the test executable file, that is, XDELETE is the part used to indicate the stop running the executable file corresponding to the plug-in code. d represents the returned running data (Data). yourproject is the part used to indicate the test executable file, and yourproject can be the file name of the test executable file. package is the part used to indicate the executable file corresponding to the plug-in code, wherein the executable file corresponding to the plug-in code is a data packet, so package can be the package name of the data packet corresponding to the plug-in code. relayer_sign_content_error is the part used to indicate the plug-in code, and relayer_sign_content_error is the name of the plug-in code mentioned above.

[0180] Step B2, when the relay node runs the executable file corresponding to the source code based on the third instruction to generate the second signature information, the scenario of resource transfer from the first object to the second object is tested to obtain a second test log, and the second test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the executable file corresponding to the plug-in code is stopped.

[0181] In the embodiment of the present application, after the test device obtains the third instruction, it can forward the third instruction to the relay node. Based on the third instruction, the relay node stops running the executable file corresponding to the stub code in the test executable file during the running of the test executable file, and only runs the executable file corresponding to the source code.

[0182] When the relay node runs the executable file corresponding to the source code, the test device can receive the test operation triggered by the test object, and in response to the test operation, send an instruction to run the resource transfer case to the first node. Then, the first node, the relay node and the second node perform operations similar to step A2.

[0183] The second test log includes the fifth to seventh log information. The fifth log information is the operation information of the node (i.e., the first node) in the first blockchain when the relay node runs the executable file corresponding to the source code, and the operation information includes the information of the first node obtaining the resource transfer operation and the content of the first node storing the target resource in the resource pool of the first blockchain. The sixth log information is the operation information of the relay node when the relay node runs the executable file corresponding to the source code, and the operation information includes the content of the relay node generating the second signature information and the content of the relay node sending the voting request for the second signature information to the node in the second blockchain (i.e., the second node). The seventh log information is the operation information of the node (i.e., the second node) in the second blockchain when the relay node runs the executable file corresponding to the source code, and the operation information includes the content of the second node sending the voting request to other nodes, the content of the second node receiving the voting results sent by other nodes, the content of the second node counting the relationship between the number of affirmative votes and the number of other nodes, and the content of the second node dividing the target resource from the resource pool of the second blockchain to the second object or the second node feedback to the relay node that the resource transfer is unsuccessful.

[0184] It can be understood that if the second node feeds back information about unsuccessful resource transfer to the relay node, it means that the second node confirms that the vote for the first signature information has not passed. At this time, the fifth log information may also include information about the first node receiving unsuccessful resource transfer and the first node dividing the target resource from the resource pool of the first blockchain to the first object. The sixth log information may also include information about the relay node receiving unsuccessful resource transfer sent by the second node and information about the relay node sending unsuccessful resource transfer to the first node.

[0185] It is understandable that the second test log may also include the eighth log information, which is the operation information of other nodes when the relay node stops running the plug-in code. The operation information of other nodes includes the content of the second signature information verified by other nodes based on the public key of the relay node, the voting results sent by other nodes based on the verification results, etc.

[0186] Step B3: Determine a second test result based on the second test log.

[0187] In an embodiment of the present application, the electronic device can analyze the second test log to obtain a second analysis result. The second analysis result includes at least one of the following: the number of resources held by the first object before resource transfer, the number of resources held by the first object after resource transfer, the number of resources held by the second object before resource transfer, the number of resources held by the second object after resource transfer, the number of resources in the resource pool of the first blockchain before resource transfer, the number of resources in the resource pool of the first blockchain after resource transfer, the number of resources in the resource pool of the second blockchain before resource transfer, the number of resources in the resource pool of the second blockchain after resource transfer, the change in the resources held by the first object before and after resource transfer, the change in the resources held by the second object before and after resource transfer, the change in the resources in the resource pool of the first blockchain before and after resource transfer, and the change in the resources in the resource pool of the second blockchain before and after resource transfer.

[0188] In the embodiment of the present application, the second analysis result can be used as the second test result. Alternatively, the second test result is determined based on the second analysis result, and the second test result indicates whether the test passes or fails when the executable file corresponding to the source code is run by the relay node to generate the second signature information.

[0189] The embodiment of the present application does not limit the method of determining the second test result based on the second analysis result. Exemplarily, if the number of target resources is equal to the reduction in resources held by the first object before and after the resource transfer, equal to the increase in resources in the resource pool of the first blockchain before and after the resource transfer, equal to the increase in resources held by the second object before and after the resource transfer, and equal to the reduction in resources in the resource pool of the second blockchain before and after the resource transfer, then the second test result indicates that the test passed when the executable file corresponding to the source code is run by the relay node to generate the second signature information. If there are two unequal situations, for example, the resources held by the second object increase by 10 before and after the resource transfer, and the resources in the resource pool of the second blockchain increase by 10 before and after the resource transfer, then the second test result indicates that the test failed when the executable file corresponding to the source code is run by the relay node to generate the second signature information.

[0190] Step 2052, determine the blockchain test result based on the first test result and the second test result.

[0191] In an embodiment of the present application, the first test result and the second test result can be used as blockchain test results, that is, the blockchain test result includes the first test result and the second test result. Alternatively, when the first test result is the first analysis result and the second test result is the second analysis result, the conclusion corresponding to the first test result can be determined based on the first test result, and the conclusion corresponding to the second test result can be determined based on the second test result. The conclusion corresponding to the first test result and the conclusion corresponding to the second test result represent whether the test has passed or failed. Among them, the method for determining the conclusion corresponding to the first test result is similar to the method for determining the first test result based on the first analysis result mentioned above, and the method for determining the conclusion corresponding to the second test result is similar to the method for determining the second test result based on the second analysis result mentioned above, which will not be repeated here.

[0192] Then, the conclusion corresponding to the first test result and the conclusion corresponding to the second test result are merged to obtain the blockchain test result. Optionally, when the first test result or the conclusion corresponding to the first test result represents a test that passes, and the second test result or the conclusion corresponding to the second test result represents a test that passes, the blockchain test result represents a test that passes. If the first test result or the conclusion corresponding to the first test result represents a test that fails, but the second test result or the conclusion corresponding to the second test result represents a test that passes, or the first test result or the conclusion represents a test that fails, and the second test result or the conclusion represents a test that fails, or the first test result or the conclusion represents a test that passes, but the second test result or the conclusion corresponding to the second test result represents a test that fails, then the blockchain test result represents a test that fails.

[0193] In the embodiment of the present application, the second instruction controls the execution of the executable file corresponding to the plug-in code, and the third instruction controls the execution of the executable file corresponding to the plug-in code to stop the execution, thereby realizing dynamic triggering to run or stop the execution of the executable file corresponding to the plug-in code. Combined with the resource transfer use case, it is possible to flexibly test the scenarios where the signature is tampered with and the scenarios where the signature is not tampered with, thereby ensuring the diversity and comprehensiveness of the test and improving the accuracy of the test results.

[0194] In a possible implementation, step 205 also includes steps 206 to 208 (not shown in the figure).

[0195] Step 206: Based on the blockchain test result indicating that the result of transferring resources from the first object to the second object meets the reference condition, a fourth instruction for clearing the plug-in code in the test code is obtained.

[0196] In an embodiment of the present application, the electronic device may obtain a fourth instruction input by a user, or the electronic device may receive an operation of clearing the plugged code in the test code by the user, and generate the fourth instruction in response to the operation. For example, the electronic device displays a clear control, and when the user triggers the clear control, the electronic device generates the fourth instruction in response to the operation of clearing the plugged code in the test code.

[0197] The embodiment of the present application does not limit the content of the fourth instruction. Exemplarily, the fourth instruction includes a part for indicating the instrumentation code and a part for indicating the clearing operation, and the instrumentation code in the test code is cleared through these two parts. For example, the fourth instruction is: $GOPATH / src / github.com / pingcap / failpoint / bin / failpoint-ctldisable. Among them, "failpoint" is the name of the instrumentation code, which is the part used to indicate the instrumentation code. "disable" is an instruction to stop running, and "failpoint-ctl disable" is used to stop running the instrumentation code. Therefore, "failpoint-ctl enable" is a part used to indicate the clearing operation of the instrumentation code.

[0198] Step 207: Generate a second intermediate file based on the fourth instruction and the test code, where the second intermediate file is used to describe the source code.

[0199] In the embodiment of the present application, the electronic device runs the test code based on the fourth instruction to generate a second intermediate file, which is an intermediate representation generated after analyzing the test code based on the fourth instruction. The second intermediate file includes multiple sub-files, and the contents of some sub-files are used to describe the source code.

[0200] Step 208: Determine the executable file corresponding to the source code based on the second intermediate file. The executable file corresponding to the source code is used to be deployed on the relay node and is run by the relay node to generate the second signature information.

[0201] In an embodiment of the present application, the electronic device displays a compilation control. When the user triggers the compilation control, it is equivalent to the user triggering the operation of compiling the second intermediate file. The electronic device responds to the operation of compiling the second intermediate file and generates an executable file corresponding to the source code, that is, the original executable file. The relay node and the original executable file can be associated to achieve the deployment of the original executable file on the relay node. When the original executable file is deployed on the relay node, it is equivalent to the relay node executing the running logic of the source code, and the reference content can be obtained and the second signature information can be generated according to the reference content.

[0202] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant regions. For example, the source code, stub code, resource transfer use cases, etc. involved in this application are all obtained with full authorization.

[0203] In the above method, the source code of the relay node is used to obtain reference content related to the signature information, and the stub code is used to tamper with the reference content obtained through the source code to obtain the tampered content. By inserting the stub code into the source code to obtain the test code, the test code can generate the first signature information based on the tampered content according to the source code, thereby simulating the tampering of the signature information and laying the foundation for testing the blockchain. Since the acquisition of the stub code is easy, and the implementation difficulty of inserting the stub code into the source code to obtain the test code is low, the acquisition efficiency of the test code is high, so that when the relay node generates the first signature information based on the test code, the test efficiency can be improved when testing the scenario of transferring resources from the first object to the second object.

[0204] The above describes the blockchain testing method provided by the embodiment of the present application from the perspective of method steps. The following is a systematic and comprehensive description. Figure 6 , Figure 6 This is a test flowchart of a blockchain provided in an embodiment of the present application.

[0205] In an embodiment of the present application, the test device can obtain the source code of the relay node, and insert the stub code into the source code of the relay node to obtain the test code, wherein the insertion method of the stub code can be seen in the description of step 203, which will not be repeated here. Then, a test executable file is generated based on the test code, wherein the generation method of the test executable file can be seen in the description of step 2041, which will not be repeated here. Afterwards, the test executable file is deployed on the relay node, and an instruction is triggered to run or stop running the executable file corresponding to the stub code in the test executable file. Among them, the second instruction mentioned above is used to run the executable file corresponding to the stub code in the test executable file, and the third instruction mentioned above is used to stop running the executable file corresponding to the stub code in the test executable file.

[0206] Next, the test environment is tested based on the instructions and resource transfer use cases to obtain the test results. Among them. The test environment includes blockchain A (corresponding to the first blockchain mentioned above) and blockchain B (corresponding to the second blockchain mentioned above). The resource transfer between blockchain A and blockchain B is realized through cross-chain bridge technology, and the relay node can realize the function of the cross-chain bridge. Based on this, the test environment also includes a relay node.

[0207] In the embodiment of the present application, blockchain A includes multiple nodes, any two nodes may be connected in communication or not in communication, for example, Figure 6 Blockchain A is shown to include nodes 1 to 4, and every two nodes are connected in communication. Similarly, blockchain B includes multiple nodes, and any two nodes may be connected in communication or not. For example, Figure 6 It is shown that blockchain B includes nodes 1 to 4, and each two nodes are connected in communication. In the process of testing the test environment based on the instruction and resource transfer use case, the test device can obtain the log information of at least one node in blockchain A, the log information of at least one node in blockchain B, and the log information of the relay node, and obtain the test results by analyzing these log information. The method for determining the test results can be seen in the description of step A3 and step B3, which will not be repeated here.

[0208] See also Figure 7 , Figure 7 This is another blockchain testing flow chart provided in the embodiment of the present application. In the embodiment of the present application, the process of testing the blockchain can be divided into a test submission phase, a test phase, and a node deployment phase.

[0209] The test submission phase is the preparation phase before testing the blockchain. In the test submission phase, technicians can write the source code of the relay node and submit the source code to the test management software. Then, the test object can associate the source code with the relay node through the test management software, submit the test file, and wait for the audit result. Optionally, the test management software is deployed on the test device, so that the test device can obtain the source code of the relay node, respond to the test object's operation of associating the source code with the relay node, deploy the source code on the relay node, then obtain the test file input by the test object and send the test file to the electronic device of the audit object (the object for auditing the test file), and receive the audit result fed back by the electronic device of the audit object. If the audit result is passed, the test phase is entered.

[0210] The test phase is a phase for testing the test environment including the first blockchain, the second blockchain, and the relay node. During the test phase, the test device can insert the plug-in code into the source code to obtain the test code, and compile the test code to obtain the test executable file. Then, the instruction is triggered to run the executable file corresponding to the plug-in code in the test executable file (i.e., trigger the first instruction) and execute the resource transfer use case. Among them, the content of the test phase can be seen in the description of steps 201 to 205, which will not be repeated here.

[0211] The deployment phase is a phase in which the relay nodes are deployed based on the test results. In the deployment phase, the test device can obtain and analyze log information, wherein the log information here includes the log information of the nodes in the first blockchain, the log information of the nodes in the second blockchain, and the log information of the relay nodes. Then, the test results are generated based on the analysis results of the log information. If the test result is passed, the test code is compiled to obtain the original executable file and the original executable file is deployed on the relay node. By deploying the original executable file on the relay node, when the resources are subsequently transferred between the first blockchain and the second blockchain, the relay node can run the original executable file, generate untampered signature information (i.e., the second signature information) based on the reference content, and complete the resource transfer between different blockchains on the premise of untampered signature information, thereby improving the security of resource transfer.

[0212] Figure 8 FIG. 1 is a schematic diagram of a blockchain testing device provided in an embodiment of the present application. Figure 8 As shown, the device comprises:

[0213] An acquisition module 801 is used to acquire a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain;

[0214] The acquisition module 801 is further used to acquire the source code of the relay node, and the source code is used to acquire reference content related to the signature information;

[0215] Insertion module 802, used for inserting stub code into source code to obtain test code, the stub code is used for tampering reference content obtained through source code to obtain tampered content, and the test code is used for generating first signature information based on the tampered content according to the source code;

[0216] The testing module 803 is used to test a scenario in which a first object transfers resources to a second object when the relay node generates first signature information based on the test code, and obtain a first test result;

[0217] The determination module 804 is used to determine the blockchain test result based on the first test result.

[0218] In a possible implementation, the reference content includes a private key, a signature algorithm, and resource transfer information of the relay node;

[0219] Insertion module 802 is used to obtain a configuration file, which includes an insertion code and an insertion position of the insertion code in the source code, and the insertion code is used to tamper with at least one of a private key, a signature algorithm, and resource transfer information; the insertion code is inserted into the source code based on the insertion position to obtain a test code.

[0220] In one possible implementation, the test module 803 is used to generate a test executable file based on the test code; deploy the test executable file on the relay node; and when the relay node generates first signature information based on the test executable file, test the scenario of resource transfer from the first object to the second object to obtain a first test result.

[0221] In one possible implementation, the test module 803 is used to obtain a first instruction for activating the stub code in the test code; generate a first intermediate file based on the first instruction and the test code, the first intermediate file being used to describe the source code, the test code, and the modifications made when the stub code is inserted into the source code; and determine the test executable file based on the first intermediate file.

[0222] In a possible implementation, the test module 803 is used to obtain a second instruction for running an executable file corresponding to the instrumentation code, where the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the instrumentation code; when the relay node runs the executable file corresponding to the source code and the executable file corresponding to the instrumentation code based on the second instruction to generate the first signature information, a scenario of resource transfer from the first object to the second object is tested to obtain a first test log, where the first test log is used to describe at least one of the operating information of the node in the first blockchain, the operating information of the relay node, and the operating information of the node in the second blockchain when the executable file corresponding to the instrumentation code is run; and a first test result is determined based on the first test log.

[0223] In a possible implementation, the test code is further used to generate second signature information based on the reference content according to the source code;

[0224] Determination module 804 is used to test the scenario of resource transfer from the first object to the second object when the relay node generates the second signature information based on the test code, and obtain the second test result; based on the first test result and the second test result, determine the blockchain test result.

[0225] In a possible implementation, a determination module 804 is used to obtain a third instruction for stopping the execution of an executable file corresponding to the instrumentation code, and the test code is used to generate a test executable file deployed on a relay node, the test executable file including an executable file corresponding to the source code and an executable file corresponding to the instrumentation code; when the relay node runs the executable file corresponding to the source code based on the third instruction to generate second signature information, a scenario of resource transfer from the first object to the second object is tested to obtain a second test log, and the second test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the execution of the executable file corresponding to the instrumentation code is stopped; and a second test result is determined based on the second test log.

[0226] In a possible implementation, the acquisition module 801 is further used to characterize that the result of the resource transfer from the first object to the second object meets the reference condition based on the blockchain test result, and to acquire a fourth instruction for clearing the stub code in the test code;

[0227] The device also includes:

[0228] A generating module, used for generating a second intermediate file based on the fourth instruction and the test code, wherein the second intermediate file is used for describing the source code;

[0229] The determination module 804 is further used to determine the executable file corresponding to the source code based on the second intermediate file. The executable file corresponding to the source code is used to be deployed on the relay node and is executed by the relay node to generate the second signature information.

[0230] In the above device, the source code of the relay node is used to obtain reference content related to the signature information, and the stub code is used to tamper with the reference content obtained through the source code to obtain the tampered content. By inserting the stub code into the source code to obtain the test code, the test code can generate the first signature information based on the tampered content according to the source code, thereby simulating the tampering of the signature information and laying the foundation for testing the blockchain. Since the acquisition of the stub code is easy, and the implementation difficulty of inserting the stub code into the source code to obtain the test code is low, the acquisition efficiency of the test code is high, so that when the relay node generates the first signature information based on the test code, the test efficiency can be improved when testing the scenario of transferring resources from the first object to the second object.

[0231] It should be understood that the above Figure 8When the device provided realizes its functions, only the division of the above-mentioned functional modules is used as an example for illustration. In practical applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0232] Fig. 9 The structure block diagram of a terminal device 900 provided by an exemplary embodiment of the present application is shown. The terminal device 900 includes: a processor 901 and a memory 902 .

[0233] The processor 901 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like. The processor 901 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 901 may also include a main processor and a coprocessor. The main processor is a processor for processing data in an awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 901 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 901 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0234] The memory 902 may include one or more computer-readable storage media, which may be non-transitory. The memory 902 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 902 is used to store at least one computer program, which is used to be executed by the processor 901 to implement the blockchain testing method provided in the method embodiment of the present application.

[0235] In some embodiments, the terminal device 900 may further optionally include: a peripheral device interface 903 and at least one peripheral device. The processor 901, the memory 902 and the peripheral device interface 903 may be connected via a bus or a signal line. Each peripheral device may be connected to the peripheral device interface 903 via a bus, a signal line or a circuit board. Specifically, the peripheral device includes: at least one of a radio frequency circuit 904, a display screen 905, a camera assembly 906, an audio circuit 907 and a power supply 908.

[0236] The peripheral device interface 903 may be used to connect at least one peripheral device related to I / O (Input / Output) to the processor 901 and the memory 902. In some embodiments, the processor 901, the memory 902, and the peripheral device interface 903 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 901, the memory 902, and the peripheral device interface 903 may be implemented on a separate chip or circuit board, which is not limited in this embodiment.

[0237] The radio frequency circuit 904 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The radio frequency circuit 904 communicates with communication networks and other communication devices through electromagnetic signals. The radio frequency circuit 904 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals into electrical signals. Optionally, the radio frequency circuit 904 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, and the like. The radio frequency circuit 904 can communicate with other terminals through at least one wireless communication protocol. The wireless communication protocol includes, but is not limited to: the World Wide Web, a metropolitan area network, an intranet, various generations of mobile communication networks (2G, 3G, 4G and 5G), a wireless local area network and / or a WiFi (Wireless Fidelity) network. In some embodiments, the radio frequency circuit 904 may also include circuits related to NFC (Near Field Communication), which is not limited in this application.

[0238] The display screen 905 is used to display the UI (User Interface). The UI may include graphics, text, icons, videos, and any combination thereof. When the display screen 905 is a touch display screen, the display screen 905 also has the ability to collect touch signals on the surface or above the surface of the display screen 905. The touch signal can be input to the processor 901 as a control signal for processing. At this time, the display screen 905 can also be used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, the display screen 905 can be one, set on the front panel of the terminal device 900; in other embodiments, the display screen 905 can be at least two, respectively set on different surfaces of the terminal device 900 or in a folding design; in other embodiments, the display screen 905 can be a flexible display screen, set on the curved surface or folding surface of the terminal device 900. Even, the display screen 905 can also be set to a non-rectangular irregular shape, that is, a special-shaped screen. The display screen 905 can be made of materials such as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode, organic light-emitting diode).

[0239] The camera assembly 906 is used to capture images or videos. Optionally, the camera assembly 906 includes a front camera and a rear camera. Typically, the front camera is arranged on the front panel of the terminal, and the rear camera is arranged on the back of the terminal. In some embodiments, there are at least two rear cameras, which are any one of a main camera, a depth of field camera, a wide-angle camera, and a telephoto camera, so as to realize the fusion of the main camera and the depth of field camera to realize the background blur function, the fusion of the main camera and the wide-angle camera to realize panoramic shooting and VR (Virtual Reality) shooting function or other fusion shooting functions. In some embodiments, the camera assembly 906 may also include a flash. The flash can be a monochrome temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cold light flash, which can be used for light compensation at different color temperatures.

[0240] The audio circuit 907 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals and input them into the processor 901 for processing, or input them into the radio frequency circuit 904 to achieve voice communication. For the purpose of stereo acquisition or noise reduction, there may be multiple microphones, which are respectively arranged at different parts of the terminal device 900. The microphone may also be an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signal from the processor 901 or the radio frequency circuit 904 into sound waves. The speaker may be a traditional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signal into sound waves audible to humans, but also convert the electrical signal into sound waves inaudible to humans for purposes such as ranging. In some embodiments, the audio circuit 907 may also include a headphone jack.

[0241] The power supply 908 is used to power various components in the terminal device 900. The power supply 908 can be an alternating current, a direct current, a disposable battery, or a rechargeable battery. When the power supply 908 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery charged through a wired line, and a wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0242] In some embodiments, the terminal device 900 further includes one or more sensors 909 . The one or more sensors 909 include but are not limited to: an acceleration sensor 911 , a gyroscope sensor 912 , a pressure sensor 913 , an optical sensor 914 , and a proximity sensor 915 .

[0243] The acceleration sensor 911 can detect the magnitude of acceleration on the three coordinate axes of the coordinate system established by the terminal device 900. For example, the acceleration sensor 911 can be used to detect the components of gravity acceleration on the three coordinate axes. The processor 901 can control the display screen 905 to display the user interface in a horizontal view or a vertical view according to the gravity acceleration signal collected by the acceleration sensor 911. The acceleration sensor 911 can also be used for collecting game or user motion data.

[0244] The gyroscope sensor 912 can detect the body direction and rotation angle of the terminal device 900. The gyroscope sensor 912 can cooperate with the acceleration sensor 911 to collect the user's 3D actions on the terminal device 900. The processor 901 can implement the following functions based on the data collected by the gyroscope sensor 912: motion sensing (such as changing the UI according to the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0245] The pressure sensor 913 can be set on the side frame of the terminal device 900 and / or the lower layer of the display screen 905. When the pressure sensor 913 is set on the side frame of the terminal device 900, it can detect the user's holding signal of the terminal device 900, and the processor 901 performs left and right hand recognition or shortcut operation according to the holding signal collected by the pressure sensor 913. When the pressure sensor 913 is set on the lower layer of the display screen 905, the processor 901 controls the operability controls on the UI interface according to the user's pressure operation on the display screen 905. The operability controls include at least one of a button control, a scroll bar control, an icon control, and a menu control.

[0246] The optical sensor 914 is used to collect the ambient light intensity. In one embodiment, the processor 901 can control the display brightness of the display screen 905 according to the ambient light intensity collected by the optical sensor 914. Specifically, when the ambient light intensity is high, the display brightness of the display screen 905 is increased; when the ambient light intensity is low, the display brightness of the display screen 905 is reduced. In another embodiment, the processor 901 can also dynamically adjust the shooting parameters of the camera assembly 906 according to the ambient light intensity collected by the optical sensor 914.

[0247] The proximity sensor 915, also called a distance sensor, is usually arranged on the front panel of the terminal device 900. The proximity sensor 915 is used to collect the distance between the user and the front of the terminal device 900. In one embodiment, when the proximity sensor 915 detects that the distance between the user and the front of the terminal device 900 is gradually decreasing, the processor 901 controls the display screen 905 to switch from the screen-on state to the screen-off state; when the proximity sensor 915 detects that the distance between the user and the front of the terminal device 900 is gradually increasing, the processor 901 controls the display screen 905 to switch from the screen-off state to the screen-on state.

[0248] Those skilled in the art will understand that Fig. 9 The structure shown in the figure does not constitute a limitation on the terminal device 900, and may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0249] Fig.10This is a schematic diagram of the structure of the server provided in the embodiment of the present application. The server 1000 may have relatively large differences due to different configurations or performances, and may include one or more processors 1001 and one or more memories 1002, wherein the one or more memories 1002 store at least one computer program, and the at least one computer program is loaded and executed by the one or more processors 1001 to implement the blockchain testing method provided by the above-mentioned various method embodiments. Exemplarily, the processor 1001 is a CPU. Of course, the server 1000 may also have components such as a wired or wireless network interface, a keyboard, and an input and output interface for input and output. The server 1000 may also include other components for implementing device functions, which will not be repeated here.

[0250] In an exemplary embodiment, a computer-readable storage medium is also provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned blockchain testing methods.

[0251] Optionally, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, etc.

[0252] In an exemplary embodiment, a computer program is also provided. The computer program is at least one, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned blockchain testing methods.

[0253] In an exemplary embodiment, a computer program product is also provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned blockchain testing methods.

[0254] It should be understood that the "plurality" mentioned in this article refers to two or more. "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 associated objects are in an "or" relationship.

[0255] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0256] The above description is only an exemplary embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A blockchain testing method, characterized in that: The method comprises: Obtain a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain; Obtaining source code of the relay node, wherein the source code is used to obtain reference content related to the signature information; Inserting a stub code into the source code to obtain a test code, wherein the stub code is used to tamper with the reference content obtained through the source code to obtain a tampered content, and the test code is used to generate first signature information based on the tampered content according to the source code; When the relay node generates the first signature information based on the test code, testing a scenario in which the first object transfers resources to the second object to obtain a first test result; Based on the first test result, a blockchain test result is determined.

2. The method according to claim 1, characterized in that The reference content includes the private key, signature algorithm and resource transfer information of the relay node; the inserting stub code into the source code to obtain the test code includes: Obtaining a configuration file, the configuration file including the plug-in code and an insertion position of the plug-in code in the source code, the plug-in code being used to tamper with at least one of the private key, the signature algorithm, and the resource transfer information; The stub code is inserted into the source code based on the insertion position to obtain the test code.

3. The method according to claim 1, characterized in that The step of testing a scenario in which the first object transfers resources to the second object when the relay node generates the first signature information based on the test code to obtain a first test result includes: generating a test executable file based on the test code; Deploy the test executable file on the relay node; When the relay node generates the first signature information based on the test executable file, a scenario of transferring resources from the first object to the second object is tested to obtain a first test result.

4. The method according to claim 3, characterized in that The generating a test executable file based on the test code comprises: Obtaining a first instruction for activating the stub code in the test code; generating a first intermediate file based on the first instruction and the test code, wherein the first intermediate file is used to describe the source code, the test code, and modifications made when the stub code is inserted into the source code; The test executable file is determined based on the first intermediate file.

5. The method according to claim 3, characterized in that: The step of testing a scenario in which the first object transfers resources to the second object when the relay node generates the first signature information based on the test executable file to obtain a first test result includes: Obtaining a second instruction for running an executable file corresponding to the stub code, wherein the test executable file includes an executable file corresponding to the source code and an executable file corresponding to the stub code; When the relay node generates the first signature information by running the executable file corresponding to the source code and the executable file corresponding to the stub code based on the second instruction, a scenario of transferring resources from the first object to the second object is tested to obtain a first test log, where the first test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the executable file corresponding to the stub code is run; Based on the first test log, the first test result is determined.

6. The method according to claim 1, characterized in that The test code is also used to generate the second signature information based on the reference content according to the source code; The determining of the blockchain test result based on the first test result includes: When the relay node generates the second signature information based on the test code, testing a scenario in which the first object transfers resources to the second object to obtain a second test result; Based on the first test result and the second test result, the blockchain test result is determined.

7. The method according to claim 6, characterized in that The step of testing a scenario in which the first object transfers resources to the second object when the relay node generates the second signature information based on the test code to obtain a second test result includes: Obtaining a third instruction for stopping the execution of an executable file corresponding to the stub code, wherein the test code is used to generate a test executable file deployed on the relay node, the test executable file including an executable file corresponding to the source code and an executable file corresponding to the stub code; When the relay node runs the executable file corresponding to the source code based on the third instruction to generate the second signature information, a scenario of transferring resources from the first object to the second object is tested to obtain a second test log, where the second test log is used to describe at least one of the operation information of the node in the first blockchain, the operation information of the relay node, and the operation information of the node in the second blockchain when the executable file corresponding to the stub code is stopped; Based on the second test log, the second test result is determined.

8. The method according to claim 1, characterized in that After determining the blockchain test result based on the first test result, the method further includes: Based on the blockchain test result indicating that a result of transferring resources from the first object to the second object meets a reference condition, obtaining a fourth instruction for clearing the stub code in the test code; generating a second intermediate file based on the fourth instruction and the test code, wherein the second intermediate file is used to describe the source code; An executable file corresponding to the source code is determined based on the second intermediate file. The executable file corresponding to the source code is used to be deployed on the relay node and is executed by the relay node to generate the second signature information.

9. A blockchain testing device, characterized in that: The device comprises: an acquisition module, used to acquire a resource transfer use case, where the resource transfer use case is used to describe a scenario in which a first object belonging to a first blockchain transfers resources to a second object belonging to a second blockchain; The acquisition module is further used to acquire source code of the relay node, and the source code is used to acquire reference content related to the signature information; an insertion module, configured to insert a stub code into the source code to obtain a test code, wherein the stub code is used to tamper with the reference content obtained through the source code to obtain a tampered content, and the test code is used to generate first signature information based on the tampered content according to the source code; a testing module, configured to test a scenario in which the first object transfers resources to the second object when the relay node generates the first signature information based on the test code, and obtain a first test result; A determination module is used to determine a blockchain test result based on the first test result.

10. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor so that the electronic device implements the blockchain testing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: At least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by the processor to enable the electronic device to implement the blockchain testing method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that The computer program product stores at least one computer program, and the at least one computer program is loaded and executed by a processor so that the electronic device implements the blockchain testing method as described in any one of claims 1 to 8.