ZK World pt. 3 - zkSync

Deep Dive on zkSync

*** This is giga-brain material… I have tried my hardest to distill into digestible form. If I got something wrong please let me know. Always trying to improve. Also, this is kinda long… my b

Welcome to the third part of the “ZK World” exploration in which zkSync takes center stage!

Quick refresher - part one served as an introduction to L2 scaling, while part two went deep into zero-knowledge proofs (zkp).

Introduction for ZK World pt. 3:

Blockchains face tradeoffs between decentralization, security, and scale in which the blockchain solves for two and sacrifices on the third. Ethereum has valued decentralization and security, thus needs some help with scalability. Rollups allow for a general-purpose computing environment and have been the focus of Ethereum L2 scaling. The two most prominent forms of rollups are fraud proof (optimistic rollups) and validity proof (zero-knowledge rollups). Zk-rollups (zkr) are widely considered the end state for L2 scaling but it was thought that a general-purpose zkr was years away (per Vitalik himself). There have been major technological breakthroughs and now general-purpose zkr L2’s are launching on Ethereum mainnet. zkSync is one of the most promising projects in the zkr space and is in the process of launching a “zkEVM” on Ethereum mainnet.

---

Beginnings

Matter Labs (ML) was founded in late 2018 by Alex Gluchowski and Alexandr Vlasov to focus on Ethereum layer 2 (L2) scaling; receiving a grant from the Ethereum Foundation in March 2019¹. ML describes itself as, “an engineering team passionate about liberty, blockchain, and math”². The goal is to scale Ethereum to enable the mainstream adoption of public blockchains using the most viable available technology - ML believes this to be zkr.

Philosophically, ML makes very idealistic claims about its values; stating that it sees itself in the line of the cypherpunks. It is interesting to note co-founder Alex Gluchowski’s is from Ukraine, a place that has experienced economic uncertainty and political corruption over the past few decades. This focus on digital liberty and decentralization is clear in the zkSync platform and is in contrast to its main competitor (StarkWare - more on this to come).

Investors:

ML has raised two investment rounds. In March 2021, $6m was raised in a Series A round led by Union Square Ventures; also of note in the round were previous investors Placeholder and Dragonfly. What is unique about this round is that it also included strategic investor partnerships in an “ecosystem round”. These strategic investors are some of the most prominent companies and founders in the digital asset space³.

Most recently in November 2021, ML raised $50m in a Series B round led by Andreessen Horowitz. Strategic partners involved in the financing include many of the top centralized exchanges (CEXes - Blockchain.com, Crypto.com, ByBit, OKEx). In the days following the announcement of the financing, many of the CEXes announced partnerships with zkSync for CEX to L2 deposits/withdrawals⁴.

Products:

In 2019, ML launched their first public prototype zkr⁵. This was followed up by zkSync 1.0 that went live on Ethereum mainnet in July 2020⁶.

What is zkSync 1.0?

zkSync 1.0 is a zkr protocol L2 scaling solution built on Ethereum. It is application specific with a focus on payments. As an L2 solution, zkSync 1.0 has the following benefits⁷:

• Low transaction fees

• Transaction fees payable in token being transferred (i.e. do not have to pay all transaction fees in ETH)

• Instant confirmation of transactions; finality within minutes (next Ethereum block)

• Withdrawal to L1 after ~15 minutes (instead of 7 days for fraud proof L2 - Optimism and Arbitrum)

zkSync 1.0 is an impressive technological achievement but its usability is limited by the fact that it is not EVM compatible (application specific and not general-purpose). The most applicable use case is payments given the low transaction fees and efficiency in finality and withdrawal times.

zkSync 2.0 is an EVM compatible L2 solution built on Ethereum; it is often referred to as “zkEVM” because it creates an EVM compatible environment by compiling EVM code (Solidity, Vyper, Yul) using zkp technology to verify the rollup transactions. For those familiar with Optimism and Arbitrum, zkSync 2.0 provides very similar capabilities (porting Ethereum applications from L1 to L2) using different technology (zkr instead of optimistic rollups). zkSync 2.0 offers a unique architecture referred to as volition - a hybrid between rollups and validium (more on this later).

The project initially launched on testnet in May 2021 with the ambitious goal to go live on mainnet in August 2021⁸. This timeline has since been delayed due to technical difficulties (the team has been transparent in providing updates⁹). That said, a fork of Uniswap has been launched on zkSync 2.0 testnet.

The remainder of this piece will focus on zkSync 2.0 given its potential as a general-purpose L2 platform. First, let’s take a quick look at the current landscape.

Environment:

Optimistic rollups - Arbitrum and Optimism - have been first to come to market with many dApps already deployed on their platforms. As the chart below indicates, Arbitrum has been most successful thus far in gaining users. This makes sense given the fact that Arbitrum has deployed a lot more dApps compared to Optimism. What is interesting is the rise of zkSync users over the past month or so. zkSync has not yet launched its EVM compatible zkEVM. All of these users are using zkSync 1.0 which, as noted above, offers limited functionality. In spite of this, zkSync is creeping up on Arbitrum for the Ethereum L2 crown.

Cute introduction but play time is over… into the weeds!

---

EVM compatibility

zkSync uses SNARK’s in their zk-rollups. Remember from part two, SNARK’s are one of two forms of zkp (the other being STARK’s). The main issue with SNARK’s is the trusted setup required at their genesis, which results in security vulnerabilities. The SNARK proof system initially used by zkSync was Groth16. Using Groth16, the trusted setup would not only need to occur once (at the genesis of zkSync for example) but the trusted setup would need to also occur for each new application (and application update) running on zkSync. This makes it cumbersome to create an EVM compatible environment and is why zkSync 1.0 focus was application specific (i.e. payments).

This all changed with the introduction of a new SNARK proof system called PLONK in late 2019. How exactly a PLONK functions is very technical - more can be read here. What is important is that with a PLONK SNARK, the trusted setup process only needs to occur once (i.e. a PLONK is a universal and updatable SNARK) and as long as at least one of the parties involved in the trusted setup process remains true, the system is safe. In not having to redo the trusted setup process, it opens the door for EVM compatibility (which is why PLONK’s were such an important breakthrough).

How does EVM compatibility work for zkSync 2.0?

“zkEVM” as zkSync calls it is not a 1:1 EVM replica, rather it aims to be able to run 99% of contracts written in Solidity while maintaining its same behavior¹⁰. In order for this to function, a compiler converts source code written in a programming language into another programming language. zkSync 2.0 uses an LLVM compiler, which converts the main EVM languages - Solidity, Yul, and Vyper - as well as zkSync’s own language - Zinc into SNARK compatible code. Below is a depiction:

What the LLVM compiler effectively does is to take smart contract code (written in Solidity for example) and converts it to SNARK friendly code which can run on zkEVM (with minimal changes to the original code). This allows for composability with other smart contracts!

zkSync has stated that in the short-term the focus is on being able to efficiently port smart contracts from Ethereum L1 to zkSync 2.0; thus the focus on compiling Solidity. That said, over the long-term zkSync sees Rust based languages winning. With Zinc being zkSync’s own Rust based language, Zinc will become focal point over time given it is more efficient for writing smart contracts¹¹.

---

Zk-rollups in practice

Before diving into the architecture of zkSync 2.0, it is important to get an idea of how zk-rollups work.

The concept of a rollup is to move transaction execution off-chain while maintaining some per transaction data on-chain. Moving execution off of L1 helps the blockchain scalability, while some per transaction data remaining on L1 allows the rollup to be EVM compatible. Very important: rollups also inherit the security guarantees of the underlying L1 by providing data availability on-chain.

To maintain and update the state of the rollup, Merkle tree cryptography is used. Merkle trees allow blockchains to store extensive amounts of data that makes verification of the data efficient. Merkle trees are structures of transactions that results from transactions in a block being hashed together. Effectively, each transaction in a block is hashed, then each pair of transactions is concatenated and hashed together; this process repeats until there is one hash for the entire block. The resulting hash is the Merkle root (i.e. the hash of all the hashes of all the transactions in the block)¹².

