Block chain performance test system and method

Abstract

The invention discloses a block chain performance test system and method, and relates to the technical field of computers, and the method comprises the steps: automatically deploying and initializing a tested block chain network according to test configuration parameters; generating an initial test transaction flow according to a preset load model, and continuously injecting the initial test transaction flow into the tested block chain network; synchronously acquiring original performance index data streams of four dimensions through a fine-grained index acquisition probe; calling a multi-chain adapter module to convert the instruction into standardized operation; dynamically adjusting transaction generation parameters based on the on-chain state feedback; and carrying out preprocessing, time sequence correlation analysis and anomaly detection on the collected original index data to generate a test report. The method aims at solving the problems that in the prior art, a test result is unreliable, a static load model is disjointed with a real scene, and only the limitation of macroscopic throughput and delay is concerned, calculation, storage and strong isolation and accurate control of network resources can be achieved, and it is ensured that the test result is high in repeatability and free of external interference.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a blockchain performance testing system and method. Background Technology

[0002] With the widespread application of distributed ledger technology, blockchain systems have demonstrated enormous potential in areas such as financial transactions, supply chain management, digital identity authentication, and IoT data storage. Their core value lies in building a trusted collaboration mechanism through decentralized, immutable, and traceable characteristics. However, the actual deployment and large-scale application of blockchain systems highly depend on their underlying performance, including key indicators such as throughput, confirmation latency, resource consumption, and stability under high concurrency loads. Currently, performance evaluation of blockchain systems has become an indispensable part of the R&D, selection, and optimization process. However, existing testing methods still have significant limitations in terms of test dimension completeness, environmental realism, dynamic load adaptability, and multi-chain heterogeneous compatibility, making it difficult to comprehensively, accurately, and efficiently reflect the system's behavioral characteristics in real business scenarios.

[0003] Blockchain performance testing technology aims to quantitatively evaluate the processing power and robustness of a target blockchain under specific configurations by simulating user requests, network topology, and consensus processes. This technology typically involves core processes such as test case generation, node deployment, transaction injection, metric collection, and result analysis. Its effectiveness directly determines the accuracy of performance bottleneck identification and the targeted nature of optimization strategies. An ideal testing system should support multiple consensus algorithms, different ledger structures, and diverse smart contract execution environments, and be able to reproduce complex network conditions under controllable conditions, thereby providing developers with performance profiles that offer engineering guidance.

[0004] Existing blockchain performance testing solutions generally suffer from the following integrated defects: First, the test load generation mechanism is static and fixed, unable to dynamically adjust transaction types, frequency, and complexity based on on-chain state feedback, resulting in a disconnect between the test scenario and real business traffic. Second, the test environment has poor isolation; most tools deploy the tested nodes directly on physical hosts or general-purpose virtual machines, making it difficult to accurately control computing, storage, and network resource quotas, causing test results to be susceptible to external interference and lack repeatability. Third, the performance metric collection granularity is coarse, focusing only on global throughput and average latency, ignoring key micro-level signals such as consensus round time, block propagation efficiency, memory leak trends, and CPU cache hit rate, making it impossible to effectively capture deep performance bottlenecks. In addition, existing systems generally lack support for multi-chain parallel testing, making it impossible to conduct horizontal comparative analysis of heterogeneous blockchains within the same framework, severely restricting the efficiency of cross-chain architecture selection and hybrid deployment scenarios. Finally, the visualization and diagnostic capabilities of test results are weak, failing to transform raw metrics into interpretable performance attribution graphs, making it difficult for developers to quickly pinpoint whether the consensus mechanism, network protocol, or smart contract execution engine is the system bottleneck. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain performance testing system and method to solve the limitations of existing technologies, such as unreliable test results, disconnect between static load models and real-world scenarios, and a focus only on macroscopic throughput and latency.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A blockchain performance testing system includes: a test environment orchestration module, used to automatically deploy and initialize the blockchain network under test in a resource-isolated containerized environment according to test configuration parameters. The containerized environment is implemented based on the Kubernetes orchestration framework, allocating independent computing, storage, and network namespaces for each node under test; a dynamic load generation module, used to generate initial test transactions according to a preset load model, and dynamically adjust the type, frequency, and complexity of transaction generation based on on-chain state feedback data collected in real time from the blockchain network under test; a fine-grained metric acquisition module, used to synchronously collect raw performance metric data in four dimensions—consensus process, network communication, smart contract execution, and system resource consumption—at a preset sampling frequency through probes deployed in the container of the node under test; a multi-chain adapter module, used to provide a unified interface specification, converting node deployment, transaction construction, and metric acquisition instructions for different blockchain underlying architectures into a standardized set of operation instructions; and an intelligent diagnosis and visualization module, used to perform time-series correlation analysis and anomaly detection on the collected raw performance metric data, and generate a multi-dimensional performance attribution graph.

[0007] Preferably, the test environment orchestration module includes a network topology construction unit, a resource quota control unit, and a node configuration injection unit. The network topology construction unit constructs the corresponding P2P network connection topology in the containerized environment based on the number of nodes, geographical distribution simulation requirements, and consensus algorithm type in the test configuration parameters, and simulates network partitioning, latency jitter, and packet loss rate parameters. The resource quota control unit sets precise upper limits for the number of CPU cores, memory usage, disk I / O bandwidth, and network bandwidth for each tested node container; these upper limits are enforced through a cgroup mechanism. The node configuration injection unit is responsible for injecting a configuration file containing genesis block information, private keys, node addresses, and specific consensus parameters into the corresponding tested node's working directory when the container starts.

[0008] Furthermore, the dynamic load generation module includes a load model parsing unit, a state awareness unit, and a strategy adjustment unit. The load model parsing unit parses user-defined load models, which are defined in JSON format and include parameters such as transaction type distribution, initial sending rate, transaction size range, and smart contract call complexity. The state awareness unit subscribes to the event logs and block header information of the tested blockchain network to obtain real-time on-chain transaction pool depth, average block confirmation time, account state change frequency, and smart contract gas consumption statistics. Based on the output of the state awareness unit, the strategy adjustment unit dynamically adjusts the load generation strategy using a feedback control algorithm. When the transaction pool depth is detected to be consistently below a threshold, the transaction sending rate is linearly increased; when the block confirmation time is detected to exceed a preset threshold, the transaction complexity is automatically reduced or the transaction type with lower load is switched.

[0009] Furthermore, the fine-grained metric acquisition module deploys probes including consensus probes, network probes, contract probes, and system probes. The consensus probe is embedded in the consensus logic of the node under test, used to collect the proposal time, pre-voting time, locking time, and final confirmation timestamp for each consensus round. The network probe, based on eBPF technology, captures the sending and receiving sequence, message size, and propagation hops of P2P messages between nodes at the kernel layer. The contract probe intercepts the execution flow of the smart contract virtual machine, recording the opcode execution count, peak memory allocation, and execution time for each contract call. The system probe reads the / proc and / sys file systems within the container to collect CPU core utilization, memory resident set size, disk read / write throughput, and network socket queue depth.

[0010] On the other hand, the multi-chain adapter module is implemented as a pluggable architecture, including an Ethereum adapter, a Fabric adapter, and a Solana adapter. Each adapter implements a unified interface specification, which includes the deployChain(config), constructTx(template, params), sendTx(tx), and collectMetrics(probeType) methods. The Ethereum adapter converts the standardized deployChain call into initialization commands and genesis file generation for geth or besu clients; the Fabric adapter converts the standardized call into Docker Compose orchestration files for Fabric CA, Orderer, and Peer nodes; and the Solana adapter corresponds to the startup parameter configuration and RPC interface encapsulation for solana-test-validator.

[0011] Furthermore, the intelligent diagnosis and visualization module includes a data preprocessing unit, a correlation analysis unit, and a map generation unit. The data preprocessing unit performs timestamp alignment, missing value imputation, and noise filtering on heterogeneous time-series data from different probes. The correlation analysis unit uses an algorithm based on dynamic time warping to calculate the correlation strength between different performance index sequences; the calculation formula is as follows: in, and There are two indicator sequences. The optimal normalized path is determined by the correlation analysis unit, which identifies paths where the DTW distance is less than a threshold. The metrics are paired. The graph generation unit uses the architectural components of the tested blockchain system as nodes and the identified strong correlations as edges to construct a directed weighted performance attribution graph. The node size represents the load pressure of the component, the edge weight represents the correlation strength, and the layout is visualized through a force-directed algorithm.

[0012] A blockchain performance testing method, the specific steps of which are as follows: Step S110: Based on the input test configuration parameters, call the test environment orchestration module to automatically deploy and initialize the blockchain network under test in a resource-isolated containerized environment, apply precise resource quota limits to each node and inject specific configurations. Step S120: Generate an initial test transaction flow based on a preset load model and continuously inject it into the blockchain network under test. Step S130: Through fine-grained metric acquisition probes deployed in the container of the node under test, raw performance metric data streams of four dimensions—consensus, network, contract, and system resources—are collected synchronously at a high sampling frequency. Step S140: Call the multi-chain adapter module to convert the deployment, transaction construction, and indicator collection instructions for the tested chain into standardized operations that can be executed by the chain's native client. Step S150: Based on the real-time status feedback data obtained from the chain, dynamically adjust the transaction generation type, frequency, and complexity parameters in step S120. Step S160: After preprocessing the raw indicator data collected in step S130, time series correlation analysis and anomaly detection are performed to identify key signals of performance bottlenecks and the correlation between components. Step S170: Based on the analysis results of step S160, generate a multi-dimensional performance attribution map and a structured test report.

[0013] Preferably, the automated deployment and initialization of the blockchain network under test in step S110 specifically includes: parsing test configuration parameters, which specify the blockchain type, number of nodes, consensus algorithm, network topology model, and resource quota; creating a corresponding number of Pods based on the Kubernetes API, with each Pod corresponding to one node under test, and defining a Resource Quota for each Pod that includes CPU and memory requests and limits; downloading the client binary file and dependency library for the corresponding blockchain type in the initialization container of each Pod; after the main container of the Pod starts, executing the node initialization command generated by the multi-chain adapter module, loading the genesis block, and starting the node daemon process; and configuring network policies between Pods to simulate the specified network topology and fault conditions.

[0014] Furthermore, the collection of raw performance indicator data streams in step S130 specifically includes: the consensus probe inserting hook functions at each key stage of the consensus engine to record microsecond-level timestamps of the start and end of the stage and the participating node IDs; the network probe attaching to the sendmsg and recvmsg system calls via the eBPF program to extract target IP, port, message length, and socket status information; the contract probe setting breakpoints at the entry and exit points of the smart contract virtual machine execution to collect call stack depth, gas consumption details, and storage access patterns; and the system probe reading the / proc / stat, / proc / meminfo, / proc / diskstats, and / proc / net / dev files at a sampling interval ≤100ms to calculate CPU utilization, memory usage, disk I / O wait time, and network bandwidth utilization.

[0015] Furthermore, the feedback control logic for dynamically adjusting the transaction generation parameters in step S150 specifically involves defining a set of state variables. Define the set of control variables. Establish a mapping function from state to control. When the trading pool depth At that time, according to the increment Improve transaction sending speed When the block time At that time, proportionally Reduce transaction complexity The complexity is quantified by the number of smart contract opcodes or nested call layers contained in the transaction; when gas utilization... When necessary, switch to the standby transaction type defined in the load model, which has lower computational and storage overhead.

[0016] Furthermore, the time-series correlation analysis and anomaly detection described in step S160 employ an ensemble strategy: for single-index sequences, the Isolation Forest algorithm is used to detect anomalies in data points, and its decision function is: in, For data points, Let be the path length in the random partition tree. For their expectations, The average path length is used. For multi-index association, the DTW algorithm described in step S150 is applied to calculate the distance between index pairs within the sliding time window. The PELT algorithm is used for detection, and when abrupt changes occur in the distance sequence, they are marked as association anomalies. Single-point anomalies and association anomalies are aggregated to form an anomalous event set.

[0017] Compared with the prior art, the beneficial technical effects of the present invention are as follows: This invention achieves strong isolation and precise control of computing, storage, and network resources through a test environment orchestration module based on containerization and resource quota control, ensuring high repeatability of test results and freedom from external interference, thus solving the problem of unreliable test results caused by environmental noise in existing technologies.

[0018] This invention introduces a dynamic load generation mechanism based on on-chain state feedback, enabling the test load to adapt to the real-time processing capabilities and state changes of the blockchain network, simulating dynamic scenarios that are closer to real business traffic, and overcoming the shortcomings of static load models being disconnected from real scenarios.

[0019] This invention, by deploying multi-dimensional, fine-grained indicator collection probes, can capture high-performance signals from multiple micro-levels such as consensus, network, contract execution, and system resources, providing unprecedented data granularity for in-depth performance bottleneck localization and overcoming the limitations of traditional testing that only focuses on macro-level throughput and latency.

[0020] This invention provides unified testing support for heterogeneous blockchains such as Ethereum, Hyperledger Fabric, and Solana through a pluggable multi-chain adapter module, enabling horizontal performance comparison and analysis within the same framework, and greatly improving the efficiency of cross-chain architecture selection and hybrid deployment evaluation.

[0021] This invention utilizes an intelligent diagnostic module based on time-series correlation analysis and graph visualization to automatically transform massive amounts of raw indicators into intuitive performance attribution graphs, clearly revealing the system bottleneck components and their interrelationships, significantly improving the interpretability and engineering guidance value of test results. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the blockchain performance testing system architecture proposed in this invention; Figure 2 This is a schematic diagram of the blockchain performance testing method proposed in this invention. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0025] In the embodiments of the present invention, the same reference numerals denote the same components, and for the sake of brevity, detailed descriptions of the same components are omitted in different embodiments. It should be understood that the thickness, length, width, and other dimensions of various components in the embodiments of the present invention shown in the accompanying drawings, as well as the overall thickness, length, width, and other dimensions of the integrated device, are merely illustrative and should not constitute any limitation on the present invention; the term "multiple" in the present invention refers to two or more (including two).

[0026] Example 1 In scenarios where fintech companies are evaluating new consortium blockchain platforms, it is necessary to conduct a horizontal performance comparison between their self-developed blockchain platform and mainstream open-source platforms. Traditional testing methods struggle to obtain repeatable and interpretable in-depth performance data in environments with controllable resources, dynamic loads, and comprehensive metrics. The blockchain performance testing system and method provided in this invention can achieve automated, high-fidelity, and multi-dimensional performance evaluation in this scenario.

