Executive Summary
- Test in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains.
- Span Batches implement a new batching specification that reduces L1 costs by ~97% for inactive chains (165 ETH → 5 ETH).
- We expect Span Batches to derisk launching new OP Chains by meaningfully reducing L1 costs for inactive chains.
Hello! This is Test in Prod, one of the core development teams of Optimism Collective.
This is a proposal for the Delta network upgrade, which activates Span Batches. Span Batches is a new batching spec from Test in Prod, building upon initial designs by Protolambda.
Span Batches removes the overhead of the current batching specs by encoding consecutive L2 blocks into one batch. This leads to reducing L1 costs by ~97% for inactive chains, and 6%~11% for performant chains like OP Mainnet or Base Mainnet based on our backtesting results.
Span Batches will support the adoption of the OP Stack by meaningfully reducing L1 costs for OP Chains, therefore reducing the risks of launching new L2s with the OP Stack.
Technical Summary
Specification
This upgrade (“Delta”) contains a single consensus-layer feature, Span Batches. Please refer to the following documents for the technical information on Span Batches:
- Design Docs
- Spec Docs
- Github Issue Tracker
- Research Repository (includes backtesting results & code for various OP Chains)
Security Considerations
The Span Batch is a consensus-critical feature. It is not required to undergo a security audit according to the OP Labs Audit Framework; Span Batches impacts liveness & reputational quadrant, instead of existential & safety parts in the rubrics of the Audit Framework—specifically derivation aside from deposits and batching. The Audit Framework doesn’t suggest audits in the liveness & reputational quadrant, but rather testing via progressive real-world usage.
The Span Batch doesn’t have changes on the state transitions, so there is no possibility that users’ states can change in an unintended way. In the worst case, some transactions could be omitted.
Therefore, Test in Prod went through the following steps to ensure the safety of this proposal, focusing on the liveness parts:
1) Security review with OP Labs
Test in Prod passed a security review with OP Labs. Since the Delta upgrade isn’t related to user assets, but instead implements a consensus upgrade, we focused on reviewing cases where the consensus could fail and built contingency plans for the failure. Please refer to the Contingency Plans section in the current proposal for detailed contingency plans.
Throughout the review, we figured that the Span Batch deployment would be less likely to impact Sequencer’s pre-confirming block production—the unsafe head progression; we expect end users to be less likely to be impacted in the majority of failure scenarios.
2) Ran verification script on Superchain Devnet & Testnets
Test in Prod prepared the verification script for Span Batches. The script checks the entire consensus process from posting batches on L1 to deriving L2 blocks from L1. It tests if there’s a consensus failure by detecting unsafe reorgs—ensuring nodes derive the same state that the Sequencer originally calculated before posting batches. Please refer to the Functionality Verification Guide for more details.
The verification script works as follows:
- Send various types of transactions to the L2.
- Record the transactions’ hashes & included unsafe blocks’ hashes.
- Poll if the included blocks are consolidated to safe.
- Compare recorded unsafe blocks’ hashes to safe blocks that include transactions.
- If same, it’s a success!
3) E2E tests & unit tests
Test in Prod prepared the e2e tests & unit tests for Span Batches. They cover a wide range of scenarios and check if the code operates as intended. Here are Github PRs for e2e tests: #1 #2 #3
Impact Summary
Performance Impact
Span Batch saves more L1 fees than the current state of the OP Stack, and savings increase the less active the chain is. Therefore, Test in Prod expects more savings on L1 fees for less-active chains; we expect to save L1 fees by ~97% for low-throughput chains and 6%~11% for high-throughput chains like OP Mainnet or Base Mainnet.
Test in Prod backtested several OP Chains and prepared the expected L1 fee savings in %. Please refer to the Expected Result section in the Design Docs for the result.
User Impact
Delta doesn’t include any direct impact on the users’ side. Also, Test in Prod doesn’t expect downtime for the Delta upgrade.
Node Impact
Nodes will be unable to sync the chain if nodes don’t perform the software update until the op-batcher operator starts posting Span Batches. Thus, nodes are required to update software versions to keep in sync with the OP Chains.
Please refer to the Guides for Nodes section in the current proposal for the upgrade details.
Upgrade Details
After Delta hard fork, Span Batches submission won’t be activated automatically; the op-batcher operators should restart their instance with the Span Batches enabled. Therefore, even though Delta hard fork time passes, nothing will happen until the op-batcher operator explicitly starts posting batches in the Span Batch.
OP Chains can use (post & derive) both Singular Batches and Span Batches after the Delta hard fork.
Action Plans
Timeline (including finished items)
Test in Prod proposes 00:00:00 Feb 22, 2024, UTC for the Delta hard fork time—1707922800 in Unix Timestamp. It’s three weeks after Voting Cycle #17 ends, and two weeks after the Citizens’ House veto period.
The Delta upgrade has already been activated on op-goerli, op-sepolia, base-goerli, base-sepolia, pgn-sepolia, zora-sepolia, and Superchain Devnet (operated by OP Labs, Base, and Conduit).
Here’s the list of the timeline for Delta including finished items:
- Superchain Devnet activation at 00:00:00, Dec 08, 2023 UTC.
- Goerli Testnets activation at 00:00:00, Dec 21, 2023 UTC.
- Sepolia Testnets activation at 00:00:00, Dec 22, 2023 UTC.
- Voting results are final & start to notify upgrading nodes at 19:00:00, Jan 31, 2024 UTC.
- Including the one-week veto period.
- (Proposed) Mainnet activation at 00:00:00, Feb 22, 2024 UTC.
- Appended one week due to the veto period.
Contingency Plans
Our contingency plans for the unexpected failure of the Delta upgrade are as follows: op-batcher disables posting Span Batches, start posting legacy batches (Singular Batches), prepare the fix, and enable Span Batches again. In this way, we expect the impact on the user side will be minimized while resolving the issues—the sequencer would continue pre-confirming blocks as normal, but batch submission would be halted until the op-batcher restarts to push Singular Batches.
However, if there’s an unexpected critical issue where we need nodes’ action, we have prepared a way for nodes to disable the upgrade by using --override.delta flag on op-node. Test in Prod will work with OP Labs to monitor, communicate, and alert relevant parties upon the upgrade in such cases.
Software versions
The code for the Delta upgrade is ready in the following Optimism monorepo hash: 54a7dbf8aa9b982f9c6a54cbbe448be41c0b7bc7.
Nodes can manually set the Delta hard fork time with the preceding code. However, nodes will not automatically activate Delta on Mainnet as the Delta hard fork time is not embedded in the code; it cannot be embedded since Delta has not yet been approved by governance.
If the governance approves the Delta hard fork and finalizes the hard fork time, Test in Prod will work with OP Labs to prepare the new release that embeds the Mainnet hard fork time and notify the community. With the new release, nodes won’t have to manually set the Delta hard fork time; but they will automatically activate the Delta upgrade.
The following versions are deployed in the testnets:
Guides for Node Operators
Node operators are required to upgrade the software versions. Please refer to the following guides:
- Delta Upgrade Guide in Optimism Docs
- Delta Node Upgrade Guide
- (For op-batcher operators) Delta Hard Fork Functionality Verification Guide
Conclusion
This proposal outlines the Delta upgrade that includes Span Batches. This upgrade reduces the size overheads of the current specs in a significant step for less-active chains, and it leads to alleviating the risks of launching new OP Stack L2s.
By reducing the L1 fees and risks with the Delta upgrade, we expect to alleviate burdens for less-active chains, help easier adoptions of the OP Stack, and head one step forward to the Superchain future.
We don’t expect sequencer downtime for the Delta hard fork & activating Span Batches.
