Block chain cross-version compatibility verification method and device, equipment and medium

Abstract

The invention relates to a block chain cross-version compatibility verification method and device, equipment and a medium. Comprising the steps that a to-be-verified block chain is built, and the to-be-verified block chain comprises a plurality of nodes of different versions; the versions comprise published versions and versions to be tested; determining a data template and a generation rule corresponding to the node according to the version corresponding to the node, generating test data based on the data template and the generation rule, and sending the test data to the node, so that each node executes a corresponding data activity based on the test data; data to be verified on the corresponding nodes are collected based on the collection module, the data to be verified are sent to the central verification server for consistency detection, when the data to be verified pass the consistency detection, it is determined that the corresponding published version and the version to be tested are compatible, and the data to be verified are generated based on data activities. By adopting the method, the efficiency of verifying the compatibility of the cross-version block chain nodes can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a method, apparatus, device, and medium for verifying the compatibility of blockchain across versions. Background Art

[0002] In practical applications, blockchain system upgrades are inevitable, and accordingly, a transition period in which old and new versions coexist is unavoidable. For example, when upgrading an enterprise's internal blockchain application from an old version to a new one, it takes a period of time for old and new version nodes to coexist within the cluster to ensure business continuity. Furthermore, as blockchain application scenarios expand, different organizations or projects may adopt different blockchain versions to build their own systems. Therefore, there is a need to integrate these heterogeneous blockchain networks into a single cluster.

[0003] In the existing technology, the data compatibility testing methods for different versions are mainly carried out in the following ways: based on manual comparison, that is, exporting key data from blockchain nodes of different versions, manually comparing the differences in data structures of different versions, checking the fields added, modified or deleted in the new version, and verifying the data values ​​of different versions under the same business scenario; or using a block browser to display blockchain data of nodes of different versions side by side, such as block height, transaction list, account balance and other information, and preliminarily judge the data compatibility between different versions by observing the consistency of data display. However, the above existing methods all have the problem of difficulty in comprehensively and efficiently evaluating the data compatibility of different versions.

[0004] Currently, no effective solution has been proposed to the problem that it is difficult to comprehensively and efficiently evaluate the compatibility of different versions of blockchain nodes in existing technologies. Summary of the Invention

[0005] Based on this, it is necessary to provide a blockchain cross-version compatibility verification method, device, equipment and medium to address the above technical issues.

[0006] First, this application provides a blockchain cross-version compatibility verification method, including:

[0007] Building a blockchain to be verified, where the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0008] Determine the data template and generation rules corresponding to the node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes specific fields corresponding to the node version, and the generation rules include version enhancement rules corresponding to the node version; the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0009] Based on the preset collection module on the node, the data to be verified on the corresponding node is collected at preset time intervals, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding released version and the version to be tested is determined, wherein the data to be verified is generated based on data activity.

[0010] In one embodiment, the above method also includes: when it is detected that there is a consistency problem in the data to be verified corresponding to each node, a corresponding test report is generated based on the target node with differences in the nodes to be verified, wherein the test report includes the severity level of the consistency problem, the cause of the consistency problem and the solution to the consistency problem.

[0011] In one embodiment, obtaining a data template includes:

[0012] Parse the node version and create a transaction data template and smart contract data template for the node based on the version feature analysis results. The transaction data template includes specific fields corresponding to the node version, and the smart contract data template includes parameter fields for the smart contract method corresponding to the node version.

[0013] Based on the transaction data template and the smart contract data template, a data template is obtained.

[0014] In one embodiment, obtaining the generation rule includes:

[0015] Based on the data template and the preset actual business needs, corresponding transaction data generation rules and smart contract call rules are formulated for the corresponding nodes. The transaction data generation rules include basic transaction rules and transaction data version enhancement rules corresponding to the node version. The smart contract call rules include basic smart contract rules and smart contract version enhancement rules corresponding to the node version.

[0016] Based on the smart contract calling rules and transaction data generation rules, the generation rules are obtained.

[0017] In one embodiment, generating test data corresponding to each node to be verified based on a data template and a generation rule includes:

[0018] The initial test data generated based on the data template and the generation rule is filled with data to generate test data corresponding to at least one node.

[0019] In one embodiment, when the central verification server performs consistency testing on each node, determining whether the corresponding released version and the version to be tested are compatible includes:

[0020] The central verification server calculates the hash value of the data to be verified corresponding to each node and obtains the account information corresponding to each node. When it is detected that the hash values ​​of the same type of data in the data to be verified are exactly the same, and when it is detected that the account information corresponding to each node is consistent, it is determined that the version of the corresponding node has passed the consistency test and the version to be tested corresponding to the node is compatible with the released version.

[0021] In one embodiment, the released version includes at least one released sub-version, and the version to be tested includes at least one sub-version to be tested.

