Zero-Knowledge Proofs and zkEVM: Where Do They Come From and Where Are They Going?

by Aki Labs - Roy, Lyv

Behind the current hot zk-Rollup track, we have always hoped to clarify why this cutting-edge blockchain technology has emerged, the differences in solutions from different teams, and how these differences might lead us to distinctly different ecosystems.

1. Zero-Knowledge Proofs

First, we need to clarify that Zero-Knowledge Proofs (ZKP) are indeed very difficult.

If we were to summarize ZKP in a few sentences, there would certainly be misunderstandings and factual discrepancies. However, we believe that in the face of the immense charm of TL;DR, people won't mind too much. Let's illustrate the principles of ZKP through three progressive scenarios based on real-life situations.

Scenario A:

Imagine the scene at the end of summer vacation when school starts, and the teacher checks the "Summer Life" assignments, with a thick stack of notebooks submitted by the whole class. The teacher cannot correct each problem one by one, so he starts flipping through the exercise books quickly, checking whether there are any blank spaces to determine if the students have completed all the assignments.

• In this scenario, the teacher does not know whether each student answered the questions correctly; he can only confirm whether the students have completed their homework.

Scenario B:

He notices that some students have filled in the blanks with nonsensical content like "Häagen-Dazs ice cream" or "KFC Crazy Thursday," and he realizes he was too naive—students are cheating. So he returns all the assignments and announces that he will randomly check some questions, hoping the students will take it seriously.

• In this scenario, the teacher verifies a very small portion of the questions through random sampling to determine whether the students have correctly completed their homework.

Scenario C:

After collecting the assignments for review, most students completed their homework well out of fear of being randomly checked, and the teacher is relatively satisfied. However, there are always some who continue to cheat; they will scribble on a random few questions. The teacher can only randomly check a portion of the questions, and if it weren't for the bad luck of some students who happened to be checked on that question, they might have gotten away with it.

• Therefore, the teacher ultimately needs a solution that can ensure each question is answered correctly while minimizing his workload.

This is the real challenge that zero-knowledge proofs overcome in the blockchain: how to ensure the overall correctness of answers while verifying as few questions as possible. In the above scenarios, the answers to each question have no logical connection; the correctness of one question does not relate to the correctness of another. So, is there a clever way for the teacher to check one question and determine whether the entire assignment is answered correctly?

Now, here comes the surreal part: the teacher wants to "string" all the correct answers together and introduces a new mathematical tool: polynomials. By constructing equations involving polynomials for verification, it is possible to almost simultaneously confirm both the correctness of individual answers and the overall correctness of the students' work. Thus, the teacher can finally confidently announce that the students have correctly and completely completed their summer homework.

So what kind of magic is a polynomial?

Here's a simple example: there are only three questions, with the numbers and answers being (1,4), (2,6), (3,3), which can be "strung" together to get y = -52x² + 192x - 3.

At this point, the teacher only needs to complete two steps to grade the homework: 1) Check the polynomial itself to verify overall correctness; 2) Randomly select a point to verify that this student indeed answered that question. Of course, this is a very naive example; in actual engineering, we construct equations involving polynomials, where one part is a statement expressed in mathematical language that needs verification, and the other part is verifiable and complete information "strung" together with polynomials (smart readers may have already thought of the concept of Data Availability, DA).

Polynomials have many wonderful properties, and in zero-knowledge proofs, we mainly utilize two of them:

1. The original information is "strung" together, and verifying a set of points in a polynomial equation can simultaneously verify the entire equation.

2. If a polynomial equation holds at certain randomly chosen points, then it is highly likely that the equation holds over the entire set.

In summary: the essence of zero-knowledge proofs is a probabilistic proof, i.e., sampling (roughly equivalent to validity proof), while introducing polynomial construction and some cryptographic tools to compensate for the completeness flaws of simple random sampling.

Interestingly, in the context of rollups, the "zero knowledge" of zero-knowledge proofs is more reflected in the compression of information in validity proofs rather than intuitively processing the privacy of each individual piece of information.

2. So what is the use of ZKP?

I believe you have heard of ZK-Rollup. We spent a lot of time earlier explaining how the teacher finds ways to be lazy while checking homework, and what ZK-Rollup does is to be lazy.