[0027] See Figure 1 This system includes a test environment orchestration module, a dynamic load generation module, a fine-grained metric acquisition module, a multi-chain adapter module, and an intelligent diagnostics and visualization module. The test environment orchestration module automatically deploys and initializes the blockchain network under test in a resource-isolated containerized environment built on Kubernetes, based on the input test configuration parameters. This module includes a network topology building unit, a resource quota control unit, and a node configuration injection unit. The network topology building unit parses the number of nodes, geographical distribution simulation requirements, and consensus algorithm type specified in the test configuration parameters.

[0028] Specifically, to simulate a cross-regional four-node RAFT consensus network, this unit creates four Pods and configures corresponding network policies, introducing specific network latency and packet loss rates between Pods to simulate network conditions between data centers in Beijing, Shanghai, Shenzhen, and Chengdu. The resource quota control unit sets precise resource limits for each Pod, enforced through a cgroup mechanism. Specifically, simulating resource-constrained edge nodes, it sets a CPU usage limit of 0.5 cores, a memory limit of 512MB, disk I / O read / write bandwidth limits of 50MB / s and 30MB / s respectively, and a network bandwidth limit of 100Mbps for a given Pod. The node configuration injection unit, during the initialization phase of each Pod, injects a configuration file containing the specific genesis block hash, node private key, peer node address list, and RAFT election timeout parameters into a specified path within the container, ensuring that the correct identity and network configuration are loaded upon node startup.

[0029] The dynamic load generation module generates initial test transactions based on a preset load model and dynamically adjusts the load based on on-chain state feedback. This module includes a load model parsing unit, a state awareness unit, and a strategy adjustment unit. The load model parsing unit reads a load model file defined in JSON format. This file defines the transaction type distribution: 60% simple inter-account transfer transactions, 30% query transactions calling specific smart contracts, and 10% contract deployment transactions involving complex state updates; it also defines an initial sending rate of 100 transactions per second, with individual transaction sizes randomly distributed between 200 bytes and 2KB. The state awareness unit subscribes to the event logs and new block headers of the tested blockchain network via a WebSocket long connection. It parses the data in real time, calculates the number of pending transactions in the current on-chain transaction pool, calculates the average block time of the last 10 blocks, and monitors the average and peak gas consumption during smart contract calls. The strategy adjustment unit executes feedback control logic based on this real-time state data. This logic defines the set of state variables as transaction pool depth, average block confirmation time, and gas usage; and the set of control variables as transaction sending rate and transaction complexity. A mapping function from state to control is established. Specifically, when the transaction pool depth is detected to be below the threshold of 20 for 5 consecutive seconds, the strategy adjustment unit linearly increases the transaction sending rate by 10 transactions per second. When the average block confirmation time exceeds the preset threshold of 2 seconds, the strategy adjustment unit automatically reduces the proportion of complex transactions, specifically reducing the proportion of contract transactions involving complex state updates from 10% to 5%, while correspondingly increasing the proportion of simple transfer transactions. When the gas utilization rate is consistently above 80%, the strategy adjustment unit triggers the backup transaction type defined in the load model, switching it to smart contract calls that only read the state without modifying it, thereby reducing computational and storage overhead.

[0030] The fine-grained metric acquisition module collects raw performance metric data synchronously at high frequency through various probes deployed within the tested node's container. Consensus probes are embedded into key functions of the tested node's consensus engine using code instrumentation. In the RAFT consensus algorithm, probes insert hook functions at critical stages such as leader election and log replication commit, precisely recording the microsecond-level timestamps of the start and end of each stage, and capturing information such as the current term number, candidate ID, and voting results. Network probes, based on eBPF technology, are mounted to the sendmsg and recvmsg system calls at the kernel layer. For each network message transmission and reception, the probe extracts the source IP, destination IP, port, protocol type, message payload length, and socket buffer status. The end-to-end latency of message propagation between nodes can be calculated using timestamp differences. Contract probes modify the smart contract virtual machine interpreter, setting breakpoints at the execution flow entry and exit points. For the Ethereum Virtual Machine, the probe records the input data for each contract call, the sequence of executed opcodes, the gas consumption of each opcode, the peak size of memory allocation during execution, and the final state storage modification set. The system probe periodically reads the / proc and / sys file systems within the container at sampling intervals not exceeding 100 milliseconds. It calculates the time spent by each CPU core in different modes (user mode, system mode, idle mode, etc.) from / proc / stat, summing these to obtain the overall CPU utilization. It obtains detailed information such as total memory, used memory, cache, and buffers from / proc / meminfo, calculating the resident set size. It reads the number of read / write operations, sectors, and wait times for disk devices from / proc / diskstats, calculating disk I / O throughput and average wait time. It obtains the number of bytes sent and received, packets, and errors for network interfaces from / proc / net / dev, calculating network bandwidth utilization.

