OPRR Flash Depth Activities

Search Extension

Exploring the future of Ethereum scaling, zkEVM and zkWasm are the next step

0xTodd

23-11-14 14:15

Read this article in 21 Minutes

AI summary

View the summary

Original title: "zkEVM + zkWasm: A trend that builds on the past and opens up the future"

Original author: putin learning blockchain, 0xTodd

The ultimate core function of Ethereum may be a distributed ledger positioning of DA + Settlement + Consensus. eWASM with zkWasm solution is more suitable for building applications. zkEVM optimizes the blockchain ecosystem, and zkWasm opens up more development possibilities. Build Rollups with zkWasm, not just Blockchains.

Foreword

Last August, Vitalik published the article The different types of ZK-EVMs, which made an overall comparison of the current mainstream expansion solutions from the perspectives of compatibility and performance (see the figure below), which triggered a lot of discussion and thinking in the entire community until today.

The different types of ZK-EVMs Overview

Current zkVM expansion solutions are basically centered around the zkEVM solution, because other zkVM solutions have certain incompatible issues with the continuation and support of the existing ecosystem, but in terms of the issue of starting from the future, it will be an important part of the upgrade of Web2 to Web3.

Especially after the emergence of solutions such as zkWasm, which are compatible with many languages such as C++, Rust, Go, AssemblyScript, C#, etc., it has become possible to upgrade the account system of Web2 applications; it is expected that zkEVM will inherit the past on the left and zkWasm will start the future on the right.

zkEVM inherits the past and zkWasm starts the future

In the Rollup era, there is no need to create too many chains, because the chain plays the role of the ledger, that is, the account layer is separated from the individual application and returns to the general layer, and the ownership returns to the user; the chain is naturally such a carrier, assuming the essential functions of Data Availability (DA), Settlement and Consensus.

AppRollup is much more flexible than Appchain

ZKP, Zero-Knowledge Proof

In cryptography, zero-knowledge proof (English: zero-knowledge proof) or zero-knowledge protocol (zero-knowledge protocol) is a method for one party (prover) to prove a proposition to another party (verifier). The characteristic is that no information is disclosed except that "the proposition is true" in the process. Therefore, it can be understood as "zero leakage proof".

It was first proposed by Shafi Goldwasser, Silvio Micali, and Charles Rackoff of MIT in a 1985 paper titled "Knowledge Complexity of Interactive Proof Systems" ([GMR85]). The authors mentioned in the paper that it is possible for a prover to convince a verifier of the authenticity of data without revealing the specific data. Zero-knowledge proof can be interactive, that is, the prover must prove the authenticity of the data once for each verifier; or it can be non-interactive, that is, the prover creates a proof and anyone who uses this proof can verify it.

History of Zero-Knowledge Proofs

zk-SNARK (Succinct Non-Interactive Arguments of Knowledge) is probably the most popular form of zero-knowledge proofs, first appearing in the Bit+11 paper in 2011. By 2013, zero-knowledge proofs could be used in real-world applications thanks to the Pinocchio PHGR13 paper, which made zk-SNARKS suitable for general computation, albeit at a slower speed. The Groth16 algorithm proposed in 2016 greatly reduced the computational complexity, making zk-SNARKS very efficient and still the standard today.

However, a "trusted setup" is critical to the security of these zero-knowledge protocols. An initial process must be used to generate cryptographic parameters in order to be able to run the zero-knowledge protocol. This is performed by a third party to ensure that the cryptographic parameters are random, unpredictable, and secure.

This was followed by the introduction of Bulletproofs (BBBPWM17) in 2017 and zk-STARKs (BBHR18) in 2018. Unlike their predecessors, they are types of range proofs that do not require an initial trusted setup. The 2019 PlonK paper implemented a universal zero-knowledge proof algorithm, meaning that the trusted setup only needs to be initiated once, compared to Groth16, which requires a separate trusted setup for each circuit.

Due to developments in the field, zero-knowledge proofs have transitioned from pure theory to having useful practical applications in blockchain, secure communications, e-voting, access control, and gaming. As they continue to be put into commercial applications, there will be more exciting developments to advance the technology.

Therefore, zk-SNARKS, zk-STARKS, PLONK and Bulletproofs constitute the main implementation methods of zero-knowledge proofs at present, and each method has its own advantages and disadvantages in terms of proof size, prover time and verification time. In the expansion solution of blockchain, it is basically centered around ZK-SNARK-friendly implementation methods.

WASM, WebAssembly

