You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this code, a choice is made between a hard-coded rootCSingle and an input rootC based on whether it is verifying a recursive1 proof or a recursive2 proof. My concern is whether there could be any issues when using rootC. Specifically, if the rootC circuit does not correctly execute the STARK verification process for two recursive1/recursive2 proofs (maybe less constraints, despite having the same shape as a normal recursive2 circuit), it could lead to potential vulnerabilities.
The above-mentioned StarkVerifier uses the code from build/proof/recursive1.circom, as shown below:
templateStarkVerifier() {
signalinput publics[48]; // constant polynomialssignalinput root1[4]; // Merkle tree root of the evaluations of all trace polynomialssignalinput root2[4]; // Merkle tree root of the evaluations of polynomials h1 and h2 used for the plookupsignalinput root3[4]; // Merkle tree root of the evaluations of the grand product polynomials (Z) signalinput root4[4]; // Merkle tree root of the evaluations of the quotient Q1 and Q2 polynomials// Notice that root2 and root3 can be zero depending on the STARK being verified signalinput rootC[4]; // Merkle tree root of the evaluations of constant polynomials
Compared to the build/proof/recursive1.circom which uses the dynamic StarkVerifier template, the rootC is hard-coded in the build/proof/c12a.verifier.circom file to ensure verification of a "correctly executed c12a process" circuit:
templateStarkVerifier() {
signalinput publics[44]; // constant polynomialssignalinput root1[4]; // Merkle tree root of the evaluations of all trace polynomialssignalinput root2[4]; // Merkle tree root of the evaluations of polynomials h1 and h2 used for the plookupsignalinput root3[4]; // Merkle tree root of the evaluations of the grand product polynomials (Z) signalinput root4[4]; // Merkle tree root of the evaluations of the quotient Q1 and Q2 polynomials// Notice that root2 and root3 can be zero depending on the STARK being verified signal rootC[4] <== [18013726111668493315,7128019730232301670,1786599658476827655,13745530316764869768 ]; // Merkle tree root of the evaluations of constant polynomials
I would like to understand whether the dynamic input rootC in recursive2.circom might introduce any issues, and if there are any approaches to ensure the security and correctness of this proof aggregation.
The text was updated successfully, but these errors were encountered:
After running
buildsetup
in zkevm-proverjs, I noticed the following code segment in thebuild/proof/recursive2.circom
file:In this code, a choice is made between a hard-coded
rootCSingle
and an inputrootC
based on whether it is verifying arecursive1
proof or arecursive2
proof. My concern is whether there could be any issues when usingrootC
. Specifically, if therootC
circuit does not correctly execute the STARK verification process for tworecursive1
/recursive2
proofs (maybe less constraints, despite having the same shape as a normalrecursive2
circuit), it could lead to potential vulnerabilities.The above-mentioned
StarkVerifier
uses the code frombuild/proof/recursive1.circom
, as shown below:Compared to the
build/proof/recursive1.circom
which uses the dynamicStarkVerifier
template, therootC
is hard-coded in thebuild/proof/c12a.verifier.circom
file to ensure verification of a "correctly executed c12a process" circuit:I would like to understand whether the dynamic input
rootC
inrecursive2.circom
might introduce any issues, and if there are any approaches to ensure the security and correctness of this proof aggregation.The text was updated successfully, but these errors were encountered: