[ZIP-12] V29 Interop Messaging & Fast Finality Upgrade

Protocol Development Draft ZIPs
1
Proposal Type ZIP
One Sentence Summary: ZIP-12 proposes the V29 upgrade for ZKsync introducing two major features: Interop Messaging and Fast Finality.
Proposal Author Matter Labs
Proposal Sponsor: TBC
Date Created: TBC
Version v1
Summary of Action Upgrade ZKsync to V29.
Link to contracts GitHub - matter-labs/era-contracts at draft-v29

Abstract

ZIP-12 proposes the v29 protocol upgrade for ZKsync, introducing two major features: Interop Messaging and Fast Finality. These capabilities enable native message passing between ZK Chains and provide faster finality guarantees to third-party observers and applications, such as exchanges and bridges.

Motivation

ZKsync v29 upgrades the protocol to improve interoperability and finality for ZK Chains within the Elastic Network. It introduces:

  • Cross-chain communication: The Interop Messaging mechanism allows ZK Chains to share and store commitment roots via the ZK Gateway, enabling Merkle-proof-based verification of cross-chain messages. This enables trustless, low-fee communication between ZK Chains.

  • Fast subjective finality: The Fast Finality feature introduces sending pre-commitments of transaction execution status directly on L1, allowing ZK Chains that are connected to ZK Gateway to validate execution outcomes before ZK Gateway’s full batch finalization on L1. Fast subjective finality allows exchanges and partners to locally validate the outcome of transactions earlier in the process, reducing wait times and improving UX.

These features are critical for improving user experience, enabling seamless connectivity across the Elastic Network, and supporting exchange integrations with faster confirmation guarantees.

These improvements align with ZKsync’s mission of building a scalable, user-centric Ethereum ecosystem.

Specification

The implementation of the new protocol version can be viewed on Github.

Interop Messaging

ZKsync v29 introduces a mechanism for ZK Chains connected to ZK Gateway to communicate with each other through a shared root commitment system, which is already present in v28, but was used only for L2→L1 communication for chains that are connected to ZK Gateway.

  • Each ZKChain appends a new batch leaf to its chainTree, resulting in a new chainRoot.

  • The updated chainRoot modifies the corresponding leaf in the global sharedTree, resulting in a new interop root.

  • The final sharedTree root is emitted in a NewInteropRoot event.

  • Operators of ZK Chains must feed these new interop roots into the bootloader of each chain, which stores them in L2InteropRootStorage.

  • Merkle proofs against these roots can be used to verify cross-ZKChain messages.

Fast Finality

Fast Finality provides early execution certainty by allowing transaction execution data to be published on L1 before the full batch is committed and proven.

  • The execution status of Gateway transactions is recorded as a rolling hash on L1 during pre-commitment.

  • During full batch commitment, the bootloader recomputes the rolling hash and verifies it matches the pre-committed version.

  • If the hashes do not match, the commitment is reverted.

  • Consumers (e.g., exchanges) can rely on pre-committed data to validate outcomes early.

  • The ability to revert these commitments is transferred from the operator to the Security Council.

Code improvements

  • Bridgehub’s functionality responsible for connecting the chain to either ZK Gateway or L1 has been moved into a separate contract called ChainAssetHandler.

  • ValidatorTimelock has been updated to an upgradeable version controlled by the ZKsync Governance and has been changed to support different roles for commit, prove, execute and revert.

Rationale

Interop Messaging

The Interop Messaging design in v29 enables secure message-passing between ZK Chains connected to ZK Gateway, establishing the foundation for advanced interoperability features like asset transfers and cross-chain contract calls. This approach supports ZKsync’s strategy of continuous, incremental upgrades, delivering immediate functionality while paving the way for future capabilities.

The specified design ensures that the interop is secure, while scalable, since all messages from all chains are aggregated into one root. By importing this single global root, a ZK Chain can validate messages coming from the entire Elastic Network.

Also, in the proposed design L2<>L2 messages reuse the same approach as the one that was used for L2→L1 messages, allowing ZK Chains to take advantage of the existing battle-tested codebase and providing better compatibility with the existing tooling.

Fast finality

The proposed design allows chains that settle on top of ZK Gateway to achieve subjective finality a lot faster. Previously, before a chain finalizes, it would have to wait for batch finalization on L1, which has been bottlenecked by two issues:

  1. The 3 hour timelock imposed on batch finalization for security purposes.

  2. Even if the timelock on L1 was removed, the need to settle ZK proofs would result in larger batches to reduce L1 gas footprint on users’ costs.

ZK Chains that are connected to ZK Gateway have neither of the issues above, but ZK Gateway itself is still a subject to it. To combine the best of both worlds, we will now publish pre-commitments to ZK Gateway’s transactions’ statuses to L1. These pre-commitments and the settlement of Gateway in general will be revertable only by the ZKsync Security Council that is protecting the ecosystem.

This way, any chain that settles on top of ZK Gateway can achieve quick subjective finality: once a small batch is successfully finalized on ZK Gateway and the pre-commitment is published on L1, anyone can be certain about the success of the batch.

Code improvements

Refactoring of Bridgehub allowed maintaining small code size and facilitated separation of concerns.

Making ValidatorTimelock an upgradeable contract allows for adding new features in the releases without changing the address, while making its validator permissions separate for commit/prove/execute/reverts was a prerequisite for fast finality and opens doors for more advanced setups for batch settlement permissions.

Implementation & Backwards Compatibility

The upgrade modifies bootloader logic, L2 storage contracts, and L1 settlement coordination logic. While backwards compatibility is maintained for existing ZK Chain operations, chains that wish to support interoperability and fast finality must update to the new version.

In this release, both interoperability and fast finality is avaliable only for chains that are connected to ZK Gateway. As such, upgrading ZK Gateway to the v29 will be a prerequisite for the support of these features.

Breaking changes

Most of the functionality remains compatible with the previous versions. However, some changes were introduced, mainly related to the code improvements efforts.

  1. Since the chain migration logic will move to ChainAssetHandler, once the ecosystem is upgraded to the v29 upgrade, only chains that have upgraded to the new version can change their settlement layer.

  2. To ensure backwards compatibility and smooth upgrade, the current validatorTimelock() getter of the ChainTypeManager contract will return the address of the old validator timelock. To obtain the address of the new validator timelock, please use the new validatorTimelockPostV29() getter.

Also note, that since the ValidatorTimelock changes, the permissions for the current validators will have to be reinstalled for the new timelock by each ZK Chain separately. The Matter Labs team will provide the community with the tooling that ensures easy upgrade process for all ZK Chains.

Security Considerations

The v29 upgrade introduces new trust surfaces and bootloader logic. Key security considerations:

  • Interop root validation is performed inside the system contracts and cross-checked during settlement.

  • All interop roots and rolling hashes are subject to validation and must match expected data.

  • Malicious operators attempting to bypass validation can be caught and reverted by the security council.

  • Pre-commits can only be reverted by the Security Council.

All major risks were reviewed and resolved through external audits.

Audit Summary

The v29 upgrade was audited by OpenZeppelin from May 20 to June 26, 2025. The audit covered all components of the Interop Messaging and Fast Finality systems, including bootloader changes, smart contracts, and L1/L2 integration. All findings were addressed before deployment.

The link to the audit will be provided soon.

Expected timeline

  • Testnet upgrade: September 2nd, 2025.
  • Mainnet upgrade: September 23rd, 2025, pending governance approval.

The actual timeline may vary, but not sooner than the dates provided above.

2 Likes