Blockchain testing method, device, system and electronic equipment

Abstract

The present disclosure provides a blockchain testing method, device, system, and electronic device. The method includes: obtaining at least one contract to be tested, where the contract to be tested is obtained based on a contract template, and the contract template includes meta-function modules and the dependencies between the meta-function modules; orchestrating the nodes to be tested and the contract to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship; deploying the contract to be tested and the nodes to be tested according to the orchestration relationship; and testing the nodes to be tested and the corresponding contracts to be tested. In this way, it can adapt to various standardized testing requirements and improve operational efficiency. It can flexibly and efficiently adapt to various blockchains. As a result, such a blockchain testing method has strong adaptability and improved testing efficiency.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain testing, and in particular to a blockchain testing method, device, system, and electronic device. Background Art

[0002] In existing technologies, because different blockchains use different programming languages ​​and code logic for smart contracts, testing multiple blockchains requires using separate test smart contracts. This results in poor adaptability and reduced testing efficiency, whether testing between front-end interfaces and different blockchains or between a large number of blockchain nodes. Summary of the Invention

[0003] In view of the above problems, the present disclosure is proposed. The present disclosure provides a blockchain testing method, device, system and electronic device.

[0004] According to a first aspect of the present disclosure, a blockchain testing method is provided, comprising: obtaining at least one node to be tested in a blockchain; obtaining at least one contract to be tested, where the contract to be tested is obtained based on a contract template, the contract template including meta-function modules and dependencies between the meta-function modules; orchestrating the node to be tested and the contract to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship; deploying the contract to be tested and the node to be tested according to the orchestration relationship; and testing the node to be tested and the corresponding contract to be tested.

[0005] In addition, according to the blockchain testing method of the first aspect of the present disclosure, obtaining at least one contract to be tested includes: obtaining any one contract to be tested in the following manner: in the contract template, obtaining the target meta-function module indicated by the user; based on the dependency relationship of each target meta-function module, merging the pseudocode of each target meta-function module; compiling the merged pseudocode according to the target programming language to obtain the contract to be tested.

[0006] In addition, according to the blockchain testing method of the first aspect of the present disclosure, obtaining any contract to be tested in the following manner also includes: based on the correspondence between the contract to be tested and the annotation template, based on the annotation level indicated by the user, obtaining the target annotation template; using the information in the contract to be tested to replace the placeholder of the target annotation template to obtain the target annotation.

[0007] In addition, according to the blockchain testing method of the first aspect of the present disclosure, with the goal of optimizing global load balancing, the node to be tested and the contract to be tested are orchestrated to obtain an orchestration relationship, including: performing at least one round of matching relationship adjustment in the following manner until convergence, and determining the converged matching relationship as the orchestration relationship: obtaining a first evaluation value corresponding to the initial matching relationship between the node to be tested and the contract to be tested, the first evaluation value being used to measure the global load balancing performance of the node cluster to be tested; adjusting the matching relationship between the node to be tested and the contract to be tested, and obtaining an adjusted second evaluation value; when the second evaluation value is greater than the first evaluation value, determining the acceptance probability to be 1; or, when the second evaluation value is less than the first evaluation value, determining the acceptance probability based on the first evaluation value and the second evaluation value, the acceptance probability being used to guide the adjustment direction of the matching relationship, and the acceptance probability being the probability of the adjusted matching relationship being accepted.

[0008] In addition, according to the blockchain testing method of the first aspect of the present disclosure, the initial matching relationship is the matching relationship between the node to be tested and the contract to be tested when the local load balancing is optimal.

[0009] In addition, according to the blockchain testing method of the first aspect of the present disclosure, the first evaluation value includes at least: global resource utilization, and the resources include at least one of the following: memory resources and central processing unit CPU resources.

[0010] In addition, according to the blockchain testing method of the first aspect of the present disclosure, the contract to be tested and the node to be tested are deployed according to the orchestration relationship, including: based on a deployment plug-in adapted to the blockchain, the contract to be tested and the node to be tested are deployed based on the orchestration relationship.

[0011] In addition, according to the blockchain testing method of the first aspect of the present disclosure, based on the deployment plug-in adapted to the blockchain and based on the orchestration relationship, the contract to be tested and the node to be tested are deployed, including: based on the blockchain underlying chain characteristics, obtaining the deployment plug-in adapted to the underlying chain characteristics; using the information of the contract to be tested and the node to be tested in the orchestration relationship, replacing the placeholders in the deployment plug-in adapted to the underlying chain characteristics, and completing the deployment of the contract to be tested and the node to be tested.

[0012] In addition, according to the blockchain testing method of the first aspect of the present disclosure, the nodes to be tested and the corresponding contracts to be tested are tested, including: testing each node to be tested and the corresponding contract to be tested, and obtaining test data; based on the test data, determining the target node to be tested among the nodes to be tested; and adjusting the target node to be tested.

[0013] In addition, according to the blockchain testing method of the first aspect of the present disclosure, the test data at least includes: test duration.

[0014] According to a second aspect of the present disclosure, a blockchain testing device is provided, which includes: a node acquisition unit, configured to acquire at least one node to be tested in the blockchain; a contract acquisition unit, configured to acquire at least one contract to be tested, where the contract to be tested is obtained based on a contract template, and the contract template includes meta-function modules, as well as dependencies between the meta-function modules; an orchestration unit, configured to orchestrate the node to be tested and the contract to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship; a deployment unit, configured to deploy the contract to be tested and the node to be tested according to the orchestration relationship; and a testing unit, configured to test the node to be tested and the corresponding contract to be tested.

[0015] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a memory for storing computer-readable instructions; and a processor for executing the computer-readable instructions so that the electronic device performs the blockchain testing method as described above.

[0016] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided for storing computer-readable instructions, wherein when the computer-readable instructions are executed by a processor, the processor executes the blockchain testing method as described above.

[0017] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program, which is executed by a processor to implement the blockchain testing method as described above.

[0018] As described in detail below, a blockchain testing method, device, system, and electronic device according to an embodiment of the present disclosure obtains nodes and contracts to be tested and orchestrates them with the goal of achieving optimal global load balancing. The contracts and nodes to be tested are deployed based on the orchestration relationship, and then the nodes and contracts to be tested are tested. Because each contract to be tested is derived from the same contract template, the underlying logic of the contract to be tested is the same, providing a standardized test contract applicable to multiple blockchains. When comparing multiple blockchains, the entire test process is simplified, improving test efficiency. Furthermore, because the contract template is a reasonable and effective assembly of various meta-functional modules with dependencies, and each test contract is derived based on the contract template, each contract is implemented based on the dependencies between the various meta-functional modules. This saves resources, reduces the amount of computation required for the nodes and contracts to be tested during the orchestration process, and improves test efficiency. Orchestration strategies that aim for optimal global load balancing can more accurately simulate the resource consumption and performance of real-world blockchain testing environments. This allows for a rational orchestration between the nodes and contracts under test to reduce resource waste, adapt to diverse standardized testing requirements, and improve operational efficiency. Plugin-based deployment allows for flexible and efficient adaptation to multiple blockchains. This makes blockchain testing highly adaptable and improves testing efficiency.

[0019] It is to be understood that both the foregoing general description and the following detailed description are exemplary, and are intended to provide further explanation of the technology as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The above and other purposes, features, and advantages of the present disclosure will become more apparent through a more detailed description of the embodiments of the present disclosure in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the present disclosure and are not intended to limit the present disclosure. In the drawings, the same reference numerals generally represent the same components or steps.

[0021] Figure 1 1 is a flowchart illustrating a blockchain testing method according to an embodiment of the present disclosure.

[0022] Figure 2 is a schematic diagram illustrating a contract template according to an embodiment of the present disclosure.

[0023] Figure 3 FIG2 is a flow chart illustrating a method for generating a contract to be tested according to an embodiment of the present disclosure.

[0024] Figure 4 It is a schematic diagram illustrating the overall process of generating a contract to be tested according to an embodiment of the present disclosure.

[0025] Figure 5 A code diagram illustrating the EOS underlying chain adaptation to the deployment of the node to be tested and the contract to be tested according to an embodiment of the present disclosure.

[0026] Figure 6 is a code diagram illustrating deployment parameter settings according to an embodiment of the present disclosure.

[0027] Figure 7 It is a schematic diagram illustrating an optimal method for deploying a contract to be tested and a node to be tested according to an embodiment of the present disclosure.

[0028] Figure 8 2 is a schematic diagram illustrating a preferred blockchain testing method according to an embodiment of the present disclosure.

[0029] Figure 9 1 is a system diagram illustrating a preferred blockchain test according to an embodiment of the present disclosure.

[0030] Figure 10 2 is a diagram illustrating an overall apparatus for blockchain testing according to an embodiment of the present disclosure.

[0031] Figure 11 is a hardware block diagram illustrating an electronic device according to an embodiment of the present disclosure.

[0032] Figure 12 is a schematic diagram illustrating a computer-readable storage medium according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0033] In order to make the purpose, technical solutions and advantages of the present disclosure more apparent, the following will describe in detail exemplary embodiments of the present disclosure with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0034] In existing technologies, because different blockchains use different programming languages ​​and code logic for smart contracts, testing multiple blockchains requires using separate test smart contracts. This results in poor adaptability and reduced testing efficiency, whether testing between front-end interfaces and different blockchains or between a large number of blockchain nodes.

[0035] Therefore, this application proposes a blockchain testing method, which can be applied to at least one of the following scenarios: front-end interfaces and different blockchains, and between a large number of blockchain nodes. The blockchain testing method provided by this disclosure can include but is not limited to at least one test such as functional testing, performance testing, application programming interface (API) testing, node testing, security testing, and fault simulation testing when conducting blockchain testing. First, Figure 1 1 is a flowchart illustrating a blockchain testing method according to an embodiment of the present disclosure.

[0036] like Figure 1 As shown, the steps of the blockchain testing method according to the embodiment of the present disclosure are as follows:

[0037] In step S101, at least one node to be tested in the blockchain is obtained.

[0038] In the disclosed embodiments, the blockchain node to be tested may be a selected blockchain network node for testing purposes, with the testing purpose including, but not limited to, at least one of the following: functionality, performance, security, stability, and compatibility. Acquiring at least one blockchain node to be tested may involve at least one of the following steps: determining the test purpose and scope, selecting a test environment, obtaining a node list, screening the nodes to be tested, configuring the test environment, and verifying the connection to the node to be tested is normal. Specific implementation details may vary depending on different blockchain platforms, testing tools, and network configurations, and can be flexibly adjusted based on actual circumstances, and are not limited here.

[0039] In step S102, at least one contract to be tested is obtained. The contract to be tested is obtained based on a contract template. The contract template includes meta-functional modules and dependency relationships between the meta-functional modules.

[0040] In an embodiment of the present disclosure, at least one contract to be tested is obtained from a blockchain, and the contract to be tested is generated based on a contract template. The contract template is determined by meta-function modules and the dependencies between the meta-function modules.

[0041] The contract under test can be a smart contract to be tested on a blockchain network. Meta-function modules are the foundation of smart contracts or blockchain applications and are reusable basic functional components. These meta-function modules can be highly abstract and modular code snippets that encapsulate specific basic functions. Dependencies can be connection relationships, including but not limited to at least one of the following: direct dependency, indirect dependency, conditional dependency, circular dependency, and hierarchical dependency. The dependency relationships between meta-function modules describe how they work together. The contract template can be a standardized, reusable contract framework. It provides the basic functional structure required to build a contract and the relationships between the various modules. In the disclosed embodiments, the contract template includes the meta-function modules and the dependencies between them. The contract template can be represented using a hypergraph. The contract under test is generated based on the contract template and can be configured and extended according to specific business needs during the generation process. In this way, the contract under test generated based on the contract template ensures the security and consistency of the contract and reduces potential logical errors.

[0042] In step S103, with the goal of optimizing global load balancing, the nodes to be tested and the contracts to be tested are orchestrated to obtain an orchestration relationship.

[0043] In the embodiment of the present disclosure, in the process of orchestrating and matching the nodes to be tested and the contracts to be tested, the ultimate goal is to optimize the global load balancing, and the matching relationship between the nodes to be tested and the contracts to be tested with the optimal global load balancing is used as the orchestration relationship.

[0044] Among them, global load optimization aims to ensure that the traffic in the test system can be evenly distributed to each node, thereby making full use of the test system resources and improving the overall processing capacity and response speed. With the goal of global load optimization, the relationship between the nodes to be tested and the contracts to be tested is orchestrated, which can more accurately simulate the resource consumption and performance of the real environment of blockchain testing. In response to various testing requirements, each node can make full use of its resources, improving the testing efficiency and operation speed of the system. In the embodiment of the present disclosure, the orchestration relationship includes but is not limited to at least one of the following: one node to be tested corresponds to multiple contracts to be tested, multiple nodes to be tested corresponds to multiple contracts to be tested, and one contract to be tested corresponds to multiple nodes to be tested.

[0045] In step S104, the contract to be tested and the node to be tested are deployed according to the arrangement relationship.

[0046] In the disclosed embodiments, the contracts to be tested and the nodes to be tested can be deployed according to the orchestration relationship. The process of deploying the contracts to be tested and the nodes to be tested may include, but is not limited to, at least one of the following steps: identifying dependencies, formulating deployment strategies, configuring test nodes, deploying the contracts to be tested, contract interaction verification, monitoring and debugging, and generating deployment reports. By deploying the contracts to be tested and the nodes to be tested according to the orchestration relationship, it is possible to ensure that the contracts are deployed on the most suitable nodes, and that the entire deployment process is orderly and controllable. This helps improve the performance and reliability of the system and provides a good foundation for the subsequent operation of the contract.

[0047] In step S105, the node to be tested and the corresponding contract to be tested are tested.

[0048] In the disclosed embodiment, by deploying the above-mentioned arrangement relationship between the contract to be tested and the node to be tested, a unified test of the node to be tested and its corresponding contract to be tested can be performed.

[0049] In this way, the nodes and contracts under test are obtained and orchestrated with the goal of achieving optimal global load balancing. Based on this orchestration, the contracts and nodes under test are deployed, and then the nodes and contracts under test are tested. Because each contract under test is derived from the same contract template, the underlying logic is identical, providing standardized test contracts applicable to multiple blockchains. This simplifies the entire testing process and improves testing efficiency when comparing multiple blockchains. Furthermore, because the contract template is a rational and effective assembly of various meta-functional modules with dependencies, and each test contract is derived from the contract template, each contract is implemented based on the dependencies between these meta-functional modules. This conserves resources, reduces the computational effort of the nodes and contracts under test during the orchestration process, and improves testing efficiency. Orchestration strategies that aim for optimal global load balancing can more accurately simulate the resource consumption and performance of real-world blockchain testing environments. Therefore, the rational orchestration of the nodes and contracts under test can reduce resource waste, adapt to various standardized testing requirements, and improve operational efficiency. The plug-in extension deployment method can flexibly and efficiently adapt to multiple blockchains. As a result, this blockchain testing method has strong adaptability and improves testing efficiency.

[0050] Whenever blockchain testing is needed, the aforementioned testing methods can be utilized, addressing the existing challenges of a lack of standardization, poor adaptability, and low efficiency. The establishment of a standard test contract effectively addresses the lack of a unified test contract for comparative testing of different blockchain types. Furthermore, it simplifies the often cumbersome contract writing process during blockchain testing, improving testing efficiency. The following provides a detailed introduction to obtaining a standard test contract.

[0051] As follows, the method for obtaining at least one contract to be tested according to an embodiment of the present disclosure includes:

[0052] In the contract template, obtain the target meta-function module indicated by the user;

[0053] Based on the dependency relationship of each target meta-functional module, the pseudo codes of each target meta-functional module are merged;

[0054] Compile the merged pseudocode according to the target programming language to obtain the contract to be tested.

[0055] In the disclosed embodiments, users can first select the target meta-function modules to be implemented in the contract template based on their needs (e.g., business requirements, scenarios, etc.). These target meta-function modules can be predefined, reusable code snippets that implement basic functions (e.g., transfers, data storage, permission verification, status updates, time locks, etc.). Next, the dependencies of the target meta-function modules are analyzed (e.g., one meta-function module may require data or status from another meta-function module to operate correctly) to ensure that subsequent code operations can function properly. The pseudocode of each target meta-function module is then merged. Based on the analyzed dependencies, the pseudocode of each target meta-function module is merged. During the merging process, care must be taken to maintain the logical consistency and integrity of the code to ensure that the merged pseudocode correctly implements the desired functionality. Finally, the merged pseudocode is compiled to produce the contract under test. This can be achieved by compiling the merged pseudocode according to the grammatical rules of the target programming language (e.g., Java, Go, C++, etc.). The compilation process includes, but is not limited to, at least one of the following steps: preprocessing the pseudocode data, syntax checking, and optimization. This ensures that the generated code complies with the specifications of the target programming language and can be run on the specific blockchain platform. After successful compilation, a contract to be tested is generated. This contract to be tested contains all the target meta-functional modules specified by the user and has been compiled and optimized according to the rules of the target programming language.

[0056] The above example generates a contract to be tested based on the target meta-function modules specified by the user and the dependencies between them, providing a foundation for subsequent deployment and testing. Below, we provide a detailed introduction to some meta-function code modules and contract templates.

[0057] Table 1 illustrates some of the meta-function code modules according to an embodiment of the present disclosure. As shown in Table 1, the meta-function modules include, but are not limited to, at least one of the following: contract deployment, asset creation, asset query, asset transfer, permission control, transaction confirmation, data verification, trigger events, error handling, status updates, multi-signature processing, contract updates, contract revocation, transaction batching, time locks, conditional triggers, data hashing, timestamp processing, and identity verification. Users can customize the meta-function modules they require.

[0058]

[0059]

[0060]

[0061] Table 1 also shows the module description, pseudo code, input, output, execution conditions, module type and performance of the meta-functional module. These detailed descriptions are crucial for the development, maintenance and integration of the meta-functional module with other modules.

[0062] Then, illustratively, Figure 2 is a schematic diagram illustrating a contract template according to an embodiment of the present disclosure.

[0063] like Figure 2 As shown, the contract template can be represented by a hypergraph:

[0064] Hypergraphs can clearly depict the relationships between meta-function code modules. Each hypergraph consists of multiple nodes and hyperedges. Nodes represent meta-function code modules, while hyperedges represent the relationships between them. The following are the steps to build a hypergraph-based meta-function code relationship model:

[0065] First, define nodes: Each meta-function code module corresponds to a node in the hypergraph. For the meta-function code modules constructed in Table 1 above, all of them are represented as nodes in the hypergraph. Next, construct hyperedges: Hyperedges are a key component of the hypergraph, depicting the complex relationships between nodes. In this step, a hyperedge needs to be established for each pair of related meta-function code modules. Hyperedges can connect any number of nodes, not just two, which is the advantage of hypergraphs for describing complex relationships. Finally, iterative optimization: Hypergraph construction is not a one-time task; it requires continuous iteration and optimization. As contract development progresses, new meta-function code modules may emerge or new inter-module relationships may be discovered. These new modules and relationships will be applied to the hypergraph model. This completes the construction of the hypergraph, and thus the construction of the contract template.

[0066] Of course, when assembling meta-function modules to form a hypergraph contract template, the hypergraph contract template can be optimized by including but not limited to at least one of the following methods: depth-first method, broad-first method, etc. For example, the hypergraph contract template is generated using the depth-first method:

[0067] We define the meta-function hypergraph model as H, the meta-function model library (i.e., node set) as V, and the set of interrelated relationships between meta-functions as E. The set of selected meta-function modules is defined as M. Then, H = (V, E). The purpose of the calculation is to determine the path connecting M.

[0068] First, define the access state set S: which stores the access states of nodes and hyperedges to prevent duplicate access and loops. Initially, every node and hyperedge is unvisited, where for each node v∈V and hyperedge e∈E, S(v)=false and S(e)=false are assigned. The path record set P: which stores the paths found to connect the meta-functional modules.

[0069] Next, enter node v as the vertex currently being explored. Mark node v as visited, S(v) = true; add v to the current path P; traverse all hyperedges e associated with v; if S(e) = false, meaning hyperedge e has not been visited, then S(e) = true; traverse all nodes u in hyperedge e; if S(u) = false, recursively repeat the above steps.

[0070] Finally, if the current path P meets the conditions (connected to a specific meta-function module), the path is saved. The system automatically links the meta-function code through the P set to generate a hypergraph, i.e., a contract template.

[0071] It's important to note that the system automatically optimizes and verifies the generated template, including but not limited to at least one of the following steps: static analysis, unit testing, and comprehensive functional and security audits. Based on the results of verification and optimization, the system automatically adjusts the Hypergraph contract template, such as by changing the selection of meta-functional modules or modifying the relationships between modules, to produce an optimal contract template.

[0072] Through this process, we can achieve fully automated generation of contract templates, greatly improving development efficiency while reducing the possibility of errors.

[0073] The above can be used to obtain the test contract through the meta-function modules and the dependencies between the meta-function modules. In one embodiment of the present disclosure, for example, Figure 3 FIG is a flow chart illustrating a method for generating a contract to be tested according to an embodiment of the present disclosure. Figure 3As shown: The method process for generating a contract to be tested according to an embodiment of the present disclosure includes: defining contract resources, selecting a smart contract template, generating intermediate contract code, preprocessing, precompiling and generating a contract.

[0074] Among them, first define the contract resources, including: (1) Meta-function code construction: The meta-function code module is the smallest unit for building a contract template, and the original function code module is constructed based on the principle of reducing coupling and increasing reusability. (2) Meta-function code relationship construction based on hypergraph, in the above Figure 2 (3) Automatic generation of contract templates: Automatic generation of smart contract templates is based on the meta-function code library and the meta-function code relationship model based on the hypergraph. The specific steps are as follows: First, demand analysis and meta-function module selection: the user enters the requirements in the system, the system automatically parses these requirements, and selects the meta-function modules corresponding to the requirements from the meta-function code library according to the hypergraph model. Then, the contract template is automatically constructed: the system automatically assembles the codes of each meta-function module according to the edges (dependencies) in the hypergraph to generate a contract template. In this process, the hyperedge feature of the hypergraph (which can connect multiple nodes) is particularly useful in processing the combination relationship of multiple function modules. Finally, the generated template is optimized and verified to obtain an optimal contract template.