WebAssembly (abbreviated WASM) is a relatively new member of the Web technology family (JavaScript, HTML, CSS) and became an officially recognized standard by W3C in December 2019. WebAssembly introduces a new runtime in the browser that works in conjunction with the JavaScript runtime. In contrast, it is lighter, has a small instruction set and a strict isolation model.

One of the main motivations for developing WebAssembly is to provide compilation targets for more programming languages (C++, Rust, Go, etc.), allowing developers to use a wider set of tools to develop new web applications or port existing applications.

Wasm Landscape

Whether it is Web2 or Web3, the support and use of Wasm are becoming more and more extensive.

Major Companies and Organizations in the WebAssembly Ecosystem

zkWasm = zkp + WASM

As a newcomer to zkVM, zkWasm essentially solves complex calculations off-chain, stores proofs on-chain, and is compatible with the idea of mainstream Web2 languages to achieve the connection upgrade between Web2 and Web3. Complex business logic is calculated off-chain, and valuable results and proofs are stored on-chain for traceability, verification and settlement. The account system is composed of the existing wallet system. The entire ecosystem can be represented by the following figure:

zkWasm Ecosystem

The overall data logic trend can be represented by the following figure:

On-Chain Contracts + Off-Chain Virtual Machine (VM) + WASM Composability

An important core of the initial Ethereum 2.0 update also included the transition from EVM to eWASM; however, the actual progress of 2.0 was not as expected, so eWASM was not mentioned too much in the latest planning plan.

ETH 2.0 Overall Planning

Although eWASM is not mentioned in the recent planning, the benefits of eWASM are also recognized. From the beginning, EVM was designed to emphasize correctness rather than efficiency. This is reflected in the fact that all nodes on the network must run EVM completely and accurately.

Although Wasm is similar to EVM, it was invented for the web. Unlike correctness, Wasm emphasizes efficiency and fast loading. Ethereum developer Lane Rettig said that the creation of the EVM did not have "a lot of design thought". He believes that the EVM was designed from a theoretical perspective rather than a practical perspective, so although it is internally sound, it cannot play the best role in the real world.

Nick Johnson agrees with this view. In contrast, Wasm is written closer to actual hardware instructions, which makes it more efficient in translating actual coding logic. In fact, Wasm instructions can be directly mapped one-to-one to the instructions used by the machine, which will greatly improve performance. At the same time, Ewasm can reduce or even eliminate the need for precompilation, will support more languages in interoperability, and will benefit from a wider set of tools than EVM.

The main advantages of using eWASM over EVM that are recognized by the mainstream are as follows:

Performance: eWASM offers better performance than EVM because it uses WebAssembly, which is designed to be faster and more efficient than EVM bytecode. WebAssembly offers near-native performance, which can significantly improve the speed and scalability of the Ethereum network.

Interoperability: eWASM offers better interoperability than EVM because it supports multiple programming languages, including C++, Rust, and AssemblyScript. This enables developers to write smart contracts in their favorite language, thereby improving code quality and developer productivity.

Security: eWASM offers better security than EVM because it includes multiple security features, such as memory sandboxing, which isolates smart contracts from each other and prevents them from accessing each other's memory. In addition, eWASM offers better protection against common smart contract vulnerabilities, such as reentrancy attacks and integer overflows.

Flexibility: eWASM provides better flexibility than EVM because it supports dynamic linking, which allows smart contracts to consist of multiple modules that can be updated independently. This can lead to better code organization and easier smart contract maintenance.

However, for Ethereum, this may be a very long-term plan, and the various security risks and the impact of the existing ecology during the replacement process should not be underestimated. Perhaps this is why eWASM has not been mentioned too much in the latest plan.

Many community members realize that the ultimate core function of Ethereum is a distributed ledger positioning of DA + Settlement + Consensus, so that many scalability requirements do not require Ethereum itself to make too many modifications and bring other unknown risks. The way to have both fish and bear's paw is to divide the work in layers. Putting eWASM on the second layer should be a more reasonable and effective solution.

Especially after combining with zk, the technical solution of zkWasm can well inherit the effect that eWASM wants to achieve. In this way, through the cooperation of zkEVM+zkWasm, the traditional EVM Dapp can be inherited, and applications written in more languages can be expanded, thus realizing the true "inheritance".

zkWasm = zkp + WASM

【References】

https://jhc.sjtu.edu.cn/~hongfeifu/manuscriptb.pdf

https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm-game-1.pdf

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

https://vitalik.ca/general/2021/01/26/snarks.html

https://vitalik.ca/general/2022/08/04/zkevm.html

https://twitter.com/VitalikButerin/status/1588669782471368704

https://github.com/DelphinusLab/zkWasm href="https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/" rel="noopener noreferrer" target="_blank">https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/