Before we close the PiSchProof code-cleanup epic, we should take a pass over the proof to make sure we didn't miss any broader improvements. The original issue took on a lot of tasks at once; we broke it into smaller, more specific issues. But that separation may have lost the more general review that was intended by the original issue.
As a reminder, some things to look for code-quality wise:
Are all variables, methods, etc. named in Rust-canonical ways?
Are all the externally-accessed methods clearly documented, including indications of which variables need to come from prover vs verifier?
Is there code duplication that can be refactored?
Is there sufficient documentation inline in the code to provide intuition about how the proof works? Does the documentation use standard terminology?
Is there module-level documentation to explain the constraint being proved and reference the proof in the paper?
Are transcripts used correctly throughout the proof?
Before we close the
PiSchProofcode-cleanup epic, we should take a pass over the proof to make sure we didn't miss any broader improvements. The original issue took on a lot of tasks at once; we broke it into smaller, more specific issues. But that separation may have lost the more general review that was intended by the original issue.As a reminder, some things to look for code-quality wise: