| Proposal Type | ZIP |
|---|---|
| One Sentence Summary | ZIP-11 proposes the V28 upgrade for ZKsync. |
| Proposal Author | Matter Labs |
| Proposal Sponsor | Cyfrin |
| Date Created | May 2025 |
| Version | Current version of proposal |
| Summary of Action | Upgrade ZKsync to V28 |
| Link to Contracts | https://github.com/matter-labs/era-contracts/tree/release-v28 |
| Link to Server | https://github.com/matter-labs/zksync-era/releases/tag/core-v28.2.1 |
Abstract
ZIP-11 proposes the V28 upgrade for ZKsync. The key features of V28 are implementing key Ethereum precompiles directly in ZkVM. This version adds native support for elliptic curve operations (ECAdd, ECMul, ECPairing) and modular exponentiation (ModExp) within the ZkEVM circuit framework. By moving these expensive operations from L2 smart contracts into optimized zkcircuits, V28 significantly improves performance and reduces gas costs for onchain cryptography. In summary, v28 enables more efficient proof verification and cryptography calculation, lowering the execution code while maintaining the same functionality.
Motivation
Improving Performance and Cost Efficiency: Cryptographic operations like SNARK proof verifications and RSA modulus exponentiations have historically been gas-intensive on ZKsync. Prior to V28, verifying a complex proof on ZKsync could consume on the order of millions of gas, making such use cases costly. The community has been pushing to optimize these operations to broaden ZKsync’s capabilities for DeFi and privacy applications. V28 delivers on this promise. For example, in tests on the Sepolia testnet, the gas cost to verify a typical zkSNARK proof dropped from ~6.8M to ~0.37M – roughly a 94% reduction in gas usage. This improvement makes advanced use cases more practical: trustless DeFi protocols can verify proofs or signatures on-chain with minimal overhead, and privacy-preserving applications become far more affordable to deploy. Ultimately, the V28 upgrade advances ZKsync’s goal of high-performance, cost-effective on-chain computation for complex cryptographic tasks.
Specification
Precompiles
ECAdd (Elliptic Curve Addition): Adds two points on the BN254 elliptic curve (the same curve as Ethereum’s alt_bn128). This precompile now runs inside the circuit, ensuring the input points are on the curve and handling edge cases like the point at infinity on a pairing-friendly elliptic curve BN256.
Checks input validation inside the circuits: The four 256-bit integers x1, x2, y1, y2 are field elements of BN254, detects points at infinity, and verifies each point actually lies on the curve. If a point fails the check, it is replaced with the curve’s zero element, preventing malformed inputs from influencing the result.
Performs mixed‑coordinate elliptic‑curve addition P₃ = P₁ + P₂, handling the special case where P₂ is infinity. The sum is converted back to affine form, normalized, and then re‑encoded as 256‑bit integers for EVM compatibility.
Aggregates all validation checks into a single Boolean success. If any check fails, success = 0, and the output coordinates are masked to zero. Otherwise, success = 1, and the (x, y) holds the correct results. The function returns (success, (x, y)), matching the EVM ECADD precompile convention.
Address of ECAdd: 0x6
**ECMul (Elliptic Curve Multiplication):** Multiplies a BN254 curve point by a scalar value. The circuit implementation performs scalar multiplication with optimizations and correctly handles special cases such as multiplication resulting in the point at infinity.
Checks input validation inside the circuits: The input 256-bit integers x1, x2 are field elements of BN254, detects points at infinity, and verifies that the point actually lies on the curve. If a point fails the check, it is replaced with the curve’s zero element, preventing malformed inputs from influencing the result. Verifies that the 256‑bit scalar fits the BN254 scalar field and normalizes it.
Scalar multiplication uses an efficient endomorphism‑based scalar decomposition combined with a width‑4 windowed method for efficiency. All calculations are performed in projective coordinates to handle cases safely where the point might become the point at infinity. Afterward, the result is converted back to affine form, with an explicit check for the infinity case before the final 256‑bit re‑encoding.
Aggregates all validation checks into a single Boolean success. If any check fails, success = 0, and the output coordinates are masked to zero. Otherwise, success = 1, and the (x, y) holds the correct results. The function returns (success, (x, y)), matching the EVM ECMul precompile convention.
Address for MUL: 0x7
ECPairing (Elliptic Curve Pairing check): Performs a bilinear pairing operation on the BN254 curve, used to verify pairing-based proofs. This precompile supports checking multiple pairs and confirms that input points lie in the correct subgroup
Checks input validation inside the circuits: The points input 256-bit integers (x1, y1) and (x2_c0, x2_c1, y2_c0, y2_c1) (affine and twisted points) are field elements of BN254, detects points at infinity, and verifies that the point actually lies on the curve. If a point fails the check, it is replaced with the curve’s zero element, preventing malformed inputs from influencing the result. Verifies that the 256‑bit scalar fits the BN254 scalar field and normalizes it.
Runs an optimized Miller loop that reuses precomputed line function, slashing constraints count ( and therefore gas) relative to a line evaluation. Performs the G2-subgroup check “for free” by reusing the same Frobenius endomorphism already computed inside the Miller loop, so no extra large field constraint spending. Applies torus-compression formula during easy part and hard part evaluation, by shrinking the non native field and cutting a significant amount of constraints. For hard-part evaluation, we use the fastest Devegili method
Collects all per‑coordinate field checks and the no_exception result into a single success Boolean. If success is false (invalid field element, off‑curve point, or pairing exception) we mask the result and return flag = 0; otherwise, the returned BN256Fq12NNField holds the product of pairings.
ModExp (Modular Exponentiation): Computes an exponentiation of the form $b^e mod (m)$
for large $b, e, m$. This operation is fundamental in many cryptographic protocols (for example, RSA-based verifications). Input parameters format is done according to EIP-198: https://eips.ethereum.org/EIPS/eip-198
Accepts 32‑byte base, exponent, and modulus and return 0 when modulus = 0. Per bits computes a² mod m and, if the bit is 1, we get (a²·base mod m). Otherwise, we just seta² mod m
After the loop, the result is zero‑masked when modulus == 0, satisfying EIP‑198’s “return zero if modulus = 0 or exponent = 0” rule without adding separate branches.
These implementations are integrated in the Rust codebase under the zksync-protocol multi crate of the ZKsync protocol. The elliptic curve operations leverage BN254 field arithmetic: https://github.com/matter-labs/zksync-protocol/tree/main/crates/zkevm_circuits/src/bn254, and the ModExp is implemented: https://github.com/matter-labs/zksync-protocol/tree/main/crates/zkevm_circuits/src/modexp
Implementation & Backwards Compatibility
Contracts on ZKsync Era that already use addresses 0x06, 0x07, 0x08 or the ModExp precompile will continue to function as before. The difference post-V28 is that those calls will execute against the new circuit backed implementations rather than the old in VM computations. From a developer’s perspective, each precompile's interface and call method remain the same; the upgrade is entirely under the hood.
Contracts
Precompiles are actively used in the verifiers' contracts to enable proof verification for chains settling on top of the ZK gateway chain.
Security Considerations
Upgrading the circuits of the zkEVM requires careful attention to security and correctness. The new precompiled circuits must uphold the same guarantees as the old implementations, ensuring no regressions or vulnerabilities are introduced. All elliptic curve operations enforce that inputs are valid and follow Ethereum’s expected behavior. For instance, the pairing check circuit validates that each provided pairing is correct and that no invalid points can trivially satisfy the equation. The ModExp circuit similarly handles edge cases like zero moduli and ensures the computation is accurate bit-by-bit.
Audits and Testing: Matter Labs conducted internal testing of the V28 circuits & contracts and did an external audit. Collaborating with Distributed Lab, the BN254 curve circuits were developed and reviewed to leverage best practices. Additionally, security firms (such as OpenZeppelin and SpearBit) audited the precompile implementations, covering both the Rust code, zk circuits, and contracts. Auditors concluded that the cryptographic implementations are sound & complete and aligned with security best practices. Audit reports:
ZKsync Crypto Precompile Audit :
report-cantinacode-matter-labs-0321.pdf
ZKsync Crypto Precompile Audit.pdf
ZKsync Protocol Precompile Audit:
ZKsync Protocol Precompiles Implementation Audit.pdf
ZKsync Era-contracts Precompile Audit:
ZKsync Era-contracts Precompile Audit.pdf
Fix Default Upgrade PR
After the initial audit more fixes have been applied in the following PR: Fix Default Upgrade PR Link
