implement commitment-carrying capability

[srinathsetty]

• The details are described in https://eprint.iacr.org/2024/1605
• As an example, implement a simple example that performs randomized checks

[Autoparallel]

@srinathsetty i see based on this and #339 there seems to be an inclination to support Nebula as well as adopt the ark ecosystem.

I've been curious about a Nebula implementation for both Nova and HyperNova (or NeutronNova) myself. It has some benefits that could be really excellent to use.

With both these said, there is a lot of work going on at Sonobe and in particular the is an issue for non-uniform IVC that points towards using Nebula for an NIVC switchboard.

I understand there is ownership in this repo here for you and your work, but I am curious about cross pollination between these two camps!

---

On a slightly related note, and my apologies if this question does not belong here, but I'm curious about the details between using Nebula inside of Nova versus using it with NIVC inside of HyperNova. In the case of Nova, you'd create a single master circuit, but disable certain constraints depending on the current step (or some other internal value) and only pay for the cost of the activated R1CS. In the case of HyperNova, you could have individual circuits and don't need a single master circuit. Would this be the main difference?

[srinathsetty]

Hi @Autoparallel

I am curious about cross pollination between these two camps!

We are always open to contributions to the repository, with new features, improvements. Essentially, anything to improve this codebase for use in real applications. Please feel free to open PRs and issues as necessary for cross pollination.

On a slightly related note, and my apologies if this question does not belong here, but I'm curious about the details between using Nebula inside of Nova versus using it with NIVC inside of HyperNova. In the case of Nova, you'd create a single master circuit, but disable certain constraints depending on the current step (or some other internal value) and only pay for the cost of the activated R1CS. In the case of HyperNova, you could have individual circuits and don't need a single master circuit. Would this be the main difference?

The switchboard construction can be used in both Nova and HyperNova in the exact same way. One could additionally make that the HyperNova's sum-check prover does not pay for unused circuits.

[Forpee]

Hi @srinathsetty,

When Nova has commitment-carrying capability, how will we perform the Nebula check in 4.4 ((2) Finalize Π_F by computing multiset hashes underneath C_n):

"2. check C_n′ = C_n // commitments carried in both Π_ops and Π_F are the same"
...since the commitments will differ due to the blinding factors being different in computing C_n' and C_n (if you compute them in separate RecursiveSNARK's)? Additionally, if we set the blinding factor to 0 in the incremental commitment scheme, won't that potentially leak information?

[srinathsetty]

Hi @Forpee, the blinding factors used in commitments can be same (they should not be 0) because we are reusing commitments, so the underlying plaintext including blinds are reused in different RecursiveSNARKs.

[Forpee]

Okay, yes, that makes sense. I didn’t suggest that because we rely on OsRng to generate the blinding factors, which means we lose built-in reusability. As a result, you’d need to explicitly store or pass along the original blinding factors to the second RecursiveSNARK, which could be cumbersome. I assume we might need to move away from using OsRng, unless I’m missing something. Do you have any suggestions for achieving this reusability more easily?

cc @srinathsetty