Detailed explanation of zkSync architecture and its similarities and differences with OP-Stack

Author: xpara, Four Pillars; translation: Jinse Finance xiaozou

Key Points:

Matterlabs, the development company of zkSync, has been working on developing its unique zkEVM and creating great products.

Currently, the zkSync Era is showing growth, as evidenced by its impressive metrics and development deployments across projects.

We can understand the zkSync architecture through three key layers of zkSync: execution layer, settlement layer, and data availability layer.

ZK-Stack (zkSync's underlying codebase) and OP-Stack may have similar philosophies. Still, there are clear differences that can be seen from the perspective of dapp developers, core developers, and business operators.

1**, the development of zkSync**** history**

1.1 Brief History of zkSync

The development of zkSync began in EthCC in 2019. At that time, it was still a small team dedicated to jointly developing and deploying Rollup with zkSNARK. They launched a proof of concept in January 2019 using zkSNARKs to operate a sidechain in Ethereum. Since then, they have made decentralization a core principle. They focused on storing all transaction data in Ethereum and worked out a multi-operator model to handle the sorter decentralization model.

In June 2020, the team made significant progress with the launch of the zkSync v1 mainnet. zkSync v1 is a key milestone in the development of zkSync, representing the actual implementation of its original concept on a larger scale. A year later, in June 2021, they made a further breakthrough and released the zkSync 2.0 testnet, also known as Era.

By March 2023, the complete mainnet of zkSync has been successfully released, marking a major achievement for the team. This development shows that the platform has reached a high level of maturity and is ready for wider adoption. This is the release of the first mainnet zkEVM deployed in the Ethereum Rollup ecosystem.

Currently, the team is working on making zkSync open source. This will enable separate deployment of zk rollup chains from within a ZK-Stack, enabling teams to launch their own custom rollups. Further details on this exciting development are expected to be announced soon.

*** **** *' *** **

Matterlabs, the development team behind zkSync, has raised significant funding to advance its mission. With their most recent Series C round in November 2022, their total funding came to $458 million, which included multiple rounds and dedicated ecosystem funds, including for example a separate $200 million dedicated ecosystem fund, A $200 million Series C, a $50 million Series B led by a16z, and an $8 million Series A and seed round.

· Seed round: In the seed round, Matterlabs received $2 million in funding from PlaceholderVC, Hashed and other investors. This early financial stimulus provided the necessary foundation for their work to start the zkSync project.

Series A: Following its seed round, Matterlabs has raised an additional $6 million in Series A funding. This new inflow of capital provides the impetus to advance their R&D and bring zkSync closer to its ultimate goal.

Series B: Matterlabs is gaining momentum as they managed to raise $50M in a Series B round led primarily by a16z.

· Series C: Matterlabs’ C round of financing is $200 million.

Finally, in addition to the above investment rounds, Matterlabs has launched a dedicated $200 million ecosystem fund. This fund is dedicated to fostering the growth and development of the broader zkSync ecosystem.

All of these resources provide Matterlabs with the financial support it needs to advance its zkSync mission, accelerate the pace of development, and foster the growth of the broader ecosystem. All in all, Matterlabs has a sizeable amount of funding in important blockchain projects.

2**、Current zkSync ecosystem status**

2.1 Overall Status

Over the years, zkSync has made significant development progress. zkSync v1, now zkSync Lite, reached a development milestone in December 2020, surpassing $1 million in Total Value Locked (TVL). Since then, the TVL of the zkSync ecosystem has grown exponentially. As of now, zkSync’s TVL has exceeded $650 million, making it the third largest L2 Rollup in the Ethereum ecosystem.

By June of this year, zkSync had some impressive key metrics. Although zkSync was slightly inferior to Arbitrum in June, it ranked first in TPS. It has the fastest TVL growth rate and leads in total fee payments on Tier 1.

Additionally, the number of unique wallets is also increasing, indicating increasing user adoption. At the same time, the amount of ETH bridged to zkSync is also growing.

2.2 Main Items

2.2.1 Silver

Argent is a non-custodial mobile wallet for Ethereum-based cryptocurrencies, providing a secure and user-friendly experience for managing digital assets.

Argent has a unique security mode design, even if the user's mobile phone is lost or stolen, it can also protect the user's assets. The security model includes features such as biometric authentication, social recovery, and on-chain smart contract wallets. V God, the founder of Ethereum, also said that Argent is a wallet with multi-signature security and social recovery functions.

2.2.2 SyncSwap

SyncSwap is the largest DeFi protocol in the zkSync Era. It is an AMM-based DEX that provides various important features in AMM design. It provides an AMM pool for various tokens, the important properties are as follows.

Stableswap: The multi-pool allows SyncSwap to aggregate multiple different pool models, each with its own optimal scenario, making transactions efficient. The first pool model to be implemented will be the Stable Pool. Compared with the general-purpose Classic Pool, the Stable Pool supports efficient stablecoin transactions, enabling SyncSwap to enter the large-scale stablecoin market.

· Smart Router: It serves as a liquidity aggregation platform that aggregates different liquidity pools and various pool models to provide the best price effortlessly. Provides multi-hop and path splitting.

Dynamic Fees: SyncSwap has introduced dynamic fees on its DEX, allowing users to customize transaction fees based on market conditions and community preferences. Including variable fees, targeted fees, fee discounts and fee entrustment. These features provide users with the flexibility and adaptability to optimize their trading strategies and stay in tune with ever-changing markets and communities.

2.2.3 Tevaera

Tevaera's gaming ecosystem brings a unique blend of adventure and technology to the gaming world. Teva Games offers games across a variety of genres, set in natural environments and connected by a central storyline of Guardian characters. The first multiplayer game will debut with the release of Tevaera 2.0, offering exciting gameplay including crypto-themed upgrades and multiple game modes.

The on-chain gaming infrastructure consisting of Teva Core, Teva Chain, Teva Dex, and Teva Market further enhances the ecosystem.

· Teva Core is an advanced multiplayer game framework.

· Teva Chain is a third-layer gaming hyperchain that facilitates the transition to full-chain gaming.

· Teva DEX contributes to sustainable play economy through automatic game dex.

· Teva Market allows for the minting and trading of unique NFT characters.

3**, zkSync Architecture**

zkSync Era is a L2 protocol designed to solve the scalability problem of Ethereum, using a zero-knowledge (ZK) rollup structure. Developed by Matter Labs, it is a zk-rollup platform focused on user needs. The platform is designed to be broadly compatible with the Ethereum Virtual Machine (EVM) in a custom virtual machine, optimized for zero-knowledge proofs.

The operation of zkSync rollup can be summarized in the following stages:

(1) Initially, transactions or priority actions are generated by users.

(2) Subsequently, the operator assumes the responsibility for processing the user's request. After successful processing, the operator creates a rollup operation and includes it into the block.

(3) After the block is completed, the operator submits it to the zkSync smart contract in the form of block submission. It is worth noting that the smart contract verifies part of the logic that certain rollups run.

(4) Finally, the proof of the block is provided to the zkSync smart contract, and this step is block verification. If the validator contract considers the validation successful, it validates the new state as final. This is the operational life cycle of zkSync rollup.

This section will delve into how zkSync works, focusing on three basic layers:

(1) Execution layer: The execution layer refers to the process that leads to changes or transitions in the state of the blockchain. Simply put, it is the place where transactions are received and applied to the previous state.

(2) Settlement layer: The settlement layer uses a proof system to ensure that changes made during the execution phase accurately reflect the overall state of the system.

(3) Data availability layer: The data availability layer is the record keeping part of the system. It is where all transaction data (inputs), system updates (outputs) and proofs are stored. The purpose is to ensure that the current state of the system can always be recreated from scratch when needed.

3.1 Execution Layer

3.1.1 Virtual Machine Level Execution Layer

It runs on type4 zkEVM, which means it takes smart contract code written in a high-level language (eg, Solidity, Vyper) and then compiles it into a zk-SNARK friendly language.

Additionally, a unique feature of zkSync Era is that it uses an LLVM-based compiler that will eventually allow developers to write smart contracts in C++, Rust, and other popular languages.

The LLVM framework is a compiler for building smart contract language toolchains. Its high-level intermediate representation (IR) allows developers to design, deploy, and improve efficient language-specific features while simultaneously taking advantage of the broad LLVM ecosystem.

In the established toolchain, LLVM processes LLVM IR, introduces full optimizations, and finally passes the optimized IR to the zkEVM backend code generator.

3.1.2 Execution layer overview

In zkSync, Core App (core application) plays a key role in managing the execution layer.

Its primary responsibility is to track deposits or priority operations of L1 smart contracts. This mechanism is critical to ensure the seamless integration of zkSync with the Ethereum network, as all changes initiated from the Ethereum network need to be monitored and reflected in the zkSync Layer 2 (L2) environment.

The Core App is also responsible for managing the memory pool (mempool) that collects incoming transactions. This collection of transactions then sits in a queue to be processed, effectively acting as a waiting area before transactions are confirmed and added to a block.

The Core App's responsibilities also include fetching transactions from the mempool, executing them in a virtual machine (VM), and adjusting state as needed. Essentially, the process consists of acquiring transactions, processing them, and reflecting the results in the system.

After executing the transaction, the Core App generates a chain block. These blocks consist of executed and verified bundles of transactions. The Core App then submits these blocks and proofs to the L1 smart contract. This process ensures that the state of the L1 Ethereum chain is kept in sync with the L2 zkSync chain.

To support seamless interaction between Ethereum-based applications, it provides an Ethereum-compatible web3 API. This makes zkSync more accessible and user-friendly for developers and users skilled in the Ethereum ecosystem.

3.2 Settlement Layer

The settlement layer is responsible for ensuring the integrity of zkSync state transitions. This verification process is done in a smart contract deployed on Ethereum. There are two important contracts in this process.

(1) Executor contract: This contract obtains block data from validators and zk proofs of state transitions in zkSync.

(2) Verifier contract: This is a logical contract that allows the system to verify the block data and zk proofs provided by the executor contract.

3.2.1 Executor contract

The proveBlocks function plays a central role in ensuring the integrity and security of the zkSync system. Its main job responsibility is to verify zk-SNARK proofs of submitted blocks. Here's a brief description of how it works:

First, proveBlocks ensures that blocks are being verified in the correct order. It does this by checking whether the previous block received is the next block in the blockchain sequence that needs to be verified.

· Next, the function starts iterating over each submitted block. It checks that the hashes of these blocks match the expected value at a particular location in the blockchain. This ensures that the block being verified is indeed the correct block.

The function then starts building the proofPublicInput array, which becomes the public input value for the zk-SNARK proof verification process. The block number for each committed block is contained in this array.

Then, using the proofPublicInput array and some stored parameters, the function will check the zk-SNARK proof. It's similar to solving a puzzle, all the pieces should fit together perfectly.

· If the proof is verified, the function updates the system to reflect that the blocks are now verified. It's like putting a tick next to an item on a checklist.

Finally, for each verified block, the function triggers a special event called BlockVerification. It's like sending a notification that the block number, hash, and commitment have been verified.

In a nutshell, the proveBlocks function acts like a vigilant gatekeeper, ensuring blocks are verified in the correct order, ensuring zk-SNARK proofs are accurate, and updating the system state accordingly. Its goal is to prevent invalid blocks from being executed, ensuring the overall security and integrity of the zkSync system.

3.2.2****Verifier contract

The verifier contract is the place to implement the above verification logic. It acts as a guard for zkSync by checking zk-SNARK proofs to verify committed data. The validator contract is used to verify whether the data submitted to zkSync is valid.

The verifier contract stores the "verification key", which is used to verify zk-SNARK proofs. Whenever zkSync wants to commit an update, it generates a zk-SNARK proof and submits it to the validator contract via the executor contract.

The validator contract then uses the validation key to check that the proof is valid. If it works, you know the update is legitimate without looking at the actual data. If invalid, the update will be rejected.

By verifying these proofs, the validator contract ensures that only correct and valid data is received into zkSync. This is critical for security and preventing invalid state updates.

3.3 Data Availability Layer

The data availability layer of the system acts as an archive, storing all transaction information (inputs), system changes (outputs) and proofs. zkSync uses a smart contract interface to set its data availability (DA) policy. zkSync plans to provide multiple options for data availability to reduce costs and protect privacy.

3.3.1 zkPorter

zkSync launched an off-chain data availability solution called "zkPorter". The tool is designed to integrate with zkSync's rollup system, facilitating interactions between rollups and zkPorter accounts. To ensure the security of data within zkPorter, "guardians" - individuals who stake zkSync tokens and verify the availability of data by signing blocks - are enabled.

zkPorter operates as an internal consensus protocol, facilitating massive transaction throughput. In comparison, the standard ZK Rollup mode in zkSync 2.0 is capable of processing around 1,000 to 5,000 transactions per second (TPS). zkPorter can manage 20,000 to 100,000 TPS, depending on the complexity of the transaction.

A tradeoff of using zkPorter is that users must trust zkSync's internal consensus mechanism. This leads to a less decentralized rollup solution. The user's consideration is to choose between zkPorter (lower cost but less secure) or ZK-rollup mode (highest security).

Additionally, zkSync 2.0 facilitates interoperability, allowing seamless swaps between ZK-rollup and zkPorter accounts. The fundamental difference between zkPorter and Starkware Volition is the determination of data availability: in zkPorter, this decision is made on an account basis, while in Volition this decision is made on an individual transaction basis within an account made on.

4**、ZK stack and OP stack**

Recently, Matter Labs announced the upcoming release of ZK-Stack. ZK-Stack will provide a software similar to OP-Stack to customize and operate rollup.

The common features of OP-Stack and ZK-Stack are as follows:

Free and Open Source: Both are developed under an open source license, ensuring free access. They encourage developers to contribute by building on top of the software.

Interoperability: ZK Stack's Hyperchain hyperchain concept can be effortlessly connected in a trustless network with low latency and shared liquidity. In addition, OP-Stack envisions a Superchain concept to connect all OP-Stack-based chains.

· Decentralization: In order to achieve a more decentralized network and community, both OP-Stack and ZK-Stack have clearly proposed a decentralization plan in the recent roadmap. This move not only increases the resilience of the network, but also ensures a fairer distribution of power and control.

Despite the similarities from a conceptual perspective, there are differences from a technical and business perspective. This section will delve into the differences between the following perspectives.

(1) Dapp developers

(2) Core developers

(3) Business

4.1****Dapp developer perspective

4.1.1 EVM equivalence

OP-Stack's EVM deployment: OP-Stack's EVM is implemented by making minor changes to Ethereum's geth, making the system almost fully compatible with EVM. On the other hand, ZK-Stack incorporates some changes in EVM opcodes, and some opcodes are not yet supported. Despite these changes, the impact has been minimal, and the projects have been rigorously tested and validated in the real world.

However, there have been incidents due to the non-EVM equivalence of ZK-Stack. A notable example is 921 ETH trapped in a smart contract because the contract uses the transfer function. This problem has been effectively solved.

4.1.2 Native account abstraction

Unlike ERC-4337, ZK-Stack's architecture includes a native account abstraction (AA) function. In a system like ERC-4337, it is necessary to have a separate mempool of UserOps to allow account abstraction in the network.

4.1.3 Privacy Support

By using validum, storing the data in an otherwise confidential database ensures privacy on the premise that the operator keeps the block data confidential. This feature is especially beneficial for enterprise users.

4.2 Core developer perspective

4.2.1 Infrastructure operation: OP-Stack is more intuitive

Operation: Both zkSync and OP-Stack use a Sequencer to coordinate transactions and store data in Ethereum. However, zkSync requires a prover to function. This prover application processes server-generated blocks and associated metadata to construct zero-knowledge proofs of validity. In contrast, OP-Stack does not require a separate complex infrastructure to participate in the proof challenge game.

4.2.2 VM alternatives: ZK-Stack has more potential to provide various options

zkSync runs with the LLVM compiler, which translates to zkEVM bytecode, showing the potential to create execution environments using other languages, such as C++.

4.2.3 Data Availability: ZK-Stack offers multiple options

The data availability layer of OP-Stack mainly relies on Ethereum, where all transaction information and output state roots are stored. This leads to a high cost of operating the OP-Stack chain. However, there have been attempts to offset this cost by storing transaction data in Celestia DA.

ZK-Stack is heavily researching and developing alternatives to data availability solutions like zkPorter. This approach enables users to determine their own data availability based on their preference for greater security or lower cost. Additionally, businesses wishing to maintain data privacy can employ solutions like Validium that support data storage that is not compromised.

4.3 Business Perspective: Costs and Benefits

Today, launching independent rollups is a viable option, especially since open source software like ZK-Stack and OP-Stack are being developed and maintained publicly. Additionally, Rollup-as-a-Service (RaaS) platforms such as Caldera and Conduit greatly simplify the process.

Beyond the developer perspective, it is critical to realistically assess the potential costs and benefits associated with rollup operations. However, forecasting these amounts can be complicated due to several variables.

As major improvements to the code base are being made on a regular basis, as seen in the recent Optimism's Bedrock upgrade, the costs associated with running rollups are rapidly decreasing. This dynamic makes it challenging to accurately estimate costs and benefits. Also, the specific costs associated with servers and infrastructure are not widely known since a single entity usually manages the entire rollup. Finally, fluctuations in the price of the underlying token (like zkSync and Optimism’s ETH) add another layer of uncertainty, as costs can fluctuate based on market sentiment.

Some of the main costs and benefits are as follows:

4.3.1 Cost

· L1 release cost: the cost of storing transactions, state roots, and proof data. Typically, an optimistic rollup is more expensive to issue because it requires storing raw transaction data for validation. Some rollups publish state differences instead of full state data to avoid further costs.

· L2 sorter running cost.

Proof cost: for zk, it is the cost of proof generation and verification; for fraud proof, it is the cost of proof challenge.

4.3.2 Benefits

· L2 transaction fees

Possibly MEV, but to avoid centralization issues, most known L2 sorters do not extract MEV.

5 Conclusion

Matterlabs has been working on the development of zkEVM and has made significant progress on it. Although not fully EVM compatible (Type4 EVM), exploiting LLVM seems to have great potential. The next phase of Matterlabs’ plans is to release ZK-Stack, a codebase that will enable developers to leverage its solid codebase to create their own rollups. The tool promises clear advantages over OP-Stack, especially in terms of privacy protection and scalability.

However, both projects are still in their early stages and a lot of work needs to be done. A thorough assessment of the cost and benefit structure associated with deployment is critical. Additionally, an important challenge lies in cultivating a developer ecosystem around these two codebases. Detailed analysis and strategic planning are essential to ensure the sustainable development of the platform and its associated technologies.

I hope both projects thrive and that open source building and shared roadmaps become the norm in the web3 space.