arXiv CSopen access

BCTuner: LLM-Guided Monte Carlo Tree Search for Efficient Blockchain Knob Tuning

arXiv:2605.23280v1 [cs.DB] 22 May 2026

BCTuner: LLM-Guided Monte Carlo Tree Search for Efficient Blockchain Knob Tuning Yaoyi Deng

Chongyang Tao

Mingxuan Li

Xuelian Lin

SKLCCSE Lab, Beihang University, China [email protected]

SKLCCSE Lab, Beihang University, China [email protected]

People’s Public Security University of China [email protected]

SKLCCSE Lab, Beihang University, China [email protected]

Han Sun

Mingchao Wan ∗

Shuai Ma ∗

SIC, Tsinghua University, China [email protected]

BAEC Beijing, China [email protected]

SKLCCSE Lab, Beihang University, China [email protected]

ABSTRACT

1

Knob tuning plays a critical role in improving the performance of permissioned blockchains. However, efficient tuning remains challenging due to the architectural complexity of blockchains and the semantic gap between knob-specific logic and the numerical optimization requirements of tuning tools. In addition, configuration changes are often coupled across different stages of the transaction pipeline, making their performance impact difficult to isolate and predict. Since each trial requires deployment and distributed benchmarking, ineffective exploration incurs substantial cost. These challenges motivate BCTuner, a Large Language Model (LLM)-guided framework that combines knowledge-guided reasoning with structured search. BCTuner organizes multi-source tuning knowledge to support LLM-based reasoning over knob semantics, constraints, and deployment context. It formulates tuning as a Monte Carlo Tree Search (MCTS) process over structured action trajectories, where configurations are incrementally constructed, validated, evaluated, and refined rather than generated in one step. BCTuner further applies adaptive pruning to discard infeasible or low-potential branches before system evaluation. We evaluate BCTuner on Hyperledger Fabric and ChainMaker under diverse workloads and network settings. Experimental results show that BCTuner achieves up to 211.38% throughput improvement over default configurations and outperforms the state-of-the-art blockchain tuning method by up to 20% in performance, while requiring up to 8× fewer interactions with the blockchain system.

Permissioned blockchains [3, 45] have been widely adopted in enterprise settings as trusted infrastructure for decentralized transaction processing, supporting applications such as financial services [7, 34], supply chain management [17, 44], and digital asset management [12, 23]. Similar to distributed transactional systems, they handle large volumes of concurrent transactions while ensuring consistency and reliability [13, 35]. However, unlike traditional distributed databases, permissioned blockchains introduce additional system-level complexities, including consensus protocols for transaction ordering, cryptographic verification, and execution models that require transaction validation and replay across multiple nodes. These mechanisms are essential for trust and fault tolerance but incur computation, communication, and coordination overhead. As a result, the throughput of permissioned blockchains is constrained, making performance optimization a critical concern. Prior work, such as Athena [28], has shown that effective knob tuning can substantially improve blockchain performance, highlighting the need for systematic and efficient tuning. Knob tuning is a general optimization problem in complex systems, where high-dimensional configuration spaces make finding an optimal configuration NP-hard [37]. Although automated tuning has been widely studied for databases and distributed systems, blockchain knob tuning poses additional challenges. (1) Semantic and contextual complexity. Blockchain systems expose heterogeneous knobs across consensus, networking, execution, validation, and resource management. Their types, units, ranges, and special values vary, and their effects depend on hardware resources, node roles, network topology, and system behavior. Thus, blockchain tuning requires semantic and contextual reasoning beyond numerical search. (2) Cross-stage dependencies. Permissioned blockchains process transactions through proposal execution, endorsement, ordering, validation, and commit. Knobs across these stages are coupled through transaction flow, consensus communication, network propagation, and resource contention, so local adjustments may shift bottlenecks across stages and make isolated tuning insufficient. (3) High evaluation cost. Each configuration trial requires system deployment or reconfiguration and distributed benchmarking, incurring substantial time and resource costs. Ineffective exploration therefore becomes prohibitive. These challenges motivate tuning approaches that incorporate blockchain-specific knowledge, reason over cross-stage dependencies, and reduce costly evaluations.

PVLDB Reference Format: Yaoyi Deng, Chongyang Tao, Mingxuan Li, Xuelian Lin, Han Sun, Mingchao Wan ∗ , and Shuai Ma ∗ . BCTuner: LLM-Guided Monte Carlo Tree Search for Efficient Blockchain Knob Tuning. PVLDB, 14(1): XXX-XXX, 2020. doi:XX.XX/XXX.XX PVLDB Artifact Availability: The source code, data, and/or other artifacts have been made available at URL_TO_YOUR_ARTIFACTS. ∗ Corresponding author. This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing [email protected]. Copyright is held by the owner/author(s). PubliBCTunerion rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 14, No. 1 ISSN 2150-8097. doi:XX.XX/XXX.XX

INTRODUCTION

Existing approaches to knob tuning can be broadly categorized into heuristic-based, learning-based, and, more recently, LLM-based methods. Early heuristic approaches [4, 33, 53] rely on manually designed rules or search heuristics, but they are often limited in high-dimensional configuration spaces and difficult to adapt to new systems. Learning-based methods improve tuning efficiency by modeling the relationship between configurations and performance. Bayesian optimization-based approaches [10, 14, 24, 40, 49, 50] reduce evaluations through surrogate modeling, reinforcement learning-based methods [9, 15, 27, 28, 43, 48] formulate tuning as sequential decision making, and deep learning-based approaches [8, 38, 41, 51] learn workload–configuration relationships with neural models. However, these methods are primarily data-driven, relying on training data, surrogate models, or repeated system interactions to guide the search, while largely ignoring blockchain-specific knob semantics, deployment context. This makes them inefficient in blockchain settings where each candidate configuration requires costly deployment and benchmarking. Recent advances in LLMs have demonstrated strong semantic understanding and structured reasoning capabilities [2, 19, 47], making them promising for configuration tuning tasks that rely on textual knob descriptions and domain rules. Existing studies explore this direction by using LLMs or textual knowledge to assist search space construction and knob selection [26, 39, 46], while the optimization process still largely depends on iterative trial-anderror evaluations. Other methods directly use LLMs to recommend configurations [16, 20], but their reliance on offline training data and database-specific representations limits their adaptability to new systems and deployment environments. More recently, LLMagent-based tuning has moved beyond static recommendation by decomposing tasks, incorporating runtime feedback, and refining decisions iteratively. AgentTune [29] represents an early effort in this direction, using workload analysis and knob selection to guide iterative database tuning. However, such methods may struggle with tightly coupled systems such as blockchains, where a single knob adjustment can affect multiple components and transaction stages. In these environments, effective tuning requires reasoning over intermediate decisions and their long-term effects, rather than merely generating complete candidate configurations. Therefore, existing LLM-based tuning methods remain insufficient for permissioned blockchains, where tuning requires reasoning over heterogeneous knobs, cross-stage transaction-pipeline dependencies, and costly system evaluations. This motivates a tuning framework that can organize blockchain-specific knowledge and reason over intermediate tuning decisions during configuration construction, evaluation, and refinement. To address these challenges, we propose BCTuner, an LLMguided tuning framework that integrates knowledge-guided reasoning with structured search. BCTuner organizes multi-source tuning knowledge to ground LLM-based reasoning in knob semantics, constraints, and deployment context. Instead of treating the LLM as a one-shot configuration generator, BCTuner embeds LLMguided actions into an MCTS process, where configurations are incrementally constructed, validated, evaluated, and refined along structured action trajectories. During this process, adaptive pruning uses validation results and runtime feedback to discard infeasible or low-potential branches before costly system evaluation. By jointly

combining knowledge organization, action-based refinement, and search pruning, BCTuner shift blockchain knob tuning from blackbox configuration prediction into knowledge-guided configuration refinement along action trajectories. We summarize our contributions as follows: • LLM-based tuning agent for blockchain systems. We propose BCTuner, to the best of our knowledge the first LLM-based framework for blockchain knob tuning, enabling structured and iterative configuration optimization. • Knowledge-guided tuning with LLMs. We leverage LLMs to extract and use knob and system knowledge, shifting blockchain knob tuning from data-driven exploration to knowledge-guided configuration search. • Action-based tuning formulation. We decompose blockchain knob tuning into a set of tuning actions that progressively refine configurations across different stages of the tuning trajectory. • Efficient search with MCTS and pruning. We employ MCTS with tailored pruning strategies to guide exploration of the configuration space, reducing unnecessary trials and the number of expensive evaluations. • Extensive evaluation on real blockchain platforms. BCTuner achieves up to 211.38% throughput improvement and is up to 8× faster than state-of-the-art methods.

2 BACKGROUND AND RELATED WORK 2.1 Blockchain Knob Tuning Permissioned blockchain systems, such as Hyperledger Fabric [3] and ChainMaker [1], are widely used in enterprise applications where transaction throughput and reliability are critical. These systems expose configuration knobs across multiple components, including transaction submission, endorsement, ordering, validation, commit, storage, networking, and resource management. These knobs control system behaviors such as batching, concurrency, communication, state access, and resource allocation. Blockchain knob tuning aims to select appropriate knob values under a given workload, network topology, and hardware environment to improve end-to-end transaction performance. Unlike traditional database systems, permissioned blockchains process transactions through a multi-stage pipeline. A transaction typically goes through proposal execution, endorsement, ordering, validation, and commit before it is finalized. Each stage is implemented by different components and controlled by different groups of knobs, but their effects are not independent. For example, increasing the block size or batch timeout at the ordering layer may improve batching efficiency by packing more transactions into each block. However, larger blocks also increase the amount of validation, state access, and commit work performed by peers, and may shift the bottleneck from ordering to validation or storage. Therefore, blockchain performance is a pipeline-level outcome determined by interactions among consensus, execution, networking, storage, and resource-management components. Taken together, these properties make blockchain knob tuning different from conventional DBMS tuning. Effective tuning must account for heterogeneous knob semantics, deployment-specific context, cross-stage effects along the transaction pipeline, and the 2

