Lucas Xia

Ran into a weird linker error in CI here: https://app.circleci.com/pipelines/github/AztecProtocol/aztec-packages/22652/workflows/ebbead1f-83c1-48a7-8be6-f06ab8577ed0/jobs/1040058 Fixed it by adding sumcheck as a CMake dependency to protogalaxy. I added this because the linker error was relating...

We can truncate hashes to be 128 bits, so multiplication is easier. Alternatively, we can generalize the transcript to take in a `num_challenge_bits` parameter, and then divide up each hash...

We have a mess of files in ecc/fields and stdlib/primitives/field, bigfield, biggroup. First, one called is field and one is fields. In the native library ecc/fields: - we have empty...

This only happens on the CI gcc build: ``` #10 50.53 inlined from 'proof_system::honk::BaseTranscript::Fr proof_system::honk::BaseTranscript::get_next_challenge_buffer()' at /usr/src/barretenberg/cpp/src/barretenberg/transcript/transcript.hpp:125:31: #10 50.53 /usr/include/c++/12.2.1/bits/stl_algobase.h:431:30: error: 'void* __builtin_memmove(void*, const void*, long unsigned int)' offset 0...

Merge ultra_recursive_verifier and ultra_verifier

1

also includes potential other repeated pieces of code like native and recursive transcript

Refactor Honk and Plonk Recursion Constraint

1

These need to be reworked so things are more clear. Some things seems unnecessary or could be clarified better. Some things need more structure and more usage of types instead...

We don't generate a recursion separator challenge in the Ultra Honk prover. We need to consider the Aztec connect bug that involved this challenge.

now that the decider is used in the ultra honk prover, we can consider renaming it so that people aren't confused that folding is done somehow in ultra honk.

It pushes double_verify_proof over the limit of 512Mi gates. Where are these gates coming from?

Currently, they are just native values because the proof already contains identical information that will be turned into witnesses. But, this deserves more thinking.