Upgrade Proposal #9: Fjord Network Upgrade

Technical Proposals 📃 Protocol Upgrade
1

Executive Summary

Hi I’m Roberto, an engineer at Coinbase working on the Base blockchain, and a core developer of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Dragan Zurzin from the OP labs team.

Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation.

This is a proposal for the Fjord network upgrade, which includes the EIP-7212 precompile to reduce gas costs of many smart wallet applications, supports Brotli batch compression for ~5-15% lower data availability costs, and improves the robustness of L1 data pricing. The upgrade also increases and hardcodes the max-sequencer-drift parameter, giving chain operators more time to respond to L1 node issues without facing a potential L2 chain halt.

Specifications

Technical Specification

We propose the Fjord network upgrade (spec overview), which activates:

  • RIP-7212: Precompile for secp256r1 Curve Support (spec)
  • Brotli as a channel compression option (spec)
  • FastLZ based L1 data availability cost calculation (spec), including an upgraded GasPriceOracle L2 predeploy to compute it (spec).
  • Parameter changes:
    • Max sequencer drift becomes a constant with value increased to 1800 seconds (spec)
    • Increased values for MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE (spec)
  • The Fjord hardfork activation block, which includes several transactions to perform all L2 contract deployments, upgrades, enablements, and proxy updates. (spec)

The upgrade also updates and deprecates:

  • getL1GasUsed method of the GasPriceOracle contract (spec)
  • L1GasUsed field of the transaction receipt (spec)

Security Considerations

Consistent with the OP Labs Audit Framework, we did not have the contents of Fjord audited; however, Coinbase and OP Labs engineers did perform a security review of these changes.

The Fjord upgrade’s inclusion of EIP-7212 involves use of the reference implementation that is already live on other blockchains, which we consider low risk.

Brotli compression is also a low-risk change since it is already used by other L2s and was evaluated for both its runtime performance and compression improvements across four different OP-stack chains. It’s usage is also optional and must be activated by the chain operator after the upgrade in order to be applied.

The introduction of the new L1 data fee cost function required updates to the GasPriceOracle L2 predeploy, and changes op-geth to compute the fee values. The contract extension allows developers to continue using the GasPriceOracle to compute the data fee, and affects only helper functions that are outside of consensus. We extensively evaluated the accuracy of this new function compared to multiple variants as well as the previous one across various timeslices of OP mainnet and Base mainnet transactions (analysis repo). The new function consistently produced significant improvements in mean-squared-error and mean-absolute-error across each, and we were unable to find any instances where the new function could wildly diverge from ground truth. (We computed ground truth by putting the transaction in a simulated batch, compressing the entire batch with Brotli-10, and returning the number of bytes occupied by the transaction in the result.) Bugs in the op-geth computation might still lead to 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. Overall we feel this change remains low risk.

Similar to the previous upgrade, Fjord uses a special upgrade block to perform the contract deployment and activation 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. Since this approach to automating the upgrade has been used successfully in the past, we consider this low risk.

Security considerations for the parameter changes are discussed in the upgrade specification here and here. These changes are also straightforward and we consider them low risk.

Impact Summary

We do not anticipate any downtime due to this upgrade.

Bringing EIP-7212 to the OP stack will benefit applications such as smart wallets that want to support many common authentication methods (such as Apple’s FaceID) that would otherwise be too gas intensive.

We evaluated Brotli compression compared to the previous compression algorithm (zlib) on 4 OP stack chains (OP mainnet, Base, Zora, and Mode) and found compression ratio improvements ranging from 5-15% under Brotli quality level 10. This will directly translate to a 5-15% reduction in L1 data availability costs, so we expect most chains will want to activate this feature immediately following the upgrade.

