The core security property that an invalid cross chain transaction will never finalize is difficult to guarantee when there is a single point of failure. Right now, the sequencer is responsible for not creating blocks that include invalid cross chain transactions. We can eliminate the single source of failure here by having two distinct ways to check the validity of a cross chain transaction before it is included in the block. We still have a single source of failure with regards to the op-supervisor and op-node for full nodes that are responsible for reorging out blocks that do contain invalid cross chain transactions. We believe this risk can only be truly mitigated with a second implementation of op-supervisor and op-node. Without these second implementations, a bug can become consensus, potentially without being detected. The worst case for this could result in ether being minted out of thin air by forging a valid cross chain transaction that mints ether.

The following documents give some additional context around this:

• design doc: interop monitoring #222
• Interop Topology

Possible action items that could come from the review:

• Implement a "cheap" second implementation of a subset of the supervisor by having a dynamic backend that fetches data from eth_getLogs rather than using its local database to look things up. This wouldn't work for finalization, but could work for filtering and add redundancy around not letting invalid executing messages arrive into blocks
• Implement an airgap for ETH, see Airgapped Cross Chain Ether specs#643
• Implement cross chain message throttling, see [Tracker] Cross Domain Message Throttling optimism#10868
• Begin implementation on a second implementation