[0031] The multi-chain adapter module, acting as a bridge for interaction between the system and heterogeneous blockchain underlying layers, adopts a plug-in architecture. This module defines a unified interface specification, including four core methods: deploying the blockchain network, constructing transactions, sending transactions, and collecting metrics. For the Ethereum platform, when the Ethereum adapter implements the `deployChain` method, it parses standardized configurations, generates a `genesis.json` genesis file that conforms to the requirements of geth or besu clients, and constructs the command-line parameters required to start the node, such as specifying the data directory, enabling the HTTP-RPC port, and setting the network ID. Its `constructTx` method receives the transaction template and parameters, calls the Ethereum Web3.js library, populates fields such as `nonce`, `gasPrice`, and `gasLimit`, and signs the transaction. For the Hyperledger Fabric platform, the Fabric adapter's `deployChain` method generates a complete set of Docker Compose orchestration files, including the configuration of the Orderer service node, multiple Peer nodes, and the CA certificate authority, and automatically executes the channel creation, chaincode installation, and instantiation process. For the Solana platform, the Solana adapter encapsulates the startup parameters of the solana-test-validator command and provides a standardized encapsulation for its RPC interface to send transactions and query status.

[0032] The intelligent diagnostics and visualization module performs in-depth analysis and presentation of the massive amounts of collected indicators. This module includes a data preprocessing unit, a correlation analysis unit, and a graph generation unit. The data preprocessing unit first receives heterogeneous time-series data streams from different probes. Since there may be microsecond-level deviations in the sampling times of each probe, this unit uses the system probe's sampling time as a benchmark and employs linear interpolation to timestamp the data from other probes. For individual data points missing due to network jitter or brief probe malfunctions, forward imputation is used to complete them. Subsequently, a moving average filter is applied to smooth the data sequence to suppress high-frequency noise. The correlation analysis unit uses an algorithm based on dynamic time warping to calculate the correlation strength of different performance indicator sequences within a moving time window. The formula for calculating the dynamic time warping distance is: in, and These are two sets of metrics to be compared, specifically CPU utilization and consensus block generation time series. This is the optimal regularized path found through dynamic programming. This unit calculates the DTW distance between all key indicator pairs, and determines the path when the distance is less than a preset threshold. At that time, it is determined that the indicator has a strong correlation within the observation window. Simultaneously, this unit applies the Isolation Forest algorithm to the single indicator sequence for anomaly detection. Isolation Forest isolates data points by randomly partitioning the feature space; outliers, due to their significant differences in features from normal points, are usually isolated with fewer splits. Its anomaly scoring decision function is: in, For the data points to be evaluated, For point Path length in a randomly partitioned tree Let it be the expected value of its path length across all trees. For a given number of samples The average path length is used for standardization. (Score) The closer a value is to 1, the more likely it is to be an anomaly. The graph generation unit uses the logical architecture components of the tested blockchain system as nodes, specifically the consensus module, network layer, smart contract virtual machine, and storage engine. Strong correlations identified by the correlation analysis unit are used as directed edges, with edge weights obtained by normalizing the inverse of the DTW distance. The size of a node is mapped based on the average load pressure of that component during the observation period; for example, the size of a consensus module node is proportional to its CPU utilization. Finally, a force-directed algorithm is used to visualize the graph layout, bringing closely connected nodes closer together to clearly reveal the source of performance bottlenecks and their propagation paths within the system. For example, the graph might show an abnormally large "smart contract virtual machine" node with a thick edge connecting to the "disk I / O wait time" node, which is also associated with the "block confirmation time" node, thus intuitively indicating that complex contract execution causes frequent disk reads and writes, thereby slowing down the entire block processing flow.

[0033] Based on the above system, the blockchain performance testing method is performed according to the following steps: Step S110: Based on the input test configuration parameters, the test environment orchestration module is invoked to automatically deploy and initialize the blockchain network under test in a resource-isolated containerized environment, imposing precise resource quota limits on each node and injecting specific configurations. The specific implementation process is as follows: The test configuration parameters are parsed, specifying in YAML format the blockchain type as Ethereum, the number of nodes as 4, the consensus algorithm as Clique, the network topology as fully connected, and the resource quota for each node. The system creates four namespace-isolated Pods via the Kubernetes API. A Resource Quota is defined for each Pod; for example, Pod-1 is set to request 0.5 CPU cores, limited to 1 core, and request 1GB of memory, limited to 2GB. In the initialization container of each Pod, the binary file of geth client v1.10.0 and its dependencies are pulled from the image repository. After the Pod's main container starts, the initialization command sequence generated by the Ethereum adapter is executed: first, the geth init command is used to load the injected genesis file to initialize the data directory; then, the geth --http --http.api eth,net,web3 command is used to start the node and enable the HTTP-RPC service. Finally, configure the Calico network policy to introduce a fixed latency of 50ms and a packet loss rate of 1% between Pod-2 and Pod-3 to simulate specific network failure conditions.

[0034] Step S120: An initial test transaction flow is generated based on a preset load model and continuously injected into the blockchain network under test. The load model parsing unit loads the JSON configuration from the file and initializes the transaction generator. The transaction generator first creates a batch of test accounts and injects initial balances into them. Then, according to the distribution defined by the model, it begins to construct transactions. For transfer transactions, the source and target accounts are randomly selected, and random amounts are generated. For contract call transactions, transaction data for calling specific contract functions is constructed according to the template. In the initial stage, the transaction generator sends transactions to the entry node of the blockchain network under test at a constant rate of 100 transactions per second through the RPC interface encapsulated by the multi-chain adapter module.

