Interop Timestamp Invariant - Intermittent Round-trip Denial

Nobody has claimed this yet.

## Overview

The current [Interop Messaging Spec's timestamp invariant](https://specs.optimism.io/interop/messaging.html#timestamp-invariant) states that:

> The timestamp at the time of inclusion of the initiating message MUST be less than or equal to the timestamp of the executing message as well as greater than or equal to the Interop Start Timestamp.

When the dependency set of the superchain contains chains with varying block times, this can create interesting situations where, within _some_ superchain snapshots (but not all,) round-trips between chains are not allowed.

### Superchain STF

The superchain STF is defined as the transition from one `SuperRoot` to the next `SuperRoot`, every one second. In this transition, chains within the dependency set may or may not have actually progressed, depending on their blocktime.


### Example Case

For this example, let's consider there's two chains in the dependency set
* Chain A (1s blocktime)
* Chain B (2s blocktime)

At `t: 3`, for example, Chain A's block timestamp in the superchain snapshot would be `3`, but Chain B's would be `2`. This means that with the current timestamp invariant (`initiating message timestamp MUST be <= executing message timestamp`), an actor would not be allowed to relay an initiating message from Chain A block # 3 within Chain B's block # 1. However, in the very next superchain snapshot @ `t: 4`, the timestamps of the blocks within the snapshot will have equivocated, and round-trip messages will once again be allowed.

This can create a non-trivial challenge for relaying applications in a post-interop world, where landing intra-block message bundles across multiple chains becomes a more difficult task (requiring targeting specific superchain snapshots, and growing in complexity with the more varied block times in the dependency set.) In the eyes of a user, sometimes their bundles will fail, and sometimes they will succeed.

### Suggestion

To allow for round-trip messaging within any superchain snapshot, we should find a way to lift the timestamp invariant into a non-local check. A possible route is changing the invariant to:

> The timestamp at the time of inclusion of the initiating message MUST be less than or equal to the largest timestamp observed within the superchain snapshot as well as greater than or equal to the Interop Start Timestamp.

But this has some downsides, requiring more data to be fed into the verification function for individual message ends. Open to discussion in this issue on other methods to loosen this check.

Start with the Interop Messaging Spec's timestamp invariant and review the Superchain STF and two-chain example in this issue. The issue proposes loosening the invariant but leaves the method open; completion would require an agreed approach, defined verification implications, and an updated specification.

Written by the indexing model from the issue text.