feat: auth registry

[LHerskind]

This pr alters how we are using the public authwits. Namely it will update where they are stored AND how they are consumed.

Instead of storing them in every account contract, they are now stored in a shared public auth registry. The registry essentially keep track of a large map, that maps account => action => authorized. When allowing something with a public authwit, the authorized is set to true and when consuming, the value is set to false.

The reasoning behind the change is fairly simple. If it was required to authorize an authwit in the non-revertible phase of a transaction (say for fees) it needed to execute code on the account contract. Since this phase as phase don't support reverts while still paying a fee, it allowed for a DOS of the sequencer by inserting very computational tasks into your account contract.

When it is now in a common registry, the sequencer will only need to execute enqueued public calls to this registry, which is much easier to verify since it is the same for all accounts and have little flexibility for extra logic.

In the old model, we were emitting a nullifier when the authwit was "consumed" (public or private did not matter here). This change is instead updating the mapping to ensure that there are no duplicate nullifiers, and to support for "squashing" of public authwits. For example if you are inserting the authwit because you need to use it in the same transaction it can be removed again adding no state diff, this reduces the data overhead by 96 bytes for this case, at the cost of increasing by 32 bytes if the approval happens in a separate transaction.

While we have solved the DOS issue that our old design had, it also take away some of the flexibility that we had. Before you could have that certain accounts where allowed to more flexible things on your behalf by having extra logic for it, and also allow mass revoking. To support the mass revoking case, the registry includes a reject_all map, that is keeping a flag for each account whether to reject authwits or not. This allows a user that have made approvals to pages that have not yet been spent to update this one flag, revoking all of his approvals at once. Ideally there should not be a lot of outstanding authwits, as they should be created on demand, but for applications such as request-for-quote DEXes, there might be authwits created that are unspent.

API wise, there should be no big surprises for consuming authwits in your contracts. The auth library have received a slight update to call into the registry instead of the account contracts.

Also there are some helper functions for adding the authwits from contracts.

The AccountWallet have been extended slightly to address the logic better and now have a more clear distinction for what is public.

[LHerskind]

• feat: auth registry #7035 👈
• test: add transfer to undeployed account #7015
• refactor: transfer and transferfrom to save constrains for simpler cases #7013
• refactor: note emission #7003
• refactor: split log emission to encrypt and a log, remove address input #6987
• master

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

Join @LHerskind and the rest of your teammates on Graphite

[AztecBot]

Docs Preview

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

[AztecBot]

Benchmark results

Metrics with a significant change:

