feat: sequencer-trusting Following Mode

[clabby]

Overview

Introduces a new mode for the rollup node post-interop, where cross-safe promotion is delegated to the sequencer. In this mode, no supervisor needs to be consulted, and the operator trusts an attestation from the sequencer that message validity has been checked.

Goal

Offer a mode of operation for the rollup node that simplifies operation by removing the need for a supervisor in the equation entirely. Achieve this by placing a trust assumption on the sequencer to ensure validity of cross-chain messages.

The outcome of this mode's introduction should be such that a rollup node operator can run a verifier node for a single chain entirely independently as they do today, albeit with an additional trust assumption placed on the sequencer.

[clabby]

Given that we want to actually check that the rollup node derived the initial attributes for the block as local-safe prior to promoting the cross-safe head, we might hold onto a relatively large in-memory buffer of local safe blocks as we wait for gossip.

Of course I don't have benchmarks for this, but if the sequencer fails to gossip cross-safety promotions for a certain period of time, the rollup node would wind up holding onto a very large queue if it wants to add that extra layer of security that this doc notes.

Of course, an alternative design here would be to just completely trust the sequencer, and turn off derivation, but I think that's kind of wack.

[axelKingsley]

Sequencers do not have any special authority to deem a block "Cross Valid" because they do not have any special knowledge of other chains. An attestation network could be a good way to promote blocks which are Cross Valid, but there is no particular value to trusting a Sequencer here.

Even once a Sequencer could deem the block they created as Cross-Valid, that attestation may be invalidated by any other Sequencer in the set, simply by equivocating the Unsafe Blocks that are being depended upon.

Counter-thought: why shouldn't we allow the Sequencer to publish "Follow Safe" blocks, so that nodes don't need to do L1 derivation in the first place? (I do not actually like this idea, just posing it as comparable-art)

[clabby]

Sequencers do not have any special authority to deem a block "Cross Valid" because they do not have any special knowledge of other chains. An attestation network could be a good way to promote blocks which are Cross Valid, but there is no particular value to trusting a Sequencer here.

Even once a Sequencer could deem the block they created as Cross-Valid, that attestation may be invalidated by any other Sequencer in the set, simply by equivocating the Unsafe Blocks that are being depended upon.

Counter-thought: why shouldn't we allow the Sequencer to publish "Follow Safe" blocks, so that nodes don't need to do L1 derivation in the first place? (I do not actually like this idea, just posing it as comparable-art)

Thanks for review!

The sequencer doesn't have any special authority to deem a block cross-valid, but it does know of one + listen to it. It can attest to the fact that it's listened to <insert some black-box authority that isn't the sequencer> to promote its own cross safe head. It can then use its signing key to attest to the fact that it observed said <insert some black-box authority that isn't the sequencer>'s verdict.

There's definitely a conversation to be had about whether or not this should actually be within the realm of the sequencer's role; We could always introduce a completely separate role to do this job, not overloading what we consider to be the sequencer today.

The design doc reuses this role as is primarily to maintain simplicity. Already, this key is available within the rollup node implementations where we need it to be, and as-is, we'd be able to implement this fairly easily without much plumbing at all.

[ajsutton]

My thinking on this is more that people like RPC providers could run a small number of "complete" nodes that have op-supervisor and full op-mainnet and unichain-mainnet op-node/op-geth instances and then configure as many other rpc serving nodes as they need to run in following mode and trust the gossip from their own op-supervisor nodes.

That minimises the changes to their architecture, allows them to still decide what level of reliability they want for safe head signals (number of complete nodes) and continue scaling the rpc serving nodes for specific chains as needed without worrying about how to actually hook them to a supervisor at all. One important detail though is how to handle gossip that's only intended for nodes in your own fleet and not spam the whole gossip network with it. Maybe that complexity makes it not worth it....

It's possibly useful for the sequencer to publish this gossip as well for people like home users that want valid blocks but trust the cross-chain checks but that is a somewhat weird trust model.