feat: sequencer-enforced invariants

[sam-iamm]

Description

This is design doc to enable sequencers to enforce invariants on OP Stack chains related to inclusion and ordering.

[tynes]

We (Firewall) are building the Safe Sequencer for OP Stack chains. Safe sequencing uses exploit detection during block construction to exclude transactions from blocks that are identified as smart contract exploits. However, forced L1 → L2 messages can bypass the exploit detection of a safe sequencer and force include an exploit into a block.

This sort of logic should not live on chain. This sort of product could exist off chain as part of the block builder behind a PBS API as proposed in https://github.com/ethereum-optimism/specs/pull/116. Chain operators that want to opt into block builders that use exploit detection can opt into it.

I see that you are trying to handle the deposits not being able to be censored as part of block building, but the complexity introduced by the implementation is very high. Not sure what the best solution to handle deposits is and if it makes sense as something we would want to include in the OP Stack long term as it basically introduces a way to censor arbitrary deposits.

[tynes]

If you can come up with a much more simple interface rather than adding logic into the bridge itself, it would be more palatable. It also adds uncertainty around what an exploit is, because its not objectively clear what that means. What is perfectly fine usage to one person is an exploit to another person.

[tynes]

Can you build such a product on top of https://github.com/ethereum-optimism/specs/pull/27? This would be more aligned with the interfaces that we have been thinking about adding to the OP Stack

[sam-iamm]

We (Firewall) are building the Safe Sequencer for OP Stack chains. Safe sequencing uses exploit detection during block construction to exclude transactions from blocks that are identified as smart contract exploits. However, forced L1 → L2 messages can bypass the exploit detection of a safe sequencer and force include an exploit into a block.

This sort of logic should not live on chain. This sort of product could exist off chain as part of the block builder behind a PBS API as proposed in ethereum-optimism/specs#116. Chain operators that want to opt into block builders that use exploit detection can opt into it.

I see that you are trying to handle the deposits not being able to be censored as part of block building, but the complexity introduced by the implementation is very high. Not sure what the best solution to handle deposits is and if it makes sense as something we would want to include in the OP Stack long term as it basically introduces a way to censor arbitrary deposits.

Yes the product exists offchain and we are trying to handle the deposits problem because they can break any invariants enforced by the block builder. Appreciate your feedback a lot. Re complexity, I definitely see your concern. The reference implementation ended up being more complex than we had anticipated.

[tynes]

This sort of feature needs to be very user research driven. Are chain operators asking for this?

It also jeopardizes the ability to be a stage 1 rollup by allowing arbitrary censorship of deposits. The OP Stack is meant to commoditize stage 2 rollups when the multiproof is ready for production

[sam-iamm]

If you can come up with a much more simple interface rather than adding logic into the bridge itself, it would be more palatable. It also adds uncertainty around what an exploit is, because its not objectively clear what that means. What is perfectly fine usage to one person is an exploit to another person.

Will dive into the resource you linked below and look for an alternative, simpler interface.

Re exploit classification, ideally the interface doesn't embed any assumptions about what is an exploit and that is handled by an operator or algorithm chosen by the rollup.

[iamoptmstc]

This sort of feature needs to be very user research driven. Are chain operators asking for this?

It also jeopardizes the ability to be a stage 1 rollup by allowing arbitrary censorship of deposits. The OP Stack is meant to commoditize stage 2 rollups when the multiproof is ready for production

Yes, there’s been two core reasons:

• (1) differentiation and enhancement of block-space - rollups are commoditized from a user POV, relative to each other they’re all cheap and fast

• (2) attraction of new liquidity - large capital allocators (whales, crypto funds, and eventually tradfi) can’t deploy capital today because of the smart contract risk. Chain operators are aware that if you mitigate that, your rollup becomes attractive to a new magnitude of assets — this is the core main driver for chain operator demand for this

We’ve seen strong demand from rollups for exploit detection at the sequencer-level (e.g. Concrete, Volmex, and Mezzanine. Zircuit is another proof-point, their unique differentiator is sequencer-level security and they have attracted $3.38B TVL within a few months. Zircuit uses a design similar to the “forced no-op deposits by the sequencer”, one of the alternative solutions summarized in the doc.

[sam-iamm]

This sort of feature needs to be very user research driven. Are chain operators asking for this?

It also jeopardizes the ability to be a stage 1 rollup by allowing arbitrary censorship of deposits. The OP Stack is meant to commoditize stage 2 rollups when the multiproof is ready for production

There are definitely some designs we’ll explore further that do not involve as much (or any) modification to the OptimismPortal and CrossDomainMessengers. Thanks for sharing this spec as well.

Overall, this doc suggests a separation of concerns that allows a rollup to delegate inclusion and ordering invariants to the sequencer because it offers more flexibility. It lets a rollup easily add or remove sequencer-enforced invariants (in our case, ML detection algorithms) through the system config which enables it to enforce “good” censorship, invariants can be upgraded without upgrading the rollup itself, and there’s a clean separation of concerns for the rollup (e.g. invariant compute isn’t in the rollups FPP).

I think the core question for your feedback to keep in mind as we explore design trade-offs is: do we want the separation of concerns, or do we want to put all inclusion invariants (and their associated compute) within the derivation and execution client of a rollup’s full node and FPP?

[tynes]

Due to the nature of smart contract composability there isn't a great way to introspect in all cases to catch anomalies. Another approach was explored in https://github.com/ethereum-optimism/op-geth/pull/256. With deposits, the only tool is static analysis, meaning that deposits must be locked into a covenant system.

You should check with L2Beat with your design and get buy in that such a design would still allow for a stage 2 rollup. The control structures around who can set the filter and the frequency at which it can be updated here is important.

[tynes]

Closing this as we are not interested in censorship and this adds too much risk to being a stage 1+ rollup