A very exciting topic in governance right now is Blockspace Charters, and we want to know your thoughts and ideas on the subject. Relevant links for more information:
What is a chain that would be part of the standard charter?
How does the charter affect upgrades?
Remember good answers get 6 points and the most thoughtful answers will be awarded an additional 20 points. Spam or low-effort posts will not count towards the point total. You can check your points and position in the GovNFT Leaderboard!
A chain that would be part of the standard charter is one that meets the specific criteria outlined in the Blockspace Charter. These criteria generally include:
Version: The chain must be using a specific version of the OP Stack, as determined by commit-hash or release.
Configuration: The chain must fall within an accepted range of parameterizations, including static variables like Chain ID and dynamic variables like sequencer or upgrade keys.
Solvency: The chainās history must not include any invalid withdrawals or outputs that could cause under-collateralization.
The Blockspace Charter affects upgrades in several ways:
Upgrade Proposals: Each upgrade proposal must specify a Blockspace Charter to be upgraded. This ensures that the proposal is aligned with the specific criteria and policies of the charter.
Precommitments: The charter outlines precommitments that must be preserved during upgrades. This provides stability and predictability for stakeholders.
Impact Summary: Upgrade proposals must include a comprehensive justification that all precommitments in the previous charter are preserved by the upgrade.
Superchain Registry: The registry helps map upgrade proposals to specific charters, ensuring that the impact on stakeholders is clearly understood and considered.
A chain that would be part of the Standard Charter is one that uses a specific version of the OP Stack and meets the defined configuration criteria. For example, chains using the OP Stack with a version approved by governance and falling within the accepted range of parameterizations (such as Chain ID, sequencer, or upgrade keys) could be included under the Standard Rollup Charter.
The Blockspace Charter affects upgrades by requiring upgrade proposals to specify a particular Blockspace Charter that will be upgraded. These proposals must link to a pull request with an updated charter, and all changes must justify why they are necessary. Additionally, the new upgrade process ensures that precommitments from the previous charter are preserved, and that stakeholders are involved in understanding the full impact of upgrades through a transparent and accountable process.
1.A chain that adheres to the Standard Rollup Charter is one that leverages a specific version of the OP Stack and aligns with predefined configuration standards. For instance, chains using the OP Stack version endorsed by governance and within the approved set of parameters (such as Chain ID, sequencer setup, or upgrade permissions) can qualify under the Standard Rollup Charter framework.
2.The Blockspace Charter introduces a transparent and accountable upgrade process. Upgrade proposals must specify which Blockspace Charter is being updated and include a pull request with the updated version of the charter. Each change must be clearly justified, ensuring stakeholders understand its necessity. The new process also safeguards previous charter commitments, ensuring continuity and stakeholder engagement throughout every upgrade.
As others have mentioned a chain that adheres to the Standard Rollup Charter uses a specific version of the OP stack that aligns to predefined configuration standards. I think the key thing though is that the Standard Rollup is the [quote=āsystem, post:1, topic:8135ā] Optimism Collectiveās flagship, high-security blockspace product. [/quote]. So the effect of this specific charter is - I think - to set the highest bar for rollups and to indicate clearly (a bit like a gold standard or marque) when a chain has achieved this. One interesting and immediate question arising from this is whether the intention is to allow non-Standard Rollup Charter-supported chains to exist within the OP stack (presumably they can and will) and / or the Superchain (here Iām presuming not). Iād be interested in other GovNFT participantās thoughts and welcome any feedback on this view.
In terms of the Blockspace Charter this is neatly defined as an Operating Manual for the different types of Superchain blockspace - and provides specific implementation details for them. This gets to the heart of the āversion controlā issue that was talked about at the recent Security Council call. It feels like quite an elegant solution to try to manage the different iterations of the OP stack that have come into existence. Blockspace Charters provide a (set of) governing documents and frameworks for the Superchain - and the first one of these is the Standard Rollup Charter.
A couple of interesting question come to mind here - firstly is the ultimate plan to have some kind of visual map / table to show which chains (e.g. OP Mainnet, Mode, Redstone, Soneium etc) adhere to each different Blockspace charter? This could be a really powerful blueprint / state of the nation type document.
And secondly - Iām curious as to whether this specific solution has been lifted and shifted from elsewhere - and if so - where? And was it successful there? Also what were the challenges?
A chain under the Standard Rollup Charter would be one that follows the OP Stack architecture and maintains required configurations like specific Chain IDs and sequencer setups.
The Charterās effect on upgrades is that it enforces a framework ensuring that upgrades align with predefined governance rules. This means that changes must go through a transparent, community-driven process, involving stakeholders to ensure proper alignment with the collectiveās goals.
What is a chain that would be part of the standard charter?
The deterministic criteria for Standard Rollups consist of 3 primary components:
Version: 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.
Configuration: ensuring that all configuration values for the chain are within high-security, well-tested bounds, and that all administrative roles are set correctly.
Solvency: ensuring all of the chainās L1 outputs are correct, preventing historic malicious withdrawals from causing the bridge to become undercollateralized.
Off-Chain Criteria
ChainID Check: Ensure that the Chain ID is unique and does not conflict with pre-existing EVM chains.
Gas Limit Checks: Ensure that the initial GasLimit of the chain is configured to a reasonable value based on the current state of the OP Stack performance test. (See below for more on the Gas Limit policy.)
Security Monitoring: Ensure that certain standard monitoring tools are deployed for each chain.
Manager/Server Validation: Verify at a social level that the chain is indeed deployed and operated by the relevant parties and is not being impersonated.
How does the charter affect upgrades?
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 . 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.