[qu0b]

A released benchmark snapshot can have a much higher block gas limit than the shadowfork needs. This lets a pre-run lower that limit—for example, from 1T to 200M—and record the new blocks for other clients to replay.

• Uses Amsterdam's targetGasLimit to ramp down and hold the requested limit. A configured fork transition can complete before ramp-down starts; the block limit still applies.
• Adds fill: false to skip EEST setup and base_bundle to continue from an existing recorded chain. The new bundle contains only the additional blocks, so consumers replay the base first.
• Streams large replay bundles instead of loading them into memory, and continues the parent's Amsterdam slot number.
• Gives every pre-run client time to flush its database on shutdown. A forced kill or failed shutdown fails the target.

Validation: builder/config tests, fork-transition regressions, real Geth gas-limit checks, and replay of the 49.7 GB release bundle. CI passes.

Used by benchmarkoor-tests #44.

[redpandabot]

Summary

This PR makes the builder's gas bump bidirectional (via the Amsterdam targetGasLimit payload attribute), adds fill: false for a ramp-only pre-run, streams replay bundles instead of loading them whole, and lets replay targets take a base_bundle. The streaming and fill: false work look sound and the prior two findings (tests required, fill undocumented) are fixed; I found one functional gap in the ramp-down check for predeploy targets and one documentation omission.

Issues

• 🟡 pkg/builder/engine.go:673 — ramp-down aborts on a predeploy target's first pre-fork bump block — see the thread on that line
• 🟢 docs/configuration.md — new base_bundle option is undocumented in the configuration reference — base_bundle is a new per-target option (pkg/config/pre_runs.go:188) used by both the fill and replay paths, but the builder.pre_runs.targets[] table in docs/configuration.md still lists only replay_from; only config.example.yaml mentions it. A row describing the pre-run it continues and the replay order (base, then the target's own bundle / replay_from) belongs next to replay_from.

---

_{Reviewed @ 2a66455c
"The most dangerous phrase in the language is 'we've always done it this way.'" — Grace Hopper}

[redpandabot]

🟡 ramp-down aborts on a predeploy target's first pre-fork bump block

With predeploy, the funding/deploy blocks are built pre-fork and the gas bump is what crosses into Amsterdam (forkAt returns preFork until activationTS). If the head is above gas_limit and the first bump block is still pre-fork, buildBlock sends no targetGasLimit, the limit rises, and this check returns an error on block 1 — even though the later Amsterdam blocks would ramp it down. The pre-fork bump is the expected case when activation is more than one block after the deploy block, so this combination cannot use ramp-down.

[redpandabot]

This PR adds a downward gas-limit ramp (payload attribute targetGasLimit), a fill:false mode for gas-ramp-only pre-runs, base_bundle chain continuation, streaming bundle replay, and clean-stop enforcement. The newest commit (adabbd8) lets a ramp-down cross a configured Amsterdam fork instead of aborting on the first pre-fork bump block; I traced that the blockTS/fork computation matches buildBlock and that geth v1.17.7 really does expose and honour targetGasLimit in testing_buildBlockV1/worker.go and returns slotNumber from eth_getBlockByNumber, so the mechanism is sound. Re-checking the prior open findings: fill:false now makes tests optional and skips the EEST checkout, the option is documented in docs/configuration.md and config.example.yaml, and the predeploy first-block abort is fixed by the waitingForAmsterdam guard. I found nothing worth reporting.

---

_{Reviewed 9 changed file(s) @ adabbd88 — no blocking issues found.
"The most dangerous phrase in the language is 'we've always done it this way.'" — Grace Hopper}