The FastLZ based L1 data fee function will more accurately charge for L1 data usage on a per transaction basis. Previously, highly incompressible transactions might be undercharged for L1 data usage, and a large number of such transactions might lead to an inability to recover revenue without the chain operator having to take action by re-tuning fee parameters. We expect this new function to far more accurately detect the (lack of) compressibility of each individual transaction and reduce the chance of revenue recovery drifting from its intended target.

The main impact of the parameter changes is that chain operators will have more time to respond to L1 node outage issues before the L2 chain stalls (30 minutes instead of 10 minutes).

Action Plan for this release

If this vote passes, the Fjord upgrade will be scheduled for execution on July 10th at 16:00:01 UTC. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Fjord is code complete in the optimism monorepo at commit f8143c8cbc4cc0c83922c53f17a1e47280673485 and op-geth at commit 7c2819836018bfe0ca07c4e4955754834ffad4e0. The op-node release v1.7.7 and op-geth release v1.101315.2 contain these changes.

This upgrade has already been activated on internal devnets and the Sepolia Superchain in coordination with Base and Conduit.

Fault Proofs Update

This is the first protocol upgrade that will activate on mainnet following the launch of Fault Proofs, which has recently been accepted by governance. However, its version of the op-program and Fault Dispute Game doesn’t contain the Fjord mainnet activation yet, so we need to perform an update of the Fault Proofs L1 infrastructure before the Fjord activation on mainnet. This is the first time that we need to perform this exercise.

This update involves a new release of the op-program (v1.2.0) that contains the Fjord activation and generate the so-called absolute pre-state for it, which is a commitment to the program and its starting state. It also requires deploying new FaultDisputeGame and PerimissionedDisputeGame contracts to L1 Mainnet with the new op-program pre-state hash. These are deployed at addresses 0xf691F8A6d908B58C534B624cF16495b491E633BA and 0xc307e93a7c530a184c98eade4545a412b857b62f respectively. After the veto period has ended, we will ask the Security Council to sign transactions to update the DisputeGameFactory to begin using these new contract implementations. This transaction has to be executed before the actual Fjord activation to avoid a broken Fault Proofs system after the activation.

Emergency Cancellation

The optimistic mainnet releases will contain a Fjord activation at the above mentioned time. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. We have included functionality for node operators to quickly react by using the --override.fjord flag on both op-node & op-geth.

Conclusion

This proposal outlines the network upgrade after Ecotone titled Fjord. This network upgrade brings reduced execution fees for certain (e.g. smart wallet) applications, lower data availability costs, and more robust L1 data pricing. We expect that this upgrade will not result in any downtime and will occur on Wednesday, July 10 2024 at 16:00:01 UTC.

28 Likes
2

Great progress, congrats!

I think it’s better to mention RIP-7212 and its spec for the r1 precompile as EIP-7212 is outdated while the RIP spec is implemented in the Fjord.

8 Likes
3

Hello. :wave: I am a new Optimism delegate and believe this proposal is ready to move towards a vote.

This is a proposal for the Fjord network upgrade, which includes the EIP-7212 precompile to reduce gas costs of many smart wallet applications, supports Brotli batch compression for ~5-15% lower data availability costs, and improves the robustness of L1 data pricing. The upgrade also increases and hardcodes the max-sequencer-drift parameter, giving chain operators more time to respond to L1 node issues without facing a potential L2 chain halt.

Super excited about this; a big level-up for the Superchain! :+1:

If this vote passes, the Fjord upgrade will be scheduled for execution on July 10th at 16:00:01 UTC.

This gives node operators plenty of time to upgrade and let them know, and also to be able to seek support should they encounter any issues or have questions.

3 Likes
4

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
5

Need more time to better understand but thanks for your work. Best to all!

1 Like
6

Excellent point, fixed.

2 Likes
7

One suggestion from someone with less technical knowledge: even if it’s a low-risk change and external audit was not requested as per OP Lab Audit Framework, would it be possible to show different test runs and their outputs? Internal or peer reviewed document ? Assuming i am not asking anything confidential. I am also assuming there might be something similar in the analysis repo attached, but without direction, it’s hard to navigate. This makes decision-making hard from a non-technical delegate standpoint.

