Season 6: Standard Rollup Charter Ratification

Season 6: Standard Rollup Charter


// This draft will be ratified by the Token House in Voting Cycle #29. For more context on the Blockspace Charter Framework, see here.

Introduction

The Standard Rollup is the Optimism Collective’s flagship, high-security blockspace product. The Standard Rollup targets the Collective’s highest bar for security, uptime, and decentralization.

This Charter applies the principles of the Law of Chains to the specific context of Standard Rollups, and does not modify or supersede the Law of Chains in any way. All conflicts between this Charter and the provisions of Law of Chains will be resolved in favor of the Law of Chains.

Optimism Governance is responsible for upholding the standards and policies outlined in this Charter and ensuring their consistency with the Law of Chains. All potential changes to the Standard Rollup should be treated with careful consideration by the governance community, to enable long-term, sustainable ecosystems to be built around Standard Rollup blockspace with confidence.

Criteria

The criteria for being a Standard Rollup consist of:

  • A set of deterministic onchain criteria to ensure that chains are well-configured, on an up-to-date version, and have authorized the Optimism Security Council to perform upgrades.
  • A set of lightweight, offchain criteria checked by the Optimism Foundation, which are expected to carry on until they are ready to be safely transitioned to Optimism Governance.
  • Completion of a “history integrity check” by the Optimism Foundation, which is expected to be deprecated in the future (as chains deploy directly as Standard Rollups from day 1).

Onchain Criteria

The onchain criteria for Standard Rollups consist of two components: a version check and a configuration check.

Version Validation

The most important onchain criteria is that a chain be on a standard, governance-approved release of the OP Stack. This check is performed by comparing all bytecode for the chain’s L1 smart contracts to the standard bytecode corresponding to a governance-approved release of the OP Stack.

Version validation is a strict, critical requirement. To securely hand over upgradability to the Collective, a chain’s L1 smart contracts must match the release tags defined by this TOML file in the Superchain Registry. At the time of writing, this corresponds to op-contracts@v1.6.0.

For those interested, the code currently used in the Superchain Registry to perform version (and configuration) checks can be found here. The Optimism Foundation may, from time to time, update this code (e.g. for quality-of-life improvements or other refactors), so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.

Configuration Check

Beyond being on a standard version of the OP Stack, all configuration values for the chain must be within high-security, well-tested bounds, and all administrative roles must be set correctly. There are two main components:

  • Parameter Configuration: A set of requirements for the “protocol parameters” of a chain — things like block time, gas metering, and other low-level variables — to either equal a certain value, or fall within a specified range. The specific requirements can be found here.
  • Role Configuration: A set of requirements for the privileged administrative roles for the chain. The specific requirements can be found here. Primarily, these checks involve ensuring that the Security Council holds authorization to perform upgrades, and other minor Stage 1 requirements (see here).

A more human-readable breakdown of these requirements, including supporting rationale choices, can be found in the configurability page of the OP Stack docs. However, the ultimate source of truth for configuration requirements are the two TOML files linked above, as modified from time to time by Optimism Governance.

The Optimism Foundation may, from time to time, update the validation code used in the Superchain Registry to perform these checks, so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.

Role Configuration Exceptions

Certain chains’ L1ProxyAdmin role shall satisfy the Standard Rollup Criteria, without the default address 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A, so long as that role is a 3/3 gnosis SAFE between the Chain Governor, Optimism Foundation, and Security Council. These chains are:

  1. Base
  2. Unichain

These Chain Governors have publicly committed to using their upgrade key consistent with the “Normal Operation” and “Emergency Response” sections of the Security Council Charter.

While not currently anticipated, the Optimism Foundation may propose expansions of this list from time to time, subject to governance approval via the Protocol Upgrade process.

Offchain Criteria

In addition to the above deterministic criteria, the Optimism Foundation may perform a limited set of manual, offchain checks at its discretion before inclusion as a Standard Rollup. These checks include:

  1. ChainID check: ensuring that the Chain ID is unique and does not collide with a pre-existing EVM chain.
  2. Gas Limit check: ensuring that the Chain’s initial GasLimit is configured to a reasonable value based on the then-current status of OP Stack performance testing. (See below for additional context on Gas Limit policy.)
  3. Security Monitoring: ensuring certain standard monitoring tools have been deployed for every chain.
  4. Governor/Servicer verification: verifying at the social layer that the chain is indeed deployed and operated by the parties in question, and are not being impersonated.
  5. Other checks: running other checks (e.g. compliance-related checks) as deemed appropriate.

