feat!: alternative key registry contract

[nventuro]

This is a tentative redesign of the key registry contract, which lets us read all 4 keys in a single merkle inclusion proof, while also performing fewer public storage writes. It relies on PublicMutable with custom deadlines instead of SharedMutable as the key registry must be lax during reads to prevent abuse from accounts performing frequent rotation.

This is meant to be a proof of concept and reference for discussion, so there are no tests yet. If we were to adopt this contract it should be relatively straightforward to replace the current getters with get_current_public_keys.

---

Update: we've now decided to move forward with this design, even if whether we actually do have full key rotation is up for debate. This is a good middle ground in terms of the code being performant and easy to either add or remove rotation in the future.

What this PR does is introduce the new registry and switch all old contracts to use it. They'll be using historical mode, i.e. reading keys at a specific block in the past instead of reading the current keys, resulting in no max block number constraints. This is a departure from the current behavior, but is only temporary until we switch over from the old API to the new one (#7953) so that we can then benefit from reduce gate counts (#7954). I've also left the original contract, libraries, etc., unmodified so as to later delete them cleanly instead of making this PR too messy (#7955).

[benesjan]

Given that we need to relax the key constraints due to the potential attacks then this scheme really is a logical conclusion so I'll approve it once it's polished.

Also losing the hard guarantee of fresh keys seems fine to me. In that catastrophic scenario of getting keys leaked I would not care that much that I would potentially lose privacy of a few more notes in the next few blocks after the keys are rotated (someone sending me new notes using my old keys).

@nventuro or can you think of a more significant downside than this ^?

[nventuro]

Also losing the hard guarantee of fresh keys seems fine to me. In that catastrophic scenario of getting keys leaked I would not care that much that I would potentially lose privacy of a few more notes in the next few blocks after the keys are rotated (someone sending me new notes using my old keys).

This post argues why it's fine for senders to use old and leaked keys for some time. I think it's also fine to use new keys immediately - there's no reason we need a strict block of change since we don't need delayed actions. I see no downsides at all in this approach.

[AztecBot]

Docs Preview

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

[AztecBot]

Benchmark results

Metrics with a significant change:

• app_circuit_witness_generation_time_in_ms (SchnorrAccount:constructor): 103 (-40%)
• app_circuit_witness_generation_time_in_ms (Token:privately_mint_private_note): 137 (-37%)
• app_circuit_witness_generation_time_in_ms (Token:transfer): 298 (-27%)
• app_circuit_witness_generation_time_in_ms (Benchmarking:create_note): 101 (-39%)
• avm_simulation_time_ms (Token:transfer_public): 20.1 (-39%)

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.

Proof generation

Each column represents the number of threads used in proof generation.

Metric	1 threads	4 threads	16 threads	32 threads	64 threads
proof_construction_time_sha256_ms	5,759 (-1%)	1,553	694	769 (+1%)	767
proof_construction_time_sha256_30_ms	11,873	3,214 (+1%)	1,429 (+1%)	1,439 (-2%)	1,478
proof_construction_time_sha256_100_ms	44,324	12,811 (+4%)	5,733 (+1%)	5,588 (+1%)	5,599 (+1%)
proof_construction_time_poseidon_hash_ms	78.0	34.0 (-29%)	34.0	59.0 (+2%)	88.0
proof_construction_time_poseidon_hash_30_ms	1,528 (-1%)	420	201	225 (-3%)	265 (-1%)
proof_construction_time_poseidon_hash_100_ms	5,655 (-1%)	1,529	688 (+2%)	725	748 (-2%)

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	4 txs	8 txs	16 txs
l1_rollup_calldata_size_in_bytes	4,324	7,844	14,852
l1_rollup_calldata_gas	49,588	92,436	177,704
l1_rollup_execution_gas	1,294,251	2,042,067	3,869,374
l2_block_processing_time_in_ms	260	448 (+1%)	801 (-4%)
l2_block_building_time_in_ms	9,239 (-1%)	18,222	36,031 (-1%)
l2_block_rollup_simulation_time_in_ms	9,238 (-1%)	18,222	36,031 (-1%)
l2_block_public_tx_process_time_in_ms	7,816 (-1%)	16,669	34,455 (-1%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric	3 blocks	5 blocks
node_history_sync_time_in_ms	3,013	3,879 (+2%)
node_database_size_in_bytes	12,681,296	16,732,240 (-1%)
pxe_database_size_in_bytes	16,254	26,813

Circuits stats

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

Circuit	simulation_time_in_ms	witness_generation_time_in_ms	input_size_in_bytes	output_size_in_bytes	proving_time_in_ms
private-kernel-init	95.6	393 (-2%)	21,846	44,858	N/A
private-kernel-inner	174	691 (-2%)	72,545	45,005	N/A
private-kernel-reset-tiny	503	1,189 (-2%)	69,614	44,844	N/A
private-kernel-tail	272	195 (-1%)	50,760	52,256	N/A
base-parity	5.55	N/A	160	96.0	N/A
root-parity	33.0 (-1%)	N/A	69,084	96.0	N/A
base-rollup	2,857	N/A	187,817	664	N/A
root-rollup	38.4	N/A	54,525	716	N/A
public-kernel-setup	99.5	N/A	103,760	71,222	N/A
public-kernel-app-logic	106	N/A	103,599	71,222	N/A
public-kernel-tail	572	N/A	409,190	16,414	N/A
private-kernel-reset-small	484	N/A	66,533	45,629	N/A
private-kernel-tail-to-public	1,312 (-2%)	699 (-2%)	507,554	1,697	N/A
public-kernel-teardown	94.3	N/A	104,005	71,222	N/A
merge-rollup	19.1	N/A	35,742	664	N/A
undefined	N/A	N/A	N/A	N/A	67,839 (+1%)

Stats on running time collected for app circuits

Function	input_size_in_bytes	output_size_in_bytes	witness_generation_time_in_ms
ContractClassRegisterer:register	1,344	11,731	341 (-1%)
ContractInstanceDeployer:deploy	1,408	11,731	18.0 (-1%)
MultiCallEntrypoint:entrypoint	1,920	11,731	419 (-9%)
FeeJuice:deploy	1,376	11,731	388 (-1%)
SchnorrAccount:constructor	1,312	11,731	⚠️ 103 (-40%)
SchnorrAccount:entrypoint	2,304	11,731	433 (-15%)
Token:privately_mint_private_note	1,280	11,731	⚠️ 137 (-37%)
FPC:fee_entrypoint_public	1,344	11,731	29.4 (+18%)
Token:transfer	1,312	11,731	⚠️ 298 (-27%)
Benchmarking:create_note	1,344	11,731	⚠️ 101 (-39%)
SchnorrAccount:verify_private_authwit	1,280	11,731	27.6 (+1%)
Token:unshield	1,376	11,731	548 (-12%)
FPC:fee_entrypoint_private	1,376	11,731	753 (-11%)

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
FeeJuice:_increase_public_balance	54.2 (+1%)	8,139
FeeJuice:set_portal	9.10 (-7%)	2,362
Token:constructor	91.1 (+10%)	31,107
FPC:constructor	53.4 (+3%)	22,380
FeeJuice:mint_public	38.1 (+1%)	6,150
Token:mint_public	70.3 (-7%)	11,720
Token:assert_minter_and_mint	39.5 (+2%)	8,028
AuthRegistry:set_authorized	35.8	4,537
FPC:prepare_fee	230	8,812
Token:transfer_public	⚠️ 20.1 (-39%)	47,374
FPC:pay_refund	53.3 (-16%)	12,114
Benchmarking:increment_balance	975	7,450
Token:_increase_public_balance	39.8	8,960
FPC:pay_refund_with_shielded_rebate	65.2 (-3%)	12,663

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.165

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	256 leaves	512 leaves	1024 leaves
batch_insert_into_append_only_tree_16_depth_ms	2.16 (-2%)	3.88	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8	31.7	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.111 (-2%)	0.110	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	11.4 (-1%)	17.8 (-1%)	31.8 (+1%)	59.5 (-2%)	112 (-3%)
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	287	543	1,055
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.110 (-1%)	0.103 (-1%)	0.103	0.103 (-1%)	0.100 (-4%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	14.5 (+1%)	25.5 (-2%)	43.7 (-1%)	83.1 (-1%)	158 (-4%)
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	109	207	355	691	1,363
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.110 (+2%)	0.103 (-3%)	0.106 (+1%)	0.103 (-1%)	0.0992 (-6%)
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	16.3 (-1%)	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	132	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.105 (-1%)	N/A	N/A	N/A	N/A

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	64,779	668,997

Transaction size based on fee payment method

| Metric | |
| - | |

[benesjan]

Looks good