[0022] In a second aspect, the present application also provides a compatibility verification device. The device includes:

[0023] Obtain a module for building a blockchain to be verified, where the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0024] A calculation module is configured to determine a data template and generation rules corresponding to each node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes specific fields corresponding to the node version, and the generation rules include version enhancement rules corresponding to the node version; and the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0025] A generation module is used to collect the data to be verified on the corresponding node at a preset time interval based on the preset collection module on the node, and send the data to be verified to the central verification server for consistency detection. When the data to be verified passes the consistency detection, it is determined that the corresponding published version and the version to be tested are compatible, wherein the data to be verified is generated based on data activity.

[0026] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are performed:

[0027] Building a blockchain to be verified, where the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0028] Determine the data template and generation rules corresponding to the node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes specific fields corresponding to the node version, and the generation rules include version enhancement rules corresponding to the node version; the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0029] Based on the preset collection module on the node, the data to be verified on the corresponding node is collected at preset time intervals, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding released version and the version to be tested is determined, wherein the data to be verified is generated based on data activity.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the following steps:

[0031] Building a blockchain to be verified, where the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0032] Determine the data template and generation rules corresponding to the node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes specific fields corresponding to the node version, and the generation rules include version enhancement rules corresponding to the node version; the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0033] Based on the preset collection module on the node, the data to be verified on the corresponding node is collected at preset time intervals, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding released version and the version to be tested is determined, wherein the data to be verified is generated based on data activity.

[0034] The above-mentioned blockchain cross-version compatibility verification method, device, equipment and medium first builds a blockchain to be verified, and the blockchain to be verified includes multiple versions of nodes, including a released version and a version to be tested; then, according to the version corresponding to the node, the data template and generation rule corresponding to the node are determined, and test data corresponding to each node is generated based on the data template and generation rule, and the test data is sent to the node so that each node performs a corresponding data activity based on the data to be tested; finally, based on the collection module on the node, the data to be verified on the corresponding node is collected at a preset time interval, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection of the central verification server, it is determined that the released version is compatible with the version to be tested, wherein the data to be verified is generated based on the above-mentioned data activity. Through this application, various types of data under different blockchain versions can be comprehensively and accurately simulated based on the above-mentioned data templates and generation rules, effectively covering various data change scenarios caused by version differences, thereby improving the efficiency of compatibility verification, reducing the risks brought by version upgrades or data interactions, and ensuring the stable operation of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 1 is a flow chart of a compatibility verification method according to an embodiment;

[0036] Figure 2 A schematic diagram of a process for generating multi-version test data in one embodiment;

[0037] Figure 3 1. A flow chart of a compatibility verification method in a preferred embodiment;

[0038] Figure 4 is a structural block diagram of a compatibility verification device in one embodiment;

[0039] Figure 5 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0041] In one embodiment, Figure 1 As shown, a cross-version compatibility verification method for blockchain is provided, including the following steps:

[0042] Step S110: Building a blockchain to be verified, wherein the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested.

[0043] Specifically, in a testing environment, a blockchain to be verified is constructed, i.e., nodes with different blockchain versions are constructed. The blockchain to be verified includes nodes with at least two different versions. In some preferred embodiments, each node can default to a full node, and the versions include a released version and a to-be-tested version. The released version is the mainstream version that has been released, which can be understood as an older version that has been released, while the to-be-tested version is the unreleased test version, which can be understood as a newer version that has not yet been officially released. Because upgrading from an old version to a new version requires a period of time for the old and new version nodes to coexist in the cluster to ensure business continuity, this application is to verify the compatibility between the to-be-tested version (i.e., the new version) and the released version (i.e., the old version). In actual applications, the nodes deploying the released and to-be-tested versions of the blockchain play equivalent roles, being consensus nodes on the chain and connected together in a fully connected manner. Independent server resources can be configured for each node, and stable network connections between nodes are ensured.

[0044] Step S120: Determine the data template and generation rules corresponding to the node according to the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs corresponding data activities based on the test data; wherein, the data template includes specific fields corresponding to the version of the node, and the generation rules include version enhancement rules corresponding to the version of the node; the test data is test data for the nodes corresponding to the version to be tested and the nodes corresponding to the released version.

[0045] Specifically, detailed information about the blockchain version corresponding to each node to be verified is obtained, including the version number, update documentation, and corresponding source code. In actual applications, professional code analysis tools (such as Git, Mythril, etc.) can be used to deeply analyze different versions of source code to identify changes in data structures. For example, if a new "block generation timestamp accuracy" field is added to the block header data structure of the tested version, or the length of the "previous block hash value" field is modified, at the same time, adjustments to transaction rules are sorted out, such as the calculation method of transaction fees from a fixed rate to a proportional calculation based on the transaction amount, as well as changes to the node weight calculation method in the consensus algorithm. In summary, feature analysis of node versions is an existing technology in this field and is not subject to excessive restrictions here. Parsing the blockchain version corresponding to each node can facilitate the subsequent establishment of data templates and generation rules.

