Snapshot on zkSync and a Comparison with OP-Stack

Key Takeaways

• Matterlabs, the company behind zkSync, has shown consistent dedication to developing its unique zkEVM and built great products.

• At present, the zkSync Era is experiencing growth, reflected in impressive metrics and the deployment of a variety of projects.

• Understanding the architecture of zkSync can be achieved by examining its three key layers: execution, settlement, and data availability.

• ZK-Stack, the underlying codebase for zkSync, and OP-Stack may share a similar philosophy, but distinct differences can be identified when viewed from the perspectives of dapp developers, core developers, and business operators.

1. Footsteps of zkSync

1.1 Brief History of zkSync

zkSync's journey began at EthCC in 2019 as a small team striving to implement Rollup with zkSNARK. Their proof of concept was introduced in January 2019, which involved using a zkSNARK to operate a sidechain in Ethereum. Since then, they had decentralization as a core principle. They focused on storing all transaction data in Ethereum and pondered a multi-operator model to handle the sequencer decentralization model.

By June 2020, the team made significant strides with the launch of zkSync v1 mainnet. This version was a crucial milestone in their journey, representing the practical implementation of their initial concept on a broader scale. A year later, in June 2021, they pushed the boundaries further with the release of the zkSync 2.0 testnet, known as Era.

Fast forward to March 2023, the full mainnet of zkSync was successfully launched, marking a significant accomplishment for the team. This development represented the maturity of the platform and its readiness for broader adoption. This launch has been the first mainnet zkEVM to be deployed in Ethereum Rollup ecosystem.

At present, the team is working towards making zkSync open-source. This will allow separate deployments of zk rollup chains from a ZK-Stack, enabling teams to launch their own customized rollups. Additional details on this exciting development are expected to be announced shortly.

(All Tweets by zkSync and Matterlabs can be found at this link)

1.2 Funding

Matterlabs, the team behind zkSync, has amassed substantial funding to further its mission. Through a recent Series C round in November 2022, they have successfully raised their total funding to $458 million. This figure encompasses various investment rounds and a dedicated ecosystem fund. This includes a separate $200 million dedicated ecosystem fund, $200 million Series C, $50 million Series B led by a16z, and $8 million in Series A and Seed Round.

• Seed Round: The seed round saw Matterlabs secure $2 million from investors including PlaceholderVC, Hashed, and others. This early financial boost provided an essential foundation to begin their work on the zkSync project.

• Series A: Following the seed round, Matterlabs raised an additional $6 million during their Series A funding round. This new influx of funds provided the fuel to push forward their research and development and bring zkSync closer to realization.

• Series B: Matterlabs' momentum continued to grow, and during the Series B funding round, they raised $50 million, primarily led by a16z.

• Series C: Matterlabs raised $200 million. The details of this funding round can be found in this Techcrunch article as well as in their own announcement.

• Lastly, in addition to these investment rounds, Matterlabs also established a dedicated $200 million ecosystem fund. This fund is allocated specifically to fostering the growth and development of the broader zkSync ecosystem.

All these resources combined have given Matterlabs the financial backing necessary to advance their zkSync mission, accelerate its pace of development, and foster growth within the wider ecosystem. Totally, Matterlabs had one of the biggest funding in major blockchain projects

(Source: zkSync Insider)

2. Current Ecosystem

2.1 Overall Status

zkSync has seen significant progress and growth over the years. zkSync v1, now known as zkSync Lite, hit a milestone in December 2020 when it surpassed $1 million in Total Value Locked (TVL). From then onwards, the TVL of the zkSync ecosystem has grown exponentially. As of now, it has exceeded $650 million, positioning zkSync as the third-largest Layer 2 Rollup in the Ethereum ecosystem.

(Source: L2BEAT – The state of the layer two ecosystem)

(Source: zkSync Era – L2BEAT)

Fast forward to June 2023, zkSync holds some impressive key metrics. It stands as the number one rollup by transactions per second (TPS), although it slightly trails Arbitrum over a 30-day period. It boasts the fastest TVL growth rate and is the leading rollup by aggregate fees paid on Layer 1.

Furthermore, the number of unique wallets is also rising, indicating an increase in user adoption. Simultaneously, the amount of Ethereum bridged into zkSync is also growing.

2.2 Major Projects

Also, there are lots of projects being developed in the ecosystem.

(Source: zkSync Ecosystem — The era of dapps )

2.2.1 Argent

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

Argent has a unique security model that is designed to protect user assets even if the user’s phone is lost or stolen. This model includes features like biometric authentication, social recovery, and on-chain smart contract wallets. Argent is a wallet with multisig security and social recovery, which Ethereum Founder Vitalik Buterin says is his "preferred method for securing a wallet.”

2.2.2 SyncSwap

SyncSwap is the largest DeFi protocol in zkSync Era. It is a DEX based on AMM and provides various important features in AMM design. It provides an AMM pool for various tokens having 62 pools and important properties are like those below

• Stableswap: The multi-pool allows SyncSwap to aggregate multiple different pool models, each with its own optimal scenarios, making trading highly efficient. The first pool model to land will be the Stable Pool supports efficient stablecoin trading compared with the general-purpose Classic Pool, making SyncSwap enter the massive stablecoin markets.

• Smart Router: It performs as a liquidity aggregator to aggregate different liquidity pools and various pool models to deliver the best price effortlessly. Providing multi-hops and path splits

• Dynamic Fees: SyncSwap introduces dynamic fees on its DEX, allowing users to customize trading fees based on market conditions and community preferences. The four facets include variable fees, directional fees, fee discounts, and fee delegation. These features provide flexibility and adaptability for users to optimize their trading strategies and align with the changing dynamics of the market and community.

2.2.3 Tevaera

Tevaera's Gaming Ecosystem brings a unique blend of adventure and technology to the gaming world. Teva Games provides multi-genre games set in naturalistic environments and linked by a central Guardian characters storyline. The first multiplayer game is set to debut with the Tevaera 2.0 launch, offering thrilling gameplay featuring crypto-themed power-ups and diverse game modes.

The ecosystem is further enhanced by an on-chain gaming infrastructure, composed of Teva Core, Teva Chain, Teva Dex, and Teva Market.

• Teva Core is an advanced multiplayer game framework

• Teva Chain, a Layer 3 gaming hyper-chain, facilitates the transition to fully on-chain games.

• Teva DEX contributes a sustainable play & earn economy via an automated gaming dex, and

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

3. Architecture of zkSync

zkSync Era is a Layer 2 protocol developed to address the scalability issues of Ethereum, utilizing a zero-knowledge (ZK) rollup structure. Developed by Matter Labs, it represents a zk-rollup platform designed with a focus on user needs. The platform aims for extensive compatibility with the Ethereum Virtual Machine (EVM) within its custom virtual machine, optimized for zero-knowledge proofs.

(Source: matter-labs/zksync-era: zkSync era)

The stages of zkSync rollup operation can be summarized as:

1. Initially, a transaction or priority operation is generated by a user.

2. Subsequently, the operator takes on the responsibility of handling the user's request. Upon successful handling, the operator creates a rollup operation and includes it in the block.

3. After the block is completed, the operator moves on to submit it to the zkSync smart contract in the form of a block commitment. It's noteworthy that the smart contract verifies a portion of the logic of certain rollup operations.

4. Lastly, the block's proof is provided to the zkSync smart contract, in a step known as block verification. If the verification is deemed successful with a Verifier contract, it validates the new state as final. This concludes the zkSync rollup operation lifecycle.

This part delves into how zkSync operates, focusing on three fundamental layers:

1. Execution: This refers to the process that causes changes or transitions in the blockchain’s state. In simpler terms, it's where transactions are received and applied to the previous state.

2. Settlement: This ensures with a proof system that the changes made during the execution phase accurately reflect the system's overall state.

3. Data Availability: This is the system's record-keeping section. It's where all the transaction data (inputs), system changes (outputs), and proofs are stored. The purpose of this is to ensure that the system's current state can always be recreated from scratch if needed.

3.1 Execution

3.1.1 Execution in VM Level

It runs on a type4 zkEVM, which means it takes smart contract code written in a high-level language (e,g, Solidity, Vyper) and then compiles it to language that is designed to be zk-SNARK-friendly.

Also, a unique thing about zkSync Era is that it uses an LLVM-based compiler that will eventually let developers write smart contracts in C++, Rust, and other popular languages.

The LLVM framework is a compiler for building smart contract language toolchains. Its advanced intermediate representation (IR) permits developers to devise, implement, and refine effective language-specific features, while leveraging the broad LLVM ecosystem.

In the established toolchain, LLVM processes the LLVM IR, introduces comprehensive optimizations, and ultimately forwards the optimized IR to the zkEVM back-end code generator.

(Source: Overview | Welcome to our Docs | zkSync Era)

3.1.2 Execution Overview

In zkSync, the Core App plays a critical role in managing the execution layer.

Its first responsibility involves tracking the Layer 1 (L1) smart contract for deposits or priority operations. This mechanism is crucial for ensuring 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 Application is also tasked with managing a memory pool (mempool) that collects incoming transactions. This collection of transactions then waits in the queue for processing, effectively acting as a holding area before they are confirmed and added to the block.

An integral part of the Core Application's duties includes fetching transactions from the mempool, executing them within a virtual machine (VM), and adjusting the state as needed. In essence, this process involves picking up transactions, processing them, and reflecting the results in the system.

After executing the transactions, the Core App generates the chain blocks. These blocks consist of bundled transactions that have been executed and verified. Then the Core App submits these blocks and proofs to the L1 smart contract. This process ensures that the state of the L1 Ethereum chain is consistently synchronized with the L2 zkSync chain.

To allow seamless interaction for Ethereum-based applications, it provides an Ethereum-compatible web3 API. This makes zkSync more accessible and user-friendly for developers and users already familiar with the Ethereum ecosystem.

3.2 Settlement

This Settlement layer is responsible for ensuring the integrity of state transition zkSync. This verification process is done in the deployed smart contracts in Ethereum. There are two important contracts in this process

1. Executor Contract: This contract gets block data from a validator and zk proof of the state transition in zkSync.

2. Verifier Contract: This is a logic contract that allows the system to validate block data and zk proof provided from the Executor contract.

(Source: zkSync Era – L2BEAT)

3.2.1 Executor Contract

(Source Code, Contract Address)

The proveBlocks function has a central role in ensuring the integrity and security of the zkSync system. Its main job is to validate zk-SNARK proofs for submitted blocks. Here's how it works in a simplified explanation:

• First, proveBlocks makes sure that the blocks are being verified in the right order. It does this by checking that the previous block received is the next one that needs verification in the blockchain sequence.

• Next, the function begins to go through each of the submitted blocks. It's checking that the hashes of these blocks match what's expected for their specific place in the blockchain. This ensures that the blocks being verified are indeed the correct ones.

• The function then starts building what's known as a proofPublicInput array. This is a list that becomes the public input for the zk-SNARK proof verification process. The block number of each submitted block is included in this array.

• Afterwards, using the proofPublicInput array and some stored parameters, the function then checks the zk-SNARK proof. It's similar to solving a puzzle where all pieces should fit perfectly together.

• If the proof checks out, the function updates the system to reflect that these blocks have now been verified. It's like adding a tick next to the items on a checklist.

• Finally, for each block that has been verified, the function triggers a special event called BlockVerification. This is like sending out a notification that the block number, hash, and commitment have been verified.

In a nutshell, the proveBlocks function is like a vigilant gatekeeper, making sure that blocks are verified in the correct order, that the 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

(Source Code, Contract Address)

This is where the above verification logic is implemented. It acts as a guard for zkSync by checking zk-SNARK proofs to validate submitted data. The Verifier contract is used to verify that data submitted to zkSync is valid.

