Block chain protocol reliability verification method based on metamorphic test and related device

Abstract

The invention belongs to a verification method, and provides a block chain protocol reliability verification method based on a metamorphic test and a related device for solving the technical problems that an existing block chain protocol reliability verification method is high in calculation complexity and difficult to apply to an actual large-scale network. The method comprises the following steps of: taking components as a metamorphic test object, performing formalized definition on a metamorphic relationship which needs to be met by each component in the metamorphic test object, generating an original test case and a subsequent test case, respectively executing the original test case and the subsequent test case, and correspondingly obtaining an original output result and a subsequent output result; and finally carrying out reliability verification on the original output result and the subsequent output result until corresponding potential vulnerability information is obtained. The test efficiency is remarkably improved, and rapid verification of a large-scale block chain network is supported.

Description

Technical Field

[0001] This application belongs to a verification method, and specifically relates to a method and related device for verifying the reliability of blockchain protocols based on metamorphic testing. Background Art

[0002] As a decentralized distributed ledger technology, blockchain technology has been widely applied in recent years in fields such as financial transactions, supply chain management, and digital identity authentication.

[0003] Currently, the verification of the reliability of blockchain protocols mainly relies on traditional software testing methods, such as unit testing, integration testing, and stress testing. The following are the main significant limitations: (1) Difficulty in obtaining test oracles: The complexity of blockchain systems makes the definition cost of expected outputs high. Especially when it comes to consensus mechanisms involving multi-node collaboration or the dynamic execution of smart contracts, it is difficult to exhaust all possible scenarios.

[0004] (2) Poor adaptability to dynamic environments: Under abnormal conditions such as network partitioning, node failures, or high loads, existing methods are difficult to effectively simulate and verify the actual behavior of protocols, resulting in hidden defects being difficult to discover.

[0005] To address the above limitations, some research has attempted to introduce formal verification methods, such as model checking or theorem proving, to analyze blockchain protocols. However, these methods usually require high mathematical modeling capabilities, and the computational complexity increases exponentially with the increase in protocol scale, making it difficult to apply to actual large-scale networks. Summary of the Invention

[0006] This application aims at the technical problems of the existing reliability verification methods for blockchain protocols, which have high computational complexity and are difficult to apply to actual large-scale networks, and provides a method and related device for verifying the reliability of blockchain protocols based on metamorphic testing.

[0007] To achieve the above objective, this application is implemented by adopting the following technical solutions: In a first aspect, this application proposes a method for verifying the reliability of blockchain protocols based on metamorphic testing, including: Determine the components used for metamorphic testing in the blockchain protocol as the metamorphic testing objects; Formalize the metamorphic relationships that each component in the metamorphic testing object needs to satisfy according to the implementation mechanism, function documentation, and existing vulnerability reports of the metamorphic testing object; Generate original test cases, and generate subsequent test cases corresponding to the original test cases according to the formalized metamorphic relationships; Execute the original test cases and subsequent test cases respectively, and obtain the original output results and subsequent output results correspondingly; Verify the reliability of the original output result and the subsequent output result. If it meets the expected expectations of the metamorphic relationship, regenerate the original test case and the subsequent test case. Otherwise, obtain the corresponding potential vulnerability information.

[0008] In a second aspect, the present application proposes a blockchain protocol reliability verification system based on metamorphic testing, including: An object determination module, configured to determine the components used for metamorphic testing in the blockchain protocol as metamorphic testing objects; A definition module, configured to formally define the metamorphic relationships that each component in the metamorphic testing object needs to satisfy according to the implementation mechanism, function documentation, and existing vulnerability reports of the metamorphic testing object; A test case module, configured to generate an original test case and generate a subsequent test case corresponding to the original test case according to the formally defined metamorphic relationship; An execution module, configured to execute the original test case and the subsequent test case respectively, and obtain the original output result and the subsequent output result correspondingly; A verification module, configured to verify the reliability of the original output result and the subsequent output result. If it meets the expected expectations of the metamorphic relationship, regenerate the original test case and the subsequent test case. Otherwise, obtain the corresponding potential vulnerability information.

[0009] In a third aspect, the present application proposes an electronic device, including: a memory, one or more processors; the memory is coupled to the processor; wherein, computer program code is stored in the memory, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device executes the steps of the above-mentioned blockchain protocol reliability verification method based on metamorphic testing.

[0010] In a fourth aspect, the present application proposes a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the steps of the above-mentioned blockchain protocol reliability verification method based on metamorphic testing are implemented.

[0011] Compared with the prior art, the present application has the following beneficial effects: The present application proposes a method for verifying the reliability of blockchain protocols based on metamorphic testing. Components for metamorphic testing in the blockchain protocol are determined as the metamorphic testing objects. Then, the metamorphic relationships that each component in the metamorphic testing objects needs to satisfy are formally defined. Next, original test cases and subsequent test cases are generated, and the original test cases and subsequent test cases are executed respectively to obtain the original output results and subsequent output results. Finally, the reliability of the original output results and subsequent output results is verified until the corresponding potential vulnerability information is obtained. It can verify the behavior of the blockchain protocol under dynamic conditions without pre-defining specific outputs, enhancing the adaptability to the decentralized environment, effectively identifying the reliability problems of the protocol in abnormal scenarios, and providing guarantee for the improvement of system robustness and security. By designing formal metamorphic relationships for each component, comprehensive verification in multiple dimensions such as consistency, security, availability, and robustness is achieved. The present application significantly improves the testing efficiency and supports the rapid verification of large-scale blockchain networks.

