https://gov.optimism.io/t/season-6-introducing-blockspace-charters-superchain-first-governance/8133

In Season 6 of Optimism Governance, we intend introduce the Blockspace Charter: a new, technical-focused governing document (and framework) for the Superchain. This post will serve as an introduction to Blockspace Charters, explaining what they are and what their purpose is. We will also present, and eventually seek ratification for, the first charter—the Standard Rollup Charter—in a parallel post. An initial draft of the Standard Rollup Charter for community feedback can be found here 60.

The Reflection Period will be used to build understanding of the underlying concepts presented below. Ratification for the Standard Rollup Charter will occur during Season 6, and updates to the corresponding Protocol Upgrade framework will follow. In the meantime, the Foundation will conduct an AMA as part of the Token House Community Call on Tuesday, May 14 to answer any questions and collect community feedback. Followup calls may be scheduled as necessary.

Motivation

The Superchain is quickly blossoming into a robust ecosystem of OP Stack-based chains. However, these chains are not all technically equivalent:

Different chains may use different versions of the OP Stack—some projects have made modifications to the stack, and others are on outdated versions of it.

Even within chains that are on the same version, some may be configured differently — that is, deployed with different values for various parameters, admin roles, and so on.

Open source, permissionless innovation is key to the Collective’s success. At the same time, ecosystem fragmentation also poses challenges:

Users and developers need an easy way to understand what blockspace has which properties and guarantees.

Optimism Governance needs to understand how to make decisions about these different forms of blockspace, which may make different commitments and have different control structures.

The Law of Chains 14 is a neutrality framework designed to provide a guiding light for the Superchain and its stakeholders to make decisions and uphold protections. However, the Law of Chains is intentionally agnostic to any specific details of the protocol. This allows for it to be applicable over many iterations of the protocol, but also means that it can fail to provide clear guidance at the granularity described in the above bullets.

This makes the Law of Chains analogous to the Working Constitution of the Optimism Collective 2. It defines the guiding principles for the Collective’s governance, but it does not define the specific mechanisms of voting cycles, quorums, and so forth. Blockspace Charters are the equivalent to the Operating Manual 3, providing the specific implementation details for different types of Superchain blockspace.

What is a Blockspace Charter?

At a high level, a Blockspace Charter consists of three primary components: Criteria, Governing Policies, and Precommitments.

Criteria are the specific technical parameters which define which chains are under the scope of a given charter. The charter’s criteria should provide an objective definition for which chains are under its scope. Generally, there are two components to blockspace criteria:

Version: The version of the OP Stack which the chain is using, as determined by commit-hash/release. This refers to the specific protocol code powering the blockspace.

Configuration: the accepted range of parameterizations of the software in the OP Chain’s deployment. Configuration can include static variables defined at genesis, like the Chain ID, and dynamic variables, like the chain’s sequencer or upgrade keys. Configuration bounds state what values those options must fall within to satisfy the charter’s criteria.

Solvency: This involves ensuring that a chain’s history does not include any invalid withdrawals, or invalid outputs, which could cause the bride to be undercollateralized.

Governing Policies are the specific rules, procedures, and principles which stakeholders participating in the charter’s blockspace follow.

Generally, Governing Policies will be related to how the different configured roles should behave or interact, and how that is enforced. For example, if a charter’s blockspace criteria requires that upgrade keys configured be held by the Security Council, and allows the chain’s sequencer to be configured to be anybody, then the governing policies could define:

The required behavior of the sequencer, which, if violated, would be grounds for removal, and the methods by which the community can check for violations.

The governance process (i.e. proposal type) by which governance could vote to remove a sequencer found in violation.

The signing procedure which would be subsequently taken by the Security Council to remove the offending sequencer.

As you will see in the Standard Blockspace Charter draft 60, governing policies should be mapped back to the Law of Chains 14 guiding principles. For each protection in the Law of Chains, the governing policies make explicit how those protections can be upheld for the charter’s blockspace.

Precommitments serve as a commitment mechanism, outlining anticipated changes (or anticipated consistency) for future upgrades to the charter.

They are designed to provide stakeholders with a clear understanding of the long-term vision and stability of the governance framework. By committing to specific parameters or outlining planned evolutions of the charter, Precommitments help mitigate uncertainty and foster a stable environment for growth and innovation within the Superchain ecosystem.