[0035] Step S130 involves using fine-grained metric acquisition probes deployed within the tested node container to synchronously collect raw performance metric data streams across four dimensions: consensus, network, contract, and system resources at a high sampling frequency. The consensus probe inserts hooks at the "round switching" and "block signing" events of the Clique consensus engine, recording the start time of the proposer packaging the block, the time of completing the block signing, and the time the block is broadcast in each block round. The network probe's eBPF program captures all data packets entering and leaving the container's network namespace, filters out P2P protocol messages destined for port 30303, and records the message type, size, and arrival / departure timestamps to calculate the message propagation delay and network throughput between nodes. The contract probe is triggered when the EVM executes critical opcodes such as CALL and SSTORE, recording the total number of opcodes executed in that call context, the cumulative Gas consumption, and the list of accessed storage keys. The system probe executes a data acquisition script every 50 milliseconds, reads the / proc file system, calculates the percentage of time the CPU spent in a non-idle state in the past 50 milliseconds, obtains the memory MemAvailable value, calculates the difference in the number of read and write sectors of the vda device in that interval from / proc / diskstats, and converts it into throughput.

[0036] Step S140 involves invoking the multi-chain adapter module to convert the deployment, transaction construction, and metric collection instructions for the tested chain into standardized operations executable by the chain's native client. Throughout the testing process, the core system logic calls a unified adapter interface. When a transaction requiring chaincode invocation needs to be sent to the Fabric network, the system calls fabricAdapter.constructTx('invoke', {chaincode: 'mycc', function: 'transfer', args: ['a', 'b', '100']}). The Fabric adapter internally converts this into a proposal request object conforming to the Fabric SDK requirements, attaching the correct identity certificate and channel header information.

[0037] Step S150: Based on real-time state feedback data obtained from the chain, dynamically adjust the transaction generation type, frequency, and complexity parameters from step S120. The state awareness unit continuously monitors the on-chain state. Assuming the transaction pool depth drops from 50 within 10 seconds and stabilizes at around 5, and the block time remains within 1 second, the gas utilization rate is 60%. The strategy adjustment unit determines that the current network processing capacity has a surplus based on the mapping function. Therefore, it issues an instruction to increase the transaction sending rate from 100 transactions per second to 120 transactions per second. Simultaneously, to further apply pressure, it increases the proportion of complex contract transactions from 10% to 15%. The adjusted new load strategy takes effect immediately, and the transaction generator generates and sends transactions according to the new parameters.

[0038] Step S160 involves preprocessing the raw indicator data collected in step S130, followed by time-series correlation analysis and anomaly detection to identify key signals of performance bottlenecks and inter-component relationships. The data preprocessing unit aligns and aggregates all indicator data from the past 5 minutes at 100-millisecond intervals. The correlation analysis unit first applies the Isolation Forest algorithm to the "CPU utilization collected by the system probe" sequence, marking anomalies where utilization exceeds 85%. Simultaneously, within a 30-second sliding window, it calculates the DTW distance between the "average message propagation delay collected by the network probe" and the "block generation time collected by the consensus probe." Analysis of the DTW distance sequence using the PELT algorithm detects a sudden jump in the distance value from 0.5 to 2.0 at a certain point in time, marking it as a correlation anomaly. Analysis shows that this correlation anomaly highly overlaps temporally with previously marked CPU utilization anomalies and the increase in network packet loss rate.

[0039] Step S170: Based on the analysis results of step S160, a multi-dimensional performance attribution graph and a structured test report are generated. The graph generation unit constructs the graph based on the analysis results of step S160. In the graph, the size of the "CPU of Node-1" node is significantly increased, the "Network Link from Node-1 to Node-2" edge is thickened and highlighted in red, and the "Consensus Block Time" node also shows a yellow warning status. The graph intuitively shows that the performance bottleneck stems from Node-1's CPU overload due to handling high-load transactions, which in turn affects its network message processing capability, leading to increased network latency to Node-2, ultimately slowing down the entire consensus process. The structured test report is automatically generated, including a test configuration summary, performance index curves over time for each dimension, a list of abnormal events, attribution analysis conclusions, and targeted optimization suggestions, such as "suggest optimizing the execution efficiency of smart contracts on Node-1" or "checking the physical network link between Node-1 and Node-2".

[0040] Example 2 In scenarios where blockchain infrastructure service providers offer hybrid chain architecture performance testing services to their clients, it is necessary to simultaneously conduct extreme stress tests on a public-chain-style permissioned chain and a consortium chain, and compare their performance differences under the same load model. The system of this invention can efficiently accomplish this task through multi-chain adaptation and isolated environment control.

