ZIP FAQ

Find full technical documentation for the ZKsync protocol at zksync.io.

How can a ZIP upgrade the ZKsync Protocol?

The Protocol Governor contracts (L2) have a direct link to “protocol upgrade handler” for the ZKsync protocol that is deployed on L1. The ZIP improvement proposals (ZIPs) give instructions to the protocol upgrade handler on L1, and the upgrade handler executes changes on L1 & L2 contracts.

What is included in the “core” ZKsync protocol?

• L1 contracts: a set of contracts that powers interaction with the rollup on Ethereum. (e.g. Verifier Contract)

• System contracts: a set of contracts deployed on L2 that are responsible for various protocol functions. (e.g. L1 Messenger, Default Account Contract, Storage Management Contract)

• Bootloader: Part of the execution environment in which all the transactions are executed on L2.

• Proof System

  • ZK circuits: ZK circuits generate cryptographic proofs (e.g., zk-SNARKs or zk-STARKs) that attest to the validity of batched state transitions on L2. These ensure that all operations on L2 are valid without needing to replicate the computational workload on L1. Read more here.

What is the upgrade handler?

The upgrade handler is the owner of State Transition Managers & owner of L1 shared bridge, bridge hub & other contracts (e.g USDC bridge or L2 bridge counterparts).

What is the Change Type Manager?

A Change Type Manager (CTM) is a critical component designed to handle and coordinate the execution of operations that span between Layer 1 (L1) and Layer 2 (L2). It serves as a factory to deploy ZK Chains, and it is responsible for ensuring that all the ZK Chains deployed by it are up-to-date. It ensures that all state transitions comply with the ZKsync protocol's rules and guarantees data consistency, and ensures consistency, validity, and synchronization across these layers.

All current ZK Chains are deployed to the main ZKsync CTM. However, this may change if/when the Gateway upgrade is executed.

What are the different types of state changes that a ZIP can include?

• Type 1: Protocol upgrade that does not affect ZK Chains

  • Example: Changes to Governor parameters (e.g. change voting delay from 7 days to 3 days)

• Type 2: Protocol upgrade that does affect ZK Chains, but does not require action

  • Example: Upgrading bridge functionality, Upgrading bridge functionality, adding new State Transition Managers, Adding a new ZK Chain with a custom state (e.g. ZIP-7 Lens Chain inclusion on Elastic Network)

• Type 3: Protocol upgrade that does affect ZK Chains AND requires an action from ZK Chains

  • Example: Any protocol version change (e.g. ZIP-3 Protocol Defense)

For ZIPs that do require action from ZK Chains, what does that look like?

Standard Case: If a state-change protocol upgrade to the ZKsync protocol is successfully approved via a ZIP, each individual ZK chain admin will have to upgrade to the new version by set deadline, otherwise a chain that doesn’t upgrade will not be able to commit new batches. A few examples:

• Circuit upgrade: If there is an upgrade of ZK circuits from 1.0 to 2.0, you are changing what is enshrined in L1 but also updating all parameters of ZK chains to adopt new proof generation process.

• Interop: When interop arrives and if it the upgrade passed through governance, all chains will have Interop: Interop will be introduced in the v29 protocol upgrade. If approved by the Token Assembly, ZKsync Chains who want to access interop will have to be on v29 to use it. However with later upgrades, ZKsync Chains who remain on v29 will still be able to send interop to v30+ Chains.

Defensive Case (governance force upgrade): In the case of an emergency, a protocol upgrade approved by governance may force an upgrade to a specific chain or all chains.

• Example: Emergency upgrade needed to fix circuit bug that allows bad batch to be proven even if it is not proven.

Can ZK Chains opt out of an upgrade that is approved by the passing of a ZIP?

It is possible to run an outdated version as long as it has not been disabled, but it is not recommended to be more than 1 version behind the latest version.

The dev team who proposes the ZIP should always provide clear deadlines as to when ZKsync Chains should upgrade to the latest version.

What are the exact list of params that the ZK Chain admin have control over? Can these be impacted by ZIPs?

Every ZK Chain has an admin contract known as the ChainAdmin.

The roles each ChainAdmin of a ZK Chain has can be found here

ℹ️ ZIPs currently cannot impact these parameters.