zkevm-specs icon indicating copy to clipboard operation
zkevm-specs copied to clipboard

EXTCODESIZE and EXTCODECOPY

Open ChihChengLiang opened this issue 3 years ago • 4 comments
trafficstars

EXTCODESIZE and EXTCODECOPY are two codes to query the information of the bytecode of another address.

  • EXTCODESIZE gives us the size of the bytecode.
  • EXTCODECOPY copies the bytecode into the memory

They cost 100 gas if the queried address is warm and 2600 if the address is cold.

The problem with proving these two opcodes inside zkevm is that we have to prove the membership of the bytecode in the state tree before we can give information about their size or load them to the memory.

Naive solution

To prove the membership of the bytecode in the state tree, we compute MPT proof and Keccak proofs.

  • Advantages:
    • simple: no extra crypto or assumption involved
  • Disadvantage:
    • It is costly in the circuit.

Build a Poseidon Tree for bytecodes

Proving the bytecode membership is the internal working of ZKEVM. So if we build a snark-friendly tree for bytecodes, it wouldn't affect Ethereum compatibility.

  • Advantages:
    • cheaper in the circuit
  • Disadvantage:
    • Introduced Poseidon. We now need to assume Poseidon is secure.
    • Increase the circuit cost of CREATE and CREATE2. Whenever a new contract is deployed, we add its bytecode to the Poseidon Tree.
    • We need the information from the previous proof. As the Poseidon tree root is not in the EVM block.
      • We could fix this by adding Poseidon tree root in a contract storage slot. It introduces more overheads to updating the tree root and initializing the block.

ChihChengLiang avatar Jul 29 '22 08:07 ChihChengLiang

Haha in fact wa have already made a binary posedion storage tree https://github.com/scroll-tech/mpt-circuit/blob/master/spec/mpt-proof.md

lispc avatar Jul 29 '22 08:07 lispc

Hi! I'm currently working on writing EXTCODECOPY spec, and I'm curious about the following:

The problem with proving these two opcodes inside zkevm is that we have to prove the membership of the bytecode in the state tree before we can give information about their size or load them to the memory.

Is there any decision about this? Thanks!

DoHoonKim8 avatar Aug 22 '22 07:08 DoHoonKim8

Hi! I'm currently working on writing EXTCODECOPY spec, and I'm curious about the following:

The problem with proving these two opcodes inside zkevm is that we have to prove the membership of the bytecode in the state tree before we can give information about their size or load them to the memory.

Is there any decision about this? Thanks!

For now you should not assume that any of these optimizations will be coded/applied and simply fetch the bytecode with the bytecode circuit.

CPerezz avatar Aug 22 '22 07:08 CPerezz

Hi! I'm currently working on writing EXTCODECOPY spec, and I'm curious about the following:

The problem with proving these two opcodes inside zkevm is that we have to prove the membership of the bytecode in the state tree before we can give information about their size or load them to the memory.

Is there any decision about this? Thanks!

For now you should not assume that any of these optimizations will be coded/applied and simply fetch the bytecode with the bytecode circuit.

Okay, I will leave the optimizations as future works. Thanks for your reply @CPerezz !

DoHoonKim8 avatar Aug 22 '22 07:08 DoHoonKim8

Duplicated by #327

Fixed by

  • #341
  • #257

ChihChengLiang avatar Jul 03 '23 16:07 ChihChengLiang