Title	Protocol Defense
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	https://github.com/matter-labs/era-contracts/pull/774

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.

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.