interop: deposits #13
Conversation
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.
|
|
||
| ``` | ||
| require(identifier.timestamp + sequencer_window <= block.timestamp) | ||
| ``` |
There was a problem hiding this comment.
This requires either:
- standard sequencer window for all chains
- sequencer window of remote chains is legible to the derivation pipeline
| This creates a leaky abstraction as now the state transition function needs to know about | ||
| the dependency set, doing remote RPC calls during execution. This does not seem like | ||
| an ideal solution for that reason. | ||
|
|
There was a problem hiding this comment.
This would also impact p2p networking as the execution payloads are sent via p2p, would need to make sure to define semantics around signing the payload before/after the malleation
|
Some short term solutions for devnet-0:
|
| txs.append(tx) | ||
| break | ||
| ``` | ||
|
|
There was a problem hiding this comment.
This logic can be added to the derivation pipeline pretty easily here
|
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 |
|
Some follow up thoughts based on a conversation with @protolambda
|
|
|
||
| ## Derivation Pipeline Execution | ||
|
|
||
| The derivation pipeline is updated to include EVM execution of the deposit transactions. A forking EVM provider backed |
There was a problem hiding this comment.
We don't want to add execution to the derivation pipeline. We instead want to use a 2 step process that registers the dependency into the L2 state and then force deposits to use state that has been registered ahead of time. This means that there needs to be an "is deposit" introspection from within the EVM. This can be accomplished by having 2 system txs, the first on toggles on isDeposit() -> true and the second isDeposit() -> false. Ideally we make isDeposit only callable by the CrossL2Inbox so that arbitrary applications cannot use it to censor
|
Additional context on how we have been thinking about this problem can be found in ethereum-optimism/optimism#10867 (comment) |
|
This is being worked on in ethereum-optimism/specs#258 |
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.