feat: add meta_hwm to PrivateCircuitPublicInputs

[alexghr]

This PR adds meta_hwm to the context and exposes it through the private circuits so that in the last circuit the side effects created during private execution can be partitioned into reversible and irreversible effect sets

Fix #4084

[github-actions]

Changes to circuit sizes

Generated at commit: 0ff06d9acc369c749d0902a0c487684d38334ba0, compared to commit: c918d8d1a6ba306afd2feab97ddb8527b76d1a82

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_ordering_simulated	+73 ❌	+10.37%	+141 ❌	+3.46%
private_kernel_inner	+2 ❌	+0.00%	+314 ❌	+0.06%
public_kernel_public_previous_simulated	+1 ❌	+0.08%	+2 ❌	+0.04%
private_kernel_inner_simulated	+1 ❌	+0.08%	+2 ❌	+0.04%
public_kernel_private_previous_simulated	+1 ❌	+0.08%	+2 ❌	+0.04%
private_kernel_init_simulated	+1 ❌	+0.08%	+2 ❌	+0.04%
private_kernel_ordering	+53 ❌	+0.03%	+106 ❌	+0.02%
private_kernel_init	+2 ❌	+0.01%	+3 ❌	+0.00%
public_kernel_public_previous	+1 ❌	+0.00%	+2 ❌	+0.00%
public_kernel_private_previous	+1 ❌	+0.00%	+2 ❌	+0.00%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_ordering_simulated	777 (+73)	+10.37%	4,216 (+141)	+3.46%
private_kernel_inner	92,702 (+2)	+0.00%	519,598 (+314)	+0.06%
public_kernel_public_previous_simulated	1,189 (+1)	+0.08%	5,013 (+2)	+0.04%
private_kernel_inner_simulated	1,189 (+1)	+0.08%	5,013 (+2)	+0.04%
public_kernel_private_previous_simulated	1,189 (+1)	+0.08%	5,013 (+2)	+0.04%
private_kernel_init_simulated	1,189 (+1)	+0.08%	5,013 (+2)	+0.04%
private_kernel_ordering	196,243 (+53)	+0.03%	504,444 (+106)	+0.02%
private_kernel_init	36,388 (+2)	+0.01%	331,229 (+3)	+0.00%
public_kernel_public_previous	46,947 (+1)	+0.00%	250,824 (+2)	+0.00%
public_kernel_private_previous	46,955 (+1)	+0.00%	250,832 (+2)	+0.00%

[AztecBot]

Benchmark results

Metrics with a significant change:

• batch_insert_into_indexed_tree_20_depth_ms (2048): 1,368 (-17%)
• batch_insert_into_indexed_tree_20_depth_ms (8192): 5,385 (-18%)
• note_history_trial_decrypting_time_in_ms (5): 168 (+83%)
• note_trial_decrypting_time_in_ms (8): 19.7 (-82%)

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 4f6d607d 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,636	180,516	720,036
l1_rollup_calldata_gas	222,480	870,996	3,465,852
l1_rollup_execution_gas	314,967	988,736	3,685,509
l2_block_processing_time_in_ms	1,162 (-11%)	4,350 (-14%)	17,154 (-15%)
note_successful_decrypting_time_in_ms	308 (+3%)	956 (-2%)	3,586 (-3%)
note_trial_decrypting_time_in_ms	⚠️ 19.7 (-82%)	84.7 (-20%)	137 (-10%)
l2_block_building_time_in_ms	17,862 (+1%)	70,626	283,375 (+1%)
l2_block_rollup_simulation_time_in_ms	13,040	51,551	207,557
l2_block_public_tx_process_time_in_ms	4,792 (+3%)	18,994 (+2%)	75,561 (+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	13,752	26,517 (+1%)
note_history_successful_decrypting_time_in_ms	2,319 (-4%)	4,554 (-7%)
note_history_trial_decrypting_time_in_ms	⚠️ 168 (+83%)	207 (+8%)
node_database_size_in_bytes	17,350,736	33,226,832 (+1%)
pxe_database_size_in_bytes	29,923	59,478

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	309	44,512	26,225
private-kernel-ordering	198 (+3%)	44,545	16,625 (+11%)
base-rollup	1,403	129,002	881
root-rollup	82.4	4,088	677
private-kernel-inner	443 (+2%)	71,703	26,225
public-kernel-private-input	246 (+3%)	32,647	26,225
public-kernel-non-first-iteration	245 (+3%)	32,689	26,225
merge-rollup	7.59 (-1%)	2,608	881

Tree insertion stats

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

Metric	1 leaves	2 leaves	8 leaves	16 leaves	32 leaves	128 leaves	64 leaves	512 leaves	1024 leaves	2048 leaves	8192 leaves
batch_insert_into_append_only_tree_16_depth_ms	10.2 (-1%)	11.3 (+6%)	12.8	17.2 (+3%)	23.0 (-1%)	63.9	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.9	17.5	23.0	31.6	47.0	143	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.593	0.631 (+6%)	0.543	0.534 (+4%)	0.480 (-1%)	0.442	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	N/A	N/A	N/A	75.4 (+1%)	47.5	240	465 (+1%)	908 (+1%)	3,552
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	N/A	N/A	N/A	159	96.0	543	1,055	2,079	8,223
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.466 (+1%)	0.488	0.437	0.434 (+1%)	0.432	0.428
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	104 (-4%)	56.7	352 (-1%)	687 (-1%)	⚠️ 1,368 (-17%)	⚠️ 5,385 (-18%)
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	N/A	N/A	N/A	197	104	691	1,363	2,707	10,771
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.497 (-4%)	0.498	0.476	0.473	0.476 (-17%)	0.470 (-18%)
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	56.4 (-6%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	94.1	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	0.578 (-6%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A

Miscellaneous

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

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	17,271 (+11%)	40,063 (+5%)

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	575 (+3%)	1,316 (+1%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.502 (-5%)	589 (+2%)

[spalladino]

Change looks good! My only nitpick is about naming. For AccumulatedMetaData, I'd argue that the commitments, nullifiers, and public calls of a tx are not metadata in the strict sense, and besides, "metadata" is often too overloaded as a term that it has pretty much lost all meaning by now. I feel like "side effects" (or maybe just "effects"!) is a better name.

Same applies to meta_hwm or the _PER_TX_META constants. Maybe it's clearer if we use the term "phases" to refer to them? Without the context of this PR, it's difficult to understand from their names what they refer to.

All that said, naming is always an annoying conversation, so feel free to push this back for later.

[spalladino]

Whenever I see a change like this one I wonder how many hours of debugging were lost to lack of meaningful error messages.

[just-mitch]

@spalladino I agree with with the naming nit. We picked the super generic turn meta since it will contain

• effects for fee prep
• enqueued calls for fee prep and fee distribution
• the transaction nullifier

We would've kept the much tighter naming tied to "fees" were it not for the inclusion of the transaction nullifier. @alexghr had advocated for something mentioning that these effects are non-revertible (or perhaps "irrevertible").

Very open to naming changes: the genericity muddies the water.

[spalladino]

Perhaps we can refer to ordering rather than effects? Like initial/preparation/setup/bootstrap phase?

[PhilWindle]

Looks ok, though I'm not very familiar with many areas of the impacted code base so wouldn't be confident approving it.

When it comes to naming, I do like the idea of using 'irrevertible' to distinguish the first phase.

[alexghr]

re naming, if it's ok we'll do it in a separate PR (this PR has already caused a bunch of merge conflicts).

I'd like to throw in another name idea into the mix: "envelope". Drawing an analogy from transactions == messages == letters, an envelope contains both a letter's metadata (or a transaction's hash) and a stamp (e.g. the fee). Thoughts?

[spalladino]

I like it, but I'm worried that envelope is already a thing in Ethereum (see https://eips.ethereum.org/EIPS/eip-2718), so it may be confusing if we use it for something else.

[sirasistant]

Looks good! One small question

[sirasistant]

Why 2 more? isn't just one new field?

[just-mitch]

Thank you Alvaro! This was a mistake while resolving merge conflicts.

[alexghr]

That's what I'm trying to figure out 😆. This was after a merge conflict
NVM @just-mitch figured it out