Executive Summary
Hi I’m Roberto, an engineer on the core Base team and a core developer of the OP Stack. Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation.
This is a proposal for the Ecotone network upgrade, which adopts EIP-4844 blobs for data availability and activates Dencun L1 extensions. Blobs are a new type of data storage introduced by Dencun specifically for the purpose of rollup data availability. Blob data is priced using a separate fee market from regular transaction gas, and is purely additive to calldata (batches in Ecotone can be posted using either). We expect a dramatic (up to ~80x) reduction in overall transaction fees due to the fact that blobs increase data availability capacity to 4x of what all L2s use today. The remaining changes in this upgrade bring the core improvements from the L1 Dencun hardfork into the OP stack, including new opcodes and the beacon root support. While blob data availability requires L1 Dencun activation, the Ecotone upgrade can be activated independently of it.
Specifications
Technical Specification
We propose the Ecotone network upgrade which activates:
- EIP-4844 Blobs for Data Availability
- Dencun
- EIP-4788: Expose beacon chain roots through the execution layer block header and EVM. (spec)
- EIP-1153: Transient storage opcode support (TLOAD, TSTORE).
- EIP-5656: Memory copy opcode support (MCODE).
- EIP-6780: Self-destruct (SELFDESTRUCT) limited to the same transaction only.
- EIP-4844 is the only Dencun execution feature not activated in Ecotone. Blob transactions are instead explicitly disabled, and the BLOBBASEFEE opcode from EIP-7516, while activated, always returns 1. (spec)
- The Ecotone hardfork activation block, which includes several transactions to perform all L2 contract deployments, upgrades, enablements, and proxy updates. (spec)
Security Considerations
Consistent with the OP Labs Audit Framework, we did not have the contents of Ecotone audited; however Coinbase and OP Labs engineers did perform a security review of these changes.
The Dencun upgrade consists of relatively standard EVM changes and the introduction of beacon block root in the block header and a beacon roots contract deployed at a special location. We consider the EVM changes low risk because they have been active on Goerli and Sepolia testnets without issue. We have also entirely disabled the new transaction type (blob transactions) introduced by EIP-4844 from being accepted by the L2 chain.
While blobs are disabled in the L2, Ecotone supports posting transaction batches to the L1 using blobs. This extension affects chain derivation, adding new logic around interpreting blob transactions posted by the batcher, downloading any referenced blobs from an L1 consensus client, and processing their contents by decoding them from the blob format to the usual channel format. We consider these changes medium risk primarily because of the larger scope of the change. These changes do not affect bridging or any L1 contracts, and are therefore unlikely to introduce bugs that can be exploited to drain assets.
The introduction of the new L1 data fee cost function required updates to two of the L2 predeploy contracts, GasPriceOracle and L1Block, and also changes to both op-node and op-geth to compute the fee values and propagate the appropriate fee parameters. The contract extensions were required to pass the new Blob base fee derived from L1 blocks to the L2 so that it is aware of the blob fee market, and so that developers could use the GasPriceOracle to compute the new data fee without having to roll their own implementation of the new function (details here). These changes are limited to a few short functions. Because of the overall scope of this change, we consider it medium risk. The most severe faults from these changes might be a chain halt due to a chain derivation/validation failure, or under/over payment for L1 data fees by users. Significant underpayment could result in revenue loss for the chain operator, but the system provides parameters that can be updated quickly via the SystemConfig in order to quickly compensate for such scenarios.
One final potential risk is the introduction of a special Ecotone upgrade block which introduces special deposit transactions that perform the various contract deployments and upgrades on the L2. Bugs in this code could lead to an incomplete fork with missing contracts or contract functionality expected by the upgrade, in the worst case leading to chain halt. We have tested the upgrade process on several devnets and the Base and OP-goerli testnets with success, and overall consider the changes medium risk.
Impact Summary
We do not anticipate any down time due to this upgrade.
Bringing Dencun to the OP Stack is important to retain compatibility with Ethereum. One Dencun change to be aware of is the new behavior of the SELFDESTRUCT opcode, which may be backwards incompatible for some contracts. We expect the number of affected contracts to be small since the change has been long telegraphed by L1 developers. The beacon root feature introduced by Dencun will allow L2 contracts to validate L1 consensus data, and should support new use cases involving staking pools and re-staking.
We expect the greatest impact of Ecotone to come from using blobs for transaction batching. Blobs are a new type of L1 data storage introduced by Dencun specifically for the purpose of rollup data availability. Blob data is priced using a separate fee market from regular transaction gas, and is purely additive to calldata (batches in Ecotone can be posted using either). It’s difficult to precisely estimate the impact of this feature on transaction fees since we cannot predict new use cases that might arise to consume them. Based on the data availability use case alone, however, capacity increases to 4x what all L2s are using today. While blobspace is uncongested, we expect up to ~80x reduction in fees for all OP chains as long as blobs are fully utilized. Prediction markets are currently estimating a 40x cost reduction in the short term.
Blob usage is optional and configurable by the chain operator in Ecotone. Lower traffic chains may choose not to enable them since achieving maximum benefits may require far less frequent posting of data to the L1. While blob usage requires Dencun activation on the L1, Ecotone can be activated independently of it should the benefits of its other features be desired earlier.
Action Plan
If this vote passes, the Ecotone upgrade will be scheduled for execution on March 14th at 00:00:01 UTC**. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Ecotone is code complete in the optimism monorepo at commit f707883038d527cbf1e9f8ea513fe33255deadbc and op-geth at commit 0402d543c3d0cff3a3d344c0f4f83809edb44f10. The op-node release v1.7.0 and op-geth release v1.101308.2 contain these changes.*
In the event governance vetoes the upgrade, we will release a new version of the op-node and op-geth software with the activation date removed.
This upgrade has already been activated on internal devnets in coordination with Base & Conduit. It successfully activated on op-goerli and base-goerli on Feb 6, with Sepolia scheduled for Feb 21.
If there is a critical security issue, node operators will be able to disable the upgrade by using the --override.ecotone flag on both op-node & op-geth. Coinbase and OP Labs will also collaborate with the community to extensively communicate that the upgrade is no longer happening.
We will release a new version of op-node & op-geth with the mainnet Ecotone activation date baked in and publicize to node operators & end users that the Ecotone upgrade will be occurring. The mainnet ecotone activation date is scheduled for March 14th at 00:00:01 UTC.
Conclusion
This proposal outlines the network upgrade after Delta titled Ecotone. This network upgrade maintains EVM equivalence via activating the Dencun network upgrade and allows OP Stack to take advantage of L1 blob data for lower cost data availability.
We expect that this upgrade will not result in any down time and will occur on March 14th.
*This proposal was updated to reference op-node v1.7.0.
**A previous revision proposed an upgrade date of March 18th 17:00:00 UTC.
