A scalable and general-purpose method and apparatus for measuring blockchain performance boundaries
By designing a scalable blockchain performance boundary measurement framework and a pruning search algorithm, the scalability, universality, and efficiency issues of blockchain performance measurement in existing technologies are solved, enabling accurate measurement and optimization guidance of blockchain performance.
Patent Information
- Application Number
- CN202311233313.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-20
- Publication Date
- 2025-10-28
- Estimated Expiration
- 2043-09-20
AI Technical Summary
Existing blockchain performance measurement frameworks cannot meet users' needs for scalable, universal, accurate, and efficient measurement. They cannot accurately measure blockchain performance in different environments and are difficult to provide optimization guidance.
A scalable and general blockchain performance boundary measurement framework is designed. It adopts a distributed cluster architecture and a performance boundary construction algorithm based on pruning search. By adjusting the on-chain configuration parameters, it can measure and optimize multiple performance indicators and construct the blockchain performance boundary.
It enables efficient and accurate performance measurement of different blockchain platforms, quickly identifies performance bottlenecks and provides optimization guidance, reduces the complexity of the search space, and improves the scalability and efficiency of the system.
Smart Images

Figure CN119690787B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of blockchain performance measurement and optimization technology, and in particular relates to a scalable and universal blockchain performance boundary measurement method and device. Background Art
[0002] As an emerging technology, blockchain technology, with its distributed ledger characteristics, provides secure, transparent, and efficient solutions for various industries such as finance, logistics, energy, and healthcare. However, with its expanding application scope, the performance bottleneck of blockchain is becoming increasingly prominent, making blockchain performance optimization a major concern. Compared to centralized systems, blockchain transaction throughput and confirmation latency differ by orders of magnitude. Therefore, improving the transaction throughput and reducing transaction confirmation latency of blockchain systems is crucial for broadening the application scenarios of blockchain.
[0003] Current mainstream research on blockchain performance optimization mainly focuses on optimizing the chain-like data structure and consensus algorithms of blockchains. Some studies introduce sharding technology into blockchains, dividing the blockchain network into smaller shards to process transactions in parallel, thereby improving blockchain throughput and reducing latency. Other studies are dedicated to proposing new consensus algorithms to improve performance. In the development of blockchain, various consensus algorithms have emerged, including PoW (Proof-of-Work), PoS (Proof-of-Stake), DPoS (Delegate Proof of Stake), and Ripple Consensus. Some studies use higher-performance hardware devices, such as custom ASICs (Application Specific Integrated Circuits), to accelerate transaction processing and consensus verification.
[0004] While there are many solutions for optimizing blockchain performance, these optimizations involve a core issue: as a complex system, changes to one part of the blockchain may affect multiple parts, inevitably impacting other parts and even hindering the original performance. To precisely adjust and improve blockchain performance, a deeper understanding of the blockchain system is needed. Detailed measurement of blockchain performance helps to understand its performance limitations and bottlenecks, guiding the direction of performance optimization and minimizing the impact on the blockchain system itself during optimization.
[0005] However, most current blockchain measurement solutions suffer from poor scalability and are developed for specific blockchain systems. Furthermore, most blockchains can only measure peak performance under fixed environments (physical environment and parameter configurations), while real-world applications involve fluctuating operating environments. Therefore, a measurement solution is needed that can measure blockchain performance under different conditions and provide optimization guidance for current configurations. Thus, there is an urgent need to propose a flexible, scalable blockchain measurement framework that can adapt to different blockchain implementations and provide guidance for blockchain performance optimization.
[0006] Blockchain performance measurement is an important direction in the development of blockchain technology. A widely applicable blockchain performance measurement tool needs to meet the following four conditions:
[0007] Scalability: The measurement framework allows for the customization of measurement metrics according to user needs, enabling functional expansion.
[0008] Versatility: The measurement framework should be applicable to different types of blockchain systems, lightweight, and easy to port;
[0009] Accuracy: The measurement framework needs to be able to measure system performance not only in ideal environments, but also to simulate real-world application scenarios and measure blockchain performance under different environments. Furthermore, the blockchain performance measured by the measurement framework should match the actual performance of the blockchain during operation.
[0010] Efficiency: While ensuring the accuracy of the test, it is also necessary to ensure the efficiency of the measurement.
[0011] The inventors discovered through research that existing blockchain measurement tools struggle to meet all the above conditions and have several shortcomings, specifically:
[0012] In terms of scalability, most existing blockchain performance measurement frameworks only have coarse-grained indicators such as transaction throughput and overall transaction latency, and cannot measure fine-grained performance indicators during blockchain operation. Users who need to measure these indicators cannot extend the measurement to include new ones.
[0013] In terms of versatility, existing blockchain performance measurement frameworks can only support one or a few specific blockchain platforms, which limits their versatility and their practicality in multi-chain environments.
[0014] In terms of accuracy, most measurement frameworks can only adjust workload and network topology, requiring the testing of a system's peak performance under otherwise fixed configurations. The experimental environment differs significantly from real-world scenarios, limiting the practical application benefits of the measurement results. Some measurement frameworks use simulators to measure blockchain operating environments that simulate real-world conditions. While this approach can simulate the changing real-world environment, the accuracy of simulator measurements is low. To ensure the accuracy of simulator results, a large amount of real-world data is needed to calibrate the simulator, leading to a significant decrease in measurement efficiency and a substantial increase in overhead.
[0015] In terms of efficiency, the aforementioned simulators ensure high-efficiency measurements, but their accuracy is low, and achieving accurate simulation requires significant overhead for simulator calibration. For real-world blockchain measurements in complex and diverse environments, multiple runs with modified configurations are necessary. Existing measurement frameworks can only be deployed and run on a single machine, which is also time-consuming and inefficient.
[0016] To address the aforementioned issues, a new blockchain measurement framework needs to be developed that can simultaneously meet the requirements of scalability, universality, accuracy, and efficiency. Summary of the Invention
[0017] The purpose of this invention is to address the problem that existing blockchain performance measurement frameworks cannot meet users' needs for scalability, universality, accuracy, and efficiency in blockchain measurement. It proposes a scalable and universal blockchain performance boundary measurement framework that measures multiple performance indicators of a running blockchain system by adjusting various configuration parameters. This framework meets the requirements of scalability, universality, accuracy, and efficiency, constructs blockchain performance boundaries, and provides guidance for optimizing blockchain parameter configurations in different application scenarios.
[0018] The core of the scalable general blockchain performance boundary measurement framework proposed in this invention is the scalable general blockchain performance boundary measurement framework and the performance boundary construction acceleration algorithm based on pruning search. The design of this framework and the analysis of the performance boundary construction algorithm are the key points of this invention and its protection.
[0019] Specifically, this invention provides a scalable, general-purpose method for measuring blockchain performance boundaries, including:
[0020] Step 1: Construct a blockchain performance measurement framework consisting of a master node and slave nodes. The slave node contains a startup module, a performance monitoring module, and a stress testing module; the master node contains a control module, a data storage module, and a parameter optimization module.
[0021] Step 2: In the startup module, set the parameter range and initial parameter configuration; in the stress test module, set the transaction type and sending rate; in the performance monitoring module, set the data structure for monitoring performance indicators and the data collection location for performance indicators.
[0022] Step 3: The startup module configures and deploys the test blockchain according to the parameters; the stress test module sends transactions to the test blockchain according to the set transaction type and sending rate; the performance monitoring module monitors the performance indicators on the chain according to the specified collection frequency and collection location, and sends the collected performance indicator data to the control module of the master node.
[0023] Step 4: After receiving the performance index data, the control module merges it with the parameter configuration sent to the slave node into a single record and sends it to the data storage module of the master node. The parameter optimization module of the master node reads historical data from the data storage module, compares it with the performance index data of the parameter configuration test before this optimization, determines whether it is a valid optimization, stores the iterative data, updates the parameter configuration according to the optimization strategy, and sends the updated parameter configuration to the slave node. Step 3 is executed again until the monitored performance index data reaches the preset stopping condition. The performance index of the test blockchain under each parameter configuration is recorded, constituting the performance boundary of the test blockchain.
[0024] Step 5: Based on the performance boundary, determine the set of configuration parameters that best meet the specific requirements, so as to configure the test blockchain to achieve the best performance under the specific requirements.
[0025] The scalable general blockchain performance boundary measurement method is described above. The blockchain performance measurement framework is a distributed cluster architecture. The control module distributes multiple sets of parameter configurations generated by the parameter adjustment module to the designated slave servers. All slave servers execute steps 2 and 3 in parallel.
[0026] The scalable, general-purpose blockchain performance boundary measurement method, wherein the optimization strategy includes:
[0027] Step 41: The user initializes the algorithm and generates a series of parameters. In the first iteration, the range of these adjusted parameters includes... Parameters The initial value is as well as Each corresponding performance index Value The optimization objective is normalized, and weights are assigned to each performance metric. Weighting:
[0028] ;
[0029] Each set of parameters is treated as a node in the tree, and the combination of parameters serves as a unique identifier for the node. Child nodes are generated by adjusting the parameter combinations. Initially, the node... Each parameter in each node has the same probability of being selected for each adjustment direction. ;
[0030] Step 42, randomly select a parameter each time. The value was changed to , To adjust parameters The step size is used to obtain the node. ;
[0031] Step 43, determine the parameter combination The result of running Is it greater than ,in If the error is due to performance error, then the adjustment result is considered a valid optimization, and the parameter adjustment in the next iteration of this child node will be improved. The probability of the value Otherwise, proceed to step 44.
[0032] In step 44, the child node will not be recorded, and the subsequent branches of its parent node will be pruned without further parameter adjustments.
[0033] Step 45: Repeat step 42 for iteration. Each time a node is generated, the tree will be checked to see if it exists. If it exists, it will be skipped and the parameter on that node will not be adjusted again. This process continues until the parameter adjustments on all nodes can no longer be recorded. The current tree structure is then saved. All leaf nodes on the tree constitute the performance boundary of the test blockchain.
[0034] The scalable, general blockchain performance boundary measurement method, wherein the specific requirement is at least one specific parameter value within the adjustment parameter range.
[0035] This invention also proposes a scalable, general-purpose blockchain performance boundary measurement device, comprising:
[0036] Module 1 is used to build a blockchain performance measurement framework consisting of a master node and slave nodes. The slave node contains a startup module, a performance monitoring module, and a stress testing module; the master node contains a control module, a data storage module, and a parameter optimization module.
[0037] Module 2 is used to set the parameter range and initial parameter configuration in the startup module; to set the transaction type and sending rate in the stress test module; and to set the data structure and data collection location for monitoring performance indicators in the performance monitoring module.
[0038] Module 3 is used for the startup module to configure and deploy the test blockchain according to the parameters; the stress testing module to send transactions to the test blockchain according to the set transaction type and sending rate; and the performance monitoring module to monitor the performance indicators on the chain according to the specified collection frequency and collection location, and send the collected performance indicator data to the control module of the master node.
[0039] Module 4 is used to control the merging of the performance index data received by the control module with the parameter configuration sent to the slave node into a single record, which is then sent to the data storage module of the master node. The parameter optimization module of the master node reads historical data from the data storage module, compares it with the performance index data of the parameter configuration test before this optimization, determines whether it is a valid optimization, stores the iterative data, updates the parameter configuration according to the optimization strategy, and sends the updated parameter configuration to the slave node. Module 3 is executed again until the monitored performance index data reaches the preset stopping condition. The performance index of the test blockchain under each parameter configuration is recorded, constituting the performance boundary of the test blockchain.
[0040] Module 5 is used to determine the optimal set of configuration parameters that meet the specific requirements based on the performance boundary, so as to configure the test blockchain to achieve the best performance under the specific requirements.
[0041] The aforementioned scalable general blockchain performance boundary measurement device, wherein the blockchain performance measurement framework is a distributed cluster architecture, the control module distributes multiple sets of parameter configurations generated by the parameter adjustment module to designated slave servers, and all slave servers execute modules 2 and 3 in parallel.
[0042] The aforementioned scalable general-purpose blockchain performance boundary measurement device, wherein the optimization strategy includes:
[0043] Module 41, used in the first iteration, includes the following adjustment parameter range: Parameters The initial value is as well as Each corresponding performance index Value The optimization objective is normalized, and weights are assigned to each performance metric. Weighting:
[0044] ;
[0045] Each set of parameters is treated as a node in the tree, and the combination of parameters serves as a unique identifier for the node. Child nodes are generated by adjusting the parameter combinations. Initially, the node... Each parameter in each node has the same probability of being selected for each adjustment direction. ;
[0046] Module 42 is used to randomly select a parameter each time. The value was changed to , To adjust parameters The step size is used to obtain the node. ;
[0047] Module 43 is used to determine parameter combinations. The result of running Is it greater than ,in If the error is due to performance error, then the adjustment result is considered a valid optimization, and the parameter adjustment in the next iteration of this child node will be improved. The probability of the value If the remaining unadjusted parameters have equal adjustment probabilities, then execute module 44.
[0048] Module 44 is used to ensure that the child node will not be recorded and that subsequent branches of its parent node will be pruned, and that its parameters will no longer be adjusted.
[0049] Module 45 is used to execute Module 42 again for iteration. Each iteration generates a node and checks if it exists in the tree. If it exists, it is skipped and the parameter on that node is no longer adjusted. This continues until the parameter adjustments on all nodes can no longer be recorded. The current tree structure is then saved, and all leaf nodes in the tree constitute the performance boundary of the test blockchain.
[0050] The aforementioned scalable general-purpose blockchain performance boundary measurement device, wherein the specific requirement is at least one specific parameter value within the adjustment parameter range.
[0051] The present invention also proposes a server, which includes the aforementioned universal blockchain performance boundary measurement device.
[0052] The present invention also proposes a storage medium for storing a computer program that executes any of the general blockchain performance boundary measurement methods.
[0053] The technological advancements of this invention lie in its ability to test any connectable blockchain, its convenient adaptation to different types and sizes of blockchains, its ability to adjust multiple parameters and customize performance metrics according to user needs, and its use of measured data to construct blockchain performance boundaries, helping users pinpoint performance bottlenecks and optimize parameters. To address the issue of excessively large search space when constructing performance boundaries, a performance boundary construction acceleration algorithm based on pruning search is designed, reducing search space complexity, improving operational efficiency, and avoiding getting trapped in local optima. Compared to existing blockchain performance measurement frameworks, this invention significantly improves system scalability and provides users with optimization guidance by constructing performance boundaries. Attached Figure Description
[0054] Figure 1 This is a diagram of the performance boundary measurement framework architecture of the present invention;
[0055] Figure 2 This is a flowchart illustrating the operation of the performance boundary measurement framework of this invention.
[0056] Figure 3 This is a flowchart of the performance boundary construction acceleration algorithm based on pruning search in this invention. Detailed Implementation
[0057] While researching blockchain performance measurement frameworks, the inventors discovered that existing frameworks could not meet users' requirements for scalability, universality, accuracy, and efficiency. To address these needs, the inventors proposed a blockchain performance measurement framework that follows a pluggable design principle to achieve high scalability. It employs a method of adjusting on-chain configuration parameters to measure real-world blockchain systems operating under different environments, yielding accurate measurement results. These results can be used to construct blockchain performance boundaries, providing guidance for identifying performance bottlenecks and optimizing performance.
[0058] Addressing the issues of most blockchain performance frameworks being limited to measuring only specific performance metrics and exhibiting low measurement efficiency, this invention offers scalability and efficiency. Scalability encompasses two aspects:
[0059] First, the measurement metrics are scalable. Users can customize the data structure and data collection location of the performance metrics they need to measure, and add new measurement metrics according to their measurement requirements.
[0060] Secondly, the framework is scalable. This invention adopts a distributed system Master-worker architecture, which can control multiple test blockchains with different configurations to run in parallel for measurement work, thereby improving the efficiency of measuring blockchains with multiple parameter configurations.
[0061] Addressing the issue that current blockchain measurement frameworks can only support specific blockchain platforms, this invention is universal and can be easily integrated into various blockchain platforms without significantly impacting the performance of the blockchain itself.
[0062] To address the issue of excessively large search space caused by the complex parameter configurations of blockchain systems when constructing performance boundaries, this invention designs a probabilistic pruning search algorithm. This algorithm prunes the search space of the configuration parameters, accelerating the construction of performance boundaries. Simultaneously, based on probabilistic selection, it avoids the results getting trapped in local optima. This invention enables performance measurement of different blockchain platforms, rapidly constructing the performance boundaries of blockchain systems. The constructed performance boundaries facilitate a deeper understanding of blockchain systems, pinpointing performance bottlenecks, and providing guidance for optimizing blockchain parameter configurations in different application scenarios.
[0063] To achieve scalability of the performance boundary measurement framework, this invention adopts a multi-modal design, mainly consisting of five modules: startup module, stress testing module, performance monitoring module, control module, data storage module, and parameter optimization module.
[0064] 1. Startup Module
[0065] In this module, users define which configuration parameters can be adjusted, and based on the received on-chain parameter configuration, adjust the on-chain configuration parameters, generate a new configuration file, and start the corresponding blockchain.
[0066] 2. Stress testing module
[0067] The module applies a load to the blockchain under test via client-side methods, i.e., sends transactions to the blockchain at a set rate. It includes settings options, allowing users to configure different transaction types and sending frequencies to perform performance tests based on their specific testing needs.
[0068] 3. Performance Monitoring Module
[0069] This module is responsible for collecting and storing on-chain performance metrics. Users need to define the data structure and collection location of the on-chain performance metrics they need to collect within this module, according to their requirements. For each defined performance metric, there is a corresponding configuration that allows dynamic control over whether to collect the metric and the collection frequency during the measurement process.
[0070] 4. Control Module
[0071] This module is responsible for collecting monitoring performance data from each worker node and sending it to the data storage module, managing and recording the running status of each worker, and sending new parameter combinations generated by the parameter optimization module to idle workers. A worker can run on a server.
[0072] 5. Data storage module
[0073] It is responsible for recording the parameter configurations and corresponding performance indicators summarized by the control module into a database or file for subsequent data analysis and recording the results of each iteration of the parameter optimization module.
[0074] 6. Parameter Optimization Module
[0075] The system retrieves collected parameter configurations and performance metrics from the data storage module, selects a specific optimization algorithm, optimizes based on historical parameter configurations, generates new configuration parameters, and sends them to the parameter tuning module. The specific algorithm within this module will be described in the next section.
[0076] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.
[0077] like Figure 1As shown, before the framework runs, users need to perform several initialization steps: In the startup module, set which configuration parameters are adjustable and which are not, for example, with fixed node network bandwidth and network topology, block size, block generation interval, consensus algorithm, and timeout for each stage of the consensus algorithm can be adjusted; In the control module, configure the number of workers and input initial parameter configurations. After setting the fixed, non-adjustable configurations, all other parameters are set to default. After setting the bandwidth of each node and the connection topology between nodes, all other parameters are set to the default configuration of the blockchain system, i.e., the initial parameter configuration; In the stress testing module, set the transaction type and sending rate; In the performance monitoring module, define the data structure of the performance metrics to be monitored and the collection location of the performance metrics. This data structure can be, for example, ID, transaction hash, current timestamp, and the location where the transaction data was collected. The collection location refers to where a transaction needs to be detected and recorded. For example, to measure transaction latency, this "location" refers to the two key points in the program's execution: when the transaction enters the transaction pool and when it is packaged into a block. The latency is calculated by collecting records of transactions at these two points (transaction hash, transaction occurrence time) and then subtracting the occurrence time of the same transaction at these two points. In the example above, the data structure could be the transaction hash, occurrence time, and the function in which the data was collected. The "location" refers to the execution points in the code where the transaction enters the transaction pool and is packaged into a block.
[0078] After the framework starts, the control module selects an idle worker, sends the initial parameter configuration to the worker's startup module, and updates the worker's status. The control module maintains a dedicated data structure for the current status of each worker. During initialization, all workers are in an idle state. After the control module distributes tasks to the workers, it modifies the status of the corresponding worker to "working". After receiving the test results returned by the worker, it changes the worker's status back to idle.
[0079] The startup module first deploys the test blockchain according to the received parameter configuration. The stress testing module sends transactions to the test blockchain according to pre-set parameters and can update the applied transaction load according to actual needs, including the type and rate of the sent transaction load. The performance monitoring module monitors the on-chain performance indicators according to the set collection switch and collection frequency, and sends the collected data to the control module. The control module receives the performance indicators from the worker, merges them with the parameter configuration sent to that worker into a record, and sends it to the data storage module in the master. The parameter optimization module reads historical data from the data storage module, compares it with the results of parameter configuration tests before the current optimization, determines whether it is an effective optimization, stores iterative data, and, based on the optimization algorithm (e.g., grid search algorithm: traversing all possible combinations of parameters, with high search complexity; gradient search algorithm: only suitable for scenarios where the function to be optimized is differentiable, and the complex relationship between blockchain parameters and performance is difficult to express with a specific expression), provides a set of optimized and adjustable parameter values, and sends the new parameter combination to the control module for distribution. The startup module updates the configuration file according to the new parameters and restarts the blockchain using the new configuration file. The above steps form a loop. During the loop, the load of the stress test and the configuration of the performance monitoring can be dynamically updated and modified according to the actual needs of the user. The iteration stops when the monitored data reaches the stopping condition of the algorithm. The parameter optimization module will give the performance boundary of the blockchain system in the current environment.
[0080] Meanwhile, to improve operational efficiency, the algorithm module and measurement framework adopt a distributed cluster architecture design. The algorithm module and storage module serve as the master layer and run on a single machine. The worker layer deploys startup, load testing, monitoring modules, and test chains on multiple machines. The control module in the control layer can distribute multiple sets of parameters generated by the parameter adjustment module to other machines for simultaneous testing. This multi-process collaboration solves the problem of long iteration times to some extent.
[0081] Compared to other performance measurement frameworks, this framework has the following advantages:
[0082] Highly efficient and scalable, compared to other frameworks that can only measure specific performance metrics, it can expand the number of machines to be measured, thus improving efficiency; and it can customize and expand the types of performance metrics to be measured, making it more comprehensive.
[0083] Versatility. It requires minimal modification to the blockchain; only the data collection location needs to be marked, making it adaptable to different types of blockchains.
[0084] Accuracy. Measurements are performed using actual blockchains, rather than through simulators and modeling, resulting in highly accurate performance metrics.
[0085] To address the performance issues of traditional optimization algorithms, this application also proposes an accelerated algorithm based on performance boundary construction using pruning search:
[0086] For optimization algorithms of configuration parameters, traversing all parameter combinations can effectively construct the performance boundary of the blockchain system. However, blockchain is a complex system. Although each parameter has a limited adjustable range, a large number of adjustable parameters still leads to an excessively large space of parameter combinations, making it difficult to construct the performance boundary within the required time, thus failing to meet efficiency requirements. Gradient-based optimization algorithms require a function relating blockchain parameters to performance; however, the relationship between blockchain parameters and performance is difficult to express simply with an expression, rendering gradient-based optimization algorithms unusable. Therefore, this invention proposes a probability-based pruning search boundary algorithm. The specific steps of the algorithm are as follows:
[0087] 1. The user initializes the algorithm and generates a series of parameters. In the first iteration, assume there are... One adjustable parameter The initial value is as well as Each corresponding performance index The value is (optimization objective). Because different performance metrics can differ by orders of magnitude, the optimization objective needs to be normalized according to requirements, and a weight should be assigned to each performance metric. Weighting is applied.
[0088]
[0089] 2. Treat each set of parameters as a node in a tree. The combination of parameters serves as a unique identifier for each node. Adjusting the current parameter combination is equivalent to creating a child node of that node. Initially, there is only one node. Each parameter in each node has the same probability of being selected for each adjustment direction. (in Indicates at node Adjusting parameters The probability, Each time, a parameter is randomly selected. The value was changed to , To adjust parameters The step size is used to obtain the node. .
[0090] 3. Based on parameter combinations The result of running If the result is greater than That is, the result is better than the parent node and exceeds the set performance error. If the result of this adjustment is deemed a valid optimization, it will improve the parameter adjustment in the next iteration of this child node. The probability of the value The adjustment probability of the remaining unadjusted parameters remains equal.
[0091] 4. If the result is not a valid optimization, the child node will not be recorded, and the subsequent branches of its parent node will be pruned without further parameter adjustments.
[0092] 5. Continuously iterate. Each iteration generates a node and checks if it exists in the tree. If it exists, skip it and do not adjust the parameter of that node again. Continue this process until the parameters of all nodes can no longer be adjusted. The entire parameter optimization process then forms a tree, starting from the root node. The path to any leaf node is the optimized path, and all the leaf nodes in this tree constitute the performance boundary of the blockchain under the current constraints.
[0093] Compared to traversal algorithms, this algorithm prunes unnecessary branches during the search process, resulting in faster search speed, fewer iterations, and the ability to construct a usable performance boundary in a shorter time. Compared to gradient-based optimization algorithms and various models, it does not require exploring the relationship between parameters and performance metrics, nor does it require significant computational resources to build a model. Its computational overhead is low, and the results are derived from actual blockchain systems, ensuring high accuracy. The algorithm stores the intermediate optimization process and optimization path in a tree structure, which can guide parameter adjustments in practical applications, quickly identify bottlenecks, and optimize accordingly. The probabilistic approach also ensures that the algorithm can optimize in multiple directions, avoiding getting trapped in local optima.
[0094] Step s1.1 Framework initialization. Set the parameters that need to be adjusted, define the data structure and data collection location for the performance metrics to be monitored, and the number of blockchain processes.
[0095] Step s1.2 Set the detection switch and monitoring frequency of the performance monitoring module for on-chain performance indicators, and set the weight of each performance indicator when there are multiple performance indicators.
[0096] Step s1.3 Input the initialization parameter configuration of the blockchain system in the control module.
[0097] Step s1.4 The control module selects an idle worker, distributes the received parameter configuration to its startup module, and updates the worker's status.
[0098] Step s1.5 The startup module generates a configuration file based on the parameter configuration and starts the blockchain.
[0099] Step s1.6 The monitoring module generates performance indicators based on the preset frequency and the data on the switch acquisition chain, and sends the performance indicators to the control module.
[0100] Step s1.7 The control module merges the received performance metrics with the parameter configurations sent to the worker into a single data entry, records it in the data storage module, and updates the worker's status.
[0101] Step s1.8: The parameter optimization module reads historical records from the data storage module and determines whether the termination condition has been met, i.e., whether the probability of adjusting all parameters of all nodes in the tree constructed by the algorithm is 0. If not, the historical configuration parameters are adjusted, the next configuration parameters are generated, and sent to the control module; otherwise, the parameter adjustment ends, and the performance boundary is output.
[0102] Step s1.9 Repeat steps s1.4-1.8 using the newly generated parameter configuration.
[0103] Finally, based on specific requirements, the optimal set of configuration parameters is found within this performance boundary to achieve the best performance for the blockchain. During actual operation within this performance boundary, a certain adjustable parameter may change. This performance boundary allows for faster adjustment of other variable parameters to obtain an optimal parameter combination suitable for the current environment. For example, if a parameter was initially 0, the optimal performance configuration parameter combination can be found within this performance boundary; when the parameter becomes 1, the optimal performance configuration parameter combination when the parameter is 1 can be found within this performance boundary.
[0104] (2) Acceleration algorithm process based on performance boundary construction of pruning search
[0105] Step s2.1 Initialize the algorithm and define the weights of each performance metric. ,error Adjustment step size of each parameter .in The number of performance metrics to be modified is denoted by m, where m is the number of parameters to be adjusted.
[0106] Step s2.2 Read the initial configuration and its monitored performance metrics from the data storage module, and construct the root node of the tree. Each node is uniquely identified by a combination of parameter values.
[0107] Step s2.3: Based on the probability of each parameter being selected at each node, select a parameter value to modify. This represents the current iteration round.
[0108] Step s2.4 Search the constructed tree for... Does the identified node exist? If it does, then... Set to 0 ( For nodes of (Probability of parameter adjustment), repeat s2.3. If not found, send to an idle startup module for deployment testing. Wait for the monitoring module to write the results to the data storage module.
[0109] Step s2.5: Read the configuration parameters and performance metrics from the previous iteration from the data storage module, and calculate the weighted result as follows: ,like If the t-th iteration is considered a valid optimization, the iteration result is written to the data storage module, and the node is saved as a child node of the previous iteration node, thus improving the selection of parameters in the next iteration. The probability. If it is an invalid optimization, ignore the previous adjustment record and set it as... Set to 0.
[0110] Step s2.6: Determine if the probability of all parameters on all nodes being modified is 0. If yes, the algorithm stops, and the leaf nodes of the constructed tree at this point represent the performance boundary. If any probability is non-zero, continue iterating.
[0111] Step s2.7 repeats steps s2.3-2.6.
[0112] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.
[0113] This invention also proposes a scalable, general-purpose blockchain performance boundary measurement device, comprising:
[0114] Module 1 is used to build a blockchain performance measurement framework consisting of a master node and slave nodes. The slave node contains a startup module, a performance monitoring module, and a stress testing module; the master node contains a control module, a data storage module, and a parameter optimization module.
[0115] Module 2 is used to set the parameter range and initial parameter configuration in the startup module; to set the transaction type and sending rate in the stress test module; and to set the data structure and data collection location for monitoring performance indicators in the performance monitoring module.
[0116] Module 3 is used for the startup module to configure and deploy the test blockchain according to the parameters; the stress testing module to send transactions to the test blockchain according to the set transaction type and sending rate; and the performance monitoring module to monitor the performance indicators on the chain according to the specified collection frequency and collection location, and send the collected performance indicator data to the control module of the master node.
[0117] Module 4 is used to control the merging of the performance index data received by the control module with the parameter configuration sent to the slave node into a single record, which is then sent to the data storage module of the master node. The parameter optimization module of the master node reads historical data from the data storage module, compares it with the performance index data of the parameter configuration test before this optimization, determines whether it is a valid optimization, stores the iterative data, updates the parameter configuration according to the optimization strategy, and sends the updated parameter configuration to the slave node. Module 3 is executed again until the monitored performance index data reaches the preset stopping condition. The performance index of the test blockchain under each parameter configuration is recorded, constituting the performance boundary of the test blockchain.
[0118] Module 5 is used to determine the optimal set of configuration parameters that meet the specific requirements based on the performance boundary, so as to configure the test blockchain to achieve the best performance under the specific requirements.
[0119] The aforementioned scalable general blockchain performance boundary measurement device, wherein the blockchain performance measurement framework is a distributed cluster architecture, the control module distributes multiple sets of parameter configurations generated by the parameter adjustment module to designated slave servers, and all slave servers execute modules 2 and 3 in parallel.
[0120] The aforementioned scalable general-purpose blockchain performance boundary measurement device, wherein the optimization strategy includes:
[0121] Module 41, used in the first iteration, includes the following adjustment parameter range: Parameters The initial value is as well as Each corresponding performance index Value The optimization objective is normalized, and weights are assigned to each performance metric. Weighting:
[0122] ;
[0123] Each set of parameters is treated as a node in the tree, and the combination of parameters serves as a unique identifier for the node. Child nodes are generated by adjusting the parameter combinations. Initially, the node... Each parameter in each node has the same probability of being selected for each adjustment direction. ;
[0124] Module 42 is used to randomly select a parameter each time. The value was changed to , To adjust parameters The step size is used to obtain the node. ;
[0125] Module 43 is used to determine parameter combinations. The result of running Is it greater than ,in If the error is due to performance error, then the adjustment result is considered a valid optimization, and the parameter adjustment in the next iteration of this child node will be improved. The probability of the value If the remaining unadjusted parameters have equal adjustment probabilities, then execute module 44.
[0126] Module 44 is used to ensure that the child node will not be recorded and that subsequent branches of its parent node will be pruned, and that its parameters will no longer be adjusted.
[0127] Module 45 is used to execute Module 42 again for iteration. Each iteration generates a node and checks if it exists in the tree. If it exists, it is skipped and the parameter on that node is no longer adjusted. This continues until the parameter adjustments on all nodes can no longer be recorded. The current tree structure is then saved, and all leaf nodes in the tree constitute the performance boundary of the test blockchain.
[0128] The aforementioned scalable general-purpose blockchain performance boundary measurement device, wherein the specific requirement is at least one specific parameter value within the adjustment parameter range.
[0129] The present invention also proposes a server, which includes the aforementioned universal blockchain performance boundary measurement device.
[0130] The present invention also proposes a storage medium for storing a computer program that executes any of the general blockchain performance boundary measurement methods.
[0131] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.
Claims
1. A scalable and general-purpose method for measuring the performance boundary of a blockchain, characterized in that, include: Step 1: Construct a blockchain performance measurement framework consisting of a master node and slave nodes. The slave node contains a startup module, a performance monitoring module, and a stress testing module; the master node contains a control module, a data storage module, and a parameter optimization module. Step 2: In the startup module, set the parameter range and initial parameter configuration; in the stress test module, set the transaction type and sending rate; in the performance monitoring module, set the data structure for monitoring performance indicators and the data collection location for performance indicators. Step 3: The startup module configures and deploys the test blockchain according to the parameters; the stress test module sends transactions to the test blockchain according to the set transaction type and sending rate; the performance monitoring module monitors the performance indicators on the chain according to the specified collection frequency and collection location, and sends the collected performance indicator data to the control module of the master node. Step 4: After receiving the performance index data, the control module merges it with the parameter configuration sent to the slave node into a single record and sends it to the data storage module of the master node. The parameter optimization module of the master node reads historical data from the data storage module, compares it with the performance index data of the parameter configuration test before this optimization, determines whether it is a valid optimization, stores the iterative data, updates the parameter configuration according to the optimization strategy, and sends the updated parameter configuration to the slave node. Step 3 is executed again until the monitored performance index data reaches the preset stopping condition. The performance index of the test blockchain under each parameter configuration is recorded, constituting the performance boundary of the test blockchain. Step 5: Determine the set of configuration parameters that best meet the specific requirements based on the performance boundary, so as to configure the test blockchain to achieve the best performance under the specific requirements; The optimization strategy includes: Step 41: The user initializes the algorithm and generates a series of parameters. In the first iteration, the range of these adjusted parameters includes... Parameters The initial value is as well as Each corresponding performance index Value The optimization objective is normalized, and weights are assigned to each performance metric. Weighting: ; Each set of parameters is treated as a node in the tree, and the combination of parameters serves as a unique identifier for the node. Child nodes are generated by adjusting the parameter combinations. Initially, the node... Each parameter in each node has the same probability of being selected for each adjustment direction. ; Step 42, randomly select a parameter each time. The value was changed to , To adjust parameters The step size is used to obtain the node. ; Step 43, determine the parameter combination The result of running Is it greater than ,in If the error is due to performance error, then the adjustment result is considered a valid optimization, and the parameter adjustment in the next iteration of this child node will be improved. The probability of the value Otherwise, proceed to step 44. In step 44, the child node will not be recorded, and the subsequent branches of its parent node will be pruned without further parameter adjustments. Step 45: Repeat step 42 for iteration. Each time a node is generated, the tree will be checked to see if it exists. If it exists, it will be skipped and the parameter on that node will not be adjusted again. This process continues until the parameter adjustments on all nodes can no longer be recorded. The current tree structure is then saved. All leaf nodes on the tree constitute the performance boundary of the test blockchain.
2. The scalable and general blockchain performance boundary measurement method as described in claim 1, characterized in that, The blockchain performance measurement framework is a distributed cluster architecture. The control module distributes multiple sets of parameter configurations generated by the parameter adjustment module to the designated slave servers. All slave servers execute steps 2 and 3 in parallel.
3. The scalable and general blockchain performance boundary measurement method as described in claim 1, characterized in that, The specific requirement is at least one specific parameter value within the range of adjustment parameters.
4. A scalable, general-purpose blockchain performance boundary measurement device, characterized in that, include: Module 1 is used to build a blockchain performance measurement framework consisting of a master node and slave nodes. The slave node contains a startup module, a performance monitoring module, and a stress testing module; the master node contains a control module, a data storage module, and a parameter optimization module. Module 2 is used to set the parameter range and initial parameter configuration in the startup module; to set the transaction type and sending rate in the stress test module; and to set the data structure and data collection location for monitoring performance indicators in the performance monitoring module. Module 3 is used for the startup module to configure and deploy the test blockchain according to the parameters; the stress testing module to send transactions to the test blockchain according to the set transaction type and sending rate; and the performance monitoring module to monitor the performance indicators on the chain according to the specified collection frequency and collection location, and send the collected performance indicator data to the control module of the master node. Module 4 is used to control the merging of the performance index data received by the control module with the parameter configuration sent to the slave node into a single record, which is then sent to the data storage module of the master node. The parameter optimization module of the master node reads historical data from the data storage module, compares it with the performance index data of the parameter configuration test before this optimization, determines whether it is a valid optimization, stores the iterative data, updates the parameter configuration according to the optimization strategy, and sends the updated parameter configuration to the slave node. Module 3 is executed again until the monitored performance index data reaches the preset stopping condition. The performance index of the test blockchain under each parameter configuration is recorded, constituting the performance boundary of the test blockchain. Module 5 is used to determine the set of configuration parameters that best meet the specific requirements based on the performance boundary, so as to configure the test blockchain to achieve the best performance under the specific requirements. The scalable general-purpose blockchain performance boundary measurement device is characterized in that the blockchain performance measurement framework is a distributed cluster architecture, and the control module distributes multiple sets of parameter configurations generated by the parameter adjustment module to the designated slave server. All slave servers execute modules 2 and 3 in parallel. The aforementioned scalable general-purpose blockchain performance boundary measurement device is characterized in that the optimization strategy includes: Module 41, used in the first iteration, includes the following adjustment parameter range: Parameters The initial value is as well as Each corresponding performance index Value The optimization objective is normalized, and weights are assigned to each performance metric. Weighting: ; Each set of parameters is treated as a node in the tree, and the combination of parameters serves as a unique identifier for the node. Child nodes are generated by adjusting the parameter combinations. Initially, the node... Each parameter in each node has the same probability of being selected for each adjustment direction. ; Module 42 is used to randomly select a parameter each time. The value was changed to , To adjust parameters The step size is used to obtain the node. ; Module 43 is used to determine parameter combinations. The result of running Is it greater than ,in If the error is due to performance error, then the adjustment result is considered a valid optimization, and the parameter adjustment in the next iteration of this child node will be improved. The probability of the value If the remaining unadjusted parameters have equal adjustment probabilities, then execute module 44. Module 44 is used to ensure that the child node will not be recorded and that subsequent branches of its parent node will be pruned, and that its parameters will no longer be adjusted. Module 45 is used to execute Module 42 again for iteration. Each iteration generates a node and checks if it exists in the tree. If it exists, it is skipped and the parameter on that node is no longer adjusted. This continues until the parameter adjustments on all nodes can no longer be recorded. The current tree structure is then saved, and all leaf nodes in the tree constitute the performance boundary of the test blockchain. The scalable general-purpose blockchain performance boundary measurement device is characterized in that the specific requirement is at least one specific parameter value within the adjustment parameter range.
5. A server, characterized in that, Includes the universal blockchain performance boundary measurement device as described in claim 4.
6. A storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the general blockchain performance boundary measurement method according to any one of claims 1-3.
Citation Information
Patent Citations
BART algorithm and super-absorption wall-based reactive power optimization method for voltage of power grid
CN103618315A
Performance monitoring and tuning system and method for distributed storage system
CN106126407A