[0041] In this embodiment, the test environment orchestration module deploys two independent blockchain networks in parallel across different namespaces within the same Kubernetes cluster, based on a single composite configuration. The first network uses an Ethereum-based permissioned blockchain version and contains 5 nodes. The second network uses Hyperledger Fabric and contains 1 Orderer node and 4 Peer nodes. The resource quota control unit sets differentiated resource limits for the two networks. Higher CPU and network bandwidth limits are set for public blockchain-style nodes to simulate high-performance servers, while stricter limits are set for consortium blockchain nodes to simulate standard enterprise server configurations. The network topology building unit configures different simulated network conditions for the two networks: the public blockchain network simulates high latency between global nodes, while the consortium blockchain network simulates a low-latency environment within a data center.

[0042] The dynamic load generation module loads a load model designed to approach the system's limits. This model initially increases the transaction sending rate linearly until a performance inflection point is observed. The state awareness unit simultaneously subscribes to the states of both networks. The strategy adjustment unit runs feedback control logic independently for both networks. When a transaction pool overflow and gas price spikes on the public blockchain network, the strategy adjustment unit determines that it is nearing its limit, maintains the current load, and records it as the peak pressure point. For the consortium blockchain network, when block generation stops or peer node memory overflows, the strategy adjustment unit immediately stops load injection and records the load parameters at the time of the failure.

[0043] The fine-grained metric collection module uses the same probe type for both networks, but the collected metrics differ due to the underlying architecture. For the Ethereum permissioned chain, the contract probe focuses on the EVM's gas consumption pattern. For the Fabric network, the contract probe records the actual resource consumption of chaincode execution within Docker containers and captures the ordering queue depth and broadcast throughput of the Orderer node through a customized probe. The system probes collect data in completely consistent dimensions, ensuring comparable resource consumption data.

[0044] The multi-chain adapter module loads both the Ethereum adapter and the Fabric adapter plugins. The test control logic uses a unified scheduler to alternately or in parallel call the interfaces of the two adapters, enabling synchronous cross-chain testing. The intelligent diagnostics and visualization module labels the indicator data of both networks with "chain type" tags during data processing. The correlation analysis unit not only performs intra-chain indicator correlation but also cross-chain comparative correlation analysis, such as comparing the differences in CPU utilization under the same transaction throughput. The graph generation unit can generate parallel comparative graphs or map the components of the two networks to different areas of the same graph, using color to distinguish chain types and visually displaying the similarities and differences of bottleneck components under different architectures.

[0045] In step S110 of the testing methodology, the automated deployment process initializes two environments in parallel, ensuring their network policies are completely isolated and do not interfere with each other. In steps S120 and S150, the load generation and adjustment strategies run independently on both networks but are subject to unified monitoring. In step S130, the metric collection streams converge into two independent but time-synchronized data streams. The analysis process in step S160 performs cross-chain data alignment and comparison, identifying key conclusions such as, "Under a load of 2000 transactions per second, the bottleneck of the Ethereum permissioned chain is storage I / O, while the bottleneck of Fabric is Orderer CPU." The report generated in step S170 includes comparative charts and hybrid architecture selection recommendations.

[0046] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention, as long as they do not depart from the scope of the present invention.

Claims

1. A blockchain performance testing system, characterized in that, It includes the following components: The test environment orchestration module is used to automatically deploy and initialize the blockchain network under test in a resource-isolated containerized environment according to the test configuration parameters. The dynamic load generation module is used to generate initial test transactions based on a preset load model, and dynamically adjust the type, frequency and complexity of transaction generation based on on-chain state feedback data collected in real time from the blockchain network under test. The fine-grained metric acquisition module is used to synchronously collect raw performance metric data in four dimensions—consensus process, network communication, smart contract execution, and system resource consumption—at a preset sampling frequency through probes deployed in the container of the node under test. The multi-chain adapter module provides a unified interface specification, converting instructions for node deployment, transaction construction, and indicator collection for different blockchain underlying architectures into a standardized set of operation instructions. The intelligent diagnosis and visualization module is used to perform time-series correlation analysis and anomaly detection on the collected raw performance index data, and generate multi-dimensional performance attribution maps.

2. The blockchain performance testing system according to claim 1, characterized in that, The containerized environment is implemented based on the Kubernetes orchestration framework, allocating independent computing, storage, and network namespaces to each node under test; the test environment orchestration module includes a network topology building unit, a resource quota control unit, and a node configuration injection unit. The network topology construction unit constructs the corresponding P2P network connection topology in the containerized environment based on the number of nodes, geographical distribution simulation requirements, and consensus algorithm type in the test configuration parameters, and simulates network partitioning, latency jitter, and packet loss rate parameters. The resource quota control unit sets precise upper limits for the number of CPU cores, memory usage, disk I / O bandwidth, and network bandwidth for each tested node container, and the upper limits are enforced through the cgroup mechanism. The node configuration injection unit is responsible for injecting the configuration file containing genesis block information, private key, node address, and specific consensus parameters into the working directory of the corresponding tested node when the container starts.