Given the fundamentally subjective nature of these checks, they are expected to be administered by the Foundation until they can be safely transitioned to Governance.

History Integrity Checks

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.

For more information on the motivation for history integrity checks, see this post.

Note on Superchain Registry

The "promotion” of a chain (i.e. setting its superchain_level to 1) in the superchain-registry repo will be the canonical indicator of passing the offchain criteria and history integrity checks. Thus, the community can determine whether a given chain falls under the scope of this Charter by checking that:

  • The Chain passes all Onchain Criteria checks
  • The Chain has been included by the Foundation in the superchain-registry repo.

Even after history integrity checks are deprecated, it should be expected that the Foundation’s subjective checks are also either eliminated, or transitioned to a process run directly by the community, so that inclusion may be determined purely by onchain data.

Governing Policies

The Standard Rollup’s governing policies implement additional “reactive” procedures in the event that one or more stakeholder protections in the Law of Chains are violated in such a way that the protocol cannot naturally handle them. Each of these governing policies include reference to a specific protection in the Law of Chains.

As such, these governing policies are applications of the existing principles of the Law of Chains. Subject to the provisions of the Law of Chains, these policies are intended to establish predictable enforcement paths for an illustrative (but not exhaustive) list of potential violations of that document.

In its current form, all governing policies’ relevant enforcement actions would be taken by the L1ProxyAdmin role, which is held by the Phase 0 Security Council, a 2/2 shared by the Foundation and the Optimism Governance-approved Council (or in the case of the chains listed in “Onchain Criteria–Role Configuration Exceptions” above, a 3/3 with the Phase 0 Council plus the Chain Governor). As such, all enforcement actions are expected to follow the standard Protocol Upgrade vote procedure, which is the existing path used for governance to exercise the L1ProxyAdmin role. In the future, policies may include different enforcement mechanisms (e.g. via unilateral action by other councils, or via direct onchain governor outcomes given explicit authority in the protocol.)

Governor Key Recovery

In the current version of the OP Stack, the SystemConfigOwner is permitted to change certain chain configuration values. According to the Law of Chains, control of some of these values are afforded to the Chain Governor (e.g. transaction fee margin), and others are afforded to the Chain Servicer (e.g. the batcher hotkey).

For convenience, the Configuration Check in the above criteria permits either the Chain Servicer or the Chain Governor to be the SystemConfigOwner, so that Chain Governors can delegate all configuration updates to Servicers. However, because the Chain Governor is also protected by the Law of Chains to be able to switch between Chain Servicers, ultimate control of the SystemConfigOwner role should belong to the Chain Governor.

In the event that a Chain Servicer stops fulfilling the wishes of the Chain Governor for those values which the Law of Chains states they should be able to control, or refuses to transfer control of the SystemConfigOwner role in the event that the Chain Governor desires to switch to a different servicer, then the Chain Governor may submit a vote to Optimism Governance to have the Security Council recover the role to an account they control.

Sequencer Censorship

In the event that a sequencer is determined to be maliciously censoring valid user transactions, or experiencing unreasonable downtime impacting applications on the chain, they are violating the User Protection of Security, Uptime, and Liveness in the Law of Chains.

In the event that a Chain Governor refuses to change its sequencer in reaction (after it has clearly been put on notice of the violation), the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new non-censoring sequencer.

Responsible GasLimits

The OP Stack is rapidly evolving and the boundaries of its performance continue to be pushed. As such, the protocol currently does not implement a hardcoded upper bound on the Gas Limit for a chain. However, this ability must be responsibly exercised to ensure fulfillment of User Protections. Thus:

  • Before any GasLimit increase, Chain Governors should submit to the community a public load test which demonstrates stability at that limit.
  • After any GasLimit increase, if the chain experiences a significant degradation in performance or stability, the GasLimit should promptly be lowered back to its previous value.

If a Chain Governor fails to take these steps, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the GasLimit.

Responsible Batch Submission