The Verifier contract stores the "verification key," which is used to verify these zk-SNARK proofs. Whenever zkSync wants to submit an update, it generates a zk-SNARK proof and submits it to the Verifier contract through Executor Contract.

The Verifier contract then uses the verification key to check if the proof is valid. If valid, it knows the update is legitimate without seeing the actual data. If invalid, it rejects the update.

By verifying these proofs, the Verifier contract ensures that only correct and valid data gets accepted into zkSync. This is crucial for security and preventing invalid state changes.

3.3 Data Availability

This section of the system functions as the archive, storing all transactional information (inputs), system modifications (outputs), and proofs. zkSync uses a smart contract interface to set its data availability (DA) policy. zkSync is planning to provide diverse options for DA for cost reduction and privacy.

3.3.1 zkPorter

(Source: zkPorter: a breakthrough in L2 scaling | by Matter Labs)

zkSync has introduced an off-chain data availability solution named 'zkPorter.' This tool is designed to integrate with zkSync's rollup system, fostering interactions between rollup and zkPorter accounts. To ensure data security within zkPorter, 'guardians' are used - individuals who stake zkSync tokens and verify data availability by signing blocks.

zkPorter operates as an internal consensus protocol, facilitating a high volume of transaction throughput. For comparison, the standard ZK Rollup mode in zkSync 2.0 is capable of processing roughly 1,000 to 5,000 transactions per second (TPS). In contrast, zkPorter can manage anywhere from 20,000 to 100,000 TPS, contingent on the complexity of the transactions.

One trade-off of utilizing zkPorter is that users must place their trust in zkSync's internal consensus mechanism. This results in a rollup solution that is less decentralized. The balancing act for users is to decide between zkPorter for a lower cost yet decreased security, or the ZK-rollup mode for the highest level of security.

In addition, zkSync 2.0 promotes interoperability, allowing for seamless exchanges between the ZK-rollup and zkPorter accounts. The fundamental distinction between zkPorter and Starkware’s Volition is in the determination of data availability: in zkPorter, this decision is made on an account basis, whereas in Volition, the decision is made on a per transaction basis within an account.

4. ZK-Stack and OP-Stack

Recently, Matter Labs announced the upcoming release of ZK-Stack. This would provide an OP-Stack-like software to customize and operate appchain rollups.

Common Traits of OP-Stack and ZK-Stack

1. Open-Source and Free: Both are developed under open-source licenses, guaranteeing cost-free access. They encourage developers to contribute and build based on the software

2. Interoperable: Hyperchains concept from ZK Stack can effortlessly link in a trustless network, featuring low latency and shared liquidity. Also, OP-Stack envisions a Superchain concept to connect all OP-Stack-based chains

3. Decentralization: In the pursuit of achieving a more distributed network and community, both OP-Stack and ZK-Stack have explicitly outlined plans for decentralization in their upcoming roadmap. This move not only increases the network's resilience but also ensures a fairer distribution of authority and control.

Although there are similarities from a philosophical standpoint, there are differences from technical and business standpoints. This part will delve into the difference between the below perspectives

1. Dapp Developer

2. Core Developer

3. Business

4.1 From Dapp Developer’s Perspective

4.1.1 EVM Equivalency

OP-Stack's EVM Implementation**:** OP-Stack's EVM is crafted with slight alterations to Ethereum's geth, resulting in a system almost fully compatible with EVM. On the other hand, ZK-Stack incorporates some changes in the EVM opcodes, with some opcodes not being supported. Despite these modifications, the impact is minimal, and the projects have been rigorously tested and proven in the real world.

However, there have been a few incidents arising from the non-EVM equivalency of ZK-Stack. A notable instance involved 921 ETH getting trapped in a smart contract because the contract utilized the transfer function. This issue has been effectively resolved.

4.1.2 Native Account Abstraction

Unlike ERC-4337, ZK-Stack's architecture includes a native Account Abstraction (AA) feature. In systems like ERC-4337, it is necessary to establish a separate UserOps mempool to permit account abstraction within the network.