3. The blockchain performance testing system according to claim 1, characterized in that, The dynamic load generation module includes a load model parsing unit, a state awareness unit, and a strategy adjustment unit. The load model parsing unit parses user-defined load models, which are defined in JSON format and include parameters such as transaction type distribution, initial sending rate, transaction size range, and smart contract call complexity. The state awareness unit subscribes to the event logs and block header information of the tested blockchain network to obtain real-time on-chain transaction pool depth, average block confirmation time, account status change frequency, and smart contract gas consumption statistics. Based on the output of the state awareness unit, the strategy adjustment unit dynamically adjusts the load generation strategy using a feedback control algorithm. When the transaction pool depth is detected to be continuously below a threshold, the transaction sending rate is linearly increased. When the block confirmation time is detected to exceed a preset threshold, the transaction complexity is automatically reduced or the transaction type is switched.

4. The blockchain performance testing system according to claim 1, characterized in that, The fine-grained metric acquisition module deploys probes including consensus probes, network probes, contract probes, and system probes. The consensus probe is embedded in the consensus logic of the node under test and is used to collect the proposal time, pre-voting time, locking time, and final confirmation timestamp for each consensus round. The network probe, based on eBPF technology, captures the sending and receiving sequence, message size, and propagation hop count of P2P messages between nodes at the kernel layer. The contract probe records the opcode execution count, peak memory allocation, and execution time of each contract call by intercepting the execution flow of the smart contract virtual machine. The system probe collects the CPU core utilization, memory resident set size, disk read / write throughput, and network socket queue depth by reading the / proc and / sys file systems within the container.

5. The blockchain performance testing system according to claim 1, characterized in that, The multi-chain adapter module is implemented as a pluggable architecture, including an Ethereum adapter, a Fabric adapter, and a Solana adapter. Each adapter implements a unified interface specification, which includes the deployChain(config), constructTx(template, params), sendTx(tx), and collectMetrics(probeType) methods. The Ethereum adapter converts the standardized deployChain call into initialization commands and genesis file generation for geth or besu clients. The Fabric adapter converts the standardized call into Docker Compose orchestration files for Fabric CA, Orderer, and Peer nodes, and the Solana adapter corresponds to the startup parameter configuration and RPC interface encapsulation of solana-test-validator.

6. The blockchain performance testing system according to claim 1, characterized in that, The intelligent diagnosis and visualization module includes a data preprocessing unit, a correlation analysis unit, and a map generation unit; the data preprocessing unit performs timestamp alignment, missing value imputation, and noise filtering on heterogeneous time-series data from different probes; The correlation analysis unit uses a dynamic time warping algorithm to calculate the correlation strength between different performance index sequences and identifies strongly correlated index pairs. The graph generation unit uses the architectural components of the tested blockchain system as nodes and the identified strong correlation relationships as edges to construct a directed weighted performance attribution graph. The node size represents the load pressure of the component, the edge weight represents the correlation strength, and the layout is visualized using a force-directed algorithm.

7. The blockchain performance testing system according to claim 3, characterized in that, When the strategy adjustment unit executes the feedback control logic, it defines a set of state variables. Define the set of control variables Establish a mapping function from state to control. When the trading pool depth At that time, according to the increment Improve transaction sending speed When the block time At that time, proportionally Reduce transaction complexity The complexity is quantified by the number of smart contract opcodes or nested call layers contained in the transaction; when gas utilization... When necessary, switch to the standby transaction type defined in the load model.

8. The blockchain performance testing system according to claim 6, characterized in that, The correlation analysis unit uses the isolated forest algorithm to detect data point anomalies in single index sequences; for multi-index correlation, it applies the dynamic time warping algorithm to calculate the distance between index pairs within a sliding time window, and marks the abrupt change in the distance sequence as a correlation anomaly; single-point anomalies and correlation anomalies are aggregated to form an anomalous event set.

9. A blockchain performance testing method, characterized in that, The method includes the following steps: Step S110: Based on the input test configuration parameters, call the test environment orchestration module to automatically deploy and initialize the blockchain network under test in a resource-isolated containerized environment, apply precise resource quota limits to each node and inject specific configurations. Step S120: Generate an initial test transaction flow based on a preset load model and continuously inject it into the blockchain network under test. Step S130: Through fine-grained metric acquisition probes deployed in the container of the node under test, raw performance metric data streams of four dimensions—consensus, network, contract, and system resources—are collected synchronously at a high sampling frequency. Step S140: Call the multi-chain adapter module to convert the deployment, transaction construction, and indicator collection instructions for the tested chain into standardized operations that can be executed by the chain's native client. Step S150: Based on the real-time status feedback data obtained from the chain, dynamically adjust the transaction generation type, frequency, and complexity parameters in step S120. Step S160: After preprocessing the raw indicator data collected in step S130, time series correlation analysis and anomaly detection are performed to identify key signals of performance bottlenecks and the correlation between components. Step S170: Based on the analysis results of step S160, generate a multi-dimensional performance attribution map and a structured test report.

Images