feat: hash logs inside circuit

[MirandaWood]

A follow-up to #5718:

• - Hash logs inside the circuit (closing Hash logs inside Noir #1165)

Complete, with some caveats. In most cases, whatever log is being broadcast can be converted to bytes with one of the traits (in log_traits) and sha hashed. Note we now need these traits because sha256_slice has (understandably) been removed, so we must define a fixed length input for generic types.

The one exception to this is broadcasting a contract class which ends up emitting up to 518,400 bytes. This is still hashed in ts via a new oracle method emit_contract_class_unencrypted_log. I believe it's fine to hash this outside of the circuit, because correctness will be guaranteed by the bytecode commitment (as opposed to a generic log, where we need the hash to come from the circuit to trust it).

• - Accumulate logs length inside the circuit

Complete, perhaps we should track lengths of each log to more easily split them into revertible/non-revertible later on?

• - Flat hash the logs in tail + update documentation

Now that sha256_slice is removed, we would have to flat hash all the empty space up to max logs - unsure whether this would give us any benefit?
EDIT: After some testing, it is more efficient for larger numbers of logs (~9+) in both the circuit and L1, so I have implemented flat hashing.

• - Add a logsCache, like noteCache, to track logs + ordering in ts in nested executions

Note that the logsCache is only implemented (and required) in the private context for now.
Public calls don't require squashing and removal of logs representing nullified notes, so an array (allUnencryptedLogs) will do. It currently just keeps track of ordering when we have nested calls, but will be useful for removing transient logs (#1641).

• - Investigate + solve issue with tx.ts error not throwing

I'm not sure why this check exists - the comment:

      // This check is present because each private function invocation creates encrypted FunctionL2Logs object and
      // both public and private function invocations create unencrypted FunctionL2Logs object. Hence "num unencrypted"
      // >= "num encrypted".

implies that functions must emit both types of logs? A tx with one private call, which emits one encrypted log, should fail here, and I don't see why.
EDIT: Have removed the check as it seems redundant.

---

Note that in nested calls that have more than one side effect, logs will have duplicate side effect counters and so cannot be sorted correctly (#6052). Currently the logs collected in allUnencryptedLogs are the only place that have correctly ordered logs in this case.

[AztecBot]

Docs Preview

Hey there! 👋 You can check your preview at https://6633929b48ae560c495b7403--aztec-docs-dev.netlify.app

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

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	740	740	740
l1_rollup_calldata_gas	6,668	6,692	6,680
l1_rollup_execution_gas	586,800	586,824	586,812
l2_block_processing_time_in_ms	1,518 (-10%)	5,448 (-4%)	10,548 (-2%)
l2_block_building_time_in_ms	22,655	89,116	178,829
l2_block_rollup_simulation_time_in_ms	22,453	88,379	177,340
l2_block_public_tx_process_time_in_ms	9,011	35,102 (+1%)	70,223

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,831 (-3%)	31,522 (-1%)
node_database_size_in_bytes	20,750,416	37,331,024
pxe_database_size_in_bytes	29,868	59,425

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	173 (-2%)	46,819	28,822
private-kernel-inner	205	76,734	28,822
private-kernel-ordering	227 (-1%)	53,040	42,751
base-parity	71.9 (+5%)	128	64.0
base-rollup	16,622 (+1%)	111,062	925
root-parity	1,669 (+4%)	27,064	64.0
root-rollup	64.3 (-1%)	11,454	789
public-kernel-app-logic	1,964 (-1%)	54,321	22,677
public-kernel-tail	4,928 (+1%)	159,770	3,898
merge-rollup	6,499	2,696	925
public-kernel-teardown	160 (-1%)	54,321	30,042
public-kernel-setup	219 (-1%)	54,321	30,042

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	11.0	17.8	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.7	31.8	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.641	0.547	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	51.9 (+1%)	80.0	260	502	980 (-1%)	1,958	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	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.531 (+1%)	0.494	0.475	0.469	0.465 (-1%)	0.467	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.6	120	375	741	1,460 (-1%)	2,936	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.534	0.538	0.511	0.510	0.507	0.509	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	66.9
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	108
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.588

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	44,613	535,433

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	897	1,129 (-1%)	1,337 (-1%)

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,386 (-2%)	1,004 (-1%)	3,695 (+1%)

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	891 (+1%)	790	1,432 (+1%)	893 (-4%)	2,196 (+1%)	1,075 (-3%)

[MirandaWood]

Removed this file as it only tested the collect logs functionality, which is now removed.

[MirandaWood]

The AVM context and interface was only changed to allow the public and private contexts to use traits in logs_traits (these define fixed lengths for many types, so we can sha hash inside the circuit). These don't need to be carried over!

[LeilaWang]

Some suggestions (maybe for future PRs). LGTM!

[LeilaWang]

Doesn't need to be public.

[LeilaWang]

Do we still need encryptedLogs/unencryptedLogs?
Wonder if we should only assign all(Un)EncryptedLogs to the top level execution result 🤔

[LeilaWang]

Or emitting the counter (and note hash counter) along with the log preimage via oracle, then we can gather all logs from all nested calls to sort and squash them. I think you've suggested this? Sorry I am being slow. This is probably better than outputting them all in one go.

[MirandaWood]

Do we still need encryptedLogs/unencryptedLogs?

I'm not sure really, but I'm keeping them as some tests rely on those logs being specific to the inidvidual call (i.e. not inlcuding extra logs from nested child/parent calls). Protocol-wise maybe it would be good to still keep track of logs per call to avoid confusion?

Or emitting the counter (and note hash counter) along with the log preimage via oracle, then we can gather all logs from all nested calls to sort and squash them.

Yep, I can do this! I just went for this method, because it seemed like the cleanest way of utilising the logs cache (which is intended mostly for removing transient logs) without adding too much extra code.

In this PR I can make the oracles also emit the log counter, then gather them from nested executions rather than populate a big array. The next PR will tackle separating note hash logs anyway, so I can add the note hash counter as part of that?

[MirandaWood]

Have implemented the above ^

[github-actions]

Changes to circuit sizes

Generated at commit: ecae76f79c0964a4643e7d400557a45be9890213, compared to commit: b39f1db91942096eb1768a37ba9ecfb94d4e1313

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_tail	-1,180 ✅	-0.31%	-72,246 ✅	-4.93%
private_kernel_tail	-3,812 ✅	-3.51%	-74,846 ✅	-19.31%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_tail	382,126 (-1,180)	-0.31%	1,394,138 (-72,246)	-4.93%
private_kernel_tail	104,721 (-3,812)	-3.51%	312,704 (-74,846)	-19.31%

[MirandaWood]

This implements IsEmpty so I can take advantage of the existing method sortByCounter. Happy to move to a new file if it's cleaner.

[LeilaWang]

Great work!