[0075] Next, select the smart contract template. You can select a language-related contract (such as Java, GO, C++, etc.) based on the generated contract template. Through keyword matching and replacement, contract resource renaming, etc., the intermediate contract code is generated.

[0076] Then, preprocessing is performed. The purpose of preprocessing is to complete the text replacement of platform-related codes and annotate the codes, including platform attributes, tool chain records, and processing dates.

[0077] Finally, pre-compilation is performed based on the pre-processed data. The pre-processed contract file can be pre-compiled through a preset compilation script to complete syntax checking and generate a standard test contract.

[0078] Of course, in the process of generating the contract to be tested, target annotations about the contract to be tested will also be generated. The following is a detailed introduction.

[0079] The method for generating target annotations according to an embodiment of the present disclosure includes:

[0080] Based on the correspondence between the contract to be tested and the annotation template, and based on the annotation level indicated by the user, a target annotation template is obtained;

[0081] Use the information in the contract to be tested to replace the placeholder of the target comment template to obtain the target comment.

[0082] In the disclosed embodiment, the standard contract template library and the standard annotation library are separated, and the correspondence between the standard contract template library and the standard annotation library can be flexibly adjusted to generate a contract to be tested according to actual scenario requirements and user needs.

[0083] First, the relationship between the contract under test and the annotation template, as well as the user-specified annotation level, must be clearly defined. The relationship between the contract under test and the annotation template can be a mapping between one contract under test and multiple annotation templates. Annotation levels can be defined based on actual needs (e.g., basic, intermediate, detailed, etc.). In this disclosure, annotation levels can be determined by the user themselves or based on their own permission level. Each level corresponds to a different annotation template, which has been previously defined and stored in a annotation template library. Once the annotation level is determined, the corresponding target annotation template can be retrieved from the annotation template library. Next, the necessary information is extracted from the contract under test. This information includes, but is not limited to, at least one of the following: function names, variable names, and parameters. This information forms the basis for generating annotations and will be used to replace placeholders in the annotation template. After extracting the contract under test information, the placeholders in the target annotation template can be replaced. This process can be a string replacement operation, replacing the template placeholders with the actual contract information. Finally, after the placeholder replacement is complete, the target annotation is obtained. The generated annotation text is directly inserted into the corresponding location in the contract code. This annotation not only contains the information required by the user-specified annotation level, but also combines the actual content of the contract to be tested, so it can accurately reflect the main content and characteristics of the contract.

[0084] For example, the user-indicated annotation levels mentioned above include but are not limited to at least one of the following: basic level, intermediate level, detailed level, etc. These annotation levels are divided according to the different types of people in the test process. The basic level, intermediate level, and detailed level annotation levels can be:

[0085] Test report issuer (basic level): only contains a brief description of the main functions and variables, such as the function's function and input / output parameters, so that they can quickly understand the main functions and test status of the smart contract.

[0086] Tested bottom chain personnel (intermediate level): Based on the basic level, add descriptions of key logic, expected results of important functions and possible abnormal situations, and provide detailed descriptions of key logic interacting with the bottom chain to enable them to understand the specific significance of the test report.

[0087] Auditor (Detailed Level): Based on the medium level, detailed descriptions of all parts of the contract are added, including detailed descriptions of functions, explanations of parameters and return values, to facilitate in-depth inspections by code auditors.

[0088] For example, based on the three roles defined above and their corresponding annotation levels, corresponding annotation templates are created for the contract templates in the standard contract library. Each template can include, but is not limited to, at least one description of a function and a variable, along with an appropriate level of detailed information. The templates are parameterized to facilitate filling in annotations based on the actual smart contract code. The contract template library is then associated with three different predefined annotation templates, forming a one-to-three mapping relationship. Finally, the annotations are generated. Users first select their desired standard contract template in the system. When selecting a template, they also select the level of annotation detail based on their role (test report issuer, tested underlying chain personnel, or auditor). Based on the selected contract template and the annotation level corresponding to their role, the system selects the corresponding annotation template from the annotation template library. Based on the selected annotation template and contract template, the system generates the corresponding annotations. Based on the changes to the standard contract, the system replaces the placeholders in the annotation template (such as function names, variable names, and parameters) with the specific annotation text. The generated annotation text is directly inserted into the corresponding location in the contract code, generating the target annotation.

[0089] With the above, the contract to be tested can be dynamically adjusted based on the contract template, and the target annotation can be adapted according to the user role.

[0090] In one embodiment of the present disclosure, illustratively, Figure 4 FIG is a schematic diagram illustrating the overall process of generating a contract to be tested according to an embodiment of the present disclosure. Figure 4 As shown:

[0091] First, select the contract template type and modify its parameters (e.g., standard template, custom template file configuration template, etc.). Contract templates allow administrators to customize them based on business needs and professional resource pool standard fields. Administrators can also preview, download, import, and batch delete smart contract templates. Next, the blockchain smart contract language feature library is used to generate standardized test smart contract source code from the user-selected template content. The smart contract editor then compiles the source code to generate a standardized test smart contract. Finally, the blockchain adapter allows the generated standardized smart contract to be deployed to the blockchain network.

[0092] In summary, we can determine the contract template by identifying the dependencies between meta-function modules and each meta-function module. This allows us to automatically generate test contracts for different scenarios, solving the problems of low efficiency and resource waste in testing scenarios. Below, we will specifically describe how to orchestrate the nodes and contracts under test with global load balancing as the goal, and how to obtain the orchestration relationship.

[0093] As follows, the method for obtaining an arrangement relationship according to an embodiment of the present disclosure includes:

[0094] Perform at least one round of matching relationship adjustment as follows until convergence, and determine the converged matching relationship as the orchestration relationship:

[0095] Obtain a first evaluation value corresponding to the initial matching relationship between the node to be tested and the contract to be tested. The first evaluation value is used to measure the global load balancing performance of the node cluster to be tested.

[0096] Adjust the matching relationship between the node to be tested and the contract to be tested, and obtain the adjusted second evaluation value;

[0097] When the second evaluation value is greater than the first evaluation value, the acceptance probability is determined to be 1; or, when the second evaluation value is less than the first evaluation value, the acceptance probability is determined based on the first evaluation value and the second evaluation value. The acceptance probability is used to guide the adjustment direction of the matching relationship, and the acceptance probability is the probability that the adjusted matching relationship is accepted.

[0098] In the disclosed embodiment, the initial matching relationship between the node to be tested and the contract to be tested can be the matching relationship between the node to be tested and the contract to be tested when the local load balancing is optimal. In this way, when the load balancing is locally optimal, with the global optimal as the goal, the workload of adjusting the matching relationship calculation can be reduced, and the efficiency of determining the orchestration relationship can be improved. Of course, when determining the optimal local load balancing, the matching method between the node to be tested and the contract to be tested includes but is not limited to at least one of the following: random matching, predetermined matching principle, and simple initial matching based on the processing capacity of the node and the resource requirements of the contract, etc.

[0099] In the disclosed embodiment, when a matching relationship between a node under test and a contract under test is obtained, a corresponding first evaluation value is calculated. The first evaluation value is used to measure global load balancing performance. In the disclosed embodiment, the first evaluation value includes at least global resource utilization, and resources include, but are not limited to, at least one of the following: memory resources and central processing unit (CPU) resources.

[0100] In the embodiment of the present disclosure, when calculating the resource utilization of a single node, the following formula is satisfied:

[0101]

[0102] When using the resource utilization of a single node to calculate the global resource utilization, at least one of the following methods may be used, including but not limited to: cumulative average method, weighted average method, maximum representative method, real-time monitoring and statistical analysis, and distributed tracking system, so as to obtain the global resource utilization.

