Minor updates to docs

docs/pages/Specs/nexus-prover.mdx

@@ -49,21 +49,21 @@ In terms of prover costs, the most expensive part of the prover's work at the ea
 
 One difficulty that arises in the Nova implementation is that the group scalar multiplications used in the recursive step involve operations over a field that is different than the native field used by the proof system. Hence, as mentioned above, the [Nova reference implementation](https://github.com/microsoft/Nova) by Microsoft uses a *cycle of elliptic curves* to reduce the number of non-native arithmetic operations and improve its overall efficiency, This is a well-known technique introduced in [[BCTV14](#references)] to improve the efficiency of elliptic-curve-based SNARK recursions. In a $2$-_cycle_ of elliptic curves $(\mathbb{G}_1, \mathbb{G}_2)$, the size of the _base field_ of one curve equals the _scalar field_ (i.e., group order) of the other curve, and vice-versa.
 
-In a nutshell, Microsoft's reference implementation for Nova works by creating two parallel copies of the IVC chain linked together in a way that allows the recursive step of one IVC chain to be verified on the other chain using native elliptic curve arithmetic operations. As shown in [[KST22](#references)], this results in a largely symmetric scheme with a recursion overhead in the order of $20{,}000$ constraints in each of the curves. Though the Nova reference implementation can work over most cycles of curves, its current implementation uses the [`pasta` cycle](https://github.com/zcash/pasta_curves) of two curves.
+In a nutshell, Microsoft's reference implementation for Nova works by creating two parallel copies of the IVC chain linked together in a way that allows the recursive step of one IVC chain to be verified on the other chain using native elliptic curve arithmetic operations. As shown in [[KST22](#references)], this results in a largely symmetric scheme with a recursion overhead in the order of [$10{,}000$ constraints](https://github.com/microsoft/Nova/blob/4f8f3e782b172e98d6d741b29e5bc671ab5b93a6/benches/recursive-snark.rs#L46) in each of the curves. Though the Nova reference implementation can work over most cycles of curves, its current implementation provides support for the [`pasta` cycle](https://github.com/zcash/pasta_curves) of two curves and the [`bn254`](https://neuromancer.sk/std/bn/bn254)-[`grumpkin`](https://hackmd.io/@aztec-network/ByzgNxBfd#2-Grumpkin---A-curve-on-top-of-BN-254-for-SNARK-efficient-group-operations) curve cycle.
 
 Thus, one consequence of using Nova over a cycles of curves is that the proof system ends up producing a pair of proofs instead of a single one. Hence, in order to verify a Nova proof, one needs to check instances over *two different* group-field pairs $(\mathbb{G}_1, \mathbb{F}_1)$ and $(\mathbb{G}_2, \mathbb{F}_2)$, where $\mathbb{F}_i$ is the scalar field of $\mathbb{G}_i$.
 
 ### `bn254`-`grumpkin` curve cycle
 
-In order to be able to produce proofs that can be cheaply verified on Ethereum, the Nexus zkVM currently implements the Nova folding scheme using the pairing-friendly [`bn254`](https://neuromancer.sk/std/bn/bn254) as the primary curve, since the latter has precompile support on Ethereum. Moreover, since `bn254` forms a $2$-cycle along with the [`grumpkin`](https://hackmd.io/@aztec-network/ByzgNxBfd#2-Grumpkin---A-curve-on-top-of-BN-254-for-SNARK-efficient-group-operations) curve, `grumpkin` is used as the secondary curve.
+In order to be able to produce proofs that can be cheaply verified on Ethereum, the Nexus zkVM currently implements the Nova folding scheme using the pairing-friendly [`bn254`](https://neuromancer.sk/std/bn/bn254) as the primary curve (also known as `bn128` or `bn256`), since the latter has precompile support on Ethereum. Moreover, since `bn254` forms a $2$-cycle along with the [`grumpkin`](https://hackmd.io/@aztec-network/ByzgNxBfd#2-Grumpkin---A-curve-on-top-of-BN-254-for-SNARK-efficient-group-operations) curve, `grumpkin` is used as the secondary curve.
 
 Interestingly, choosing `bn254` as the primary curve by itself is not enough to achieve cheap verification on Ethereum. For that, it is also important that later phases of the proof system, such as the compression phase, only require elliptic-curve operations on `bn254`. Unfortunately, this means that the IVC verifier for the secondary circuit will need to be implemented as a circuit over the `bn254` scalar field using non-native arithmetic.
 
 Hence, unlike Microsoft's reference implementation, the Nexus zkVM follows the approach proposed by CycleFold [[KS23](#references)] in its implementation of Nova to address concerns about non-native elliptic-curve arithmetic operations in later phases of the proof system. In this approach, instead of duplicating the IVC chain in both curves, the circuit implemented over the second curve is only used to perform a single group scalar multiplication over the base field of the first curve. Moreover, this is done in a way that allows the verifier in the first curve to avoid non-native arithmetic operations by verifiably delegating its group scalar multiplications to the second curve.
 
-Besides not having to reason about the 2-cycle of elliptic curves in the security proof of Nova [[KS23](#references)], one important advantage of CycleFold's approach over the one used in Microsoft's reference implementation is that the circuit size over the secondary curve becomes significantly smaller. More concretely, the size of the IVC verifier of the Nexus zkVM on the secondary curve is in the order of $3{,}000$ constraints.
+Besides not having to reason about the 2-cycle of elliptic curves in the security proof of Nova [[KS23](#references)], one important advantage of CycleFold's approach over the one used in Microsoft's reference implementation is that the circuit size over the secondary curve becomes significantly smaller. More concretely, the size of the IVC verifier of the Nexus zkVM on the secondary curve is in the order of $3{,}000$ constraints. Though this could in principle be reduced to around $1{,}500$ constraints in the IVC setting, the Nexus zkVM implementation of the secondary circuit currently unifies both the IVC and PCD settings.
 
-The reduction in circuit complexity over the secondary curve has, however, implications on the size of the IVC verifier over the primary curve since the latter circuit now needs to keep track of additional witnesses and to perform several additional small multi-scalar multiplications and hashing operations related to these witnesses. More concretely, the recursion overhead over the primary curve is in the order of $70{,}000$ constraints when used to realize an IVC scheme and $340{,}000$ constraints when used to realize a PCD scheme.
+The reduction in circuit complexity over the secondary curve has, however, implications on the size of the IVC verifier over the primary curve since the latter circuit now needs to keep track of additional witnesses and to perform several additional small multi-scalar multiplications and hashing operations related to these witnesses. More concretely, the recursion overhead over the primary curve is in the order of $120{,}000$ constraints when used to realize an IVC scheme and $340{,}000$ constraints when used to realize a PCD scheme.
 
 ## Proof compression
 
@@ -107,9 +107,9 @@ const MODULUS_BITS: u64 = 254;
 
 ### Instructions per folding step
 
-The Nexus zkVM's approach based on Nova provides a proof system with a recursion overhead which is independent of the total number of computation steps and of the step function itself. However, in our current implementation, the recursion overhead  remains quite high (in the order of $70{,}000$ and $340{,}000$ constraints in the IVC and PCD settings) compared the cost of a single step of the Nexus VM (around $15{,}000$ constraints). 
+The Nexus zkVM's approach based on Nova provides a proof system with a recursion overhead which is independent of the total number of computation steps and of the step function itself. However, in our current implementation, the recursion overhead  remains quite high (in the order of $120{,}000$ and $340{,}000$ constraints in the IVC and PCD settings) compared the cost of a single step of the Nexus VM (around $15{,}000$ constraints). 
 
-Hence, in order to offset the current recursion overhead, the Nexus zkVM includes a configuration parameter $k$ which allows the prover to combine several steps of the Nexus VM into a single folding step. Even though a higher value of $k$ will increase the overall complexity of the prover, the value $k$ has no impact on the recursion overhead. As a result, one can improve the overall performance of the Nexus zkVM by increasing the value $k$. For instance, by choosing $k=5$ in the IVC setting, the cost of each folding step will approximately double while the total number of folding steps will be reduced by a factor $5$.
+Hence, in order to offset the current recursion overhead, the Nexus zkVM includes a configuration parameter $k$ which allows the prover to combine several steps of the Nexus VM into a single folding step. Even though a higher value of $k$ will increase the overall complexity of the prover, the value $k$ has no impact on the recursion overhead. As a result, one can improve the overall performance of the Nexus zkVM by increasing the value $k$. For instance, by choosing $k=8$ in the IVC setting, the cost of each folding step will approximately double while the total number of folding steps will be reduced by a factor $8$.
 
 The current default value for $k$ is 16, which seems to avoid large RAM requirements for the prover while providing a reasonable offset for the recursion overhead. This value can, however, be set by the user of the Nexus zkVM.