[0046] Furthermore, based on the above analysis results of the blockchain version of the node, a data template corresponding to the node can be constructed, and then the generation rules of the corresponding node can be established according to the data template. Finally, test data corresponding to each node can be established according to the data template and the generation rules. Specifically, the data template includes multiple sub-data templates, mainly including transaction data templates and smart contract data templates. For transaction data templates, in addition to the conventional basic fields such as sender address, receiver address, transaction amount, and transaction timestamp, specific fields will be added based on version characteristics. For example, if a privacy protection mechanism is introduced in a certain version, encryption-related fields will be added to the transaction data template accordingly. In actual applications, the transaction data template may contain a version_specific field of type object, which is a version-specific field that only exists in the current version and is the specific field corresponding to the current version of the corresponding node. For the above-mentioned smart contract data template, the template will clearly specify the contract interface definition, the type and initial value of the state variable, the parameter format and return value type of the function call, etc. For example, in a new version of the smart contract, a new function is added to query specific historical transaction records. The smart contract data template will detail the function's input parameters (such as the transaction time range, transaction type filter conditions, etc.) and return value structure (such as a list of eligible transactions and related detailed information). In actual applications, the above-mentioned smart contract data template may include a functions field of type object, which is the method parameter type and contains version-specific fields.

[0047] Furthermore, after generating the above data template, comprehensive data generation rules can be formulated based on the data template and actual business scenario requirements. The generation rules also include multiple rules, mainly including transaction data generation rules and smart contract call rules. Among them, for the transaction data generation rules, the transaction amount is limited to a reasonable value range, such as being greater than zero and not exceeding the sender's account balance, the transaction timestamp should be within the time range allowed by the current blockchain network, and meet the version's requirements for time accuracy, etc.; for the smart contract call rules, the rules will strictly limit the type and value range of the call parameters, as well as the order and preconditions of the calls. For example, when calling a smart contract function with permission verification, the generation rules will ensure that the call parameters contain valid permission credentials and that the call order complies with the contract design logic. Furthermore, the above-mentioned generation rules generally include basic rules and version enhancement rules, and adopt a hierarchical constraint mechanism. Specifically, the above-mentioned transaction data generation rules include version enhancement rules. For example, when it is detected that the current version has added a new privacy encryption field, it is necessary to set the encryption field to be randomly generated (preferably, a 50% probability of enabling can be set), and / or, the encryption algorithm is set to use AES-256-GCM, etc.; similarly, the above-mentioned smart contract calling rules also include corresponding version enhancement rules. For example, when it is detected that the current version introduces permission management, it is necessary to generate a valid permission certificate (the UUID can be randomly set), and / or, the calling sequence must include the permission granting step, etc.

[0048] It should be noted that the method provided in this embodiment can generate representative test data in batches based on data templates and generation rules. In order to better realize the compatibility detection of nodes corresponding to the version to be tested, the generated test data should include test data for nodes corresponding to the version to be tested and nodes corresponding to the released version.

[0049] After the test data is generated in batches, the test data is sent to the node. This embodiment does not impose too many restrictions on the specific sending method. The test data can be sent to any node, or to the corresponding node, etc., so that each node executes and generates corresponding data activities based on the test data.

[0050] Step S130, based on the preset collection module on the node, collects the data to be verified on the corresponding node at a preset time interval, and sends the data to be verified to the central verification server for consistency detection. When the data to be verified passes the consistency detection, it is determined that the corresponding published version and the version to be tested are compatible, wherein the data to be verified is generated based on data activity.

[0051] Specifically, a data collection module is deployed on blockchain nodes of different versions. This module can monitor various data activities in the blockchain network in real time, including but not limited to the generation of new transactions, the generation and propagation of blocks, changes in the status of smart contracts, etc. In some preferred embodiments, the data collection module can be a lightweight collection module.

[0052] Through the above-mentioned collection module, the data to be verified on the corresponding node is collected at preset time intervals (such as every 5 minutes), and the latest collected data is packaged and synchronously transmitted to the central verification server, such as all transaction data generated during the time period, newly generated block data, and smart contract status change data, etc., are sent to the above-mentioned central verification server.

[0053] After receiving data from nodes with different versions, the central verification server performs consistency checks on the data to be verified corresponding to each node. This consistency check includes, but is not limited to, using a hash algorithm to calculate whether the same type of data is consistent across different versions. If the data to be verified passes the consistency check, the server determines that the published version and the version to be tested are compatible. Specifically, the data to be verified is generated by the node based on corresponding data activity.

