[FINAL] Upgrade Proposal #2: Canyon Network Upgrade

Technical Proposals 📃 Protocol Upgrade
1

Executive Summary

Hi I’m Joshua, an engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem, and a core developer of the OP Stack. We provide some services to, but do not represent or speak on behalf of, the Optimism Foundation.

Upgrade #2, Canyon is the first proposed network upgrade after Bedrock. Canyon contains the Shapella network upgrade from Ethereum, a change to reduce the volatility of the basefee, and several minor bug fixes. The Canyon upgrade will maintain EVM equivalence & improve the ergonomics of using the OP Stack for developers and end users. In addition, node operators will need to upgrade their nodes to stay in sync. Canyon brings the OP Stack protocol version to v4.0.0.

If this vote passes, Canyon will activate on op-mainnet, base-mainnet, pgn-mainnet, & zora-mainnet on Thu Jan 11 17:00:01 UTC 2024 (Unix Time 1704992401) barring a critical security issue. All op-node versions after v1.3.1 & all op-geth versions after v1.101304.1 are compatible with Canyon. We will release a new version of op-node & op-geth with the Canyon activation time baked in if the vote passes governance.

Specifications

Technical Specification

We are activating the following features as part of the Canyon upgrade. Full Canyon Specification in Github.

Security Considerations

Consistent with the OP Labs Audit Framework, OP Labs did not have the contents of Canyon audited; however OP Labs did perform a security review of these changes.

The Shapella L1 upgrade consists of relatively standard EVM changes & the addition of beacon chain withdrawals. OP Labs considers the EVM changes low risk because they have been active on L1 without issue. Withdrawals are a new L1 codepath to create arbitrary mints in the EVM. OP Labs has ensured that this type of transaction cannot occur on L2…

The next set of changes, EIP-1559 config change, the channel ordering change, and the receipt hash change also are low risk changes. They do not modify any code path which is responsible for securing user funds and have been tested.

The last change, the create2Deployer, presents a larger user facing change. Canyon unconditionally modifies the bytecode of the 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2 address. This address already has the create2Deployer on it on some, but not all, networks. OP Labs has validated that the contract code deployed by Canyon matches the public ABI of the existing contract. This upgrade does remove portions of the admin ABI (pausing, ownable), but OP Labs has confirmed that the contract author is ok with removing the Ownable & Pausable functionality. A typical developer would not be able to call these functions.

Impact Summary

OP Labs does not anticipate any down time due to this upgrade. This network upgrade does not contain backwards incompatible changes for end users.

Shapella is important to retain compatibility with Ethereum. One change to be aware of is the deprecation warning of the SELFDESTRUCT opcode. The behavior of the opcode is not changing in Canyon, but is expected to change in a future network upgrade. Ethereum is expected to implement EIP-6780 in the Dencun network upgrade to modify this opcode, and the Optimism community should expect to follow this change in the spirit of EVM equivalence.

The EIP-1559 Denominator will be changing from 50 to 250. OP Labs is proposing this change to decrease volatility in the basefee on the OP Stack. By increasing the denominator, the amount the basefee increases is reduced when the gas used is over the gas target. A denominator of 50 was initially chosen for Bedrock such that the basefee on the OP Stack would decrease at approximately a rate of -12% per 12s when the block were completely empty. This matches the decrease of Ethereum’s basefee. The rate of increase with completely full blocks was 77% over 12s because the gas limit on the OP Stack is 6x the gas target. Since Bedrock, 2 minutes of full congestion (30m gas blocks) on the OP Stack would result in an increased base fee of ****304x ****(1.1^60) ******vs 2 minutes of full congestion on L1 Ethereum would result in an increased base fee of 3.24x (1.125^10). OP Labs is suggesting a denominator of 250 to match the rate of increase of Ethereum when OP Stack blocks are completely full. This will also reduce how quickly the basefee decays when blocks are empty and will enable users to have their transactions included more easily during periods of high usage.

Canyon modifies the protocol to handle unclosed channels. Previously, only a single channel could be active at a time and if the channel was not closed, it would need to time out before progress could resume. Following the upgrade, the op-node will read the first channel that is ready.

A new field will be added to the deposit transaction receipt encoding. It modifies the encoding to fix a bug where the deposit transaction nonce was not in consensus encoding.

