You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the dependency set is maintained on L1 as well as each L2. This adds complexity to the contracts as we need to make sure that each time a dependency is added to the dependency set, it is pushed into each L2 state. This allows the smart contracts to revert when trying to consume a message from a chain outside of the dependency set or when sending to a chain outside of the dependency set (ethereum-optimism/specs#460)
If we instead removed these onchain checks and moved the checks offchain into the proof/blockbuilder, it would remove the concept of needing to maintain this state in each L2. We would lose the ability to prevent sends to chains outside of the dependency set, but in return we would get a lot more onchain simplicity. The dependency set would live in a single place in the SuperchainConfig and it would not need to be pushed to each SystemConfig. We would be able to drop the idea of the SystemConfig and L1Block contracts knowing about the dependency set.
The text was updated successfully, but these errors were encountered:
zainbacchus
added a commit
to ethereum-optimism/docs
that referenced
this issue
Dec 19, 2024
Reverting #1171 due to ethereum-optimism/optimism#13457
Preventing sends to outside dependency set can be explored via app-layer solution eg onchain tokenlist
Right now the dependency set is maintained on L1 as well as each L2. This adds complexity to the contracts as we need to make sure that each time a dependency is added to the dependency set, it is pushed into each L2 state. This allows the smart contracts to revert when trying to consume a message from a chain outside of the dependency set or when sending to a chain outside of the dependency set (ethereum-optimism/specs#460)
If we instead removed these onchain checks and moved the checks offchain into the proof/blockbuilder, it would remove the concept of needing to maintain this state in each L2. We would lose the ability to prevent sends to chains outside of the dependency set, but in return we would get a lot more onchain simplicity. The dependency set would live in a single place in the
SuperchainConfig
and it would not need to be pushed to eachSystemConfig
. We would be able to drop the idea of theSystemConfig
andL1Block
contracts knowing about the dependency set.The text was updated successfully, but these errors were encountered: