zkSync

Summary

zkSync (opens in a new tab) is a zero knowledge (ZK) rollup with native account abstraction (opens in a new tab).

The zkSync documentation outlines the addresses for their L1 contracts (opens in a new tab).
Their chain explorer can be found here (opens in a new tab).
The gateway and verifier solution developed for the mainnet chain can also be used for other ZKChains (opens in a new tab).

High level overview

The zkSync rollup contract (opens in a new tab) implements the diamond proxy pattern meaning that the implementations of different functions are handled by facet contracts to which queries are directed. Contract storage is maintained at the root proxy level.

The ExecutorFacet (opens in a new tab) handles the three step process by which batches of L2 transactions are committed (commitBatches), proven (proveBatches), and then finalized (executeBatches). After finalization state roots are available on L1 which we prove against.

Context

The context for zkSync is the last submitted batch number which is fetched by calling getTotalBatchesExecuted on the rollup contract.

Commit

The abiEncodedBatch is of the format:

    [
        'uint64', // batchNumber
        'bytes32', // batchHash
        'uint64', // indexRepeatedStorageChanges
        'uint256', // numberOfLayer1Txs
        'bytes32', // priorityOperationsHash
        'bytes32', // l2LogsTreeRoot;
        'uint256', // timestamp
        'bytes32', // commitment
    ]

Verification

The Unruggable gateway Typescript prover implementation used for ZKChains is ZKSyncProver.ts.

"ZKsync Era employs a different Merkle tree structure, necessitating a unique approach to proof verification. Unlike Ethereum's two-level hexadecimal trie—where the top level maps to accounts and the bottom to account storage slots—Era uses a single-level, full binary tree with 256-bit keys."

zkSync implements the zks_getProof (opens in a new tab) RPC method which takes an L1 batch number (rather than a block number), and returns appropriate proofs that are verified in our ZKSyncVerifier.sol contract.

In ZKSync, the entire state of the network is represented using a Sparse Merkle Tree. Proofs are verified using a Solidity adaptation of the SparseMerkleProof implementation in the zkSync rust codebase (originally ported by Clave (opens in a new tab)).

Notes

Use Proxy pattern

zkSync uses the era Virtual machine. It may have bugs.

"We recommend using the Proxy pattern for a few months after your first deployment on ZKsync Era, even if you plan to migrate to an immutable contract in the future."

Contract deployment and Ethereum Differences

Contract deployment follows different paradigms to L1 Ethereum. There are additional considerations (opens in a new tab).

More generally whilst EVM compatabile, zkSync does fundamentally differ (opens in a new tab) from Ethereum mainnet in many ways that contract deployers/chain users should be aware of.

Scroll Examples