A blockchain-based data processing method, apparatus, device, and medium

Abstract

Embodiments of the application disclose a data processing method and device based on a blockchain, equipment and a medium. The method comprises: generating target construction instructions associated with a target network topology structure when M simulation nodes respectively correspond to node information is acquired; acquiring a first simulation execution result obtained after a blockchain service is executed in the target network topology structure; generating target transfer instructions corresponding to the target network topology structure based on a path offset degree corresponding to the target network topology structure; acquiring a second simulation execution result obtained after the blockchain service is executed in a heterogeneous network topology structure; and determining consensus states of the target network topology structure and the heterogeneous network topology structure based on the first simulation execution result and the second simulation execution result, respectively. The consensus state is used to reflect stability of a consensus layer of the blockchain network. The embodiments of the application can improve test efficiency and test accuracy.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a data processing method, apparatus, device and medium based on blockchain. Background Technology

[0002] Traditional testing of blockchain network topology typically involves two stages: construction and manual analysis. The construction stage requires allocating machine resources and address identifiers to draw various network topologies based on the number of nodes. The manual analysis stage requires manual analysis of inter-node communication for each topology, triggering commands manually. Because these two stages are isolated and lack coordination, and the entire process requires manual intervention, significant time is spent analyzing data with a large number of nodes, leading to high labor costs. Therefore, this low-automation testing method not only results in low testing efficiency but also reduces accuracy. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and medium based on blockchain, which can improve testing efficiency and accuracy.

[0004] One embodiment of this application provides a blockchain-based data processing method, including:

[0005] Upon obtaining the node information corresponding to each of the M simulated nodes, a target construction instruction associated with the target network topology is generated. The target construction instruction is used to instruct the M simulated nodes to construct the target network topology associated with the blockchain network; M is a positive integer.

[0006] Obtain the first simulated execution result after executing blockchain business in the target network topology;

[0007] Based on the path offset corresponding to the target network topology, a target transfer instruction corresponding to the target network topology is generated; the target transfer instruction is used to instruct M simulated nodes to switch from the target network topology to the heterogeneous network topology.

[0008] Obtain the second simulated execution result after executing blockchain business in a heterogeneous network topology;

[0009] Based on the results of the first and second simulations, the consensus states of the target network topology and the heterogeneous network topology are determined respectively; the consensus state is used to reflect the stability of the consensus layer of the blockchain network.

[0010] One embodiment of this application provides a blockchain-based data processing device, including:

[0011] The construction instruction generation module is used to generate target construction instructions associated with the target network topology when the node information corresponding to M simulated nodes is obtained. The target construction instructions are used to instruct the M simulated nodes to construct the target network topology associated with the blockchain network; M is a positive integer.

[0012] The first result acquisition module is used to acquire the first simulated execution result obtained after executing blockchain business in the target network topology;

[0013] The transfer instruction generation module is used to generate target transfer instructions corresponding to the target network topology based on the path offset of the target network topology; the target transfer instructions are used to instruct M simulated nodes to switch from the target network topology to the heterogeneous network topology.

[0014] The second result acquisition module is used to acquire the second simulated execution result obtained after executing blockchain business in a heterogeneous network topology.

[0015] The consensus state determination module is used to determine the consensus state of the target network topology and the heterogeneous network topology based on the first simulation execution result and the second simulation execution result, respectively; the consensus state is used to reflect the stability of the consensus layer of the blockchain network.

[0016] Among them, M simulation nodes include simulation node N i ; i is a positive integer less than or equal to M;

[0017] The constructor instruction generation module includes:

[0018] The type set acquisition unit is used to obtain a set of network topologies associated with the blockchain network after acquiring node information corresponding to M simulated nodes; the set of network topologies includes X types of topologies; X is a positive integer.

[0019] The target type determination unit is used to determine the target topology type to be simulated from X types of topology types;

[0020] The connection relationship determination unit is used to determine the connection relationship N based on the target topology type and M simulation nodes. i The corresponding node connection relationship;

[0021] The construction instruction generation unit is used to generate construction instructions that conform to the target topology type based on the node information corresponding to the M simulated nodes and the M node connection relationships when the node connection relationships corresponding to the M simulated nodes are obtained. The generated construction instructions are used as target construction instructions associated with the target network topology.

[0022] The connection relationship determination unit includes:

[0023] The first determining sub-unit is used to determine the relationship between simulation node N and M simulation nodes based on the target topology type. i The simulated nodes with connections are designated as simulated node N. i The corresponding first type of node;

[0024] The second determining sub-unit is used to determine the relationship between simulation node N and the target topology type from M simulation nodes. i Simulation nodes that do not have a connection relationship will be identified as simulation node N. i The corresponding second type of node;

[0025] The first relationship determines the sub-unit, used based on simulation node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0026] Among them, the target topology type includes star topology type;

[0027] The connection determination unit includes:

[0028] The third determined sub-unit is used if the simulation node N i If the central node belongs to the star topology type, then the M simulated nodes excluding simulated node N will be selected. i All other simulation nodes are designated as simulation node N. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships;

[0029] The second relationship determines the sub-unit, used based on simulation node N. i The corresponding first type of node yields the simulated node N. i The corresponding node connection relationships.

[0030] The connection relationship determination unit includes:

[0031] The fourth determined sub-unit is used if the simulation node N iIt belongs to the non-central node in the star topology type, and the central node in the star topology type is simulation node N out of M simulation nodes. j Then simulate node N j N is determined to be a simulation node. i The corresponding first type node; j is a positive integer less than or equal to M, and j is not equal to i;

[0032] The fifth determined sub-unit is used to select from the M simulation nodes excluding simulation node N. j All other simulation nodes are designated as simulation node N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected;

[0033] The third relationship determines the sub-unit, used based on simulation node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0034] Among them, the target topology type includes the ring topology type;

[0035] The connection determination unit includes:

[0036] The sixth sub-unit is determined based on the ring topology type and the number of simulated nodes N. i Determine simulation node N from M simulation nodes. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships;

[0037] The seventh sub-unit is used to identify the other simulation nodes (excluding the first type of nodes) among the M simulation nodes as simulation node N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected;

[0038] The fourth relationship determines the sub-unit, used based on the simulated node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0039] The ring-shaped topology includes a first node, intermediate nodes, and a tail node; the first node is simulation node N1 out of the M simulation nodes; the tail node is simulation node N out of the M simulation nodes. MThe intermediate nodes are the other simulated nodes among the M simulated nodes, excluding the first and last nodes.

[0040] This sixth determining subunit is also used for:

[0041] If the simulated node N i If it belongs to the first node, then simulated node N2 and simulated node N from the M simulated nodes. M All were determined to be simulated nodes N. i The corresponding first type of node;

[0042] If the simulated node N i If it belongs to the tail node, then simulated node N1 and simulated node N out of the M simulated nodes will be... M-1 All were determined to be simulated nodes N. i The corresponding first type of node;

[0043] If the simulated node N i If it belongs to an intermediate node, then simulate node N out of the M simulated nodes. i-1 and simulated node N i+1 All were determined to be simulated nodes N. i The corresponding first type of node.

[0044] The method is executed by test nodes; the test nodes are M simulated nodes; the blockchain business includes a sub-business for reaching consensus on the information to be verified;

[0045] The first result acquisition module includes:

[0046] The information broadcasting unit is used to execute blockchain business in the target network topology, broadcasting the information to be verified to (M-1) simulated nodes so that the (M-1) simulated nodes can reach a consensus on the information to be verified and obtain a consensus result;

[0047] The success result determination unit is used to determine that if there is a consensus result in the consensus results returned by (M-1) simulated nodes that exceeds the consensus threshold and indicates that the consensus is successful, then the simulated nodes in the blockchain network corresponding to the target network topology have reached a consensus and a first simulated execution result indicating successful execution is obtained.

[0048] The failure result determination unit is used to determine that the simulated nodes in the blockchain network corresponding to the target network topology have not reached a consensus if none of the consensus results returned by (M-1) simulated nodes exceed the consensus threshold and indicate that the consensus was successful. This results in the first simulated execution result indicating the execution failure.

[0049] The transfer instruction generation module includes:

[0050] The path offset determination unit is used to acquire test accuracy parameters associated with the target network topology, and determine the path offset corresponding to the target network topology based on the test accuracy parameters; the path offset is determined based on the total number of paths corresponding to the target network topology.

[0051] The dynamic transfer unit is used to dynamically transfer the target network topology based on the path offset to obtain the heterogeneous topology corresponding to the target network topology.

[0052] The connection relationship redeter unit is used to redetermine the node connection relationships corresponding to the M simulation nodes based on the heterogeneous topology and the M simulation nodes.

[0053] The transfer instruction generation unit is used to generate construction instructions for constructing a heterogeneous topology based on the newly determined connection relationship of M nodes, and to use the generated construction instructions as the target transfer instructions corresponding to the target network topology.

[0054] The device also includes:

[0055] The business topology determination module is used to determine the first simulation execution result or the second simulation execution result as the business simulation execution result, and to determine the network topology corresponding to the business simulation execution result as the business network topology; the business network topology includes the target network topology and the heterogeneous network topology;

[0056] The status setting module is used to set the running status of the blockchain network corresponding to the business network topology to a blocked state if the business simulation execution result indicates that the execution has failed.

[0057] The device also includes:

[0058] The error information acquisition module is used to acquire error identification codes and error details that indicate execution failure when the blockchain network is in a blocked state.

[0059] The exception information display module is used to generate exception prompts related to the blockchain business based on the error identification code and error details, and display the exception prompts on the test node corresponding to the test object.

[0060] The device also includes:

[0061] The quantity statistics module is used to count the first number of the first network topology that meets the consensus conditions and the second number of the second network topology that does not meet the consensus conditions, respectively, from the consensus state of the target network topology and the consensus state of the heterogeneous network topology.

[0062] A stability determination module is used to determine the stability of the target network topology to the consensus layer in the blockchain network based on a first quantity and a second quantity.

[0063] The test report generation module is used to generate test reports for testing the consensus layer of the blockchain network based on the stability of the consensus layer in each network topology in the set of network topologies.

