interop: cross L2 inbox #8258
interop: cross L2 inbox #8258
Conversation
| return SUPERCHAIN_POSTIE; | ||
| } | ||
|
|
||
| /// @notice The inbox receives mail from the postie. |
There was a problem hiding this comment.
There was a problem hiding this comment.
Do we want to make the calldata structure more complex, by grouping output-roots of the same chain ID? There's no place to share a local intermediate storage key. It should be a single SSTORE either way. There's a double lookup to two related but different calldata struct fields, but there's nothing to share their either. I'm down to optimize this function with assembly and other tricks later FTW, but we're only in the prototype stage.
There was a problem hiding this comment.
Also, depending on the design, we might be able to include output-roots without their chain ID, by including the chain-identity in the output-root pre-image itself.
There was a problem hiding this comment.
Got it. Was just commenting on the declaring a local storage mapping when doing the nested accesses to save some hashing. I thought it was a cool pattern to share
There was a problem hiding this comment.
Putting the chain identity in the output does seem like an interesting idea but unclear what UX implications that would have. Ideally there is p2p network for serving output root preimages
| require(msg.sender == SUPERCHAIN_POSTIE, "CrossL2Inbox: only postie can deliver mail"); | ||
| for (uint256 i = 0; i < mail.length; i++) { | ||
| roots[mail[i].chain][mail[i].output] = true; | ||
| } |
There was a problem hiding this comment.
Maybe? It increases cross-L2 bridging cost, but it may make UX better. Currently we don't depend on receipts for this. Will ignore in prototype, it's rather easy to add later.
There was a problem hiding this comment.
Ok, for indexers having the event is ideal until shadow events are the norm
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #8258 +/- ##
===========================================
+ Coverage 34.69% 34.73% +0.03%
===========================================
Files 167 168 +1
Lines 7136 7140 +4
Branches 1205 1206 +1
===========================================
+ Hits 2476 2480 +4
Misses 4509 4509
Partials 151 151
Flags with carried forward coverage won't be shown. Click here to find out more.
|
protolambda
force-pushed
the
interop-cross-l2-inbox
branch
from
c7b5341
to
abd0628
Compare
|
|
||
| /// @notice The collection of output roots, by chain. | ||
| /// chain ID => output root => bool. | ||
| mapping(bytes32 => mapping(bytes32 => bool)) public roots; |
There was a problem hiding this comment.
Why is chainid a bytes32 instead of a uint?
There was a problem hiding this comment.
From a UX perspective it'll be easier to represent as an integer instead of a hex value
There was a problem hiding this comment.
We're thinking of versioning and formatting the chain identifiers in a way that's more forward compatible if we ever have to deal with new source/destination types, or conflicting chains.
|
Marking as draft / do-not-merge, this is blocked by interop design decisions, this might not be the right approach to do the bridging. |
protolambda
force-pushed
the
interop-deploy-config
branch
2 times, most recently
from
0c89106
to
dee66db
Compare
protolambda
force-pushed
the
interop-cross-l2-inbox
branch
from
abd0628
to
f5a6148
Compare
protolambda
force-pushed
the
interop-cross-l2-inbox
branch
from
f5a6148
to
48c24b1
Compare
Description
Draft of interop
CrossL2Inboxcontract, integrated into deploy-config, inserted into L2 genesis as predeploy if interop is active at genesis.For the prototype, we simply update the inbox with a configurable EOA. In the next iteration we can swap this out with a system-derived message, that the node validates with subjective safety (i.e. check the output-root of the other L2 chain by running a full node of said chain, or through alternative light-client backed mechanism).
Depends on #8256
Tests
Metadata
Fix https://github.com/ethereum-optimism/interop/issues/21