SuperCircuit

[ed255]

The SuperCircuit is a new circuit that will contain all the circuits of the zkEVM in order to achieve two things:

1. Check the correct integration between circuits via the shared lookup tables
2. Allow having a single circuit setup for which a proof can be generated that would be verified under a single aggregation circuit for the first milestone

The name "SuperCircuit" is open for discussion, other name proposals are welcome!

Adding the State Circuit into the SuperCircuit will be done after the work being done by scroll-tech to integrate the EVM circuit with the State circuit is merged (See main...scroll-tech:zkevm-circuits:scroll-dev-0607)

NOTE: The super circuit test is disabled from the CI because it requires more memory than is available in the github workers.

Summary of changes

• general:

  • Addapt the circuits so that the shared tables can be assigned outside of
    the circuit's assign functions.

• evm_circuit.rs

  • load table functions moved to table.rs

• bytecode_circuit/bytecode_unroller.rs

  • Rename hash_length to code_length in Config
  • Rename r to randomness
  • Add is_enabled expression to the keccak lookup
  • Move load_keccaks to table.rs
  • Fix endianness in keccak hash output
  • Add function to obtain all the keccak inputs required by the SignVerifyChip

• table.rs

  • Move table definitions from evm_circuit/table.rs and rw_table.rs to here
  • Move all shared table load functions to here
  • Add BytecodeTable to help reusing the table config with other
  • Rename hash to code_hash in BytecodeTable
  • Use RLC(reversed(input)) in keccak table assignment for input_rlc.

• tx_circuit.rs

  • Add function to obtain all the keccak inputs required by the TxCircuit
  • Fix Gas encoding: remove RLC
  • Add missing field TxFieldTag::CallDataGasCost

• tx_circuit/sign_verify.rs

  • Move load_keccak to table.rs
  • Add function to obtain all the keccak inputs required by the SignVerifyChip
  • Reverse the pk_hash used in the lookup so that the RLC is calculated as if
    it was a hash in an Ethereum Word.

The SuperCircuit contains the following circuits:

• EVM Circuit
• State Circuit
• Tx Circuit
• Bytecode Circuit
• Copy Circuit
• Keccak Circuit
• MPT Circuit
• PublicInputs Circuit

And the following shared tables, with the circuits that use them:

• Copy Table
  • Copy Circuit
  • EVM Circuit
• Rw Table
  • State Circuit
  • EVM Circuit
  • Copy Circuit
• Tx Table
  • Tx Circuit
  • EVM Circuit
  • Copy Circuit
  • PublicInputs Circuit
• Bytecode Table
  • Bytecode Circuit
  • EVM Circuit
  • Copy Circuit
• Block Table
  • EVM Circuit
  • PublicInputs Circuit
• MPT Table
  • MPT Circuit
  • State Circuit
• Keccak Table
  • Keccak Circuit
  • EVM Circuit
  • Bytecode Circuit
  • Tx Circuit
  • MPT Circuit

Diagram of the Super Circuit (in green are the included components for this PR):

Resolve #600

[lispc]

7 is the degree? (Maybe either add some comment or use cs.degree() will be better)

[ed255]

I've added a variable and a constant that show what those values are in 7955480

[lispc]

the general idea looks good to me.

Some questions:

(1) in scroll-dev-0714, i have already make rw table of evm circuit and state circuit identical. (implicitly, not a explicit "RwTable" struct). Will it be good to add it also into this branch? But i may submit no earlier than next Tuesday.
(2) this pr may bring a lot of conflict, eg: state circuit mpt pr. Any idea on the merging order?
(3) power_of_randomness_from_instance: (a) i am not sure whether it should be instance cols now, anyway finally it should be cs.challege(). (Another thought is that i find it be useful to allow a fixed Fr to be fake "randomness" for debugging, better for reproducibility rather than real Fr::rand(). In my own branch, I use power of 0x1000 as randomness [Expr; 31] in daily development. )

[han0110]

Everything looks great! With structured tables It makes things much easier to follow! Only left some small questions and suggestions.

[ed255]

Some questions:

(1) in scroll-dev-0714, i have already make rw table of evm circuit and state circuit identical. (implicitly, not a explicit "RwTable" struct). Will it be good to add it also into this branch? But i may submit no earlier than next Tuesday.

I intentionally left the State circuit out of this PR because I knew you were working on the EVM - State Circuit integration in parallel. I would prefer to leave this PR as is, and in the future, once your work is also merged we can extend the Super Circuit.

(2) this pr may bring a lot of conflict, eg: state circuit mpt pr. Any idea on the merging order?

I think the conflict that may be introduced by that PR will be manageable (The current state of the SuperCircuit doesn't include the MPT Table nor the State Circuit). About merging order, I would like to give this PR priority because it touches several circuits so the earlier it is merged, the soon we can build on top of those changes.

I do have some doubts about how to approach the lookups between circuits: state circuit mpt uses RLC for lookups (so that the lookup is a single expression), but in the SuperCircuit the lookups are kept without RLC. See this comment #621 (review)

(3) power_of_randomness_from_instance: (a) i am not sure whether it should be instance cols now, anyway finally it should be cs.challege(). (Another thought is that i find it be useful to allow a fixed Fr to be fake "randomness" for debugging, better for reproducibility rather than real Fr::rand(). In my own branch, I use power of 0x1000 as randomness [Expr; 31] in daily development. )

Ah those are interesting points. So the idea of passing the randomness via instance was originally used in the EVM circuit, as a temporary solution to allow testing while we don't have the challenge API available. I completely agree that using a different random value on each test run is not desirable: it makes debugging harder and the tests are not 100% reproducible. I would prefer handling that outside of this PR. I'll open an issue for that: #641

[lispc]

ok. for the rlc, i can discuss it later ( we currently use AggregationCircuit to verify multi small circuits, and check some advice column commitments are equal between small circuits, so using rlc can reduce num of cols, reducing the cost of AggregationCircuit. I may adjust the "RLC"-ness of shared table between circuits configurable, or at least, merge friendly later)