[0054] Through steps S110 to S130, the present application accurately simulates data under different versions and performs consistency testing on the data to be verified generated by data activities, thereby comprehensively and efficiently completing the compatibility test of data between different versions, effectively improving the reliability and stability of the blockchain system.

[0055] In some embodiments, the method further comprises:

[0056] When consistency issues are detected in the data to be verified corresponding to each node, a corresponding test report is generated based on the target node with differences among the nodes to be verified, wherein the test report includes the severity level of the consistency problem, the cause of the consistency problem and the solution to the consistency problem.

[0057] Specifically, if the data to be verified fails the consistency check on the central verification server—that is, if a consistency issue is detected in the data to be verified—the verification software on the central verification server automatically initiates an exception handling process. First, a detailed record is kept of the time the issue occurred, the blockchain version involved, the data type, and the specific discrepancies, which indicate the degree of discrepancy between the different versions of the data to be verified. Then, through data analysis and traceability techniques, attempts are made to locate the root cause of the issue, such as a code vulnerability encountered during the version upgrade, a data migration error, or a network transmission failure.

[0058] Finally, a test report is generated based on the consistency issues detected between the data under test. This report includes a summary of all data consistency issues, a severity rating (e.g., severely impacting transaction execution, slightly impacting data display), an analysis of the possible causes of the issues, and recommended solutions for each issue. For example, if a consistency issue is found in a certain version of transaction data due to a field format conversion error during transmission, the report will detail the issue and recommend fixing the format conversion code used during data transmission.

[0059] Through this embodiment, the current consistency problems can be fully reflected based on the test report, which is convenient for users or relevant technical personnel to solve corresponding problems in a targeted manner.

[0060] In some embodiments, obtaining a data template includes:

[0061] Parse the node version and create a transaction data template and smart contract data template for the node based on the version feature analysis results. The transaction data template includes specific fields corresponding to the node version, and the smart contract data template includes parameter fields for the smart contract method corresponding to the node version.

[0062] Based on the transaction data template and the smart contract data template, a data template is obtained.

[0063] Specifically, after the system is started, it automatically obtains detailed information about each blockchain version to be tested, and uses professional code analysis tools to deeply analyze the source code of different versions. Then, based on the version feature analysis results, corresponding transaction data templates and smart contract data templates are formulated for the corresponding nodes. It can be understood that the transaction data templates and smart contract data templates are clearly defined in the code logic. In actual applications, they can be obtained based on the above analysis of the version source code. Specifically, the above data templates include but are not limited to transaction data templates and smart contract data templates. This embodiment takes the transaction data template and smart contract data template as examples. The data template uses a structured method to store version-specific fields and constraints. For example, the transaction data template includes the version number, basic fields, version-specific fields, verification rules, etc.; the smart contract data template includes the contract name, ABI (Application Binary Interface) version number, method parameter type, state variables, etc. The following Table 1 is a transaction data template in one embodiment:

[0064] Table 1

[0065]

[0066] The version_specific field (which only exists in the current version) is the specific field corresponding to the version of the node mentioned above.

[0067] Table 2 below is a smart contract data template in one embodiment:

[0068] Table 2

[0069]

[0070] Among them, the above-mentioned smart contract data template includes functions, that is, the method parameter type corresponding to the version, that is, the parameter field of the above-mentioned smart contract method corresponding to the version of the node.

[0071] In summary, based on the transaction data template and the smart contract data template, the above data template is obtained. This embodiment can efficiently implement the formulation of data templates corresponding to batches of nodes, facilitating the subsequent batch generation of test data.

[0072] In some embodiments, obtaining a generation rule includes:

[0073] Based on the data template and the preset actual business needs, corresponding transaction data generation rules and smart contract call rules are formulated for the corresponding nodes. The transaction data generation rules include basic transaction rules and transaction data version enhancement rules corresponding to the node version. The smart contract call rules include basic smart contract rules and smart contract version enhancement rules corresponding to the node version.

[0074] Based on the smart contract calling rules and transaction data generation rules, the generation rules are obtained.

[0075] Specifically, by combining data templates with actual business needs, comprehensive generation rules corresponding to version nodes are formulated. The generation rules mainly include transaction data generation rules and smart contract call rules. Moreover, both transaction data generation rules and smart contract call rules include basic rules and version enhancement rules, and adopt a layered constraint mechanism.

[0076] The above-mentioned transaction data generation rules include basic transaction rules and transaction data version enhancement rules. In some embodiments, the basic transaction rules include but are not limited to: the transaction amount must be greater than 0 and less than or equal to the sender's balance, the timestamp must comply with the time range of the blockchain network (±5 minutes), and the address format must comply with the version specification (such as EIP-55 verification); the transaction data version enhancement rules include but are not limited to: when a privacy encryption field is added in v2.3.0, the encryption field is randomly generated, with a 50% probability of being enabled, and the encryption algorithm uses AES-256-GCM; for example, when the calculation method of gas is adjusted in v2.2.0 (those skilled in the art will understand that gas is a unit derived from the public chain to measure the usage of computing resources, and is also used in some consortium chains to measure the computing resources required for contract execution), gas_price = basic gas fee × (1 + network congestion coefficient) is set, and the network congestion coefficient is randomly set to 0.1-0.3.

