Feature request: QBFT On-Chain Governance for Block/Chain Parameters Updating without off-chain soft forks.

[OlegJakushkin]

Description

As a QBFT PoA-based blockchain author, I want to dynamically update base block parameters (e.g., block size, transaction count, inter-block interval) via an on-chain contract. This capability will enable the blockchain to self-govern, adjusting to varying demand levels:

• Rush hour: Shrink block size and intervals to accommodate higher transaction volumes efficiently.
• Low-demand periods: Extend inter-block time intervals and reduce block sizes to optimize resource usage and minimize storage overhead.

Acceptance Criteria

The system must support the following capabilities, accessible via an on-chain governance contract:

1. Update the maximum transaction count per block.
2. Update the inter-block time interval.
3. Update the maximum block size.

Smart contract information

• Currently, the only method besu looks at is the getValidators view function. Please add more to enable block info updates.

Additional Information

• Besu setup info - I use QBFT with Contract based consensus

Proposed block update API

• add a structure to hold param updates like

    // Define a structure for scheduled parameter changes
    struct ParameterUpdate {
        uint256 startingBlock; // When the new param value becomes active
        bytes32 paramName;     // Parameter name, could be like "MAX_TX_COUNT" or "BLOCK_SIZE"
        uint256 paramValue;    // The new value for the parameter
    }

• add a public callable function for the governance contracts to implement function getParameterUpdates() external view returns (ParameterUpdate[] memory)

[Gabriel-Trintinalia]

@matthew1001 is this something that you think could be useful for QBFT?

[matthew1001]

It's an interesting idea. It strikes me there are 2 separate aspects to it:

1. Allow a QBFT node to change its configuration on the fly without a restart
2. Allow QBFT to be managed through on-chain configuration

1 doesn't necessitate 2 so it's perhaps worth discussing whether the smart-contract config idea is purely to solve 1?

Besu does have the option to reload certain file-based config on the fly through JSON/RPC calls - see e.g. perm_reloadPermissionsFromFile which reloads the permissioning file. So 1 could be addressed in a similar way if we felt that was useful and avoided the complication of on-chain config.

It would be good to understand where you feel the priority/benefit of each is.

[OlegJakushkin]

(2) is the most important one, as it enables users and DApps to respond to on-chain events by synchronizing node configuration directly through the blockchain. This removes the need to manually interact with node providers, effectively separating the execution layer from the control layer. Specifically, it:

• Real-Time Parameter Control: Allows network parameters to be changed by accounts in near real-time, facilitating rapid and frequent updates.
• Decoupled Node Configuration: Ensures nodes adhere to on-chain governance decisions rather than relying on manual configuration from node operators.

In a more ambitious vision, one could imagine a client that ships with all EIPs pre-implemented. On-chain governance would then let accounts enable, disable, or reconfigure chain features on a per-block basis—without requiring ongoing input from client developers or any human intervention.