[0064] The test report display module is used to display the test report on the test node corresponding to the test object.

[0065] This application provides a computer device, including: a processor, a memory, and a network interface;

[0066] The processor is connected to a memory and a network interface. The network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the methods provided in the embodiments of this application.

[0067] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0068] One aspect of this application provides a computer program product, which includes a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method described in this application.

[0069] In this embodiment, the test node with network topology testing capabilities, upon obtaining node information corresponding to M simulated nodes, can automatically generate a target construction instruction associated with the target network topology. This allows the M simulated nodes to quickly construct the target network topology based on the instruction, thereby obtaining a first simulated execution result after executing blockchain business within the target network topology. Simultaneously, the test node also considers the dynamic characteristics between network topologies. Based on the path offset of the target network topology, it automatically generates a target transfer instruction, enabling the M simulated nodes to quickly switch from the target network topology to a heterogeneous network topology, thus obtaining a second simulated execution result after executing blockchain business within the heterogeneous network topology. Furthermore, the test node can determine the consensus state of each network topology (i.e., the target network topology and the heterogeneous network topology) based on the first and second simulated execution results, reflecting the stability of the blockchain network's consensus layer. Therefore, the testing method provided in this embodiment requires no manual intervention, automating the entire process and significantly reducing testing costs while improving efficiency. Furthermore, this testing method takes into account the dynamic characteristics between network topologies when evaluating the impact on the consensus layer, thereby improving the accuracy of the test. Attached Figure Description

[0070] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0071] Figure 1a This is a schematic diagram of the structure of a blockchain node system provided in an embodiment of this application;

[0072] Figure 1b These are schematic diagrams illustrating the various network topologies provided in the embodiments of this application;

[0073] Figure 2 This is a schematic diagram of a scenario for conducting network topology transformation testing, provided in an embodiment of this application.

[0074] Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0075] Figure 4 This is a schematic diagram illustrating a scenario for determining a heterogeneous network topology, provided in an embodiment of this application.

[0076] Figure 5 This is a schematic diagram of another scenario for determining the topology of a heterogeneous network provided in an embodiment of this application;

[0077] Figure 6 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0078] Figure 7 This is a schematic diagram of the overall process for testing a blockchain network topology, provided in an embodiment of this application.

[0079] Figure 8 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application;

[0080] Figure 9 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0081] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0082] Please see Figure 1a , Figure 1aThis is a schematic diagram of the structure of a blockchain node system provided in an embodiment of this application. It should be understood that the blockchain network corresponding to the blockchain node system is a peer-to-peer (P2P) network, which is a distributed application architecture that distributes tasks and workloads among users. It is a network or grouping form of a peer-to-peer computing model at the application layer. The blockchain nodes in this blockchain network can be any form of computer device connected to the blockchain network. For example, the computer device can be a client connected to the blockchain network or a server connected to the blockchain network; the specific form of the blockchain node is not limited here. In other words, each computer in this blockchain network can act as a requester of network services and can also respond to requests from other computers, providing resources, services, and content. The servers connected to the blockchain network can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud computing services. Clients connected to the blockchain network can run on terminal devices, which can include: smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, in-vehicle terminals, smart TVs, and other smart terminals.

[0083] In blockchain networks (e.g., public blockchains), since there is no authentication required, joining a blockchain node is costless. Nodes can join and, by adjusting network policies or addressing network jitter, form various network topologies. Understandably, while these network topologies do not affect the normal function of the P2P layer, they can impact the consensus layer of the blockchain network. Therefore, during the testing phase, test nodes with network topology testing capabilities can obtain node information corresponding to M simulated nodes and simulate various network topologies to accurately assess their impact on the consensus layer. Here, the test node can be any one of the M simulated nodes or a separate computer device independent of these M simulated nodes; no specific limitations will be imposed on the test node here.

[0084] Understandably, in a P2P network, normal consensus nodes satisfy P2P full connectivity, meaning all nodes are interconnected in pairs to form a consensus network. Figure 1a The blockchain node system 100S shown is a distributed system formed by multiple nodes connected through network communication. Figure 1a The blockchain system 100S shown is constructed from M simulated nodes, where M is a positive integer, such as... Figure 1aAs shown, these M simulation nodes can specifically include node 10A, node 10B, node 10C, ..., node 10M.

[0085] Understandably, blockchain is a distributed ledger technology that is jointly maintained by multiple parties, uses cryptography to ensure secure transmission and access, and enables consistent data storage, tamper-proofing, and non-repudiation. The blockchain lifecycle is as follows: 1. A client sends a transaction to a blockchain node, which broadcasts the transaction to other nodes via a P2P network; 2. The consensus mechanism in the blockchain randomly selects a blockchain node as the ledger node; 3. The ledger node packages a list of transactions into a block structure, generates a block proposal message, and broadcasts it to other nodes. If the transaction list is empty, it is packaged into an empty block and broadcast; 4. After receiving the block, other nodes need to verify the transactions within the block and broadcast their votes on the proposal; 5. After reaching a consensus on the block, the ledger node can submit the block to the blockchain storage layer to begin the next round of election and consensus.

[0086] Here, consensus algorithm refers to the process by which all parties reach a consensus on a proposal (goals, voting, and various collaborative tasks). For example, this consensus algorithm could include Byzantine Fault Tolerance (BFT) consensus. Byzantine fault tolerance is a fault-tolerant technology in the field of distributed computing. In a distributed system with M blockchain nodes, if the number of Byzantine nodes in the entire system does not exceed f (M≥3f+1), the entire system can operate normally, meaning it allows M / 3 nodes to malfunction. f indicates the maximum number of illegitimate nodes (i.e., malicious nodes) in the distributed system. For example, in a 7-node blockchain system, the maximum number of illegitimate nodes allowed is 2. Illegitimate nodes might not transmit messages or transmit inconsistent messages in an attempt to disrupt other nodes. This consensus algorithm does not rely on unrealistic assumptions and allows illegitimate nodes to delay network transmissions between normal nodes, providing security and activity even when fewer than 1 / 3 of the nodes are illegitimate.

[0087] exist Figure 1aIn the illustrated blockchain system 100S, consensus can be achieved when at least (2f+1) non-malicious nodes are functioning normally. In other words, in a typical BFT-based consensus blockchain network, the ledger node loads the transaction list from the transaction pool, constructs a block proposal, and broadcasts it to other nodes. Upon receiving the block proposal, other nodes verify it and can vote for or against it. When a node votes against a block proposal, each node collects voting information and verifies whether the number of votes in favor is greater than 2 / 3 of the total number of nodes. If it is, it is determined that all blockchain nodes in blockchain system 100S have reached consensus, and the block is submitted to that node. If it is less than 2 / 3 of the total number of nodes, it is determined that the blockchain nodes in blockchain system 100S have not reached consensus, and the blockchain operation becomes abnormal and blocked. Therefore, it is crucial for blockchain to possess the ability to handle various complex network topologies and dynamic transitions between structures.

[0088] Therefore, during the testing phase, the test node can obtain node information corresponding to each of the M simulated nodes, and then generate a target construction instruction associated with the target network topology. This target construction instruction can be used to instruct the M simulated nodes to construct the target network topology. The target network topology can be any of several network topologies associated with the blockchain network that arise due to unreliable or unstable network conditions. For example, these various network topologies can include bus topologies, star topologies, ring topologies, tree topologies, hybrid topologies, and isolated topologies (also known as partitioned topologies).

[0089] Furthermore, the test node can obtain the simulated execution results (i.e., the first simulated execution result) obtained after executing blockchain business in the target network topology. Here, the blockchain business can be used to trigger the execution of normal use cases on the blockchain automation platform. These normal use cases can include simulated consensus use cases and simulated interface use cases; for example, the simulated interface use cases could refer to simulated transaction on-chaining, transaction querying, and contract deployment.

[0090] Furthermore, since blockchain networks are constantly changing dynamically, structural transitions between topologies are also a key focus of testing. Therefore, the test node can generate target transition instructions corresponding to the target network topology based on the path offset of the target network topology. These target transition instructions are used to demonstrate the switching of M simulated nodes from the target network topology to a heterogeneous network topology. At this time, the test node can also obtain the simulated execution results (i.e., the second simulated execution result) obtained after executing blockchain business in the heterogeneous network topology. Further, the test node can determine the consensus state of the target network topology and the heterogeneous network topology based on the first and second simulated execution results, respectively. This consensus state can be used to reflect the stability of the consensus layer of the blockchain network. Thus, this application embodiment provides a network topology transformation testing method based on path offset. This testing method requires no manual intervention, automating the entire process, thereby greatly reducing testing costs and improving testing efficiency. In addition, this testing method considers the dynamic characteristics between network topologies when evaluating the impact on the consensus layer, thus improving the accuracy of the test.

[0091] For better understanding, please refer to [link / reference]. Figure 1b , Figure 1b This is a schematic diagram of various network topologies provided in the embodiments of this application. The network topologies associated with the blockchain network involved in these embodiments may include X types of network topologies, where X can be a positive integer. These various network topologies may include bus topologies, star topologies, ring topologies, tree topologies, hybrid topologies, and isolated topologies (also known as partitioned topologies).

[0092] Among them, the bus topology can be Figure 1b The network topology 1000J1 shown here connects M (e.g., 5) analog nodes directly to a common bus via corresponding hardware interfaces. The analog nodes communicate via broadcast; information sent by one node can be received by all other nodes on the bus. This network topology offers advantages such as simple structure, easy wiring, high reliability, and ease of expansion.

[0093] Among them, the star topology can be Figure 1b The network topology 1000J2 shown consists of M (e.g., 6) simulated nodes. This network topology can include two types of nodes: central nodes and non-central nodes. That is, this network topology is a radial interconnection structure with a central node connecting several peripheral nodes. This network topology has advantages such as simple structure, ease of implementation, and convenient management, facilitating network maintenance and management.

[0094] Among them, the ring topology can be Figure 1b The network topology 1000J3 shown consists of M (e.g., 6) analog nodes. These analog nodes can form closed loops via communication lines and can include three types of nodes: head nodes, tail nodes, and intermediate nodes. This network topology has advantages such as simple structure, long transmission distance, and deterministic transmission delay.