[0077] Similarly, the smart contract calling rules include basic smart contract rules and smart contract version enhancement rules corresponding to the node version. In some embodiments, the basic smart contract rules include but are not limited to: parameter types must match the ABI definition, the function call order must comply with the contract state machine (that is, the function call order must comply with the specific business logic in the smart contract, because the contract state changes are all realized through the transaction execution of function calls. For example, a contract about voting for new nodes must be carried out according to the contract states of initiating voting, voting, proposal completion / proposal rejection), precondition checks (such as whether the balance is sufficient, etc.); the above-mentioned smart contract version enhancement rules include but are not limited to: when permission management is introduced in v2.1.0, it is necessary to set the generation of valid permission credentials (such as random UUIDs), and the calling sequence must include permission granting steps; for example, when transaction limits are added in v3.0.0, it is necessary to set the transfer amount not to exceed the daily limit (the calculation of the daily transfer amount here should be dynamic), and the system maintenance period must be avoided when generating timestamps, etc. It will be understood that the above-mentioned v2.2.0, v2.1.0, v3.0.0, and v2.3.0 are all used to refer to different versions. In actual applications, relevant technical personnel can set specific versions according to actual needs.

[0078] In summary, based on the above smart contract calling rules and transaction data generation rules, the generation rules are obtained.

[0079] In actual applications, the version template of each node contains a version_specific field. The rule engine automatically matches the corresponding rule by version number (which is equivalent to finding the corresponding rule by mapping the version_specific field). In terms of conflicts, the version rule in this application takes precedence over the basic rule, and the special scenario rule overrides the general rule. In summary, based on the above data template and generation rules, test data covering version difference scenarios can be successfully generated.

[0080] In some embodiments, generating test data corresponding to each node to be verified based on a data template and a generation rule includes:

[0081] The initial test data generated based on the data template and the generation rule is filled with data to generate test data corresponding to at least one node.

[0082] Specifically, the initial test data corresponding to each version node includes the corresponding data template and generation rules. In actual applications, after obtaining the above initial test data, it is also necessary to use random number generators, data filling algorithms and other means to batch generate representative test data based on the initial test data. For example, for transaction data, it is necessary to randomly generate legal sender and receiver addresses (which must comply with the address format specified in the corresponding version) and transaction amounts, and accurately set additional field values ​​according to the version characteristics.

[0083] As for smart contract data, the above-mentioned data filling methods must be used to generate call parameters and data that comply with the contract interface and rules, such as randomly generating function call parameters that meet the value range requirements, to ensure that the generated data can fully cover various functional scenarios of the smart contract.

[0084] In some embodiments, the test data can be generated by a preset multi-version data simulation generator. Figure 2 This is a schematic diagram of the process of generating multi-version test data implemented by a multi-version data simulation generator in one embodiment. According to the above content, the multi-version data simulation generator can implement the above-mentioned version feature analysis function (i.e., obtaining detailed information of each blockchain version to be tested, and using professional code analysis tools to deeply analyze the source code of different versions), construct the above-mentioned data template corresponding to each version node, formulate generation rules corresponding to each version node, and fill data based on the data template and generation rules. Finally, the multi-version data simulation generator batch generates test data corresponding to multiple versions of nodes. In actual applications, the multi-version data simulation generator includes a data template generation algorithm and a generation rule generation algorithm. The following is the pseudo code of the key algorithms included in the multi-version data simulation generator in actual applications:

[0085] / / Transaction data generation algorithm

[0086] Algorithm GenerateTransactionData(version, sender_balance, current_time):

[0087] 1. Initialize the transaction template transaction = GetTransactionTemplate(version); (i.e., the generation of the transaction data template in the above data template)

[0088] 2. Generate basic fields: (i.e., the generation of basic transaction rules in the above generation rules)

[0089] a. sender_address, receiver_address generate legal addresses according to the address_format rule of version;

[0090] b. amount is a random value in the range of (0, sender_balance);

[0091] c. timestamp is randomly generated within the time interval [current_time-300, current_time+300];

[0092] d. signature transaction signature

[0093] 3. Application version enhancement rules: (i.e., generation of transaction data version enhancement rules in the above generation rules)

[0094] if version == "v2.3.0":

[0095] if random probability < 50%:

[0096] transaction.version_specific.encryption_field generates encrypted data using the AES-256-GCM algorithm;

[0097] if version == "v2.2.0":

