EchoFlow: A Workload-Aware Parameter Tuning Method for Blockchain Systems Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
arXiv:2606.22934v1 [cs.DC] 22 Jun 2026
1
Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100190 2 School of Computer Science and Technology, UCAS, Beijing 100049 3 Hangzhou Qulian Technology Co., Ltd., Hangzhou 310051 4 State Key Laboratory of Blockchain and Data Security, ZJU, Hangzhou 310027 5 Beijing Advanced Innovation Center for Future Blockchain and Privacy Computing, Beihang University, Beijing 100191 6 Shandong Key Laboratory Blockchain Finance, Jinan 250014 [email protected]
Abstract. Blockchain systems expose a large number of tunable parameters that significantly influence system performance. However, in practice, a single parameter configuration is often applied across different workloads, leaving substantial unexploited performance potential. To address this, we propose EchoFlow, a blockchain parameter tuning framework that adaptively adjusts parameter configurations based on workload characteristics, enabling continuous performance optimization. EchoFlow employs a distributed reinforcement learning approach in which multiple actors perform parallel sampling to mitigate the substantial time required for sample generation in blockchain environments. To further accelerate convergence, we introduce a genetic algorithm during the initial phase of training to generate high-quality samples. Extensive experimental evaluations demonstrate that EchoFlow consistently outperforms existing methods across diverse workload scenarios while also reducing training time, highlighting its effectiveness and practical value. Keywords: Performance Optimization, Parameter Tuning, Blockchain, Reinforcement Learning
1
Introduction
As a distributed system, the operation of a blockchain system relies on numerous preconfigured system parameters. These parameters affect all phases of the blockchain system, including peer-to-peer communication, consensus execution, and transaction execution. Consequently, parameter configuration has a significant impact on system performance. As illustrated in Fig. 1, adjusting only two parameters in Hyperledger Fabric [1] leads to substantial performance variations. This also implies that appropriate parameter tuning can significantly enhance the performance of blockchain systems. For instance, prior research [2, 3] has shown that properly adjusting the number of transactions per block can significantly improve blockchain throughput, and that further optimization of
2
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
this parameter leads to continued performance gains until the system converges to a stable state. More importantly, the parameter tuning approach does not alter the core operational logic of the blockchain system, indicating that it is independent of existing performance optimization techniques. Given that current blockchain platforms are relatively mature yet still have room for performance improvement, this method enables blockchain systems to approach their theoretical performance limits.
Fig. 1. Throughput variations under two-parameter tuning
Fig. 2. Optimal parameter under different workload patterns
However, determining appropriate parameter configurations is far from trivial. Blockchain systems expose a large number of tunable parameters, and complex nonlinear interdependencies exist among them. Consequently, blockchain parameter tuning constitutes a high-dimensional optimization problem in a multiparameter space. In practice, parameter configuration in most blockchain deployments is still conducted manually or based on expert-recommended settings. Such approaches are not only inefficient but may also be unable to achieve optimal performance. To address this issue, various automatic parameter tuning techniques have been proposed, among which deep reinforcement learning (DRL)-based approaches [4,5] have attracted particular attention and have gradually become mainstream. Compared with traditional machine learning or search-based methods, DRLbased approaches can learn effective parameter adjustment policies through trialand-error exploration and typically achieve superior performance. Nevertheless, existing DRL-based methods still face several unresolved challenges in real-world blockchain systems. Challenge 1: How to Achieve Workload-Aware Dynamic Parameter Tuning? In practice, blockchain systems operate under dynamically varying workloads [6], and the optimal parameter configuration is not static across different workload conditions. As illustrated in Fig. 2, we measure the throughput of Hyperledger Fabric under four different workloads, showing that the optimal parameter setting varies across distinct workload patterns. Therefore, the ability to dynamically adjust system parameters in response to workload changes
EchoFlow: A Workload-Aware Parameter Tuning Method
3
is critical to the effectiveness of optimization methods in practical deployments. However, existing studies do not fully support dynamic parameter adaptation based on workload variations. For example, Athena [4] primarily trains its optimization model under a single workload scenario, while TuneChain [5] trains its model using the transaction conflict ratio as the workload characteristic, which may not capture finer-grained workload variations. Challenge 2: How to Accelerate DRL Training Under Diverse Workloads? The training of DRL models relies on interactions between the agent and the environment. However, a critical bottleneck arises during interaction with the blockchain system: each parameter adjustment requires a system restart for the new configuration to take effect. This process incurs substantial overhead, making performance feedback costly and significantly limiting training efficiency, especially when large numbers of samples are required under diverse workloads. In this paper, we design and implement a workload-aware automatic parameter tuning approach, EchoFlow, for blockchain systems. Compared with existing DRL-based approaches [4, 5] for blockchain parameter tuning, our work further addresses the two aforementioned critical challenges. To tackle Challenge 1, we analyze blockchain workload characteristics and model them as a workload feature vector that captures three dimensions: workload scale, transaction type, and access pattern. We then extend the original DRL framework by incorporating this workload feature vector into the state space, enabling the trained DRL agent to dynamically adjust parameter configurations according to varying workload types. This design facilitates adaptive performance optimization under dynamic workload conditions. To tackle Challenge 2, we propose a distributed DRL training method, in which multiple distributed-actors interact with the environment in parallel to collect samples. Furthermore, we introduce a genetic algorithm-based method to generate a large number of high-quality samples covering representative workload scenarios. These designs mitigate the substantial time required for sample generation in blockchain environments, thereby accelerating training. We summarize our main contributions as follows: • We model blockchain workload characteristics and propose EchoFlow, a workload-aware parameter tuning framework that adaptively adjusts system configurations according to observed workload patterns, enabling continuous performance optimization. • We employ a distributed DRL training method with multiple actors performing parallel sampling to reduce the time required for sample generation, and introduce a genetic algorithm-based method to generate high-quality initial samples for DRL training, improving training efficiency. • Extensive experimental evaluations show that, compared with existing approaches, our method dynamically adjusts parameters under diverse workload conditions, achieves superior performance, and effectively accelerates the training process.
4
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
2
Formulation
2.1
Blockchain Parameters
The Execute-Order-Validate (EOV) architecture is a representative blockchain architecture aimed at improving performance and flexibility. It is widely adopted in permissioned blockchain scenarios, with Fabric [1] serving as a prominent implementation. Using Fabric as an example, we analyze in detail how numerous parameters in a blockchain system influence different stages. Table 1. Tunable parameters in Fabric
Phase Tunable Parameters Execution Phase CORE PEER CLIENT CONNTIMEOUT, CORE PEER AUTHENTICATION TIMEWINDOW, CORE PEER KEEPALIVE CLIENT INTERVAL, ... Ordering Phase ORDERER RAMLEDGER HISTORYSIZE, MaxMessageCount, PreferredMaxBytes, ... Validation Phase CORE PEER GOSSIP PULLINTERVAL, CORE PEER GOSSIP SENDBUFFSIZE, CORE PEER GOSSIP STATE BATCHSIZE, ... Execution Phase. The client sends transaction proposals to peer nodes, and each peer verifies and executes the proposal. The execution results are not immediately committed to the local ledger; instead, they are returned to the client as signed proposal responses. The tunable parameters in this phase primarily affect the communication between clients and peer nodes. Ordering Phase. After collecting a sufficient number of proposal responses, the client packages them and submits them to the ordering nodes. The leader ordering node sorts all transactions according to the consensus protocol (e.g., Raft) and packages them into blocks. The tunable parameters in this phase mainly affect message reception by ordering nodes and block formation. Validation Phase. The ordering nodes broadcast newly generated blocks to peer nodes, and these blocks are also synchronized across peers. Upon receiving a block, each peer validates the transactions contained within it and immutably commits valid transactions to its local ledger. The tunable parameters in this phase mainly affect block dissemination and synchronization. 2.2
Workload Characterization
Characterizing blockchain workloads requires a systematic analysis to capture the complexity of real-world deployments. In this work, we summarize blockchain workloads as three core characteristics—workload scale, transaction type, and access pattern—to facilitate effective differentiation among heterogeneous workload scenarios.
EchoFlow: A Workload-Aware Parameter Tuning Method
5
1) Workload Scale. In real blockchain networks, request loads are highly dynamic and often non-stationary, frequently exhibiting unpredictable and irregular burst patterns [6]. For example, in Ethereum, the instantaneous transaction request rate—measured in queries per second (QPS)—can reach up to 6.1 times the daily minimum value. To quantitatively capture such dynamics, we use two variables, µ and β, to represent the QPS p and the degree of QPS variation. They are defined as follows: µ = E[λ(t)], β = E[(λ(t) − µ)2 ]/µ, where λ(t) denotes the instantaneous QPS. A larger β indicates stronger burstiness, and β > 1 implies substantial workload variability. 2) Transaction Type. Transactions in blockchain systems are heterogeneous, and different transaction types exhibit distinct performance bottlenecks [7]. For instance, read operations are primarily limited by state lookup efficiency, whereas write operations involve state updates, are more affected by the consensus process, and may introduce conflicts when accessing shared data. Therefore, it is necessary to characterize both read and write operations within transactions. Accordingly, we define each transaction τi as (ri , wi ), where ri denotes the read intensity, representing the number of state data retrievals, and wi denotes the write intensity, representing the number of state modification operations. For example, a typical transfer transaction can be defined as τt = (2, 2). 3) Access Pattern. Access to blockchain state data is typically non-uniform and exhibits significant skewness. A small number of hot accounts are accessed frequently, whereas the majority of accounts receive minimal access [6]. Therefore, we model the access probability of the k-th most frequently accessed account α as: P (k) = PN1/k1/iα , which follows a Zipf distribution. In the formulation N i=1 denotes the total number of accounts, and α is the skewness parameter that controls the concentration of the distribution. When α = 0, the access probability follows a uniform distribution. As α increases, access becomes more concentrated on top-ranked hot accounts, resulting in a more skewed distribution. 2.3
Optimization Objective
Our objective is to determine an optimal parameter configuration X ∗ under a given workload W , such that the system performance metric J is maximized. The performance objective function J(X; W ) can be defined according to specific optimization requirements. For example: J = throughput(X; W )
maximize throughput
J = −latency(X; W ) Pn J = i=1 ωi fi (X; W )
minimize average latency multi-objective optimization
The overall optimization problem is therefore formulated as: X ∗ = arg max J(X; W ). X∈Ω
In the formulation, W = (µ, β, r̄, w̄, α) denotes the workload feature vector, which characterizes workload scale (average QPS µ and variability β), transaction type (average read intensity r̄ and average write intensity w̄), and access
6
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
pattern (access skewness α). X = (x1 , x2 , · · · , xn ) represents a complete system parameter configuration, including tunable parameters across the Execution, Ordering, and Validation phases. Ω denotes the feasible configuration space.
3
EchoFlow Parameter Tuning Framework
3.1
Framework
Fig. 3. The overview of EchoFlow
To enable workload-aware automatic parameter tuning, we design and implement the EchoFlow framework. The overall framework of EchoFlow is illustrated in Fig 3. Similar to most DRL-based frameworks, it consists of two primary components: the Agent and the Environment. The Environment consists of multiple blockchain instances deployed under identical system conditions. Each blockchain instance can receive and execute transactions under predefined workloads. Through interaction with the Environment, the Agent collects experience samples. The Agent is further decomposed into multiple Distributed-Actors and a Learner. These components execute asynchronously. The Learner is the central training component which uses a distributed deterministic policy gradient (D4PG [8]) approach. It samples experiences from a shared replay buffer, updates the network parameters, and periodically synchronizes the updated Actor parameters to the Distributed-Actors. The Distributed-Actors serve as executors. They interact with the Environment in parallel and continuously store collected experience data into the shared replay buffer. In addition, we incorporate a genetic algorithm-based parameter tuning approach (GA-Tune) within the Agent. At the initial stage, GA-Tune generates a large number of high-quality parameter configurations and interacts with the environment. Once the GA-Tune no longer produces performance improvements, subsequent parameter configurations are generated by the Distributed-Actors.
EchoFlow: A Workload-Aware Parameter Tuning Method
7
Within the Agent–Environment interaction framework, several auxiliary components ensure stable and effective system operation. The Adapter converts the action vector into parameter configurations and applies them by updating system settings and restarting relevant blockchain services. The Stressor generates transactions according to predefined workloads to simulate realistic operational pressure. The Observer monitors system performance, collects key metrics, and computes the corresponding reward. The Characterizer extracts workload features to form the state representation. 3.2
Genetic Algorithm-based Tuning
During the early training stage, the Learner is not yet sufficiently trained, causing the Distributed-Actors to generate low-quality parameter configurations with performance close to random selection. Interacting with the environment using these parameter configurations reduces training efficiency. To address this problem, we introduce GA-Tune, a genetic algorithm-based parameter tuning method. GA-Tune continuously generates superior offspring configurations through population evolution, thereby rapidly producing a set of high-quality parameter configurations and accelerating the initial training phase of the Learner. Among various heuristic algorithms, we select the genetic algorithm due to the following advantages: (1) As a widely adopted method, it simulates natural selection and genetic inheritance mechanisms, and can achieve fast convergence. (2) It can naturally incorporate expert-recommended configurations by including them in the initial population.
Fig. 4. the workflow of GA-Tune algorithm
The workflow of the GA-Tune algorithm is illustrated in Fig. 4. The algorithm performs initialization by constructing an initial population P = {X1 , · · · , Xn }, where each individual Xi represents a complete parameter configuration. These configurations can be derived from expert recommendations. Subsequently, the algorithm initiates an iterative optimization process starting from the initial population. In each iteration, the algorithm performs the following steps: selecting parent individuals from the current population based on fitness; generating offspring through crossover and mutation; evaluating the offspring and updating their fitness; and merging the offspring with the current population to form an updated population.
8
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
Fitness evaluation serves as the key metric for measuring individual quality. We design a fitness evaluation strategy where the fitness of an individual Xi = (xi1 , xi2 , . . . , P xin ) is defined as the weighted sum of its configuration pan rameters: f (Xi ) = j=1 Wxij . For the initial population, the parameter weights of individual Xi are determined according to the observed performance of the configuration, denoted as PERF(Xi ). During the evolutionary process, the weight update rule for offspring individuals is defined as follows. Suppose an offspring individual X partially inherits parameters from its parent X̄. Parameters that remain unchanged retain their original weights, while the weights of modified parameters are dynamically adjusted according to their impact on performance: ( Wx̄ij , xij = x̄ij Wxij = Wx̄ij + PERF(Xi ) − PERF(X̄i ), xij ̸= x̄ij . 3.3
D4PG-based Dynamic Tuning
To mitigate the substantial time required for sample generation in blockchain parameter tuning, we propose D4PG-Tune, a D4PG-based dynamic parameter tuning algorithm. D4PG [8] is an extension of the DDPG that enhances learning efficiency by incorporating distributed actors. Owing to its off-policy nature and parallel data collection via multiple actors, D4PG effectively improves the sample collection efficiency. In the following, we introduce the algorithm. State. The state consists of workload characteristics and physical resource utilization. The workload characteristics include workload scale (average QPS µ and volatility β), transaction type (average read intensity r̄ and average write intensity w̄), and access pattern (skewness parameter α). Physical resource utilization includes CPU and bandwidth usage. Action. The action is defined as a new configuration of all tunable parameters. Each parameter must remain within a predefined feasible range to prevent system instability caused by invalid configurations. Reward. The reward function guides the Agent toward learning parameter configurations that yield superior performance. Unlike prior studies [4, 5], our reward formulation must explicitly account for workload variations, as the upper bound of achievable performance differs substantially across different workload conditions. Therefore, we define the reward as: J(X; W ) − J(Xd ; W ) r = exp J(Xd ; W ) where J(X; W ) and J(Xd ; W ) denote the performance under the workload W using the adjusted parameter configuration X and the default configuration Xd , respectively. By measuring performance improvement relative to the default configuration under identical workload conditions, this design ensures fair reward evaluation across heterogeneous workloads. Furthermore, the exponential function amplifies differences in performance improvement.
EchoFlow: A Workload-Aware Parameter Tuning Method
9
Algorithm 1 D4PG-based Parameter Tuning Algorithm Require: batch size M , replay size R, exploration constant ϵ, maximum episode number T Ensure: Optimized policy parameters θ Distributed-Actor 1: Initialize actor network θd ← θ 2: repeat 3: Receive current workload s from Characterizer 4: Generate action a = πθd (s) + ϵN (0, 1) 5: Adapter applies a, Stressor generates requests, Observer obtains reward r 6: Store transition (s, a, r, s′ ) in the replay buffer 7: until learner terminates Learner 1: Initialize actor network θ and critic network w 2: Set target networks (θ ′ , w′ ) ← (θ, w) 3: for t = 1 to T and when |R| ≥ M do 4: Sample M transitions (si , ai , ri , s′i ) from the replay buffer 5: Compute target distributions Yi 6: Update critic network w by δw and actor network θ by δθ 7: Periodically update target networks: (θ′ , w′ ) ← (θ, w) 8: Periodically update Distributed-Actor network: θd ← θ 9: end for 10: return optimized policy parameters θ
D4PG-Tune consists of two core components, Distributed-Actors and Learner, which operate asynchronously. The execution processes of the Distributed-Actor and the Learner are summarized in Algorithm 1. Distributed-Actor. The Distributed-Actor contains an actor network that does not perform local training. This actor network continuously interacts with the Environment to collect samples. Multiple Distributed-Actors can run in parallel, thereby significantly accelerating sample collection. First, the Distributed-Actor copies the parameters θ from the Learner’s actor network as its initial parameters (line 1). It then enters an interaction loop with the Environment to collect training samples (lines 2–7). In each iteration, the Distributed-Actor generates a new parameter configuration (action) based on the current workload (state), and then obtain the performance results (reward) under this action. Finally, the Distributed-Actor stores the transition (s, a, r, s′ ) in the replay buffer for subsequent training by the Learner. Learner. The Learner contains an actor and a critic network, each with a corresponding target network. The actor network, parameterized by θ, represents a deterministic policy π for action generation. The critic network, parameterized by w, evaluates the effectiveness of the policy π.
10
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
The Learner first initializes the networks and copies their parameters to the target networks (lines 1–2). Once the number of samples in the replay buffer reaches the batch size M , the Learner enters the training loop (lines 3–9). In each iteration, the Learner samples M transitions from the replay buffer (line 4). It then computes the target distribution for each sample: Yi = P ri + γZw′ (s′i , πθ′ (s′i )) (line 5), where P denotes the projection operator that maps the distribution onto the predefined support of the critic network and Zw is a discrete probability distribution that provides more stable value estimates. After obtaining the target distribution, the Learner updates the critic network and actor network (line 6). By minimizing the distributional distance d between the predicted distribution Zw (siP , ai ) and the target distribution Yi , the 1 −1 ∇w d Yi , Zw (si , ai ) . Then critic gradient is computed as: δw = M i (|R| pi ) using the Deterministic Policy Gradient method, the actor gradient is computed P 1 as: δθ = M . In these formulations, pi de∇ π (s ) · E ∇ Z (s , a) θ θ i a w i i a=πθ (si ) notes the sampling probability associated with sample i, while |R| represents the total number of samples currently maintained in the replay buffer. During training, the Learner periodically coppies the actor and critic parameters to target networks to maintain stability in the target distribution (line 7). Meanwhile, the actor network parameters are also periodically synchronized across all Distributed-Actors, enabling them to interact with the Environment using the latest policy (line 8).
4
Evaluation
Our experimental study is designed to address the following Research Questions: 1. How much do workload variations affect performance? 2. To what extent can our method sustain performance improvements under diverse workloads? 3. How much do D4PG-Tune and GA-Tune accelerate training? Experimental Environment. Our experiments were conducted on five physical servers equipped with an Intel Xeon Platinum 8255C CPU @2.50 GHz, 128 GB RAM, running CentOS 7. We selected Hyperledger Fabric as the experimental platform because it is a widely adopted permissioned blockchain system. A local Fabric network was deployed to evaluate our approach. Each Fabric instance runs Hyperledger Fabric v2.5.14 and consists of two ordering nodes and four peer nodes, with the inter-node bandwidth constrained to 100 Mb/s. We used Python3 and PyTorch to implement all of our algorithms and components. Workload Configuration. We deployed the SmallBank smart contract, a benchmark widely used in academic research [2, 9]. This contract simulates basic bank-account operations, which facilitates precise control of the read–write ratio. To investigate the impact of workload diversity on system performance,
EchoFlow: A Workload-Aware Parameter Tuning Method
11
we designed multiple representative workload patterns: read-heavy (RH) with an average read intensity r̄ = 0.8; write-heavy (WH) with an average intensity ratio w̄ = 0.8; write-heavy with concentrated account access (WH-C), where w̄ = 0.8 and the skewness parameter α = 1; and read-heavy with query-rate variation (RH-V), where r̄ = 0.8 and the volatility β = 1.
4.1
Effectiveness of Workload Awareness
Fig. 5. Throughput comparison under diverse workloads
To address Research Questions 1 and 2, we conducted experiments under diverse workloads, with the results illustrated in Fig. 5. We evaluated the throughput under three configurations: the default configuration, the configuration generated by Athena, and the dynamic configuration produced by EchoFlow. Athena [4], a multi-agent DRL method designed to optimize the parameters of different nodes in Fabric, was selected as our primary baseline for comparison. Under the default parameter configuration, the average throughput values across the four workloads were 420.50, 380.54, 290.24, and 401.93 tps, respectively, exhibiting substantial performance disparities. Notably, compared with the RH workload, the average throughput under the WH, WH-C, and RH-V workloads decreased by 9.50%, 30.98%, and 4.42%, demonstrating that workload variations have a significant impact on throughput (RQ 1). We further observed that the parameter configuration provided by Athena significantly improved average throughput. Under the RH workload, Athena achieved 798.48 tps, an 89.89% improvement over the default configuration. However, as the workload changed, throughput declined to 668.65, 454.46, and 717.49 tps under the WH, WH-C, and RH-V workloads, representing drops of 16.26%, 43.08%, and 10.14%. In contrast, EchoFlow dynamically adjusted parameters according to workload characteristics. It achieved average throughput values of 804.22, 719.59, 544.98, and 745.24 tps under diverse workloads. Compared with Athena, EchoFlow improved throughput by 7.62%, 19.92%, and 3.87% as the workload changed, demonstrating better adaptability and sustained performance gains (RQ 2).
12
4.2
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
Acceleration of Training
Fig. 6. Best throughput achieved over time by different methods
To answer Research Question 3, we conducted experiments under a fixed workload to evaluate training efficiency: (i) the proposed method (D4PG-Tune + GA-Tune), (ii) D4PG-Tune only, (iii) GA-Tune only, and (iv) the baseline DDPG without enhancement. During training, we recorded the best throughput achieved so far every 15 minutes, as illustrated in Fig. 6. When using the baseline DDPG method, the model required about 3.5 hours to converge, and exhibited limited early-stage improvement due to insufficient exploration samples. With D4PG-Tune, multiple samples could be collected in parallel, accelerating the training process. After 1 hour of training, the best throughput reached 745.02 tps. Under the same training duration, D4PG-Tune substantially outperformed the baseline. Nevertheless, it still required approximately 3 hours to converge to its optimal performance. To further accelerate optimization, we introduced GA-Tune. By incorporating expert configurations into the initial population, GA-Tune achieved strong initial performance, reaching 701.38 tps within only 0.5 hours. However, GATune alone tends to converge prematurely to local optima, reaching only 786.93 tps. To address this, our proposed method integrates GA-Tune with D4PG-Tune, enabling convergence within 1.25 hours and achieving 857.60 tps, demonstrating faster training and superior parameter configurations (RQ 3).
5
Related Work
Automatic parameter tuning has been widely studied in the database domain and can generally be categorized into three approaches: search-based [10, 11], model-based [12, 13], and DRL-based methods [14–16]. Search-based methods rely on heuristic search strategies to efficiently identify high-performance configurations, though they may suffer from local optima. Model-based methods build predictive models to capture the relationship between configuration parameters
EchoFlow: A Workload-Aware Parameter Tuning Method
13
and system performance, but they require large volumes of high-quality training data. In contrast, DRL-based methods interact with the environment through trial-and-error learning, requiring fewer samples and discovering improved configurations, making them a promising research direction. Inspired by recent advances in database autotuning, blockchain parameter tuning has increasingly adopted DRL-based techniques due to the high cost of collecting sufficient training data. Athena [4] is the first to apply a DRL-based method to optimize the parameters of different node types in Hyperledger Fabric, significantly improving throughput and reducing latency. TuneChain [5] enables online tuning by training multiple models to adapt to different transaction conflict ratios. In addition, several DRL-based approaches go beyond parameter tuning and focus on broader blockchain optimization tasks. SPRING [17] optimizes the shard placement of states, aiming to minimize the proportion of cross-shard transactions while maintaining workload balance among shards. AdaChain [18] adapts blockchain system architectures and key parameters, enabling the system to better match deployed smart contracts and workload characteristics.
6
Conclusion
In this paper, we propose EchoFlow, a workload-aware dynamic parameter tuning approach for blockchain systems. EchoFlow adaptively adjusts system configurations according to workload characteristics, enabling continuous performance optimization. To mitigate the substantial time required for sample generation in blockchain environments, we adopt a distributed reinforcement learning method that integrates parallel data collection from multiple actors, substantially improving training efficiency. Furthermore, a genetic algorithm is introduced during the initial training stage to generate high-quality samples, shortening the early exploration phase. Extensive experimental results demonstrate that, compared with existing approaches, EchoFlow consistently achieves more stable and superior performance across diverse workloads while also reducing training time. Acknowledgements. This work was supported in part by the National Natural Science Foundation of China under Grant U22B2032.
References 1. Hyperledger Foundation: Hyperledger Fabric Documentation (2026). URL https: //hyperledger-fabric.readthedocs.io/en/release-2.5/. Accessed: 2026-03-04 2. Sharma, A., Schuhknecht, F.M., Agrawal, D., Dittrich, J.: Blurring the lines between blockchains and database systems: the case of hyperledger fabric. In: Proceedings of the 2019 International Conference on Management of Data, pp. 105–122 (2019) 3. Xu, J., Xie, Q., Peng, S., Wang, C., Jia, X.: Adaptchain: adaptive scaling blockchain with transaction deduplication. IEEE Transactions on Parallel and Distributed Systems 34(6), 1909–1922 (2023)
14
Ben Lian1,2 , Linpeng Jia1 , Xing Chen1,2 , Xiaofeng Chen3,4 , Yi Sun1,2,5,6(✉)
4. Li, M., Wang, Y., Ma, S., Liu, C., Huo, D., Wang, Y., Xu, Z.: Auto-tuning with reinforcement learning for permissioned blockchain systems. Proceedings of the VLDB Endowment 16(5), 1000–1012 (2023) 5. Lin, J., Deng, R., Lu, Z., Zhang, Y., Duan, Q.: TuneChain: an online configuration auto-tuning approach for permissioned blockchain systems. In: Proceedings of the 2024 IEEE International Conference on Web Services (ICWS), pp. 512–523 (2024) 6. Zhang, S., Xiao, J., Wu, E., Cheng, F., Li, B., Wang, W., Jin, H.: MorphDAG: a workload-aware elastic dag-based blockchain. IEEE Transactions on Knowledge and Data Engineering 36(10), 5249–5264 (2024) 7. Khan, M.M., Khan, F.S., Nadeem, M., Khan, T.H., Haider, S., Daas, D.: Scalability and efficiency analysis of hyperledger fabric and private ethereum in smart contract execution. Computers 14(4), 132 (2025) 8. Barth-Maron, G., Hoffman, M.W., Budden, D., Dabney, W., Horgan, D., TB, D., Muldal, A., Heess, N., Lillicrap, T.: Distributed distributional deterministic policy gradients. In: International Conference on Learning Representations (ICLR) (2018) 9. Dinh, T.T.A., Wang, J., Chen, G., Liu, R., Ooi, B.C., Tan, K.L.: BLOCKBENCH: a framework for analyzing private blockchains. In: Proceedings of the 2017 ACM International Conference on Management of Data, pp. 1085–1100 (2017) 10. Ansel, J., Kamil, S., Veeramachaneni, K., Ragan-Kelley, J., Bosboom, J., O’Reilly, U.M., Amarasinghe, S.: OpenTuner: an extensible framework for program autotuning. In: Proceedings of the 23rd International Conference on Parallel Architectures and Compilation Techniques (PACT), pp. 303–316 (2014) 11. Zhu, Y., Liu, J., Guo, M., Bao, Y., Ma, W., Liu, Z., Song, K., Yang, Y.: BestConfig: tapping the performance potential of systems via automatic configuration tuning. In: Proceedings of the 2017 ACM Symposium on Cloud Computing, pp. 338–350 (2017) 12. Van Aken, D., Pavlo, A., Gordon, G.J., Zhang, B.: Automatic database management system tuning through large-scale machine learning. In: Proceedings of the 2017 ACM International Conference on Management of Data, pp. 1009–1024 (2017) 13. Bao, L., Liu, X., Xu, Z., Fang, B.: Autoconfig: automatic configuration tuning for distributed message systems. In: Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, pp. 29–40 (2018) 14. Zhang, J., Liu, Y., Zhou, K., Li, G., Xiao, Z., Cheng, B., Xing, J., Wang, Y., Chen, T., Liu, L., Ran, M., Li, Z.: An end-to-end automatic cloud database tuning system using deep reinforcement learning. In: Proceedings of the 2019 International Conference on Management of Data, pp. 415–432 (2019) 15. Li, G., Zhou, X., Li, S., Gao, B.: Qtune: a query-aware database tuning system with deep reinforcement learning. Proceedings of the VLDB Endowment 12(12), 2118–2130 (2019) 16. Cai, B., Liu, Y., Zhang, C., Zhang, G., Zhou, K., Liu, L., Li, C., Cheng, B., Yang, J., Xing, J.: Hunter: an online cloud database hybrid tuning system for personalized requirements. In: Proceedings of the 2022 International Conference on Management of Data, pp. 646–659 (2022) 17. Li, P., Song, M., Xing, M., Xiao, Z., Ding, Q., Guan, S., Long, J.: Spring: improving the throughput of sharding blockchain via deep reinforcement learning based state placement. In: Proceedings of the ACM Web Conference 2024, pp. 2836–2846 (2024) 18. Wu, C., Mehta, B., Amiri, M.J., Marcus, R., Loo, B.T.: Adachain: a learned adaptive blockchain framework. Proceedings of the VLDB Endowment 16(8), 2033– 2046 (2023)