feat: generic key validation request

[benesjan]

Fixes #6093

[benesjan]

• feat: generic key validation request #6474 👈
• refactor: get_nullifier_keys cleanup #6451
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @benesjan and the rest of your teammates on Graphite

[github-actions]

Changes to circuit sizes

Generated at commit: 32000e548e3ed4ff1126f1394a56d4bfb0885b54, compared to commit: 8e8d2ddd5eefed4f5ca7248b882dfc3d8287d1bb

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset	+256 ❌	+0.10%	+256 ❌	+0.01%
private_kernel_reset_medium	+16 ❌	+0.01%	+16 ❌	+0.00%
private_kernel_reset_big	+16 ❌	+0.01%	+16 ❌	+0.00%
private_kernel_reset_small	+8 ❌	+0.01%	+8 ❌	+0.00%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset	257,443 (+256)	+0.10%	2,528,135 (+256)	+0.01%
private_kernel_reset_medium	148,060 (+16)	+0.01%	1,197,386 (+16)	+0.00%
private_kernel_reset_big	173,380 (+16)	+0.01%	1,547,098 (+16)	+0.00%
private_kernel_reset_small	134,285 (+8)	+0.01%	1,013,116 (+8)	+0.00%

[AztecBot]

Docs Preview

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

[benesjan]

Other than adding computeAppSecretKey just renamed this file from index.ts to derivation.ts.

[sklppy88]

Looks very nice. I agree on your points regarding the keystore.

Although I think you may have forgot some cases to rename.

Approving now though as it seems like the changes required are purely cosmetic.

Feel free to merge once addressed. Also feel free to re-request a review if you think necessary, up to you.

[AztecBot]

Benchmark results

Metrics with a significant change:

• app_circuit_proving_time_in_ms (FPC:fee_entrypoint_private): 12,217 (+37%)
• protocol_circuit_witness_generation_time_in_ms (private-kernel-reset-small): 2,950 (+16%)
• protocol_circuit_witness_generation_time_in_ms (public-kernel-teardown): 425 (+26%)

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	772	772	772
l1_rollup_calldata_gas	6,832	6,868	6,856
l1_rollup_execution_gas	587,372	587,408	587,396
l2_block_processing_time_in_ms	1,369 (-1%)	5,108	10,078
l2_block_building_time_in_ms	33,284 (-1%)	130,913	261,341
l2_block_rollup_simulation_time_in_ms	33,105 (-1%)	130,278	260,093
l2_block_public_tx_process_time_in_ms	15,424 (-1%)	66,360	133,499 (-1%)

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	15,178 (-1%)	28,319 (-1%)
node_database_size_in_bytes	21,405,776	38,281,296
pxe_database_size_in_bytes	29,868	59,425

Circuits stats

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

Circuit	protocol_circuit_simulation_time_in_ms	protocol_circuit_witness_generation_time_in_ms	protocol_circuit_proving_time_in_ms	protocol_circuit_input_size_in_bytes	protocol_circuit_output_size_in_bytes	protocol_circuit_proof_size_in_bytes	protocol_circuit_num_public_inputs	protocol_circuit_size_in_gates
private-kernel-init	154	3,654	21,184 (-2%)	19,987	61,999	86,720	2,643	1,048,576
private-kernel-inner	539	4,535 (-7%)	41,822 (+3%)	89,054	61,999	86,720	2,643	2,097,152
private-kernel-reset-small	551	⚠️ 2,950 (+16%)	23,064 (-1%)	117,961	61,999	86,720	2,643	1,048,576
private-kernel-tail	531	4,017 (+2%)	38,139 (+1%)	86,849	79,454	10,688	267	2,097,152
base-parity	7.71 (+1%)	872 (-1%)	4,429 (-1%)	128	64.0	2,208	2.00	131,072
root-parity	49.2 (+1%)	126 (-3%)	40,242 (+1%)	27,064	64.0	2,720	18.0	2,097,152
base-rollup	864 (+1%)	5,344	43,478 (+1%)	111,158	957	3,136	31.0	2,097,152
root-rollup	65.7	174	8,446 (+1%)	11,518	821	3,456	41.0	524,288
public-kernel-app-logic	189 (-1%)	319 (-1%)	794 (-2%)	96,979	85,095	116,448	3,572	4,096
public-kernel-tail	852	839 (-1%)	1,129 (+5%)	388,207	7,755	10,176	251	512
public-kernel-setup	166	357 (+2%)	1,015	138,310	85,095	116,448	3,572	4,096
public-kernel-teardown	165 (+1%)	⚠️ 425 (+26%)	958 (-8%)	143,321	85,095	116,448	3,572	4,096
merge-rollup	6.56	87.5 (+3%)	1,612	2,760	957	3,136	31.0	65,536
private-kernel-tail-to-public	N/A	10,203 (+7%)	72,938	N/A	N/A	116,960	3,588	4,194,304

