beacon/engine, eth/catalyst, miner: honor targetGasLimit from payload attributes

[qu0b]

Problem

On glamsterdam-devnet-7 the block gas limit is now driven by the consensus layer: PayloadAttributesV4 carries a required targetGasLimit field (execution-apis#796) that the CL supplies with every engine_forkchoiceUpdatedV4, replacing the static EL-side flag for local building.

geth's PayloadAttributes struct has no such field, so the JSON key is silently dropped and payload building falls back to the local miner gas ceiling (default 60M). In a 12-node devnet-7 network (geth/ethrex/nethermind × lighthouse/teku/lodestar/prysm) with genesis at 150M, the CLs registering 300M, and no EL gas-limit flags, all 58 geth proposals over 166 Gloas blocks stepped the gas limit down by the maximum parent/1024, under all four CLs alike, while every ethrex and nethermind proposal stepped up toward the target. geth proposers permanently fight the CL-configured gas limit.

Fix

• decode targetGasLimit in PayloadAttributes (hex-quantity, mirroring slotNumber)
• reject forkchoiceUpdatedV4 attributes without it (the spec lists it as required), like slotNumber
• thread it through BuildPayloadArgs — included in the payload id, with a tag byte so an args set with only slotNum cannot collide with one with only targetGasLimit (both encode as 8 big-endian bytes) — into the worker, where it takes precedence over miner.config.GasCeil in CalcGasLimit
• internal callers that leave it unset (simulated beacon, testing payloads) keep the existing gas-ceiling behavior

Testing

• TestPayloadAttributesJSON: decodes CL-shaped fcuV4 attributes JSON + round trip
• TestBuildPayloadTargetGasLimit: built payload steers up toward a target above parent, down toward one below, and falls back to GasCeil when unset
• TestForkchoiceUpdatedV4TargetGasLimit: missing field → Invalid payload attributes (-38003); present → proceeds to the fork check
• TestPayloadId: id distinctness for slotNum/targetGasLimit combinations
• full miner, beacon/engine, eth/catalyst suites pass

Devnet validation

Kurtosis network of 4× geth (this branch) under lighthouse, teku, lodestar and prysm; minimal preset, genesis gasLimit 150M, every CL configured to register 300M (--gas-limit / --validators-builder-registration-default-gas-limit / --defaultGasLimit / --suggested-gas-limit), no EL-side gas-limit flags:

• pre-Gloas (fulu, fcuV3) blocks steer down toward the 60M ceiling, as before
• from the Gloas fork on, every geth-built payload steps up at the maximum +parent/1024 rate under all four CLs — 97 up-steps, 150M → 163.5M over ~100 slots and climbing toward 300M
• the only exceptions were a handful of proposals in the first four minutes where teku supplied its own default target before validator registrations were applied — CL-side warm-up, independent of this change

Without the fix (stock glamsterdam-devnet-7 image), the same setup produces 58/58 maximum down-steps on geth proposals.

🤖 Generated with Claude Code