Season 6: [DRAFT] Standard Rollup Charter

Season 6: [DRAFT] Standard Rollup Charter


// This is a draft for community feedback. A final draft will be ratified by the Token House in Season 6. 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, with Optimism Governance responsible for upholding the protections outlined in the Law of Chains. Further, the Standard Rollup should have all potential changes treated with careful consideration by the governance community, to enable long-term, sustainable projects 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, up-to-date, and secured by the Optimism Security Council, as well as a set of lightweight offchain criteria initially checked by the Optimism Foundation.

Deterministic (Onchain) Criteria

The deterministic criteria for Standard Rollups consist of 3 primary components:

  1. Version Check: ensuring that all L1 smart contracts are the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase.

  2. Configuration Check: ensuring that all configuration values for the chain are within high-security, well-tested bounds, and that all administrative roles are set correctly.

  3. Solvency Check: ensuring all of the chain’s L1 outputs are correct, preventing historic malicious withdrawals from causing the bridge to become undercollateralized.

The precise code which can be used to perform these checks can be found [here], and should be considered the canonical, deterministic criteria for what blockspace is governed via this charter. However, some of the key points are included here for readability:

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

  • The protocol parameters are constrained to high-security, high-stability, well-tested values.

  • The Security Council (currently in Phase 0) for the chain’s L1 bridge contracts, and any other roles .

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

Offchain Criteria

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

  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 necessary checks related to compliance with applicable laws.

The Optimism Foundation’s final inclusion of a chain in the superchain-registry repo will be the canonical indicator of passing the offchain criteria. Thus, in summation, the community can determine whether a given chain falls under the scope of this charter by checking that:

  • The Chain passes all Deterministic Criteria checks

  • The Chain has been included by the Optimism Foundation in the superchain-registry repo.

Over time, it should be expected that the Foundation’s subjective checks are 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.

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. As such, all enforcement actions will 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 Phase 1 Security Council recover the role to an account they control.

Sequencer Censorship

In the event that a sequencer is determined to be intentionally 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, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new 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 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. A Chain Governor that configures the OP Chain in such a way that Users indirectly cannot transact (e.g.%2C by setting a prohibitively high gas markup.)

The Standard Rollup should allow a maximum fee margin of 50% (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.

Collective Fee Take

The current Blockspace Charter specifies a fee split to the collective 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 reliable, sustainable long-term projects. 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 for 5 years, until [June] 2029.

This does not preclude changes or improvements to the implementation of the fee split contracts, so long as they preserve the original 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 projects on 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, the Collective expects to transition to a model which establishes independent roles for the Governor and Servicer, allowing them to modify the configuration values afforded to them independently. This change would also remove controllability of the Resource Metering Config without a protocol upgrade.

Ossified GasLimits

Because the OP Stack’s performance is rapidly improving, the GasLimit configurability is unbounded (subject to the relevant Governing Policy above). However, as the rate of change slows, the Collective expects to set a hard 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 anticipates a protocol improvement which allows the margin to be set more directly, and which imposes a strict upper bound of 50%, to remove the ability to perform economic censorship even temporarily.

5 Likes