[0103] Specifically, the cumulative average method can be to collect resource utilization data of each node, and then add up these utilizations to get the total resource usage. Summarize the total amount of resources such as the number of CPU cores and total memory of all nodes. Cumulative average is used to get the global resource utilization. The weighted average method can be to calculate the global utilization by weighted average based on the actual configuration weight of each node, that is, to assign different computing proportions to different nodes. The maximum representative method can be used in some cases. If you are concerned about the bottleneck resources of the system, you can choose the node with the highest resource utilization in the cluster as the reference standard for global resource utilization. Real-time monitoring and statistical analysis can use monitoring tools to obtain and summarize the resource usage of each node in real time, and use data analysis software to integrate and calculate the global resource utilization. Distributed tracing systems can use distributed tracing systems to track and record the resource consumption of each node, and aggregate and calculate this information through a central coordinator or stream processing framework to obtain global resource utilization.

[0104] In the disclosed embodiments, adjusting the matching relationship between the node under test and the contract under test includes, but is not limited to, at least one of the following methods: swapping the contract under test between the nodes under test, transferring the contract under test from the node under test to the target node under test, reallocating the contract under test to a different node under test, etc., thereby completing the adjustment between the node under test and the contract under test. Simultaneously, a second evaluation value is calculated after the adjustment, and the aforementioned evaluation value calculation method can be reused for the second evaluation value.

[0105] In the embodiment of the present disclosure, after obtaining the first evaluation value and the second evaluation value, the two evaluation values ​​will be compared: if the second evaluation value is greater than the first evaluation value, it means that the adjusted matching relationship has improved the global load balancing performance, and the acceptance probability is 1 at this time, that is, the adjustment is directly accepted. If the second evaluation value is less than the first evaluation value, it means that the adjusted matching relationship has reduced the global load balancing performance. At this time, it is necessary to determine the acceptance probability based on the first evaluation value and the second evaluation value. According to the calculated acceptance probability, use random or other methods to decide whether to accept this adjustment. If accepted, then the current matching relationship is determined to be the adjusted matching relationship; if not accepted, then the original matching relationship and evaluation value remain unchanged.

[0106] In the embodiment of the present disclosure, the acceptance probability when the second evaluation value is less than the first evaluation value is determined based on the first evaluation value and the second evaluation value. In actual applications, it must also be set considering specific business needs and strategies. For example, a function can be used to calculate the acceptance probability, which takes into account the extent of performance degradation and other relevant factors.

[0107] Specifically, in the embodiment of the present disclosure, when the second evaluation value is less than the first evaluation value, the acceptance probability satisfies the following formula:

[0108]

[0109] P is the probability of whether the adjusted matching relationship is accepted during the matching process. T is the manually set parameter for whether to iterate forward.

[0110] As T gradually decreases, the acceptance probability of P gradually decreases. Therefore, at the beginning of matching, it is more inclined to accept the matching relationship before adjustment to explore a wider solution space; in the middle of matching, it gradually converges to the optimal matching relationship, but some matching relationships before adjustment are still accepted; in the late stage of matching, it mainly accepts the matching relationship after adjustment, thus achieving the global optimum.

[0111] In the disclosed embodiment, after each matching relationship adjustment, a check is performed to determine whether convergence conditions are met. Convergence conditions include, but are not limited to, at least one of the following: reaching a certain number of adjustments, or a change in the evaluation value being less than a preset threshold. If the convergence conditions are met, matching relationship adjustment is terminated, and the current matching relationship is determined as the final arrangement relationship. If not, the process proceeds to the next round of matching relationship adjustment.

[0112] In summary, to determine the orchestration relationship, we can obtain the initial matching relationship between the node under test and the contract under test. We then calculate the first evaluation value corresponding to this initial matching relationship. Based on the policy, we adjust the matching relationship between the node under test and the contract under test. After adjusting the matching relationship, we recalculate the global load balancing performance to obtain the second evaluation value. We then compare the evaluation values ​​and determine the acceptance probability. Finally, after each matching relationship adjustment, we check whether the convergence condition is met. If the convergence condition is met, we stop adjusting the matching relationship and determine the current matching relationship as the final orchestration relationship. If not, we proceed to the next round of matching relationship adjustment. This allows us to determine the matching relationship between the node under test and the contract under test, which optimizes global load balancing and serves as the orchestration relationship.

[0113] Exemplarily, the optimal method for obtaining the arrangement relationship according to an embodiment of the present disclosure includes:

[0114] First, we define the solution space and the objective function: the solution space is the set of all possible matching combinations of the nodes to be tested and the contracts to be tested. An objective function can be used to measure the quality of each solution.

[0115] The objective function satisfies the following formula:

[0116] f(solution) = ω1·coverage + ω2·utilization + ω3·load balancing

[0117] Here, ω1+ω2+ω3=1 represents the weight of the three indicators. Coverage indicates the comprehensiveness of the test. Utilization represents the efficiency of node resource usage. Load balance indicates the degree of balance of the test load across nodes.

[0118] Next, we designed contract dependency constraints. In test scenarios, some contracts have dependencies. For each pair of dependencies, the dependent contract must execute after the dependent contract. The standard smart contract template can identify dependencies through the "meta-function model hypergraph," or manually set them. Because dependent contracts are deployed on different test nodes, synchronization, latency, and idle load issues arise. Therefore, we constrain interdependent contracts to execute sequentially on the same node to reduce task complexity while ensuring sequential contract execution. Dependency constraints define a dependency list for each contract, listing the other contracts it depends on. (For example, if Contract A must execute before Contract B, then Contract A is said to depend on Contract B.) For each pair of dependencies, the dependent contract must execute before the dependent contract; we constrain the dependent contracts to be tested on the same test node. Therefore, we merge interdependent contracts into a new contract, which is then matched to the test node along with the other contracts.

[0119] Then, a local optimal solution can be generated as the initial solution. The generation method includes: Initialization: All nodes and contracts are unmatched. Select Next Element: Find an unmatched node and an unmatched contract such that matching them maximizes a local criterion (such as coverage, utilization, etc.). Check Completeness: If all nodes and contracts are matched, return the current matching solution. Otherwise, return to the previous step.

[0120] Furthermore, the matching relationship can be adjusted: swap operation: swap the contracts of two nodes i and j; move operation: move the contract from node i to node k.

[0121] Also, compare the new solution matching scheme with the current solution matching scheme:

[0122] When the new solution matches the current solution, the new solution is accepted.

[0123] When the new solution is worse than the current solution, there is a certain probability that the new solution will be accepted, that is, a step back will be taken to explore more matching solutions.

[0124] The above comparison scheme satisfies the following formula:

[0125] If f(new solution)>f(current solution), then P(accept)=1

[0126] otherwise

[0127] This formula defines the probability of a new solution being accepted during the matching process. If the new solution is better than the current solution, it is immediately accepted; otherwise, the probability of acceptance is related to the difference in the objective function between the new and current solutions, as well as the current T. T is a manually set parameter that determines whether to iterate. As T gradually decreases, the probability P of accepting a suboptimal solution gradually decreases. At the beginning of the matching process, suboptimal solutions are more likely to be accepted to explore a wider range of solution spaces. In the middle of the matching process, the system gradually converges to the optimal solution, but some suboptimal solutions are still accepted. In the later stages of the matching process, new solutions that are better than the current solution are mainly accepted, thus reaching the global optimum.

[0128] Finally, a convergence solution is designed to satisfy the following formula:

[0129] T new =α·T old , where α∈(0,1)