For a rollup, there is a smart contract on L1 which maintains the “state root”. The state root is the Merkle root for the state of the rollup. What this means is that the state root maintains the state (account balances, contract code, etc.) of the rollup (i.e. what the account balances are inside the rollup)¹³ which is then reconciled to L1 after each batch of transactions. Below is a simple depiction.

When a new batch of rollup transactions is processed, this batch together with the previous state root form the new state root (this is how the state of the rollup is updated). The L1 smart contract then verifies the updates. This verification process takes two forms - fraud proof (optimistic rollups) or validity proof (zk-rollups). In part one of this adventure there was a comparison between the two.

Pause…

Okay so… rollups execute transactions off-chain (on L2), group these transactions together into a transaction batch, then send to L1 for verification. To do this in an efficient way, Merkle tree cryptography is used in which the state root of the rollup is maintained by a smart contract on L1. There are two main groupings of rollups - fraud proof and validity proof. The difference between the two comes down to how the L2 state transition is verified.

Continue…

zkSync uses validity proof verification (aka - zk-rollups which are zkp). With a fundamental understanding of how rollups work in general, now let’s double click on zk-rollups specifically!

Zk-rollups grant the ability to prove honest computation without providing the inputs to that computation.

Remember from part two of this ZK World series, a zkp is based on the idea of a prover and verifier. The prover does complex work to provide a proof to the verifier and the verifier can easily verify the integrity of the work based on the proof itself. This is conceptually how the verification process in a zk-rollup works. It is possible due to the cryptography and mathematics behind a zkp.

Bringing it together into a concrete example…

Users can deposit funds from L1 onto L2 - in this case from Ethereum mainnet to zkSync. Once those funds are on L2, users transact using decentralized applications (dApps) - for example: ZigZag exchange to trade ETH on zkSync. The cumulative transactions from L2 are grouped into batches by a prover (also called a coordinator or validator). In order to update the rollup state and reconcile the state on L2 to L1 (remember by reconciling the L2 state back to L1 and having L1 smart contracts verify the updates a rollup is able to maintain L1 security), the prover submits three things to L1:

1. “root hash” of the new state for the rollup

2. zero-knowledge proof (SNARK or STARK)

3. Change in the rollup state published as “calldata”

Huh?

1. Rollups use Merkle tree cryptography. The “root hash” represents the hashed batch of transactions sent to L1. The L1 smart contract will use this to update the state root of the rollup on L1 (i.e. update the account balances of the rollup on L1).

2. L1 needs to verify that this update is correct. Remember the goal of rollups is to help the blockchain scale, thus verifying this update as efficiently as possible. The magic of a zkp is that the verifier can verify the update just based on the proof itself (the proof being the output of the provers computation). The zkp sent with the state update (root hash) for the batch allows the verifier to quickly verify the state transition instead of having to manually check.

3. The zkp only guarantees the validity of the state but does not provide the data (account balances) to L1. Therefore, a user cannot actually prove to L1 (Ethereum) their account balance but is instead relying on the prover’s computation. In order to ensure users can prove their account balances without the zkp, the data is published to L1 in the form of calldata. This allows users to recreate the state and prove ownership on L1.

Below is an attempt to visualize how a zk-rollup works at a high level.

Few quick notes:

• There are two primary types of zkp - SNARK’s and STARK’s. In part two there is a detailed breakdown. zkSync uses SNARK’s. Below is a quick comparison between the two:

• More detail on calldata:

  • From a EVM computational perspective there are three locations to store variables - storage, memory, and calldata. As I understand it, calldata is a special data location which represents the cheapest location to use; calldata is also immutable (it cannot be altered)¹⁴. This makes it well suited for the purposes of cheaply maintaining the rollup state for users to check on L1.

  • For zkSync not all the account balances/transactions are published each batch as calldata on-chain. What is actually published is the “state delta” (the difference in balance for each account from the start of the batch to the end of the batch). This mechanism results in less data being sent —> uses less Ethereum gas —> is less expensive —> resulting in better scalability.

  • There is an Ethereum Improvement Proposal (EIP) currently up for debate that would reduce the transaction calldata gas cost and implement a total calldata limit. The reduction in calldata gas costs will help rollups scale, while the limit ensures safety of the protocol. This is a nuanced topic but early estimates note that the change could reduce fees on rollups by up to 5x current levels¹⁵.

Summary of efficiencies brought about by zk-rollups:

• instead of publishing the entire batch of transactions to L1, the L2 transactions are hashed together into a Merkle tree with only the state root of said Merkle tree maintained in the L1 smart contract.

• to update the rollup state root on L1, the prover does extensive work off-chain so that the L1 smart contract can efficiently verify and update the state on-chain.

• calldata is the cheapest way to store data on L1. The rollup state changes from batch to batch are sent as calldata to L1. This maintains data availability on-chain.

The net result of these efficiencies is zk-rollups being up to 100x cheaper than Ethereum L1 transactions.

Hopefully this provided a high level introduction into how zk-rollups work. The next section will focus on the architecture of zkSync 2.0. Yay!

---

“Have your cake and eat it too” - zkPorter

In part one of this adventure there was a table that depicted the four main types of scaling solutions in matrix form with their basic properties.

The architecture of zkSync 2.0 is comprised of both zk-rollup and validium modes of operation. This dichotomy was labeled “volition” by StarkWare due to the fact that it gives users the choice between zk-rollup and validium¹⁶.

Let’s dive in…

Validity proofs (zk-rollups) and fraud proofs (optimistic rollups) are the two methods by which L2 batches are verified on L1. Data availability on-chain (meaning on L1) for a rollup was elaborated upon in our example above. The change in the rollup state is sent as calldata to L1 (thus the data is available “on-chain”) so that the rollup state can be reconstructed (allowing users to prove their balances on L1 - in doing so are guaranteed L1 security).

So… combining a validity proof with on-chain data availability is a zk-rollup; which was discussed at length in the previous section. Zk-rollups result in L2 transactions being up to 100x cheaper than Ethereum L1. The problem is that data availability being on-chain and the limited L1 block space available means that a zk-rollup provide linear scalability but not exponential scalability¹⁷.

Using the same verification method - zkp - there is a way to (at least theoretically) exponentially scale a blockchain. The tradeoff to do so is to move data availability off-chain (which means less security relative to data availability on-chain). Using zkp to verify the batched L2 transactions, while having data availability off-chain is termed validium.

There are different methods of implementing data availability off-chain. zkSync 2.0 utilizes a proof-of-stake (PoS) system, while StarkNet utilizes Data Availability Committees (DAC).

zk-rollups + validium = volition… how does it all work?

Within the zkSync 2.0 architecture, there will be zk-rollup accounts and validium accounts (called zkPorter). Depiction 1:

The zk-rollup accounts will function as described above; zkp used for verification and on-chain data availability. The zkPorter accounts will also use zkp verification but data availability will be maintained off-chain in PoS system. Users will have the choice on which account they would like to use at a given time based on their idiosyncratic preferences. More details:

• zkPorter state updates will not be published to L1 as call data. Rather, the root hash of the zkPorter accounts will publish to L1. This ensures that users of the zkr accounts can reconcile accounts on L1 no matter the state of zkPorter accounts.

• zkPorter account data availability is published to another network that is maintained by “Guardians” as part of PoS system (which will be similar to other L1 PoS systems).

The PoS system that maintains zkPorter accounts works like this - there are Guardians and validators:

• Validators are responsible for grouping zkSync 2.0 transactions into batches and completing the computational work to produce the zkp (similar to the “prover” in the zkr explanation above).

• Guardians are zkSync token holders who stake their tokens. The Guardians have to sign-off on each state transition (batch of transactions) with super-majority (two-thirds majority). If any Guardian acts maliciously they risk having their stake slashed.

ML’s ultimate goal is to have zkSync be completely censorship resistant and to be able to run without any intervention from ML. In reality achieving this goal is a process that is often referred to as progressive decentralization. Currently, the validator is centralized (it being ML itself who currently does this). In the future, there will be a number of validators who are nominated and kept in check by Guardians. These validators will post a security bond to L1 that can be slashed if the proper transactions are on included within a given block.

The Guardians will be comprised of zkSync token holders who stake their tokens to the zkPorter PoS network (thus the Guardians will maintain data availability for zkPorter and monitor validators against censorship). Both the validators and Guardians will be rewarded with some percentage of fees. Over time, this should ensure the decentralization of the system.

Below is a depiction from a presentation given by zkSync which brings it all together.

It is important to note that the zkr accounts security is not impacted by the volition architecture (i.e. zkr accounts still maintain L1 security). When it comes to security for zkPorter there are two scenarios to think about:

1. If one-third plus one of the Guardians are malicious then there will be no blocks because the super-majority will be broken

2. If two-thirds of the Guardians are malicious then could freeze the entire zkPorter state (this would also freeze their stakes so unlikely)

Ultimately, zkPorter funds can only be frozen, never stolen.

There is a great chart that zkSync provides to summarize the scalability and security tradeoffs between the different architectures¹⁸:

As the graph above indicates, the creation of a volition architecture allows for massive scale.

---

zkSync v. StarkNet

The next saga of the adventure (ZK World pt. 4) will be comprised of a deep dive into StarkNet. Thus, in this section there will be a high level comparison between zkSync and StarkNet (more detail on StarkNet to come in part four).

ML co-founder Alex Gluchowski recently did an AMA on Reddit in which he discussed his view on the philosophical differences between zkSync and StarkWare¹⁹.

From his view, zkSync values freedom and resilience against powerful adversaries (digital freedom) above all else. Thus, the team is building an open protocol optimized for decentralization and resilience. While from Alex’s perspective, StarkWare is building proprietary scaling solutions optimized for performance and defensibility of intellectual property.

Both parties have different perspectives and philosophies that drive the direction of their respective projects. Given the idealist dreams of the digital asset space as a whole, it is always important to keep this in mind.

Now… quick overview of some of the important differences between the two:

The differences between SNARK’s and STARK’s was discussed in part two. Both zkSync 2.0 and StarkNet have a zk-rollup component and a validium component (aka: volition). There are two major differences:

• zkSync 2.0 will implement the decentralized validators/Guardian PoS architecture using zkSync tokens to handle off-chain data availability, while StarkNet relies on a Data Availability Committee (DAC) which is more centralized.

• zkSync 2.0 will offer two separate accounts - zk-rollup and zkPorter - in which the user will switch between the two accounts before transacting. Thus, the user is making the tradeoff between cheaper fees and lower security at the account level. For StarkNet, users will be able to decide which mode they want to use - zk-rollup or validium - on a transaction-by-transaction basis (i.e. at the transaction level).

zkSync’s focus has been on establishing EVM compatibility by making it easy for existing contracts to convert code to zkEVM. The idea being that zkSync will first convert established dApps to L2, then focus on native Zinc language application development in the long-term. StarkNet has been more focused on developing and promoting its native Cairo language but has recently announced they are working on a transpiler that effectively converts current smart contracts into Cairo so they can run on StarkNet.

---

Ecosystem & Roadmap

Infrastructure:

Ahead of the launch of zkSync 2.0, the ecosystem is in the process of building out infrastructure and integrations. As was mentioned above, in both its Series A and Series B financing strategic investment partnerships have been formed to help bootstrap the nascent ecosystem. In the Series A financing, many leading Ethereum protocol companies and founders were involved in the round. Thus, these parties will have a vested interest in helping to convert Ethereum L1 dApps to zkSync 2.0. The recent Series B round of financing included many centralized exchanges (CEX) as strategic investment partners. Many of these CEXes have already announced integrations with zkSync to efficiently move funds to L2. There have also been multiple fiat-to-L2 on-ramps built.