4.1.3 Support for Privacy

By utilizing Validium, storing data on other confidential databases ensures privacy, provided the operator keeps the block data confidential. This feature is particularly advantageous for enterprise users.

4.2 From Core Developer’s Perspective

4.2.1 Infrastructure Operation: OP-Stack is more intuitive

Operation: Both zkSync and OP-Stack function via a Sequencer that orchestrates transactions and deposits data to Ethereum. Nevertheless, the operations for zkSync necessitate a prover. This prover application processes blocks and associated metadata generated by the server to construct a validity zero-knowledge (zk) proof. In comparison, OP-Stack doesn’t require separate complex infrastructure to participate in the proof-challenging game.

4.2.2 VM Alternatives: zkSync has potentials to provide more options

zkSync operates with an LLVM compiler that translates into zkEVM bytecode, indicating the potential to establish execution environments with other languages, such as C++.

4.2.3 Data Availability: ZK-Stack offers diverse options

OP-Stack relies mainly on Ethereum for its Data Availability layer, storing all transaction information and the output state root in Ethereum. This usage results in a substantial cost for operating an OP-Stack chain. Yet, there have been attempts to offset this cost by storing transaction data in Celestia DA.

ZK-Stack is vigorously researching and developing alternative data availability solutions like zkPorter. This approach enables users to determine their data availability based on their preference for higher security or lower cost. Additionally, enterprises desiring to maintain data privacy can adopt solutions like Validium, which allows data storage without disclosure.

4.3 Business Perspective: Cost and Revenue

Launching an independent rollup has become a feasible option today, especially with open-source software like ZK-Stack and OP-Stack being publicly developed and maintained. Additionally, Rollup-as-a-Service (RaaS) platforms such as Caldera and Conduit are significantly simplifying the process.

Taking a step beyond the viewpoint of a developer, it's crucial to realistically assess the potential costs and revenues associated with operating a rollup. However, projecting these amounts can be complex due to several variables.

As major improvements in the codebase are being made regularly, evident from the recent Bedrock upgrade from Optimism, the costs associated with running a rollup are rapidly reducing. This dynamic nature makes it challenging to estimate costs and revenues accurately. Furthermore, since a single entity usually manages all rollups, the specific costs linked to the server and infrastructure are not widely recognized. Lastly, the volatility of the base token price, such as $ETH for zkSync and Optimism, adds another layer of uncertainty as costs can swing according to market sentiment.

Some of the major costs and revenues are as follow:

4.3.1 Cost

• L1 publication cost: Costs on storing transactions, state root, proof data. Usually, optimistic rollup requires more publication cost since it requires storing raw transactions data for verification. Some rollups post the state diff rather than whole state data to avoid further cost.

• L2 Sequencer Operating cost

• Proving cost: For zk, proof generating and verifying cost and for fraud-proof, proof challenging cost.

4.3.2 Revenue

• L2 Transaction fee

• Possibly MEV, but currently, most L2 sequencers are known not to extract MEV to avoid centralization issue

5. Final Thoughts

Matterlabs has been deeply dedicated to the development of zkEVM, achieving significant advancements in the process. Despite not being fully EVM compatible (Type4 EVM), there appears to be substantial potential in harnessing LLVM. The next stage of progress for Matterlabs is the release of the ZK-Stack, a codebase that will enable developers to utilize its robust codebase for creating their own rollups. This tool promises to have a clear edge over OP-Stack, specifically in areas of privacy and scalability.

Nevertheless, both projects are still in its early phase and require considerable work. It is vital to conduct thorough evaluations of cost and revenue structures associated with its implementation. Moreover, a significant challenge lies in fostering a developer ecosystem around the two codebases. Detailed analysis and strategic planning are crucial to ensuring a sustainable future for the platform and its associated technologies.

I hope both projects flourish and building in public and sharing roadmaps become the norm in the web3 landscape.

Thanks to Kate for designing the graphics for this article and M3TA for providing valuable insights into on-chain data on zkSync.