feat: Integrate ZeroMorph into Honk

[ledwards2225]

This PR integrates ZeroMorph into Honk. Anywhere we used to use Gemini+Shplonk+KZG, we now use ZeroMorph.

Note: Charlie has confirmed that the work_queue is no longer needed so it has not been incorporated into the ZeroMorph rounds. (I'll remove the work_queue altogether in a follow on). This also means that it doesn't make sense to define the ZM protocol across multiple rounds split up in the Prover/Verifier (like we used to for Gemini/Shplonk). Instead, the entire protocol is defined via prove and verify functions in the ZeroMorphProver/Verifier classes and those methods are called from the main Honk Prover/Verifier (similar to Sumcheck).

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[maramihali]

Great work again! Just a couple of things that are slightly unclear to me but other than that it's ready to merge.

[maramihali]

why is this better?

[ledwards2225]

In various places we need to extract a builder from an existing stdlib element (e.g. I need a builder in a ZM method so I get it via auto builder = foo_challenge.get_context(). We were already using this from_witness method for single challenges but not in the multiple challenges method. I never noticed simply because we were never explicitly extracting a builder from a challenge generated via the plural method get_challenges().

[maramihali]

I feel like we do somethig like this in several places in the codebase (or at least PG) so evntually I think it can be retrieved from a Utils file. No need to do it now tho

[ledwards2225]

Agreed, it's very general. We'll find a place for it

[maramihali]

if you call it rho here (I assume because alpha is a clashing name) can you modify the writeup as well and comments?

[ledwards2225]

Thanks, I'll make sure this is consistent everywhere

[maramihali]

and it should be rho here as well

[maramihali]

can you add a note on why we dont use projective form here?

[ledwards2225]

I added a comment saying this is used for native verification only and is not optimized but it's also the case that projective form is used under the hood in the + operator for affine elements

[maramihali]

I see, good to know

[maramihali]

have you tested this if clause branch? it looks a bit funny to me that the return value is projective but the signature is affine? (unless conversion happens magically)

[maramihali]

looked at tests, don't see it tested

[ledwards2225]

This code is run and tested in all of the honk recursive verifier tests (stdlib/recursion/honk/verifier/verifier.test.cpp) which are now set up to use ZM. For stdlib values (biggroup) there is no distinction (it's all affine), we just define aliases for Group Element and AffineElement (see stdlib/primitives/curves/bn254.hpp) that all reference element (defined in biggroup).

[ledwards2225]

I can change the alias used to avoid confusion

[maramihali]

Ah, didn't know that it's all affine. But yeah I think if there is no concept of projective we should just not expose Element to avoid confusion

[AztecBot]

Benchmark results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Values are compared against data from master at commit 9a354c94 and shown if the difference exceeds 1%.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	128 txs
l1_rollup_calldata_size_in_bytes	45,444	179,588	716,132
l1_rollup_calldata_gas	222,792	868,160	3,449,300
l1_rollup_execution_gas	841,879	3,595,268	22,204,669
l2_block_processing_time_in_ms	1,049 (+2%)	3,823 (-1%)	15,384
note_successful_decrypting_time_in_ms	331 (+2%)	967 (-2%)	3,642
note_trial_decrypting_time_in_ms	⚠️ 36.0 (+33%)	⚠️ 76.0 (-16%)	137 (+1%)
l2_block_building_time_in_ms	9,068 (+1%)	35,368 (-1%)	150,934 (+1%)
l2_block_rollup_simulation_time_in_ms	6,727 (+1%)	26,303 (-1%)	105,763 (+1%)
l2_block_public_tx_process_time_in_ms	2,296 (+1%)	8,937 (-2%)	44,311 (+2%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	16,349 (+10%)	35,266 (+9%)
note_history_successful_decrypting_time_in_ms	2,599 (+8%)	5,323 (+8%)
note_history_trial_decrypting_time_in_ms	124 (+2%)	152 (+3%)
node_database_size_in_bytes	1,645,526	1,089,005 (-9%)
pxe_database_size_in_bytes	27,188	54,187

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	45.6 (+4%)	56,577	14,745
private-kernel-ordering	22.2 (+2%)	20,137	8,089
base-rollup	867 (+2%)	631,605	811
root-rollup	38.9 (+2%)	4,072	1,097
private-kernel-inner	39.0 (+5%)	72,288	14,745
public-kernel-private-input	48.0 (+1%)	37,359	14,745
public-kernel-non-first-iteration	29.1 (+3%)	37,401	14,745
merge-rollup	1.02 (+9%)	2,592	873