Proposal: Euclid Upgrade

Proposals
1

Introduction

The purpose of this proposal is to follow-up on previous draft and inform the Scroll DAO of a proposed protocol upgrade, and to allow projects, users, and devs to prepare in advance. Please follow Telegram: View @scroll_tech_announcements for upcoming upgrade and maintenance announcements.

Executive Summary

We propose the Euclid upgrade to be considered for inclusion and execution during the April 2025 governance cycle. This is the latest upgrade since Darwin, and the biggest upgrade since Scroll launched its mainnet.

Euclid contains five main changes:

  • Migration to OpenVM Prover.
  • Migration to MPT state commitment.
  • Optimized rollup process.
  • EIP-7702 and RIP-7212 support.
  • Stage-1 readiness.

These changes will result in lower fees, higher throughput, better security, better compatibility, and more advanced features that users and developers on Scroll can enjoy.

Features

The Euclid network upgrade activates the following features.

OpenVM Prover

Scroll has been among the pioneers of ZK technology through our EVM bytecode compatible halo2 zkEVM. ZK technology has continued to progress rapidly ever since, and now general-purpose RISC-V zkVMs are becoming practical. In the Euclid upgrade we are deprecating our halo2 circuits in favor of a new prover built on top of OpenVM.

The new OpenVM prover offers numerous benefits: Prover code is easier to reason about and to audit. We can better reuse code among different components. We can also reduce proving costs and latency. Finally, the new prover will enable us to prove arbitrarily complex transactions, allowing us to remove the circuit capacity checker module that has been a major bottleneck on sequencer throughput.

MPT State Commitment

Scroll currently uses a zk-friendly state commitment data structure called zktrie. With the new OpenVM prover, it is now practical to prove Ethereum’s state structure: the Merkle-Patricia Trie, also known as MPT. Scroll is now deprecating the zktrie and adopting MPT.

MPT unlocks better sequencer performance and offers better compatibility for dapps relying on L2 state proofs.

Optimized Rollup Process

In Euclid, we are rolling out a series of optimizations to the rollup process. These result in major reductions in Data Availability (DA) overhead, and ultimately lower fees for users. The main optimizations are:

  • Move blob verification from contract code to zk circuits.
  • Amortize message queue commitment cost.
  • Move L2 block header data from calldata to blobs.
  • Commit multiple blobs in a single transaction.

These changes combined are estimated to reduce batch commitment costs by up to 90%.

In addition, Scroll L2 nodes will deprecate Clique (the current Proof-of-Authority consensus) and will start reading the authorized unsafe block signer from the new SystemConfig contract on L1.

Powerful Smart Accounts

In Euclid, Scroll is adopting EIP-7702 and RIP-7212. Adopting 7702 in parallel with Ethereum’s Pectra upgrade ensures that Scroll maintains a high degree of compatibility with Ethereum. These features will also allow Scroll users and developers to tap into the latest technologies in smart accounts: Users can add smart contract functionalities to their accounts, use passkeys for signing authorizations, and benefit from the emerging UX improvements that these new standards will bring.

Stage-1

In Euclid, we are rolling out important safety guarantees, that will allow Scroll to reach Stage-1 based on the standard defined by L2BEAT.

  • Enforced transaction inclusion is a censorship resistance mechanism. It allows users to enqueue a transaction directly from Ethereum, forcing the sequencer to include it.
  • Permissionless batch submission is a mechanism to prevent liveness failure. In the unlikely scenario that the Scroll sequencer stops posting or finalizing batches for an extended period of time, this mechanism allows anyone to step up and start posting and finalizing batches.

Both mechanisms force the Scroll sequencer to do its job. As such, they serve as deterrents, and they offer important safety guarantees to the users.

We have also recently transferred control to the Security Council, an independent body of 12 reputable members, forming a 9/12 multisig. The Euclid upgrade will be the first upgrade to be executed by the Security Council.

Upgrade Timeline

If the proposal passes, the upgrade will be rolled out in two phases. The planned timeline is as follows:

  1. April 1st: Submit upgrade to governance proposal.
  2. April 4th: Governance voting begins.
  3. April 11th: Governance voting ends.
  4. April 12th: Security council signs the transaction for Phase 1 and Phase 2 upgrades according to the voting result.
  5. April 16th at 15:00:00 UTC: Phase 1 transition occurs, consisting of the OpenVM Migration and MPT Migration features. Following is the commit hash of each module after transition:
    1. Contract: scroll-contracts repo at 76e5df4f9b176a91319d0040199c2da45b57fb90.
    2. Node: l2geth repo at v5.8.33.
    3. Circuit: zkvm-prover repo at v0.2.0.
  6. April 17th at 15:00:00 UTC: Security council completes verification of the non-standard state transition from zktrie state root to MPT state root. The security council signs the finalization transaction, concluding Phase 1 migration. Scroll will continue to operate as before, but finalization will occur using the new OpenVM-based zk provers.
  7. April 22nd at 07:00:00 UTC: Phase 2 transition occurs, consisting of the Optimized Rollup Process, Smart Accounts, and Stage-1 features. Following is the commit hash of each module after transition:
    1. Contract: scroll-contracts repo at 8e6a02b120d3a997f7c8e948b62bfb0e5b3ac185.
    2. Node: l2geth repo at v5.8.33.
    3. Circuit: zkvm-prover repo at v0.2.0.

