Add spec for CREATE(2)

[z2trillion]

Close #371

[adria0]

Hey @z2trillion, it will be nice to have CREATE/CREATE2 since a lot of ethereum tests depends on it.

[ashWhiteHat]

Hi @z2trillion
I picked up your commits and proceeded a bit.
#378

I think generating test data is necessary and takes time.

I would be happy if we work together 🙂

I am going to implement verifying contract address.

[roynalnaruto]

@ashWhiteHat I will be working on this issue as @z2trillion is occupied with another issue. Happy to collaborate :)

[ashWhiteHat]

Hi @roynalnaruto
I am happy to collaborate with you!

I added my commits to this PR.
Let's work on this branch.
There are two parts we need to do now.

• implement contract address circuit
• generate test data

I already implemented generate contract address but the verification haven't done yet.
Also we need to prepare the test data to execute simple contract deploy with constructor.
I would like you to work whichever you prefer.

Please push the changes if you finish working in order to avoid conflict.

I won't work for 10 hours because I sleep.
I will ping you before I start to work on this.

Thank you!

[ashWhiteHat]

Thank you @roynalnaruto
The generate contract address looks really nice!
I work on adding constraints.

[ashWhiteHat]

I finished implementing before calling contract.
https://github.com/ethereum/go-ethereum/blob/877d2174fb898daefeb7e9c944a68d1c3a98c923/core/vm/evm.go#L443
Calling contract is the same operation with call opcode so it might be helpful.
https://github.com/ethereum/go-ethereum/blob/877d2174fb898daefeb7e9c944a68d1c3a98c923/core/vm/evm.go#L233

I won't work for 20 hours.

[adria0]

Hey @ashWhiteHat it will be nice if we can move forward with it!

[ashWhiteHat]

Hi @adria0
I am working on state circuit synchronization and bn256 sub circuit.
I can work on this after these but if this is emergent, it would be better to assign someone to following issue.
#371

[KimiWu123]

Hi @ashWhiteHat , if you don't mind, I could take this. I found you have taken many tasks (#364, #323, #377 and this one) and afraid that you're overloaded. But you have put some effort on this task and if you want to complete it, it's also fine with me. 😄

[ashWhiteHat]

Thank you @KimiWu123 !
I would like you to take this over.

Followings are reference.

• latest create implementation
  Implement CREATE & CREATE2 zkevm-circuits#1130 (comment)
• create gadget implementation.
  gadget for CREATE(2) zkevm-circuits#981

Please ping me whenever you have questions 😀

[ChihChengLiang]

During the discussion with @KimiWu123. We have a question of the instruction.step_state_transition_to_new_context part in the CREATE opcode.

What would be the code_hash here?

In the flow of CREATE opcode. The opcode reads the input from memory and runs the input in the next context.

We can use the example 3 for CREATE opcode on EVM.codes.

// Create an account with 0 wei and 4 FF as code
PUSH13 0x63FFFFFFFF6000526004601CF3
PUSH1 0
MSTORE
PUSH1 13
PUSH1 0
PUSH1 0
CREATE 

This one writes 0x63FFFFFFFF6000526004601CF3 to memory. Use CREATE opcode to read it from memory.

The CREATE opcode creates a new context and runs 0x63FFFFFFFF6000526004601CF3 as code, which returns 0xFFFFFFFF as the final deployment bytecode.

Possible answers of the codehash field to instruction.step_state_transition_to_new_context could be

1. empty code_hash?
2. hash(init_code). 0x63FFFFFFFF6000526004601CF3

Tracing go-ethereum supports it should be empty code_hash.
The reason to support 2 is we need to read the execution code by querying the bytecode table, so we need the codehash as the key.

[z2trillion]

code_hash in the StepStateTransisition should be 2 for the reason you have stated.

however, 1 is also true, but only in the sense the sense that EXTCODEHASH for this address will still return the empty code hash until the until the RETURN at the end of the create call.

[han0110]

For creation context the code_hash is decided to be hash of init_code some time ago, see this issue for more context #73.

however, 1 is also true, but only in the sense the sense that EXTCODEHASH for this address will still return the empty code hash until the until the RETURN at the end of the create call.

I think when it's creation and we call EXTCODEHASH to self, it'd be still 0~ keccak256([]) because we will only update the account's code_hash in the RETURN or STOP step, and we would create the account (update from 0 to keccak256([])) in merkle trie while CREATE*.

[han0110]

First pass review

[han0110]

First pass

[han0110]

LGTM! Final 2 nits.

BTW I checked with the circuit impl the main difference between is:

• Handles insufficient balance, nonce overflow, depth overflow in the same gadget
• Skips new context if init code is empty
• Does keccak table lookup itself without checking bytecod length (which I think we need)

The rest is similar with different order.

[KimiWu123]

LGTM! Final 2 nits.

BTW I checked with the circuit impl the main difference between is:

• Handles insufficient balance, nonce overflow, depth overflow in the same gadget
• Skips new context if init code is empty
• Does keccak table lookup itself without checking bytecod length (which I think we need)

The rest is similar with different order.

Finally! Thanks 👍

What do you think if I merge this first and create another pr for above difference?

[han0110]

LGTM! Nice work!