[0130] In the process of matching test nodes with test contracts, T helps strike a balance between exploration and exploitation. A higher T encourages exploring new, unknown matching solutions, even if they are not the best options at the moment; a lower T encourages focusing on known good solutions, optimizing and refining them.

[0131] In this way, through the above solution, we have obtained the optimal matching solution between test contracts and test nodes.

[0132] In summary, the above solution allows for the matching and orchestration of the nodes under test and the contracts under test, resulting in a globally load-balanced matching relationship between the nodes under test and the contracts under test as the orchestration relationship. The following describes the deployment of the nodes under test and the contracts under test based on this orchestration relationship.

[0133] The method for deploying the contract to be tested and the node to be tested according to an embodiment of the present disclosure includes:

[0134] Based on a deployment plug-in adapted to the blockchain and based on the orchestration relationship, the contract to be tested and the node to be tested are deployed.

[0135] In the disclosed embodiments, when deploying the node and contract under test, a suitable deployment plugin can be selected. This is based on the blockchain platform being used and its characteristics. These plugins are typically provided by the blockchain platform or a third party to simplify contract deployment and node management. Of course, ensure that the contract under test is fully written and tested, and that the node under test is configured and operational. This may include, but is not limited to, at least one of the following steps: setting the node's network configuration, security authentication, and resource limits. Determining the orchestration relationship between the contract under test and the node under test. Next, using the deployment plugin's configuration tool, configure the deployment parameters for the contract under test and the node under test. This may include, but is not limited to, at least one of the following: the name of the test contract, the number of test contract processes, the installation function, the test contract's deployment address, node connection information, and resource allocation. The deployment plugin's execution command then triggers the contract's compilation, packaging, and deployment. The plugin automatically handles interactions with the blockchain platform and performs deployment.

[0136] Through the above steps, you can deploy the contract to be tested and the node to be tested based on the deployment plug-in adapted to the blockchain according to the orchestration relationship. This approach can simplify the complexity of contract deployment, improve deployment efficiency and accuracy, and ensure that the contract can run on the correct node to meet business needs.

[0137] Furthermore, the method for deploying the contract to be tested and the node to be tested according to an embodiment of the present disclosure includes:

[0138] Based on the characteristics of the blockchain underlying chain, obtain the deployment plug-in adapted to the characteristics of the underlying chain;

[0139] Using the information of the contract to be tested and the node to be tested in the orchestration relationship, the placeholders in the deployment plug-in adapted to the characteristics of the underlying chain are replaced to complete the deployment of the contract to be tested and the node to be tested.

[0140] In the disclosed embodiments, the underlying blockchain used must first be analyzed to understand at least one of its characteristics, functions, limitations, and interactions with other components. In the disclosed embodiments, the blockchain includes, but is not limited to, at least one of the following: a distributed ledger platform (Fabric), an Enterprise Operating System (EOS), the Financial Industry Secure Computing Organization Blockchain Open Source Platform (FISCO BCOS), and Changan Chain.

[0141] Next, based on the characteristics of the underlying chain, select or develop appropriate deployment plugins. These plugins should fully leverage the capabilities of the underlying chain while overcoming its potential limitations. Ensure that the plugins can interact efficiently with the underlying chain and support operations such as contract compilation, deployment, upgrades, and monitoring.

[0142] Then, the relationship between the contract to be tested and the node to be tested in the orchestration relationship is determined to include but is not limited to one of the following relationships: mapping relationship, configuration parameters and other related information.

[0143] Furthermore, because deployment plugins typically contain placeholders for dynamically inserting at least one piece of information, such as specific contract addresses and node configurations, during the deployment process, these placeholders can be replaced using the information about the contract and node under test in the orchestration relationship. This can be automated through at least one of scripting or using specialized tools.

[0144] Finally, after completing the placeholder replacement, use the deployment plugin to perform the deployment operation.

[0145] With the above, we can retrieve the appropriate deployment plugin based on the characteristics of the underlying blockchain and use the information in the orchestration relationship to deploy the contract and node under test. This approach ensures efficient and accurate deployment while fully leveraging the functionality and characteristics of the underlying blockchain.

[0146] For example, Figure 5 This is a code diagram illustrating the EOS bottom chain adaptation to the deployment of the node to be tested and the contract to be tested according to the embodiment of the present disclosure. Figure 5 As shown:

[0147] First, get the name of the linker test through the getType() function; then get the number of processes for this test through the getWorkerIndex() function. The main function of this function is to determine the number of processes used for this test; the init(workerInit) function is used to initialize the entire linker process; installSmartContract() is mainly a contract installation function, which is used to define the contract used for this link; the prepareWorkerArguments() function is used to manage the process, and its main purpose is to ensure that the linker can distribute data stably to complete the test; the releaseContext() function is used to release resources after each test; the sendRequests() function is the key function in the connection. The main content of this function is the content sent to the blockchain to be tested each time. At the same time, this function will also send the start time t1, end time t1 and status (success or failure) of each contract; finally, the constructor() function ends.

[0148] For example, Figure 6 is a code diagram illustrating deployment parameter settings according to an embodiment of the present disclosure.

[0149] like Figure 6 As shown:

[0150] Figure 6 The main purpose of the code is to define the address (IP), port, and wallet key of the blockchain being tested, so as to ensure that the linker can accurately connect to the blockchain being tested.

[0151] For example, in one embodiment of the present disclosure, Figure 7 Schematic diagram illustrating the best method for deploying the contract to be tested and the node to be tested according to an embodiment of the present disclosure. Figure 7 As shown, it includes: Software Development Kit (SDK) selection and parameter configuration of the bottom link interface.

[0152] First, based on the characteristics of each underlying blockchain, the SDKs for each underlying chain link are compiled and the underlying chain interface SDK is selected. Tested blockchains include, but are not limited to, at least one of the following: Fabric, EOS, FISCO BCOS, and Changan Chain. Next, basic test parameters are set using the benchmark configuration file. The network configuration file specifies at least one of the following: the address, port, and wallet key of the blockchain being tested, enabling the linker to accurately connect to the tested blockchain. Finally, the link between the tested node and the tested contract on the tested blockchain is completed.

[0153] In summary, we can deploy the nodes and contracts to be tested based on the orchestration relationship. Below, we will provide a detailed introduction to testing the successfully deployed nodes and the corresponding contracts to be tested.

[0154] The method for testing a node to be tested and a corresponding contract to be tested according to an embodiment of the present disclosure includes:

[0155] Test each node to be tested and the corresponding contract to be tested, and obtain test data;

[0156] Based on the test data, a target node to be tested is determined among the nodes to be tested.

[0157] Adjust the target node to be tested.

[0158] In the disclosed embodiments, when testing a node under test and its corresponding contract under test, the test environment is first established, including the required node under test, contract under test, and at least one of the necessary testing tools and frameworks. Furthermore, the test environment is ensured to be as consistent as possible with the production environment to obtain accurate test data. Next, the node under test and its corresponding contract under test are tested within the test environment. It should be noted that in the disclosed embodiments, testing methods include, but are not limited to, at least one of the following: sequential testing or unified synchronous testing. This allows for simulating real-world operations and recording test data and results. After the test is complete, the data generated during the test is collected. This test data includes at least test duration. The accuracy and completeness of the data are ensured for subsequent analysis. Furthermore, the collected test data is analyzed to identify performance bottlenecks, errors, or anomalies. The test data can be visualized and quantitatively analyzed by, for example, plotting charts, calculating averages, standard deviations, or other methods. Based on the test data analysis results, target nodes under test that require adjustment are identified. Target nodes under test include, but are not limited to, at least one of the following: nodes with poor performance, nodes with high error rates, or nodes with inappropriate resource utilization. Finally, targeted adjustment strategies can be developed based on the specific circumstances of the target node under test. These strategies may include, but are not limited to, at least one of the following: optimizing contract code, adjusting node configuration, increasing or decreasing resource allocation, etc. By adjusting the target node under test according to the developed adjustment strategy, the performance of the entire system is improved.