[0098] transaction.version_specific.gas_price: base gas fee × (1 + 0.1~0.3 random congestion factor);

[0099] 4. Verify data compliance:

[0100] Call validation_rules to check the amount, timestamp, and address format;

[0101] 5. Return transaction; (i.e., complete data generation through the data generation algorithm)

[0102] / / Smart contract calls data generation algorithm

[0103] Algorithm GenerateSmartContractData(version, contract_name, abi_version, state_machine):

[0104] 1. Initialize the contract template contract = GetSmartContractTemplate(contract_name, abi_version); (i.e., generate the smart contract data template in the above data template)

[0105] 2. Generate function parameters: (Generate basic smart contract rules)

[0106] for each function in contract.functions:

[0107] parameters generates legal parameter types according to ABI definition (such as uint256, address);

[0108] Check parameter_type_match(parameters, abi_definition), if not, throw an exception;

[0109] 3. Application version enhancement rules: (i.e. smart contract version enhancement rules)

[0110] if version == "v2.1.0":

[0111] contract.version_specific.permission_id generates a random UUID;

[0112] Make sure the calling sequence includes the "grant_permission" pre-step;

[0113] if version == "v3.0.0":

[0114] Dynamically calculate daily_transfer = current day's cumulative transfer amount;

[0115] Check if transfer amount + daily_transfer ≤ daily_limit, otherwise adjust the amount;

[0116] Generate timestamps and avoid system maintenance periods;

[0117] 4. Return contract; (same as above, complete the generation of generation rules through the data generation algorithm)

[0118] In summary, on the basis of obtaining the initial test data corresponding to the nodes of each version, the initial test data is filled with data based on methods such as a random number generator and a data filling algorithm, thereby generating the complete test data mentioned above.

[0119] In some embodiments, when the central verification server performs consistency testing on each node, determining whether the corresponding released version and the version to be tested are compatible includes:

[0120] The central verification server calculates the hash value of the data to be verified corresponding to each node and obtains the account information corresponding to each node. When it is detected that the hash values ​​of the same type of data in the data to be verified are exactly the same, and when it is detected that the account information corresponding to each node is consistent, it is determined that the version of the corresponding node has passed the consistency test and the version to be tested corresponding to the node is compatible with the released version.

[0121] Specifically, this embodiment provides a consistency detection method for each node, which is used to determine whether the released version and the version to be tested are compatible.

[0122] First, the data collection module is used to collect the latest data corresponding to each node, i.e., the data to be verified. After receiving data from nodes of different versions, the central verification server uses a unified and secure hash algorithm (such as SHA-256) to calculate the hash value of the data to be verified corresponding to each node. For data of the same type (such as transaction data), its hash value under different versions is calculated separately.

[0123] The hash values ​​of the same type of data in different version nodes are compared one by one. If the hash values ​​are exactly the same, it means that the data maintains a high degree of consistency between different versions. If there are differences in the hash values, the system will immediately mark the data as having consistency issues and further analyze the causes of the differences, such as inconsistent data structure, tampering of field values, etc.

[0124] Furthermore, when verifying the hash value of the data being verified, in-depth verification of the status information of different blockchain versions of nodes is also required. For example, for account balance status, the balance information of the same account is queried on different versions of nodes to compare the balance values ​​for consistency and check whether the balance change records conform to the transaction logic. Furthermore, this account information includes, but is not limited to, account balance status and comprehensive verification combined with transaction history.

[0125] Furthermore, consistency testing of the smart contract states corresponding to each version node involves determining that the corresponding node version has passed consistency testing and that the tested version corresponding to the node is compatible with the released version when the value of the state variable in each node matches the contract execution logic and transaction records of the corresponding node. The contract execution logic refers to the preset execution logic corresponding to the smart contract, and the transaction records are pushed by the collection module, meaning that the transaction records can be determined based on the collected data corresponding to the nodes to be verified. For example, in a smart contract that records product inventory, the system checks whether the inventory quantity on different version nodes has consistently changed due to the same transaction operation (such as a product sale), and whether the inventory quantity is always above zero.

[0126] In some embodiments, the released version includes at least one released sub-version, and the version to be tested includes at least one sub-version to be tested.

[0127] Specifically, this embodiment does not impose excessive restrictions on the blockchain to be verified. The blockchain in this application defaults to a consortium chain. The blockchain to be verified should include at least one published sub-version, and the version to be tested should include at least one sub-version to be tested. Furthermore, in actual applications, to initiate consensus, the published mainstream version and the version to be tested must meet the consensus rules for the number of nodes. If the number of nodes of different versions is insufficient, several more nodes of the same version can be started. For example, a commonly used Byzantine fault-tolerant consensus algorithm must tolerate at most f malicious nodes, and must satisfy n ≥ 3f + 1 (where n is the total number of nodes and f is the fault tolerance number), meaning the number of nodes must be at least 4.