[0012] The present application also proposes a system for verifying the reliability of blockchain protocols based on metamorphic testing, an electronic device, and a computer-readable storage medium, which have all the advantages of the above-mentioned method for verifying the reliability of blockchain protocols based on metamorphic testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the accompanying drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0014] Figure 1 It is a schematic diagram of the method for verifying the reliability of blockchain protocols based on metamorphic testing of the present application; Figure 2 It is a schematic diagram of a simplified blockchain protocol architecture for cryptocurrency custody; Figure 3 It is another flowchart of the method for verifying the reliability of blockchain protocols based on metamorphic testing of the present application; Figure 4 For Figure 3 the contract code of the blockchain protocol architecture in Figure 5 It is a schematic diagram of the system for verifying the reliability of blockchain protocols based on metamorphic testing of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0015] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are some, but not all, of the embodiments of this application. Usually, the components of the embodiments of this application described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations.

[0016] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application that is claimed, but merely represents selected embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of this application without creative efforts shall fall within the scope of protection of this application.

[0017] It should be noted that: like reference numerals and letters denote like items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0018] In the description of the embodiments of this application, it should be noted that if terms such as "upper", "lower", "horizontal", "inner", etc. indicate orientations or positional relationships, they are based on the orientations or positional relationships shown in the accompanying drawings, or the orientations or positional relationships in which the inventive product is customarily placed during use. This is only for the convenience of describing this application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. In addition, terms such as "first", "second", etc. are only used for descriptive distinction and cannot be understood as indicating or implying relative importance.

[0019] In addition, if the term "horizontal" appears, it does not mean that the component is required to be absolutely horizontal, but it can be slightly inclined. For example, "horizontal" only means that its direction is more horizontal relative to "vertical", and does not mean that the structure must be completely horizontal, but it can be slightly inclined.

[0020] In the description of the embodiments of this application, it should also be noted that unless otherwise clearly specified and limited, if terms such as "set", "installed", "connected", "connected to" are understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0021] The core of blockchain technology lies in achieving high reliability, immutability, and transparency of data through a decentralized network and specific protocol mechanisms. The reliability of blockchain protocols directly determines whether the system can withstand failures, attacks, and maintain consistent operation in a distributed environment. Therefore, the verification of protocols has become a crucial link in the development of blockchain technology.

[0022] In existing technologies, the reliability verification of blockchain protocols mainly relies on traditional software testing methods. These methods usually rely on predefined input-output pairs and judge the correctness of system behavior by comparing the actual output with the expected results. For example, in the Bitcoin network, the implementation of proof of work (PoW) verifies the validity of blocks through computing power competition, and the testing methods often focus on checking the correctness of hash calculations. In Ethereum, the testing of smart contracts is mostly based on manually constructing transaction inputs to verify state changes. However, since blockchain protocols run in a decentralized environment, their outputs are affected by various dynamic factors such as network latency, node behavior, and malicious attacks. Traditional testing methods have significant limitations in the following aspects: In the current booming development of blockchain technology, protocol verification faces numerous obstacles. The most prominent one is the difficulty in obtaining test oracles. The distributed architecture and multi-node collaboration characteristics of blockchain systems make the cost of defining the expected output of protocols extremely high. Taking the consensus mechanism as an example, in the proof of stake (PoS) or practical Byzantine fault tolerance (PBFT) algorithms, the communication between nodes, stake distribution, and fault handling logic are intertwined, forming a huge state space. If smart contracts are involved, their dynamic execution characteristics further exacerbate the complexity. Smart contracts can trigger different code paths according to external inputs, timestamps, etc. In decentralized finance (DeFi) applications, a lending contract may produce multiple execution results due to factors such as market interest rate fluctuations and changes in the value of collateral. It is almost an impossible task to exhaust all possible scenarios. This difficulty in obtaining test oracles makes it difficult for developers to build comprehensive and accurate test benchmarks, thus affecting the verification of the functional correctness of blockchain protocols.

[0023] In addition, the adaptability of blockchain protocols in dynamic environments is also not satisfactory. When network partitioning occurs, the communication links between nodes are segmented, and the consensus mechanism may not operate properly, posing a risk of data inconsistency; node failures will disrupt the execution process of the protocol, and without an effective fault tolerance mechanism, it may lead to system crashes; under high load conditions, network latency increases and transaction processing speed decreases, and the performance and security of the protocol will be tested. However, most existing protocol verification methods are based on idealized scenarios and are difficult to simulate the actual behavior of protocols under these abnormal conditions. For example, in traditional simulation tests, it is difficult to accurately reproduce the communication latency and message loss between nodes during network partitioning, making it difficult to detect hidden defects in the actual operation of the protocol in a timely manner and posing a potential hazard to the stable operation of the blockchain system.

