HackMD
Different editions
Community
https://drive.google.com/file/d/1mhO5otzOsVLDGwyNI1CQKWzE1Ly3FQws/view?usp=sharing
Consensys
Polygon
Topics for discussions
Insufficient capacity to verify 15m gas
In community edition, the main VM circuit needs lots of witnesses per step, and to support the same gas limit target of current Ethereum (15m gas) in a single proof, and not blow up the amount of polynomials, we use lots of rotations. However, the usage of lots of rotations also limits the amount of gas we can verify, the bound of each dimension looks like:
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Idea #1
If we can incrementally verify a block, say have 5 recursive proof and each proof verifies 3m gas, then we are no longer bounded by the gas limit target, and we can have narrower circuit or higher degree.
How to copy the state (context, stack, memory, updated storages, etc…) from previous proof to next might be an issue?
PCS scheme
In community edition, it uses SHPLONK for inner proof, and standard PLONK for aggregation proof, which aggregate proof on the same curve, so it needs to do wrong field arithmetic to do MSM.
Field size utilization efficiency
In community edition, it represents the 256-bits word in random linear combination of 32 8-bits limbs, which is useful when dealing with bytecode and memory, but also bring some overhead because we can only do the decomposition of 32 8-bits limbs, instead of something like 4 64-bits limbs.
Idea #1
We should just represent the 256-bits word in 2 128-bits limbs, and gain the flexibility to do decomposition in larger limbs (e.g. 16-bits) for range check.
Underpriced opcodes
In EVM, there are some underpriced opcodes that will be very unfriendly to circuit, for example EXTCODESIZE, which requires to verify the hash of the bytecode is correct to make sure the size is correct. However, it only costs 2600 gas, then it produces at most 0x6000 bytes as preimage of code hash to verify, so it's around 9.45 byte/gas.
To achieve censorship resistence, there must be some way for user to submit their transaction somewhere (e.g. L1) to enforce L2 block producer to include it. However, this gives malicious users to submit some zk unfriendly transaction (repeat of EXTCODESIZE) which can't be proven.
Idea #1
In polygon edition, it can prove that the trace is too long to be proved by the VM.
How to charge such transaction? Or how to charge transaction that is not allowed in yellowpaper (e.g. insufficient intrinsic balance, invalid nonce, invalid signature, etc…)
Upcoming EVM upgrades (EOF, Verkle trie, …)
There are a bunch of potential upcoming EVM upgrade after the merge, like EVM Object Format and Verkle trie. How difficult would it be to upgrade the VM circuit to align to upstream EVM?
Cencorship resistence
To provide cencorship resistence, we somehow need a way for user to submit their transaction to L1 directly.
However, sequencer then needs to prove that some malicious transaction invalid or can't be proved, to make sure the rollup can continuely work.
