Support PCS of aggregation circuit in contracts

[pinkiebell]

No description provided.

[pinkiebell]

Note: Might not be economically viable to do the accumulation inside the evm contracts. Consider adding
i) A instance column(s) with the non-accumulated values of the original snark instance(s) and verify that those matches the accumulated versions that are used for the the aggregated circuit. Needs to do accumulation inside the circuit. < Is this feasible?
or
ii) Same as above but instead compress those via keccak(instances) and to the verification inside the circuit.

cc @han0110 @ed255 Does this sound possible/feasible to do?
cc @KimiWu123

[han0110]

Might not be economically viable to do the accumulation inside the evm contracts.

Would you like to elaborate more about what's the accumulation doing here? Do you mean turning proof of SuperCircuit into pairing input (lhs, rhs)? If so I think that's what RootCircuit doing already?

[pinkiebell]

Might not be economically viable to do the accumulation inside the evm contracts.

Would you like to elaborate more about what's the accumulation doing here? Do you mean turning proof of SuperCircuit into pairing input (lhs, rhs)? If so I think that's what RootCircuit doing already?

Sorry, I'm talking about the circuit instances and a way to verify those on the L1 bridge. The l1 bridge has a keccak(super_circuit_instance) stored after block submission. And we later need to verify that a given proof relates to the commitment hash we saved on block submission. This works for the super circuit but not the aggregation circuit yet, because the latter is transformed in the aggregation circuit. And after looking the steps that are involved that isn't something we can do without much gas consumption on l1. Hence I'm wondering if there is another way of proofing or preserving the inputs from the super circuit in the aggregation circuit proof in a way that can be verified on l1. Maybe embedded into the transcript or something else.

[ed255]

@pinkiebell your analysis of the part that is not economically viable is the calculation of the random linear combination with the raw_public_inputs right? Which requires an MULMOD + ADDMOD for each value.

I don't fully understand this statement:

This works for the super circuit but not the aggregation circuit yet, because the latter is transformed in the aggregation circuit.

[pinkiebell]

Copy pasting from chat:

Ah yes. I smell a lot of confusion about this. So apart from the public input design that is - as it stands also expensive, this issue is about the commiting to the inputs for the aggregation circuit

Right now, the aggregation circuit accumulates the proof and splits it into sizable chunks (the limbs). In that process the public inputs also get changed (accumulated and sliced?). And as far I dig into the mechanics this will depend on the transcript of the proof. Hence that method is practically impossible to do on l1. That's why I'm asking for input how we could verify the original public inputs values as part of the aggregation proof

Because we need to satisfy the relationship between the aggregation proof and the public inputs derived and committed to on l1

[aguzmant103]

Note: we have an example that gives more direction to continue progress.

[smtmfft]

Note: we have an example that gives more direction to continue progress.

Hi, @aguzmant103 You mean there is already an example of aggregation circuit verification in smart contract? Could you please show me where it is. Thanks!

[ChihChengLiang]

privacy-scaling-explorations/snark-verifier#22 is unblocked now