In short, for example, if there are currently one thousand statements (usually transactions), with the help of ZK, only ten verifications are needed to prove their correctness. As the workload of proof increases, the corresponding increase in the number of verifications required is far below a linear relationship; that is, if the number of statements increases to ten thousand, the number of verifications does not increase to one hundred times; we may only need eleven times to prove it.

So this is a very good scaling solution. Similar to other scaling solutions (like Optimistic Rollup), the current application process of ZK-Rollup is as follows:

1. Users lock assets in a ZK-Rollup smart contract on a certain L1.

2. Users start to conduct transactions, which are organized and packaged by the L2 sequencer, generating a validity proof (using ZK proof here) and updating the state in each batch.

3. The state updates and proofs are submitted to the ZK-Rollup smart contract on L1 for verification to update the L1 state.

4. Users use the updated state on L1 to perform the next operation.

3. ZK-Rollups vs Optimistic Rollups

As one of the two technical routes of Rollups, ZK-based Rollups provide higher security. This is because ZK-Rollups rely solely on mathematics and the security guarantees provided by Ethereum itself, while Optimistic Rollups depend on economic incentives and penalties under a game-theoretic framework.

For users, this means that ZK-Rollups have faster L1 finality confirmation, while Optimistic Rollups need to wait a week for a challenge period. Of course, there are now various cross-chain protocols that can make the user experience of Optimistic Rollups more convenient and quick through DeFi means, such as Celer, Stargate, Across, Synapose, etc. However, this often comes at the cost of sacrificing some overall security to enhance the experience of localized single-point users, and the withdrawal fees paid by users in these protocols are generally several times that of official withdrawal channels.

Although ZK Rollups enjoy theoretical advantages over OP Rollups, the current situation is that the ecosystem based on ZK-Rollups is still far less prosperous than that of OP Rollups, making it difficult for users to obtain a similar interactive experience in the ZK ecosystem, and ZK Rollups also struggle to demonstrate advantages that can only be realized after scaling (high concurrency, low latency, L1 interaction security, etc.).

4. So where is the problem with ZKP?

Since ZKP theoretically became usable no earlier than 2015, Ethereum had no relation to ZKP at its inception. From reading the first section, you might have a vague feeling: this is a very mathematical thing. Your feeling is correct; the most direct problem it brings is that the core infrastructure of EVM is not compatible with ZK-Rollup, due to reasons including but not limited to Ethereum's storage layout and signature encryption mechanism. The computations of Ethereum EVM are based on the normal mathematical world, while ZKP computations and proofs are in prime fields. (Note: This point is logically parallel to the previous two.)

Such incompatibilities bring a significant additional burden (overhead) of on-chain computations for blockchain projects based on ZKP; secondly, because ZKP requires engineering implementation, the complexity of implementing mathematical concepts like arithmetic circuits and logic gates becomes a constraint that developers must consider when programming, forcing them to make trade-offs between development learning costs and implementation accuracy.

At the application level, the existing technology stack based on ZKP is either deployed on L1 smart contracts pointing to a specific L2 ZK-Rollup (which I call general ZK-Rollups here) or is a dedicated ZK-Rollup designed based on Dapp, such as dYdX V3, which uses a ZK-Rollup (essentially a dedicated ZK-Rollup based on Starkware).

Regardless of the form, the significant differences at the mathematical level lead to poor composability of these ZK projects with other projects. For example, a DeFi protocol deployed in the ZK-rollup ecosystem wants to find a credible oracle; this demand is real. However, since this protocol is developed based on ZK-Rollup, it becomes very difficult to interact with others; for instance, Etherscan cannot simply fork on a ZKP-based blockchain to directly serve that chain.

5. Why is compatibility with Ethereum (or EVM) important?

Because the Ethereum ecosystem is large, the more your chain resembles it, ideally just differing in Chain ID, the greater the probability that your ecosystem will be supported by apps developed based on Ethereum. For example, Polygon has long been committed to supporting Ethereum, providing various efficient and inexpensive scaling solutions, making significant contributions to the development of users and the Ethereum ecosystem.

From the user's (developer's) perspective, familiarity, low cost, and painless transition are the gold standards. For the vast majority of developers, the learning cost of a new high-level language (like Rust/Move) is far lower than that of learning a serious mathematics course (not to mention the complex engineering applications introduced by ZKP). Therefore, the difficulty of re-developing a protocol project on a new public chain, such as Solana/Aptos, is much lower than that on a relatively unfamiliar blockchain based on serious, precise, and complex mathematical logic languages (ZK-based).

Of course, this does not mean that creating a new standard is impossible. With a strong development team and moderate economic incentives, Solana has also achieved great success. With the support of EVM, the Cosmos ecosystem has successfully attracted a large number of Solidity developers to deploy their protocols.

Therefore, if ZKP can be painlessly compatible with EVM, developers will find it easier to port existing Dapps and smart contracts to ZK-based L2 or develop entirely new types of Dapps within this new framework. Furthermore, if the composability issues mentioned in the fourth section can also be improved, allowing ZK-based projects to interact better with other applications, we will achieve a more prosperous ZK-based L2 ecosystem. In this regard, the underlying driving forces of ZK L2 players and L1 players like Solana and Aptos are consistent.

6. So is there a way to make ZKP compatible with EVM?

Yes. Many teams are currently working on this.

6.1 Wait, what is EVM?

EVM is the virtual machine that runs smart contracts on Ethereum.

6.2 Wait again, what is a virtual machine?

A virtual computer that is almost identical to a real computer, simulated by software.

6.3 So why does Ethereum need a virtual machine?

Because Ethereum introduced smart contracts, and executing contracts requires a computer. In a decentralized network, the premise for achieving consensus is that different nodes must produce the same result when computing and processing the same contract, meaning that different computers calculating 1+1 (in the real number domain) should all yield the result of 2. However, each node's physical computer may have different underlying environments, so to avoid interference from these underlying environmental differences, smart contracts need to run on a virtual machine to ensure that the same problem produces the same result, i.e., determinism.

Many articles or tweets have summarized the technical differences between these different routes, and I won't elaborate further here, as you may not be interested. So let's talk about common sense, business, and more user-oriented aspects.

The first question is what kind of expectations we have for the ecosystem.

Currently, teams like ZkSync and StarkWARE have developed many application-specific zk-rollups, and their B2B business has matured, such as Immutable on Starkware hosting highly anticipated large Web3 games. However, due to the reasons discussed in previous sections (mainly the lack of composability), these projects are still waiting to form a common and shared ecosystem for collective development.

Scroll, Polygon Hermez, and zkSync Era are making efforts to build a ZK-based L2 ecosystem by reducing the difficulty of developing and porting existing protocols to an almost painless level. In the process of achieving complete EVM equivalence (Type 2 by Vitalik), we are currently at a stage of "almost" EVM equivalence (Type 3 by Vitalik) in practice. For example, zkSync Era allows 99% of Ethereum projects to be deployed without needing to refactor or re-audit any line of code.

For users, if there is not a significant difference in the interactive experience, the choice of which chain to use often depends on which chains they are already using. Polygon has a certain advantage in this regard, especially since its existing ecosystem hosts a large number of native gaming and social protocols and users, as well as unique exposure to Web2 brands.

However, we believe that Scroll and zkSync Era will not face significant obstacles in attracting existing protocols to deploy in the short to medium term, mainly based on the following long-term observations of the developer ecosystem:

• The deployment and development difficulty of Ethereum ecosystem Dapps on ZK-based L2 is gradually decreasing to the tipping point that triggers large-scale migration.

• Cross-chain protocols for L2 to L2 and L1 to L2 are gradually becoming simple, convenient, and inexpensive, and L2 native directional cross-chain bridges are also expected to emerge, although centralized challenges may still exist in the long term.

• From the fields we are familiar with, due to the expectation of economic incentives and active operations (referencing the successful multi-round airdrop incentives of Optimism, the operational logic of the Arbitrum developer community, etc.), users can try multiple protocols across multiple chains.

The second question is how to transition from centralization to decentralization.

First, it should be noted that the vast majority of ZK-Rollups currently have a very centralized structure. A significant reason for this is path dependence: because there is currently no composability, there is no need to combine with others, so centralization is not a concern for now. However, if we want to develop into an ecosystem, this centralization issue must be addressed.

