// This post outlines the key changes made to the Standard Rollup Charter since the v0.1 draft’s introduction earlier this year. For an introductory post explaining how Blockspace Charters work, please see this post. The updated version of the Standard Rollup Charter proposal can be found here.
Since the Optimism Foundation introduced the first draft of the Standard Rollup Charter earlier this year, we have had the pleasure of iterating based on conversations with Chain Governors, real-world testing via the Superchain Registry Beta, and overall feedback from the broader community. As we seek ratification of this Charter, we wanted to provide a standalone post to outline two of the key changes made since introduction, and provide more color on their motivations than would be appropriate in the charter itself. These two changes are:
- Introduction of temporary control structures: the ability for a limited set of chains to be included as a signer on a 3/3 upgrade multisig for their chain. This measure aims to mitigate the risks posed by malicious Chain Governors while allowing for confident, incremental adoption of Optimism Governance.
- Moving history integrity checks to offchain tooling: in operating the Superchain Registry Beta, the Optimism Foundation uncovered significant operational overhead in programmatically identifying all historic discrepancies between legacy chains. As a result, history integrity checks have been moved to offchain tooling, to ensure a better balance between Superchain inclusivity and security.
Let’s dive into both in more detail!
Intermediate Control Structures
A small set of Chain Governors have expressed a strong desire for the ability to retain a blocking right over Protocol Upgrades for their specific chain, to prevent against governance or Security Council capture. This is a valid, but nuanced, request.
On one hand, Optimism Governance is still evolving, and we feel that it is reasonable for chain governors entrusting the Collective to upgrade chains with large amounts of value to request some form of oversight as governance continues to mature.
On the other hand, affording Chain Governors blocking rights over protocol upgrades for their specific chain poses meaningful risk. The Optimism Collective’s most crucial responsibility is to uphold the Law of Chains and its Protections when performing upgrades on behalf of its stakeholders. A malicious Chain Governor with a blocking right over protocol upgrades could, among other things:
- Block emergency security upgrades for their chain, resulting in loss of assets and violating the User Protection of state transition and messaging validity.
- Block regularly scheduled Protocol Upgrades for their chain, breaking blockspace homogeneity and violating the User Protection of Universal, Governance-approved Upgrades.
As such, this updated draft of the Standard Rollup Charter includes a temporary solution intended to balance this tradeoff. In particular:
- A limited number of Chain Governors may be approved by Optimism Governance to have their upgrade keys held in an interim 3/3 multisig consisting of: (1) the Optimism Security Council, (2) the Optimism Foundation, and (3) the Chain Governor.
- These chains must be proposed by the Optimism Foundation via a Protocol Upgrade, and are subject to governance approval via the existing Protocol Upgrade Process.
The initial chains, which would be subject to approval by ratification of the initial Standard Rollup Charter, are twofold: Base, and Unichain.
We believe that this solution strikes a fair balance between empowering Optimism Governance and limiting the downside of malicious Chain Governors, while preserving the ability for key contributors to confidently and incrementally adopt Optimism Governance.
Offchain History Integrity Checks
The introduction of this Charter represents a transitional moment for the Superchain, and for the Collective; a unification of chains which were deployed before the existence of Blockspace Charters or the Standard Rollup. As a result, it is important to consider not just the current version and configuration, but also the historic state of a chain which was deployed in the past. Historic chain management decisions can theoretically introduce future security vulnerabilities, even if the chain passes all of the “present-day” checks listed above.
To date, there have been a number of observed discrepancies between different chains which were previously launched, including:
- Deployment of intermediate versions: some chains were launched via intermediate commits of the OP Stack (i.e. commits “in-between” two governance-approved releases)
- Temporary bugfixes, patches, and maintenance: some Chain Governors and Servicers have performed manual maintenance for purposes of security or quality-of-life, which caused short-lived deviations in their history.
- Inconsistent fork activation heights: some chains have activated forks at different times in their history.
- Predeploy inconsistency: some chains are missing certain predeployed contracts (e.g. the EAS) or have differing predeploy contracts (e.g. certain fee faults)
These discrepancies may largely be reasonable, since they stem from actions taken before the clarity and specificity presented in this document. However, they vary in nature, and it is infeasible to capture them all through a constrained set of deterministic validation checks to prove that they are “safe.”
As such, the Optimism Foundation has implemented a suite of history integrity checks, which can be used to identify historical discrepancies between chains and manually assess their impact. The Optimism Foundation will assess these discrepancies on an as-needed basis. If it believes that these discrepancies risk violating the Law of Chains (e.g., User Protections) in the future once the chain is added as a Standard Rollup, it will deny the chain’s inclusion, even if all other criteria in this document are met.
The importance of history integrity checks should quickly diminish over time towards deprecation, since the expectation is that all Standard Rollups launched after the ratification of this Charter are deployed correctly at launch.