interop: deposits

[tynes]

Description

This design doc is meant to explain how we can safely support deposit transactions that trigger executing messages. It adds a new stage to the derivation pipeline as well as a new invariant. It modifies the way that deposit events are mapped into deposit transactions to guarantee integrity of deposited executing messages.

[tynes]

Some short term solutions for devnet-0:

• do nothing, permission deposits that have calldata
  • this will not work because contracts on L2 can have fallback functions that create executing messages
• do nothing, allow for deposits to cause reorgs
  • this can only work if we use a private L1
• make diff in state transition function as a quick hack
  • this is the option we should pursue

[tynes]

This design would result in the requirement of archival state for historical sync. We don't want to impose that, h/t @protolambda

Thinking more on how to solve this

[tynes]

Some follow up thoughts based on a conversation with @protolambda

• It may be possible that we can encode information in the block body using EIP-7685 to remove the need for historical execution. EIP-7685 is being included in Pectra
• Another design space is around having "is deposit" introspection in the EVM
  • The simple approach would be to modify the STF to set state in a predeploy before execution so that when called, it can return a bool
  • Another approach involves adding a second system deposit transaction at the tail end of the deposits. This would store something in state that indicates that there are no more deposits, so its possible to differentiate between deposits and not
• The "is deposit" introspection could be tied to a "delayed inclusion system" where if its a deposit that is triggering a cross chain message, the codepath would be different and it would result in a follow up where the deposit is "finalized"
• Another design space would involve providing a proof if its a deposit, this proof would be done against some global accumulator that is updated slowly

[tynes]

Additional context on how we have been thinking about this problem can be found in https://github.com/ethereum-optimism/optimism/issues/10867#issuecomment-2183111697

[tynes]

This is being worked on in https://github.com/ethereum-optimism/specs/pull/258