ZKSync Products and Ecosystem: A Flexible Assembly Shortcut for Scalability

Author: echo_z, Chain Teahouse

With the launch of tokens by Optimism and the start of the Odyssey incentive war by Arbitrum, the second half of 2022 is destined to be a flourishing phase for L2. Previously, Chain Teahouse has detailed the background of L2 and provided a special introduction to StarkWare of the ZK series. As another representative project of the ZK series, ZKSync is also worth attention. This article will deeply analyze the product architecture and operational ecosystem of ZKSync within the framework of comparison with StarkWare.

1: Product System

ZKSync's products have existed for some time, but in the 1.0 phase, it only supported simple functions like payments; the 2.0 product achieved EVM compatibility and began to showcase its true capabilities.

ZKSync 2.0 launched its testnet in June last year but was not open to developers; in October last year, the first zkEVM product UniSync was launched, which is the Uniswap version on ZKSync. It wasn't until February of this year that ZKSync 2.0 development tools were finally opened to developers, allowing for ecosystem deployment. Currently, the ZKSync mainnet products are still in the 1.0 phase. This article will focus on introducing 2.0.

1.1 Proof System: SNARK vs STARK

ZKSync and StarkWare have chosen different proof systems at their core; ZKSync has opted for the more mature SNARK technology, while StarkWare has developed its own STARK system. The differences in underlying technology also lead to distinct performance potentials and product roadmaps.

The consensus in the industry regarding these two proof systems is: In cases of high computational load, STARK's scalability and speed will significantly outperform SNARK, and STARK is also more secure[1].

In terms of scalability and speed, STARK can generate proofs that include more computational results. Although STARK requires more bytes and takes longer to verify, the larger proof itself can lower the gas cost per transaction.

In terms of security, SNARK requires a trusted setup, which has certain trust prerequisites, while STARK does not require this prerequisite.

1.2 Data Availability Model: Mixed Mode Volition with Different Granularity

Data Availability simply refers to whether the necessary information, aside from the final state data of completed transactions, can be accessed to reconstruct transaction history. If all necessary data is stored on-chain, it is the Rollup model, which has a higher security level but is also more expensive due to consuming more on-chain storage space; if stored off-chain, it is the Validium model. The choice of data availability model is essentially a trade-off between security and efficiency.

In this regard, both StarkWare and ZKSync adopt the "Volition" model, which is a mix of Rollup and Validium, allowing users to choose how to store their data.

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

The concept of Volition was first proposed by StarkWare, and the above image is from their blog published in 2020. However, as of now, neither StarkWare nor ZKSync has implemented Volition. Nevertheless, ZKSync's roadmap seems to place greater emphasis on this feature, specifically naming it ZKPorter and listing it alongside zkEVM as two major breakthroughs in architecture[2].

It is worth noting that StarkWare and ZKSync have different settings for user-selectable "granularity." StarkWare has chosen a finer granularity, which is also more challenging to implement.

In StarkWare's vision, users will choose the data availability model on a "per transaction" basis. However, this may lead to a problem: if a user's account simultaneously selects both modes, will a problem with a Validium transaction of lower security level affect the subsequent Rollup transactions? According to StarkWare's early vision, to prevent attacks on data unavailability, a minimum rollback mechanism was designed, meaning that if data unavailability is detected, the transaction history will roll back to the last block state where data was available. In the worst-case scenario, this minimum rollback mechanism may require all data to be published on-chain, effectively reverting to the Rollup model[3]. Relevant details have yet to be disclosed, but it can be imagined that there are many challenges.

In ZKSync's design, users will choose the data availability model on an "account" basis. This means that transactions from Rollup accounts will all be conducted in Rollup mode, while redundant data from ZKPorter accounts will be stored off-chain. Thus, transactions under the two modes are isolated, each with its own transaction history, and will not affect each other. However, ZKSync will also allow interoperability between zkRollup and ZKPorter accounts, suggesting that such transactions will be recorded in both zkRollup and zkPorter to ensure security.

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

1.3 Development Language: Native Language Cairo vs Solidity Priority Strategy

For a long time, StarkWare has used the native language Cairo as its sole development language. Cairo is a language developed by the StarkWare team that adapts well to the STARK proof system, but the requirement for developers to learn a new language creates a high barrier to entry.

In terms of EVM compatibility, StarkWare's solution is the Solidity-to-Cairo compiler Warp, developed by a third-party team, Nethermind. The Warp 1.0 version did not gain much popularity due to the large size of the generated Cairo files, but the Warp 2.0 version significantly improved efficiency by leveraging Yul (an intermediate code for Solidity)[4]. This month, Warp 2.0 began its auditing process and is about to be put into use.

ZKSync, on the other hand, adopted a Solidity-first strategy much earlier, allowing developers to write contracts in Solidity when ZKSync 2.0 launched. Its implementation is shown in the following diagram: using LLVM as the compiler backend, Solidity is compiled to LLVM via Yul, and then compiled to zkEVM. The advantage of this approach is that in the future, other languages can also achieve compatibility through a similar method (i.e., first compiling to LLVM). Currently, ZKSync's development and maintenance focus on the Solidity language, with plans to develop a proprietary language, Zinc, and open compatibility for languages like Rust in the future.

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

ZKSync's strategy undoubtedly lowers the entry barrier for developers, with the core goal of quickly attracting ecosystem projects and accumulating TVL through EVM compatibility. However, given that StarkWare's compiler Warp 2.0 is about to launch, it is expected to similarly attract Solidity developers (though it is uncertain how much functional difference there will be), and ZKSync's development may be impacted.