Finally, Canyon sets the create2Deployer bytecode at 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2 on all OP networks. This enables developers to have access to this commonly used contract on all OP networks, not just OP Mainnet. This also particularly helps users on Base mainnet, where, due to a deployment issue, the create2Deployer is not able to be deployed to this address. Block explorers may have to re-verify the create2Deployer contract.

Action Plan

If this vote passes, the Canyon upgrade will be schedule for execution 5 ****weeks after the vote passes, on Thu Jan 11 17:00:01 UTC 2024. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Canyon is code complete in the optimism monorepo at commit 6cce3728b7bed5e36234aeba3b773e0f97867be3 and op-geth at commit ed8e9f54ed0a5069e77ea34895ff12a9ac4ca17f. The op-node release v1.3.1 and op-geth release v1.101304.1 contain these changes. These commits do not contain the Canyon timestamp for mainnet. These releases could be used on mainnet by using the --override.canyon flag. OP Labs will release a future version of op-node & op-geth with the Canyon time configured if governance approves this upgrade.

This upgrade has already been activated on internal devnets in coordination with Base & Conduit. It successfully activated on op-goerli, op-sepolia, base-goerli, base-sepolia, pgn-sepolia, & zora-sepolia on November 14 at 17:00:00 UTC.

If there is a critical security issue, node operators will be able to disable the upgrade by using the —override.canyon flag on both op-node & op-geth. OP Labs will also collaborate with the community to extensively communicate that the upgrade is no longer happening.

OP Labs will release a new version of op-node & op-geth with the Canyon activation date baked in and publicize to node operators & end users that the Canyon upgrade will be occurring.

Conclusion

This proposal outlines the Optimism Collective’s first network upgrade after Bedrock titled Canyon. This network upgrade maintains EVM equivalence via activating the Shapella network upgrade and includes several OP Stack specific improvements.

We expect that this upgrade will not result in any down time and will occur at Thu Jan 11 17:00:01 UTC 2024.

19 Likes
2

We are a delegate with enough voting power and believe this is appropriate for a vote in the upcoming cycle.

2 Likes
3

Hello,
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
4

I am a delegate with sufficient voting weight Delegate Commitments [OLD] - #71 by MoneyManDoug I believe this proposal is ready for voting.

3 Likes
5

As a delegate with sufficient voting power, I believe this is ready to go to a vote.

2 Likes
6

Hey @trianglesphere we are thrilled at the additional level of scalability brought about by the Canyon Network Upgrade! The Lyra Chain has recently been deployed ahead of the V2 launch of the Lyra Protocol. Is it possible to include Lyra Chain in this proposal and the scheduled upgrades?

3 Likes
7

I voted for this proposal after getting a second opinion from my Scalar colleague Jordan Clifford as we didn’t see any major issues.

3 Likes
8

There is no need to go through a governance process to implement Canyon; all new Conduit chains will activate Canyon.

3 Likes
9

Awesome work team. See you on the moon🧑🏽‍🚀

Big thanks to all the core contributors who coordinated to make this happen. Drinks on us​:tea::beer::tropical_drink:

1 Like
10

We at Wildfire have voted in favour of this proposal. The upgrades that are being implemented are necessary for the sustainability of the Optimism Network. OP Labs have proven themselves to be a strong development team.

In the future it would be interesting to explore the viability of these upgrades going through a formal audit process, whether that would be worthwhile and cost-effective for the DAO and whether the benefits would outweigh the costs.

Interested in the opinions of more closely involved and/or technical contributors here! :gear:

1 Like
11

@WildfireDAO because these changes do not touch the deposits or withdrawals codepaths and touch no L1 smart contracts (and one particular L2 contract, but very minimal and unrelated to withdrawals), we feel that these changes do not need an audit. The OP Labs audit framework is described in more detail here: OP Labs Audit Framework: When to get external security review and how to prepare for it.

2 Likes
12

We believe that the Canyon update is necessary for alignment with Ethereum. The fact that the Shapella update has been live on Ethereum for a while without any issues leads us to believe that the Canyon update will not pose a threat to the network. We are also looking forward to the update that Optimism will implement following the Dencun update.

1 Like
13

The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.

After reviewing the proposal, we’ve decided to vote in its favour as there don’t seem to be any issues with the proposed changes.

2 Likes
14

I voted for this proposal as I see it as a proper step forward in the technical upgrade of the network. Not a huge fan of modifying bytecode of an existing contract but other than that all good.

1 Like