Out of interest, I have been following EIP-7212. This helped me understand the change and associated risks, and I’m happy to see it coming live. For other points, here is the parent link of EIP if anyone wants to read: EIP-7212 Precompiled for SECP256R1 Curve Support.

Both links point to the same page:

As OP Stack evolves and governance matures, we, as delegates, have some responsibility. When approving, I want to be sure my decision is based on information rather than assumption at the same time I don’t want to request something unnecessary, leading to additional bureaucracy and work hour.

Sharing so that other delegate could share their feedback.

4 Likes
8

GM

@wbnns Welcome! Glad to have you here. Currently, only delegates within the Top 100 can approve this kind of proposal. You can check the full process in the operating manual. Let me know if you have any questions.

@bayardo I don’t know if you’re planning to join our call tomorrow at 18:00, but I would love to hear more about Fjord. It’s a great opportunity for Q&A. cc.@Michael

Thank you!

1 Like
9

Yes we will be having a Fjord AMA on tomorrows call! @brichis

1 Like
10

Hey Michael, would love to join the AMA as well. Where will it be held? Are you able to share the details on the AMA?

4 Likes
11

It will take place during the Token House community call tomorrow at 2pm EST
https://meet.google.com/vme-ovto-jcn.

@wbnns

6 Likes
12

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

3 Likes
13

I love to see that. RIP-7212 is the new milestone for better gas optimizing lfgg

2 Likes
14

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

2 Likes
15

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

4 Likes
16

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

2 Likes
17

On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:

The Fjord upgrade packages together five changes that are somewhat related, but can be considered separately for simplicity.

1) secp256r1 Precompile

Your phone actually has its own private key. It’s hardcoded in there and is inaccessible, except when you present biometric data like a thumbprint or FaceID. If it was on the secp256k1 curve, your phone would be able to have a built in Ethereum wallet.

But it’s on a different cryptographic curve called secp256r1. That means that if your phone signs something with its private key, it’s not an Ethereum signature. It can’t send a transaction on chain. But it can be verified on chain that it was your phone that signed it! It would just cost a lot of gas to do it.

This upgrade implements a precompile contract at the address 0x0000000000000000000000000000000000000100. This contract allows users to send a hash, a signature, and a public key. It will return whether the signature is valid or invalid, and it uses a lot less gas than it would otherwise take.

This will make it possible to cheaply create “smart accounts” that are controlled by your phone, and adds no risk to the core protocol’s signature scheme, which remains unchanged.

(Note: The secp256r1 curve is used by more than just phones. Check out the RIP-7212 proposal for more examples of use cases this unlocks. The phone is just one example.)

Brotli for Compression

The Optimism sequencer posts all the L2 transactions to a blob on Ethereum, which is read by nodes to rerun the transactions to reconstruct the state.

The more we can compress those transactions, the cheaper the blob cost (which makes up the majority of L2 transaction cost) will be.

This upgrade switches from the previous compression algorithm to Brotli (a data compression algorithm developed by Google), which reduces the amount of data we need to post by 5-15%. This means the L1 portion of the gas cost will be reduced by 5-15%, meaning cheaper transactions.

L1 Gas Cost Estimates

When you pay for an L2 transaction, part of the cost comes from the sequencer estimating the cost of posting your data to L1 as a part of the blob (like described above) and including that in your transaction cost.

Previous estimates were not completely accurate, because they were not able to estimate exactly how much compression would be possible. This meant that users might over or under pay for their actual data usage.

This upgrade implements a new estimate function. It was tested on historical data and found to provide better estimates than the previous algorithm, and to never diverge substantially from the correct estimate.

Increase Sequencer Drift

If the sequencer loses its connection with L1, it would ideally continue to produce blocks until it regains the connection.