Applications:

The first use case to gain traction for zkSync 1.0 was an integration with GitCoin to fund grants. Currently, the main application in use on zkSync is ZigZag exchange, a decentralized exchange (DEX) offering a trades in a limited number of assets. There is also the ability to mint NFT’s using zkNFT. We are still early…

Roadmap:

zkSync 1.0 was a zk-rollup with functionality limited to application specific use cases - that being payments. Launching zkSync 2.0 and building out the ecosystem is the primary focus right now. Once the protocol has developed enough, the focus will shift to working on privacy and decentralization.

Team:

There is not a ton of information available about individual team members (again… the opposite of StarkWare). Alex G. is the co-founder who does all the interviews to explain to product. His background is software engineering and entrepreneurship. Alexandr Vlasov (the other co-founder) has a PhD in Electrical Engineering from McGill University in Canada.

Deep breath…

---

Conclusions

• Through strategic partnerships, zkSync has built relationships with applications and exchanges. It is early but fiat to L2 on-ramps and CEX to L2 ramps are huge step to onboarding users (avoid Ethereum L1 gas fees). Given relationships, Ethereum dApps should port to zkSync en mass once it launches. This could lead to massive growth leading zkSync the most used Ethereum L2.

• zkSync’s focus on EVM compatibility (converting existing L1 contracts to L2) in the short-term and native language Zinc in long-term seems to be winning strategy as it is paramount to build user base (flywheel effect with more users leading to more active developer engagement that then leads to more users, etc. - adding a token also helps). After initially taking the opposite approach (focusing first and foremost on native language), StarkNet has shifted focus to EVM compatible transpiler.

• One major driver of recent user growth is the decentralized future. Users want to be early to new protocols and have the chance at ownership of those protocols. The hype around zk-rollup technology and the hope for ownership (airdrop) has fueled growth. It will be interesting to see if StarkNet gains the same level of traction once users can onboard.

• In in the long-term, it seems many think STARK’s are the superior technology (and StarkWare the superior team). It will be important to monitor if zkSync’s short-term advantages (already building strong user base and primed to convert many applications from L1 given partnerships and LLVM compiler) persist into long-term success relative to StarkNet (not that it is necessarily winner take all).

1. https://blog.matter-labs.io/grant-from-the-ethereum-foundation-for-matter-labs-64338f3dd938

2. https://matter-labs.io/

3. https://blog.matter-labs.io/leading-defi-projects-and-exchanges-invest-to-bring-solidity-to-zksync-9a3df978f824

4. https://blog.matter-labs.io/funding-ea89c1fa731e

5. https://www.coindesk.com/business/2021/11/08/andreessen-horowitz-leads-50m-funding-round-for-matter-labs/

6. https://blog.matter-labs.io/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58

7. https://blog.matter-labs.io/zksync-is-live-bringing-trustless-scalable-payments-to-ethereum-9c634b3e6823

8. https://blog.matter-labs.io/zksync-2-0-hello-ethereum-ca48588de179

9. https://blog.matter-labs.io/zksync-2-0-developer-update-d25417f16446

10. https://blog.matter-labs.io/zksync-2-0-hello-ethereum-ca48588de179

11. YouTube: “zkEVM & zkPorter with Matter Labs”

12. https://www.blockchain-council.org/blockchain/what-is-merkel-tree-merkel-root-in-blockchain/

13. https://vitalik.ca/general/2021/01/05/rollup.html

14. https://ethereum.stackexchange.com/questions/74442/when-should-i-use-calldata-and-when-should-i-use-memory

15. https://polynya.medium.com/why-calldata-gas-cost-reduction-is-crucial-for-rollups-30e663577d3a

16. https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb

17. https://blog.matter-labs.io/zkporter-composable-scalability-in-l2-beyond-zkrollup-2a30c4d69a75

18. https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf

19. https://www.reddit.com/r/ethereum/comments/q8q822/ama_were_matter_labs_the_team_behind_zksync_the/hgsjjxf/?utm_source=reddit&utm_medium=web2x&context=3