Edge Cases

Handling Edge Cases

Blocks with Identical Timestamps

Certain chains, like Arbitrum, can produce multiple blocks with identical timestamps. This is due to their rapid block creation every 300ms and the use of UNIX timestamps in block headers, which are accurate only to the second. For instance, a sequence of Arbitrum block timestamps could look like:

119723839 → 1691589677
119723838 → 1691589676
...
119723834 → 1691589675

Problem

When querying for a timestamp, say 1691589676, the data structure will yield the most recent block with that timestamp (119723838). This introduces potential logic errors since there are other blocks matching the same criteria.

Solution

To address this, anyone trying to validate a query result should furnish inclusion proofs for all elements in the remapped MMR that precede the binary search result. This continues until a block with a differing timestamp appears. Thus, for our example with 1691589676, the binary search might yield 119723838, but we'd also need to consider:

119723837
119723836
119723835
119723834

Optimization

For efficiency, adjust the constraints to:

Supply the first block in the MMR with a result preceding the binary search outcome and the succeeding block.

Hence, using our previous example, the binary search returns 119723838, but the additional blocks are:

119723834
119723835

Using this method, we bypass verifying two more proofs and logically deduce that all blocks between 119723835 and 119723838 share the timestamp.

Special Consideration

In the rare scenario where no prior block has a distinct timestamp (like the very first block), the entire range of matching blocks (having the same timestamp) should be provided, inclusive of their inclusion proofs.