feat: DataBus notion with calldata/return data

[ledwards2225]

The DataBus will eventually contain 3 columns: calldata, return data, and a 3rd for storing "function" calldata/returndata. Prior to this PR, we only had calldata (implemented as a proof of concept). This PR introduced a more proper notion of the DataBus and adds return data to its functionality. (No 3rd column yet).

Each column (BusVector) of the DataBus essentially behaves the same way so the bulk of the work in this PR is simply making that logic generic/shareable in the GoblinUltraCircuitBuilder and the DataBusLookupRelation.

Note: In prior work I collected some of the generic log-derivative lookup logic (originally introduced by Zac for the ECCVM) in logderivative_library.hpp. I'm no longer using that shared logic for the Databus for a few reasons: 1) the library is now also used by the AVM so any changes would have touched many avm files, 2) the DataBus relation needs functionality for multiple "tables" (bus columns) whereas others only have one, and 3) the library methods were over generalized in a way not needed for the DataBus (multiple read/write terms) that obscured the simple structure of the Databus lookup relation.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_trial_decrypting_time_in_ms (32): 98.6 (+144%)

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 150932a3 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	64 txs
l1_rollup_calldata_size_in_bytes	676	676	676
l1_rollup_calldata_gas	6,388	6,388	6,424
l1_rollup_execution_gas	585,721	585,721	585,757
l2_block_processing_time_in_ms	1,343 (+3%)	4,767 (-2%)	9,602 (-1%)
note_successful_decrypting_time_in_ms	256 (+6%)	589 (-7%)	1,073
note_trial_decrypting_time_in_ms	58.8 (+35%)	⚠️ 98.6 (+144%)	32.2 (-61%)
l2_block_building_time_in_ms	12,121 (+1%)	44,242 (+1%)	87,259 (+2%)
l2_block_rollup_simulation_time_in_ms	7,266 (+2%)	25,216 (+1%)	48,341 (+1%)
l2_block_public_tx_process_time_in_ms	4,812	18,896	38,664 (+3%)

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	14,232	26,417 (-1%)
note_history_successful_decrypting_time_in_ms	1,466 (+11%)	2,338 (-2%)
note_history_trial_decrypting_time_in_ms	95.3 (+33%)	97.0 (-38%)
node_database_size_in_bytes	18,673,744	34,988,112
pxe_database_size_in_bytes	29,859	59,414

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	179 (-1%)	44,377	26,164
private-kernel-ordering	161	50,830	39,325
base-parity	4,172 (-4%)	128	311
root-parity	1,167 (+1%)	1,244	311
base-rollup	14,547	116,608	861
root-rollup	49.3 (-2%)	4,359	725
private-kernel-inner	220	71,744	26,164
public-kernel-app-logic	120 (+1%)	47,695	40,661
public-kernel-tail	163 (+1%)	53,372	13,269
merge-rollup	10.2 (+8%)	2,568	861
public-kernel-teardown	117 (+2%)	47,695	40,661
public-kernel-setup	116 (+3%)	47,695	40,661

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	16 leaves	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves	32 leaves
batch_insert_into_append_only_tree_16_depth_ms	9.97 (-2%)	16.1 (-1%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8	31.6	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.580 (-1%)	0.495 (-1%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	46.4	71.7 (-2%)	234 (+1%)	433 (-3%)	883	1,746	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	96.0	159	543	1,055	2,079	4,127	N/A
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.474	0.441 (-2%)	0.424	0.405 (-3%)	0.418	0.417	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	54.5 (-1%)	107	344 (+2%)	640 (-3%)	1,329	2,656 (+1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.478 (-1%)	0.479 (-1%)	0.463 (+1%)	0.441 (-3%)	0.458	0.459 (+1%)	N/A
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	60.8 (-2%)
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	109
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.529 (-1%)

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	40,548	501,142

Transaction size based on fee payment method

Metric	native fee payment method	fpc_public fee payment method	fpc_private fee payment method
tx_with_fee_size_in_bytes	905	1,161	1,377

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	1,751 (+2%)	1,093	5,554 (+3%)

Metric	1 public data writes	2 public data writes	3 public data writes	4 public data writes	5 public data writes	8 public data writes
tx_sequencer_processing_time_ms	581	448 (+3%)	1,072 (+1%)	593 (+1%)	1,755 (+1%)	592

[maramihali]

Looks good to me! Just a couple of tiny requests, mostly related to clarifying documentation

[maramihali]

Can you please add comments here explaining what calldata and return_data is?

[ledwards2225]

Yes, thanks. Basically calldata = public input to the circuit and return_data = public output of the circuit. I added some comments to this effect

[maramihali]

why is reading more than once something we don't wanna support?

[ledwards2225]

This is done for efficiency reasons, I added an issue explaining this in detail. I marked it as NOTE rather than TODO since this may be an acceptable restriction indefinitely

[maramihali]

Could you explain how/if the readterm - writeterm relate to the calldata and returndata terminology in databus?

[ledwards2225]

I added some more comments in this section to try to clarify. There isn't a direct connection between calldata/returndata and read/write. We can read and write from each column of the databus in the same way. A read is the only thing associated with a gate. "writing" to the columns just amounts to populating them with data (then committing to those columns when constructing a proof). Its possible that "read_terms" and "table_entries" would be better language. I used read/write to be consistent with Zac's original language but I'll keep this in mind as I keep working.

[maramihali]

can you explain why this structure? Afaiu they're copy constraints right?

[ledwards2225]

Added a comment here explaining the basic motivation and linking the original log-derivative lookups paper. The copy constraints mechanism isn't really coming into play here but maybe I'm misunderstanding what you mean

[maramihali]

Do you think it's possible/useful to have at least one failing test as well?

[ledwards2225]

This is a great suggestion and I did think about this but I struggled (and am still struggling) to come up with a way to do it. As you may have noticed, I was very deliberate in limiting the interface to the databus via access specifiers so I'm actually not sure it's possible to create a failing circuit. The only interface is read_bus_vector and if you try to read an invalid index, it will trigger an ASSERT. If you read a valid index, the read gate will be valid by definition. I'll keep thinking about this but if its really the case that an invalid gate can't be created then that seems like a good thing.