[0128] This application also provides a preferred embodiment of a blockchain cross-version compatibility verification method. Figure 3 Schematic diagram of a flow chart of a compatibility verification method in a preferred embodiment.

[0129] Step S310: Set up the blockchain to be verified. You can choose from three mainstream released versions, such as 1.0, 2.0, and 3.0. Use three independent servers in the test environment to deploy nodes for each of these versions and initialize their configuration. Furthermore, you can set up a node for the version to be verified (i.e., the new version node to be tested) on another independent server. After this setup is complete, you can configure the network connection. Specifically, set the correct network connection parameters in each node's configuration file, start the node, and join the different versions of the node to the same blockchain network.

[0130] Step S320: Deploy the collection module on each node. Specifically, a lightweight data collection module can be written in Go language so that it can be easily deployed on servers with different operating systems. The binary file of the collection module is copied to the server of each blockchain node. Furthermore, on each node server, a system configuration file collector_config.toml is created, which contains the collection time interval and the target address for data transmission. The collection module is then started through the command line, such as . / data_collector --config collector_config.toml. In summary, the parameter configuration and startup of the collection module are completed.

[0131] Step S330, configure the central verification server. Specifically, upload the data verification software of the installation package BlockchainValidator to the server and decompress and install it, wherein the installation package is used to perform the above-mentioned data consistency verification. In the configuration file of BlockchainValidator, set the hash calculation algorithm to SHA-256, use MongoDB to store and query the collected blockchain data, and define the collection structure of the data storage, such as creating a transactions collection for storing transaction data, a blocks collection for storing block data, etc. In summary, the data consistency test can be completed later through the hash calculation algorithm SHA-256, and after the test data is sent to the blockchain cluster through a transaction, the collection module deployed on the node will push the collected data to the central verification server. Then, when the central verification server stores the data in MongoDB, MongoDB can be used to store and query the collected blockchain data. Furthermore, you can configure related parameters for exception handling. For example, when a data consistency issue is detected, an email notification is automatically sent to the administrator. For test report generation, the output format of the test report can be set to HTML, the report generation interval can be set to once a day, that is, report_interval = "1d", and the report output path can be set to / reports / blockchain_validation_report.html.

[0132] Step S340: Generate test data and perform transaction simulation. Specifically, a multi-version data simulation generator is used. The multi-version data simulation generator can determine the data templates and generation rules corresponding to each node, thereby generating various types of test data based on the data structure characteristics of different versions. The generated test data is sent to each node in the previously deployed blockchain cluster in the form of a transaction through the JSON-RPC interface.

[0133] Step S350 performs cross-version data consistency verification. Specifically, the data collection module on each node collects blockchain data from the node at the configured time interval to obtain the aforementioned data to be verified. The data to be verified includes newly generated transaction data and newly generated block data. After collection, the data is transmitted to the specified destination address (i.e., the address of the central verification server). The collected data is verified by the BlockchainValidator, and a corresponding report is generated based on the verification results.

[0134] Through the above method, various types of data under different blockchain versions can be fully and accurately simulated, effectively covering data change scenarios caused by version differences, and providing rich, high-quality test data for compatibility testing. In addition, this application provides multi-dimensional verification methods for cross-version data consistency verification, including hash calculation and comparison, status information verification, etc., which can quickly and accurately detect data consistency problems between different versions, greatly improving the efficiency and accuracy of data compatibility testing. In summary, through the solution in this application, the data compatibility between different versions of the blockchain can be significantly improved, the risks caused by version upgrades or data interactions can be reduced, the stable operation of the blockchain system can be guaranteed, and the widespread application and healthy development of blockchain technology can be promoted.

[0135] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0136] Based on the same inventive concept, the present application also provides a compatibility verification device for implementing the aforementioned compatibility verification method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more of the following embodiments of the compatibility verification device can be found in the above-mentioned limitations of the compatibility verification method and will not be repeated here.

[0137] In one embodiment, Figure 4 As shown, a compatibility verification device is provided, including: an acquisition module 41, a calculation module 42 and a generation module 43, wherein:

[0138] An acquisition module 41 is configured to construct a blockchain to be verified, wherein the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0139] A calculation module 42 is configured to determine a data template and generation rule corresponding to each node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rule, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes a specific field corresponding to the node version, and the generation rule includes a version enhancement rule corresponding to the node version; and the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0140] The generation module 43 is used to collect the data to be verified on the corresponding node at a preset time interval based on the collection module preset on the node, and send the data to be verified to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding released version and the version to be tested is determined, wherein the data to be verified is generated based on data activity.

[0141] Each module in the compatibility verification device described above may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor in a computer device in the form of hardware, or may be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0142] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data related to the compatibility verification algorithm. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a compatibility verification method is implemented.