[0095] Among them, the tree topology can be Figure 1b The network topology 1000J4 shown consists of M (e.g., 9) analog nodes. This network topology is a hierarchical structure, with analog nodes connected hierarchically. Information exchange mainly occurs between nodes above and below each other; data exchange is generally not performed between adjacent nodes or nodes at the same level. This network topology has advantages such as simple connection and convenient maintenance, and is suitable for applications requiring information aggregation.

[0096] Hybrid topology can include Figure 1b The network topologies 1000J5 and 1000J6 shown are illustrated. Network topology 1000J5 can be composed of M (e.g., 6) simulated nodes, and network topology 1000J6 can be composed of M (e.g., 9) simulated nodes. This type of network topology is also called an irregular structure, where the connections between simulated nodes are arbitrary and without any pattern. This network topology has advantages such as high system reliability and relatively easy expansion.

[0097] Among them, the partitioned topology can be Figure 1b The network topology 1000J7 shown consists of M (e.g., 6) simulated nodes. This network topology refers to a structure where network partitioning or isolation occurs, leading to a "split-brain" phenomenon. Isolated networks can communicate independently, but communication between two network areas is difficult. This network topology offers advantages such as high data security and privacy protection.

[0098] For better understanding, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario for conducting network topology transformation testing, as provided in an embodiment of this application. Figure 2 As shown, the test node in this embodiment can be a computer device independent of the blockchain network. The test node can be a terminal device or a server, and there is no limitation on it here.

[0099] like Figure 2As shown, when evaluating the impact of the blockchain network topology on the consensus layer, the test node can obtain node information corresponding to the M simulated nodes used to build the blockchain network. This node information may include node address identifiers (e.g., IP addresses), port information, and network interface card information. M is a positive integer greater than 3. For ease of understanding, the number of simulated nodes in this embodiment can be taken as 4. In this case, the node information obtained by the test node may specifically include the node information corresponding to node N1 (e.g., ...). Figure 2 The node information shown is X1), and the node information corresponding to node N2 is (for example, Figure 2 The node information shown is X2), and the node information corresponding to node N3 is (for example, Figure 2 The node information shown is X3) and the node information corresponding to node N4 (e.g., Figure 2 The node information shown is X4.

[0100] Furthermore, the test node can input the information of these four nodes into the intelligent network topology program, and based on this program, generate target construction instructions associated with the target network topology (e.g., a star topology). These target construction instructions instruct the four simulated nodes to construct the target network topology associated with the blockchain network. For example, the test node can distribute these target construction instructions to... Figure 2 The four simulated nodes shown are used to execute the target construction instructions individually, constructing the target network topology in seconds (e.g., Figure 2 The network topology shown is 200J.

[0101] Furthermore, the test node can obtain the simulated execution result 20G (i.e., the first simulated execution result) obtained after executing blockchain business (e.g., consensus business) in network topology 200J. Based on this simulated execution result 20G, the consensus state of network topology 200J can be determined, i.e., whether BFT consensus is satisfied when the blockchain network topology is network topology 200J. Here, the simulated execution result can include execution failure results or execution success results. An execution failure result refers to the simulated execution result indicating execution failure obtained after executing blockchain business in the current network topology, while an execution success result refers to the simulated execution result indicating execution success obtained after executing blockchain business in the current network topology.

[0102] To more accurately assess the impact on the consensus layer of the blockchain network, the test node also needs to consider the dynamic transfer characteristics of network topology 200J. Specifically, the test node can generate a target transfer instruction corresponding to network topology 200J based on the path offset. Here, path offset refers to the number of paths offset within the current network topology. The target transfer instruction instructs the four simulated nodes to switch from network topology 200J to a heterogeneous network topology. This allows the test node to subsequently obtain the second simulated execution result after executing blockchain business in the heterogeneous network topology. Based on the first and second simulated execution results, the consensus state of each network topology can be obtained, reflecting the stability of the blockchain network's consensus layer.

[0103] If the path offset value determined by the test node is 1, it means that a path is offset (i.e., deleted or changed) within the network topology 200J. Based on this, the test node can generate multiple target transfer instructions based on the path offset value of 1. For example, these target transfer instructions can include a first transfer instruction, a second transfer instruction, and a third transfer instruction.

[0104] The first transfer instruction refers to the instruction to delete a specific path in network topology 200J (e.g., the path between nodes N1 and N3). It can be understood that when the test node generates the first transfer instruction, it can send this instruction to the corresponding simulated nodes, causing these four simulated nodes to switch from network topology 200J to... Figure 2 The network topology shown is 200J. 11 Furthermore, this test node can acquire data within a 200J network topology. 11 The simulated execution result G obtained after executing blockchain business (e.g., consensus business) in the blockchain. 11 (i.e., the second simulation execution result), and then based on this simulation execution result G 11 Determine the network topology 200J 11 The consensus state, that is, in the blockchain network topology structure of network topology structure 200J. 11 At that time, does it satisfy the BFT consensus?

[0105] The second transfer instruction refers to an instruction that changes one of the paths in network topology 200J. For example, the second transfer instruction is used to change the path between nodes N1 and N3 to the path between nodes N2 and N4. It can be understood that when the test node generates the second transfer instruction, it can send the instruction to the corresponding simulated nodes, causing these four simulated nodes to switch from network topology 200J to... Figure 2The network topology shown is 200J. 12 Furthermore, this test node can acquire data within a 200J network topology. 12 The simulated execution result G obtained after executing blockchain business (e.g., consensus business) in the blockchain. 12 (i.e., the second simulation execution result), and then based on this simulation execution result G 12 Determine the network topology 200J 12 The consensus state, that is, in the blockchain network topology structure of network topology structure 200J. 12 At that time, does it satisfy the BFT consensus?

[0106] The third transfer instruction refers to an instruction that changes another path in network topology 200J. For example, this third transfer instruction is used to change the path between node N1 and node N3 to the path between node N4 and node N3. It can be understood that when a test node generates a third transfer instruction, it can send this instruction to the corresponding simulated nodes, causing these four simulated nodes to switch from network topology 200J to... Figure 2 The network topology shown is 200J. 13 Furthermore, this test node can acquire data within a 200J network topology. 13 The simulated execution result G obtained after executing blockchain business (e.g., consensus business) in the blockchain. 13 (i.e., the second simulation execution result), and then based on this simulation execution result G 13 Determine the network topology 200J 13 The consensus state, that is, in the blockchain network topology structure of network topology structure 200J. 13 At that time, does it satisfy the BFT consensus?

[0107] Therefore, in this embodiment, both the static characteristics (i.e., the inherent characteristics of the target network topology) and the dynamic characteristics (i.e., the characteristics of switching from the target network topology to various heterogeneous network topologies) of the blockchain network can be automatically simulated and tested under the blockchain consensus mechanism. The entire process requires no manual intervention and automatically analyzes and generates various network topologies. This means that the test nodes in this embodiment can cover the dynamic transfer characteristics of network topologies at low cost and high efficiency, achieving comprehensiveness in blockchain topology testing, thereby improving the accuracy of evaluating the impact on the consensus layer of the blockchain network.

[0108] The specific implementation method for the test node to perform network topology transformation testing on the blockchain network based on path offset can be found below. Figures 3-7 The corresponding implementation examples.

[0109] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 3 As shown, this method can be executed by a test node, which can be a simulated node used to simulate a blockchain network (e.g., the one described above). Figure 1a The device shown as 10A can also be other computer devices independent of the blockchain network, and this will not be limited here. The test node can be a terminal device or a server. The method can include at least the following steps S101-S105:

[0110] Step S101: When the node information corresponding to the M simulated nodes is obtained, a target construction instruction associated with the target network topology is generated.

[0111] The target construction instruction is used to instruct M simulated nodes to construct a target network topology associated with the blockchain network, where M is a positive integer. These M simulated nodes can include simulated node N. i ; i is a positive integer less than or equal to M. Specifically, after obtaining the node information corresponding to each of the M simulated nodes, the test node can obtain a set of network topologies associated with the blockchain network. This set of network topologies includes X types; X is a positive integer. For example, these X types of topologies may include bus topologies, star topologies, ring topologies, tree topologies, hybrid topologies, and isolated topologies (also known as partitioned topologies). Further, the test node can determine the target topology type to be simulated from the X types of topologies, and then, based on the target topology type and the M simulated nodes, determine the simulated node N. i The corresponding node connection relationships. It can be understood that, upon obtaining the node connection relationships corresponding to each of the M simulated nodes, the test node can generate construction instructions that conform to the target topology type based on the node information corresponding to each of the M simulated nodes and the M node connection relationships. The generated construction instructions will then be used as the target construction instructions associated with the target network topology.

[0112] For example, the node information corresponding to each node may include node address identifier (e.g., IP address), port information (e.g., port), and network card information. In this embodiment, six simulated nodes can be used as an example, meaning the node information obtained by the test node may specifically include node information X1, node information X2, node information X3, node information X4, node information X5, and node information X6. Node information X1 refers to the node information corresponding to node N1, for example, "{'ip':'1.1.1.1','port':'20020'}". Node information X2 refers to the node information corresponding to node N2, for example, "{'ip':'2.2.2.2','port':'20020'}". Node information X3 refers to the node information corresponding to node N3, for example, "{'ip':'3.3.3.3','port':'20020'}". Node information X4 refers to the node information corresponding to node N4, for example, "{'ip':'4.4.4.4','port':'20020'}". Node information X5 refers to the node information corresponding to node N5, for example, "{'ip':'5.5.5.5','port':'20020'}". Node information X6 refers to the node information corresponding to node N6, for example, "{'ip':'6.6.6.6','port':'20020'}".

[0113] It is understandable that, during the generation of target construction instructions, the test node needs to determine the node connection relationships corresponding to each of the M simulated nodes. For example, for simulated node N... i Specifically, the test node needs to be determined from M simulated nodes based on the target topology type, and its relationship with simulated node N needs to be established. i The simulated nodes that have connections can then be identified as simulated node N. i The corresponding first type of node. At the same time, this test node can also determine the node corresponding to simulation node N from M simulation nodes based on the target topology type. i Simulation nodes that do not have connections can be identified as simulation node N. i The corresponding second type of node. Furthermore, this test node can be based on the simulated node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0114] If the target topology type determined by the test node is a star topology, then the test node needs to obtain the simulated node N. iThe node type in the star topology is used to determine the simulated node N. i The node connection relationship.

[0115] For example, if the simulated node N i If a simulated node is the central node in a star topology, then this simulated node can generate all of the M simulated nodes except for simulated node N. i All other simulation nodes are designated as simulation node N. i The corresponding first type of node, where the first type of node refers to the node that is related to the simulation node N. i Simulated nodes that are connected. In other words, excluding simulated node N. i Of the (M-1) simulation nodes, each simulation node is connected to simulation node N. i Establish a connection (e.g., a TCP connection). At this point, the test node can be based on the simulated node N. i The corresponding first type of node yields the simulated node N. i The corresponding node connection relationships.

[0116] Optionally, if the simulated node N i It belongs to the non-central node in the star topology type, and the central node in the star topology type is simulation node N out of M simulation nodes. j Then the test node can simulate node N. j N is determined to be a simulation node. i The corresponding first type of node; j is a positive integer less than or equal to M, and j is not equal to i. Meanwhile, this test node can select from M simulated nodes excluding simulated node N. j All other simulation nodes are designated as simulation node N. i The corresponding second type of node, where the second type of node refers to the node related to the simulation node N. i Simulated nodes that are not connected. In other words, except for simulated node N. i Of the (M-1) simulation nodes other than simulation node N, there exist nodes that are related to simulation node N. i The simulated node that establishes a connection (e.g., a TCP connection) also exists with simulated node N. i A simulated node with no established connection (e.g., a TCP connection). In this case, the test node can be based on simulated node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0117] Further, please refer to Table 1, which is a pseudocode illustration of instructions for generating a star topology provided in an embodiment of this application. When the simulated nodes include nodes N1, N2, N3, N4, N5, and N6, the test node can determine node N4 as the central node in the star topology type, and then generate instructions for constructing the star topology based on the node connection relationships of these six simulated nodes (e.g., ...). Figure 1b The target construction instructions for the network topology 1000J2 shown are as follows: (See Table 1).