• protocol_circuit_witness_generation_time_in_ms (public-kernel-tail): 37,393 (+34%)
• protocol_circuit_proving_time_in_ms (private-kernel-tail-to-public): 100,713 (+17%)
• protocol_circuit_proving_time_in_ms (avm-circuit): 3,878 (+16%)
• protocol_circuit_proving_time_in_ms (base-rollup): 86,172 (+19%)
• protocol_circuit_proving_time_in_ms (root-parity): 42,924 (+27%)
• protocol_circuit_proving_time_in_ms (public-kernel-setup): 45,307 (+17%)
• protocol_circuit_proving_time_in_ms (public-kernel-teardown): 46,831 (+17%)
• protocol_circuit_proving_time_in_ms (public-kernel-tail): 193,958 (+17%)
• protocol_circuit_proving_time_in_ms (root-rollup): 23,280 (+19%)
• node_database_size_in_bytes (3): 12,210,256 (+16%)

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_30_ms	11,690	3,119	1,479 (+3%)	1,451 (-14%)	1,504 (-2%)
proof_construction_time_sha256_100_ms	43,612	11,734	5,435	5,407	5,345
proof_construction_time_poseidon_hash_ms	78.0	34.0	34.0	58.0 (+2%)	88.0 (+1%)
proof_construction_time_poseidon_hash_30_ms	1,514	416	200	227 (+1%)	266 (-1%)
proof_construction_time_poseidon_hash_100_ms	5,730	1,558	723	771 (-4%)	801 (+1%)

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	1,412	1,412	1,412
l1_rollup_calldata_gas	9,476	9,474	9,464
l1_rollup_execution_gas	610,297	610,295	610,285
l2_block_processing_time_in_ms	754 (+1%)	1,409	2,677
l2_block_building_time_in_ms	25,551 (+2%)	51,307 (+2%)	99,416 (+1%)
l2_block_rollup_simulation_time_in_ms	25,454 (+2%)	50,985 (+2%)	99,067 (+1%)
l2_block_public_tx_process_time_in_ms	21,853 (+2%)	47,209 (+2%)	95,374 (+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	6,882 (+8%)	9,881 (+5%)
node_database_size_in_bytes	⚠️ 12,210,256 (+16%)	16,105,552 (+12%)
pxe_database_size_in_bytes	9,246	15,133

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	proving_time_in_ms	input_size_in_bytes	output_size_in_bytes	proof_size_in_bytes	num_public_inputs	size_in_gates
private-kernel-init	132 (+2%)	470 (-5%)	12,552 (+4%)	20,634	67,190	92,352	2,819	524,288
private-kernel-inner	393	1,091 (+7%)	50,180 (+11%)	94,902	67,190	92,352	2,819	2,097,152
private-kernel-tail	374 (+1%)	1,846 (-3%)	52,525 (+14%)	99,121	71,733 (-5%)	14,912	399	2,097,152
base-parity	6.27 (+1%)	1,889 (-3%)	2,716 (+7%)	128	64.0	2,208	2.00	131,072
root-parity	48.8 (-1%)	62.5 (+26%)	⚠️ 42,924 (+27%)	27,100	64.0	2,720	18.0	2,097,152
base-rollup	7,908 (-7%)	4,437 (+1%)	⚠️ 86,172 (+19%)	170,330	756	3,648	47.0	4,194,304
root-rollup	110 (-2%)	76.6 (+25%)	⚠️ 23,280 (+19%)	25,309	620	3,456	41.0	1,048,576
public-kernel-setup	723 (-2%)	3,269 (+3%)	⚠️ 45,307 (+17%)	116,905	93,334	125,344	3,850	2,097,152
public-kernel-app-logic	612	4,144	46,729 (+15%)	116,905	93,334	125,344	3,850	2,097,152
public-kernel-tail	1,416	⚠️ 37,393 (+34%)	⚠️ 193,958 (+17%)	511,910	10,014	14,912	399	8,388,608
private-kernel-reset-small	595 (+1%)	2,160 (+3%)	45,688 (+13%)	123,313	67,190	92,352	2,819	2,097,152
public-kernel-teardown	619 (-1%)	4,119 (-2%)	⚠️ 46,831 (+17%)	116,905	93,334	125,344	3,850	2,097,152
merge-rollup	28.9 (+1%)	N/A	N/A	16,542	756	N/A	N/A	N/A
private-kernel-tail-to-public	N/A	6,733 (-5%)	⚠️ 100,713 (+17%)	N/A	N/A	125,344	3,850	4,194,304
avm-circuit	N/A	N/A	⚠️ 3,878 (+16%)	N/A	N/A	87,734	0.00	0.00

Stats on running time collected for app circuits

Function	input_size_in_bytes	output_size_in_bytes	witness_generation_time_in_ms	proof_size_in_bytes	proving_time_in_ms	size_in_gates	num_public_inputs
ContractClassRegisterer:register	1,344	9,944	408 (+1%)	N/A	N/A	N/A	N/A
ContractInstanceDeployer:deploy	1,408	9,944	40.1 (-4%)	N/A	N/A	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	9,944	1,784 (-12%)	N/A	N/A	N/A	N/A
GasToken:deploy	1,376	9,944	969 (-5%)	N/A	N/A	N/A	N/A
SchnorrAccount:constructor	1,312	9,944	1,431 (-2%)	N/A	N/A	N/A	N/A
SchnorrAccount:entrypoint	2,304	9,944	2,850	16,768	54,842 (+8%)	2,097,152	457
Token:privately_mint_private_note	1,280	9,944	1,654 (-5%)	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_public	1,344	9,944	354 (-6%)	16,768	11,064 (+7%)	524,288	457
Token:transfer	1,312	9,944	4,817 (-2%)	16,768	51,636 (+11%)	2,097,152	457
Benchmarking:create_note	1,344	9,944	1,396	N/A	N/A	N/A	N/A
SchnorrAccount:spend_private_authwit	1,280	9,944	75.8	N/A	N/A	N/A	N/A
Token:unshield	1,376	9,944	3,980	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_private	1,376	9,944	4,943 (+1%)	N/A	N/A	N/A	N/A

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
GasToken:_increase_public_balance	68.0	13,873
GasToken:set_portal	16.4 (-1%)	3,495
Token:constructor	93.3	24,207
FPC:constructor	61.2 (-2%)	13,893
GasToken:mint_public	52.1 (-2%)	10,241
Token:mint_public	620	19,216
Token:assert_minter_and_mint	59.0 (-21%)	13,034
AuthRegistry:set_authorized	32.1	7,869
FPC:prepare_fee	86.3 (+16%)	15,187
Token:transfer_public	36.2 (+4%)	31,425 (+1%)
FPC:pay_refund	57.1 (-12%)	20,080
Benchmarking:increment_balance	2,691 (+2%)	15,465
Token:_increase_public_balance	58.5 (+2%)	15,089
FPC:pay_refund_with_shielded_rebate	53.5 (+2%)	21,167

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.191 (+13%)

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	10.3	16.7 (-1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8 (+1%)	31.7	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.594 (-1%)	0.514 (-1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	48.4 (-1%)	75.4 (-2%)	130 (-1%)	244 (-1%)	465
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.494 (-1%)	0.464 (-2%)	0.448	0.443	0.435
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	59.0 (-1%)	111	182 (+1%)	350	687
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.500 (-1%)	0.497	0.481	0.475	0.472
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	72.5 (-3%)	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	133 (-1%)	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.516 (-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	85,672	670,983 (-1%)

Transaction size based on fee payment method

| Metric | |
| - | |

[benesjan]

Nice work. Feel free to merge once you address my comments

[benesjan]

Suggested change

As noted earlier, we could use the ERC20 standard for public. But this seems like a waste when we have the ability to try righting some wrongs. Instead, we can expand our AuthWit scheme to also work in public. This is actually quite simple, instead of asking an oracle (which we can't do as easily because not private execution) we can just store the AuthWit in a shared registry, and look it up when we need it. While this needs the storage to be updated ahead of time (can be same tx), we can quite easily do so by batching the AuthWit updates with the interaction - a benefit of Account Contracts. A shared registry is used such that execution from the sequencers point of view will be more straight forward and predictable. Furthermore, since we have the authorization data directly in public state, if they are both set and unset (authorized and then used) in the same transaction, there will be no state effect after the transaction for the authorization which saves gas ⛽.

As noted earlier, we could use the ERC20 standard for public. But this seems like a waste when we have the ability to try righting some wrongs. Instead, we can expand our AuthWit scheme to also work in public. This is actually quite simple, instead of asking an oracle (which we can't do as easily because not private execution) we can just store the AuthWit in a shared registry, and look it up when we need it. While this needs the storage to be updated ahead of time (can be same tx), we can quite easily do so by batching the AuthWit updates with the interaction - a benefit of Account Contracts. A shared registry is used such that execution from the sequencer's point of view will be more straight forward and predictable. Furthermore, since we have the authorization data directly in public state, if they are both set and unset (authorized and then used) in the same transaction, there will be no state effect after the transaction for the authorization which saves gas ⛽.

[benesjan]

First sentence doesn't make sense.

[benesjan]

Suggested change

	For the typescript wallets this is handled so the API's don't change, but account contracts should get rid of their current setup with `approved_actions`.
	For the typescript wallets this is handled so the APIs don't change, but account contracts should get rid of their current setup with `approved_actions`.

[benesjan]

I feel like this is a bit confusing because from looking at it I would guess that all the authwits are nullified for good. But this essentially just makes them unspendable until you set reject to false again.

What is the intention here? Is it to give user a time to manually deauthorize all the authwits? Or is the expectation that user just sets this and then never sets any public authwits with that particular account?

[LHerskind]

The expectation is that it is a "panic-button" making it easy for a user to make sure their funds stays put, and then can then handle them as they want in the tempo they desire.

[benesjan]

Suggested change

	* Updates the `authorized` value for `msg_sender` for `messageHash`.
	* Updates the `authorized` value for `msg_sender` for `message_hash`.

[benesjan]

Suggested change

	// the key registry has already been deployed to the correct address.
	// the auth registry has already been deployed to the correct address.

[benesjan]

This issue is still relevant, no? If yes please keep the todo.

[LHerskind]

The todo for the #6021 was still in there so thought that was sufficient, but will update.

[benesjan]

I feel like this change makes the type hacky. Instead I would prefer if you just explicitly list the functions below or if you created AllowedContract type.

[just-mitch]

Might we want to be so verbose as to have

• AllowedInstance
• AllowedInstanceFunction
• AllowedClass
• AllowedClassFunction

[LHerskind]

It is to allow the case where a full contract is added to the whitelist. For example, the auth contract in its entirety can be allowed instead of needing to add each function individually.

[just-mitch]

Yes, so I think possible confusion comes because the type is allowed "Function". Perhaps we instead just want to rename the type to AllowedEndpoint

[benesjan]

Suggested change

	// We check to see if there exists a contract at the canonical Key Registry address with the same contract class id as we expect. This means that
	// We check to see if there exists a contract at the canonical Auth Registry address with the same contract class id as we expect. This means that

[benesjan]

Suggested change

	// the key registry has already been deployed to the correct address.
	// the auth registry has already been deployed to the correct address.