zkEVM and hardware analysis

2023 is the first year of ZK’s outbreak, and there are already some opinions. In this article, we will focus on discussing different types of zkEVM and ZKP’s hardware track, etc., and will analyze them one by one. At the investment research meeting on the ZK theme initiated by ChainTimes last week, everyone actively communicated. This article will sort out the analysis on zkEVM and hardware shared by MetaStone Capital.

01.About zk-rollup

As an Ethereum scalability solution, Rollups can bundle and compress transactions through its own network and send them to the Ethereum chain for verification. It can increase the operating efficiency of the network by verifying multiple transactions on the network at one time, and also This is to increase the number of transaction executions and achieve expansion.

Through the number of transactions executed at one time by Rollups itself, the TPS problem that Ethereum has been criticized for can be improved. Based on the security of Ethereum itself, the number of executable transactions can be increased by several orders of magnitude.

zkRollups can combine privacy with solutions through zero-knowledge proof technology, which allows one party to prove something to another party without revealing the information proving that party, thereby achieving privacy. Of course, not all zkRollups will take advantage of the privacy properties of zero-knowledge technology. At the same time, compared to L1, zkRollups has stronger economies of scale. As for L1 Ethereum, its cost and processing speed are generally not suitable for more and more users. For zkRollups, it is more More transaction users will further reduce the cost of using the network and achieve the original purpose.

The obvious benefits of applying zk-rollup on ETH are:

1. Sharing the security of the Ethereum consensus layer

2. Solve the scalability problem in the impossible triangle of blockchain

3. Huge network effects

02. How EVM and zkEVM work

a. Working principle of EVM

Smart contract bytecode is loaded from the EVM’s storage and executed by peer-to-peer nodes on the EVM.

EVM opcodes interact with different parts of the EVM state and perform read and write operations (including memory and stack)

The EVM opcode performs calculations on the value obtained from the state store before returning the new value to complete the state transition.

b. How zkEVM works

That is, a zero-knowledge proof is generated to verify each of the above processes, a validity certificate is generated, and submitted to the ETH verifier contract for verification. Verification includes seeing whether the correct value is obtained from the old state, whether there is a deviation in the calculation, etc. The process of generating a validity proof is also the process of making a zero-knowledge proof circuit.

3.zkEVM execution program

01. The basic conditions of zkEVM require an evm-compatible virtual machine to execute opcodes and run smart contracts.

02. There is a verification circuit that generates zero-knowledge proofs. Complete the proof generation process using pre-state, transaction input, and post-state information as input

4. Compatibility issues between Scroll and zkSync, Starknet, and Polygon

Because EVM did not consider the issue of zkp calculation when it was originally designed, there are two ways to combine zk+zvm:

a. Compilation method

Starknet itself uses the Cairo language (zero-knowledge proof system language). If developers want to move eth applications to starknet, they need to borrow the starknet team's compiler for compilation, allowing projects written in Solidity to "one-click" their code base ” Translates to Cairo.

zksync is also compiled in language. Through the intermediate language YUL, using the LLVM framework, the solidity contract bytecode is compiled into the YUL language, and then compiled into the zksync ZKEVM executable bytecode set through the YUL bytecode.

Polygon is compiled on bytecode, and the open source solidity bytecode is compiled into polygon uvm executable micro-operation code, which actually replaces the evm native operation code. But the point of progress is to complete evm compatibility from the bytecode level.

b.scroll is the process of designing zero-knowledge circuits for evm opcodes

Scroll will execute the smart contract on the EVM, transfer the smart contract bytecode to the memory, execute it one by one with the opcodes, obtain the Merkle tree, and customize a circuit for each tree. Each opcode has a circuit and when combined, there is no translator step and no need to modify anything.

The bytecode-level zkEVM is developer-friendly: low-threshold deployment is one point. In addition, without converting Solidity code into another coding language, developers can directly use common Ethereum development tools, libraries, wallets (such as MetaMask), Market and debugger, this is the most critical. On the contrary, using language level compatibility will cause certain difficulties for developers to use eth tools and migrate Ethereum ecological applications, and the compatibility will be poorer.

Compatibility aside, how to compare ZK-EVM:

In an open source environment, the differences between the various ZK solutions of the overall Prove system are very small, and the differences are not significant, which weakly affects the efficiency of Prove. In terms of engineering, it is measured in terms of proof complexity, verification complexity, communication complexity, etc., as well as the overall circuit development ideas. It is impossible to judge who will win in the end. Because network effects, community culture, operation promotion, wealth effects, developer support, etc. are all the most important elements of the ecosystem.

5. Current types of ZKP

To prove a computation through ZK, you usually need to translate a traditional program into a ZK-friendly program.

The more complex the calculation is, and it is not friendly to ZK, the slower the process of generating proof will be. Some operations are not friendly to ZK (sha/bitwise operation). If the calculation is friendly to ZK, the faster it will be. The proof system Currently there are PLONK, Spartan, and STARK. These proof systems can output a proof based on input.

However, the current bottleneck in generating proof is nothing more than one of the two. All proof systems basically include two algorithms: FFT and MSMs. The main factor limiting the speed of the two algorithms currently depends on the cost of hardware and bandwidth costs.

The current hardware types mainly include the following three types of GPU FPGA ASIC. Currently, ZKP is still in the early development stage. There is still little standardization work on system parameters (such as FFT’s width or element’s bit-size). The selection of proof system is also There is no relevant standard.

Based on the above factors, for ZKP scenarios, FPGA has 2 core attributes that make it better than ASIC:

01Write multiple times” VS “Write once”

The business logic on the ASIC is write-once. If there are any ZKP logic modifications, you need to start over. FPGA can re-flash within 1 second and supports re-flash countless times, which means that the same hardware can be reused between different chains running incompatible proof systems (for example, if you want to extract MEV across chains), and the same hardware can be reused at any time. Adapt flexibly to changes in ZK "meta".

02Healthier Supply:

ASIC design, manufacturing and deployment typically takes 12 to 18 months or more. The FPGA supply chain is healthy. Leading FPGA suppliers such as Xilinx allow bulk orders to be placed online (that is, no other contact is required) and arrive within 16 weeks. This allows FPGA-centric operations to have a tighter feedback loop on their products and expand their operations by purchasing and deploying more FPGAs.

And we also expect that FPGA performance will be better than GPU, mainly for two reasons:

1) Hardware overhead: Top FPGAs (leading processing nodes, clock speeds, energy efficiency and memory bandwidth) are about 3 times cheaper than top GPUs. Global demand for GPUs further exacerbates the problem.

2) Power consumption efficiency: The energy consumption of FPGA is >10 times higher than that of GPU. The main reason is that GPU needs to be connected to a host device, which usually consumes a lot of power.

We think the future winners in the market will be: FPGA > ASIC (or GPU). If only one or a small number of ZK L1 or L2 solutions dominate the scale in the future, and the ZK proof system will stabilize around a single implementation, then ASIC may exceed FPGA. But at present, this situation will not happen in a few years.

Bitcoin miners earned over $15 billion, and Ethereum miners earned just over $17 billion. Zero-knowledge proofs will eventually become the de facto medium for computational integrity and privacy on the web, in which case the opportunity for ZK miners/provers may be similar in size to the proof-of-work mining market.

ZKP is slow and requires hardware acceleration to implement complex calculations. We believe that the most important technology for ZK hardware acceleration is FPGA, not GPU (limited by cost and energy efficiency) or ASIC (limited by its inflexibility and long iteration cycle).