[0118] Table 1

[0119]

[0120]

[0121] For node N4, since node N4 is the central node in the star topology, the test node can identify all other simulated nodes besides node N4 as the first type of node corresponding to node N4. Specifically, this can include nodes N1, N2, N3, N5, and N6. At this time, the test node can determine that the node connection relationship corresponding to node N4 means that node N4 has a connection relationship with each of the simulated nodes in the first type of node. Furthermore, the test node can generate a sub-instruction associated with node N4 based on the node information of these 6 simulated nodes and the node connection relationship corresponding to node N4. That is, a sub-instruction used to establish a TCP connection with the first type of node.

[0122] For nodes N1, N2, N3, N5, and N6, these five simulated nodes are all non-central nodes in a star topology. Therefore, the specific method for determining the node connection relationships corresponding to these five simulated nodes is the same. Taking node N1 as an example, the test node can identify the central node (i.e., node N4) as a first-type node of node N1. At the same time, the test node can identify all other simulated nodes except node N4 as second-type nodes corresponding to node N4, specifically including nodes N2, N3, N5, and N6. In this case, the test node can determine that the node connection relationship corresponding to node N1 is that node N1 has a connection relationship with node N4, but no connection relationship with any of the simulated nodes in the second type. Furthermore, based on the node information of these six simulated nodes and the node connection relationship corresponding to node N1, the test node can generate sub-instructions associated with node N1, namely, sub-instructions for establishing TCP connections with first-type nodes and sub-instructions for establishing REJECT interrupts with second-type nodes.

[0123] Upon receiving the sub-instructions associated with node N1, node N2, node N3, node N4, node N5, and node N6, the test node can generate construction instructions that conform to the star topology type and use the generated construction instructions as the target construction instructions associated with the star topology.

[0124] If the target topology type determined by the test node is a ring topology, then the test node can be based on the ring topology type and the simulated node N. i Determine simulation node N from M simulation nodes. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships. Simultaneously, this test node can also use other simulated nodes from the M simulated nodes (excluding the first type of nodes) as simulated nodes N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected. Furthermore, this test node can be based on simulated node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0125] Since a ring topology can include a first node, intermediate nodes, and a tail node, when determining the first type of node for each simulated node, this test node needs to first determine these three types of nodes from the M simulated nodes. For example, the first node here can be simulated node N1 from the M simulated nodes; the tail node can be simulated node N from the M simulated nodes. M The intermediate nodes are the other simulated nodes among the M simulated nodes, excluding the first and last nodes.

[0126] Based on this, if the simulated node N i If it belongs to the first node, then this test node can connect simulation node N2 and simulation node N among the M simulation nodes. M All were determined to be simulated nodes N. i The corresponding first type of node. Optionally, if the simulated node N i If it belongs to the tail node, then this test node can connect simulation node N1 and simulation node N out of the M simulation nodes. M-1 All were determined to be simulated nodes N. i The corresponding first type of node. Optionally, if the simulated node N i If it is an intermediate node, then this test node can simulate node N out of M simulated nodes.i-1 and simulated node N i+1 All were determined to be simulated nodes N. i The corresponding first type of node.

[0127] Further, please refer to Table 2, which is a pseudocode illustration of instructions for generating a ring topology provided in an embodiment of this application. When the simulated nodes include nodes N1, N2, N3, N4, N5, and N6, the test node can determine node N1 as the first node in the ring topology type, node N6 as the tail node, and the other nodes besides the first and tail nodes as intermediate nodes. Then, based on the node connection relationships of these six simulated nodes, it generates instructions for constructing a ring topology (e.g., ...). Figure 1b The target construction instructions for the network topology 1000J3 shown are as follows: (See Table 2).

[0128] Table 2

[0129]

[0130] In this context, for node N1, since it is the first node in the ring topology, the test node can identify nodes N2 and N6 as first-type nodes corresponding to node N1, and the other simulated nodes besides the first-type nodes as second-type nodes corresponding to node N1, namely nodes N3, N4, and N5. At this point, the test node can determine that the node connection relationship corresponding to node N1 means that node N1 has a connection relationship with each simulated node in the first-type node group, but not with any simulated node in the second-type node group. Furthermore, based on the node information of these six simulated nodes and the node connection relationship corresponding to node N1, the test node can generate sub-instructions associated with node N1, namely, sub-instructions for establishing TCP connections with first-type nodes and sub-instructions for establishing REJECT interrupts with second-type nodes.

[0131] For nodes N2, N3, N4, and N5, these four simulated nodes are all intermediate nodes in a ring topology. Therefore, the specific methods for determining the node connection relationships corresponding to these four simulated nodes are the same. For ease of understanding, this embodiment takes node N2 as an example. The test node can determine nodes N1 and N3 as first-type nodes corresponding to node N2, and the other simulated nodes besides the first-type nodes as second-type nodes corresponding to node N2, namely nodes N4, N5, and N6. At this time, the test node can determine that the node connection relationship corresponding to node N2 means that node N2 has a connection relationship with each simulated node in the first-type nodes, but no connection relationship with each simulated node in the second-type nodes. Further, the test node can generate sub-instructions associated with node N2 based on the node information of these six simulated nodes and the node connection relationship corresponding to node N2, namely, sub-instructions for establishing TCP connections with first-type nodes and sub-instructions for establishing REJECT interrupts with second-type nodes.

[0132] For node N6, since it is the tail node in the ring topology, the test node can identify nodes N1 and N5 as the first type of nodes corresponding to node N6, and the other simulated nodes besides the first type as the second type of nodes corresponding to node N6, namely nodes N2, N3, and N4. At this point, the test node can determine that the node connection relationship corresponding to node N6 means that node N6 has a connection relationship with each simulated node in the first type, but not with any of the simulated nodes in the second type. Furthermore, based on the node information of these six simulated nodes and the node connection relationship corresponding to node N6, the test node can generate sub-instructions associated with node N6, namely, sub-instructions for establishing TCP connections with the first type of nodes and sub-instructions for establishing REJECT interrupts with the second type of nodes.

[0133] Upon receiving the sub-instructions associated with node N1, node N2, node N3, node N4, node N5, and node N6, the test node can generate construction instructions that conform to the ring topology type and use the generated construction instructions as the target construction instructions associated with the ring topology.

[0134] If the target topology type determined by the test node is a partitioned topology type, then the test node can be based on the partitioned topology type and the simulated node N. i Determine simulation node N from M simulation nodes. iThe corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships. Simultaneously, this test node can also use other simulated nodes from the M simulated nodes (excluding the first type of nodes) as simulated nodes N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected. Furthermore, this test node can be based on simulated node N. i The corresponding first type of node and simulation node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0135] Since a partitioned topology can include multiple subnetworks, we can take two subnetworks as an example, specifically a first subnetwork and a second subnetwork. In this case, when determining the node connections for each simulated node, the test node needs to first determine the simulated node N from the M simulated nodes. i The subnetwork to which it belongs. For example, the first subnetwork can be constructed by M1 simulated nodes, and the second subnetwork can be constructed by M2 simulated nodes, where M1 and M2 are both positive integers, and the sum of M1 and M2 is M.

[0136] Based on this, if the simulated node N i If a test node belongs to the first subnetwork, then this test node can identify all other simulated nodes belonging to the first subnetwork out of the M simulated nodes as simulated node N. i The corresponding first type of node, and all other simulated nodes belonging to the second sub-network among the M simulated nodes are determined as second type nodes, and then based on the simulated node N i The corresponding first type of node, and the simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0137] Further, please refer to Table 3, which is a pseudocode illustration of instructions for generating a partitioned topology provided in an embodiment of this application. When the simulated nodes include nodes N1, N2, N3, N4, N5, and N6, the test node can determine nodes N1, N2, and N3 as simulated nodes for forming the first sub-network in the partitioned topology type, and nodes N4, N5, and N6 as simulated nodes for forming the second sub-network in the partitioned topology type. Then, based on the node connection relationships of these six simulated nodes, it generates instructions for constructing the partitioned topology (e.g., ...). Figure 1bThe target construction instructions for the network topology 1000J7 shown are as follows: (See Table 3).

