Some thoughts on “how EOF affects zkEVM”

I have done some research on EOF in the last few days. It can be considered one of the biggest improvements in EVM since Genesis Block. I was curious about how this would affect zkEVM.

The following information is very helpful to understand EOF :point_down:

  1. EOF consists of five EIPs, namely 3540 (EOF container introduced), 3670 (validation rules for EOF contract), 4200 (replacement of dynamic jumps), 4750 (EVM functions + complete removal of dynamic jumps), 5450 (stack underflow/overflow validation rules).

  2. The most significant improvement EOF brings to EVM is “Versioning”, which facilitates EVM to introduce/remove a feature. In addition, the EOF contract disables dynamic jumps, shifting some validation from runtime to deployment time (which reduces EVM overhead, saves Gas, makes the contract more secure, etc.).

  3. According to the ACD#151 meeting, EOF will be deployed in Shanghai Upgrade (around March 2022). But Shanghai Upgrade is centered on Beacon Chain Withdrawals, and if EOF delays withdrawals, it will be abandoned.

  4. After EOF deployment, EVM will keep both sets of rules (they work in parallel). The existing contracts will be called “legacy contracts” and the new contracts will be called “EOFv1 contracts”.

Initial thoughts on the possible impact on zkEVM: If all contracts are legacy contracts, there is no impact on our zkEVM. But if all contracts are EOF contracts it will have a more significant impact :point_down:

  1. EOF contracts prohibit JUMP, JUMPI and other opcodes, and add RJUMP, RJUMPI, RJUMPV, CALLF, RETF opcodes (according to Vitalik’s proposal, CODECOPY, CODESIZE may also be removed in the future…) . This requires us to write new opcode gadgets.

  2. EOF adds new validation content (see here for details), which may require us to update our previous circuits to add EOF-related constraints.

  3. EOF contract separates data and code, which may have some impact on bytecode circuits.

Some nice material on EOF!:point_down:

Both EOF and zkEVM are very interesting things, open to discussion and glad to hear more ideas!