# Upgrade Proposal #11: Holocene Network Upgrade **URL:** \ **Category:** Protocol Upgrade\ **Created:** [November 25, 2024, 1:49pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313 "2024-11-25T13:49:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Dragan\_ZzZ](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/dragan_zzz/32/11193_2.png) [@Dragan\_ZzZ](https://gov.optimism.io/u/Dragan_ZzZ)\ **Post date:** [November 25, 2024, 1:49pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/1 "2024-11-25T13:49:37Z")
### **Proposal Title:** Holocene governance proposal ### **Proposal Type** : Protocol Upgrade ## **Executive Summary** Hi I’m Dragan, a technical program manager at OP labs working on the OP blockchain development team, and a core contributor of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler, Adrian Sutton, George Knee, Matt Solomon from the OP labs team and with Roberto Bayardo from the Base team. Neither OP labs nor I represent or speak on behalf of the Optimism Foundation. Holocene contains three changes: - **Holocene block derivation** : a set of changes that render the derivation pipeline stricter and simpler, but also improve worst-case scenarios for Fault Proofs and Interoperability. - **EIP-1559 configurability** : The elasticity and denominator EIP-1559 parameters become configurable via the `SystemConfig` L1 contract, allowing gas target and gas limit to be independently configured. - **MIPS contract upgrade** : Updates to support additional calls made by the new `op-program` version. ### **Motivation:** We are submitting this proposal to make our community aware about all the improvement we made to our derivation pipeline and adding EIP-1559 configurability options. I believe we should adopt the listed changes since we are getting a lot of improvements to the current codebase with this upgrade. Also the listed changes are opening the doors for future Fault proofs and Interoperability project, since they both need improvement to our block derivation. # **Specifications:** ## **Blockspace Charter:** - This Protocol Upgrade is scoped to the [Standard Rollup Charter](https://github.com/ethereum-optimism/OPerating-manual/blob/712be876d53809b10a0b70d07ea87ce7334163fd/Standard%20Rollup%20Charter.md). - Corresponding changes are specified in this PR: [Holocene Standard Rollup Charter](https://github.com/ethereum-optimism/OPerating-manual/pull/37) ## **Technical Specification** : The Holocene network upgrade ([spec overview](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/holocene/overview.md)) activates the following features: - **Holocene derivation** ([Holocene L2 Chain Derivation](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/holocene/derivation.md#holocene-derivation)) comprises the following changes to the derivation process: - **EIP-1559 configurability** ([Dynamic EIP-1559 Parameters](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/holocene/exec-engine.md#dynamic-eip-1559-parameters)) allows configuring the elasticity and denominator EIP-1559 parameters via the L1 SystemConfig. A new config update event was added, which is parsed by CL clients and then inserted into the extra field of the payload attributes in a special encoding format. These parameters, in turn, are then read by the EL clients during block building and applied accordingly. As _with_ other SystemConfig updates, setting this is restricted to the SystemConfig owner. - **Simplified Fee Scalar Configuration** with new methods in the `SystemConfig` - this allows chain operators to change fee scalars in a more direct way, reducing the chance of user errors ## **Security Considerations** Consistent with [OP labs audit framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864) we did not have the contents of Holocene audited; however, Coinbase and OP Labs engineers did perform a [security review](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-holocene.md) (Failure Mode Analysis) of these changes. The linked FMA can be consulted for details. As for any hardfork that changes derivation, there is a risk that either the spec itself has a bug or that any implementation has a bug. We’ve mitigated these risks by thorough internal reviews of the spec and unit and end-to-end tests of the implementations in Go and Rust. Also, we have added differential tests of the derivation changes between the Go and Rust fault-proof program implementations op-program and Kona for the first time. Holocene has also already been activated on internal devnets of Base and OP Labs, and it was confirmed that these networks operate as expected and that the new EIP1559 reconfigurability works as intended. Specific security considerations for the Holocene upgrade are discussed in the [respective section of the Holocene derivation spec](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/holocene/derivation.md#security-and-implementation-considerations). A noteworthy change in Holocene derivation behavior is that invalid payload attributes got second chances to replace valid, future payload attributes. Because they are immediately replaced by deposit-only attributes with Holocene, there is a theoretically heightened risk for unsafe chain reorgs; however, it is only if a buggy or malicious sequencer batches an invalid block. To the best of our knowledge, we haven’t experienced this on OP Mainnet or other mainnet OP Stack chains yet. Such a scenario would still be automatically resolved: the batcher would detect the reorg and submit the reorged unsafe section of the chain. With the stricter derivation rules, some complexity gets shifted from the derivation pipeline to the batcher because it now has to adhere to stricter rules in order not to produce invalid channels or batches. We’ve implemented a set of improvements to the batcher to guarantee the stricter ordering rules by design. Next to that, the Holocene contains the fail-safe rule that any first frame of a new channel replaces old buffered frames of non-completed channels. An invalid batch forwards-invalidates any remaining batches and the channel that contained the batch. This means that an emergency batcher restart should be able to resolve any deadlock in the derivation pipeline if it were to occur. ## **Impact Summary** We do not anticipate any downtime due to this upgrade. Bringing Holocene derivation changes is making our derivation pipeline stricter and simpler. It also allow us to improve and unlock new development paths for Fault Proofs and Interoperability features. EIP-1559 configurability allows chain operators to change the gas target independently from the gas limit. Before, a workaround had to be taken to raise the limit to indirectly raise the target, and then enforce the old limit via a sequencer block building policy. **Precommitment impact review:** This Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter. - Collective Fee Take: no modification or onchain implementation introduced. - Governor/Servicer Role Separation: no change to role structures or authorization patterns. - Ossified GasLimits: this upgrade does make it easier to configure Gas Limits, but does not ossify them. - Direct Fee Margin Controls: no change to the relevant configuration structure and authorization. Some helper methods for get/set logic are added to the SystemConfig, but do not fulfill the overall intent of this precommittment. # **Action Plan for this release** If this vote passes, the Holocene upgrade will be planned for execution on the **9th of Jan 2025 18:00:01 UTC.** The upgrade will occur automatically for chains on the Granite mainnet release if those chains have opted-in to activate at Superchain times via their superchain-registry configuration (i.e., have the `superchain_time` set to a timestamp before or at the mainnet activation time, or have set their `holocene_time` directly). The mainnet release will be prepared at a later time during the governance process, but no later than 4 weeks before the proposed activation time. Holocene is code complete in the optimism monorepo at a tag [`op-node/v1.10.2-rc.1`](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.10.2-rc.1) and op-geth at tag [`op-geth/v1.101411.4-rc.2`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101411.4-rc.2). # Contract updates The following contracts are updated to OP Contracts [v1.8.0-rc.3 release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.8.0-rc.3): - MIPS: 1.2.1 - FaultDisputeGame: 1.3.1 - PermissionedDisputeGame: 1.3.1 - SystemConfig: 2.3.0 ## SystemConfig Update The `SystemConfig` L1 contract will get upgraded to version 2.3.0 (the implementation is deployed at this address:(“`0xAB9d6cB7A427c0765163A7f45BB91cAfe5f2D375`”). This is a shared implementation of the Mainnet Superchain The upgrade will happen after the Holocene activation. The upgraded `SystemConfig` enables chain operators to update the EIP-1559 parameters via a new function `setEIP1559Params`. ## Fault Proofs Update This update involves a new release of the `op-program` [v1.4.0-rc.3](https://github.com/ethereum-optimism/optimism/releases/tag/op-program%2Fv1.4.0-rc.3) that contains the Holocene activation and generate the _absolute pre-state_ (“`faultGameAbsolutePrestate`”: “`0x03f89406817db1ed7fd8b31e13300444652cdb0b9c509a674de43483b2f83568`”) for it, which is a commitment to the program and its starting state. This requires deploying new `FaultDisputeGame` and `PerimissionedDisputeGame` contracts to L1 Mainnet with the new op-program pre-state hash. - These contracts are deployed at the following addresses `FaultDisputeGame`: (“`0x27B81db41F586016694632193b99E45b1a27B8f8`”) and for `PermissionedDisputeGame`: (“`0x91a661891248d8C4916FB4a1508492a5e2CBcb87`”) - contract addresses are specific to OP mainnet - MIPS: 1.2.1 (with the following contract address: (“`0x5fE03a12C1236F9C22Cb6479778DDAa4bce6299C`”) - which is a shared implementation on the Mainnet Superchain After the veto period has ended, we will ask the Security Council to sign transactions to update the `DisputeGameFactory` to begin using these new contract implementations. This transaction has to be executed _before_ the actual Holocene activation to avoid a broken Fault Proofs system after the activation. - **Updates to the MIPS contract** As part of the Holocene upgrade, the Go compiler was updated from 1.21 to 1.22. This impacts the op-program as the go1.22 runtime makes additional syscalls that are not supported by the pre-Holocene MIPS Fault Proof Virtual Machine (FPVM). As such, Holocene includes an update to MIPS.sol that supports go1.22 programs. This change to the FPVM is very minimal; an update to the `fcntl` syscall emulation that was partially implemented by the pre-Holocene FPVM. In order to make sure we implemented this in a proper way, we conducted an external audit for this change. In order to make sure we implemented this in a proper way, we conducted an external audit for this change, which is open for reviews under this [**link**](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_10-Cannon-FGETFD-3DocSecurity.md) - no major findings reported. # **Conclusion** This proposal outlines the network upgrade after Granite titled Holocene. This network upgrade brings all the listed features and we hope we will get your votes to bring all the suggested improvements to the OP stack. ---
**Author:** ![AnthiasLabs](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/anthiaslabs/32/10199_2.png) [@AnthiasLabs](https://gov.optimism.io/u/AnthiasLabs)\ **Post date:** [November 25, 2024, 9:24pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/2 "2024-11-25T21:24:04Z")
We are an [Optimism delegate](https://vote.optimism.io/delegates/anthiaslabs.eth) with sufficient voting power, and we believe this proposal is ready to move to a vote. ---
**Author:** ![Takeshi](https://avatars.discourse-cdn.com/v4/letter/t/57b2e6/32.png) [@Takeshi](https://gov.optimism.io/u/Takeshi)\ **Post date:** [November 25, 2024, 9:31pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/3 "2024-11-25T21:31:44Z")
Can I know why the audit is not performed for a major technical upgrade? I feel users and developers would be more comfortable knowing the audit has been completed before a network derivation change ---
**Author:** ![PGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/pgov/32/10448_2.png) [@PGov](https://gov.optimism.io/u/PGov)\ **Post date:** [November 26, 2024, 12:43am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/4 "2024-11-26T00:43:45Z")
We are an Optimism Delegate ([PGov Delegate](https://gov.optimism.io/t/pgov-delegate-communication-thread/6059)) and we believe this proposal should be pushed forward to a vote. ---
**Author:** ![jaymayday.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/jaymayday.eth/32/11494_2.png) [@jaymayday.eth](https://gov.optimism.io/u/jaymayday.eth)\ **Post date:** [November 26, 2024, 1:08am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/5 "2024-11-26T01:08:44Z")
I think it’s based on this [framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864). ---
**Author:** ![0xDonPepe](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/0xdonpepe/32/7804_2.png) [@0xDonPepe](https://gov.optimism.io/u/0xDonPepe)\ **Post date:** [November 26, 2024, 1:47am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/6 "2024-11-26T01:47:53Z")
I appreciate that the changes to the MIPs contract were audited and trust the DAB to provide the final decision on the SystemConfig contract review conducted by the OPLabs and Base teams. I am an [Optimism delegate](https://vote.optimism.io/delegates/0xdonpepe.eth)with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![Dragan\_ZzZ](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/dragan_zzz/32/11193_2.png) [@Dragan\_ZzZ](https://gov.optimism.io/u/Dragan_ZzZ)\ **Post date:** [November 26, 2024, 1:32pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/7 "2024-11-26T13:32:17Z")
We used [OP Labs audit framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864/1) and determined that the changes we have in this upgrade don’t require us to perform an audit. However, Coinbase and OP Labs engineering team did perform a security review ([Failure Mode Analysis](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-holocene.md)) of these changes. Feel free to review the FMA document for all the details of our analysis. ---
**Author:** ![SEEDGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/seedgov/32/5202_2.png) [@SEEDGov](https://gov.optimism.io/u/SEEDGov)\ **Post date:** [November 28, 2024, 4:33pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/8 "2024-11-28T16:33:38Z")
Thanks, @Dragan_ZzZ for putting forward this proposal. Regarding the `SystemConfig` change, this looks very straightforward. On the side of the `Holocene` derivation changes, one important question for us is to understand the maximum risk during its implementation. Since the possibility of reorgs is introduced, how deep (in terms of time) could these reorgs go? Should users with time-sensitive activities be concerned about this? Thank you! ---
**Author:** ![kelvin](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/kelvin/32/3162_2.png) [@kelvin](https://gov.optimism.io/u/kelvin)\ **Post date:** [November 29, 2024, 4:06am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/9 "2024-11-29T04:06:56Z")
# Developer Advisory Board: Holocene Summary Hello! The Developer Advisory Board has written the following non-technical summary of the Holocene upgrade proposal. ## Disclaimer Please note that I am an employee of OP Labs. I have written this summary in my capacity as a member of the Developer Advisory Board. I did not have any significant involvement with the development of the Holocene upgrade proposal presented here. ## Holocene Derivation Changes All of the block data for any OP Stack chain is published to Ethereum, which is what makes OP Stack chains Rollups! When nodes want to sync an OP Stack chain, they use a process called “chain derivation” to scan through Ethereum blocks and reconstruct the L2 chain from the various transactions that were published to Ethereum. ### Why is chain derivation being updated? OP Stack chain derivation is handled by a somewhat complex piece of code that tries to make the life of the Sequencer/block producer easier in certain cases. OP Labs has stated that experience from OP Mainnet and other OP Stack chains shows that some of this code is not necessary. Holocene proposes to simplify the chain derivation process and remove a lot of this existing Sequencer hand-holding code. These changes also benefit Fault Proofs and Interop by making the OP Stack simpler and easier to run. ### How does this impact the OP Stack? The Holocene chain derivation changes shift more responsibility for smooth chain operation onto the Sequencer but the changes **do not** allow the Sequencer to do anything new that it could not previously do. Sequencer software would need to be more careful to avoid causing short-term disruptions like reorgs of blocks that the Sequencer has not yet published to Ethereum. OP Labs states that the current Sequencer software already handles this appropriately but any future changes will need to keep this in mind. ### What code is being changed? These changes require modifications to `op-node`, `op-geth`, and any other implementations of these components. ### Were these changes audited? No, these changes were not audited by a third party. OP Labs states that this is consistent with the [OP Labs Audit Framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864). Engineers from OP Labs and Coinbase jointly wrote a [Failure Mode Analysis](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-holocene.md) for these changes. ## EIP-1559 Configurability EIP-1559 is the EIP that controls how Ethereum handles fees, gas, and block gas limits. EIP-1559 defines a number of parameters that control how this process works. Holocene proposes to change two of these parameters (the **elasticity** and **denominator** values) that were previously fixed to be configurable. This gives operators more flexibility when running an OP Stack chain. ### What is the EIP-1559 elasticity parameter? EIP-1559 defines a **target** gas limit for each block. EIP-1559 allows chains to be “elastic” to handle bursts of usage and blocks can therefore be larger than this target gas limit. The **elasticity** parameter defines how much gas a block can use at a maximum in comparison to the target gas limit. For example, if a chain sets a target gas limit of 25 million gas per block and has an elasticity of 2, then the maximum gas limit will be `25 million x 2 = 50 million gas per block`. ### What is the EIP-1559 denominator value? Chains want the amount of gas used in the average block to be close to their target gas limit. EIP-1559 achieves this by automatically _increasing_ the gas price when blocks are using _more_ than the target gas limit and _decreasing_ the gas price when blocks are using _less_ than the target gas limit. The **denominator** parameter defines how quickly these increases can happen. For example, if the denominator is set to 8, then the gas price can increase or decrease by a maximum of 1/8 = 12.5% per block. ### Why are these values being made configurable? OP Labs states that OP Stack operators have requested the ability to have more fine-grained control over the way that block gas limits work on OP Stack chains. ### How would this impact OP Mainnet? OP Mainnet would not be immediately impacted by this change as the values for these two parameters are not changing with Holocene. However, future upgrades can now propose to modify these values. ### What code is being changed? These changes require a modification to the `SystemConfig` contract on Ethereum as well as modifications to the `op-node`, `op-geth`, and any other implementations of these two components. ### Were these changes audited? No, these changes were not audited by a third party. OP Labs states that this is consistent with the [OP Labs Audit Framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864). Engineers from OP Labs and Coinbase jointly wrote a [Failure Mode Analysis](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-holocene.md) for these changes. ## MIPS Changes The Holocene upgrade proposes to upgrade the Go compiler version in the OP Stack from 1.21 to 1.22. This new version of the Go compiler uses certain features that are not supported by the existing `MIPS` smart contract. Holocene proposes to update the `MIPS` contract as a result. ### Why do we need this change now? Version 1.21 of the Go compiler didn’t make use of certain MIPS features that version 1.22 does. Holocene proposes to upgrade to version 1.22 of the Go compiler, so these features must now be supported. ### Were these changes audited? Yes, these changes were audited by [3DOCSec](https://x.com/3DOCsec), an independent security researcher. This audit did not result in any findings. You can find the audit report [here](https://github.com/ethereum-optimism/optimism/blob/7719c8538b8d911519f861fc70085e7a3b4e6787/docs/security-reviews/2024_10-Cannon-FGETFD-3DocSecurity.md). ## Fault Proof Changes Whenever the L2 code undergoes a fork, the Fault Proof code on L1 must also be updated to be able to follow this fork. Holocene proposes to update the `FaultDisputeGame` and `PermissionedDisputeGame` contracts to be able to follow this fork. ### Is this a standard change? Yes, this is a routine change that needs to happen whenever the L2 code forks. Delegates should expect that an update to the `FaultDisputeGame` and `PermissionedDisputeGame` code will come with any future upgrade that changes `op-node` or `op-geth`. ## Feedback If you have any additional questions, comments, or concerns about this proposal that the Developer Advisory Board can help to clarify, please feel free to ping me or any other member of the DAB! ---
**Author:** ![Luckyhooman.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/luckyhooman.eth/32/1684_2.png) [@Luckyhooman.eth](https://gov.optimism.io/u/Luckyhooman.eth)\ **Post date:** [December 1, 2024, 1:19pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/10 "2024-12-01T13:19:26Z")
Thanks Mr smartcontracts.eth & the DAB for the summary. I am an [Optimism delegate](https://vote.optimism.io/delegates/luckyhooman.eth) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![Tane](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/tane/32/6950_2.png) [@Tane](https://gov.optimism.io/u/Tane)\ **Post date:** [December 1, 2024, 9:29pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/11 "2024-12-01T21:29:19Z")
Thanks @Dragan_ZzZ for the proposal and @kelvin for the DAB summary of the proposal. All the proposed changes that are the chain derivation changes, the EIP-1559 elasticity parameter change and the MIPS related changes look reasonable and make sense, to be staged for the future major upgrades. The failure mode analysis provided for these changes is well-thought-out while these changes are not audited according to the Audit Framework. **We are [an Optimism delegate](https://vote.optimism.io/delegates/tanegov.eth) with sufficient voting power and believe this proposal is ready to move to a vote**. ---
**Author:** ![Gauntlet](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gauntlet/32/5216_2.png) [@Gauntlet](https://gov.optimism.io/u/Gauntlet)\ **Post date:** [December 3, 2024, 2:33am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/12 "2024-12-03T02:33:58Z")
After reviewing these proposals, we support this movement to upgrade proposal #11. The elasticity parameter, in theory, makes a lot of sense, allowing for greater flexibility for OP Stack chain builders. As an aside, we would be curious if research has been conducted surrounding user elasticity toward gas limits and what different chains (with different use cases) have found. While the changes are not audited in accordance with the OP Labs Audit Framework, as the DAO is increasingly consulted, it would be beneficial to have some third-party auditing of all changes, if for no other reason than to better represent the needs of OP stack builders in ensuring all changes are as robustly reviewed as possible. That said, as presented, we trust OP Labs’ process to properly audit the #11 upgrade. **We are an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote**. ---
**Author:** ![GFXlabs](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gfxlabs/32/171_2.png) [@GFXlabs](https://gov.optimism.io/u/GFXlabs)\ **Post date:** [December 3, 2024, 4:10pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/13 "2024-12-03T16:10:54Z")
> [@Dragan\_ZzZ](#): > > Consistent with [OP labs audit framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864) we did not have the contents of Holocene audited; Can we revisit this framework? This just seems unnecessary not to audit all of these upgrades. What exactly is gained by not auditing, anyway? If Labs is unable to finance the audit, [governance regularly provides audit subsidies](https://app.charmverse.io/op-grants/audits-and-special-missions-sub-committee-16536013406280148). Even if no user funds are at risk, there’s reputational risk. ---
**Author:** ![chaselb](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/chaselb/32/3530_2.png) [@chaselb](https://gov.optimism.io/u/chaselb)\ **Post date:** [December 3, 2024, 6:21pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/14 "2024-12-03T18:21:50Z")
On behalf of Blockchain@USC: We are an [Optimism delegate](https://vote.optimism.io/delegates/0x995013b47ef3a2b07b9e60da6d1fff8fa9c53cf4) with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![Dragan\_ZzZ](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/dragan_zzz/32/11193_2.png) [@Dragan\_ZzZ](https://gov.optimism.io/u/Dragan_ZzZ)\ **Post date:** [December 3, 2024, 10:36pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/15 "2024-12-03T22:36:43Z")
Hey @GFXlabs, thanks for your comment. As mentioned in my post and by @kelvin, we performed a full [Failure Mode Analysis](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-holocene.md) for all the changes mentioned in Holocene. This was done by all implementation teams and we shared all our findings publicly, which is the process that should follow according to the [Audits framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864). I do believe that we are actively revisiting this framework and that we will probably make certain updates to it in 2025. ---
**Author:** ![seb](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/seb/32/3838_2.png) [@seb](https://gov.optimism.io/u/seb)\ **Post date:** [December 4, 2024, 9:53am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/16 "2024-12-04T09:53:37Z")
Hey @SEEDGov, Unsafe reorgs have always been possible. We have just identified a new scenario which could theoretically cause an unsafe reorg. We’ve introduced the new derivation rule to reattempt invalid payload attributes with a deposits-only version. This new rule is primarily in preparation of future Interop protocol extensions, to avoid cascading reorgs of inter-dependent chains. An unsafe reorg from this scenario is very theoretical and could only be cause by a malicious or (very unlikely) buggy sequencer implementation. A sequencer would need to _craft invalid attributes_, different from the matching unsafe block, and then batch them. So under normal operation, this scenario cannot happen. And if you have a malicious chain operator, there’s worse things to worry about than an unsafe reorg. The depth of such a reorg would be at most the length of the unsafe chain, so it wouldn’t go into the safe chain. Therefore no action needs to be taken by normal chain users, and practically, unsafe chain reorgs aren’t more probably than they were before, in terms of _expected causes of reorgs_. Hope this helped putting the reorg risk into perspective. ---
**Author:** ![Takeshi](https://avatars.discourse-cdn.com/v4/letter/t/57b2e6/32.png) [@Takeshi](https://gov.optimism.io/u/Takeshi)\ **Post date:** [December 5, 2024, 8:32pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/17 "2024-12-05T20:32:36Z")
Fully agree A network that is securing billions in TVL like Optimism and Superchain should not push any network level upgrades without a third party audit. It seems bordering on careless… ---
**Author:** ![MBBCH15](https://avatars.discourse-cdn.com/v4/letter/m/6de8d8/32.png) [@MBBCH15](https://gov.optimism.io/u/MBBCH15)\ **Post date:** [December 8, 2024, 10:09am UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/18 "2024-12-08T10:09:46Z")
Weldone team… more effort in ensuring the op collective mission is actualize Stay Optimistic. ---
**Author:** ![Pumbi](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/pumbi/32/12911_2.png) [@Pumbi](https://gov.optimism.io/u/Pumbi)\ **Post date:** [December 9, 2024, 3:07pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/19 "2024-12-09T15:07:10Z")
Hi @lavande! > [@Season 7: Reflection Period Guide](https://gov.optimism.io/t/season-7-reflection-period-guide/9299/1): > > [Holocene Network Upgrade](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313) (3 delegate approvals and 1 from DAB) This proposal met the requirement for delegate approvals, but how will this go to a vote if there is currently no elected DAB to give the remaining approval? As I recall, during all Reflection Periods we always have Upgrade Proposals. I think this situation should be considered in the DAB charter for Season 7. CC:@zachobront ---
**Author:** ![Dragan\_ZzZ](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/dragan_zzz/32/11193_2.png) [@Dragan\_ZzZ](https://gov.optimism.io/u/Dragan_ZzZ)\ **Post date:** [December 9, 2024, 4:29pm UTC](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/20 "2024-12-09T16:29:34Z")
Hey all, just a quick update on my side: - I want to let everyone know that I re-formatted the gov proposal to the new “charter-aware upgrade proposal” format that was approved with the ratified standard blockspace charter proposal. - No substantive changes were made to the content of this proposal. - @AnthiasLabs, @PGov, @Gauntlet @Tane, @Luckyhooman.eth - I’m making you aware about this change, since you already shared your approval on the Holocene upgrade proposal. 🙏 [Next page](https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313.md?page=2)