[0024] To solve the above problems, the academic and industrial communities have turned their attention to formal verification methods such as model checking and theorem proving. Model checking verifies whether a protocol model satisfies specific properties by performing a state space search on the protocol model; theorem proving, based on mathematical logic, theoretically proves the correctness of the protocol. These methods have high rigor at the theoretical level but face many limitations in practical applications. On the one hand, they require users to have strong mathematical modeling capabilities. Not only do they need to understand the technical details of blockchain protocols, but they also need to transform them into accurate mathematical models, which places extremely high requirements on developers and researchers. On the other hand, as the scale of blockchain protocols continues to expand, their state space grows exponentially, and the computational complexity increases sharply. Taking a blockchain network with hundreds of nodes and complex smart contracts as an example, using the model checking method for verification may consume a large amount of computing resources and time, and may even be unable to complete the verification task due to resource exhaustion, making it difficult to popularize these methods in actual large-scale networks.

[0025] Based on the above situation, this application proposes a method and related device for verifying the reliability of blockchain protocols based on metamorphic testing. The following will make a detailed description of this application in combination with embodiments and drawings.

[0026] As Figure 1 shown, it is a schematic diagram of a method for verifying the reliability of a blockchain protocol based on metamorphic testing according to this application, which may include: S101, determine the components used for metamorphic testing in the blockchain protocol as the metamorphic testing objects.

[0027] Blockchain protocols encompass multiple core components, including consensus mechanisms, smart contracts, and decentralized networks. Each component plays a distinct role in the protocol's proper functioning. When determining transformation testing targets, prioritize high-risk and critical components. For example, consensus mechanisms are central to ensuring data consistency and security within blockchain systems, while smart contracts are crucial for implementing decentralized application logic. Vulnerabilities in these components can lead to serious security issues and system failures. Analyzing historical vulnerability reports and factoring in component complexity and update frequency can help identify components most likely to harbor potential issues. Frequently updated smart contracts or consensus mechanism modules operating in complex network environments can be prioritized for testing, thereby narrowing the scope of testing and improving verification efficiency.

[0028] S102 , formally defining the transformation relationships that each component in the transformation test object needs to satisfy based on the implementation mechanism, functional documentation, and existing vulnerability reports of the transformation test object.

[0029] The transformation relationship is a core concept in transformation testing. It describes the logical relationship that must be satisfied between the output results of a test case after undergoing a specific transformation. When defining a transformation relationship, one can first delve into the implementation mechanism of the test object. For example, for smart contracts, one needs to understand the code logic, data structure, and interaction with the external environment. For consensus mechanisms, one needs to understand the inter-node communication rules, voting process, and state transition logic. By integrating functional documentation with the component's expected functionality and behavior, a sound transformation relationship can be constructed based on this foundation. By referencing existing vulnerability reports, one can identify potential logical flaw patterns from historical issues and design targeted transformation relationships. For example, if historical reports indicate a smart contract vulnerability caused by data overflow, a transformation relationship can be defined that states: "After increasing the input value within a certain range, the output should not produce abnormal values or error messages." These relationships can be precisely expressed using formal languages such as mathematical symbols and logical expressions, providing clear verification criteria for subsequent testing.

[0030] S103: Generate an original test case, and generate a subsequent test case corresponding to the original test case according to the formally defined metamorphosis relationship.

[0031] The generation of original test cases can adopt various strategies, such as traditional test case design methods like equivalence class partitioning and boundary value analysis. Considering the characteristics of blockchain protocols, test cases covering normal operations, abnormal operations, and boundary conditions can be designed in combination with actual application scenarios. For example, when testing smart contracts, normal transfer transaction test cases, abnormal transfer test cases with an amount of zero or negative, and boundary test cases reaching the asset limit can be designed. After generating the original test cases, subsequent test cases are generated by modifying, combining, or adding specific conditions to the input parameters of the original test cases according to the defined metamorphic relations. For instance, if the metamorphic relation is that "when the input transaction amount is doubled, the output handling fee should increase accordingly", then subsequent test cases with the doubled amount are generated based on the original transaction amount test case to ensure that the test cases can cover the behavior of components in different situations and comprehensively verify the metamorphic relation.

[0032] S104, Execute the original test cases and subsequent test cases respectively, and obtain the original output results and subsequent output results correspondingly.

[0033] When executing the test cases, a test environment similar to the actual running environment of the blockchain protocol can be set up to ensure the authenticity and effectiveness of the test results. For the test of smart contracts, they can be deployed in a local blockchain test network to simulate the interaction between nodes; for the test of consensus mechanisms, a multi-node test cluster can be constructed to simulate complex scenarios such as network partitioning and node failures. According to the design steps of the test cases, the original test cases and subsequent test cases are executed in sequence, and the output results of each execution are accurately recorded. The output results may include various forms such as transaction status, return values, and log information. For different types of outputs, corresponding recording and storage methods can also be adopted for subsequent comparison and analysis.

[0034] S105, Conduct reliability verification on the original output results and subsequent output results. If they meet the expected expectations of the metamorphic relation, regenerate the original test cases and subsequent test cases; otherwise, obtain the corresponding potential vulnerability information.

