[ZIP-001] Protocol Defense

:ballot_box: This proposal passed with a majority of 1.06B ZK in-favor of the proposal. See final results here.

Title [ZIP 001] Protocol Defense
Link to Vote ZKsync Governance Portal (powered by Tally)
Proposal Type ZIP
One Sentence Summary: This ZIP is a proposal to deploy quality of life improvements to ZKsync Era.
Proposal Author Matter Labs, point of contact is Zach Kolodny [@koloz]
Date Created: 2024-10-18
Version Version 1
Summary of Action Quality of life improvements including: Custom errors to replace string-based reverts for improved gas usage and revert insights + Stricter solhint rules for better code quality and consistency + Introduces floating compiler versions for interfaces and libraries to enhance ecosystem compatibility + Incorporates various gas optimisations to improve overall efficiency + Charge for pubdata in L2 → L1 logs + Chains will now be able to charge more to cover overhead of interacting with L1
Link to contracts [DO NOT MERGE]: Release v25 protocol defense by koloz193 · Pull Request #774 · matter-labs/era-contracts · GitHub

Simple Summary

This ZIP proposes a set of code quality improvements and optimizations for ZKsync Era. The changes focus on refactoring the codebase to enhance readability, maintainability, and gas efficiency.

Abstract

This proposal aims to implement several code quality improvements and gas optimizations within the ZKsync protocol. The changes include replacing string-based reverts with custom errors, introducing stricter solhint rules, utilizing floating pragmas for interfaces and libraries, and implementing minor gas optimization changes. These updates will enhance code readability, maintainability, and gas efficiency across the ZKsync ecosystem.

Motivation

The motivation behind this protocol upgrade is to implement several improvements and optimizations in line with the evolving standards for security, gas efficiency, and best practices in the Ethereum ecosystem. Since the ZKsync Era mainnet launched over a year ago, both the Ethereum Virtual Machine (EVM) compiler and industry standards have undergone updates and improvements. This proposal seeks to incorporate these advancements into the ZKsync protocol to ensure it remains efficient, secure, and aligned with the latest industry practices.

Specification

The complete technical specification can be found in the code repository here.

The technical changes that will be made to the ZKsync protocol covers updates to syntax, semantics, and new components.

The proposed changes include:

  • Custom Errors: Replace all string-based reverts with custom errors improving gas usage insights into reverts.
  • Solhint Rules: Implement stricter solhint rules, including but not limited to enforcing consistent naming conventions, requiring explicit visibility for state variables and functions, and limiting function complexity.
  • Floating Point Compiler Versions: Implement floating compiler versions for interfaces and libraries so they can be used within ecosystem projects without defining an exact compiler version.
  • Gas Optimizations: Implement minor gas optimizations, such as caching array lengths in loops, using unchecked blocks for arithmetic operations where overflow/underflow is impossible, and packing variables to use fewer storage slots.

These changes aim to improve security, maintainability, and compatibility with the latest tools and libraries. The focus is on holding our code to the highest standards and optimizing gas usage where applicable.

Testnet Details

Testnet (Seplolia) upgrade is currently scheduled for Tuesday Oct 22nd.

Rationale

The primary goal of these updates is to strengthen the security and maintainability of the ZKsync protocol while reducing gas costs for users. Custom error handling is more gas-efficient and provides clearer feedback for developers compared to string-based errors. The inclusion of stricter linting rules enforces best practices, ensuring long-term code quality.

We considered alternative approaches to certain issues, such as leaving string-based reverts in place, but concluded that the minor gas savings and improved clarity of custom errors were worth the transition. Similarly, caching array lengths in loops, though not mandatory, is a well-established gas optimisation practice that enhances performance at minimal development cost.

Security Considerations

This upgrade has been audited by OpenZeppelin. View the OpenZeppelin audit report here.

Summary of audit findings

The security audit identified no critical vulnerabilities, high vulnerabilities, or medium vulnerabilities. There were three low vulnerabilities identified, of which two items were resolved and one was partially resolved. The proposed changes have been reviewed to ensure they do not introduce new risks.

Low severity findings

  • L-01 Misleading Errors — Resolved in pull request #569 at commit 815b737.
  • L-02 Inconsistent Input Validation — Partially resolved in pull request #570 at commit f5ad651. The Matter Labs team stated “Given that these are only callable by the owner of the contract and used in scripts/tests we are less concerned with validation on the inputs for the additional cost.”
  • L-03 getAllHyperchains Function Reverts Due to Invalid Key Access — Resolved in pull request #571 at commit 7a7174e.

By consolidating and standardizing error handling, the upgrade minimizes the chances of misleading errors that could cause unnecessary retries or incorrect debugging efforts.

Additionally, stricter input validation and the removal of unused variables reduce potential attack surfaces, ensuring that only valid inputs are processed in key ecosystem functions. The OpenZeppelin audit team resolved floating pragma issues to prevent exposure to known bugs in the Solidity Yul optimizer.

Execution Impact

  • Gas changes reduced (report with diffs link)
  • Charge gas when sending L2 to L1 log
  • All ZK chains will now be able to charge more to cover overhead of interacting with L1

All client-side tools, libraries, and applications should remain unaffected by these changes. However, developers are encouraged to verify their contract deployments to ensure compatibility with the updated logic and tooling.

Backwards Compatibility

This upgrade is fully backward-compatible. Existing contracts and applications will continue to function without interruption. The changes primarily involve internal optimizations and error standardization, which do not affect contract interfaces or core functionalities.

For developers, there are no breaking changes, and no migration of existing contracts is necessary. The upgrade has been thoroughly tested, and any previously deployed contracts will remain compatible with the new framework.

Next Steps

  • The Testnet (Sepolia) upgrade is scheduled for Tuesday 22nd October
  • Call data for mainnet will be generated on Thursday 24th October and added to the Specification section.
  • Matter Labs will hold an Office Hours on Tuesday 22nd October at 10am ET to answer any questions on the proposal. Meeting link will be posted in the comments below.
9 Likes

Hi, I’m Zach, Senior Protocol Engineer at Matter Labs. Excited to post the first protocol upgrade for ZK Nation to vote on. We have been working on quality of life improvements over the past few months. We expect the upgrade on testnet to go live next week, with mainnet upgrade calldata being generated shortly after. Happy to answer any questions or comments!

8 Likes

ACI are in favour of this proposal and congratulate the Matter Labs team on their first technical upgrade making its way through governance.

ACI will always support technical developments which promise gas savings and remaining in line with best practices.

2 Likes

Although I may not understand all technicals implications, I do understand the benefit for a user and the chain itself.
Congrats on the first ZIP and happy to support it.

2 Likes

Great to see this proposal put forward by Matter Labs. Cyfrin is happy to sponsor the proposal and put it onchain when it is ready. Similarly, we have not audited the codebase ourselves, but are happy with the work OpenZeppelin has done.

2 Likes

Hey @patrickalphac thanks a ton for volunteering to sponsor the ZIP!

2 Likes

Just an update here, we’re waiting on partners/users running our EN to update to the latest version. Once that’s done (or a reasonable amount of time, 1 week, has passed) we will be moving to the testnet upgrade. Only after testnet has been upgraded will we move forward with mainnet calldata generation

3 Likes

Really excited to see the ZIP process moving.

I expect this forum to become an active place for technical discussions, and from the Matter Labs side we’re really motivated to discuss this and future proposals (in case people have questions/comments etc).

2 Likes

Thanks for putting this together and sharing it with the DAO.

The proposal clearly outlines the improvements and their benefits to the chain and developers building on ZKsync which is really important as we keep increasing onchain developer activity through TPPs in the coming months.

Happy to see technical proposals officially kicking off.

1 Like

Thanks for bringing this to the forum, agree with the other members in the thread that the suggested code changes are reasonable.
I see some of the commits are already a couple of months old, I guess with the governance running, it should be a quicker process in the future?

Cyfrin supports [ZIP-001] Protocol Defense, enhancing the quality of life and efficiency of the ZKSync Era chain.

OpenZeppelin is proud to have audited this first code upgrade to be deployed and approved via the ZIP process. As our report states, no major issues were found during our review and the few minor issues that we raised have been addressed.

With ZIP-001 live and on-chain, our team is doing final verification checks that the proposal payload sufficiently matches the audited code in preparation for giving our approval as a member of the Security Council, following the Token Assembly vote.

Thanks for posting this proposal @koloz
We will support this proposal as it enhances efficiency, security, and coding practices, improving the overall experience for ZKsync users and developers. we’re very happy to see these improvements implemented.

After consideration Treasure’s Treasure Delegate Council (TDC) would like to share the following feedback on the proposal

We intend to vote FOR this proposal, as it aims to improve gas efficiency and security, delivering tangible benefits for both ZKsync users and developers. These upgrades are important for strengthening the chain’s infrastructure, creating a more robust and reliable foundation for onchain activity.

We have confidence in the technical expertise behind this initiative, placing trust in the Matter Labs team and the thorough audit conducted by OpenZeppelin. The professionalism and transparency demonstrated throughout the development and presentation of this proposal are commendable, and we appreciate the clear communication that has accompanied it.

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

We’re voting FOR the proposal.

The proposed quality-of-life changes will improve the experience for developers and users while the changes themselves do not seem as contentious. Given that, our main consideration before voting in favor of the proposal would be security considerations regarding implementing the changes. While the audit by OpenZeppelin revealed some non-critical issues, those have since been addressed, either wholly or partially, which makes us comfortable supporting the proposal.

The ZKsync Security Council has posted an update related to ZIP-1. Please see the post linked below for more information.