# \[FINAL\] Upgrade Proposal #3: Delta Network Upgrade

**URL:** <https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310>\
**Category:** Protocol Upgrade\
**Created:** [January 5, 2024, 7:35am UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310 "2024-01-05T07:35:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![testinprod\_io](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/testinprod_io/32/7749_2.png) [@testinprod\_io](https://gov.optimism.io/u/testinprod_io)\
**Post date:** [January 5, 2024, 7:35am UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/1 "2024-01-05T07:35:07Z")

</div>

## 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](https://op-tip.notion.site/Span-Batch-Design-Docs-b85e599a47774dcdb8171cc84cab2476#:~:text=PGN%20(Further%20Analysis%20Notebook)) (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](https://gov.optimism.io/t/welcoming-test-in-prod-to-the-optimism-collective/6944) 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](https://op-tip.notion.site/Span-Batch-Design-Docs-b85e599a47774dcdb8171cc84cab2476#:~:text=the%20hard%20fork.-,Expected%20Results,-We%20had%20backtests).

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](https://op-tip.notion.site/Span-Batch-Design-Docs-b85e599a47774dcdb8171cc84cab2476?pvs=74)
- [Spec Docs](https://github.com/ethereum-optimism/optimism/blob/develop/specs/span-batches.md)
- [Github Issue Tracker](https://github.com/ethereum-optimism/optimism/issues/7454)
- [Research Repository](https://github.com/testinprod-io/span-batch-research) (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](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864); 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](https://github.com/ethereum-optimism/optimism/pull/8474) 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](https://op-tip.notion.site/Delta-Hard-Fork-Functionality-Verification-4dba746fd3e2409a8a3c9c362fa27dd3) 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](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#unsafe-block-consolidation).
- 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](https://github.com/ethereum-optimism/optimism/pull/7291) [#2](https://github.com/ethereum-optimism/optimism/pull/8047) [#3](https://github.com/ethereum-optimism/optimism/pull/8358)

## 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](https://op-tip.notion.site/Span-Batch-Design-Docs-b85e599a47774dcdb8171cc84cab2476#:~:text=the%20hard%20fork.-,Expected%20Results,-We%20had%20backtests) 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`](https://github.com/ethereum-optimism/optimism/commit/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:

- [op-node: v1.4.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.4.1)
- [op-batcher: v1.4.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-batcher%2Fv1.4.1)
- [op-proposer: v1.4.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-proposer%2Fv1.4.1)
- [op-geth: v1.101304.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101304.2)

### 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](https://docs.optimism.io/builders/node-operators/network-upgrades/delta)
- [Delta Node Upgrade Guide](https://op-tip.notion.site/Delta-Node-Upgrade-Guide-c4627f9dc02e4ed884d2420e8a9f8777)
- (For op-batcher operators) [Delta Hard Fork Functionality Verification Guide](https://op-tip.notion.site/Delta-Hard-Fork-Functionality-Verification-4dba746fd3e2409a8a3c9c362fa27dd3)

## 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.

---

<div class="post-metadata">

**Author:** ![Harper](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/harper/32/420_2.png) [@Harper](https://gov.optimism.io/u/Harper)\
**Post date:** [January 5, 2024, 4:28pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/2 "2024-01-05T16:28:56Z")

</div>

wowow

this is super exciting!

---

<div class="post-metadata">

**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:** [January 8, 2024, 2:09pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/3 "2024-01-08T14:09:42Z")

</div>

Does this need an audit? Or was that included in the security review by Labs?

Also, it would be helpful if a Labs representative can confirm when a contributor team goes through a step like a collaborative security review. Just as a standard process going forward.

---

<div class="post-metadata">

**Author:** ![maurelian](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/maurelian/32/9353_2.png) [@maurelian](https://gov.optimism.io/u/maurelian)\
**Post date:** [January 9, 2024, 3:35pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/4 "2024-01-09T15:35:26Z")

</div>

Hi good question!

Per the rationale outlined [here](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864), we do not believe an audit is warranted for this change.

We worked with Test in Prod on Failure Modes Analysis (FMA), which outlined the various risks posed by the changes, identifies mitigations, and ensures we have a plan for recovery in the event of each failure mode.

---

<div class="post-metadata">

**Author:** ![katie](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/katie/32/5184_2.png) [@katie](https://gov.optimism.io/u/katie)\
**Post date:** [January 9, 2024, 6:36pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/5 "2024-01-09T18:36:32Z")

</div>

**I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments/235/18) with sufficient voting power and I believe this proposal is ready to move to a vote.**

---

<div class="post-metadata">

**Author:** ![Gonna.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gonna.eth/32/3379_2.png) [@Gonna.eth](https://gov.optimism.io/u/Gonna.eth)\
**Post date:** [January 9, 2024, 7:01pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/6 "2024-01-09T19:01:45Z")

</div>

**I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments-old/235/2) with sufficient voting power and I believe this proposal is ready to move to a vote.**

---

<div class="post-metadata">

**Author:** ![Joxes](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/joxes/32/5814_2.png) [@Joxes](https://gov.optimism.io/u/Joxes)\
**Post date:** [January 9, 2024, 9:26pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/7 "2024-01-09T21:26:55Z")

</div>

Hey! It’s great to see this proposal posted in the forum.

> [@testinprod\_io](#):
>
> 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.

For now, I have a quick question about this sentence, _in the worst case, some transactions could be omitted_: is this when the proposer generates and posts a new state root, right? The proposer would just ignore the batch -or a portion of it-?. Is this the case, or are we talking about another situation in particular?

---

<div class="post-metadata">

**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:** [January 9, 2024, 9:42pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/8 "2024-01-09T21:42:45Z")

</div>

> [@maurelian](#):
>
> Per the rationale outlined [here](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864), we do not believe an audit is warranted for this change.

Ok, we’re ready to see this get a vote. Yes, we’re a delegate with sufficient voting power.

---

<div class="post-metadata">

**Author:** ![testinprod\_io](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/testinprod_io/32/7749_2.png) [@testinprod\_io](https://gov.optimism.io/u/testinprod_io)\
**Post date:** [January 10, 2024, 7:16am UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/9 "2024-01-10T07:16:27Z")

</div>

Hi Joxes! Thanks for the question.

> [@Joxes](#):
>
> is this when the proposer generates and posts a new state root, right?

No. This case refers to when the op-batcher has an unexpected bug where it omits some transactions.

> [@Joxes](#):
>
> The proposer would just ignore the batch -or a portion of it-?.

The proposer cannot omit any portion of the batch.

Let us know if you have any more questions!

---

<div class="post-metadata">

**Author:** ![Joxes](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/joxes/32/5814_2.png) [@Joxes](https://gov.optimism.io/u/Joxes)\
**Post date:** [January 10, 2024, 2:11pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/10 "2024-01-10T14:11:59Z")

</div>

@testinprod_io Thank you!

> [@testinprod\_io](#):
>
> This case refers to when the op-batcher has an unexpected bug where it omits some transactions.

I see; I want to make sure I understand the worst case impact on users and services. So, in this case, does the sequencer provide the confirmation, but the batcher not include the actual tx in the batch?

Thank you again.

---

<div class="post-metadata">

**Author:** ![mastermojo](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/mastermojo/32/1178_2.png) [@mastermojo](https://gov.optimism.io/u/mastermojo)\
**Post date:** [January 10, 2024, 3:59pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/11 "2024-01-10T15:59:14Z")

</div>

I am one of the Synthetix Ambassadors, and a Optimism Badgeholder. I am an Optimism delegate [[Delegate Commitments - #65 by mastermojo](https://gov.optimism.io/t/delegate-commitments/235/65)] with sufficient voting power, and I believe this proposal is ready to move to a vote.

---

<div class="post-metadata">

**Author:** ![testinprod\_io](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/testinprod_io/32/7749_2.png) [@testinprod\_io](https://gov.optimism.io/u/testinprod_io)\
**Post date:** [January 10, 2024, 4:34pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/12 "2024-01-10T16:34:18Z")

</div>

> [@Joxes](#):
>
> So, in this case, does the sequencer provide the confirmation, but the batcher not include the actual tx in the batch?

Yes. That is correct.

> [@Joxes](#):
>
> I want to make sure I understand the worst case impact on users and services.

The worst-case impact on users & services is the L1-confirmed block reorgs (safe block), which are triggered by various situations–for example, when the batcher omits a transaction.

It won’t halt the sequencer’s pre-confirmed block progression. That’s why we expect end users to be less likely to be impacted in the majority of failure scenarios.

Please let us know if you have any more questions! Happy to answer 🙂

---

<div class="post-metadata">

**Author:** ![Joxes](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/joxes/32/5814_2.png) [@Joxes](https://gov.optimism.io/u/Joxes)\
**Post date:** [January 10, 2024, 4:41pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/13 "2024-01-10T16:41:22Z")

</div>

Thank you for clarifying @testinprod_io. I will come with more questions if necessary.

I am an [Optimism delegate](https://vote.optimism.io/delegate/joxes.eth) with sufficient voting power and I believe this proposal is ready to move to a vote.

---

<div class="post-metadata">

**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:** [January 10, 2024, 4:43pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/14 "2024-01-10T16:43:10Z")

</div>

I am an Optimism [delegate](https://gov.optimism.io/t/pgov-delegate-communication-thread/6059) with sufficient voting power and I believe this proposal is ready to move to a vote.

---

<div class="post-metadata">

**Author:** ![testinprod\_io](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/testinprod_io/32/7749_2.png) [@testinprod\_io](https://gov.optimism.io/u/testinprod_io)\
**Post date:** [January 10, 2024, 6:02pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/15 "2024-01-10T18:02:12Z")

</div>

> [@testinprod\_io](#):
>
> L1-confirmed block reorgs (safe block),

Correction: it’s a Sequencer’s pre-confirmed blocks reorgs—unsafe head.

---

<div class="post-metadata">

**Author:** ![0x666](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/0x666/32/3327_2.png) [@0x666](https://gov.optimism.io/u/0x666)\
**Post date:** [January 18, 2024, 12:16pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/16 "2024-01-18T12:16:03Z")

</div>

when can delta upgrade apply to OP Mainnet after vote passed?PGN is going to close their network,hope we can push this to PGN before the close

---

<div class="post-metadata">

**Author:** ![testinprod\_io](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/testinprod_io/32/7749_2.png) [@testinprod\_io](https://gov.optimism.io/u/testinprod_io)\
**Post date:** [January 19, 2024, 9:39am UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/17 "2024-01-19T09:39:25Z")

</div>

Hello! We are proposing the Mainnet activation at **00:00:00, Feb 22, 2024 UTC.**

> [@testinprod\_io](#):
>
> (Proposed) Mainnet activation at 00:00:00, Feb 22, 2024 UTC.

---

<div class="post-metadata">

**Author:** ![kutubu](https://avatars.discourse-cdn.com/v4/letter/k/50afbb/32.png) [@kutubu](https://gov.optimism.io/u/kutubu)\
**Post date:** [January 23, 2024, 2:01pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/18 "2024-01-23T14:01:43Z")

</div>

Lots of technical jargons, but this is a clean run-down proposal. Sad I am not a delegate with no voting right for now, but I love it.

---

<div class="post-metadata">

**Author:** ![Joxes](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/joxes/32/5814_2.png) [@Joxes](https://gov.optimism.io/u/Joxes)\
**Post date:** [January 23, 2024, 2:12pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/19 "2024-01-23T14:12:42Z")

</div>

Voting FOR this proposal.

The presented information and worst-case scenarios explained in the proposal indicate that the implementation is ready for going forward.

As always, we encourage any consideration that may arise before the implementation to be promptly communicated.

---

<div class="post-metadata">

**Author:** ![linda](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/linda/32/187_2.png) [@linda](https://gov.optimism.io/u/linda)\
**Post date:** [January 23, 2024, 5:22pm UTC](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310/20 "2024-01-23T17:22:13Z")

</div>

Voting for this proposal after getting technical input from my Scalar colleague Jordan.

[Next page](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310.md?page=2)