[0035] Compare the original output result and the subsequent output result with the predefined metamorphic relationship to determine whether it meets the expected expectation. In practical applications, the output result can be parsed and logically judged through automated scripts or tools. For example, check whether the numerical value satisfies a specific calculation relationship, whether the status conforms to the expected conversion, etc. If the output result conforms to the metamorphic relationship, it indicates that the behavior of the blockchain protocol component is reliable under the current test scenario. However, to more comprehensively verify the reliability of the protocol, new original test cases and subsequent test cases can be regenerated to continue the test. If the output result does not conform to the metamorphic relationship, it indicates that there may be potential vulnerabilities. At this time, it is necessary to conduct a detailed analysis of the test process and output result, locate the problematic components and specific code logic, extract relevant information, and form a potential vulnerability report to provide a basis for subsequent protocol repair and optimization.

[0036] As a new software testing technology, metamorphic testing can detect system defects without explicitly expecting the output by defining the metamorphic relationship between input transformation and output. This method has shown potential in the testing of complex systems. Based on this idea, aiming at the problems of incomplete test coverage and insufficient dynamic adaptability in the verification of blockchain protocol reliability in the prior art, this application proposes a method for efficiently and systematically verifying blockchain protocols using metamorphic testing technology to improve the reliability and application credibility of blockchain protocols. By identifying key components related to protocol reliability, formal metamorphic relationships are designed for each component and an automated test framework is built to systematically verify the stability and credibility of blockchain protocols in a decentralized environment, thereby enhancing their consistency, security, availability, and robustness. It solves the problems of incomplete test coverage, insufficient adaptability to dynamic environments, and low automation in the verification of blockchain protocol reliability in the prior art.

[0037] As Figure 2 shown, it is a schematic diagram of a simplified blockchain protocol architecture for cryptocurrency custody. This protocol architecture includes: Network layer: It includes a P2P network, a verification mechanism, and a transmission mechanism, supporting data communication between nodes. The P2P network serves as the basis for decentralized communication. Nodes spread transaction and block data through the Gossip protocol or Kademlia DHT to ensure the consistency of the entire network ledger. For example, Bitcoin uses the Gossip protocol to broadcast transactions, and Ethereum optimizes the node discovery efficiency through Kademlia. Nodes verify transaction signatures, block hashes, and PoW difficulty targets, rejecting invalid or malicious data.

[0038] Base layer: Adopts the Proof of Work (PoW) consensus algorithm to ensure the consistency of the ledger. Verifiers compete for the right to record transactions by calculating the nonce value that meets the difficulty target, and the entire network of nodes updates the ledger after verification. For example, Bitcoin adjusts the difficulty value every 10 minutes to ensure the stability of block generation. Through the coordination of the consensus mechanism, data replication, and verification, the ledger consistency can still be maintained even if 50% of the nodes fail.

[0039] Execution layer: Includes the Ethereum Virtual Machine (EVM) and smart contracts, which are used to execute business logic related to custody. As a Turing-complete runtime environment, it supports smart contracts written in languages such as Solidity. The EVM executes code through sandbox isolation to prevent interference between contracts. It implements custody logic, such as locking funds to a specified address when depositing and verifying the user's signature and balance when withdrawing. Typical scenarios include collateral locking in DeFi lending.

[0040] Application layer: Provides a fund custody function to manage user deposit and withdrawal operations. The fund custody process is as follows: The user sends a transaction to the smart contract address, and the contract records the balance and triggers an event notification. The funds are frozen according to the contract terms (such as time locks, multi-signature conditions). For example, 100 ETH is locked and released after 30 days. When the user submits a withdrawal request, the contract verifies the permission and then executes the transfer.

[0041] The core function of the custody protocol is to implement the deposit, locking, and withdrawal operations of user funds through smart contracts, while ensuring the security and consistency of funds in a decentralized network. However, the protocol may face problems such as smart contract vulnerabilities (such as re-entrancy attacks) or network synchronization failures, which affect reliability.

[0042] The following takes Figure 2 the protocol in Figure 3 as an example, and through another embodiment of the blockchain protocol reliability verification method based on metamorphic testing in this application, this application will be described in more detail. As shown, it is another schematic flowchart of the blockchain protocol reliability verification method based on metamorphic testing in this application, which may include:

[0043] It should be noted that the consensus mechanism is the core of blockchain reliability and determines how nodes in the network reach an agreement on the validity of transactions and the blockchain state. The consensus mechanism directly affects the consistency and security of the protocol. Consistency is manifested as the unified understanding of all nodes on the ledger state, and security is manifested as the ability to resist malicious nodes (such as attacks exceeding the fault tolerance threshold). A smart contract is a programmable component used in the blockchain protocol to automatically execute the terms of the protocol. It defines the business logic in the form of code and runs distributedly in the blockchain network. Smart contracts affect the consistency and security of the protocol. Consistency requires that the contract produce predictable execution results under different inputs, and the security requirement is to prevent logical vulnerabilities (such as re-entrancy attacks). A decentralized network is a communication architecture that runs through distributed nodes and uses peer-to-peer (P2P) technology to achieve data synchronization and protocol execution, avoiding the impact of single-point failures on the system. A decentralized network affects the availability and robustness of the protocol. Availability is manifested as the continuous response ability of the system to user requests, and robustness is manifested as the stability under abnormal conditions (such as node failures and network delays).

