[ZIP-10] Activate ZK Gateway as a Settlement Layer

Protocol Development Draft ZIPs
1
Title Activate ZK Gateway as a Settlement Layer
Proposal Type ZIP
One Sentence Summary: This proposal aims to whitelist ZK Gateway chain as a settlement layer for the Elastic Network, paving the way to facilitate fast interop by providing a layer for cheap batch settlement and as well as quick communication between ZK Chains.
Proposal Author Matter Labs
Proposal Sponsor: TBC
Date Created: TBC
Version v1
Summary of Action This proposal will whitelist ZK Gateway chain as a settlement layer for Elastic Network.
Link to contracts GitHub - matter-labs/era-contracts at release-v27

[ZIP-10] Activate ZK Gateway as a Settlement Layer

Abstract

ZIP-10 builds on the groundwork laid by ZIP-6 Prepare ZKsync for ZK Gateway, which shipped V26 of ZKsync.

ZIP-10 approves ZK Gateway as an optional shared settlement layer for the Elastic Network. ZK Gateway aims to enhance the efficiency of batch settlements across ZK Chains, reducing settlement costs and stabilizing pricing for users, especially for ZK Chains that do not depend on Ethereum for DA. In addition, ZK Gateway will facilitate future interopability across the Elastic Network and provide even cheaper pricing in the future, once optimized precompiles are available in the next release.

Motivation

The motivations for this proposal are:

  1. Cheaper settlement costs. When settling on top of Gateway, ZK Chains are able to utilize cheaper settlement costs for settling their batches (i.e. committing, proving and executing those), which will translate into cheaper and more stable pricing for users, particularly in future releases when precompiles are available.
  2. Future interop facilitations. As a result of the above, ZK Chains will be able to settle batches faster, allowing for faster trustless interop. Also, ZK Gateway is able to serve as a communication layer between ZK Chains, paving the way to seamless interop with additional security requirements.

Specification

ZIP-10 is a continuation of efforts started with ZIP-6. With the approval of ZIP-6, V26 was implemented on the Elastic Network. The main feature of V26 was the support of shared settlement layers for the Elastic Network. ZIP-10 does not introduce new code changes in addition to ZIP-6. Instead, ZIP-10 focuses on whitelisting the ZK Gateway chain as an optional shared settlement layer.

Here you can read more about how settlement layers as well as how the ZK Chains would be able to migrate on top of the ZK Gateway in the future.

Note, the decision to migrate on top of ZK Gateway is an optional choice which can be made by each individual ZK ChainAdmin. Also, there is always an option to opt out of using Gateway.

The ZK Gateway has been deployed as a ZK Chain, with chainID (TBD). ZK Gateway uses the ZK token as the base token and maintains the same security properties as ZKsync Era. ZK Gateway is also a permanent rollup, i.e. regardless of the actions of the ChainAdmin it will always use Ethereum as its DA layer.

For simplicity, in this release, the ZK Gateway is just a chain with the same capabilities as a standard ZK Chain. In the future, the chain can be upgraded to a more specialized version. To prevent unintended usage and to make this future migration easier, deploying of contracts inside the ZK Gateway will only be available under a whitelist.

As part of the ZIP execution, governance will complete the following actions:

  1. Call Bridgehub.registerSettlementLayer to register this chain as a valid settlement layer.
  2. Do an L1->GW transaction to whitelist a ChainTypeManager on top of Gateway to manage the ZK Chains that settle on top of it.
  3. Do the calls to Bridgehub and CTMDeploymentTracker to ensure that everything is set up to facilitate future ZK chain migrations on top of ZK Gateway.

Rationale

This upgrade introduces a new shared settlement network in an incremental way, while already providing value for ZK Chains of the Elastic Network. It will give an opportunity for ZK Chains to receive more stable batch settling pricing, while allowing prices that are much cheaper than L1 starting with a future upgrade, that will introduce more efficient cryptographic precompiles.

Reusing an existing ZK Chain architecture for a shared settlement layer allows ZK Chains to enjoy the benefits faster while relying on already battle-tested codebase that is used by all ZK Chains.

Backwards Compatibility

No backwards compatibility issues.

Security Considerations

All the existing code has been audited as a part of the previous ZIPs.

During the initial release Matter Labs will be the sole sequencer of the ZK Gateway with planned transition to a decentralized setting over time.

9 Likes
2

It’s a great step to become a rollup hub. After reading the proposal I have some questions:

  • I assume ZKsync Era and ZK Gateway will be the shared trust layers. In case of an attack on one settlement layer, is there a reliance between the settlement layers? Maybe a settlement threshold? Or do ZK Chains only have to settle on one of them?
  • Do you have statistics to compare settling on ZKsync Era and ZK Gateway?
3

ZIP-10 was discussed on the bi-weekly Proposal Review call that took place on Wednesday this week.

:link: Find call notes, links and the recording here!

4

Era will just be another L2, no different from for example Abstract, Sophon, or Lens. Each of the L2s will be independent from each other and not reliant on security of either one. Era will also be settling proofs to Gateway

Gateway would be the shared layer where proofs get aggregated and validated before settling to L1.

As for benchmarks, we are working on some more benchmarks but once we have more optimized precompiles (which are underway very very soon), Gateway will bring significant cost reductions for each of the L2s

2 Likes
5

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

We are voting FOR the proposal.

As this was a technical and not a trivial upgrade, we requested L2BEAT’s research team to review both the proposal’s outline and its calldata.

As we understand, the new ZK chain ‘Gateway’ (chainID 9075) is whitelisted as a settlement layer, allowing it to host other ZK chains, which is part of the broader ZK stack scaling/interop roadmap. In turn, it will also enable ZKsync to migrate there as an L3. Since after the proposal is executed, the chain owners could start a migration at any instant, we’d like to ask whether we could have clarity on the plans for when this should occur.

Other than that, we do not see any issue with the proposal on a high level, and we are supportive of it as it is in line with the ZKsync priorities set forward by GAP-1.

Our research team successfully verified the proposal’s calldata using cyfrin’s zkgov-check, l2beat decoder, l2b zkgovproposal and l2b fetchzkstack, finding transactions that:

  1. Register chainid 9075 as a settlement layer,
  2. Set up the ChainTypeManager contract on the new settlement layer,
  3. Prepare chain migration via BridgeHub and CTMDeploymentTracker

With all the above info in mind, we decided to vote in favor of the proposal, and we’re looking forward to when ZKsync also migrates to Gateway as an L3.