You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(ProtocolConfig): add updateTargetBlockTimeMs — the only consensus param with no granular setter and a documented zero-disable semantic #488
ConsensusParams has eight fields. Seven of them have no special zero semantics and are validated with > 0 guards in updateConsensusParams. The eighth, targetBlockTimeMs, is different: its own NatSpec says setting to 0 disables the block time control mechanism. That makes zero a valid, meaningful value — not an error.
Despite this, targetBlockTimeMs is the only consensus field that has no granular setter. IProtocolConfig ships:
updateTimeoutProposeMs
updateBlockGasLimit
but no updateTargetBlockTimeMs.
The problem
A controller that wants to change only targetBlockTimeMs must re-submit the full ConsensusParams struct. Two failure modes follow:
1. Accidental disable. A caller building the struct from a stale copy or an SDK that zero-initialises unknown fields silently passes targetBlockTimeMs = 0, disabling the block time control mechanism with no error, no event distinguishing it from an intentional disable, and no revert.
2. Inconsistency with the rest of the API. Every other individually-adjustable parameter has a single-field setter. targetBlockTimeMs does not, even though it has the most unusual semantics of the set.
Suggested fix
Add to IProtocolConfig and implement in ProtocolConfig:
/// @notice Update only the targetBlockTimeMs in consensus params./// @dev Pass 0 to disable the block time control mechanism (see ConsensusParams.targetBlockTimeMs)./// @dev Access - onlyController / whenNotPaused.function updateTargetBlockTimeMs(uint16newTargetBlockTimeMs) external;
Implementation mirrors updateTimeoutProposeMs — no > 0 guard, because zero is intentional here:
Activity