The current version of the OP Stack allows for batches to be submitted with up to a 12 hour delay after initial reception by the sequencer (the “sequencing window”). However, Sequencers are expected to submit at least twice as frequently (i.e. every 6 hours). This affords sufficient time to batch submit in the case of failures or downtime, fulfilling the User Protection to Security, Uptime, and Liveness.

In the event that a Chain Governor refuses (after it has clearly been put on notice of the violation) to change its sequencer which repeatedly and intentionally violates this practice, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new compliant sequencer.

Fee Margins

The Law of Chains affords Chain Governors the ability to set fee margins for the chain. However, setting the fee margin significantly high can be a form of economic censorship — by making transactions prohibitively expensive to submit, the Governor could effectively violate the User Protection to censorship resistance.

The Standard Rollup should allow a maximum fee margin of 100% (i.e., the average cost of transactions should not exceed twice the cost of batch submission). If a Chain Governor sets the fee margin in excess of this, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the Fee Margin.

ResourceMetering

The SystemConfigOwner role is currently able to modify the ResourceMetering struct, a low-level set of values which set certain properties of L1→L2 message rules. This is a low-level variable with no reason to be changed outside of a protocol upgrade.

If a SystemConfigOwner (either Servicer or Governor) changes this value, the community may submit a vote to Optimism Governance to remove the relevant party and revert the change.

Precommitments

This section commits to anticipated changes (or lack thereof) for future upgrades to this Charter. While by no means an exhaustive description of the Standard Rollup’s full future development path, the following commitments are core to the expectations of existing and future Superchain ecosystem participants. The Collective should endeavor to do everything in its power to ensure the following commitments are actualized, understanding that non-adherence will fundamentally and irrevocably undermine the legitimacy and trustworthiness of Optimism Governance.

Collective Fee Take

This Charter specifies a fee split of the greater of 1) 2.5% of transaction fee revenue and 2) 15% of chain profit (fee revenue - L1 submission cost).

It is extremely important to provide stakeholders in the Collective with a reliable economic model on which they can build sustainable long-term ecosystems. By ratifying this Blockspace Charter, the Collective is signaling its precommitment to all Standard Rollups that it will not modify the fee split parameters outlined above until December 31, 2029 (at the earliest).

This does not preclude changes or improvements to the implementation of the fee split contracts, so long as they preserve the original economic spirit. In the event that new sources of fees (or operating costs) are introduced to the protocol, the economics should be updated with minimized impact to the existing expectations and ecosystems in the Superchain.

Governor/Servicer Role Separation

Some policies above (e.g. Governor Key Recovery) arise from an overloading of the SystemConfigOwner role to control configurability options which the Law of Chains affords separately to Governors and Servicers. In a future upgrade (or upgrades), the Collective should transition to a model which establishes independent roles for the Governors and Servicers of Standard Rollups, allowing them to modify the configuration values afforded to them independently. This change should also remove controllability of the Resource Metering Config without a protocol upgrade.

Ossified GasLimits

Because the OP Stack’s performance is rapidly improving, the onchain GasLimit criteria is bounded above by a significantly higher value (based on the limits of fault provability) than what chains in practice require for stability. The Governing Policy above reflects the fast-paced nature of gas limits today, in which chains frequently increase their gas limits to test stability. However, as the rate of change slows, the Collective should set a more realistic upper bound, which can only be changed via upgrade.

Direct Fee Margin Controls

Today, the “fee margin” discussed in the relevant Governing Policy above is only indirectly influenceable via the control of multiple other configuration variables. In the future, the Collective should implement a protocol improvement which allows the margin to be set more directly, and which imposes a strict upper bound of 100%, to remove the ability to perform economic censorship even temporarily.

17 Likes

Great work in putting this together, this charter will serve as a vital tool in ensuring all Superchains are compliant with the law of chains and more broadly the Optimism ethos.

Will we( the collective) be expecting this fee split to be paid in OP tokens or in ETH

Hi Butterbum

All chains use ETH as their gas token, so it would get paid in ETH

1 Like

Hello, I noticed that the draft mentions: “The chain’s genesis state and predeploy (0x420000…) contracts are standard, uniform implementations with no malicious code.”

Is this saying that there can be no other predeploys/state in addition to the default genesis.json, or is this only requiring that the predeploys/genesis state specified in the default OP Stack configuration are not altered?

