Using a small LLM to tune gas & block parameters on a Besu (QBFT) fork

Hey folks,

I’ve been working on Studio Blockchain for the past year, it’s a Hyperledger Besu fork running QBFT. We kept it fully EVM-compatible, but one aspect i really wanted to share with you all is something we’re doing around AI-assisted parameter tuning at the consensus layer.

The idea came from a simple pain point: on permissioned/PoA networks like QBFT, gas limits and block times are static configs. If traffic patterns change, you either over-provision (wasteful) or under-provision (latency spikes, stuck txs). Instead of setting a “forever” number, we wanted the chain to react more like an adaptive system.

What we did was bolt on an ops agent that watches telemetry (pending txs, median gas price, block propagation delay, reorgs). The data is bucketed (1s, 10s, 1m, 5m windows) and fed to two pieces:

• a small numeric predictor (gradient-boost model) that just forecasts “what will the mempool look like in 60 seconds” and “how will latency behave if nothing changes.”
• and a lightweight language model (we’re using LLaMA-2 7B instruct-tuned, running locally no API calls) that reads both the raw metrics and the predictor’s output, and spits back a recommendation in JSON.

The LLM is there mostly for interpretability. It doesn’t just say “lower block time,” it gives a rationale in plain English like: “pending gas grew +12% in the last 5 minutes, projected latency crosses 300ms, safe to shave block time from 2.0s to 1.9s since no reorgs were observed.” That’s useful for operators reading the logs.

We don’t let the model touch consensus directly. There’s a controller process that takes every suggestion and runs it through a battery of checks: static bounds (e.g. block time can never go below 1.5s), a mini-simulator that replays a few hundred blocks with the proposed params, and ensemble agreement (the numeric model has to agree it won’t spike reorg risk). Only then does it submit the change to a governance/multisig contract, which validators read on the next epoch.

So in practice the AI layer is more like an advisor with a very strict babysitter. We log every prompt, every output, and every change, so anyone can audit. If you’re curious, you can even see its decisions live here: Studio-Scan AI Dashboard.

From a dev perspective, the interesting bits were:

• LLaMA-2 7B is just small enough to run inference in <500ms on commodity hardware with quantization.
• Prompts have to be extremely compact; we hand-roll a JSON schema for telemetry so the model isn’t distracted.
• The simulator is actually the most important piece we learned that without a cooling period, the model would oscillate suggestions (1.9s → 2.0s → 1.9s). Adding hysteresis fixed it.
• Telemetry poisoning is a real attack surface: in theory someone could spam txs to push a bad recommendation. That’s why we require agreement from the numeric predictor and ignore extreme outliers.

I’m not here to push a token, genuinely curious if anyone in the Ethereum dev/research crowd sees value in this kind of adaptive tuning. Does it sound useful, or is it just adding unnecessary complexity where hand-tuned heuristics would do? And if you’ve played with AI in ops contexts, i’d love to hear where you think the real risks are (model drift, nondeterminism, etc.).

Appreciate any thoughts. Happy to dive deeper into the implementation if anyone’s interested.