|
| 1 | +# [interop]: Following Mode |
| 2 | + |
| 3 | +| | | |
| 4 | +| ------------------ | -------------------------------------------------- | |
| 5 | +| Author | _@clabby_ | |
| 6 | +| Created at | _2025-06-24_ | |
| 7 | +| Initial Reviewers | _Protolambda, Adrian Sutton_ | |
| 8 | +| Need Approval From | _Mark Tyneway_ | |
| 9 | +| Status | _Draft / In Review / Implementing Actions / Final_ | |
| 10 | + |
| 11 | +## Purpose |
| 12 | + |
| 13 | +The purpose of this design doc is to specify a potential new "mode" for the [rollup node][rollup-node] to operate in a |
| 14 | +post-interop world, that alleviates the need to reach out to an `op-supervisor` to determine [cross-safety][cross-safe]. |
| 15 | + |
| 16 | +## Summary |
| 17 | + |
| 18 | +This design doc introduces an alternative design for "following mode," where a [rollup node][rollup-node] operator |
| 19 | +trusts a sequencer's determination of |
| 20 | +[message validity](https://specs.optimism.io/interop/messaging.html#invalid-messages) in order to advance its |
| 21 | +[`cross-safe`][cross-safe] chain. |
| 22 | + |
| 23 | +## Problem Statement + Context |
| 24 | + |
| 25 | +For the vast majority of [Rollup Node][rollup-node] operators, operating a [supervisor][supervisor] is costly and |
| 26 | +undesirable. The benefit of operating one's own [supervisor][supervisor] is primarily to _ensure_ that the messages |
| 27 | +included in blocks by the sequencer are indeed valid. While this is a necessary step to _ensure_ an L2 chain's integrity |
| 28 | +post-interop, there are valid user stories that don't involve the costly validation of message validity, beyond trusting |
| 29 | +an _attestation_ from the sequencer that it has already been done. |
| 30 | + |
| 31 | +For operators that are willing to trust the sequencer's attestations, an alternative mode can be introduced which |
| 32 | +bypasses the need for a [rollup node][rollup-node] to directly consult a [supervisor][supervisor] when determining |
| 33 | +[cross-safety][cross-safe]. |
| 34 | + |
| 35 | +## Proposed Solution |
| 36 | + |
| 37 | +"Following Mode," at a high level, consists of [rollup nodes][rollup-node] subscribing to a new gossip topic that |
| 38 | +receives _signed [`cross-safe`][cross-safe] blocks_. |
| 39 | + |
| 40 | +1. When the sequencing node consults with its own [supervisor][supervisor] and determines that a block can be promoted |
| 41 | +to [`cross-safe`][cross-safe], it will sign the payload hash of the new [cross-safe][cross-safe] block as specified in |
| 42 | +["Rollup Node P2P"](https://specs.optimism.io/protocol/rollup-node-p2p.html#block-signatures) and gossip it to peers |
| 43 | +over the [`cross-safe-blocksv1` topic](#new-gossip-topic). |
| 44 | +1. Peers observing the topic that are operating in "Following Mode" will then validate the block as specified in |
| 45 | +["Rollup Node P2P"](https://specs.optimism.io/protocol/rollup-node-p2p.html#block-validation), and if validation succeeds: |
| 46 | + 1. Check that the block has been derived as `local-safe`. If not, ignore the block. |
| 47 | + 1. Perform [L1 consolidation](https://specs.optimism.io/protocol/derivation.html#l1-consolidation-payload-attributes-matching) |
| 48 | + on the derived attributes, relative to the received block. |
| 49 | + 1. If L1 consolidation fails, reduce the `transactions` array in the derived attributes to only deposits |
| 50 | + following the [interop block replacement rules](https://specs.optimism.io/interop/derivation.html#replacing-invalid-blocks) |
| 51 | + , and try again. |
| 52 | + 1. If finally, L1 consolidation fails after reducing the attributes to deposits-only, discard the block. |
| 53 | + |
| 54 | +### New Gossip Topic |
| 55 | + |
| 56 | +The new gossip topic that is introduced is `cross-safe-blocksv1`, broadcasted on |
| 57 | +`/optimism/<chainId>/0/cross-safe-blocks`. Block encoding for the `cross-safe-blocksv1` topic is as specified within |
| 58 | +["Rollup Node P2P - blocksv4"](https://specs.optimism.io/protocol/rollup-node-p2p.html#block-encoding). |
| 59 | + |
| 60 | +Peers that broadcast invalid blocks on this topic, per the block validity rules mentioned above, should be downscored |
| 61 | +to mitigate possible DoS. |
| 62 | + |
| 63 | +### Resource Usage |
| 64 | + |
| 65 | +Resource utilization for this new mode should be minimal. A new gossip topic will need to be subscribed to among |
| 66 | +rollup node participants operating as a sequencer or in "Following Mode," and the sequencer will need to both sign |
| 67 | +and broadcast blocks as it promotes them to [`cross-safe`][cross-safe]. |
| 68 | + |
| 69 | +### Single Point of Failure and Multi Client Considerations |
| 70 | + |
| 71 | +This change affects only the [rollup node][rollup-node], and will need to be implemented in both |
| 72 | +[`op-node`](https://github.com/ethereum-optimism/optimism/tree/develop/op-node) and |
| 73 | +[`kona-node`](https://github.com/op-rs/kona). It is invisible to the execution layer. |
| 74 | + |
| 75 | +## Failure Mode Analysis |
| 76 | + |
| 77 | +<!-- Link to the failure mode analysis document, created from the fma-template.md file. --> |
| 78 | + |
| 79 | +## Impact on Developer Experience |
| 80 | + |
| 81 | +n/a - change affects node operators. |
| 82 | + |
| 83 | +## Alternatives Considered |
| 84 | + |
| 85 | +_TODO_ |
| 86 | + |
| 87 | +## Risks & Uncertainties |
| 88 | + |
| 89 | +_TODO_ |
| 90 | + |
| 91 | +[cross-safe]: https://specs.optimism.io/interop/verifier.html#safe-inputs |
| 92 | +[supervisor]: https://specs.optimism.io/interop/supervisor.html#supervisor |
| 93 | +[rollup-node]: https://specs.optimism.io/protocol/rollup-node.html |
0 commit comments