[0159] Exemplarily, a preferred method for adjusting a target node to be tested according to an embodiment of the present disclosure includes:

[0160] First, the test data of each test node is collected through the base. The test start time t1, end time t1 and status (success or failure) are recorded for each round of testing. Then the average completion time of each round of smart contract is, which satisfies the following formula:

[0161] t n =t1-t2(n=1,2,3....)

[0162] Assuming that a total of n tests are performed, the average delay for each test satisfies the following formula:

[0163]

[0164] t is the average delay time of this test.

[0165] The success rate is calculated using the following formula. When this round of testing is successful, the following formula is satisfied: P = P + 1

[0166] Assuming that a total of n tests are performed, the test success rate satisfies the following formula: w = P / (n+1)

[0167] At this point, the key performance parameter indicators: success rate and average delay have been obtained.

[0168] Then, based on the performance parameter indicators, high-frequency requests are sent to nodes with poor performance to effectively discover the worst-performing nodes in the tested distributed blockchain system.

[0169] Finally, the blockchain system capabilities can be improved by transforming the nodes with the worst performance.

[0170] In summary, we can test each node under test and the corresponding contract under test, and determine the target node under test based on the test data for adjustment. This helps to discover and resolve performance issues and improve system stability and efficiency.

[0171] For example, Figure 8 Schematic diagram of a preferred blockchain testing method according to an embodiment of the present disclosure. Figure 8 As shown:

[0172] First, each test node and each contract transaction are matched together using a test transaction orchestrator, using a resource matrix-based approach. Contract transactions can be derived from the aforementioned contract templates. Next, after matching each test node with each contract transaction, the transactions are integrated into a test transaction library. Execution adapters are then used to assign different nodes to cluster testing of different smart contracts. The adapter can be thought of as a deployment mechanism, deploying different nodes and different smart contracts. Finally, a standardized test report is automatically generated.

[0173] For example, Figure 9 : is a schematic diagram illustrating a preferred blockchain test system according to an embodiment of the present disclosure. Figure 9 As shown:

[0174] The entire blockchain system includes smart contract management, test transaction orchestration, test resource scheduling, and test process management.

[0175] Smart contract management: Generate a standard smart contract set through templates and deploy standardized test smart contracts to the blockchain system under test.

[0176] Test transaction orchestration: Through the test resource pool and smart contract set matrix orchestration, test transactions, standardize the scheduling of test resources and smart contract execution process.

[0177] Test resource scheduling: Multiple test nodes form a test resource pool, and the nodes in the resource pool are scheduled and managed through various test load models.

[0178] Test process management: This invention uses a plug-in extension method to construct a blockchain access interface adapter. Through this method, users can flexibly and efficiently test multiple blockchains. It also provides unified test process management operations.

[0179] Figure 10 : is a diagram illustrating the overall device of the blockchain test according to an embodiment of the present disclosure. Figure 10 As shown, the blockchain testing device 1000 includes a node acquisition unit 1001, a contract acquisition unit 1002, an orchestration unit 1003, a deployment unit 1004 and a testing unit 1005.

[0180] The node acquisition unit 1001 is configured to acquire at least one node to be tested in the blockchain.

[0181] The contract acquisition unit 1002 acquires at least one contract to be tested. The contract to be tested is obtained based on a contract template. The contract template includes meta-functional modules and dependency relationships between the meta-functional modules.

[0182] The orchestration unit 1003 is configured to orchestrate the nodes to be tested and the contracts to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship.

[0183] The deployment unit 1004 is configured to deploy the contract to be tested and the node to be tested according to the arrangement relationship.

[0184] The testing unit 1005 is configured to test the node to be tested and the corresponding contract to be tested.

[0185] In an exemplary embodiment, the contract acquisition unit 1002 is specifically used to obtain any contract to be tested in the following manner: in the contract template, obtain the target meta-functional module indicated by the user; based on the dependency relationship of each target meta-functional module, merge the pseudocode of each target meta-functional module; compile the merged pseudocode according to the target programming language to obtain the contract to be tested.

[0186] In an exemplary embodiment, the contract acquisition unit 1002 is specifically used to: acquire the target annotation template based on the correspondence between the contract to be tested and the annotation template, and based on the annotation level indicated by the user; use the information in the contract to be tested to replace the placeholder of the target annotation template to obtain the target annotation.

[0187] In an exemplary embodiment, the orchestration unit 1003 is specifically used to: perform at least one round of matching relationship adjustment in the following manner until convergence, and determine the converged matching relationship as the orchestration relationship: obtain a first evaluation value corresponding to the initial matching relationship between the node to be tested and the contract to be tested, and the first evaluation value is used to measure the global load balancing performance of the node cluster to be tested; adjust the matching relationship between the node to be tested and the contract to be tested, and obtain an adjusted second evaluation value; when the second evaluation value is greater than the first evaluation value, determine the acceptance probability to be 1; or, when the second evaluation value is less than the first evaluation value, determine the acceptance probability based on the first evaluation value and the second evaluation value, and the acceptance probability is used to guide the adjustment direction of the matching relationship, and the acceptance probability is the probability that the adjusted matching relationship is accepted.

[0188] In an exemplary embodiment, the initial matching relationship is a matching relationship between the node to be tested and the contract to be tested when the local load balancing is optimal.

[0189] In an exemplary embodiment, the first evaluation value includes at least: global resource utilization, and the resources include at least one of the following: memory resources and central processing unit (CPU) resources.

[0190] In an exemplary embodiment, the deployment unit 1004 is specifically configured to deploy the contract to be tested and the node to be tested based on a deployment plug-in adapted to the blockchain and based on an orchestration relationship.

[0191] In an exemplary embodiment, the deployment unit 1004 is specifically used to: obtain a deployment plug-in adapted to the underlying chain characteristics based on the blockchain underlying chain characteristics; use the information of the contract to be tested and the node to be tested in the orchestration relationship to replace the placeholders in the deployment plug-in adapted to the underlying chain characteristics, and complete the deployment of the contract to be tested and the node to be tested.

[0192] In an exemplary embodiment, the testing unit 1005 is specifically used to: test each node to be tested and the corresponding contract to be tested, and obtain test data; determine a target node to be tested among the nodes to be tested based on the test data; and adjust the target node to be tested.

[0193] In an exemplary embodiment, the test data at least includes: test duration.

[0194] Figure 11 1 is a hardware block diagram illustrating an electronic device 1100 according to an embodiment of the present disclosure. The electronic device according to an embodiment of the present disclosure includes at least a processor and a memory for storing computer-readable instructions. When the computer-readable instructions are loaded and executed by the processor, the processor executes the network access method described above.

[0195] Figure 11The electronic device 1100 shown specifically includes: a central processing unit (CPU) 1101, a graphics processing unit (GPU) 1102, and a memory 1103. These units are interconnected via a bus 1104. The central processing unit (CPU) 1101 and / or the graphics processing unit (GPU) 1102 can be used as the above-mentioned processor, and the memory 1103 can be used as the above-mentioned memory for storing computer-readable instructions. In addition, the electronic device 1100 may also include a communication unit 1105, a storage unit 1106, an output unit 1107, an input unit 1108, and an external device 1109, which are also connected to the bus 1104.