[0138] Table 3

[0139]

[0140]

[0141] For any simulated node, such as node N1, since node N1 belongs to the first sub-network in the partitioned topology, the test node can identify all simulated nodes in the first sub-network other than node N1 as first-type nodes corresponding to node N1, namely nodes N2 and N3. The simulated nodes in the second sub-network are all identified as second-type nodes corresponding to node N1, namely nodes N4, N5, and N6. In this case, the test node can determine that the node connection relationship corresponding to node N1 means that node N1 has a connection relationship with each simulated node in the first-type nodes, but not with any of the simulated nodes in the second-type nodes. Furthermore, based on the node information of these six simulated nodes and the node connection relationship corresponding to node N1, the test node can generate a sub-instruction associated with node N1, namely a sub-instruction used to establish a REJECT interrupt with the second-type nodes.

[0142] Upon receiving the sub-instructions associated with node N1, node N2, node N3, node N4, node N5, and node N6, the test node can generate construction instructions that conform to the partitioned topology type and use the generated construction instructions as the target construction instructions associated with the partitioned topology.

[0143] Of course, the target construction instructions generated by the test node may also include construction instructions that conform to the bus topology type, construction instructions that conform to the tree topology type, and construction instructions that conform to the hybrid topology type. Examples will not be given here.

[0144] Step S102: Obtain the first simulated execution result after executing the blockchain business in the target network topology.

[0145] Specifically, the test node can distribute the generated target construction instructions to the corresponding simulated nodes according to the instruction execution strategy, so that M simulated nodes can execute the target construction instructions to construct the target network topology. The instruction execution strategy can include a timed generation strategy or a one-time generation strategy. A timed strategy means that the M simulated nodes quickly generate the target network topology according to configured time points, while a one-time generation strategy means that the M simulated nodes directly generate the target network topology upon receiving the target construction instructions. Further, the M simulated nodes can trigger the execution of normal use cases on the blockchain automation platform, that is, execute blockchain business within the target network topology to obtain the first simulated execution result. The normal use cases can include simulated consensus use cases and simulated interface use cases. For example, the simulated interface use cases could refer to simulated transaction on-chain, transaction query, and contract deployment use cases. This means that blockchain business can include sub-businesses for consensus on information to be verified, sub-businesses for on-chain transactions, sub-businesses for querying transactions, and sub-businesses for contract deployment, etc. It is understood that the first simulated execution result can include execution failure or execution success results. An execution failure result refers to a simulated execution result indicating failure after executing a blockchain business in the current network topology, while an execution success result refers to a simulated execution result indicating success after executing a blockchain business in the current network topology.

[0146] The target network topology corresponds to a blockchain network that can include ledger nodes (also called block-producing nodes or leader nodes). During each packaging cycle in the blockchain, these ledger nodes package a list of transactions into a block structure and broadcast it to other nodes for consensus. Ledger nodes are those that generate blocks and initiate proposals. A proposal occurs at the beginning of the blockchain's lifecycle when a ledger node scans its transaction pool. If the transaction pool list is not empty, a block proposal is generated. The proposal message can include the block height, block header, Merkle root, transaction information, etc. The proposal message is then broadcast to other nodes for consensus.

[0147] It is understandable that if the test node (e.g., Figure 1aNode 10A shown belongs to M simulated nodes, and this test node is a ledger node in the target network topology. Therefore, this test node can trigger a simulated consensus use case on the blockchain automation platform. This involves executing blockchain business within the target network topology and broadcasting the information to be verified to (M-1) other simulated nodes besides the test node. This allows the (M-1) simulated nodes to reach a consensus on the received information and obtain a consensus result. The information to be verified can be a block to be written to the blockchain obtained by the test node, or a transaction sent by a client to be verified; these are not limited here. At this time, the test node can receive the consensus results returned by the (M-1) simulated nodes and then analyze the received consensus results.

[0148] For example, if among the consensus results returned by (M-1) simulated nodes, more than a consensus threshold (e.g., 2 / 3) indicates successful consensus, then the test node can determine that the simulated nodes in the blockchain network corresponding to the target network topology have reached a consensus, and thus obtain a first simulated execution result indicating successful execution. Optionally, if none of the consensus results returned by (M-1) simulated nodes exceed the consensus threshold indicating successful consensus, then the test node can determine that the simulated nodes in the blockchain network corresponding to the target network topology have not reached a consensus, and thus obtain a first simulated execution result indicating failed execution.

[0149] Optionally, if the test node (e.g., Figure 2 If the test node shown is a computer device independent of the blockchain network, then in this embodiment of the application, any one of the M simulated nodes can be selected (e.g., Figure 2 In the network topology 200J shown, node N1 acts as a ledger node to trigger simulated consensus use cases on the blockchain automation platform. Specifically, node N1 can execute blockchain transactions within the target network topology, broadcasting the information to be verified to three simulated nodes (excluding the test node) to achieve consensus. Upon receiving the consensus results from the three simulated nodes, node N1 can analyze them to obtain a first simulated execution result compared to the result obtained from executing blockchain transactions on network topology 200J. This first simulated execution result can then be returned to the test node.

[0150] Step S103: Based on the path offset corresponding to the target network topology, generate the target transfer instruction corresponding to the target network topology.

[0151] The target transfer instruction is used to instruct M simulated nodes to switch from the target network topology to a heterogeneous network topology. Specifically, the test node can obtain test accuracy parameters associated with the target network topology, and then determine the path offset corresponding to the target network topology based on the test accuracy parameters. Here, the path offset is determined based on the total number of paths corresponding to the target network topology. Further, the test node can dynamically transfer the target network topology based on the path offset to obtain the corresponding heterogeneous topology. Then, based on the heterogeneous topology and the M simulated nodes, it can redetermine the node connection relationships corresponding to the M simulated nodes, and based on the redetermined node connection relationships, generate a construction instruction for constructing the heterogeneous topology. This generated construction instruction serves as the target transfer instruction corresponding to the target network topology.

[0152] Here, the test precision parameter can be used to characterize the degree of dynamic transition between the network topologies to be tested. For example, the test precision parameter can include a first test precision parameter and a second test precision parameter, with the first test precision parameter being higher than the second test precision parameter. That is, when the test node obtains the first test precision parameter, the path offset determined by the test node can be H1 (H1 is a positive integer), such as a path offset with a value of 1, a path offset with a value of 2, and a path offset with a value of 3, etc. When the test node obtains the second test precision parameter, the path offset determined by the test node can be H2 (H2 is a positive integer less than H1), such as a path offset with a value of 1.

[0153] For better understanding, please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario for determining a heterogeneous network topology, as provided in an embodiment of this application. Figure 4 As shown, the number of simulated nodes in this embodiment can be 4. It should be understood that the network topology of the blockchain network composed of 4 simulated nodes can include the following 11 types, specifically including network topology 401J, network topology 402J, network topology 403J, ..., and network topology 411J. Among them, network topology 407J can be the target network topology constructed by the test node when it obtains the node information corresponding to the 4 simulated nodes.

[0154] It should be understood that if the path offset value determined by the test node is 1, the test node needs to dynamically transfer the target network topology, that is, offset the path based on network topology 407J to obtain the heterogeneous network topology corresponding to network topology 407J. For example... Figure 4As shown, the heterogeneous network topology determined by this test node may include... Figure 4 The network topologies shown are 403J, 405J, and 406J. This means that when the path offset value of the test node is 1, the node connection relationships of these four simulated nodes in these three heterogeneous network topologies can be redefined to generate three target transfer commands. Specifically, these commands can include a target transfer command for switching from network topology 407J to network topology 403J, a target transfer command for switching from network topology 407J to network topology 405J, and a target transfer command for switching from network topology 407J to network topology 406J.

[0155] For better understanding, please refer to [link / reference]. Figure 5 , Figure 5 This is a schematic diagram illustrating another scenario for determining the heterogeneous network topology provided in an embodiment of this application. For example... Figure 5 As shown, the number of simulated nodes in this embodiment can be 4. It should be understood that the network topology of the blockchain network composed of 4 simulated nodes can include the following 11 types, specifically including network topology 501J, network topology 502J, network topology 503J, ..., and network topology 511J. Among them, network topology 507J can be the target network topology constructed by the test node when it obtains the node information corresponding to the 4 simulated nodes.

[0156] It should be understood that if the path offset value determined by the test node is 2, the test node needs to dynamically transfer the target network topology, that is, offset the network topology 507J by two paths to obtain the heterogeneous network topology corresponding to network topology 507J. For example... Figure 5 As shown, the heterogeneous network topology determined by this test node may include... Figure 5The network topologies shown are 502J, 504J, 508J, 509J, and 510J. This means that when the path offset value of the test node is 2, the node connection relationships of these four simulated nodes in these five heterogeneous network topologies can be redefined to generate five target transfer commands. Specifically, these commands can include those for switching from network topology 507J to network topology 502J, from network topology 507J to network topology 504J, from network topology 507J to network topology 508J, from network topology 507J to network topology 509J, and from network topology 507J to network topology 510J.

[0157] Understandably, this test node can simulate various heterogeneous network topologies formed by connecting the target network topology after it has shifted by one, two, ..., multiple paths based on the path offset. It can automatically issue corresponding target transfer instructions to M simulated nodes so that the M simulated nodes can execute each target transfer instruction to quickly construct the corresponding heterogeneous network topology.

[0158] Step S104: Obtain the second simulated execution result after executing blockchain business in a heterogeneous network topology.

[0159] Specifically, M simulated nodes can trigger the execution of normal use cases on the blockchain automation platform, that is, execute blockchain business in a heterogeneous network topology to obtain a second simulated execution result. The specific implementation method for the test node to obtain the second simulated execution result can be found in the specific implementation method for obtaining the first simulated execution result in step S102 above, and will not be repeated here.

[0160] Step S105: Based on the first simulation execution result and the second simulation execution result, determine the consensus state of the target network topology and the heterogeneous network topology, respectively.

[0161] Specifically, the test node can determine either the first or second simulated execution result as the business simulation execution result, and determine the network topology corresponding to the business simulation execution result as the business network topology. Here, the business network topology can include the target network topology and heterogeneous network topologies. Further, the test node can analyze the consensus state of the business network topology. For example, if the business simulation execution result indicates execution failure, the test node can determine the consensus state of the business network topology as the first consensus state (i.e., the business state indicating that the business network topology does not meet BFT consensus), at which point it can be determined that the business network topology does not meet the consensus conditions. Optionally, if the business simulation execution result indicates execution success, the test node can determine the consensus state of the business network topology as the second consensus state (i.e., the business state indicating that the business network topology can meet BFT consensus), a consensus failure state, at which point it can be determined that the business network topology meets the consensus conditions. Here, the consensus state reflects the stability of the consensus layer of the blockchain network.

[0162] Therefore, the testing method provided in this application requires no manual intervention, automating the entire testing process, thus greatly reducing testing costs and improving testing efficiency. Furthermore, this testing method considers the dynamic characteristics of network topology when evaluating the impact on the consensus layer, thereby improving testing accuracy.

[0163] Further, please see Figure 6 , Figure 6 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 6 As shown, this method can be executed by a test node and M simulated nodes. The test node can be a computer device independent of the blockchain network, such as a terminal device or a server. Specifically, the M simulated nodes can include node N1, node N2, ..., node N... M Each simulated node can record a runtime log to document various important information during node operation. This method may include at least the following steps S201-S212:

[0164] Step S201: When the test node obtains the node information corresponding to each of the M simulated nodes, it generates a target construction instruction associated with the target network topology.

[0165] In step S202, the test node sends the target construction instructions to M simulation nodes respectively.

[0166] In step S203, each of the M simulated nodes executes the target construction instruction to construct the target network topology.

[0167] Step S204: M simulated nodes execute blockchain transactions in the target network topology to obtain the first simulated execution result.

[0168] Step S205: The test node obtains the first simulation execution result returned by the M simulation nodes.

[0169] Step S206: The test node generates a target transfer instruction corresponding to the target network topology based on the path offset corresponding to the target network topology.

[0170] In step S207, the test node sends the target transfer command to each of the M simulated nodes.

[0171] In step S208, each of the M simulated nodes executes the target transfer instruction to switch the target network topology to a heterogeneous network topology.

[0172] Step S209: M simulated nodes execute blockchain transactions in a heterogeneous network topology to obtain the second simulated execution result.

[0173] Step S210: The test node obtains the second simulation execution result returned by the M simulation nodes.

[0174] Step S211: Based on the first simulation execution result and the second simulation execution result, the test node determines the consensus state of the target network topology and the heterogeneous network topology, respectively.

[0175] The specific implementation methods for steps S201-S211 can be found above. Figure 3 The descriptions of steps S101-S105 in the corresponding embodiments will not be repeated here.

[0176] Step S212: The test node generates a test report for testing the consensus layer of the blockchain network based on the consensus state of each network topology.

[0177] Specifically, the test node can count the first number of network topologies that meet the consensus conditions and the second number of network topologies that do not meet the consensus conditions from the consensus states of the target network topology and the heterogeneous network topologies. Based on these first and second counts, it can determine the stability of the target network topology for the consensus layer in the blockchain network. Furthermore, based on the stability of each network topology in the set for the consensus layer in the blockchain network, the test node can generate a test report (which can be used to analyze the impact of P2P network topologies on the consensus mechanism) to test the consensus layer of the blockchain network, and display the test report on the test node corresponding to the test object.

[0178] Understandably, the test node can determine the ratio between the first and second quantities. The larger the ratio, the greater the stability of the consensus layer in the blockchain network corresponding to the current target network topology, even when considering the dynamic transfer between topologies.

[0179] It should be understood that when the test node determines the first or second simulation execution result as the business simulation execution result and the network topology corresponding to the business simulation execution result as the business network topology, the test node can analyze the business simulation execution result to determine the operating status of the blockchain network.

[0180] If the business simulation execution result indicates successful execution, the test node can determine that the operating status of the blockchain network corresponding to the current business network topology is set to "open". Optionally, if the business simulation execution result indicates failure, the test node can set the operating status of the blockchain network corresponding to the business network topology to "blocked". Understandably, when the blockchain network is in a blocked state, the test node can obtain the error identifier code and error details indicating the execution failure. Based on the error identifier code and error details, it can then generate an exception message associated with the blockchain business and display the exception message on the test node corresponding to the test object.

[0181] For example, if the business network topology is as described above Figure 4Given network topologies 407J (a star topology consisting of 4 simulated nodes) or 404J (a partitioned topology consisting of 4 simulated nodes), the test node can determine that under these topologies, nodes cannot broadcast consensus messages. This means the topology cannot satisfy BFT consensus, specifically the condition that the number of normal nodes must be greater than 2 / 3 of the total number of nodes. Ultimately, this renders the entire blockchain network unusable, causing automated test cases to fail. In this case, the test node can set the blockchain network to a blocked state. The test node can then obtain error codes and error details indicating the failure, and based on these, generate exception messages related to the blockchain business.

[0182] For better understanding, please refer to [link / reference]. Figure 7 , Figure 7 This is a schematic diagram illustrating the overall process of testing a blockchain network topology, as provided in an embodiment of this application. Figure 7 As shown in the diagram, the process diagram can include three stages, specifically the first stage (i.e., the blockchain product testing stage), the second stage (i.e., the network topology testing stage), and the third stage (i.e., the release stage).

[0183] It should be understood that during the blockchain product testing phase, this embodiment of the application can execute step S71 to develop the blockchain product, and then execute step S72 to submit the P2P module to the management platform for testing. Here, the management platform can be a REQ platform, i.e., a software development testing process management platform, which manages the entire lifecycle of software version development, testing, defect submission, regression testing, and release. Further, this embodiment of the application can execute steps S73 and S74 to enable the management platform to distribute the product, and upon approval, initiate the testing process.

[0184] During the network topology testing phase, a test node with network topology testing capabilities can execute step S75. Upon obtaining node information corresponding to each of the M simulated nodes, this information is input into the intelligent network topology program. Step S76 then executes to automatically generate target construction instructions for various complex target network topologies such as star, tree, ring, and partition topologies. These instructions are then distributed to the corresponding simulated nodes according to the instruction execution strategy, enabling the M simulated nodes to execute the target construction instructions and construct the target network topology in seconds. The program also supports functions such as timed recycling and scenario construction. Furthermore, in this embodiment, the execution can proceed to step S78, causing the M simulated nodes to trigger the execution of automated test cases on the blockchain automation platform to obtain the first simulation execution result. Meanwhile, after executing step S76, the test node can also directly execute step S78, which is to generate a target transfer instruction corresponding to the target network topology based on the path offset of the target network topology, and send the target transfer instruction to the corresponding simulation node so that these M simulation nodes can gradually simulate the situation of switching from the target network topology to the heterogeneous network topology. Then, step S78 can be executed so that these M simulation nodes can trigger the execution of automated use cases on the blockchain automation platform to obtain the second simulation execution result.

[0185] During the release phase, the test node can execute step S79, analyzing the consensus state of each network topology based on the first and second simulation execution results to verify the antifragility of the consensus layer against various complex network topologies, thereby improving the availability and stability of the blockchain. Further, the test node can execute step S80 to generate a test report for testing the consensus layer of the blockchain network, facilitating problem identification by the test object. After the test object fixes the problems, step S81 can be executed to release and launch the developed blockchain product.

[0186] In this embodiment, when a test node with network topology testing capabilities receives node information (including IP address, port, network card information, etc.) corresponding to a simulated node during the testing phase, it can input this node information into an intelligent network topology program. This program automatically generates target construction instructions for constructing various network topologies and then distributes them in batches to M simulated nodes. These nodes automatically execute the target construction instructions, constructing the target network topology within seconds. Furthermore, the test node can gradually simulate the dynamic characteristics of the topology based on the path offset between topologies, significantly improving testing efficiency. Combined with automated test cases, it outputs the impact of various network topologies on the consensus mechanism. Based on this, this embodiment can cover the dynamic transfer characteristics of network topologies at low cost and high efficiency, achieving comprehensive blockchain topology testing.

[0187] Further, please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. Figure 8 As shown, the blockchain-based data processing device 1 can be a computer program (including program code) running on a computer device. For example, the blockchain-based data processing device 1 is an application software; the blockchain-based data processing device 1 can be used to execute the corresponding steps in the methods provided in the embodiments of this application. Figure 8 As shown, the blockchain-based data processing device 1 can run on a test node with network topology testing capabilities. The blockchain-based data processing device 1 may include: a construction instruction generation module 11, a first result acquisition module 12, a transfer instruction generation module 13, a second result acquisition module 14, a consensus state determination module 15, a business topology structure determination module 16, a state setting module 17, an error information acquisition module 18, an anomaly information display module 19, a quantity statistics module 20, a stability determination module 21, a test report generation module 22, and a test report display module 23.

[0188] The construction instruction generation module 11 is used to generate a target construction instruction associated with the target network topology when the node information corresponding to the M simulated nodes is obtained. The target construction instruction is used to instruct the M simulated nodes to construct a target network topology associated with the blockchain network. M is a positive integer.

[0189] Among them, M simulation nodes include simulation node N i ; i is a positive integer less than or equal to M;

[0190] The construction instruction generation module 11 includes: a type set acquisition unit 111, a target type determination unit 112, a connection relationship determination unit 113, and a construction instruction generation unit 114.

[0191] This type of set acquisition unit 111 is used to acquire a set of network topologies associated with the blockchain network after acquiring the node information corresponding to M simulated nodes; the set of network topologies includes X types of topologies; X is a positive integer;

[0192] The target type determination unit 112 is used to determine the target topology type to be simulated from X types of topology types;

[0193] The connection determination unit 113 is used to determine the simulation node N based on the target topology type and M simulation nodes. i The corresponding node connection relationships.

[0194] The connection relationship determination unit 113 includes: a first determination subunit 11301, a second determination subunit 11302, a first relationship determination subunit 11303, a third determination subunit 11304, a second relationship determination subunit 11305, a fourth determination subunit 11306, a fifth determination subunit 11307, a third relationship determination subunit 11308, a sixth determination subunit 11309, a seventh determination subunit 11310, and a fourth relationship determination subunit 11311.

[0195] The first determining subunit 11301 is used to determine, based on the target topology type, the relationship between simulation node N and M simulation nodes from M simulation nodes. i The simulated nodes with connections are designated as simulated node N. i The corresponding first type of node;

[0196] The second determining subunit 11302 is used to determine, based on the target topology type, the relationship between simulation node N and M from M simulation nodes. i Simulation nodes that do not have a connection relationship will be identified as simulation node N. i The corresponding second type of node;

[0197] This first relationship determines subunit 11303, used for simulation node N. i The corresponding first type of node and simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0198] Among them, the target topology type includes star topology type;

[0199] The third determining subunit 11304 is used if the simulation node N i If the central node belongs to the star topology type, then the M simulated nodes excluding simulated node N will be selected. i All other simulation nodes are designated as simulation node N. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships;

[0200] This second relationship determines subunit 11305, used for simulation node N. i The corresponding first type of node yields the simulated node N. i The corresponding node connection relationships.

[0201] The fourth determining subunit 11306 is used if the simulation node N iIt belongs to the non-central node in the star topology type, and the central node in the star topology type is simulation node N out of M simulation nodes. j Then simulate node N j N is determined to be a simulation node. i The corresponding first type node; j is a positive integer less than or equal to M, and j is not equal to i;

[0202] The fifth determining subunit 11307 is used to determine the number of simulation nodes excluding simulation node N from the M simulation nodes. j All other simulation nodes are designated as simulation node N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected;

[0203] This third relationship determines subunit 11308, used for simulation node N. i The corresponding first type of node and simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0204] Among them, the target topology type includes the ring topology type;

[0205] The sixth determining subunit 11309 is used to determine the ring topology type and the simulated node N. i Determine simulation node N from M simulation nodes. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships.

[0206] The ring-shaped topology includes a first node, intermediate nodes, and a tail node; the first node is simulation node N1 out of the M simulation nodes; the tail node is simulation node N out of the M simulation nodes. M The intermediate nodes are the other simulated nodes among the M simulated nodes, excluding the first and last nodes.

[0207] The sixth determining subunit 11309 is also used for:

[0208] If the simulated node N i If it belongs to the first node, then simulated node N2 and simulated node N from the M simulated nodes. M All were determined to be simulated nodes N. i The corresponding first type of node;

[0209] If the simulated node N i If it belongs to the tail node, then simulated node N1 and simulated node N out of the M simulated nodes will be... M-1All were determined to be simulated nodes N. i The corresponding first type of node;

[0210] If the simulated node N i If it belongs to an intermediate node, then simulate node N out of the M simulated nodes. i-1 and simulated node N i+1 All were determined to be simulated nodes N. i The corresponding first type of node.

[0211] The seventh determining subunit 11310 is used to identify the other simulation nodes among the M simulation nodes, excluding the first type of nodes, as simulation nodes N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected;

[0212] This fourth relation determines subunit 11311, used for simulation node N. i The corresponding first type of node and simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

[0213] The specific implementation methods of the first determining subunit 11301, the second determining subunit 11302, the first relation determining subunit 11303, the third determining subunit 11304, the second relation determining subunit 11305, the fourth determining subunit 11306, the fifth determining subunit 11307, the third relation determining subunit 11308, the sixth determining subunit 11309, the seventh determining subunit 11310, and the fourth relation determining subunit 11311 can be found above. Figure 3 The description of the node connection relationship in the corresponding embodiments will not be repeated here.

[0214] The construction instruction generation unit 114 is used to generate a construction instruction that conforms to the target topology type based on the node information corresponding to the M simulated nodes and the M node connection relationships when the node connection relationships corresponding to the M simulated nodes are obtained respectively, and to use the generated construction instruction as the target construction instruction associated with the target network topology.

[0215] The specific implementation methods of the type set acquisition unit 111, target type determination unit 112, connection relationship determination unit 113, and construction instruction generation unit 114 can be found above. Figure 3 The description of step S101 in the corresponding embodiments will not be repeated here.

[0216] The first result acquisition module 12 is used to acquire the first simulated execution result obtained after executing blockchain business in the target network topology.

[0217] The method is executed by a test node; the test node consists of M simulated nodes; the blockchain business includes a sub-business for reaching consensus on the information to be verified.

[0218] The first result acquisition module 12 includes: an information broadcasting unit 121, a success result determination unit 122, and a failure result determination unit 123.

[0219] The information broadcasting unit 121 is used to execute blockchain business in the target network topology, broadcasting the information to be verified to (M-1) simulated nodes so that the (M-1) simulated nodes can reach a consensus on the information to be verified and obtain a consensus result.

[0220] The success result determination unit 122 is used to determine that the simulated nodes in the blockchain network corresponding to the target network topology have reached a consensus if there is a consensus result that exceeds the consensus threshold among the consensus results returned by (M-1) simulated nodes, indicating that the consensus is successful, and to obtain the first simulated execution result used to indicate the execution success.

[0221] The failure result determination unit 123 is used to determine that the simulated nodes in the blockchain network corresponding to the target network topology have not reached a consensus if there is no consensus result exceeding the consensus threshold among the consensus results returned by (M-1) simulated nodes, thus obtaining the first simulated execution result indicating execution failure.

[0222] The specific implementation methods of the information broadcasting unit 121, the success result determination unit 122, and the failure result determination unit 123 can be found in the above description. Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0223] The transfer instruction generation module 13 is used to generate a target transfer instruction corresponding to the target network topology based on the path offset of the target network topology; the target transfer instruction is used to instruct M simulated nodes to switch from the target network topology to the heterogeneous network topology.

