Open Wollac opened 2 days ago
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:
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:
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:
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.
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.