high cost of evaluating configurations on a deployed blockchain network. This makes purely black-box or trial-and-error tuning less suitable, motivating the need for knowledge-aware and evaluationefficient tuning methods.

2.2

preprocessing tools and requires many iterative evaluations. AgentTune [29] supports structured decision-making through task decomposition and iterative refinement, but relies on database-specific abstractions such as SQL workload semantics and execution-level metrics. Overall, these methods are designed for database systems and depend on workload-specific knowledge, historical data, or repeated system interactions, making them difficult to apply to permissioned blockchains with distinct execution models and limited tuning knowledge.

Traditional Database Knob Tuning

Traditional database knob tuning methods can be broadly divided into four categories. (1) Heuristic-based methods, such as PGTune [33], OpenTuner [4], and BestConfig [53], rely on expert-designed rules, enabling quick guidance but requiring substantial domain expertise and offering limited generalization across workloads and environments. (2) Bayesian optimization-based methods, including iTuned [14], OtterTune [40], ResTune [49], CGPTuner [10], LlamaTune [24], and OnlineTune [50], use surrogate models to approximate the performance landscape and guide search. However, they typically require high-quality historical data, and their effectiveness can degrade under workload shifts, limiting generalization to unseen scenarios. (3) Reinforcement learning-based methods, such as Qtune [27], CDBTune [48], UDO [43], WATuning [15], Hunter [9], and Athena [28], formulate tuning as sequential decision-making and learn policies for configuration adjustment. Although they can adapt to dynamic environments, they often require unstable training and extensive system interactions, leading to high tuning overhead. (4) Deep learning-based methods, including iBTune [38], OpAdviser [51], and Db2une [8], use neural networks to model performance or guide search. These methods depend on sufficient training data and still require iterative refinement, making them less effective in data-scarce or changing environments. Despite their differences, these approaches either rely on high-quality historical data or require extensive online interactions with the system, making efficient and robust tuning difficult in complex and dynamic environments.

2.3

3 BCTUNER FRAMEWORK 3.1 Problem Formulation Blockchain knob tuning. We formally define the blockchain knob tuning task as follows. Let B = (𝐻, 𝑁 ) denote a blockchain system, where 𝐻 represents the hardware environment and 𝑁 denotes the network topology. Let K = {𝑘 1, 𝑘 2, . . . , 𝑘𝑚 } denote the set of tunable knobs. Each knob 𝑘𝑖 is associated with a value range V𝑖 . The configuration space is defined as the Cartesian product of the value ranges of all knobs, i.e., C = V1 × V2 × · · · × V𝑚 . A configuration is an assignment of values to all knobs, denoted as 𝐶 = (𝑘𝑣 1, 𝑘𝑣 2, . . . , 𝑘𝑣𝑚 ), where 𝑘𝑣𝑖 is the value of knob 𝑘𝑖 . Given a blockchain system B, a configuration 𝐶, and a smart contract workload 𝑆, the system performance is evaluated by a function Eval, measured in throughput (transactions per second, TPS), denoted by 𝑇 : 𝑇 = Eval(B, 𝐶, 𝑆).

(1)

The goal of blockchain knob tuning is to identify an optimal configuration 𝐶 ∗ that maximizes system performance under a given hardware environment, network topology, and workload. Formally, the optimization problem is defined as: 𝐶 ∗ = arg max Eval(B, 𝐶, 𝑆).

LLM-based Database Knob Tuning

𝐶∈C

(2)

Blockchain knob tuning as a Search Problem. Traditional tuning approaches are largely data-driven, relying on configuration– performance observations collected through iterative interactions with the target system [26, 28]. However, obtaining such observations is expensive and time-consuming in blockchain environments, where each evaluation requires deploying or reconfiguring the system and running distributed workload benchmarks. LLMs exhibit strong capabilities in semantic understanding and reasoning. They can capture the meanings of knobs and their interdependencies, and generate informed adjustments. This motivates the use of LLMs to simulate the decision-making process of human blockchain administrators for configuration tuning. However, directly relying on LLMs is insufficient due to the large search space and the complex coupling among knobs, which make purely heuristic or one-shot decisions unreliable. Therefore, it is necessary to incorporate a structured search mechanism to systematically explore and refine configurations. To address the blockchain knob tuning problem, we formulate it as an LLM-guided MCTS problem. Given the large search space and expensive evaluations, MCTS provides an effective framework that balances exploration and exploitation, enabling efficient search toward high-quality configurations.

LLMs have recently shown strong capabilities in semantic understanding and reasoning, and have been applied to various database tasks such as performance diagnosis [11, 52], text-to-SQL [5, 42], and query optimization [30, 31]. These capabilities make LLMs a promising tool for configuration tuning, where understanding knob semantics and parameter interactions is essential. Several recent studies have explored LLMs for database knob tuning. DB-BERT [39] extracts tuning hints from textual documents, but still relies on reinforcement learning-based trial-anderror search and is sensitive to external knowledge quality. GPTuner [26] uses LLMs to guide Bayesian optimization, but treats them as auxiliary components and still requires extensive iterative interactions, with limited generalization under workload shifts. 𝜆-Tune [16] generates full configurations via LLMs and reduces evaluation overhead through workload-specific scheduling, but is coupled with query execution characteristics and suffers from unstable single-shot generation in high-dimensional knob spaces. E2ETune [20] learns workload–configuration mappings from largescale offline data, but costly data generation and retraining limit its adaptability to new systems and dynamic environments. MCTuner [46] uses LLMs for knob selection and combines space decomposition with Bayesian optimization, but still treats LLMs as 3

Figure 1: System Overview of BCTuner. Formally, let 𝑠 denote a search state, where each state corresponds to a configuration 𝐶, and let 𝑎 ∈ A denote a tuning action. We construct a search tree T , in which each node represents a state 𝑠, and each edge corresponds to an action that transforms one state into another. Applying action 𝑎𝑡 to state 𝑠𝑡 yields the next state 𝑠𝑡 +1 = 𝛿 (𝑠𝑡 , 𝑎𝑡 ), where 𝛿 denotes the state transition function. The tuning process is modeled as a sequential search over action sequences 𝜋 = (𝑎 0, . . . , 𝑎 |𝜋 | −1 ), where each sequence defines a path in the search tree starting from an initial state 𝑠 0 , and Π denotes the set of all feasible action sequences. Let 𝑠𝑡𝜋 denote the state at step 𝑡 along trajectory 𝜋, and let 𝐶𝑡𝜋 denote the corresponding configuration. The objective is to identify the configuration that achieves the best performance over all explored trajectories: 𝐶 ∗ = arg max max Eval(B, 𝐶𝑡𝜋 , 𝑆). 𝜋 ∈Π 0≤𝑡 ≤ |𝜋 |

space and the intricate interactions among consensus, network, and execution components. These characteristics introduce several key challenges: (a) The configuration space is extremely large, and performance depends on complex and often non-linear interactions among knobs. Without sufficient understanding of knob semantics and their relationships, exploration can easily fall into ineffective or invalid regions. (b) Directly generating a full configuration in one shot is unreliable in high-dimensional knob spaces. Without structured guidance, important dependencies among knobs can be easily overlooked, leading to low-quality or even invalid configuration settings. (c) Configuration evaluation is expensive, as each candidate must be deployed and benchmarked on the system. This necessitates minimizing unnecessary trials and maximizing the utility of each evaluation. The above challenges lead to three design requirements for effective blockchain tuning. BCTuner addresses the above requirements through an LLM-guided MCTS framework for blockchain knob tuning. First, BCTuner incorporates multi-source knowledge, including knob semantics and system-level context, to ground tuning decisions in explicit blockchain knowledge and guide the search toward valid and effective configurations. Second, instead of generating full configurations in a single step, BCTuner organizes tuning as a structured action-based process, where the LLM progressively refines configurations through iterative decisions. Third, BCTuner leverages MCTS with adaptive pruning to organize exploration and reduce unnecessary deployment and benchmarking during tuning.

(3)

where for each trajectory 𝜋, the inner maximization selects the best-performing configuration along the trajectory, and the outer maximization identifies the trajectory that yields the highest performance overall. As a result, 𝐶 ∗ corresponds to the configuration that achieves the maximum throughput among all configurations explored during the search.

3.2

BCTuner overview

Overall Design. Blockchain knob tuning presents an NP-hard optimization problem due to the high-dimensional configuration 4

The integration of knowledge-guided reasoning and structured search enables BCTuner to perform effective tuning in blockchain systems. In our experiments, BCTuner achieves up to 211.38% performance improvement and reduces tuning time by up to 14× compared with traditional approaches, demonstrating the effectiveness of this design. The approach also provides a general paradigm for applying LLMs to high-dimensional system optimization.

This limited but authoritative source requires a structured pipeline to extract and organize tuning-relevant information. BCTuner constructs knob knowledge in three stages. First, the LLM identifies performance-related knobs from system manuals and extracts their descriptions, covering knobs that directly or indirectly affect performance. Second, it infers key attributes of each knob, including type (e.g., integer, float, boolean, or string), unit, and special values, which provide constraints for valid configuration generation. Third, it groups knobs into clusters according to their functional roles in the blockchain execution pipeline, such as transaction processing, networking, and resource management. This LLM-based grouping captures semantic relationships between knobs and system components.

Workflow. Fig. 1 illustrates the overall workflow of BCTuner, which consists of two phases: an offline knowledge preparation phase and an online tuning phase. In the offline phase, BCTuner collects multi-source information from system manuals and runtime metadata, including knob semantics, hardware characteristics, and network topology. This information is further processed and organized into structured representations, capturing key properties such as knob roles, implicit constraints, and relationships among knobs. By transforming heterogeneous and unstructured inputs into a unified and structured form, this phase provides actionable guidance that can be consistently utilized throughout the tuning process, effectively bridging raw system knowledge and automated decision-making. In the online phase, BCTuner formulates knob tuning as a search over the configuration space. BCTuner incrementally constructs a configuration through a sequence of reasoning actions. At each step, partial decisions are extended and refined until a complete configuration is obtained. The generated configuration is then deployed and evaluated on the blockchain system to obtain performance metrics. The evaluation results are used as feedback to guide subsequent tuning, forming a closed-loop optimization process. Through iterative generation, evaluation, and feedback, configurations are progressively improved over multiple steps, enabling effective exploration of the configuration space.

Hardware and Network Knowledge Construction. In addition to knob-level knowledge, BCTuner incorporates hardware-level and network-level Knowledge to capture the deployment environment. This Knowledge is provided by administrators and encoded in structured formats (e.g., JSON), including hardware specifications and network topology. hardware-level knowledge captures hardware characteristics such as CPU, memory, and storage, which constrain feasible configurations. Network-level knowledge describes structural properties of the blockchain system, including node roles and connectivity, which influence knob interactions and system performance. Incorporating this Knowledge allows BCTuner to contextualize tuning decisions and avoid configurations that are incompatible with the system environment. Taken together, knob-level, hardware-level, and network-level knowledge provide a structured representation of the blockchain system. This representation allows BCTuner to assess both configuration feasibility and potential performance effects. By grounding tuning decisions in explicit system knowledge rather than treating knob tuning as black-box optimization, BCTuner guides the search toward valid and promising regions of the configuration space, improving tuning efficiency and robustness.

4

LLM-GUIDED MCTS FOR BLOCKCHAIN KNOB TUNING 4.1 Multi-Source Blockchain Knowledge

4.2

LLM as the Tuning Action Model

BCTuner models the LLM as an action generator within an iterative tuning loop, rather than treating configuration generation as a one-shot process. At each step, the LLM produces a action that incrementally modifies the current configuration. This design alleviates the difficulty of adjusting all knobs in a single pass, where the LLM’s attention may be dispersed across numerous knobs [6, 32], leading to suboptimal decisions. By decomposing tuning into a sequence of interdependent actions, BCTuner progressively refines configurations, supports reasoning over knob interactions, and enables structured decision-making. To support diverse tuning decisions, BCTuner adopts actionspecific prompts instead of a fixed prompt. Each prompt is constructed from the current configuration, system context, and task instructions, with objectives and contextual information tailored to the corresponding action type. This design constrains the reasoning scope of the LLM and supports precise, context-aware adjustments. Formally, at step 𝑡, given the current state 𝑠𝑡 (corresponding to configuration 𝐶𝑡 ), the LLM generates an action A𝑡 ∈ A conditioned on the current state and a dynamically constructed prompt, type(𝑎𝑡 ) denotes the action type, and Prompt(𝑠𝑡 , type(𝑎𝑡 )) is constructed

In practice, human blockchain administrators first understand how each knob functions before tuning, which helps them reason about feasible configurations and avoid invalid or undesirable settings. Without such knowledge, tuning becomes unguided and may lead to invalid configurations or inefficient exploration. This suggests that effective knob tuning requires not only searching the configuration space, but also capturing knob semantics, constraints, and behavior. Based on this insight, BCTuner incorporates multi-source knowledge to support knowledge-aware exploration. Specifically, it leverages three types of knowledge: knob-level, hardware-level, and network-level knowledge. Knob-level knowledge captures the semantics, functional effects, and constraints of individual knobs. Hardware-level knowledge describes resources such as CPU, memory, and storage, which affect configuration feasibility. Networklevel knowledge encodes node roles and topology, which influence knob interactions and system behavior. Knob Knowledge Construction. Unlike database systems, where a mature ecosystem provides diverse sources of tuning knowledge, blockchain knob knowledge is mainly derived from official manual. 5

(𝑔 )

by combining the current configuration, system context, and task instructions associated with that action type. The environment then applies the action to obtain the next state: 𝑠𝑡 +1 = 𝛿 (𝑠𝑡 , A𝑡 = LLM(Prompt(𝑠𝑡 , type(A𝑡 ))),

where 𝐶𝑡 𝑡 denotes the sub-configuration corresponding to cluster 𝑔𝑡 , representing the assigned values of all knobs within the selected cluster at step 𝑡. Once a cluster is selected, the action retrieves its associated knobs based on the predefined cluster–knob mapping and generates updated values while maintaining consistency with previously tuned knobs. By jointly tuning multiple related knobs, this action captures their semantic relationships and functional dependencies, producing coordinated configurations rather than independent updates. Operating at the cluster level, it provides an effective intermediate step between global planning and fine(𝑔 ) grained knob-level tuning. The resulting sub-configuration 𝐶𝑡 𝑡 serves as the basis for subsequent actions such as refinement or validation, enabling targeted and progressive optimization.

(4)

where 𝛿 (·) denotes the state transition function induced by executing the action in the current state. This design allows different actions to operate under distinct reasoning contexts, where prompts are aligned with action semantics to guide the LLM within well-defined decision scopes. As a result, the LLM induces state transitions conditioned on the current state and action-specific prompts, enabling structured decision-making that integrates with search-based optimization.

4.3

A3. Single-knob Tuning. The Single-knob Tuning action performs fine-grained configuration updates by selecting a critical knob and refining its value based on the current state. Given the plan 𝑝𝑡 , system and network knowledge K 𝑠𝑦𝑠 , knob-level knowledge K 𝑘𝑛𝑜𝑏 , and the previously tuned configuration C𝑡𝑡𝑢𝑛𝑒𝑑 −1 , this action selects a knob 𝑘𝑡 and generates an updated value 𝑣𝑡 for that knob.

Tuning Action Design

To enable structured tuning, BCTuner defines a set of actions that decompose configuration optimization into a sequence of decision steps. Instead of generating complete configurations in a single pass, the tuning process explores the configuration space by selecting and applying actions at each step, where actions correspond to levels of decision granularity, including Global Tuning Plan, Cluster-wise tuning, and Single-knob tuning. The configurations are complemented by Validation and Feedback-driven refinement, with MCTS guiding the selection of the next action based on the current search state. We next describe each action type.

(𝑘𝑡 , 𝑣𝑡 ) = A𝑠𝑖𝑛𝑔𝑙𝑒 (𝑝𝑡 , K 𝑠𝑦𝑠 , K 𝑘𝑛𝑜𝑏 , C𝑡𝑡𝑢𝑛𝑒𝑑 −1 )

where 𝑘𝑡 denotes the selected knob and 𝑣𝑡 denotes its updated value at step 𝑡. Unlike cluster-wise tuning, which jointly adjusts multiple related knobs, this action focuses on refining a single knob to capture fine-grained improvements. The action identifies under-optimized knobs that require further refinement and updates them while considering their interactions with previously tuned parameters. By operating at the individual knob level, this action complements cluster-wise tuning and enables more precise performance improvement.

A1. Global Tuning Plan. The Global Tuning Plan action determines the high-level optimization plan at each stage of tuning. Given the current state, including hardware and network knowledge K 𝑠𝑦𝑠 , cluster organization G, and untuned clusters G𝑡𝑢𝑛𝑡𝑢𝑛𝑒𝑑 , this action generates a planning decision 𝑝𝑡 that specifies which parts of the system should be prioritized in subsequent tuning steps. This action operates at a global level, determining how optimization efforts are allocated across system components. Formally, the planning decision is defined as: 𝑝𝑡 = A𝑝𝑙𝑎𝑛 (K 𝑛𝑒𝑡 , K 𝑠𝑦𝑠 , G, G𝑡𝑢𝑛𝑡𝑢𝑛𝑒𝑑 ).

A4. Knob Validation. The Knob Validation action evaluates the rationality and feasibility of the current tuned configuration. Given the current configuration C𝑡𝑡𝑢𝑛𝑒𝑑 −1 , system and network Knowledge K 𝑠𝑦𝑠 and knob-level knowledge K 𝑘𝑛𝑜𝑏 , this action assesses whether the configuration is valid under the given system context.

(5)

𝑠𝑦𝑠 (𝑣𝑡 , E𝑡𝑣𝑎𝑙 ) = A 𝑣𝑎𝑙𝑖𝑑𝑎𝑡𝑖𝑜𝑛 (C𝑡𝑡𝑢𝑛𝑒𝑑 , K 𝑘𝑛𝑜𝑏 ) −1 , K

To ensure a structured tuning process, the planning decision considers the blockchain execution pipeline, prioritizing clusters along the transaction processing flow (e.g., gateway, execution, ordering, and validation/commit), as well as system-level components such as resource management and network communication. It also incorporates feedback from previous evaluations and captures dependencies among clusters to identify potential bottlenecks. The resulting plan 𝑝𝑡 guides subsequent actions by narrowing the search space and determining the focus of future tuning steps.

(𝑔 )

(8)

where 𝑣𝑡 ∈ {0, 1} indicates whether the configuration is valid, and E𝑡𝑣𝑎𝑙 denotes the set of detected issues, including constraint violations, format errors, and logical inconsistencies. This action focuses on identifying configurations that violate constraints or exhibit internal inconsistencies. It checks whether knob values remain within valid ranges, follow correct formats, and are compatible with related configurations under the current system context, filtering out invalid or conflicting configurations. The output E𝑡𝑒𝑟𝑟 explicitly identifies problematic knobs, enabling targeted correction in subsequent steps.

A2. Cluster-wise Tuning. The Cluster-wise Tuning action performs coarse-grained configuration updates by selecting a cluster and jointly tuning its associated knobs. Given the planning decision 𝑝𝑡 , system and network knowledge K 𝑠𝑦𝑠 , knob-level knowledge K 𝑘𝑛𝑜𝑏 , cluster definitions G, the set of untuned clusters G𝑡𝑢𝑛 , and the set of previously tuned knobs C𝑡𝑡𝑢𝑛𝑒𝑑 −1 , this action selects a cluster 𝑔𝑡 ∈ G𝑡𝑢𝑛 and generates coordinated updates for the knobs within the selected cluster. 𝐶𝑡 𝑡 = A𝑐𝑙𝑢𝑠𝑡𝑒𝑟 (𝑝𝑡 , K 𝑠𝑦𝑠 , K 𝑘𝑛𝑜𝑏 , G, G𝑡𝑢𝑛 , C𝑡𝑡𝑢𝑛𝑒𝑑 −1 )

(7)

A5. Knob Fix. The Knob Fix action performs targeted correction of invalid or conflicting configurations identified during validation. Given the current configuration C𝑡𝑡𝑢𝑛𝑒𝑑 −1 , system and network Knowledge K 𝑠𝑦𝑠 , knob-level knowledge K 𝑘𝑛𝑜𝑏 , and the detected issues E𝑡𝑣𝑎𝑙 −1 , this action generates a corrected configuration. 𝑓 𝑖𝑥

C𝑡

(6) 6

𝑠𝑦𝑠 = A 𝑓 𝑖𝑥 (C𝑡𝑡𝑢𝑛𝑒𝑑 , K 𝑘𝑛𝑜𝑏 , E𝑡𝑣𝑎𝑙 −1 , K −1 )

(9)

Table 1: Action Ordering in BCTuner Current Action

Valid Next Actions

Root A1 Global Tuning Plan A2 Cluster-wise Tuning A3 Single-knob Tuning A4 Knob Validation A5 Knob Fix A6 Performance Evaluation A7 Feedback-driven Refinement A8 Terminal

A1 A2, A3 A2, A3, A4, A6 A2, A3, A4 A2, A3, A5, A6, A8 A4 A1, A7, A8 A8 –

A8. Terminal. The Terminal action indicates the termination of the tuning process. It is triggered when predefined stopping conditions are met, such as the completion of feedback iterations or reaching the maximum search depth. Once activated, no further tuning actions are performed. To constrain the search process, BCTuner defines explicit transition rules over the action space, restricting which actions can follow a given action. These rules enforce a valid ordering among actions and ensure that each action is applied at an appropriate stage of the tuning process (e.g., validation and fixing follow configuration adjustments, while feedback tuning is triggered only after evaluation). Table 1 summarizes the valid action transitions. These constraints guide the search into a structured progression, improving both efficiency and stability.

4.4 𝑓 𝑖𝑥

where C𝑡 denotes the updated configuration. For the identified issues, the action adjusts the corresponding knobs based on configuration constraints, inter-knob dependencies, and system context. The correction focuses on resolving conflicts and restoring feasibility. After applying the fixes, the updated configuration is rechecked to ensure logical consistency and deployability. This action ensures that the configuration remains valid and executable, providing a reliable basis for subsequent tuning steps. A6. Performance Evaluation. The Performance Evaluation action executes the current configuration C𝑡 −1 on the blockchain system to obtain its performance. Given the system B and workload 𝑆, this action runs benchmark workloads and computes the resulting throughput. The resulting performance 𝑇𝑡 captures the effect of the applied tuning decisions, and is used to evaluate the current configuration, guide subsequent action selection, and support pruning of suboptimal configurations during the search. 𝑇𝑡 = Eval(B, C𝑡 −1, 𝑆)

MCTS-based Configuration Generation

Configuration Generation with MCTS Rollout. To generate configurations in a large and interdependent knob space, BCTuner employs MCTS to guide the search. Instead of predicting a complete configuration in one step, MCTS incrementally explores the space through structured actions, balancing exploration of new decisions and exploitation of promising configurations. In BCTuner, the search operates over the action space defined in Section 4.3. Each action transforms the current configuration into a new state, forming a search tree where nodes represent intermediate configurations and edges correspond to valid tuning actions. MCTS then explores and evaluates action sequences to identify promising tuning trajectories through four stages: selection, expansion, simulation, and backpropagation, as summarized in Algorithm 1. Selection. During selection, the search traverses the tree from the root node to either an unexpanded node or a terminal node, identifying promising nodes for further expansion. We adopt the Upper Confidence Bound applied to Trees (UCT) strategy [25] to balance exploration and exploitation during node selection. The UCT score of selecting action is defined as: √︄ ln 𝑁 (𝑣) 𝑄 (𝑣, 𝑎) UCT(𝑣, 𝑎) = +𝑐 · , (12) 𝑁 (𝑣, 𝑎) 𝑁 (𝑣, 𝑎)

(10)

A7. Feedback-driven Refinement. The Feedback-driven Refinement action performs iterative refinement based on runtime feedback from previous evaluations. Unlike one-shot configuration generation, this action improves configurations through repeated observation and adjustment. Given the latest evaluation results, including performance metrics 𝑇𝑡 and execution errors E𝑡𝑟𝑢𝑛 , the current configuration C𝑡𝑡𝑢𝑛𝑒𝑑 , system and network knowledge K 𝑠𝑦𝑠 , and knob-level knowledge K 𝑘𝑛𝑜𝑏 , this action analyzes potential causes of performance degradation or failures and identifies bottleneckrelated knobs for further refinement. (11)

where 𝑁 (𝑣, 𝑎) denotes the number of times action 𝑎 has been selected from node 𝑣, and 𝑁 (𝑣) is the total number of visits to node 𝑣. 𝑄 (𝑣, 𝑎) represents the accumulated reward of taking action 𝑎 from node 𝑣, which is updated during backpropagation. At each step, the action with the highest UCT score is selected to traverse the tree. If there exist unvisited child nodes (i.e., 𝑁 (𝑣, 𝑎) = 0), they are prioritized to encourage exploration.

where C𝑡 denotes the updated configuration after incorporating feedback from the latest evaluation. The action analyzes feedback to identify performance bottlenecks, selectively refines performancelimiting knobs while preserving effective settings, and re-evaluates the updated configuration to guide subsequent refinement. This process continues until performance improvement becomes marginal or a maximum number of refinement iterations is reached. This design enables targeted refinement of bottleneck knobs and progressively improves configuration quality.

Expansion. During expansion, the selected node is expanded through valid actions, where the valid action set is determined by the current action type and the transition rules in Table 1. For actions involving LLM reasoning, BCTuner invokes the LLM to generate executable action instances conditioned on the current tuning context, and samples each action multiple times to produce diverse child nodes. For non-LLM actions (e.g., Performance Evaluation), the transition produces a deterministic successor. Since these actions interact with the real system and provide contextual information for later decisions, BCTuner replicates the resulting state to match the number

𝑓𝑏

C𝑡

= A 𝑓 𝑒𝑒𝑑𝑏𝑎𝑐𝑘 (C𝑡𝑡𝑢𝑛𝑒𝑑 ,𝑇𝑡 , E𝑡𝑟𝑢𝑛 , K 𝑘𝑛𝑜𝑏 , K 𝑠𝑦𝑠 )

𝑓𝑏

7

Algorithm 1 MCTS-based Configuration Generation in BCTuner

and feedback tuning, the reward is defined based on the relative performance improvement with respect to a baseline configuration:

1: Initialize the root state 𝑠 0 and search tree T 2: 𝐶 ∗ ← 𝐶 (𝑠 0 ), 𝑇 ∗ ← 𝑏𝑒𝑛𝑐ℎ𝑚𝑎𝑟𝑘 (𝐵𝐶, 𝐶 (𝑠 0 ), 𝑆)

𝑇 −𝑇default   𝑇default  , 𝑇 ≥ 𝑇default, 𝑒    𝑟𝑇 =  𝑇 −𝑇default    − 𝑒 𝑇default , 𝑇 < 𝑇default, 

3: for 𝑖 = 1 to 𝑚𝑎𝑥𝑅𝑜𝑙𝑙𝑜𝑢𝑡 do

𝑣 ← 𝑠0 , 𝜏 ← ∅ Selection 5: while 𝑣 is expanded and do   not terminal √︃ 𝑄 (𝑣,𝑎) ln 𝑁 (𝑣) 6: 𝑣 ← arg max𝑎∈𝐴(𝑣) 𝑁 (𝑣,𝑎) + 𝑐 𝑁 (𝑣,𝑎)

4:

(13)

where 𝑇 and 𝑇𝑑𝑒 𝑓 𝑎𝑢𝑙𝑡 denote the throughput of the current configuration and default configuration, respectively. Evaluation actions directly use this reward, while feedback-driven tuning follows the same formulation but further amplifies it as 𝑟 feedback = 1.5 · 𝑟𝑇 .This reward design integrates feasibility constraints with continuous performance signals, enabling the search to both prune invalid configurations and prioritize trajectories that lead to consistent performance improvement.

end while Expansion 8: if 𝑣 is not terminal then 9: Expand 𝑣 via valid actions and obtain a successor state 10: 𝜏 ← 𝜏 ∪ (𝑣, 𝑎) 11: end if Simulation 12: while 𝑣 is not terminal do 13: Execute the next valid action and update 𝑣 14: 𝜏 ← 𝜏 ∪ (𝑣, 𝑎) 15: end while Backpropagation 16: Compute reward 𝑟 for the rollout result 17: Update 𝐶 ∗ and 𝑇 ∗ if a better configuration is found 18: for all (𝑣 𝑗 , 𝑎 𝑗 ) ∈ 𝜏 do 19: Update 𝑄 (𝑣 𝑗 , 𝑎 𝑗 ) and 𝑁 (𝑣 𝑗 , 𝑎 𝑗 ) 20: end for 21: end for 22: return 𝐶 ∗ 7:

Stopping Criteria. The overall search process terminates when one of the following conditions is satisfied: (1) a configuration achieves the predefined target throughput, or (2) the rollout budget is fully exhausted. Upon termination of the search, BCTuner returns the configuration with the highest throughput observed during the entire exploration process, among all candidates.

4.5

Pruning Strategy

Although MCTS provides a framework for exploring the action space, expanding all valid successors can produce many low-value branches in blockchain knob tuning, where each evaluation requires deployment and benchmarking. To improve efficiency, BCTuner applies a rule-based pruning strategy during expansion. Instead of treating all actions equally, the pruning mechanism narrows the candidate set based on the search stage, action outcomes, and runtime feedback, removing actions that are premature, redundant, or unlikely to improve the search outcome. In addition, BCTuner applies a separate pruning rule in the feedback tuning stage to terminate refinement when further iterations become ineffective. At a high level, the pruning strategy follows three principles. First, it enforces stage-aware progression, introducing expensive or restrictive actions only after sufficient exploration. The search is initially restricted to cluster-level tuning at the optimization-direction stage, and the full action space is opened after cluster exploration. Validation is postponed until enough tuning actions have accumulated, while evaluation is enabled after sufficient adjustment and suppressed if it appears too frequently in nearby ancestors, preventing premature validation or evaluation. Second, BCTuner applies outcome-aware pruning after validation and evaluation. During validation, branches with unreasonable configurations are terminated when similar results appear in recent ancestors; otherwise, only the fix action is retained before further exploration. When validation succeeds, successors are restricted to adjustment or evaluation. During evaluation, branches are terminated if throughput drops below 90% of the initial performance. Third, BCTuner adopts performance-guided continuation rules for evaluation and feedback. After evaluation, a branch enters feedback tuning only if its throughput reaches at least 80% of the interval between the baseline and the best observed performance; otherwise, the search returns to the optimization-direction stage. Within feedback tuning, refinement is terminated if performance degrades by

of child nodes generated by LLM-based actions. In this way, each action contributes a consistent number of child nodes, allowing evaluation results to be effectively incorporated into subsequent search decisions and refinement steps. Simulation. The simulation phase proceeds by repeatedly extending nodes through successive action selection and expansion steps, until reaching a termination node. All intermediate nodes generated during this process are retained in the search tree, enabling future iterations to build upon previously explored trajectories. Backpropagation. During backpropagation, the reward obtained from simulation is propagated backward along the visited trajectory to update the statistics of the corresponding nodes. Specifically, for each node-action pair (𝑣, 𝑎) along the trajectory 𝑣 0 ⊕ · · · ⊕ 𝑣𝑡 , the accumulated reward and visit count are updated as 𝑄 (𝑣, 𝑎) = 𝑄 (𝑣, 𝑎) + 𝑟 and 𝑁 (𝑣) = 𝑁 (𝑣) + 1. These updated statistics are then used to guide subsequent selection via the tree policy. A key component of BCTuner is a reward mechanism tailored to different types of tuning actions, enabling effective guidance of the search process. For validation-related actions, a sparse reward is adopted to enforce feasibility constraints: an invalid configuration receives a negative reward 𝑟 = −1, while a valid configuration is assigned 𝑟 = 1, allowing the search to quickly eliminate infeasible branches. For performance-related actions, including evaluation 8

more than 10%. Overall, pruning combines search-stage constraints, action outcomes, and runtime feedback to guide the search toward promising trajectories and reduce unnecessary evaluations.

5 EXPERIMENTAL EVALUATION 5.1 Experimental Setup Blockchain Platforms: We evaluate two representative blockchain systems, Hyperledger Fabric (hereafter referred to as Fabric) and ChainMaker. For Fabric, we use the latest LTS version v2.5.12 with the Raft consensus protocol and an “OR” endorsement policy, deploying all components via Docker containers. For ChainMaker (v2.3.7), smart contracts are executed within a Docker-based containerized runtime environment. Hardware and Environment: All experiments are conducted on cloud servers running Ubuntu 22.04 LTS. The blockchain system runs on six instances (16 vCPU, AMD EPYC 9754, 32 GB RAM, 500 GB SSD). Benchmark execution is performed on a separate client machine (Intel Xeon Platinum 8576C, 20 vCPU, 96 GB RAM, 1 TB SSD). All servers and clients are connected via a 5 Gbps internal network. BCTuner is implemented in Python 3.9.

Figure 2: Tuning performance comparison under the SmallBank workload across different network architectures.

Workload: On Fabric, we use the Simple and SmallBank smart contracts, which are widely adopted and representative of generalpurpose and financial workloads [18, 28, 36]. Experiments are conducted using Hyperledger Caliper [22] with 50,000 transactions under fixed-rate mode. On ChainMaker, we evaluate the system using chainmaker-bench with 50,000 transactions in automated testing mode. TPS (transactions per second) measures the number of successfully committed transactions. Baseline: We consider the following baseline methods: • SMAC [21] is a Bayesian optimization method that uses random forests to handle high-dimensional heterogeneous knob spaces. • GP [14, 40] is a Bayesian optimization method that uses Gaussian processes to model configuration–performance relationships. • GPTuner [26] is an LLM-assisted tuning method that reduces the search space via knowledge extraction and applies coarseto-fine Bayesian optimization. • Athena [28] is a reinforcement learning–based tuning system for Fabric that uses PB-MADDPG, a multi-agent deep reinforcement learning algorithm, to optimize system configurations.

Figure 3: Tuning performance comparison under the Simple workload across different network architectures. lines denote the median TPS, and the shaded regions show the observed TPS fluctuation across the three runs.

Tuning Settings: In all experiments, BCTuner jointly tunes all 120 Fabric knobs, with ranges derived from official manuals and knob semantics. Directly applying baseline methods to the full Fabric knob set is often ineffective, because inter-knob dependencies frequently lead to invalid configurations that prevent the blockchain network from starting properly. These invalid trials provide no valid performance feedback, limiting the ability of data-driven methods to update their surrogate models or search policies. Therefore, we select 50 performance-critical knobs for the baselines based on expert experience. For ChainMaker, all methods tune the complete set of 38 system-provided knobs. Value ranges are taken from official documentation when available; otherwise, they are set to [0.1×, 10×] of the default values. Each experiment is repeated three times. We report the best TPS from the median run. In the plots, the solid

5.2

Tuning Effectiveness and Efficiency

This subsection evaluates the proposed method BCTuner against Default, GPTuner, Athena, SMAC, and GP under different workloads and Fabric network architectures to assess its effectiveness and efficiency in knob tuning. We consider the SmallBank and Simple smart contracts as representative workloads and conduct experiments on Fabric networks with 4, 8, 12, 16, 20, and 24 Peer nodes. In all experiments, the number of Orderer nodes is fixed at five. Peer nodes are deployed with two Peers per organization across six servers, while Orderer nodes are placed on five of these servers. The results are shown in Fig. 2 and Fig. 3. 9

Table 2: Ablation study of BCTuner under the 5o8p network with the SmallBank workload.

Overall, the results show that BCTuner consistently achieves the best performance across all experimental settings. Across different Fabric network architectures ranging from 4 to 24 Peer nodes, BCTuner achieves TPS improvements of (102.77%, 102.84%, 70.57%, 28.2%, 34.39%, 30.87%) in the SmallBank workload over default settings, with an average gain of 61.61%, and reaches peak performance within (8, 20, 7, 7, 13, 17) iterations. For the Simple workload, BCTuner achieves TPS improvements of (211.38%, 146.62%, 135.4%, 53.22%, 56.45%, 36.95%), with an average gain of 106.67%, and converges to the optimal configuration within (6, 21, 12, 6, 14, 11) iterations. These results suggest that BCTuner effectively uncovers performance potential left untapped by default configurations, delivering substantial throughput improvements across network scales while requiring relatively few iterations.

Method BCTuner - w/o Knob Knowl - w/o Hardware Knowl - w/o Network Knowl - w/o Global Tuning Plan - w/o Cluster-wise Tuning - w/o Single-knob Tuning - w/o Validation & Fix - w/o Feedback-driven - w/o Pruning Rules

Compared with GPTuner, BCTuner achieves higher TPS and faster convergence across all settings. As shown in Fig. 2 and Fig. 3, under 4–24 Peer nodes, BCTuner improves TPS by 14.88% on average on SmallBank (5.26%, 33.21%, 19.56%, 8.76%, 8.45%, 14.02%) with 7.33× faster convergence (9.63, 3.05, 12.71, 11, 5.5, 2.05). On Simple, it achieves 19.01% improvement (23.52%, 48.22%, 9.17%, 7.62%, 4.33%, 21.22%) with 8.27× faster convergence (15, 2.76, 6.33, 12.5, 6.14, 6.91). This gap reflects differences in knowledge utilization and search strategy. GPTuner reduces the search space using prior knowledge but performs optimization within a Bayesian framework. In blockchain systems, reusable prior knowledge is limited, and complex interactions among knobs make it difficult for such approaches to capture global dependencies. In contrast, BCTuner incorporates knob knowledge from manuals and combines it with MCTS process, reducing ineffective trials and improving convergence and final performance.

𝑻∗

𝚫𝑻 (%) 𝑵 ∗ 𝑵 neg 𝑵 err

1417.80 102.85 20 0/24 0/24 1174.25 68.00 9 6/17 8/17 1375.55 96.80 29 8/31 2/31 1281.71 83.38 11 0/13 0/13 1360.04 94.58 21 0/26 2/26 1337.18 91.31 15 0/17 4/17 1356.88 94.13 34 0/34 0/34 1360.04 94.58 21 0/26 2/26 1227.73 75.65 23 3/30 1/30 1386.24 98.33 39 0/43 6/43

faster convergence, respectively. This gap is mainly due to differences in search guidance. Without knob and system knowledge, Bayesian optimization relies on trial-based exploration, leading to inefficient search and slower convergence. In contrast, BCTuner guides the search using multi-source knowledge and structured tuning actions, improving search efficiency and performance. Further analysis across different network scales shows that BCTuner exhibits more pronounced performance advantages over other methods in configurations with 4–12 Peer nodes. In contrast, under configurations with 16–24 Peer nodes, where some servers host both Orderer and multiple Peer nodes, system resources gradually become a bottleneck, limiting the overall room for performance improvement. Even under these conditions, BCTuner consistently outperforms all baselines, demonstrating strong robustness. Moreover, benefiting from its pruning mechanism, BCTuner can effectively filter candidate configurations before deployment, thereby reducing unnecessary evaluation overhead; this advantage is particularly evident under low-TPS conditions. Overall, by effectively leveraging domain knowledge and guiding the search process, BCTuner significantly outperforms existing methods in both tuning effectiveness and efficiency.

Athena adopts an online reinforcement learning approach and relies on extensive system interactions, requiring a large number of trials to learn effective tuning strategies. Across all network scales, BCTuner achieves higher peak TPS and faster convergence on both SmallBank and Simple workloads. On SmallBank, BCTuner improves TPS by 18.94% on average (14.91%, 40.48%, 21.20%, 11.62%, 10.60%, 14.82%) and achieves 7.90× faster convergence (9.5, 3.7, 11.85, 11.71, 6.23, 4.41). On Simple, it achieves 20.71% average improvement (42.21%, 29.5%, 18.33%, 13.51%, 8.7%, 11%) with 8.19× faster convergence (13.5, 3.19, 6.41, 14.3, 5.5, 6.18). This gap mainly reflects differences in exploration efficiency. Reinforcement learning methods typically require extensive trial-and-error interactions to learn effective tuning policies. In contrast, BCTuner uses knob semantics, system-level knowledge, and structured tuning actions to constrain the search process, thereby reducing ineffective trials and achieving faster convergence with higher performance.

5.3

Ablation Study

The purpose of this ablation study is to analyze the contribution of key components in BCTuner, including multi-Source blockchain knowledge, tuning actions, and pruning strategy. All experiments are performed on a 5o8p network using the SmallBank workload. We report the following metrics:𝑇 ∗ (best achieved TPS), Δ𝑇 (relative improvement over the default configuration, in %), 𝑁 ∗ (number of evaluations required to reach 𝑇 ∗ ), 𝑁 neg (number of configurations with performance lower than the default), and 𝑁 err (number of invalid configurations).

Compared with SMAC and GP, BCTuner achieves higher TPS and faster convergence. As shown in Fig. 2 and Fig. 3, on SmallBank, BCTuner improves TPS by 23.42% over SMAC (14.29%, 50.72%, 37.46%, 10.21%, 11.69%, 16.14%) and 36.43% over GP (76.6%, 58.24%, 39.9%, 11.29%, 21.56%, 10.95%), with 8.01× (10.5, 3.65, 12.43, 11.14, 5.85, 4.47) and 6.08× (6.625, 3.75, 9.57, 11.86, 4.15, 0.529) faster convergence, respectively. On Simple, it achieves 35.37% improvement over SMAC (84.43%, 54.34%, 36.31%, 18.56%, 4.18%, 14.38%) and 41.5% over GP (51.86%, 88.08%, 48.81%, 27.72%, 9.77%, 22.77%), with 7.96× (13.83, 3.66, 6.08, 12, 4.71, 7.45) and 7× (14.33, 1.86, 5.8, 9.5, 4.57, 5.9)

Impact of Multi-Source Blockchain Knowledge. We analyze the effect of removing different knowledge, including knob, hardware and network knowledge. As shown in Table 2, eliminating any of these knowledge sources leads to performance degradation. Removing knob knowledge causes the largest degradation, with Δ𝑇 dropping by 34.85%, and leads to a high proportion of invalid 10

configurations, with nearly half being invalid. It also produces many configurations worse than the default, indicating that knob-level semantics are essential for ensuring configuration validity and effective search. Removing hardware knowledge reduces tuning stability, with nearly one third of configurations either invalid or worse than the default, suggesting that without accurate capacity information, configurations may violate hardware constraints or underutilize resources. Removing network knowledge decreases Δ𝑇 by 19.47%; although no invalid configurations are observed, the search converges to suboptimal regions, indicating that network-level knowledge is required to capture blockchain system characteristics and guide the search. Overall, different types of knowledge play complementary roles in BCTuner. Knob knowledge ensures validity, hardware knowledge improves stability, and network knowledge guides the search toward better configurations. These results highlight that effective tuning requires the combined use of these knowledge sources.

Figure 4: Tuning performance comparison on ChainMaker under different workloads.

in both architecture and execution model. Fabric follows an execute– order–validate paradigm with modularized stages, while ChainMaker adopts a more integrated transaction processing pipeline with distinct consensus and execution mechanisms, resulting in different performance bottlenecks and tuning behaviors. BCTuner consistently outperforms the default configuration across all workloads. Under 20p, 200b, and 350b, it achieves TPS improvements of 144.58%, 135.48%, and 123.71%, respectively, with an average gain of 134.59%, and reaches the best configuration within 19, 20, and 12 evaluations. Compared with Athena, BCTuner achieves higher TPS in all settings, with improvements of 11.22%, 20.94%, and 15.48%. It also converges 4.15× faster on average, requiring fewer evaluations to reach high-quality configurations. As shown in Fig. 4, BCTuner attains higher performance with fewer iterations, while Athena converges more slowly and often remains in suboptimal regions. These results demonstrate the adaptability of BCTuner across different blockchain systems. By leveraging knowledge derived from system documentation and incorporating runtime feedback, BCTuner captures system-specific characteristics and adjusts configurations accordingly. Combined with MCTS-based search, it achieves effective tuning without system-specific customization.

Impact of Tuning Actions. We analyze the effect of removing different action modules in the MCTS process, including Global Tuning Plan, Cluster-wise Tuning, Single-knob Tuning, Validation and Fix, and Feedback-driven Refinement. Removing Global Tuning Plan has limited impact on final performance, suggesting that its role can be partially compensated by subsequent actions during the search process. In contrast, removing Cluster-wise Tuning leads to a clear performance drop, with Δ𝑇 decreasing by 11.5%, and results in a high proportion of invalid configurations (4/17). Without structured grouping, the search operates over the full knob space, increasing dimensionality and making it difficult to capture interactions among knobs. Removing Single-knob Tuning increases 𝑁 ∗ from 20 to 34, indicating substantially slower convergence, as the search cannot efficiently refine configurations without fine-grained adjustments. Removing Validation & Fix introduces invalid configurations (2/26), indicating reduced robustness, since infeasible configurations may propagate during the search and degrade reliability. Removing Feedback-driven Refinement causes substantial performance degradation, with Δ𝑇 dropping by 27.2%. Without feedback, the LLM cannot incorporate execution errors and performance outcomes, weakening the alignment between actions and observed outcomes. Overall, these actions play complementary roles in structuring and stabilizing the search process. Cluster-wise Tuning and Feedback-driven Refinement have the largest impact on performance, while Single-knob Tuning improves efficiency and Validation & Fix ensures robustness.

5.5

Impact of Pruning Rules. Disabling pruning during the search leads to a substantial increase in evaluations. The search expands from 24 to 43 steps and requires 39 evaluations to reach the best configuration. Without pruning, the search explores a larger portion of the configuration space, including redundant and low-quality candidates, which reduces efficiency. These results indicate that pruning is essential for constraining the search space and improving exploration efficiency in high-dimensional tuning.

5.4

Execution Time Breakdown

To analyze the tuning time of BCTuner, we introduce a set of timerelated metrics. Total tuning time (All) consists of search overhead (SR), deployment (DP), and evaluation (EV). DP denotes the time to deploy and initialize the blockchain system under a given configuration, EV denotes workload execution and metric collection, and SR denotes the computational overhead of MCTS, including node selection and backpropagation. Action execution (AE) is decomposed into A1–A7, corresponding to Global Tuning Plan, Cluster-wise Tuning, Single-knob Tuning, Knob Validation, Knob Fix, Performance Evaluation, and Feedback-driven Refinement, each reported as the average execution time per step. As shown in Table 3, we report both the overall time breakdown and the average execution time of A1–A7. The results show that DP and EV dominate the total tuning time across workloads (SmallBank and Simple) and network settings (5o8p and 5o20p), while SR remains small, indicating that the main bottleneck lies in deployment and benchmarking rather than the search process. Among actions, A6 and A7 incur higher costs due to their reliance on deployment and workload evaluation.

Cross-System Adaptability

To evaluate the adaptability of BCTuner across blockchain systems, we conduct experiments on ChainMaker, which differs from Fabric 11

Table 3: Time Breakdown of BCTuner under Different Workloads and Network Architectures

Workload

Network

All

SR

DP

EV

A1

A2

A3

A4

A5

A6

A7

Overhead (%)

SmallBank SmallBank Simple Simple

5o8p 5o20p 5o8p 5o20p

4615.89 11283.31 7307.65 12435.49

345.38 345.68 368.88 337.25

1478.42 4102.36 2288.86 4244.48

2956.80 6872.30 4750.87 8036.89

4.62 4.35 2.91 2.59

4.70 4.57 5.34 4.75

4.29 4.03 3.72 3.76

5.77 5.41 5.46 5.83

7.42 8.18 5.70 6.04

244.27 259.41 229.73 604.50

453.96 1558.06 1160.29 2228.73

7.48 3.06 5.05 2.71

Table 4: Comparison of Different LLM Backbones under the 5o8p Network with the SmallBank Workload LLM Backbone

𝑻∗

𝚫𝑻

𝑵∗

𝑵 neg

𝑵 err

Interact

Prompt Tokens

Completion Tokens

Cost ($)

GPT-5-mini GPT-5 GPT-5.2 Gemini-3-Flash Gemini-3.1-Pro Gemini-2.5-Flash Gemini-2.5-Pro Deepseek-v3 Deepseek-R1 Qwen3-32b

1417.80 1435.68 1433.75 1399.00 1445.56 1130.83 1369.72 1078.75 1333.69 939.93

102.85 105.41 105.13 100.16 106.82 61.79 95.97 54.34 90.81 34.48

20 15 15 18 15 14 10 3 18 4

0/24 0/18 2/18 0/24 0/18 1/15 0/18 0/12 2/26 0/8

0/24 2/18 0/18 0/19 0/18 1/15 4/18 6/12 1/26 3/8

186 205 164 198 284 148 157 210 199 167

2952.87K 3189.12K 2596.24K 3037.29K 4441.36K 2309.42K 2429.89K 3228.82K 3256.69K 2516.29K

50.04K 50.47K 31.06K 22.46K 37.79K 29.71K 19.94K 26.01K 33.08K 12.13K

0.84 4.49 4.98 1.59 9.34 0.77 3.24 0.95 0.96 -

BCTuner improves efficiency by reducing the number of deployment and evaluation rounds through guided search, enabling it to reach high-quality configurations with fewer evaluations and lower overall tuning time. This advantage is more pronounced in low-TPS settings, where each evaluation is more expensive. Overall, BCTuner reduces costly system operations, improving efficiency and scalability in practical settings.

5.6

4.4M across models, corresponding to $0.77–$9.34. Efficiency varies across backbones: lightweight models (e.g., GPT-5-mini and Gemini2.5-Flash) achieve comparable performance with lower token usage. Overall, BCTuner maintains low LLM-related cost while achieving strong tuning performance, indicating good cost-effectiveness for practical deployment.

6

Effect of Different LLM Backbones

In this paper, we studied the problem of automatic configuration tuning for permissioned blockchains, which is inherently challenging due to the high-dimensional configuration space, complex dependencies among system knobs, and the high cost of evaluation. To address these challenges, we proposed BCTuner, an LLM-guided framework that integrates knowledge-driven reasoning with structured search for efficient tuning. The key idea of BCTuner is to formulate configuration tuning as a structured and iterative decision process, rather than a black-box trial-and-error approach or one-shot configuration generation. By incorporating multi-source knowledge and leveraging Monte Carlo Tree Search with pruning, BCTuner effectively guides the search toward high-quality configurations while significantly reducing unnecessary evaluations, resulting in more efficient optimization in complex configuration spaces. We implemented BCTuner and evaluated it on Hyperledger Fabric and ChainMaker under diverse workloads and network settings. The results show that BCTuner consistently achieves substantial performance improvements.

We further study how the choice of LLM backbone affects BCTuner by conducting experiments on the 5o8p Fabric network with the SmallBank workload. We instantiate BCTuner with ten models, including GPT-5-mini, GPT-5, GPT-5.2, Gemini-3-Flash, Gemini3.1-Pro, Gemini-2.5-Flash, Gemini-2.5-Pro, Deepseek-v3, DeepseekR1, and Qwen3-32b. As shown in Table 4, all evaluated backbones improve throughput over the default configuration, while exhibiting clear differences in final performance, convergence, invalid configurations, token usage, and monetary cost. Gemini-3.1-Pro achieves the highest throughput, while GPT-5 and GPT-5.2 obtain comparable performance with fewer evaluations. GPT-5-mini and Gemini-2.5-Flash achieve competitive tuning performance at relatively low monetary cost. Overall, these results show that BCTuner can work with different LLM backbones, and its effectiveness is not tied to a specific model.

5.7

CONCLUSION

Cost analysis

In LLM-driven blockchain knob tuning, the overhead mainly comes from LLM interactions. BCTuner avoids costly data collection and pre-training by leveraging textual knowledge, and reaches 𝑁 ∗ within few iterations. We evaluate cost in terms of token consumption (prompt and completion), monetary expense, and interaction steps. As shown in Table 4, total token usage ranges from 2.3M to

ACKNOWLEDGMENTS This work was supported by the [...] Research Fund of [...] (Number [...]). Additional funding was provided by [...] and [...]. We also thank [...] for contributing [...]. 12

REFERENCES

[23] JPMorgan Chase. 2024. Tokenized Assets on Blockchain via Onyx Platform. https://www.jpmorgan.com/kinexys. Accessed: 2026-04. [24] Konstantinos Kanellis, Cong Ding, Brian Kroth, Andreas Müller, Carlo Curino, and Shivaram Venkataraman. 2022. LlamaTune: sample-efficient DBMS configuration tuning. Proc. VLDB Endow. 15, 11 (July 2022), 2953–2965. https: //doi.org/10.14778/3551793.3551844 [25] Levente Kocsis and Csaba Szepesvári. 2006. Bandit based monte-carlo planning. In European conference on machine learning. Springer, 282–293. [26] Jiale Lao, Yibo Wang, Yufei Li, Jianping Wang, Yunjia Zhang, Zhiyuan Cheng, Wanghu Chen, Mingjie Tang, and Jianguo Wang. 2025. GPTuner: An LLM-Based Database Tuning System. ACM SIGMOD Record 54, 1 (2025), 101–110. [27] Guoliang Li, Xuanhe Zhou, Shifu Li, and Bo Gao. 2019. Qtune: A query-aware database tuning system with deep reinforcement learning. Proceedings of the VLDB Endowment 12, 12 (2019), 2118–2130. [28] Mingxuan Li, Yazhe Wang, Shuai Ma, Chao Liu, Dongdong Huo, Yu Wang, and Zhen Xu. 2023. Auto-Tuning with Reinforcement Learning for Permissioned Blockchain Systems. Proc. VLDB Endow. 16, 5 (Jan. 2023), 1000–1012. https: //doi.org/10.14778/3579075.3579076 [29] Yiyan Li, Haoyang Li, Jing Zhang, Renata Borovica-Gajic, Shuai Wang, Tieying Zhang, Jianjun Chen, Rui Shi, Cuiping Li, and Hong Chen. 2025. AgentTune: An Agent-Based Large Language Model Framework for Database Knob Tuning. Proceedings of the ACM on Management of Data 3, 6 (2025), 1–29. [30] Zhaodonghui Li, Haitao Yuan, Huiming Wang, Gao Cong, and Lidong Bing. 2024. LLM-R2: A large language model enhanced rule-based rewrite system for boosting query efficiency. arXiv preprint arXiv:2404.12872 (2024). [31] Jie Liu and Barzan Mozafari. 2026. GenRewrite: Query Rewriting via Large Language Models. Proc. ACM Manag. Data 4, 1, Article 70 (April 2026), 26 pages. https://doi.org/10.1145/3786684 [32] Nelson F Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the middle: How language models use long contexts. Transactions of the association for computational linguistics 12 (2024), 157–173. [33] PGTune. 2014. PGTune: PostgreSQL Configuration Tuning Tool. https://pgtune. leopard.in.ua. Accessed: 2026-04-20. [34] Ripple. 2026. Ripple: Financial Infrastructure and Blockchain Solutions. https: //ripple.com/. Accessed: 2026-04. [35] Pingcheng Ruan, Tien Tuan Anh Dinh, Dumitrel Loghin, Meihui Zhang, Gang Chen, Qian Lin, and Beng Chin Ooi. 2021. Blockchains vs. distributed databases: Dichotomy and fusion. In Proceedings of the 2021 International Conference on Management of Data. 1504–1517. [36] Ankur Sharma, Felix Martin Schuhknecht, Divya Agrawal, and Jens Dittrich. 2019. Blurring the lines between blockchains and database systems: the case of hyperledger fabric. In Proceedings of the 2019 International Conference on Management of Data. 105–122. [37] David G Sullivan, Margo I Seltzer, and Avi Pfeffer. 2004. Using probabilistic reasoning to automate software tuning. ACM SIGMETRICS Performance Evaluation Review 32, 1 (2004), 404–405. [38] Jian Tan, Tieying Zhang, Feifei Li, Jie Chen, Qixing Zheng, Ping Zhang, Honglin Qiao, Yue Shi, Wei Cao, and Rui Zhang. 2019. Ibtune: Individualized buffer tuning for large-scale cloud databases. Proc. VLDB Endow. 12, 10 (2019), 1221–1234. [39] Immanuel Trummer. 2022. DB-BERT: a Database Tuning Tool that" Reads the Manual". In Proceedings of the 2022 international conference on management of data. 190–203. [40] Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. 2017. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 ACM international conference on management of data. 1009–1024. [41] Dana Van Aken, Dongsheng Yang, Sebastien Brillard, Ari Fiorino, Bohan Zhang, Christian Bilien, and Andrew Pavlo. 2021. An inquiry into machine learningbased automatic configuration tuning services on real-world database management systems. Proceedings of the VLDB Endowment 14, 7 (2021), 1241–1253. [42] Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, Linzheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, et al. 2025. MAC-SQL: A MultiAgent Collaborative Framework for Text-to-SQL. In COLING. 540–557. [43] Junxiong Wang, Immanuel Trummer, and Debabrota Basu. 2021. UDO: universal database optimization using reinforcement learning. Proc. VLDB Endow. 14, 13 (Sept. 2021), 3402–3414. https://doi.org/10.14778/3484224.3484236 [44] we.trade. 2023. we.trade: Blockchain-Based Trade Finance Platform. https://wetrade.com/. Accessed: 2026-04. [45] Xiwei Xu, Ingo Weber, Mark Staples, Liming Zhu, Jan Bosch, Len Bass, Cesare Pautasso, and Paul Rimba. 2017. A Taxonomy of Blockchain-Based Systems for Architecture Design. In 2017 IEEE International Conference on Software Architecture (ICSA). 243–252. https://doi.org/10.1109/ICSA.2017.33 [46] Zihan Yan, Rui Xi, and Mengshu Hou. 2025. MCTuner: Spatial DecompositionEnhanced Database Tuning via LLM-Guided Exploration. Proceedings of the ACM on Management of Data 3, 6 (2025), 1–25. [47] An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 technical

[1] 2024. ChainMaker: A Next-Generation Permissioned Blockchain Platform. https: //chainmaker.org.cn/home. Accessed: 2026-04-22. [2] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023). [3] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. 2018. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference. 1–15. [4] Jason Ansel, Shoaib Kamil, Kalyan Veeramachaneni, Jonathan Ragan-Kelley, Jeffrey Bosboom, Una-May O’Reilly, and Saman Amarasinghe. 2014. Opentuner: An extensible framework for program autotuning. In Proceedings of the 23rd international conference on Parallel architectures and compilation. 303–316. [5] Jiayuan Bai, Xuan-guang Pan, Chongyang Tao, and Shuai Ma. 2025. JudgeSQL: Reasoning over SQL Candidates with Weighted Consensus Tournament. arXiv preprint arXiv:2510.15560 (2025). [6] Yushi Bai, Xin Lv, Jiajie Zhang, Hongchang Lyu, Jiankai Tang, Zhidian Huang, Zhengxiao Du, Xiao Liu, Aohan Zeng, Lei Hou, et al. 2024. Longbench: A bilingual, multitask benchmark for long context understanding. In Proceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers). 3119–3137. [7] Bank for International Settlements. 2024. Project mBridge: Multi-CBDC Platform for Cross-Border Payments. https://www.bis.org/about/bisih/topics/cbdc/ mcbdc_bridge.htm. Accessed: 2026-04. [8] Alexander Bianchi, Rafael Dolores, Andrew Chai, Vincent Corvinelli, Parke Godfrey, Jarek Szlichta, and Calisto Zuzarte. 2025. Db2une: Tuning ibm db2 with deep learning. In 2025 IEEE 41st International Conference on Data Engineering (ICDE). IEEE, 4540–4543. [9] Baoqing Cai, Yu Liu, Ce Zhang, Guangyu Zhang, Ke Zhou, Li Liu, Chunhua Li, Bin Cheng, Jie Yang, and Jiashu Xing. 2022. HUNTER: an online cloud database hybrid tuning system for personalized requirements. In Proceedings of the 2022 International Conference on Management of Data. 646–659. [10] Stefano Cereda, Stefano Valladares, Paolo Cremonesi, Stefano Doni, et al. 2021. Cgptuner: a contextual gaussian process bandit approach for the automatic tuning of it configurations under varying workload conditions. Proceedings of the VLDB Endowment 14, 8 (2021), 1401–1413. [11] Sibei Chen, Ju Fan, Bin Wu, Nan Tang, Chao Deng, Pengyi Wang, Ye Li, Jian Tan, Feifei Li, Jingren Zhou, and Xiaoyong Du. 2025. Automatic Database Configuration Debugging using Retrieval-Augmented Language Models. Proc. ACM Manag. Data 3, 1, Article 13 (Feb. 2025), 27 pages. https://doi.org/10.1145/3709663 [12] Coinbase. 2024. Coinbase: Institutional Digital Asset Custody and Exchange. https://www.coinbase.com/institutional. Accessed: 2026-04. [13] Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Ji Wang. 2018. Untangling Blockchain: A Data Processing View of Blockchain Systems. IEEE Transactions on Knowledge and Data Engineering 30, 7 (2018), 1366–1385. https://doi.org/10.1109/TKDE.2017.2781227 [14] Songyun Duan, Vamsidhar Thummala, and Shivnath Babu. 2009. Tuning database configuration parameters with ituned. Proceedings of the VLDB Endowment 2, 1 (2009), 1246–1257. [15] Jia-Ke Ge, Yan-Feng Chai, and Yun-Peng Chai. 2021. WATuning: a workloadaware tuning system with attention-based deep reinforcement learning. Journal of Computer Science and Technology 36, 4 (2021), 741–761. [16] Victor Giannakouris and Immanuel Trummer. 2025. 𝜆 -tune: Harnessing large language models for automated database system tuning. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–26. [17] Global Shipping Business Network. 2023. GSBN: Blockchain-Based Data Infrastructure for Global Supply Chains. https://www.gsbn.trade/. Accessed: 2026-04. [18] Christian Gorenflo, Stephen Lee, Lukasz Golab, and Srinivasan Keshav. 2020. FastFabric: Scaling hyperledger fabric to 20 000 transactions per second. International Journal of Network Management 30, 5 (2020), e2099. [19] Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. 2025. DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning. Nature 645, 8081 (2025), 633–638. [20] Xinmei Huang, Haoyang Li, Jing Zhang, Xinxin Zhao, Zhiming Yao, Yiyan Li, Tieying Zhang, Jianjun Chen, Hong Chen, and Cuiping Li. 2025. E2ETune: Endto-End Knob Tuning via Fine-Tuned Generative Language Model. Proc. VLDB Endow. 18, 13 (Sept. 2025), 5540–5554. https://doi.org/10.14778/3773731.3773732 [21] Frank Hutter, Holger H Hoos, and Kevin Leyton-Brown. 2011. Sequential modelbased optimization for general algorithm configuration. In International conference on learning and intelligent optimization. Springer, 507–523. [22] Hyperledger. 2026. Hyperledger Caliper Documentation (v0.7.1). https:// hyperledger-caliper.github.io/caliper/0.7.1/. Accessed: 2026-04-28. 13

[51] Xinyi Zhang, Hong Wu, Yang Li, Zhengju Tang, Jian Tan, Feifei Li, and Bin Cui. 2023. An efficient transfer learning based configuration adviser for database tuning. Proceedings of the VLDB Endowment 17, 3 (2023), 539–552. [52] Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. 2024. D-Bot: Database Diagnosis System using Large Language Models. Proc. VLDB Endow. 17, 10 (June 2024), 2514–2527. https://doi.org/10.14778/3675034.3675043 [53] Yuqing Zhu, Jianxun Liu, Mengying Guo, Yungang Bao, Wenlong Ma, Zhuoyue Liu, Kunpeng Song, and Yingchun Yang. 2017. Bestconfig: tapping the performance potential of systems via automatic configuration tuning. In Proceedings of the 2017 symposium on cloud computing. 338–350.

report. arXiv preprint arXiv:2505.09388 (2025). [48] Ji Zhang, Ke Zhou, Guoliang Li, Yu Liu, Ming Xie, Bin Cheng, and Jiashu Xing. 2021. CDBTune+: An efficient deep reinforcement learning-based automatic cloud database tuning system. The VLDB Journal 30, 6 (2021), 959–987. [49] Xinyi Zhang, Hong Wu, Zhuo Chang, Shuowei Jin, Jian Tan, Feifei Li, Tieying Zhang, and Bin Cui. 2021. Restune: Resource oriented tuning boosted by metalearning for cloud databases. In Proceedings of the 2021 international conference on management of data. 2102–2114. [50] Xinyi Zhang, Hong Wu, Yang Li, Jian Tan, Feifei Li, and Bin Cui. 2022. Towards dynamic and safe configuration tuning for cloud databases. In Proceedings of the 2022 International Conference on Management of Data. 631–645.

14

Related documents

• String Diagrams for Process Mining#978502
• ZigZag Trie: A Novel Index for Contextual Queries#978503
• A Functional Pilot for Certified Freshness-Aware Semantic--Spatial Range Retrieval#978504
• Efficiently Linking Unstructured Data for Multi-step Reasoning#978505