Optimism is Ethereum, scaled.
This release candidate enables fault proofs in the withdrawal path of the bridge on L1. It also modifies the SystemConfig
to remove the legacy L2OutputOracle
contract in favor of the DisputeGameFactory
.
Specification here.
The full set of L1 contracts included in this release is:
The L2OutputOracle is no longer used for chains running this version of the L1 contracts.
L2OutputOracle
L2OutputOracle
has been removed from the deployed protocol.OptimismPortal
OptimismPortal
has been modified to allow users to prove their withdrawals against outputs that were proposed as dispute games, created via a trusted DisputeGameFactory
contract. spec.SystemConfig
SystemConfig
has been changed to remove the L2_OUTPUT_ORACLE
storage slot as well as the getter for the contract. To replace it, a new getter for the DisputeGameFactory
proxy has been added.DisputeGameFactory
DisputeGameFactory
is the new inbox for L2 output proposals on L1, creating dispute games.FaultDisputeGame
FaultDisputeGame
facilitates trustless disputes over L2 output roots proposed on L1. spec.PermissionedDisputeGame
FaultDisputeGame
contract, that permissions proposing and challenging. Deployed as a safety mechanism to temporarily restore liveness in the event of the FaultDisputeGame
's failure.MIPS
MIPS
VM is a minimal kernel emulating the MIPS32 ISA with a subset of available Linux syscalls. This contract allows for executing single steps of a fault proof program at the base case of disputes in the FaultDisputeGame
. spec.PreimageOracle
PreimageOracle
contract is responsible for serving verified data to the program running on top of the MIPS
VM during single-step execution. When data enters the PreimageOracle
, it is verified to be correctly formatted and honest. spec.AnchorStateRegistry
AnchorStateRegistry
contract is responsible for tracking the latest finalized root claims from various dispute game types.DelayedWETH
DelayedWETH
is an extension of WETH9
that delays unwrapping operations. Bonds that are placed in dispute games are held within this contract, and the owner may intervene in withdrawals to redistribute funds to submitters in case of dispute game resolution failure.⚠️ This is a recommended maintenance release of op-node. It fixes an ssz unmarshaling implementation in the p2p req-resp protocol (#10362).
Full Changelog (all monorepo): https://github.com/ethereum-optimism/optimism/compare/v1.7.4...op-node/v1.7.5
🚢 Docker image: https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.7.5
If an L1 block got reorg'd out during blob retrieval, an op-node might get stuck in a loop retrieving a blob that will never exist, requiring a restart. This got fixed by internally signaling the right error types, forcing a derivation pipeline reset in such cases.
op-batcher and op-proposer can now wait for the sequencer to sync to the current L1 head before starting their work. This fixes an issue where a restart of op-batcher/proposer and op-node at the same time might cause to resend duplicate batches from the last finalized L2 block, because a freshly restarted op-node resyncs from the finalized head, potentially signaling a too early safe head in its sync status.
🏳️ This feature is off by default, so we recommend testing it by using the new batcher and proposer flag --wait-node-sync
(or its corresponding env vars).
Enabling this will cause op-batcher and op-proposer to wait for the sequencer's verifier confirmation depth for typically 4 L1 blocks, or ~1 min, at startup.
🏳️ To speed up this process in case that no recent batcher transaction have happened, there's another optional new batcher flag --check-recent-txs-depth
that lets the batcher check for recent batcher transactions to determine a potentially earlier sync target. This feature is off by default (0) and should be set to the sequencer's verifier confirmation depth to get enabled.
superchain
package by @geoknee in https://github.com/ethereum-optimism/optimism/pull/10204
checkForGapInUnsafeQueue
by @bitwiseguy in https://github.com/ethereum-optimism/optimism/pull/10063
Full Changelog: https://github.com/ethereum-optimism/optimism/compare/v1.7.3...v1.7.4
🚢 Docker Images:
This contracts release adds an optional DA Challenge contract for use with OP Plasma. If usePlasma
is set to true in the deploy config, then the OP Plasma feature will be enabled.
The challenge DA contract is used to ensure that data posted as part of OP Plasma is made available. There are four deploy config parameters that must be set when using this feature: daChallengeWindow
, daResolveWindow
, daBondSize
, daResolverRefundPercentage
⬆️ This is a recommended release for Optimism Mainnet, particularly for op-batcher operators.
This release contains general fixes & improvements to op-node, op-batcher, & op-proposer. This also update the monorepo op-geth dependency to https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101311.0
The most important change to be aware of is that the op-batcher is now significantly more performant in handling span batches that contain a large number of L2 blocks.
Read
more correctly by @zhiqiangxu in https://github.com/ethereum-optimism/optimism/pull/10034
Full Changelog: https://github.com/ethereum-optimism/optimism/compare/v1.7.2...v1.7.3
🚢 Docker Images:
⬆️ This is a strongly recommended release of op-batcher for all chain operators.
See release notes for v1.7.2-rc.3
for details on how to configure a multi-blob batcher.
The batcher now tracks channel durations relative to the last L1 origin in a previous channel. The last channel's L1 origin is restored at startup and during reorgs.
This ensures that the desired channel duration survives restarts of the batcher, which is particularly important for low-throughput chains that use channel durations of a few hours.
There's a known quirk in the new tracking design, which leads to a slightly lower effective channel duration (~1min lower), related to how a channel timeout is determined relative to the current L1 head, not current channel's newest L1 origin. This will be improved in a future release.
The channel and compressor configuration got simplified by removal of the target-frame-size
flag. The only configuration parameters left to configure the channel size are
max-l1-tx-size
- default of 120k for calldata; for blobs this is overwritten to the max blob sizetaget-num-frames
- default of 1 for calldata; for multi-blob txs, set this to the desired amount of blobs per blob-tx (e.g. 6)
The default compressor is the shadow compressor, which is recommended in production.The batcher now correctly estimates a channel's output size, fixing a rarely but regularly occurring bug that produced overflow frames, leading for example to a 7th blob that was sent in a second batcher transaction.
IsLast
as true
when closed && maxDataSize==readyBytes
by @zhiqiangxu in https://github.com/ethereum-optimism/optimism/pull/9696
NextBatch
by @zhiqiangxu in https://github.com/ethereum-optimism/optimism/pull/9885
Full Changelog: https://github.com/ethereum-optimism/optimism/compare/v1.7.0...v1.7.2
This release enables atomic, cross-chain upgrades and mitigates potential exploitation risks during emergency, multi-chain upgrades by transitioning chain-specific deployment configuration variables from immutables into storage. It also extends SystemConfig
to contain the addresses of the network’s contracts.
Governance post: https://gov.optimism.io/t/upgrade-proposal-6-multi-chain-prep-mcp-l1/7677
The full set of L1 contracts included in this release is:
The following contracts would be changed as part of this upgrade. Each contract links to the pull request where the changes were made, and the bullet points corresponds to the immutable variables moved into state (in format {type} {varName}
):
L2OutputOracle l2Oracle
SystemConfig systemConfig
OptimismPortal portal
CrossDomainMessenger otherMessenger
CrossDomainMessenger messenger
StandardBridge otherBridge
CrossDomainMessenger messenger
StandardBridge otherBridge
address bridge
uint256 submissionInterval
uint256 l2BlockTime
address challenger
address proposer
uint256 finalizationPeriodSeconds
sync()
method by @tynes in https://github.com/ethereum-optimism/optimism/pull/9100
Full Changelog: https://github.com/ethereum-optimism/optimism/compare/op-contracts/v1.2.0...op-contracts/v1.3.0
The op-batcher in this release candidate has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the specs for more technical details on channels and frames.
A minimal batcher configuration (with env vars) to enable 6-blob batcher transactions is:
- OP_BATCHER_BATCH_TYPE=1 # span batches, optional
- OP_BATCHER_DATA_AVAILABILITY_TYPE=blobs
- OP_BATCHER_TARGET_NUM_FRAMES=6 # 6 blobs per tx
- OP_BATCHER_TXMGR_MIN_BASEFEE=2.0 # 2 gwei, might need to tweak, depending on gas market
- OP_BATCHER_TXMGR_MIN_TIP_CAP=2.0 # 2 gwei, might need to tweak, depending on gas market
- OP_BATCHER_RESUBMISSION_TIMEOUT=240s # wait 4 min before bumping fees
This enables blob transactions and sets the target number of frames to 6, which translates to 6 blobs per transaction. The min. tip cap and base fee are also lifted to 2 gwei because it is uncertain how easy it will be to get 6-blob transactions included and slightly higher priority fees should help. The resubmission timeout is increased to a few minutes to give more time for inclusion before bumping the fees, because current txpool implementations require a doubling of fees for blob transaction replacements.
Multi-blob transactions are particularly interesting for medium to high-throughput chains, where enough transaction volume exists to fill up 6 blobs in a reasonable amount of time. You can use this calculator for your chain to determine what number of blobs are right for you, and what gas scalar configuration to use. Please also refer to our documentation on Blobs for chain operators.
🚢 Docker image: https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-batcher:v1.7.2-rc.3
A full v1.7.2
release of the op-stack follows soon.
⬆️ This is a recommended release for node operators using Snap Sync on Optimism Mainnet & Sepolia. For other users, this is a minor release. Node operators should be on at least v1.7.0.
Full Changelog: https://github.com/ethereum-optimism/optimism/compare/op-node/v1.7.0...op-node/v1.7.1
❗ Mainnet operators are required to update to this release to follow the chain post-Ecotone. This release contains an optimistic Ecotone Mainnet activation time of Mar 14, 00:00:01 UTC
.
⚠️ The old release v1.6.1
contained a different Ecotone Mainnet activation date, so it is particularly important for Mainnet operators to upgrade from this release.
The Ecotone activation contained in this release is still subject to approval during the currently ongoing Optimism Governance voting cycle 19, see the Governance Proposal of the Ecotone Protocol Upgrade. The voting period ends on Mar 6 while the veto period ends on Mar 13, 19:00 UTC.
We will soon publish a Veto Release in advance with the Ecotone OP Mainnet activation removed so node operators can prepare for the unlikely event of a negative vote or a veto. We will also soon provide documentation on how to override the Ecotone activation included in this or future releases via command line flags or env vars. This leaves an emergency window of 5h to change the node configuration, or update to the Veto Release, in the unlikely event that the veto period ends in a veto.
Node operators need to configure a Beacon endpoint for op-node
, because soon after the Ecotone activation, batch transactions will be sent as 4844 blobs, and blobs can only be retrieved from Beacon nodes. If you're using Lighthouse, make sure to use at least version v5.0.0
, which contains the Dencun upgrade for Mainnet.
The op-node
provides a new command line flag & env var for configuring the Beacon endpoint: --l1.beacon
and $OP_NODE_L1_BEACON
. If you need to configure an HTTP header for authentication with the Beacon endpoint, you can use the flag --l1.beacon-header
or $OP_NODE_L1_BEACON_HEADER
.
❗ We encourage all node operators to already configure their Beacon endpoint to avoid interruptions after the Ecotone activation.
op-node 1.7.0 and op-geth v1.101308.2 now support Snap Sync. To enable snap sync set the --syncmode=execution-layer
flag on op-node
. op-geth
should also be set to --syncmode=snap
and must have discovery and be peered to the network for snap sync to work.
This feature is ready to be tested, but still may contain some bugs as it is rolled out.
SystemConfigProxy
address from new location in superchain
(registry). by @geoknee in https://github.com/ethereum-optimism/optimism/pull/9585
Full Changelog (monorepo): https://github.com/ethereum-optimism/optimism/compare/v1.6.1...v1.7.0
https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.7.0 https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-batcher:v1.7.0 https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-proposer:v1.7.0