There is a protocol variable called “max sequencer drift” that determines how long the L2 can continue to produce blocks based on an old L1 origin. After this point, the L2 can no longer produce blocks.

This upgrade increases this value from 10 minutes up to 30 minutes to add more flexibility, based on the unanimous agreement of chain operators.

Increase Max Batch Size

As discussed earlier, L2 transaction data is posted to L1. This is done in “channels”, which can group together multiple L2 blocks. However, we can’t split a single L2 block across multiple channels — it needs to fit within one.

The maximum channel size is 10mb. That is more than enough for any normal circumstances, but if an OP Stack chain allowed a gas limit of more than 40mm (as opposed to Optimism’s 30mm), a block could theoretically be filled with one transaction with more than 10 million zeros.

This would exceed the 10mb limit, would not be able to be added to a channel, and therefore would fail to be posted on L1 to progress the chain.

This upgrade increases the limit to 100mb, so there is no risk of such a block unless a chain increases their gas limit over 400mm (which is currently far outside the normal range).

All of these changes appear to be logical, well tested, improvements to the OP Stack, and don’t seem to create any new risks in the core chain or bridge logic.

15 Likes
18

As part of the Path to Open Metagovernance, we’re experimenting with polls to collect more community input.

Was this non-technical summary useful?

Please provide any additional feedback in the comments below

This summary was effective at explaining the contents of the proposal
  • 1
  • 2
  • 3
  • 4
  • 5
0 voters
This summary influenced my confidence in voting on the proposal
  • 1
  • 2
  • 3
  • 4
  • 5
0 voters
  • I still do not understand this proposal
0 voters
2 Likes
19

This is a rationale on behalf of the @SEEDGov delegation, as we have communicated here.

@bayardo, thank you for sharing your perspective on this network upgrade. We highly appreciate your insights, along with the @zachobront non-technical summary. The review you provided is quite detailed.

After commenting on this upgrade with @Joxes and the SEED Latam delegation, we are thrilled by its versatility, efficiency, and resilience. From expanding the possibility of signing from any device to its significant impact on Data Availability and protocol-level efficiency, the Fjord upgrade brings a lot to the network.

However, what is the rationale behind moving from 10 to 30 minutes for the Sequencer drift? Can you explain how the chain operators reached this unanimous decision? Is the time extension related to the expectation of frequent syncing failures between the Sequencer and the L1, or is it due to increased resilience in the time to respond during these events?

Once again, thank you for your valuable insights about this network upgrade

5 Likes
20

@habacuc.eth The primary motivation of increasing the maximum seqeuencer drift value is because of past incidents in which L1 node issues have led to L2 unsafe head chain halts. (Unsafe chain halts are the most user-disruptive type, since transactions won’t clear the transaction pool until the chain restarts).

With a 10 minute sequencer drift, chain operators have at most 10 minutes to respond to a non-responsive L1 before unsafe chain halt. In our experience it has not been possible to react quickly enough to prevent this. The sequencer drift parameter sets a maximum bound on the time the L2 chain’s knowledge of L1 “attributes” (such as L1 gas price) is out of date. Because L1 attributes like gas price are designed not to fluctuate wildly in short time periods, and situations where we must rely on a larger drift will be rare, the consensus was the downsides of such an increase were small and well worth the added safety it provides against unsafe chain halt.

I should add that ideally chain operators should have significant L1 node redundancy so that these sorts of L1 issues never arise. However this has proven challenging in practice, hence the desire for this extra level of insurance.

As for how we reached the decision, the Base team made a request at one of our regular infrastructure meetings to increase this value, citing previous testnet incidents, and continued discussing the proposal with OP Labs engineers on our shared Slack channels. We reached consensus on 30 minutes as providing enough time for paged engineers to respond to alerts for all but the most catastrophic of incidents. The proposal was socialized on our broader shared superchain channels and OP stack infrastructure meetings without objections from the community.

7 Likes