Currently, mainstream ZKEVM solution providers recognize the necessity of solving this problem. In this regard, Scroll, Polygon Hermez, and zkSync Era believe that the process of promoting the decentralization of prover networks and sequencer networks should be gradual and ultimately achieve outsourcing computational power and marketization of prover/sequencer work through token economics, although there are still differences in specific implementation steps among different parties.

So we return to familiar territory: those with money contribute money, those with strength contribute strength, and then everyone waits for the platform to distribute dividends. Here we have a small concern that the cost of generating proofs is actually very high, so the threshold for provers in zk-based L2 will be much higher than that of corresponding departments in PoS chains; and the issue of sequencers producing erroneous blocks is actually a common problem for all blockchain networks and does not belong solely to zk-based L2. Therefore, I believe that in the ZK ecosystem, the decentralization of the prover network may face greater challenges.

7. Aspirations for the Development of ZK-based L2 Ecosystem

StarkNet:

As the highest-valued Ethereum ZK scaling solution in private equity and the founder of the cryptographic theory of zk-STARK, the technical faction represented by StarkNet has always been the industry standard. Founder Eli Ben-Sasson is even the inventor of zk-SNARKs and ZK-STARKs, which are widely used in blockchain.

However, we also find that in many product configurations that are crucial for integration with the Ethereum EVM ecosystem, the StarkNet ecosystem is still exploring more developer-friendly and mass-oriented solutions due to its technical path. We believe that in the future, the StarkNet team may continue to execute a dual strategy:

1. On one hand, continue to use customized development services through mature StarkNet for projects with large-scale ZKP needs, such as AAA productions from Web2 game manufacturers or large-scale experiments in on-chain metaverses by IP holders.

2. On the other hand, enhance the overall synergy with the Ethereum ecosystem by supporting smart contract wallets (Argent X, Braavos), middleware bridges for Cairo x Solidity developers (Kakarot, Wrap), etc.

Unlike OP-Rollups, which need to establish smart contract wallets together with the Ethereum mainnet through EIP-4337, StarkNet has supported account abstraction-based smart contract wallets on L2 from the very beginning. Smart contract wallets deployed on StarkNet can utilize the cryptographic security capabilities of built-in chips in mobile phones to achieve hardware signing and multi-factor authentication, and complete scenarios like social recovery and mobile wallet payments through innovations at the blockchain contract layer.

At that time, we can imagine a large mobile hardware company entering StarkNet and Web3 with a massive Web2 user base, using metaverses or large on-chain games as an entry point.

zkSync Era:

Recently launched zkEVM 2.0, zkSync is also one of the most anticipated zk L2 solutions, focusing on extremely high performance ceilings while balancing security and user experience, with a maximum TPS potential of over 20,000. The latest zkSync Era utilizes a Solidity compiler based on LLVM, zkSync's self-created award-winning GPU prover, and the upcoming Redshift proof system from Matter Labs, which will reduce the cost of each transaction to far less than one cent.

zkSync Era also aims to address blockchain data storage issues, providing an innovative zkPorter feature on top of EIP-4844, allowing users and developers to choose data availability formats based on different security level needs, balancing development focus between high-performance validium (zkPorter) and high-security validity (zk-Rollup).

Additionally, zkSync Era introduces the fractal scaling solution of Hyperchains as its primary development direction for "L3." Hyperchains are zkEVM-like fractal instances utilizing LLVM (the world's most mature compiler stack architecture) that can achieve parallel operation and joint settlement on L1. Anyone can deploy Hyperchains without permission; it features a highly customizable modular zkEVM chain stack supported by the same zkEVM engine as the main zkSync L2. Developers can choose different solution routes, select corresponding virtual machines (e.g., MoveVM), sequencer designs, and data availability (such as the zkRollup, zkPorter, and zkValidium mentioned earlier).

The introduction of such a highly customizable modular stack in zkSync Era inevitably reminds us of the OP stack that recently entered the public eye through Coinbase's Base chain.

We believe that zkSync's B-side development path may reference Optimism's experience, leveraging existing large-scale users and strong institutional supporter backgrounds to establish a virtuous cycle of airdrop expectations and governance mechanisms (Token House, RetroPGF, etc.) with the developer community. This can promote innovative applications that go beyond basic infrastructure while encouraging the latest versions of existing protocols (like traditional DeFi blue chips on L1) to come to Era for deployment.

From the C-side perspective, zkSync Era may start from the currently not very strong Web3 social aspect of Ethereum L2, focusing on building the strongest social network and social graph applications within the Ethereum system to attract more lightweight Web3 users. We note that Hyperchains also have an innovation that is very suitable for social protocols. It can also be used to achieve high concurrency and temporary execution environments. For example, developers can launch a Rollup to cheaply mint millions of homogeneous NFT assets within a social network, then bridge these NFTs to another execution layer, and finally close the temporary Rollup, providing necessary infrastructure capacity elasticity for social protocols.

Polygon zkEVM:

Polygon's overall strategy has always been very clear, and the team has executed it very decisively. We see that a differentiated competition has already formed between Polygon and other Ethereum Rollups. In the social ecosystem, Polygon has become one of the two giants in Web3 social alongside BNB, thanks to the Lens Protocol ecosystem and Galxe. Games like Planet IX, Hunters On-Chain, and Benji Bananas also have hundreds of thousands of monthly active wallet addresses. Recently, Polygon zkEVM also announced a strategic partnership with Immutable at the 2023 GDC conference to better serve studios and developers in creating high-quality on-chain games. According to a report by Cumberland, Polygon is expected to achieve an annual revenue of $300 million from non-crypto partners in the short to medium term, which is more than ten times its current daily revenue of several tens of thousands of dollars.

Most notably, Polygon has become the ambassador for Web3 in traditional industries through partnerships with numerous brands outside the blockchain industry. Through close collaboration with Forum3, the organizer of Starbucks' Odyssey event, Polygon is expected to welcome 27 million almost entirely new blockchain users in North America over the next year, which would be a seismic shift for the industry's existing user base. Polygon has also recently joined Disney's accelerator program, integrated with Stripe's global payment system, supported Reddit's meme NFT system, and established commercial partnerships with world-renowned brands like Adobe, Nike, Adidas, Mercedes-Benz, Mastercard, and Coca-Cola.

We believe that Polygon zkEVM (Hermez) can inherit the strong competitive edge of the entire Polygon ecosystem in traditional fields, achieving a more complete integration with zkEVM L2 and the Ethereum ecosystem, allowing Web2 brands to enjoy the asset security premium brought by Ethereum L1. We are optimistic about the rapid growth of the gaming and social sectors within the Polygon ecosystem.

Scroll:

As the youngest Ethereum zk L2 solution, Scroll may be the development team that is closest to the Ethereum Foundation, gathering one of the latest and most powerful zero-knowledge proof teams. Scroll is striving to catch up with the development progress of other zk-based rollups based on its technical capabilities and iteration speed.

Scroll is at the forefront of the decentralized design of prover networks and sequencers, particularly proposing solutions to enhance computational power using GPU/ASIC to decentralize the verification network. The EVM of Scroll theoretically has a higher ceiling of code compatibility compared to zkSync Era and Starkware, meaning developers do not need to trust a new virtual machine and compiler (like zkSync's LLVM) and can also avoid the risks associated with achieving EVM compatibility through an intermediate code during transaction execution (as seen in Polygon zkEVM's current solution).

From day one, the Scroll team has been deeply tied to Ethereum's core activities, building its brand recognition and infrastructure suite, such as oracles and wallets. Although all Ethereum L1 and even L2 protocol developments can theoretically be quickly deployed to Scroll, we believe that Scroll's greatest opportunity lies in capturing the crown jewel of DeFi: decentralized central limit order book exchanges (CLOB). The powerful performance potential of Scroll, combined with the urgent demand for a secure and efficient trading environment from the vast liquidity seeking safety on the Ethereum mainnet, may lead to an explosion of such DEX protocols. We also note that Web3 projects like Lens Protocol are starting to attempt deployments on Scroll, and we look forward to more similar good news.

Introduction: Aki Labs is a deep research institution under Aki Network, dedicated to combining the business logic and technical theory of the blockchain industry with engineering practice, conveying the most thought-provoking and forward-looking voices to our community.

Details link