The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We are voting FOR the proposal.
Our research team verified the proposed calldata using Matter Labs’ verification tool. They sampled some of the contracts’ source code that is already deployed on L1, which was discovered using the tool and the proposed calldata. Finally, scanning the 4 OpenZeppelin audits and the docs on GitHub and putting it into a bigger context, this proposal sets the stage for the ‘Gateway’ settlement Rollup and ZK chains like Era migrating to Layer 3. To make it clear, this proposal doesn’t migrate chains like Era to Layer 3, but it’s the first step towards enabling that migration in the future.
During the review, our research team found the following things that delegates should be aware of.
1. Data Availability (DA) switching post-deployment
Right now, and before the proposed upgrade executes, ZK stack chains must choose where they post their data as soon as they create their chain. After the proposed upgrade, ZK stack chains will be able to change their DA at any time, which would instantly affect the trust assumptions.
Since ZK Rollups can only worsen their trust assumptions when changing their DA, a ‘permanent-rollup’ mode is introduced that permanently fixes the DA Layer to Ethereum for any Rollup that opts in, as ZKsync Era committed to do. The implementation in the proposal allows immediate DA changes by the local chain admin, which is incompatible with Stage 1 Rollups (see L2BEAT’s Stages Framework for reference). We therefore urge teams aiming to build a decentralized Rollup to use the ‘permanent-rollup’ mode.
2. Shared Bridge to Asset Routers and Handlers
Currently, all canonical tokens get the same contract implementations on L2 and are kept in a shared bridge on L1. The proposal splits bridging logic into a few contracts.
- Assets must specify a handler (escrow) and receive a unique token ID upon registration.
- Each chain has a central asset router contract, which now allows token owners to define a custom l2 asset handler upon registration (meaning custom l2 contracts with upgradeability, minting etc.)
- To migrate to this new asset router/handler paradigm, the L1SharedBridge on L1 is repurposed, and all assets from it are transferred to a default / canonical asset handler called L1NativeTokenVault.
- The L1SharedBridge proxy is changed to an implementation called ‘L1Nullifier’ that accounts for the assets on the different chains (e.g.
chainBalancemapping) and does not escrow any tokens.
This change will allow ZK chains to customize their tokens more, add L2 → L1 bridging for native tokens, and pave the way to a more interoperable Elastic Network. However, more customization also opens the door to bad customization and new trust assumptions from tokens that are canonically bridged but, for example, have contracts on L2 that can be changed at any time.
3. Custom Settlement Layers
This is a deep change that will not be immediately usable. It prepares the migration of chains to alternative settlement layers, allowing, e.g., the ZKsync Era L3 migration. Chain migration is coordinated by a ChainTypeManager (prev. StateTransitionManager) contract that is present on every chain that allows settlement (for example on the future ‘Gateway’ Rollup). The design allows future chains to move in the Elastic Network similarly to assets, freely choosing to be on Layer 2 or Layer 3 and on which ZK host chain.
Similarly to the DA switching mentioned above, a local chain admin can start a migration at any time, which is incompatible with Stage 1 (as defined by our Stages Framework - see above) unless done by a local SecurityCouncil.
However, at the time of writing this comment none of the ZK stack chains are Stage 1, and the Gateway deployment (first alternative settlement layer) is not part of this proposal, leaving only one settlement layer - Ethereum.
v26
The bigger picture for v26, which this proposed upgrade is just a part of, is an aggregation layer similar to Polygon’s AggLayer but kind of different since the aggregation layer will just be another ZK stack rollup. It will use a strict transactionFilterer and not be general purpose, focused on receiving data and proofs from its L3s and aggregating them to L1.
As far as we can tell and from the documentation we reviewed, the upgrade is well-presented, and the verification tool is useful. The audits are thorough, available docs are informative, and the L1 contracts are pre-deployed and verified. Regarding the upgrade itself, there are pros and cons to the proposed changes (as outlined above), but overall, we don’t see a solid reason that would compel us to vote against the proposal.
Shout-out to our research team for all their hard work going through everything to help us make an informed decision.