Add MPT table lookup to state circuit

[ed255]

Introduce MPT table lookups from the state circuit for Storage and Account operations.

[han0110]

LGTM! Nice work!

[ed255]

@z2trillion could you help as a second reviewer for this PR?

[lispc]

@noel2004 have a question on the mpt_counter. In the current code, the mpt_counter increases with keys lexicographic ordering.
But in the mpt side, the counter should be in wall clock time order?

So we have two option
(1) adjust mpt_counter in state circuit using wallet clock time order(or similar with rw_counter) too. EVM circuit can have constraints like if storage_related_rw() { rwc++; mpt_counter++; } else { rwc++} We may have to add mpt_counter into rw table?
(2) let mpt circuit update state root in the same order with current state circuit mpt counter, lexicographic ordering. It can get the same final root, but it is very counter intuitive.. And not easy to debug.

@ed255

[ed255]

@noel2004 have a question on the mpt_counter. In the current code, the mpt_counter increases with keys lexicographic ordering. But in the mpt side, the counter should be in wall clock time order?

So we have two option (1) adjust mpt_counter in state circuit using wallet clock time order(or similar with rw_counter) too. EVM circuit can have constraints like if storage_related_rw() { rwc++; mpt_counter++; } else { rwc++} We may have to add mpt_counter into rw table?
(2) let mpt circuit update state root in the same order with current state circuit mpt counter, lexicographic ordering. It can get the same final root, but it is very counter intuitive.. And not easy to debug.

From my point of view, option 2 has always been the one considered for the design, because it's simpler. We already process stack and memory in key order instead of chronological order (in the state circuit), and we know that the result is equivalent to processing the updates chronologically (in terms of read consistency). So it doesn't seem strange to me that we do the same for state/storage updates.

Why do you think approach 2 is not easy to debug?

Here's a rough description of the witness generation process, taken from privacy-scaling-explorations/zkevm-circuits#222:

Generate intermediate proofs for StorageOps and AccountOps (Blocked by inputs / witness spec of MPT Circuit https://github.com/appliedzkp/zkevm-circuits/tree/mpt2)

• Sort all StorageOps, AccountOps, AccountDeletedOps by (address, key, rwc)
• Use wrapper over MPT witness generation https://github.com/miha-stopar/mpt
• For each unique (address, key), get a "before" proof, apply last write, get "after" proof
• Sort all AccountOps by (address, rwc)
• For each unique (address), get "before" proof, apply write with final values, get "after" proof

Following approach (2) we will encounter intermediate state roots that never happened in geth (because of the reordering), so we'll have a partial mpt which we will be updating following the lexicographic ordering, to get the intermediate proofs between updates.

[lispc]

ok i understand the design. "we will encounter intermediate state roots that never happened in geth" is what i think as "counter intuitive". For the "uneasy to debug", i thought of bug case where the replay final root is not same with real final root, yeah, it is only bug after it is fixed it will be ok later. No problem~ Thanks for the explanation