Nova over Cycles of Curves
Cycles of curves
Actual implementation of Nova uses EC group over a field defined as:
so each element in consists of 2 elements from base field . Therefore, constraints in will translate into operations (non-native) which turns out to be quite expensive. So instead, we try to express elliptic curve group operations over the base field only which turns out to be quite efficient. But to incrementally prove and verify, we need something called a cycle of curves. In a cycle of curves, there are 2 elliptic curve groups that are base fields of the other. For example,
where and are different fields. Pasta curves are one example of a cycle of curves.
Efficient folding over cycles of curves
Let's define functions as the verifier and prover parts of folding committed relaxed R1CS, respectively. Suppose you have a instance over a certain scalar field of which is . To check a folded instance from we need to check if the folded instance is the result of correct execution . This constraint can be only be implemented efficiently over the base field of which is .
For example, with four instances, the folding process would occur in two steps:
First fold: Fold two pairs of instances, resulting in two instances but to verify if each of them are constructed correctly, we will need two instances.
Second fold: Fold the instances into a single instance but to verify if it is constructed correctly, we will need one instance.
IVC Construction

To construct the folding described above, the original Nova implementation uses:
to do -th step in and accumulate the instances of (denoted as ).
to do -th step in and accumulate the instances of (denoted as ).
So if we denote the step function in as and as . The high level overview of the IVC will be as shown below:


This is the high-level view of but would also look the same:

To summarize what we need to do in is:
Check if the public instance of is indeed as given.
Check ( checks if the error term is and scalar is 1).
Calculate and accumulate .
Check if the input used in this step matches the output from previous step.
Check if the output element hash is done correctly.
NOTE: In , it will fold and (instead of instances of same index). Also, hash assignments will be a bit different in terms of indexing:

VC Verification

Faulty version
Given a proof , checks the following:
Check if , , and instances are satisfied.
Check if . This ensures that this output hash is derived from inputs
Check if .
In this version, Wilson Nguyen et al. showed that it is possible to generate proof of evaluation of rounds of the Minroot VDF in only 1.46 seconds and proposed a fix which has been reflected to Nova implementation.
Attack overview
This attack mainly stems from the fact that there is no constraints on the . Notice that the verification in the faulty version can be split into 2 parts:
Check if and instances are satisfied.
Check
Check if .
And the other part would be:
Check if and instances are satisfied.
Check
Check if .
So they can be from completely 2 different runs and this check will still pass. An actual attack is implemented as follows (Instances highlighted red are not satisfied malicious instances and green ones are satisfied instances):
Step 1: Generate malicious instance where is a trash value and .
Step 2: Run the honest prover to get and .
Step 3: Do step 1 and 2 for the other field to get .
It is very well explained in the presentation by Wilson Nguyen here. It is highly recommended to watch it if you want to fully understand how it works. To elaborate a bit more on this video:
The honest prover will run with and some fake accumulation claim , and some arbitrary .
This will give us:
with .
This makes it possible to use in and it will output:
with .
With this, we have a valid and .
The generated here is invalid so cannot be used as well since the hash has . But we will just discard them both and generate them in Step 3.
Now, the faulty verification check will:
Check if instances from step 2 and 3 are satisfied. Since they are a result of an honest prover, it passes without problem.
Check passes since this hash was also properly constructed by the honest prover.
Check passes as well similarly.
Fixed version
Given a proof , checks the following:
Check if , and instances are valid.
Check if .
Check if .
Here, the previous attack passes the check 1 and 2 but for the last check, it becomes tricky since now we can't just discard the invalid instances and generate another one because contains .
References
Written by BATZORIG ZORIGOO from A41
Last updated