Refactor and WHIR Integration

[b-wagn]

This PR does a major refactoring of the codebase with the aim to allow integrating zkVMs that are based on WHIR.

Related to #19

Status

• Make name, soundness, proof size, parameters functions of the zkVM
• Split zkVM into subclasses (FRI-based, WHIR-based, or even more later)
• Re-integrate best attack
• Re-integrate printing of parameters
• Define WHIR parameters
• Create a dummy WHIR VM to test things
• Add computation of WHIR proof sizes
• Add computation of WHIR security levels
• Add a proximity gaps regime class
• Add a UDR regime
• Add a Johnson bound regime
• Add batching for WHIR
• Add grinding for WHIR
• Re-integrate md report

[asn-d6]

Thanks for all the work! Fixed a bug, and revived the markdown.

Some thoughts on the refactoring:

• regimes/fri_regime.py seems a bit weird, as FRI is definitely not a regime. What's the plan? How much of regimes/ do we think will also be useful for WHIR?

• A side-effect now is that there is a bunch of FRI stuff scattered across the modules. An alternative structure (not sure if it's better) would be to make a soundcalc/FRI/ directory and put there all the FRI stuff there, including zkvms/fri_based_vm.py and common/fri.py. Then introduce a soundcalc/WHIR/ directory. What is not clear to me right now is how much code will be shared between the FRI and the WHIR module (probably some of the proximity gaps stuff).

[b-wagn]

Thanks for the review and the progress :)
About your questions:

FRI-Regimes: I agree that it is a bit weird. In the long term, I think we should have proximity gaps / CA regimes and both WHIR and FRI VMs should call them to get their soundness errors. Right now, the reason why it is still called FRI-regime is that the functions that it provides are still FRI-specific, e.g., the name get_commit_phase_error does not make a lot of sense for WHIR. My strategy would be to keep the regimes FRI-specific for now, then integrate WHIR, and then see how much code is shared and move it into a separate proximity gaps module.

Structure: I think what you propose here makes sense to me. Btw, it was a bit tricky to avoid circular dependency between modules here, which is why the class FRIParameters was introduced.

[asn-d6]

Did an initial review

[asn-d6]

As discussed, it would be good if we could unify soundcalc/proxgaps/ and soundcalc/regimes/, as they essentially do things related to proximity gaps.

[asn-d6]

Is there an equivalent of trace_length for WHIR VMs?

[b-wagn]

Not sure tbh

[b-wagn]

Maybe 2 ** log_degree?