Description
When utilizing the miner_changeTargetGasLimit JSON-RPC method to dynamically adjust the target block gas limit, the node returns a JsonRpcSuccessResponse. However, if the node is operating on a network utilizing a PoW, IBFT, or QBFT consensus mechanism, the gas limit is never actually updated. The node continues block creation using the previous gas limit, misleading operators into believing the configuration change was successfully applied.
Steps to Reproduce
- Start a Besu node configured with a PoW or BFT (e.g., IBFT 2.0 or QBFT) consensus mechanism.
- Ensure the JSON-RPC service is enabled with the
MINER API exposed.
- Send a JSON-RPC request to change the target gas limit:
{
"jsonrpc": "2.0",
"method": "miner_changeTargetGasLimit",
"params": ["0x1000000"],
"id": 1
}
- Observe the 200 OK successful response.
- Check the gas limit of newly mined blocks; observe that they still target the original, un-updated gas limit.
Expected Behavior
The node should update its internal MiningConfiguration with the new target gas limit and immediately begin targeting the new limit for subsequent block creation.
Actual Behavior
The API request succeeds, but the MiningConfiguration is completely bypassed. The target block gas limit remains unchanged.
Root Cause
The miner_changeTargetGasLimit RPC endpoint delegates the call to the current MiningCoordinator. For non-Merge networks, this delegates to the changeTargetGasLimit(Long) method in AbstractMinerExecutor.java.
As seen in ethereum/blockcreation/src/main/java/org/hyperledger/besu/ethereum/blockcreation/AbstractMinerExecutor.java:
public void changeTargetGasLimit(final Long newTargetGasLimit) {
if (AbstractGasLimitSpecification.isValidTargetGasLimit(newTargetGasLimit)) {
// BUG: Empty block. The miningConfiguration is never updated.
} else {
throw new UnsupportedOperationException("Specified target gas limit is invalid");
}
}
The method correctly validates the target gas limit but contains an empty if block, meaning it silently does nothing instead of calling miningConfiguration.setTargetGasLimit(newTargetGasLimit);.
(Note: The MergeCoordinator correctly sets this property, so post-Merge networks are unaffected by this bug).
Environment
- Besu version: main (and earlier versions)
- Consensus mechanism: PoW, IBFT 2.0, QBFT
- OS: Cross-platform
Description
When utilizing the
miner_changeTargetGasLimitJSON-RPC method to dynamically adjust the target block gas limit, the node returns aJsonRpcSuccessResponse. However, if the node is operating on a network utilizing aPoW,IBFT, orQBFTconsensus mechanism, the gas limit is never actually updated. The node continues block creation using the previous gas limit, misleading operators into believing the configuration change was successfully applied.Steps to Reproduce
MINERAPI exposed.{ "jsonrpc": "2.0", "method": "miner_changeTargetGasLimit", "params": ["0x1000000"], "id": 1 }Expected Behavior
The node should update its internal
MiningConfigurationwith the new target gas limit and immediately begin targeting the new limit for subsequent block creation.Actual Behavior
The API request succeeds, but the
MiningConfigurationis completely bypassed. The target block gas limit remains unchanged.Root Cause
The
miner_changeTargetGasLimitRPC endpoint delegates the call to the currentMiningCoordinator. For non-Merge networks, this delegates to thechangeTargetGasLimit(Long)method inAbstractMinerExecutor.java.As seen in
ethereum/blockcreation/src/main/java/org/hyperledger/besu/ethereum/blockcreation/AbstractMinerExecutor.java:The method correctly validates the target gas limit but contains an empty
ifblock, meaning it silently does nothing instead of callingminingConfiguration.setTargetGasLimit(newTargetGasLimit);.(Note: The
MergeCoordinatorcorrectly sets this property, so post-Merge networks are unaffected by this bug).Environment