[0044] Specifically, since the execution result of a smart contract depends on input parameters and states, and complex logic may hide vulnerabilities (such as re-entrancy attacks), it is suitable to verify the state consistency by changing the amount or call order; since the output of the consensus mechanism is affected by dynamic factors such as the number of nodes and the computing power distribution, and directly determines the consistency and security, it is suitable to verify the ledger consistency by changing the input (such as adding nodes); since the synchronization result of a decentralized network is affected by dynamic factors such as delays and node failures, and determines the availability and robustness, it is suitable to verify the synchronization reliability by simulating failures. The dynamic characteristics of these components make them ideal objects for metamorphic testing.

[0045] Other components, such as encryption technologies (used for signatures and hashes) or immutability (guaranteed by the chain structure), since their outputs are deterministic and static, can be verified by traditional testing methods and are therefore not suitable for metamorphic testing. By focusing on smart contracts, consensus mechanisms, and decentralized networks, the present invention ensures that the testing can comprehensively cover the reliability requirements of the blockchain protocol, providing a clear direction and basis for subsequent metamorphic testing.

[0046] S202, according to the implementation mechanism of the metamorphic testing object, its code, and existing vulnerability reports, design and formally define the metamorphic relationship that the metamorphic testing object should satisfy.

[0047] First, the meanings of the following parameters are explained: : represents the set of nodes in the network 。

[0048] : represents the transactions on the blockchain Among them, represents the account interacting with the target contract, represents the gas limit of the transaction, represents the execution status of the transaction, represents the change in the account balance before and after the transaction, represents the gas cost of the transaction.

[0049] : represents a continuous set of transactions, .

[0050] : represents the input, , where represents additional parameters (such as network latency).

[0051] : represents the output, that is, the transaction execution result or the blockchain state, , where represents the contract execution function.

[0052] : The metamorphic relationship, formalized as where represents the original input and output, represents the subsequent input and output. The goal of the metamorphic relationship is to describe the expected relationship to be satisfied.

[0053] The subscript of all parameters s represents the corresponding original test case, and the subscript f represents the corresponding subsequent test case.

[0054] (1) Design of the metamorphic relationship of the consensus mechanism.

[0055] This escrow protocol adopts the PoW consensus mechanism, and nodes compete through computing power to confirm escrow transactions and generate blocks. Its function is to ensure ledger consistency (all nodes agree on the transaction order) and security (resisting malicious attacks). Therefore, the reliability requirements include: consistency (the ledger state is not affected by the change in the number of nodes) and security (malicious nodes with less than 51% computing power threshold do not affect the result). Accordingly, the corresponding metamorphic relationships and are selected, and their formal descriptions are as follows: : The increase in the number of honest nodes does not affect the consistency of the ledger. In the original input, honest nodes confirm the transaction set , and subsequently more honest nodes are added, and the consensus result should remain the same.

[0056] Input:

[0057] Output:

[0058] Metamorphic relationship:

[0059] : If a small number of malicious nodes are introduced (below the 51% computing power threshold), the consensus results should remain consistent. In the original input, honest nodes confirm the transaction set , and then malicious nodes are added (below the fault tolerance threshold, such as 1 / 3 of the total number of nodes in Practical Byzantine Fault Tolerance PBFT), and the consensus results should remain consistent.

[0060] Input:

[0061] Output:

[0062] Metamorphic relationship:

[0063] (2) The metamorphic relationship of the reliability of smart contracts.

[0064] As Figure 4 shown, it is the contract code of the aforementioned escrow contract. It is responsible for the deposit and withdrawal operations of the escrow funds. Combining the existing re-entrancy attack events, the metamorphic relationship for its verification should be able to verify whether there is a re-entrancy vulnerability in it.

[0065] The core of the re-entrancy vulnerability lies in that when the contract calls an external contract, the state update (such as clearing the balance) occurs after the external call. When the contract sends Ether to an external address through the call function, if the recipient is a malicious contract, it can immediately call the function of the original contract again through its fallback or receive function when it receives the Ether. Since the original contract has not updated the state (for example, setting the balance to zero), the attacker can repeatedly take advantage of this opportunity to execute key operations (such as withdrawals) multiple times until the funds in the contract are exhausted. If there is a re-entrancy vulnerability in the contract of the escrow protocol, then when calling the withdraw method through the external account and the Attack contract account respectively, the contract account balances after the call should be different. Based on this, is selected as the metamorphic relationship to test the reliability of this contract.

[0066] The formal definition of : In the original transaction, an external account is used for contract calls; subsequent transactions are called by a contract account with a hook function containing recursive calls; the results of the two transactions should be the same.

[0067] Input:

[0068] Output:

[0069] Metamorphic relationship: That is, the execution status of the transaction and the change in account balance should be the same.

[0070] In other embodiments of the present application, (3) the reliability metamorphic relationship of the smart contract may further include and : : In the original contract call transaction, allocate the amount of gas required for the transaction ( the amount of gas required for the transaction) to complete the transaction, and subsequently increase the gas allocation. The transaction execution results should remain the same. The formal definition is as follows:

[0071] Output:

[0072] Metamorphic relationship: That is, the gas consumption and the change in account balance of the two transactions should be the same.