1.4 Overall Architecture: Centered on Sequencer and Prover

The core architecture of the entire network will determine how the network achieves decentralization. Overall, both projects center their architecture around Sequencer and Prover. The core functions of the Sequencer include selecting valid transactions and executing computations, while the Prover generates proofs for the computation results.

StarkWare has not yet clarified whether the roles of Sequencer and Prover will be separate or combined, while ZKSync has already referred to the role of Sequencer as "full node," suggesting that it and the Prover will be independent entities[5]. Additionally, ZKSync's architecture includes an Interactor to assist in L2 and L1 interactions, compute transaction fees, and a Paranoid Monitor for health monitoring.

How to achieve decentralization is very important in the long run, but this issue is still a future concern for the relatively early-stage ZK Rollups, and currently, neither StarkWare nor ZKSync has a very clear answer.

1.5 Summary

This section compared StarkWare and ZKSync in terms of proof systems, data availability models, development languages, and overall architecture. Aside from the overall architecture where the core roles are similar but details remain unclear, there are significant differences in other aspects.

In terms of proof systems, StarkWare's STARK has stronger scalability and security than ZKSync's SNARK; in terms of data availability models, both provide a user-selectable Volition, but ZKSync operates on an account basis while StarkWare operates on a per-transaction basis, making ZKSync's granularity coarser and its path simpler; in terms of development languages, StarkWare prioritized the development of the native language Cairo and subsequently achieved EVM compatibility through a third-party developed compiler, while ZKSync adopted a Solidity-first strategy from the start, lowering the entry barrier for developers but still facing strong competition from StarkWare.

Overall, ZKSync's approach is more "user-friendly," and its products resemble an assembly model like Apple's, with core technologies such as SNARK and LLVM derived from existing industry or academic achievements; in contrast, StarkWare is more hardcore, choosing a more challenging original route in both technology and product aspects.

2: Operational Ecosystem

ZKSync's ecosystem projects are concentrated in the areas of DeFi and infrastructure.

On ZKSync's official website, one can see mature projects migrating to ZKSync 2.0 (some shown below), with DeFi projects including 1inch, FRAX, Zigzag, etc.; infrastructure projects include Gnosis Safe, Snapshot, cross-chain bridges like Orbit, and centralized exchanges like Banxa.

Source: https://ecosystem.zksync.io/

On its Notion page, emerging projects that are about to or have already been deployed on ZKSync 2.0 are listed. Among them, Trustless Currency Protocol is a collateral lending project similar to Maker, SyncSwap is a token exchange DEX similar to Uniswap. Mint Square is an NFT marketplace built on ZK Rollups, which has also been deployed on the StarkNet testnet, while tofuNFT is a multi-chain NFT marketplace deployed on multiple chains including BNB, ETH, and Arb.

Source: https://matterlabs.notion.site/zkSync-2-0-Testnet-Applications-e38328bccda7472793024a25e26a1cac

Overall, the ecosystem of ZKSync 2.0 mainly comes from the migration of mature DeFi and infrastructure projects, as well as the deployment of multi-chain NFT marketplaces. Besides that, there do not seem to be any particularly eye-catching projects. In contrast, the StarkNet testnet has many gaming projects and native DeFi projects, making its categories richer and more independent compared to ZKSync.

3: Team and Financing

Matter Labs co-founder and CEO Alex Gluchowski is from Germany and graduated from the Technische Universität Berlin in 2011 with a master's degree. He has held R&D/CTO positions at several companies. He started his entrepreneurial journey in 2013, co-founding the fitness platform Somuchmore GmbH (2013.12~2015.9) and the camper rental platform PaulCamper (2015.10~2017.8). In September 2017, he joined Entropy Labs in Hong Kong as an R&D engineer, marking his entry into the blockchain industry. At the end of 2018, he co-founded Matter Labs.

Another co-founder, Alexandr Vlasov, has a relatively simple background. He studied nuclear and particle physics at Moscow State University from 2006 to 2012 and obtained a PhD in electrical engineering from McGill University in Canada from 2013 to 2018. He then joined Matter Labs to oversee R&D.

As of now, Matter Labs has raised a total of $58 million, with $50 million coming from a Series B funding round in November 2021, led by a16z. a16z also invested in Optimism, betting on both the OP and ZK ecosystems.

In comparison, StarkWare has had successful experiences in the crypto industry with ZCash, led by professors, and has raised approximately $280 million, while ZKSync's team and financing are relatively grassroots.

4: Advantages and Challenges

ZKSync's style is somewhat similar to Apple's, adept at assembling mature technologies into user-friendly new products, and its Solidity-first strategy is very developer-friendly. For ZKSync, whether the existing zkEVM can quickly attract mature applications from L1 and increase TVL will be crucial. This may also be a shortcut for ZKSync to secure a place in the L2 competition.

However, in this regard, ZKSync faces competition from multiple fronts: the OP series' Optimism has already launched its token and can attract users through token incentives, while Arbitrum has recently started the Odyssey campaign to attract users and funds through marketing activities; StarkWare, which has always been based on the native language Cairo and has a relatively independent ecosystem, is also about to launch an upgraded Solidity compiler, lowering the entry barrier for developers. In this L2 competition, the speed of ZKSync will be critical.