[0143] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0144] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0145] Building a blockchain to be verified, where the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested;

[0146] Determine the data template and generation rules corresponding to the node based on the version corresponding to the node, generate test data corresponding to each node based on the data template and generation rules, and send the test data to the node so that each node performs a corresponding data activity based on the test data; wherein the data template includes specific fields corresponding to the node version, and the generation rules include version enhancement rules corresponding to the node version; the test data is test data for nodes corresponding to the version to be tested and nodes corresponding to the released version;

[0147] Based on the preset collection module on the node, the data to be verified on the corresponding node is collected at preset time intervals, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding released version and the version to be tested is determined, wherein the data to be verified is generated based on data activity.

[0148] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0149] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0150] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0151] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A blockchain cross-version compatibility verification method, characterized in that: The method comprises: Building a blockchain to be verified, wherein the blockchain to be verified includes nodes of at least two different versions; the versions include a released version and a version to be tested; Determine, based on the version corresponding to the node, a data template and generation rules corresponding to the node; generate test data corresponding to each of the nodes based on the data template and the generation rules; and send the test data to the node so that each of the nodes performs a corresponding data activity based on the test data; wherein the data template includes a specific field corresponding to the version of the node, and the generation rules include a version enhancement rule corresponding to the version of the node; and the test data is test data for the node corresponding to the version to be tested and the node corresponding to the released version; Based on the preset collection module on the node, the data to be verified on the corresponding node is collected at preset time intervals, and the data to be verified is sent to the central verification server for consistency detection. When the data to be verified passes the consistency detection, the compatibility between the corresponding published version and the version to be tested is determined, wherein the data to be verified is generated based on the data activity.

2. The compatibility verification method according to claim 1, wherein: The method further comprises: When it is detected that the data to be verified corresponding to each node has consistency problems, a corresponding test report is generated based on the target node where there are differences in the data to be verified, wherein the test report includes the severity level of the consistency problem, the cause of the consistency problem and the solution to the consistency problem.

3. The compatibility verification method according to claim 1, wherein: Obtaining the data template includes: Parsing the version corresponding to the node, and formulating a corresponding transaction data template and smart contract data template for the corresponding node based on the version feature parsing results, wherein the transaction data template includes specific fields corresponding to the version of the node, and the smart contract data template includes parameter fields of the smart contract method corresponding to the version of the node; The data template is obtained based on the transaction data template and the smart contract data template.

4. The compatibility verification method according to claim 1, wherein: Obtaining the generation rule includes: Based on the data template and the preset actual business needs, corresponding transaction data generation rules and smart contract call rules are formulated for the corresponding node, wherein the transaction data generation rules include basic transaction rules and transaction data version enhancement rules corresponding to the node version, and the smart contract call rules include basic smart contract rules and smart contract version enhancement rules corresponding to the node version; The generation rule is obtained based on the smart contract calling rule and the transaction data generation rule.

5. The compatibility verification method according to claim 1, wherein: Generating test data corresponding to each of the nodes based on the data template and the generation rule includes: Data filling is performed on the initial test data generated based on the data template and the generation rule to generate the test data corresponding to at least one node.

6. The compatibility verification method according to claim 1, wherein: When the central verification server performs consistency testing on each node, determining whether the corresponding released version and the version to be tested are compatible includes: The central verification server calculates the hash value of the data to be verified corresponding to each node, and obtains the account information corresponding to each node. When it is detected that the hash values ​​of the same type of data in the data to be verified are exactly the same, and when it is detected that the account information corresponding to each node is consistent, it is determined that the version of the corresponding node passes the consistency test, and the version to be tested corresponding to the node is compatible with the released version.

7. The compatibility verification method according to claim 1, wherein: The published version includes at least one published sub-version, and the version to be tested includes at least one sub-version to be tested.

8. A compatibility verification device, characterized in that: The device comprises: An acquisition module is configured to construct a blockchain to be verified, wherein the blockchain to be verified includes at least two nodes of different versions; wherein the versions include a released version and a version to be tested; a calculation module, configured to determine, based on the version corresponding to the node, a data template and generation rules corresponding to the node, generate test data corresponding to each of the nodes based on the data template and the generation rules, and send the test data to the node so that each of the nodes performs a corresponding data activity based on the test data; wherein the data template includes a specific field corresponding to the version of the node, the generation rules include a version enhancement rule corresponding to the version of the node; and the test data is test data for the node corresponding to the version to be tested and the node corresponding to the released version; A generation module is used to collect the data to be verified on the corresponding node at a preset time interval based on the collection module preset on the node, and send the data to be verified to a central verification server for consistency testing. When the data to be verified passes the consistency test, it is determined that the corresponding published version and the version to be tested are compatible, wherein the data to be verified is generated based on the data activity.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images