With the Worldchain launch, we will need to migrate the existing WorldApp user’s Safe wallets from Optimism to Worldchain. We were planning on setting the genesis state with a predeploy for each user’s Safe address along with the necessary storage slots set.

In general, it would be helpful to have the flexibility to include additional predeploys in the genesis state.

1 Like

Great draft, thanks for putting it together. I’ve few questions that I would like to present here.

The questions assume that I’m building a custom L2 rollup using Op-stack and the chain wants to be a part of the Superchain.

The chain’s genesis state and predeploy (0x420000...) contracts are standard, uniform implementations with no malicious code.

  1. Can we add one or more pre-deploy contracts, which is not malicious but there to have some additional functionality for the new rollup? If one does add one or more predeploys does it still qualify as a standard rollup?

A standard fee split to the Collective is enforced by smart contracts, as specified [here] and implemented by [this contract].

  1. Even though currently all chains use ETH as their gas token, if someone wants to use a custom native gas token in future, or let’s the new rollup has a feature of custom gas token and then would this affect the stance of the new rollup or existing rollup as a standard Rollup chain?

  2. Adding to the above question how would fee split work in that case if custom gas token is implemented/used? Emphasis on custom gas token because let’s say a chain is made for some specific usecase other than the primary use-cases that current chains have, something like redstone for gaming or some chain for other real-world use-case. How would this affect it?

Thanks in advance!

3 Likes

This Standard Rollup Charter draft has been updated to include the changes outlined in the following update post: Updates to the Standard Rollup Charter

2 Likes

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

We would like to confirm; this means that no Chain Governor could block the upgrade process for the rest, correct?

How is this mitigated with interoperability? In principle, chains that fall behind with an old version should be disconnected since the state transition of all involved is at risk.

This process initially seems to have the same level of importance as a typical protocol upgrade audit. Is it expected to treat it as such? Is it expected to cover those in conjunction with third-party security teams? It would be great if these followed a report format for public knowledge.

3 Likes

I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote.

Cool I’m bullish on Optimism

(post deleted by author)

Hello everyone, Mint blockchain is an Optimism Delegate.
Mint blockchain supports this proposal. We think the proposal strengthens the security and decentralization of the Rollup by establishing clear standards for governance and oversight, while ensuring a flexible approach to integrity checks in the early phases.

1 Like

I believe that for each chain included under this role, one developer selected by that chain should be added to the Security Council. This developer would serve not only as a voter but also as a technical representative who is kept updated on the latest changes within their chain and understands the implications of any upgrades. This approach would ensure more informed decision-making while maintaining alignment with each chain’s specific technical requirements.

If something should happen to a particular chain this person will be a direct channel between the Security Council and the specific chain.

2 Likes

I have a bit of a dump of questions:

  • why are the parameters set the way they are?
  • I don’t have enough context on the technical implementation of the OP Stack, and the tradeoffs of different parameter changes, so what’s more important (to me) is how these decisions were made. Was it just OP Labs? Input from other teams?
  • I also think what’s most important is that standard rollup chains are
    • Easily verifiable (as in, it’s easy to independently verify that a rollup chain is “standard”)
    • Secure
    • Sufficiently standardized to be interoperable with other standard rollup chains (as interoperable tech improves)
  • What stake holders have given input on this charter?
  • Which chains are expected to follow this charter?
  • Who decides which chains get a special multisig with a “Chain Governor” like Base and Unichain? What criteria was used to decide it for Base and Unichain?

As a side note, I think there should be some way to make these proposals requiring high technical understanding more accessible to the broader community. As I was getting at above, without the background to analyze the technicals of this proposal, or verify its soundness, it would be nice to have some confidence that a lot of thought and review was put into this proposal. I like the format of protocol upgrades where they talk about risks, other reviewers, and the developer advisory board adds a summary and thoughts as well. I think proposals like this could benefit from the same.

Due to the lack of confidence in my ability to properly critique this proposal, I (on behalf of Blockchain@USC), will likely abstain on this proposal.

2 Likes

Great work! I’m new to the governance side of the community but look forward to contributing!

This brings Optimism closer to its goal and make it more viable and practical.

In cases where there’s a conflict between a Chain Governor and Servicer regarding control over configuration values, how would governance balance community input versus technical requirements?