[0073] : In the original input, the input transfer amount results in a change in the account balance , and in subsequent transactions, the input transfer amount , and the change in the account balance should be . The formal definition is as follows: Contract state: Represents the balance of each account.

[0074] Input: Indicates that account A transfers M tokens to account B.

[0075] Output:

[0076] Metamorphic relationship: That is, the change in the balance of account A is the same as the transfer amount.

[0077] (3) Decentralized network reliability metamorphic relationship.

[0078] The decentralized network of this custody agreement adopts a P2P network, which is responsible for transaction broadcasting and ledger synchronization. Its function is to ensure that all nodes can also synchronize custody transaction data in a fluctuating network environment, and accordingly select As a metamorphic relationship for testing the decentralized network, its formal definition is as follows: : In the original input, the blockchain network contains nodes synchronizing , and as the subsequent network latency increases, the two synchronization results should be consistent.

[0079] Input:

[0080] is the latency increment.

[0081] Output:

[0082] Metamorphic relationship: , that is, network latency does not affect the communication results of nodes.

[0083] S203. Build an automated test framework. According to the metamorphic relationship defined formally, generate the original test cases and the corresponding subsequent test cases, and execute the original test cases and the subsequent test cases respectively to obtain the corresponding output results.

[0084] Build an automated test framework to simulate respectively Figure 2 the four-layer architecture of the cryptocurrency custody blockchain protocol shown, including the network layer (Layer 0), the basic layer (Layer 1), the execution layer (Layer 2), and the application layer (Layer 3), so as to comprehensively verify the reliability of the consensus mechanism, smart contracts, and the decentralized network. For the network layer, use the NS-3 simulator to build a P2P network to simulate the communication, latency, and faults between nodes, and support transaction broadcasting and data synchronization; the basic layer implements the proof-of-work (PoW) consensus algorithm through a custom blockchain simulator to simulate block generation and ledger consistency; the execution layer uses Ganache to create an Ethereum test network for compiling, deploying, and running Solidity smart contracts (Victim and Attacker contracts) to simulate the business logic of fund custody; the application layer realizes user deposit and withdrawal operations through the interaction between the Web3 library and the smart contract. In addition, the framework combines Python scripts to implement automated functions, including test case generation, execution, and result verification.

[0085] The process of generating test cases is based on the metamorphic testing method, and the original input and subsequent inputs are designed for the consensus mechanism, smart contracts, and decentralized networks. For the metamorphic testing of the consensus mechanism, the original input is set as 20 honest nodes to confirm a transaction set under the default network latency (50 ms). (User A and B each deposit 5 ETH), and the subsequent inputs are gradually increased by the number of honest nodes (verifying ) and by the number of (with computing power accounting for no more than 51%) malicious nodes (verifying ) to confirm the transaction set . For the metamorphic testing of smart contracts, the original input is that User A calls the withdraw method of the Victim contract to withdraw 2 ETH, and the subsequent input is that the Attacker contract containing a malicious hook function calls the withdraw method of the Victim contract to withdraw 2 ETH (verifying ). For the metamorphic testing of decentralized networks, the original input is that 30 nodes synchronize a transaction (A deposits 5 ETH) under a 50 ms latency, and the subsequent input is to gradually increase the latency to 150 ms (verifying ). These test cases are automatically generated by a Python script, which constructs transaction sequences, adjusts parameters (such as the number of nodes, transaction parameters, latency), and saves the input data to ensure the comprehensiveness and repeatability of the tests.

[0086] S204, Evaluate the output results of the metamorphic testing to determine whether the outputs corresponding to the inputs belonging to the same metamorphic relationship meet the expected expectations. If the output does not match the expectation, record and output the corresponding potential vulnerability information to help identify possible defects or risks in the protocol; if the output meets the expectation, continue to repeat the test case generation step in S203, and further verify the reliability of the protocol through more test cases.

[0087] This process continues until unreliable behavior in the protocol is found or it is confirmed that it meets the reliability requirements. Ultimately, a comprehensive inspection of the reliability of the blockchain protocol is achieved, providing a scientific basis for the optimization and improvement of the protocol.

[0088] Specifically, for the reliability verification of the consensus mechanism of the blockchain protocol, the following methods can be adopted: For protocols based on proof of work (PoW), the metamorphic relationship of the consensus mechanism considers the change in the computing power distribution. For protocols based on proof of stake (PoS), the metamorphic relationship of the consensus mechanism considers the change in the number of staked tokens. For protocols based on Byzantine fault tolerance (BFT), the metamorphic relationship of the consensus mechanism considers the change in the proportion of malicious nodes being lower than the fault tolerance threshold (1 / 3 of the total number of nodes).

[0089] It should be noted that the method described in this application not only verifies the reliability of individual components of the protocol, but also includes verifying the combined reliability of key components. The specific steps are as follows: (1) Construct comprehensive test cases , , which simultaneously include transformation parameters of the consensus mechanism, smart contract, and decentralized network (such as malicious nodes, amount changes, network latency).

[0090] (2) Define combined metamorphic relations, such as , to verify the consistency when multiple components work together.

[0091] (3) Execute in the test framework and analyze the output to check whether it satisfies the described relationship.

