Determine step size in Steel history commitments

[Wollac]

The Beacon roots contract in Ethereum stores the historical roots of the last 8191 slots. When building the chain of state_commits, we need to pinpoint the latest (or near-latest) block within each 8191 slot window. Simply incrementing the block number by 8191 works if no slots are missed, but this approach fails when slots are skipped. To guarantee accuracy, we need a more sophisticated mechanism to identify the correct block within the time window, accounting for potential missed slots.

[linear[bot]]

WEB3-201 Determine step size in Steel history commitments

[Wollac]

Possible Solution 1: Adaptive Block Increment

One approach is to assume a maximum percentage (x%) of missed blocks within an 8191 slot window. The block number increment would then be adjusted to 8191 * (1 - x).

Drawbacks:

• Inflexible: This method struggles to adapt to varying network conditions. On stable networks like Ethereum Mainnet, where missed blocks are rare, it unnecessarily shortens the step size, increasing proving costs. Conversely, on testnets or experimental chains with higher block miss rates, it may consistently fail to find the correct block.

[Wollac]

Possible Solution 2: Timestamp-based Lookup

If the block time is known (since this commitment pattern only works on Ethereum and not L2, it might be reasonable to always assume 12 seconds), we could determine the target block by calculating its timestamp: current_timestamp + (8191 * 12).

Drawbacks:

• RPC Limitations: Ethereum's standard JSON-RPC API doesn't offer a direct way to query blocks by timestamp. This would necessitate a binary search (or similar method) to find the block with the closest timestamp, potentially increasing load on RPC nodes and incurring higher costs.
• Block Time Variations: While Ethereum uses a 12-second block time, hardcoding this value could cause issues on testnets or forks with different block times. Adding block time to the chain configuration is not ideal, as this information is only relevant for history commitments and only on the host.

[Wollac]

Possible Solution 3: Beacon API

Leverage the Beacon API to directly query consensus blocks by slot number. This allows us to identify the last block within the 8191 slot window by iteratively decrementing the slot number until a valid block is found. The corresponding execution block can then be extracted from the returned consensus block's ExecutionPayload.

Drawbacks:

• Beacon Node Load: Repeatedly querying a Beacon API node, especially when potentially traversing numerous slots to find a valid block, can impose significant load and cost on the node. This is particularly concerning because the eth/v2/beacon/blocks/{block_id} API call (used to retrieve block data by slot) is typically one of the most expensive calls in the entire Beacon API. This could be exacerbated by concurrent requests or if multiple clients adopt this approach.