The ultimate core function of Ethereum may be a distributed ledger positioning of DA+Settlement+Consumus, and eWASM's zkWasm solution is more suitable for building applications. ZkEVM continues to optimize the blockchain ecosystem, and zkWasm accepts more development possibilities after its launch

The ultimate core function of Ethereum may be a distributed ledger positioning of DA+Settlement+Consumus, and eWASM's zkWasm solution is more suitable for building applications. ZkEVM continues to optimize the blockchain ecosystem, and zkWasm accepts more development possibilities after its launch. BuildRollupswitzkWasm, notjustBlockchains.

preface

Last August, Vitalik released an article titled 'The Different Types of ZK EVMs', which comprehensively compared the current mainstream expansion solutions from the perspectives of compatibility and performance (see figure below), sparking a lot of discussion and reflection throughout the community until today.

The different types of ZK EVMsOverview

The current solutions for zkVM expansion are basically centered around zkEVM's solution, as other zkVM solutions have some incompatibility issues with the continuation and support of the existing ecosystem. However, the issues after startup will be an important component of upgrading Web2 to Web3.

Especially after the emergence of solutions that are compatible with many languages such as C++, Rust, Go, AssemblyScript, and C #, represented by zkWasm, it became possible to upgrade the account system for Web2 applications; The expected zkEVM moves forward to the left and zkWasm moves backward to the right.

ZkEVM forward, zkWasm after startup

In the Rollup era, there is no need to create too many chains because chains play the role of ledgers, meaning that the account layer is separated from a separate application and returns to the general layer, with ownership returning to users; Chain is naturally such a carrier, responsible for the essential functions of Data Availability (DA), Settlement, and Compensation.

AppRollupismuchmoreflexiblethanAppchain

ZKP, Zero Knowledge Proof

In cryptography, zero knowledge proof or zero knowledge protocol is a method in which one party (the verifier) proves a proposition to the other party (the verifier), characterized by not disclosing any information during the process except for the fact that the proposition is true. Therefore, it can be understood as a "zero leakage proof".

Originally developed by ShafiGoldwasser from MIT Silvio Micali and Charles Rackoff proposed in a 1985 paper titled "Knowledge Complexity of Interactive Proof Systems (GMR85)". The author mentioned in the paper that it is possible for provers to have verifiers without disclosing specific data Believe in the authenticity of the data. Zero knowledge proof can be interactive, meaning that the verifier must prove the authenticity of the data once for each verifier; It can also be non interactive, where the certifier creates a proof that anyone who uses it can verify.

Development History of Zero Knowledge Proof

Zk SNARK (SuccinctNon Interactive Arguments of Knowledge) may be the most popular form of zero knowledge proof, first appearing in the 2011 Bit+11 paper. By 2013, thanks to the PinocchioPHGR13 paper, zero knowledge proof could be used in practical applications, making zk SNARKS suitable for general computing, despite its slower speed. The Groth16 algorithm proposed in 2016 greatly reduced computational complexity, making zk-SNARKS highly efficient and still the standard to this day.

However, 'trusted settings' are crucial for the security of these zero knowledge protocols. The initial process must be used to generate encrypted parameters in order to run the zero knowledge protocol. This operation is performed by a third party to ensure that the encryption parameters are random, unpredictable, and secure.

Subsequently, Bulletroofs (BBBPWM17) were introduced in 2017, and zk STARKs (BBHR18) were introduced in 2018. Unlike their predecessors, they are scope proof types that do not require initial trust settings. In the 2019 PlonK paper, a universal zero knowledge proof algorithm was implemented, which means that only one trust setting needs to be activated, whereas Groth16 requires a separate trust setting for each circuit.

Due to the development of the field, zero knowledge proof has transitioned from pure theory to practical applications in blockchain, secure communication, electronic voting, access control, and gaming. As they continue to be put into commercial applications, there will be more exciting developments to advance technology.

So, zk SNARKS, zk STARKS, PLONK, and Bulletproofs constitute the main implementation methods of zero knowledge proof at present. Each method has its own advantages and disadvantages in terms of proof size, verifier time, and verification time. In the expansion solution of blockchain, the implementation mainly revolves around ZK-SNARK-friendly.

WASM, WebAssembly

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

One of the main motivations for developing WebAssemblies is to provide compilation targets for a wider range of programming languages (C++, Rust, Go, etc.), allowing developers to develop new web applications or port existing applications using a wider toolset.

Wasm layout

Whether it's Web2 or Web3, the support and scope of use for Wasm are also becoming increasingly widespread.

Major companies and organizations in the WebAssembly ecosystem

ZkWasm=zkp+WASM

As a rising star of zkVM, zkWasm essentially solves complex operations offline, stores proofs on the chain, and is compatible with the mainstream language of Web2. It realizes the connection upgrade between Web2 and Web3, performs complex business logic offline calculations, and saves valuable results and proofs on the chain for traceability, verification, and liquidation. The account system consists of an existing wallet system, and the entire ecosystem can be represented by the following figure:

ZkWasm Ecology

The overall logical direction of the data can be represented by the following figure:

On ChainContracts+Off ChainVirtualMachine (VM)+WASMComposability

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

ETH2.0 Overall Planning

Although eWASM has not been mentioned in recent planning, the benefits that eWASM can bring 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 stated that the creation of EVM did not have a "large number of design ideas". He believed that EVM was designed from a theoretical rather than practical perspective, so although it is internally sound, it cannot perform its best in the real world.

Nick Johnson agrees with this view that, in contrast, Wasm's writing is closer to actual hardware instructions, which makes it more effective in translating actual coding logic. In fact, the Wasm instruction can directly map one-on-one to the instructions used by the machine, which greatly improves performance. At the same time, Ewasm can reduce or even eliminate the need for pre compilation, support more languages for interoperability, and benefit from a wider toolset than EVM.

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

Performance: Compared to EVM, eWASM provides better performance because it uses WebAssembly, designed to be faster and more efficient than EVM bytecode. WebAssembly provides performance close to native, which can significantly improve the speed and scalability of Ethereum networks.

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

Security: eWASM provides better security than EVM because it includes multiple security features, such as a memory sandbox, which can isolate smart contracts from each other and prevent them from accessing each other's memory. In addition, eWASM provides better protection against common smart contract vulnerabilities such as re-entry attacks and integer overflow.

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

However, for Ethereum, this may be an ultra long term plan, and the various security risks and existing ecological impacts during the replacement process cannot be underestimated. Perhaps this is also the reason 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+Consumus, which does not require too many modifications to Ethereum itself and other unknown risks for many scalability needs. The way to have both fish and bear's paw is through hierarchical division of labor, and placing eWASM on the second layer should be a more reasonable and effective solution.

Especially when combined with zk, zkWasm's technical solution can effectively inherit the effect that eWASM wants to achieve. By combining zkEVM and zkWasm, traditional EVMDapp can be inherited forward, and applications written in more languages can be expanded backward, thus achieving true "continuity".

ZkWasm=zkp+WASM