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
As of today, we have stopped using the ProtocolVersions contract due to it being too much of an overhead to keep up to date. It could be worth simplifying the way that it is used and integrating into OPCM, to guarantee safety over liveness universally (ie prevent syncing the wrong chain with outdated client software)
Think of the ProtocolVersions.required field as being a synchronization between the L1 contracts and the client software. OPCM would call ProtocolVersions and be able to modify the required field.
One possible way to manage the versioning: if the L2 client software absolutely will not work with the L1 contracts, we should bump the major version. We could bump the minor/patch versions on other upgrades where the client software doesn't absolutely need to be updated. The L2 client software would have a max known major version and compare it against what is onchain and halt if the onchain version is greater than the known version.
We could delete/simplify parts of ProtocolVersions so that it exactly fits the usecase of universally guaranteeing safety over liveness. With this universal guarantee, then we no longer need to make decisions like the derivation pipeline halting on unknown ConfigUpdate event types, it could just ignore them. This will help to decouple the ability to upgrade L1 contracts and L2 client software independently, with an explicit onchain synchronization mechanism.
The text was updated successfully, but these errors were encountered:
As of today, we have stopped using the
ProtocolVersions
contract due to it being too much of an overhead to keep up to date. It could be worth simplifying the way that it is used and integrating into OPCM, to guarantee safety over liveness universally (ie prevent syncing the wrong chain with outdated client software)Think of the
ProtocolVersions.required
field as being a synchronization between the L1 contracts and the client software. OPCM would callProtocolVersions
and be able to modify therequired
field.One possible way to manage the versioning: if the L2 client software absolutely will not work with the L1 contracts, we should bump the major version. We could bump the minor/patch versions on other upgrades where the client software doesn't absolutely need to be updated. The L2 client software would have a max known major version and compare it against what is onchain and halt if the onchain version is greater than the known version.
We could delete/simplify parts of
ProtocolVersions
so that it exactly fits the usecase of universally guaranteeing safety over liveness. With this universal guarantee, then we no longer need to make decisions like the derivation pipeline halting on unknownConfigUpdate
event types, it could just ignore them. This will help to decouple the ability to upgrade L1 contracts and L2 client software independently, with an explicit onchain synchronization mechanism.The text was updated successfully, but these errors were encountered: