Auto-detect blockchain block time from RPC endpoint

[gacevicljubisa]

Summary

Automatically detect and calculate the average block time from the blockchain RPC endpoint instead of requiring manual configuration via the --block-time flag. When a node connects to an RPC endpoint, it would sample recent block timestamps (e.g., last 1000 blocks) to determine the actual average block time of the connected chain, eliminating the need for operators to manually configure this parameter when deploying across different EVM chains with varying block times.

Motivation

Problem: The --block-time flag currently defaults to 5 seconds (configured for Gnosis Chain). When operators deploy Bee nodes on different EVM chains or testnets with different block times, they must manually configure this parameter. Incorrect block time configuration causes timing issues in the storage incentives redistribution game, potentially causing nodes to miss commit/reveal/claim phase windows.

Use cases:

1. Multi-chain deployment: Different EVM chains have different block times (Gnosis ~5s, Sepolia ~12s). Auto-detection eliminates configuration errors.
2. Network upgrades: If the underlying blockchain changes its block time due to consensus upgrades, nodes adapt automatically without reconfiguration.
3. Testnet/mainnet parity: Developers can use the same configuration across environments with different block characteristics.
4. Reduced operator burden: One less parameter to configure and maintain across deployments.

Implementation

Approach:

When --blockchain-rpc-endpoint is provided and chain backend is enabled:

1. Calculate average block time by sampling recent blocks:

   currentBlock := backend.BlockNumber(ctx)
   pastBlock := currentBlock - 1000
   currentHeader := backend.HeaderByNumber(ctx, big.NewInt(currentBlock))
   pastHeader := backend.HeaderByNumber(ctx, big.NewInt(pastBlock))
   avgBlockTime := time.Duration((currentHeader.Time - pastHeader.Time) / 1000) * time.Second

2. Update strategy: Calculate once on startup and log the detected value. Optionally support periodic recalculation (configurable interval).
3. Fallback hierarchy:

• Auto-detected from RPC (priority)
• Manual --block-time flag (fallback/override)
• Default 5 seconds (last resort)

4. Preserve --block-time flag for:

• Ultra-Light nodes (without RPC endpoint)
• Manual override capability
• Backwards compatibility

Note: For ultra-light nodes (without RPC), verify if block-time is actually required.

Drawbacks

1. Additional RPC calls on startup: Requires 2 extra RPC calls (BlockNumber and HeaderByNumber) to calculate block time.
2. Network variability: Short-term network issues or anomalies could affect the calculation. Mitigated by using a large sample size (1000 blocks provides stable average over ~1.4 hours on Gnosis).
3. Breaking changes for misconfigured nodes: Nodes currently running with incorrect --block-time values would suddenly behave differently. Mitigation: log both detected and configured values, allow override via flag.
4. Complexity: Adds logic and state management for block time detection and updates, increasing code complexity slightly.

[gacevicljubisa]

The node already polls backend.BlockNumber() regularly for phase checks (see pkg/storageincentives/agent.go:188). We can cache block timestamps from these existing calls and calculate a rolling average, eliminating the need for dedicated RPC calls after initial startup. This makes block time detection essentially "free" by reusing data already fetched during normal operation.