[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 9075. 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.