[0092] This application can be used to efficiently discover hidden logical errors in protocol implementation, ensure the reliable operation of protocol implementation under various boundary conditions, and meet the four key indicators of consistency, availability, security, and robustness. First, extract key reliability components based on the blockchain protocol specification to determine the input domain; determine the necessary attributes according to documents, business logic, etc. to design metamorphic relations; generate original test cases and subsequent test cases according to the designed metamorphic relations; execute the two types of test cases respectively to obtain execution results; expose potential vulnerabilities (such as logical vulnerabilities, specification deviations, fault tolerance defects, etc.) by checking whether the outputs corresponding to the protocol under two inputs satisfy the metamorphic relations, and verify the reliability of the blockchain protocol.

[0093] This application utilizes metamorphic testing technology. Through the design of metamorphic relationships between input transformations and expected output relationships (such as the ledger state remaining consistent after adding malicious nodes, or the synchronization result remaining unchanged after a delayed addition), it can verify the behavior of blockchain protocols under dynamic conditions (such as node failures and network partitions) without the need to predefine specific outputs. Compared with the limitations of static testing or simulation methods in the prior art, this application enhances the adaptability to decentralized environments, effectively identifies reliability issues of protocols in abnormal scenarios, and provides guarantees for improving the robustness and security of the system. Furthermore, by clearly defining the key components related to the reliability of blockchain protocols (consensus mechanism, smart contract, decentralized network) and designing formal metamorphic relationships for each component, this application achieves comprehensive verification in multiple dimensions such as consistency, security, availability, and robustness. Compared with the testing methods in the prior art that only focus on a single component (such as encryption algorithms), this application can detect hidden defects in the interaction between components, such as the fork risk of the consensus mechanism under network latency or the logical errors of smart contracts under abnormal inputs, thus significantly improving the comprehensiveness of test coverage. Moreover, this application constructs an automated testing framework, which realizes the full-process automation from input construction to result analysis by automatically generating pairs of original and subsequent test cases in metamorphic testing, executing protocol instances, and verifying metamorphic relationships. Compared with the methods in the prior art that rely on manual scenario design or complex modeling, this application significantly improves the testing efficiency and supports the rapid verification of large-scale blockchain networks.

[0094] As Figure 5 shown, it is a schematic diagram of a blockchain protocol reliability verification system based on metamorphic testing according to this application, which may include: An object determination module, configured to determine the components in the blockchain protocol for metamorphic testing as metamorphic testing objects; A definition module, configured to formally define the metamorphic relationships that each component in the metamorphic testing object needs to satisfy according to the implementation mechanism, function documentation, and existing vulnerability reports of the metamorphic testing object; A test case module, configured to generate original test cases and generate subsequent test cases corresponding to the original test cases according to the formally defined metamorphic relationships; An execution module, configured to execute the original test cases and the subsequent test cases respectively, and obtain the original output results and the subsequent output results correspondingly; A verification module, configured to perform reliability verification on the original output results and the subsequent output results. If they meet the expected expectations of the metamorphic relationships, regenerate the original test cases and the subsequent test cases; otherwise, obtain the corresponding potential vulnerability information.

[0095] It should be noted that in several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of each module is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules can be combined or integrated into another device, or some features can be ignored or not executed. The modules described as separate components may or may not be physically separated. The components shown as modules can be one physical unit or multiple physical units, that is, they can be located in one place or distributed to multiple different places. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0096] In addition, in each embodiment of the present invention, each module can be integrated in a processing unit, or each module can exist physically alone, or two or more modules can be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0097] The embodiments of this application also provide an electronic device, which may include one or more processors, a memory, and a communication interface.

[0098] Among them, the memory and the communication interface are coupled to the processor. For example, the memory and the communication interface can be coupled together through a bus.

[0099] Among them, the communication interface is used for data transmission with other devices. The memory stores computer program code. The computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device executes the steps of the above-mentioned method for verifying the reliability of the blockchain protocol based on metamorphic testing.

[0100] Among them, the processor can be a processor or a controller. For example, it can be a Central Processing Unit (CPU), a general-purpose processor, a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The processor can be used to support the electronic device in executing the method steps provided in the above embodiments.

[0101] Among them, the bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The above buses can be divided into an address bus, a data bus, a control bus, etc.

[0102] A computer-readable storage medium provided by an embodiment of the present application stores a computer program, and when the computer program is executed by a processor, it implements the steps of the above-mentioned method for verifying the reliability of a blockchain protocol based on metamorphic testing.

[0103] The computer-readable storage medium involved in the present application includes a Random Access Memory (RAM), a memory, a Read-Only Memory (ROM), an Electrically Programmable ROM, an Electrically Erasable Programmable ROM, a register, a hard disk, a removable disk, a CD ROM, or any other form of storage medium well-known in the technical field.

[0104] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for verifying the reliability of a blockchain protocol based on metamorphic testing, characterized in that, Including: Determine the components in the blockchain protocol for metamorphic testing as the metamorphic testing objects; Formalize the metamorphic relationships that each component in the metamorphic testing object needs to satisfy according to the implementation mechanism, function documentation, and existing vulnerability reports of the metamorphic testing object; Generate original test cases and, according to the formally defined metamorphic relationships, generate subsequent test cases corresponding to the original test cases; Execute the original test cases and subsequent test cases respectively to obtain the original output results and subsequent output results correspondingly; Verify the reliability of the original output results and subsequent output results. If they meet the expected expectations of the metamorphic relationships, regenerate the original test cases and subsequent test cases. Otherwise, obtain the corresponding potential vulnerability information.

2. The method for verifying the reliability of a blockchain protocol based on metamorphic testing according to claim 1, wherein The metamorphic testing objects include at least one of smart contracts, consensus mechanisms, and decentralized networks.

3. The reliability verification method of the blockchain protocol based on metamorphic testing according to claim 2, wherein The method for formally defining the metamorphic relationships that each component in the metamorphic testing object needs to satisfy includes: For the consensus mechanism, the metamorphic relationships that need to be satisfied include: on the basis of the original input, after adding honest nodes subsequently, the consensus results are the same; and, on the basis of the original input, after adding malicious nodes subsequently, the consensus results are the same; For smart contracts, the metamorphic relationships that need to be satisfied include: in the original transaction, if the allocated gas can complete the transaction, increasing the gas allocation in the subsequent transaction does not affect the transaction execution result; and, in the original transaction, using an external account to call the contract, and in the subsequent transaction, calling by a contract account containing a recursive call hook function, the results of the two transactions are the same; and, in the original transaction, the transferred amount input causes a change in the account balance. In the subsequent transaction, the change amount of the account balance should always correspond to the change amount of the transferred amount; For the decentralized network, the metamorphic relationships that need to be satisfied include: in the original input, nodes in the blockchain network synchronize consecutive transactions. When the subsequent network latency increases, the transaction execution results are the same.

4. The method for verifying the reliability of a blockchain protocol based on metamorphic testing according to claim 1, wherein The metamorphic testing objects include smart contracts, consensus mechanisms, and decentralized networks; The method for reliability verification further includes: Construct original comprehensive test cases and subsequent comprehensive test cases including transformation parameters of smart contracts, consensus mechanisms, and decentralized networks; Define combined metamorphic relationships; Execute the original comprehensive test cases and subsequent comprehensive test cases respectively, and determine whether the obtained outputs satisfy the combined metamorphic relationships.

5. The reliability verification method of the blockchain protocol based on metamorphic testing according to claim 4, characterized in that The transformation parameters include malicious nodes, amount changes, and network latency.

6. A reliability verification system for blockchain protocols based on metamorphic testing, characterized in that, Including: An object determination module for determining the components in the blockchain protocol for metamorphic testing as the metamorphic testing objects; A definition module for formally defining the metamorphic relationships that each component in the metamorphic testing object needs to satisfy according to the implementation mechanism, function documentation, and existing vulnerability reports of the metamorphic testing object; A use case module for generating original test cases and, according to the formally defined metamorphic relationships, generating subsequent test cases corresponding to the original test cases; An execution module for executing the original test cases and subsequent test cases respectively to obtain the original output results and subsequent output results correspondingly; A verification module is used to verify the reliability of the original output result and the subsequent output result. If it meets the expected expectations of the metamorphic relationship, the original test case and the subsequent test case are regenerated. Otherwise, the corresponding potential vulnerability information is obtained.

7. The reliability verification system for blockchain protocols based on metamorphic testing according to claim 6, characterized in that, The metamorphic test object includes at least one of a smart contract, a consensus mechanism, and a decentralized network; The method for formally defining the metamorphic relationships that each component in the metamorphic test object needs to satisfy includes: For the consensus mechanism, the metamorphic relationships that need to be satisfied include: on the basis of the original input, after adding honest nodes subsequently, the consensus results are the same; and, on the basis of the original input, after adding malicious nodes subsequently, the consensus results are the same; For the smart contract, the metamorphic relationships that need to be satisfied include: in the original transaction, if the allocated gas can complete the transaction, increasing the gas allocation in the subsequent transaction does not affect the transaction execution result; and, in the original transaction, an external account is used to call the contract, and in the subsequent transaction, the contract account with a hook function containing a recursive call is used for the call, and the results of the two transactions are the same; and, in the original transaction, the transferred amount input causes a change in the account balance, and in the subsequent transaction, the change amount of the account balance should always correspond to the change amount of the transferred amount; For the decentralized network, the metamorphic relationships that need to be satisfied include: in the original input, the nodes in the blockchain network synchronize consecutive transactions, and when the subsequent network latency increases, the transaction execution results are the same.

8. The reliability verification system for blockchain protocols based on metamorphic testing according to claim 6, wherein, The metamorphic test object includes a smart contract, a consensus mechanism, and a decentralized network; The method for reliability verification further includes: Constructing an original comprehensive test case and a subsequent comprehensive test case including the transformation parameters of the smart contract, the consensus mechanism, and the decentralized network; Defining a combined metamorphic relationship; Executing the original comprehensive test case and the subsequent comprehensive test case respectively, and determining whether the obtained output meets the combined metamorphic relationship.

9. An electronic device, characterized in that, Including: A memory and one or more processors; the memory is coupled to the processor; wherein, computer program code is stored in the memory, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device executes the steps of the method for verifying the reliability of the blockchain protocol based on metamorphic testing as described in any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method for verifying the reliability of the blockchain protocol based on metamorphic testing as described in any one of claims 1-5 are implemented.

Images