Security Considerations

This section covers security audits and tests conducted for the Euclid upgrade.

Testing

The following tests were conducted to ensure a smooth upgrade:

  1. Local Devnet Transition Test: Tests the transition in a controlled environment to ensure stability.
  2. Mainnet Backtest: Historical Mainnet blocks are fed into the Euclid environment to verify that the new circuits function correctly on existing Mainnet blocks.
  3. Testnet without Proving: A local test environment that checks whether protocol components (without proving) interact as expected.
  4. Devnet Test: Tests the interaction of most components in a Devnet environment, including proof generation and the execution of new features.
  5. Sepolia Test: The upgrade has already been activated on the Sepolia Testnet on March 13th.

Audit Report

Three separate audits were conducted for the Euclid upgrade:

  • OpenVM Core Module Audit: The audit was conducted by Cantina and Axiom independently. The audit and fix report from both parties are available here.
  • OpenVM Integration and MPT Migration Scripts Audit: The audit was conducted by Trail of Bits. The letter of attestation indicating audit findings and fixes is available here. Trail of Bits is preparing the full report and will be shared when ready.
  • Remaining Features Audit: The remaining features in the Euclid upgrade, including enforced transactions, enforced batches, L1 commit cost reduction, were audited by Trail of Bits. The letter of attestation indicating audit findings and fixes is available here. Trail of Bits is preparing the full report and will be shared when ready.

Impact on Users

Euclid will bring numerous benefits to Scroll users:

  • DA costs will be reduced by 80% or more.
  • Peak throughput will be improved by 4x or more.
  • Users can enjoy new wallet features that are unlocked by the smart account standards.
  • Users will have robust security guarantees through Stage-1 readiness.

However, users should expect a slightly degraded experience during the upgrade. This will last between a few hours and one day, and will entail the following:

  • During phase-1, batch finalization is expected to be delayed by several hours. Users should expect increased withdrawal times.
  • During phase-2, Scroll will migrate to a new message queue contract. As a result, we expect slightly increased delays when depositing funds to Scroll.

Impact on Node Operators

For Euclid phase-1 (MPT Migration), node operators should migrate to the new MPT version of l2geth. This requires a full resync (from network or from snapshot). We will provide a node release and snapshots later.

Zktrie nodes will continue to operate, but they will stop verifying state roots on the received block headers. We encourage node operators to migrate to mpt nodes shortly before Euclid.

In addition, node operators need to be aware of stage-1 (permissionless batches). While this mechanism will most likely not be triggered in practice, if it is, it will require manual steps to recover the nodes. We will provide detailed documentation about this in our next node release notes.

To node operators, please watch Releases · scroll-tech/go-ethereum · GitHub for the releases and follow Telegram: View @scroll_tech_announcements for the upgrade and maintenance notice.

Impact on Indexers and Dapps

Projects that need guidance to prepare for Euclid are encouraged to open a ticket on Discord with their questions.

During Euclid phase-1, we switch to a new state commitment data structure. Any dapp on Scroll that relies on zktrie proofs must migrate to MPT proofs. The batch versions used in phase-1 will be v5 and v6 (identical format to the previous v4 batches).

Euclid phase-2 brings major changes to how we commit batches:

  • Batch headers and blob payload will use a new encoding. The batch versions used in phase-2 will be v7.

  • Commit batch calldata will no longer contain block headers. Projects that need this information from L1 must fetch and decode the blob.

  • Previously, one CommitBatch event would correspond to one commit transaction that carried a single blob. After Euclid phase-2, a single commit transaction can carry multiple batches. This means that indexers should be able to process multiple batches from the same L1 transaction. We maintain the 1 batch = 1 blob semantics and emit a CommitBatch event for each batch.

  • In permissionless batch mode, the batch submitter commits and finalizes a single batch in a single atomic step through the newly added commitAndFinalizeBatch function. While this will be rare in practice, indexers should prepare to handle this case.

  • Function signatures will change for commit, finalize, and revert batch. Projects that decode transaction calldata should add support for the new signatures. See the contract changes for the detailed function signatures.

    Pre-Euclid-phase-2: commitBatchWithBlobProof, finalizeBundleWithProof, revertBatch

    Post-Euclid-phase-2: commitBatches, finalizeBundlePostEuclidV2, commitAndFinalizeBatch, revertBatch (new).

  • The committedBatches array in the ScrollChain will become sparse: Only the last batch hash from each commit batch transaction will be stored in the contract state.

  • We will migrate to a new message queue contract (L1MessageQueueV2) that will store messages by a different (rolling) hash.