[0196] Figure 12 Schematic diagram of a computer-readable storage medium according to an embodiment of the present disclosure. Figure 12 As shown, a computer-readable storage medium 1200 according to an embodiment of the present disclosure has computer-readable instructions 1201 stored thereon. When the computer-readable instructions 1201 are executed by a processor, the network access method according to the embodiment of the present disclosure described with reference to the above figures is executed. The computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, optical disk, magnetic disk, etc.

[0197] The blockchain testing method, apparatus, system, and electronic device according to the embodiments of the present disclosure have been described above with reference to the accompanying drawings. These methods obtain nodes and contracts to be tested and orchestrate them with the goal of achieving optimal global load balancing. The contracts and nodes to be tested are deployed based on the orchestration relationship, and then the nodes and contracts to be tested are tested. Because each contract to be tested is derived from the same contract template, the underlying logic of the contract to be tested is identical, providing a standardized test contract applicable to multiple blockchains. This simplifies the entire testing process and improves testing efficiency when comparing multiple blockchains. Furthermore, because the contract template is a rational and effective assembly of various meta-functional modules with dependencies, and each test contract is derived based on the contract template, each contract is implemented based on the dependencies between the meta-functional modules. This saves resources, reduces the computational effort required by the nodes and contracts to be tested during the orchestration process, and improves testing efficiency. Orchestration strategies that aim for optimal global load balancing can more accurately simulate the resource consumption and performance of real-world blockchain testing environments. This allows for a rational orchestration between the nodes and contracts under test to reduce resource waste, adapt to diverse standardized testing requirements, and improve operational efficiency. Plugin-based deployment allows for flexible and efficient adaptation to multiple blockchains. This makes blockchain testing highly adaptable and improves testing efficiency.

[0198] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0199] The basic principles of the present disclosure have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this disclosure are merely illustrative and not restrictive, and should not be construed as necessarily possessed by each embodiment of the present disclosure. Furthermore, the specific details disclosed above are provided for illustrative purposes and to facilitate understanding, rather than as limitations. These details do not limit the present disclosure to necessarily being implemented using these specific details.

[0200] The block diagrams of the devices, devices, equipment, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and can be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and can be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and can be used interchangeably therewith.

[0201] Additionally, as used herein, "or" used in a list of items beginning with "at least one" indicates a separate list, so that, for example, a list of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not mean that the example described is preferred or better than other examples.

[0202] It should also be noted that in the system and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0203] Various changes, substitutions, and modifications may be made to the technology herein without departing from the teachings as defined by the appended claims. Moreover, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of things, means, methods, and actions described above. Currently existing or later developed processes, machines, manufactures, compositions of things, means, methods, or actions that perform substantially the same function or achieve substantially the same results as the corresponding aspects herein may be utilized. Accordingly, the appended claims include within their scope such processes, machines, manufactures, compositions of things, means, methods, or actions.

[0204] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0205] The above description has been provided for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A blockchain testing method, characterized in that: The method comprises: Obtain at least one node to be tested in the blockchain; Obtain at least one contract to be tested, where the contract to be tested is obtained based on a contract template, where the contract template includes meta-function modules and dependencies between the meta-function modules; With the goal of optimizing global load balancing, orchestrate the nodes to be tested and the contracts to be tested to obtain an orchestration relationship; Deploy the contract to be tested and the node to be tested according to the arrangement relationship; Test the node to be tested and the corresponding contract to be tested.

2. The method according to claim 1, characterized in that The obtaining of at least one contract to be tested includes obtaining any one of the contracts to be tested in the following manner: In the contract template, obtaining a target meta-function module indicated by the user; Based on the dependency relationship of each target meta-function module, merging the pseudo codes of each target meta-function module; The combined pseudocode is compiled according to the target programming language to obtain the contract to be tested.

3. The method according to claim 2, characterized in that The method of obtaining any one of the contracts to be tested in the following manner further includes: Based on the correspondence between the contract to be tested and the annotation template, and based on the annotation level indicated by the user, obtaining a target annotation template; The target annotation template is replaced with a placeholder by using the information in the contract to be tested to obtain the target annotation.

4. The method according to claim 1, wherein The step of orchestrating the nodes to be tested and the contracts to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship includes: Perform at least one round of matching relationship adjustment in the following manner until convergence, and determine the converged matching relationship as the arrangement relationship: Obtaining a first evaluation value corresponding to an initial matching relationship between the node to be tested and the contract to be tested, where the first evaluation value is used to measure the global load balancing performance of the node cluster to be tested; Adjusting the matching relationship between the node to be tested and the contract to be tested, and obtaining an adjusted second evaluation value; When the second evaluation value is greater than the first evaluation value, the acceptance probability is determined to be 1; or, when the second evaluation value is less than the first evaluation value, the acceptance probability is determined based on the first evaluation value and the second evaluation value, and the acceptance probability is used to guide the adjustment direction of the matching relationship, and the acceptance probability is the probability that the adjusted matching relationship is accepted.

5. The method according to claim 4, characterized in that The initial matching relationship is the matching relationship between the node to be tested and the contract to be tested when the local load balancing is optimal.

6. The method according to claim 4, characterized in that The first evaluation value includes at least: global resource utilization, and the resources include at least one of the following: memory resources and central processing unit (CPU) resources.

7. The method according to claim 1, characterized in that The deploying the contract to be tested and the node to be tested according to the arrangement relationship includes: Based on a deployment plug-in adapted to the blockchain and based on the orchestration relationship, the contract to be tested and the node to be tested are deployed.

8. The method according to claim 7, characterized in that The deploying of the contract to be tested and the node to be tested based on the deployment plug-in adapted to the blockchain and based on the orchestration relationship includes: Based on the characteristics of the blockchain underlying chain, obtain a deployment plug-in adapted to the characteristics of the underlying chain; The information of the contract to be tested and the node to be tested in the orchestration relationship is used to replace the placeholder in the deployment plug-in adapted to the bottom chain characteristics, thereby completing the deployment of the contract to be tested and the node to be tested.

9. The method according to claim 1, characterized in that The testing of the node to be tested and the corresponding contract to be tested includes: Testing each of the nodes to be tested and the corresponding contracts to be tested, and obtaining test data; Based on the test data, determining a target node to be tested among the nodes to be tested; Adjust the target node to be tested.

10. The method according to claim 9, characterized in that The test data at least includes: test duration.

11. A blockchain testing device, characterized in that: The device comprises: A node acquisition unit, configured to acquire at least one node to be tested in the blockchain; A contract acquisition unit is configured to acquire at least one contract to be tested, wherein the contract to be tested is obtained based on a contract template, wherein the contract template includes meta-function modules and dependency relationships between the meta-function modules; An orchestration unit is configured to orchestrate the node to be tested and the contract to be tested with the goal of optimizing global load balancing to obtain an orchestration relationship; A deployment unit, configured to deploy the contract to be tested and the node to be tested according to the arrangement relationship; The testing unit is configured to test the node to be tested and the corresponding contract to be tested.

12. An electronic device, characterized in that: include: a memory for storing computer-readable instructions; as well as A processor, configured to run the computer-readable instructions so that the electronic device performs the blockchain testing method according to any one of claims 1 to 10.

13. A non-transitory computer-readable storage medium for storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by a processor, the processor is caused to perform the blockchain testing method according to any one of claims 1 to 10.

14. A computer program product, characterized in that The method comprises a computer program, wherein the computer program is executed by a processor to implement the blockchain testing method according to any one of claims 1 to 10.

Images