Stats on running time collected for app circuits

Function	app_circuit_proof_size_in_bytes	app_circuit_proving_time_in_ms	app_circuit_size_in_gates	app_circuit_num_public_inputs
SchnorrAccount:entrypoint	16,128	49,135 (+2%)	2,097,152	437
Test:emit_nullifier	16,128	2,628 (-2%)	65,536	437
FPC:fee_entrypoint_public	16,128	16,530	524,288	437
FPC:fee_entrypoint_private	16,128	⚠️ 12,217 (+37%)	524,288	437
Token:unshield	16,128	46,146 (-9%)	2,097,152	437
SchnorrAccount:spend_private_authwit	16,128	2,686	131,072	437
Token:transfer	16,128	35,315	2,097,152	437

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.2	18.4	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.654	0.565	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	52.4	81.1	262 (-1%)	506	989	1,951 (-1%)	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.536	0.501	0.476 (-1%)	0.472	0.469	0.467	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	62.4	119 (-1%)	380	743	1,469	2,922 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	106	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.543	0.535	0.515	0.511	0.509	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	67.7
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.593

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	84,743	673,221

Transaction size based on fee payment method

| Metric | |
| - | |

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	28,847 (+1%)	3,109	96,938 (-1%)

Metric	0 public data writes	1 public data writes	2 public data writes	4 public data writes	8 public data writes
tx_sequencer_processing_time_ms	1,328 (-2%)	2,148	1,865	2,761	1,766

[LHerskind]

Hmmm. Just me thinking here.

If I am creating new notes, I will be constraining the npk_m for every recipient, but then I also need to do a validation request for my outgoing key ovpk. Here I am not having this issue that If I created 16 notes, I will run out of requests before I can actually emit them all 😬

Applications such as dispurse seems likely to run into these issues. In most cases I think a user would only be using one outgoing key throughput their flow, but every call might fetch one so it seems fairly likely that we would run out even if the individual calls dont?

[benesjan]

So what do you think should be done here? Just increasing the constant or somehow trying to prune redundant requests across calls? And what is dispurse app?

[LHerskind]

I think we can likely add a todo, since there was a nother location stating that it would be addressed with the databus anyway? (think I added a note there).

Think I meant disperse, but essentially a large multisend where you are sending to N users, so in this case if you send the max number of notes you would end up needing more than N key validation requests which run into an out of bounds, but as said with the databus seems a pain to optimise it now for it to not be constrained in a similar manner later 🤷

The comment was in #6474 (comment)

[LHerskind]

Not related to your PR, just me being confused here, why is it ia note preimage hash here? What is that actually used for 🤔 @dbanks12 I might annoy you with this? Why is it a pre-image hash? We are usually providing a hash of the full log which is a full section of encrypted data for the notes.

[benesjan]

I would say it's just stale.

[dbanks12]

I have no clue! I am very out of the loop with how logs / log-hashes work....

[LHerskind]

Oh, sorry for tagging you @dbanks12, just saw now it was the private kernel 😬 I tagged you in.

[LHerskind]

Following comment earlier. If we don't run into these limits because of the reset circuits, we can probably keep it is as for now but add a comment on it to make sure it is not forgotten and breaks applications in the future? 👀

[LHerskind]

Is this really hints? Usually the hints have been stuff like merkle paths where it was easily validated that not lying etc, but what actually happens if I provide "wrong" paths here with a malicious oracle?

[benesjan]

The values are used to verify that the keys in KeyValidationRequest can be derived using the hints (sk_m and sk_app generator index). So if you provide wrong hints here the proof would fail.

[LHerskind]

With the changes from prior addresses or new issues created. 🚢