In addition, L2 unsafe blocks will no longer include a signature or vanity tag in the ExtraData field.

Resources:

5 Likes
2

Hello Scroll community,

Congrats to everyone who contributed to the Euclid upgrade. We’ve reviewed the proposal and the Recent Q&A. We fully support the proposal and are excited to see it move forward.

Best regards,

Crisgarner
Ethereum Tegucigalpa

1 Like
3

Thanks for sharing Roy. The Foundation is keen to endorse this proposal and is excited to see the upgrade happen.

4

Just to clarify, as it stands, the audit reports are not ready – does this mean we don’t yet know the outcome of the audit? If so, we would prefer for everything on the audit side to be finalized and presented to the DAO before this proposal goes to a vote.

Otherwise, looking at the proposed upgrades and the benefits for users, nodes, etc., it is highly welcome and we appreciate the effort that the core team has put into this.

2 Likes
5

Hi @Chris_Areta. If I’m not mistaken, the audit results should be finalized in the next few days. The engineering team didn’t want to wait for that to post the proposal as it would not be ideal to delay the upgrades once the audit clears

6

Agree on this point. It looks like the audit results are forthcoming. It would be good to have the outcome of those before moving forward

Do you feel there has been ample preparation in working with the node operators leading up to this? It would be good to ensure they have the necessary documentation for migration well ahead of the deployment

Do you feel there has been ample testing to this end? Specifically dapps relying on state proofs when transitioning from zktrie to MPT with backwards compatibility.

Thanks for surfacing this @eugene … exciting to see the progress!

1 Like
7

First of all, well done to Peter, as both the forum post and his presentation were easy to follow and quite comprehensive. We’re in line with this upgrade, which hands down comes to solve matters that will definitely help Scroll become more attractive for its users.

As mentioned during the call, reducing DA costs by up to 80% and improving Scroll’s throughput by 4x will tackle transaction costs, something that every user will always welcome. In the same vein, having the Stage-1 badge is not just something that looks nice, but also gives users the possibility to bypass a failing sequencer and keep the network running even if the sequencer has problems. This will definitely position Scroll a step closer to reaching its maturity while it gives users extra assurance.

Moving to an OpenVM Prover and MPT state commitment will increase Scroll’s compatibility and auditability and, while these changes might not have as much impact for day-to-day users, they are in line with taking Scroll to the next level. Lastly, we agree with the two-phase implementation approach, which is cautious enough to gradually let everyone adapt to these big changes that Scroll will face soon. Also we look forward to the discussion about the future of data publication for Scroll and having more details about the hybrid model combining transaction data and state diffs mentioned during the upgrade presentation.

All in all, and logically tied to the audit results, as verified delegates we believe this proposal is ready for a vote.

2 Likes
8

Glad to see this upgrade in progress, thanks @roylou . I look forward to the audit results as other delegates have already pointed out.

As a general comment on delegates who are commenting here, do we know the depth of technical expertise everyone has? Maybe its worth considering a neutral third party similar to optimism technical advisory board to review such important technical upgrades and provide comments which can be easily absorbed by non-technical delegates and help them in making their decisions.

3 Likes
9

Nice. sounds like a good approach.

10

The audit for both phases has been concluded and we has submitted the fixes. I have amended the original post with attestation letter to indicate the findings. Trail of Bits is preparing another letter including fixes in the next few days and I will amend when available.

The full report will take another week due to Trail of Bits’ proofreading process.

We have done the following to prepare for node operators:

  1. 7 days before the Sepolia upgrade, we shared the upgrade note to partners.
  2. The Sepolia testnet was successfully upgraded with Euclide on the week of March 11th. See telegram messages.
  3. For Mainnet upgrade we will notify operators on the week of March 31st to give them more than 7 days for preparation.

During the development stage, we have discussed with a few dapps partners. Most dapps don’t check the continuity of state proofs. Will notify again on the week of Mar 31st before Mainnet upgrade.

5 Likes
11

Excellent responses thanks for this @roylou. Its sounds like the team thought through these considerations and planned accordingly!

2 Likes
12

Just a heads up, this proposal will go live on Agora for the Apr voting cycle. Let us know if you have any questions / concerns for now. Thanks!