feat: DataBus PoC (UltraHonk as extension of Ultra)

[ledwards2225]

This work adds some basic PoC DataBus functionality to the GoblinUltra/UltraHonk arithmetization. In particular, it allows for proving lookups/reads from a new calldata column in the execution trace. The corresponding relation has been set up to share logic with the existing log-derivative lookup relation implemented in the ECCVM proving system.

This work also establishes the mechanism for reusing the conventional Ultra arithmetization/builder logic (e.g. gate creation) in builders that extend this basic functionality. This same mechanism will be used shortly by @lucasxia01 to add a custom gate for poseidon hashing.

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).

[AztecBot]

Benchmark results

No metrics with a significant change found.

Detailed 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 4229173e 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,888	868,196	3,448,112
l1_rollup_execution_gas	841,975	3,595,304	22,203,481
l2_block_processing_time_in_ms	2,050 (+2%)	7,625 (-1%)	30,000
note_successful_decrypting_time_in_ms	298	885	3,248 (+1%)
note_trial_decrypting_time_in_ms	99.3 (-1%)	94.1 (+3%)	163 (+23%)
l2_block_building_time_in_ms	20,694	82,179	327,949
l2_block_rollup_simulation_time_in_ms	12,089 (+1%)	47,859	190,303 (+1%)
l2_block_public_tx_process_time_in_ms	8,561 (-1%)	34,178	136,949

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	22,116 (+1%)	42,819 (+1%)
note_history_successful_decrypting_time_in_ms	2,116 (+4%)	4,139 (+4%)
note_history_trial_decrypting_time_in_ms	122 (+2%)	145
node_database_size_in_bytes	1,631,503	1,101,424
pxe_database_size_in_bytes	29,748	59,307

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	762	61,697	18,905
private-kernel-ordering	125	24,297	8,153
base-rollup	1,775	656,428	873
root-rollup	169	4,072	1,097
private-kernel-inner	786	81,568	18,905
public-kernel-private-input	567	41,519	18,905
public-kernel-non-first-iteration	405	41,561	18,905
merge-rollup	15.2	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	8,787	27,547

[ludamad]

nit: This feels like an unidiomatic way to declare a variable, more C++ish is:
proof_system::GoblinUltraCircuitBuilder builder{op_queue};

(or, before {} syntax, proof_system::GoblinUltraCircuitBuilder builder(op_queue);, but the less parser-ambiguous {} syntax is a Good Thing(tm) to me)

[ledwards2225]

Sounds good. When I first learned C++ I was taught (and got in the habit of) always using brace initialization. I got a bit of pushback when I started using it in this codebase since it wasn't used anywhere else. I guess it's time to get back in the habit.

[ludamad]

Does this mean we're calling a virtual function now for every gate added? Might be ok but worth discussing

[ledwards2225]

Moved this functionality to the Arithmetization classes so we're more consistent in how we're achieving polymorphism

[ludamad]

LGTM