Precommitments can address various critical aspects of OP chains, such as fee split models, role separations, and technical parameters like gas limits and fee margins.

The specificity of Precommitments can vary from extremely specific anticipated changes to protocol code, to anticipated changes to Governing Policies’ enforcement procedures, to implementation-independent economic guidance or principles.

How will Blockspace Charters be rolled out?

Blockspace Charters will be rolled out alongside two supporting components: the Superchain Registry, a Github repository which manages addition of new chains according to Charters’ Criteria, and an improved upgrade proposal process which maps upgrade proposals to a particular Charter (see here 21.)

Superchain Registry

The Superchain Registry will play a crucial role in the Blockspace Charter framework by serving as an accessible index of what chains are a part of the Superchain. It acts as the source of truth for which chains have been accepted under a specific charter and documents the specific configuration values which have been chosen for each chain. This registry is essential for maintaining transparency and accountability within the Superchain ecosystem.

The Superchain Registry implements the validation logic referenced in Charters’ Criteria via an automated test suite. This ensures that all chains meet the criteria outlined in their respective Blockspace Charter before being added, ensuring consistency and security across the Superchain.

As a public index, the Superchain Registry also serves as unified, accessible documentation for what OP Chains exist, and what kind of blockspace they implement (i.e.—what charter, if any, they fall under). Note that the Superchain Registry may include different chains in the superchain which meet different charters’ criteria (or which meet no charters’ criteria). This means that inclusion in the Superchain Registry only implies inclusion in the Superchain. The Superchain Registry implements an extensible categorization system to clearly delineate which chains fall under which criteria (and therefore which Blockspace Charter), which further implies what “part” of the Superchain it is in.

Incremental Rollout (Beta Registry)

While the process outlined in this document brings a great deal of clarity to Superchain governance, the Collective already votes on protocol versions independent of the chains in question. As the Security Council currently enacts all Protocol Upgrades, we do not view it as strictly necessary for the Standard Rollup Charter to be ratified before the Phase 1 Security Council becomes responsible for upgrades on additional OP Chains.

Therefore, in close coordination with the Security Council and relevant Chain Governors and Servicers, we plan to roll out a “beta registry” and begin onboarding some initial chains to the Phase 1 Security Council and Superchain Registry, if we know they are on the governance-approved version of the OP Stack. We plan to use this as an opportunity to iron out any frictions and get the Security Council comfortable with the end-to-end process, before before the charter is ratified and the process is scaled.

Improved Upgrade Proposal Process

Corresponding to Blockspace Charters being able to rigorously define specific types of blockspace, upgrade proposals will now be changed to correspond to specific charters. Together with the Superchain Registry, this will allow the Collective to clearly understand exactly which chains are in the scope of an upgrade, and rigorously consider the impact on stakeholders.

The updated Upgrade Proposal template can be found here 21. The template is relatively similar to that in previous seasons, with the difference that:

Upgrade proposals now specify a Blockspace Charter to be upgraded.

Upgrade proposals must link to a pull request for an updated charter. This will be the version of the charter that, if successful, applies post-upgrade.

The Impact Summary section of the upgrade proposal now must provide:

Justifications for all changes to the Blockspace Charter not covered in other sections.

A comprehensive justification that all Precommitments in the previous Charter are preserved by the upgrade.

This enhanced upgrade proposal process, by aligning closely with Blockspace Charters and the Superchain Registry, ensures a transparent, accountable, and stakeholder-focused approach to evolving the Superchain. It supports to goal that every upgrade is carefully considered, justified, and aligned with the long-term vision and commitments of the Optimism Collective, fostering a stable and innovative ecosystem.

Listed on May 13

8 days later

Kami

May 21

Hi guys, I have a question:

Is one purpose of the Blockspace Charters to define the main guidelines that OP Stack-based chains should follow?

Understanding that each Blockspace Charters will package the different processes for chains based on OP Stack and in this way provide more structure through its 3 components: Criteria, Governing Policies and Precommitments.

But I don’t understand how it relates to the section that says:

system: This makes the Law of Chains analogous to the Working Constitution of the Optimism Collective. It defines the guiding principles for the Collective’s governance, but it does not define the specific mechanisms of voting cycles, quorums, and so forth. Blockspace Charters are the equivalent to the Operating Manual, providing the specific implementation details for different types of Superchain blockspace.

Please can someone help me solve them.

Thank you.