[0224] The transfer instruction generation module 13 includes: a path offset determination unit 131, a dynamic transfer unit 132, a connection relationship redeter unit 133, and a transfer instruction generation unit 134.

[0225] The path offset determination unit 131 is used to acquire test accuracy parameters associated with the target network topology, and determine the path offset corresponding to the target network topology based on the test accuracy parameters; the path offset is determined based on the total number of paths corresponding to the target network topology.

[0226] The dynamic transfer unit 132 is used to dynamically transfer the target network topology based on the path offset to obtain the heterogeneous topology corresponding to the target network topology.

[0227] The connection relationship redefinition unit 133 is used to redefine the node connection relationship corresponding to the M simulation nodes based on the heterogeneous topology and the M simulation nodes.

[0228] The transfer instruction generation unit 134 is used to generate a construction instruction for constructing a heterogeneous topology based on the redefined connection relationship of M nodes, and to use the generated construction instruction as the target transfer instruction corresponding to the target network topology.

[0229] The specific implementation methods of the path offset determination unit 131, dynamic transfer unit 132, connection relationship re-determination unit 133, and transfer instruction generation unit 134 can be found above. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0230] The second result acquisition module 14 is used to acquire the second simulated execution result obtained after executing blockchain business in a heterogeneous network topology;

[0231] The consensus state determination module 15 is used to determine the consensus state of the target network topology and the heterogeneous network topology based on the first simulation execution result and the second simulation execution result, respectively; the consensus state is used to reflect the stability of the consensus layer of the blockchain network.

[0232] The service topology determination module 16 is used to determine the first simulation execution result or the second simulation execution result as the service simulation execution result, and to determine the network topology corresponding to the service simulation execution result as the service network topology; the service network topology includes the target network topology and the heterogeneous network topology;

[0233] The state setting module 17 is used to set the running state of the blockchain network corresponding to the business network topology to a blocked state if the business simulation execution result indicates that the execution has failed.

[0234] The error information acquisition module 18 is used to acquire error identification codes and error details that indicate execution failure when the blockchain network is in a blocked state.

[0235] The exception information display module 19 is used to generate exception prompt information related to the blockchain business based on the error identification code and error details, and display the exception prompt information on the test node corresponding to the test object.

[0236] The quantity statistics module 20 is used to count the first number of the first network topology that has consensus conditions and the second number of the second network topology that does not have consensus conditions from the consensus state of the target network topology and the consensus state of the heterogeneous network topology, respectively.

[0237] The stability determination module 21 is used to determine the stability of the target network topology to the consensus layer in the blockchain network based on a first quantity and a second quantity.

[0238] The test report generation module 22 is used to generate a test report for testing the consensus layer of the blockchain network based on the stability of the consensus layer in the blockchain network for each network topology in the set of network topologies.

[0239] The test report display module 23 is used to display the test report on the test node corresponding to the test object.

[0240] The specific implementation methods of the following modules can be found above: the construction instruction generation module 11, the first result acquisition module 12, the transfer instruction generation module 13, the second result acquisition module 14, the consensus state determination module 15, the business topology structure determination module 16, the state setting module 17, the error information acquisition module 18, the exception information display module 19, the quantity statistics module 20, the stability determination module 21, the test report generation module 22, and the test report display module 23. Figure 6 The descriptions of steps S201-S212 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0241] Further, please see Figure 9 , Figure 9 This is a schematic diagram of a computer device provided in an embodiment of this application. Figure 9As shown, the computer device 1000 can be the aforementioned test node with network topology testing function. The computer device 1000 may include: at least one processor 1001, such as a CPU; at least one network interface 1004; a user interface 1003; a memory 1005; and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may include a display screen and a keyboard. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 9 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0242] exist Figure 9 In the computer device 1000 shown, the network interface 1004 is mainly used for network communication with the simulated node; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0243] Upon obtaining the node information corresponding to each of the M simulated nodes, a target construction instruction associated with the target network topology is generated. The target construction instruction is used to instruct the M simulated nodes to construct the target network topology associated with the blockchain network; M is a positive integer.

[0244] Obtain the first simulated execution result after executing blockchain business in the target network topology;

[0245] Based on the path offset corresponding to the target network topology, a target transfer instruction corresponding to the target network topology is generated; the target transfer instruction is used to instruct M simulated nodes to switch from the target network topology to the heterogeneous network topology.

[0246] Obtain the second simulated execution result after executing blockchain business in a heterogeneous network topology;

[0247] Based on the results of the first and second simulations, the consensus states of the target network topology and the heterogeneous network topology are determined respectively; the consensus state is used to reflect the stability of the consensus layer of the blockchain network.

[0248] It should be understood that the computer device 1000 described in the embodiments of this application can perform the foregoing... Figure 3 and Figure 6 The description of the blockchain-based data processing method in the corresponding embodiments can also be performed as described above. Figure 8 The description of the blockchain-based data processing device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0249] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are implemented when executed by a processor. Figure 3 and Figure 6 For details on the blockchain-based data processing methods provided in each step, please refer to [link / reference]. Figure 3 as well as Figure 6 The implementation methods provided for each step will not be elaborated here.

[0250] The computer-readable storage medium can be an internal storage unit of the data transmission apparatus or computer device provided in any of the foregoing embodiments, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium may include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0251] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, enabling the computer device to perform the blockchain-based data processing methods or apparatus described in the preceding embodiments, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0252] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0253] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0254] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, include: When the node information corresponding to each of the M simulated nodes is obtained, a target construction instruction associated with the target network topology is generated. The target construction instruction is used to instruct the M simulated nodes to construct the target network topology associated with the blockchain network; M is a positive integer; Obtain the first simulated execution result after executing blockchain business in the target network topology; Obtain test accuracy parameters associated with the target network topology, and determine the path offset corresponding to the target network topology based on the test accuracy parameters; the path offset is determined based on the total number of paths corresponding to the target network topology; dynamically transfer the target network topology based on the path offset to obtain a heterogeneous network topology corresponding to the target network topology; based on the heterogeneous network topology and the M simulated nodes, redetermine the node connection relationships corresponding to the M simulated nodes respectively; Based on the redefined connection relationships of the M simulated nodes, a construction instruction for constructing the heterogeneous network topology is generated, and the generated construction instruction is used as the target transfer instruction corresponding to the target network topology. The target transfer instruction is used to instruct the M simulated nodes to switch from the target network topology to the heterogeneous network topology; Obtain the second simulated execution result after executing the blockchain business in the heterogeneous network topology; Based on the first simulation execution result and the second simulation execution result, the consensus state of the target network topology and the heterogeneous network topology is determined respectively. The consensus state is used to reflect the stability of the consensus layer of the blockchain network.

2. The method according to claim 1, characterized in that, The M simulation nodes include simulation node N. i ; i is a positive integer less than or equal to M; When the node information corresponding to each of the M simulated nodes is obtained, a target construction instruction associated with the target network topology is generated, including: After obtaining the node information corresponding to M simulated nodes, a set of network topologies associated with the blockchain network is obtained; the set of network topologies includes X types of topologies; X is a positive integer. Determine the target topology type to be simulated from the X types of topology; Based on the target topology type and the M simulated nodes, determine the simulated node N. i The corresponding node connection relationship; When the node connection relationships corresponding to the M simulated nodes are obtained, a construction instruction that conforms to the target topology type is generated based on the node information corresponding to the M simulated nodes and the connection relationships of the M simulated nodes. The generated construction instruction is used as the target construction instruction associated with the target network topology.

3. The method according to claim 2, characterized in that, Based on the target topology type and the M simulated nodes, the simulated node N is determined. i The corresponding node connection relationships include: Based on the target topology type, determine the simulation node N from the M simulation nodes. i The simulated nodes with connection relationships are designated as the simulated node N. i The corresponding first type of node; Based on the target topology type, determine the simulation node N from the M simulation nodes. i Simulation nodes that do not have a connection relationship will be identified as simulation node N. i The corresponding second type of node; Based on the simulation node N i The corresponding first type of node and the simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

4. The method according to claim 2, characterized in that, The target topology type includes the star topology type; Based on the target topology type and the M simulated nodes, the simulated node N is determined. i The corresponding node connection relationships include: If the simulation node N i If the central node belongs to the star topology type, then the M simulated nodes excluding simulated node N will be selected. i All other simulation nodes besides N are identified as simulation node N. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships; Based on the simulation node N i The corresponding first type of node is used to obtain the simulated node N. i The corresponding node connection relationships.

5. The method according to claim 4, characterized in that, Based on the target topology type and the M simulated nodes, the simulated node N is determined. i The corresponding node connection relationships include: If the simulation node N i The non-central node belongs to the star topology type, and the central node of the star topology type is simulation node N among the M simulation nodes. j Then the simulated node N j The simulation node N was determined to be N. i The corresponding first type node; j is a positive integer less than or equal to M, and j is not equal to i; Of the M simulation nodes, excluding simulation node N... j All other simulation nodes besides N are identified as simulation node N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected; Based on the simulation node N i The corresponding first type of node and the simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

6. The method according to claim 2, characterized in that, The target topology type includes ring topology type; Based on the target topology type and the M simulated nodes, the simulated node N is determined. i The corresponding node connection relationships include: Based on the ring topology type and the simulated node N i The simulation node N is determined from the M simulation nodes. i The corresponding first type of node; the first type of node refers to the node corresponding to the simulation node N. i Simulated nodes with interconnected relationships; The simulation nodes other than the first type of nodes among the M simulation nodes are designated as simulation node N. i The corresponding second type of node; the second type of node refers to the node corresponding to the simulation node N. i Simulated nodes that are not connected; Based on the simulation node N i The corresponding first type of node and the simulated node N i The corresponding second type of node yields the simulated node N. i The corresponding node connection relationships.

7. The method according to claim 6, characterized in that, The ring-shaped topology type includes a first node, intermediate nodes, and a tail node; the first node is simulation node N1 among the M simulation nodes; the tail node is simulation node N among the M simulation nodes. M The intermediate node refers to the other simulated nodes among the M simulated nodes, excluding the first node and the last node. The ring topology type and the simulated node N are based on the above. i The simulation node N is determined from the M simulation nodes. i The corresponding first type of node includes: If the simulation node N i If it belongs to the first node, then simulated node N2 and simulated node N from the M simulated nodes will be... M All were determined to be the simulated node N. i The corresponding first type of node; If the simulation node N i If it belongs to the tail node, then simulated node N1 and simulated node N from the M simulated nodes will be... M-1 All were determined to be the simulated node N. i The corresponding first type of node; If the simulation node N i If it belongs to the intermediate node, then the simulation node N among the M simulation nodes will be... i-1 and simulated node N i+1 All were determined to be the simulated node N. i The corresponding first type of node.

8. The method according to claim 1, characterized in that, The method is executed by a test node; the test node belongs to the M simulated nodes; the blockchain service includes a sub-service for reaching consensus on the information to be verified; The step of obtaining the first simulated execution result after executing blockchain business in the target network topology includes: The blockchain service is executed in the target network topology, and the information to be verified is broadcast to (M-1) simulated nodes so that the (M-1) simulated nodes reach a consensus on the information to be verified and obtain a consensus result. If any of the consensus results returned by the (M-1) simulated nodes exceeds the consensus threshold and indicates successful consensus, then it is determined that the simulated nodes in the blockchain network corresponding to the target network topology have reached a consensus, and a first simulated execution result is obtained to indicate successful execution. If none of the consensus results returned by the (M-1) simulated nodes exceed the consensus threshold indicating successful consensus, then it is determined that the simulated nodes in the blockchain network corresponding to the target network topology have not reached a consensus, and a first simulated execution result is obtained to indicate execution failure.

9. The method according to claim 1, characterized in that, The method further includes: The first simulation execution result or the second simulation execution result is determined as the service simulation execution result, and the network topology corresponding to the service simulation execution result is determined as the service network topology; the service network topology includes the target network topology and the heterogeneous network topology; If the business simulation execution result indicates execution failure, then the running state of the blockchain network corresponding to the business network topology is set to blocked state.

10. The method according to claim 9, characterized in that, The method further includes: When the blockchain network is in a blocked state, obtain the error identification code and error details to indicate execution failure; Based on the error identifier and the error details, an exception message associated with the blockchain business is generated and displayed on the test node corresponding to the test object.

11. The method according to claim 1, characterized in that, The method further includes: From the consensus states of the target network topology and the heterogeneous network topology, respectively count the first number of first network topologies that have consensus conditions and the second number of second network topologies that do not have consensus conditions. Based on the first quantity and the second quantity, determine the stability of the target network topology for the consensus layer in the blockchain network; Based on the stability of the consensus layer in the blockchain network for each network topology in the set of network topologies, a test report is generated to test the consensus layer of the blockchain network. The test report is displayed on the test node corresponding to the test object.

12. A data processing device based on blockchain, characterized in that, include: A construction instruction generation module is used to generate a target construction instruction associated with the target network topology when the node information corresponding to M simulated nodes is obtained; the target construction instruction is used to instruct the M simulated nodes to construct the target network topology associated with the blockchain network; M is a positive integer; The first result acquisition module is used to acquire the first simulated execution result obtained after executing blockchain business in the target network topology; A transfer instruction generation module is used to acquire test accuracy parameters associated with the target network topology, determine the path offset corresponding to the target network topology based on the test accuracy parameters, the path offset being determined based on the total number of paths corresponding to the target network topology, dynamically transfer the target network topology based on the path offset to obtain a heterogeneous network topology corresponding to the target network topology, and redetermine the node connection relationships corresponding to the M simulated nodes based on the heterogeneous network topology and the M simulated nodes. Based on the redefined connection relationships of the M simulated nodes, a construction instruction for constructing the heterogeneous network topology is generated, and the generated construction instruction is used as the target transfer instruction corresponding to the target network topology; the target transfer instruction is used to instruct the M simulated nodes to switch from the target network topology to the heterogeneous network topology. The second result acquisition module is used to acquire the second simulated execution result obtained after executing the blockchain business in the heterogeneous network topology; The consensus state determination module is used to determine the consensus state of the target network topology and the heterogeneous network topology based on the first simulation execution result and the second simulation execution result, respectively. The consensus state is used to reflect the stability of the consensus layer of the blockchain network.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to invoke the computer programs to cause the computer device to perform the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1 to 11.

Images