feat(AuthWit): simplify create authwit syntax

[LHerskind]

Fixes #4821 and #5075.

Renames the functions related to AuthWit to use a similar naming scheme.

Extends the createAuthWit, setPublicAuthWit and cancelAuthWit functions such that they can now take an object

{
  caller: AztecAddress;
  action: ContractFunctionInteraction | FunctionCall;
},

Allowing for adding a new authwit more simply.

Example:

await user1Wallet.createAuthWit({
  caller: l2Bridge.address,
  action: l2Token.methods.burn(ownerAddress, withdrawAmount, nonce)
});

[LHerskind]

• feat(AuthWit): simplify create authwit syntax #5132 👈
• 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://65f83fe4cac913696d52f726--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.

Values are compared against data from master at commit a26d9685 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	64 txs
l1_rollup_calldata_size_in_bytes	5,668	18,820	36,356
l1_rollup_calldata_gas	66,424	238,648	469,976
l1_rollup_execution_gas	647,522	929,006	1,306,156
l2_block_processing_time_in_ms	1,323 (+2%)	4,843 (+2%)	9,248
note_successful_decrypting_time_in_ms	176 (-5%)	525 (-1%)	1,002 (+3%)
note_trial_decrypting_time_in_ms	80.1 (-13%)	44.4 (-9%)	134 (+26%)
l2_block_building_time_in_ms	18,105 (+1%)	68,269	135,457 (-1%)
l2_block_rollup_simulation_time_in_ms	8,041	28,531	56,123 (-1%)
l2_block_public_tx_process_time_in_ms	10,043 (+1%)	39,682	79,237 (-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	14,394 (+3%)	27,574 (+4%)
note_history_successful_decrypting_time_in_ms	1,229 (-5%)	2,484 (+3%)
note_history_trial_decrypting_time_in_ms	69.7 (-48%)	146 (+26%)
node_database_size_in_bytes	19,136,592	35,725,392
pxe_database_size_in_bytes	29,859	59,414

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	280	44,366	28,244
private-kernel-ordering	215	52,868	14,326
base-parity	1,843 (-3%)	128	311
base-rollup	714 (-1%)	165,787	925
root-parity	1,501 (+3%)	1,244	311
root-rollup	62.8	4,487	789
private-kernel-inner	644 (+1%)	73,771	28,244
public-kernel-app-logic	444	35,260	28,215
public-kernel-tail	173 (+1%)	40,926	28,215
merge-rollup	8.26	2,696	925

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	9.95	15.9	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.8	31.6	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.581	0.493	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	45.5 (-1%)	72.7	229	443 (-2%)	875 (-1%)	1,716 (-1%)	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	96.0	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.467 (-1%)	0.449	0.419	0.415 (-1%)	0.416 (-1%)	0.412	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	53.5 (-4%)	106 (-1%)	335	658	1,302	2,596	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	104	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.476 (-4%)	0.481 (-1%)	0.456	0.453	0.451	0.451	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	60.8 (-1%)
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	109
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.532 (-1%)

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes
tx_size_in_bytes	22,012

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes
tx_pxe_processing_time_ms	3,203	1,754 (+1%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	11.6 (+1%)	1,239

[benesjan]

I think the "AuthWitInput" in the param name is not that great because I see as authwit input the input of this function. Maybe something like msgOrMsgPreimage would be better?

Also the naming here is inconsistent with the rest of the codebase. There is a computeAuthWitMessageHash which returns what you call a message here. I think it would be useful to be consistent with what an authWit message is and I would rename computeAuthWitMessageHash as computeAuthWitMessage and authwit message would everywhere be the hash of caller and action.

[sklppy88]

Yes I think being clear that there is no difference between a Message and Message Hash, as well as there being a Message Input (named AuthWitInput here), which is just the message preimage.

So being super clear, right now we have an AuthWitMessage and an AuthWitMessageInput (which is just the preimage of the AuthWit Message), and this function computes a "live authwit" from either one of these ?

[LHerskind]

It is not only the preimage, it is the action which is then used to generate the pre-image. Could be the "messageHashOrIntent` with danger of opening a can of worms with the intent naming 😆

The message is essentially just a field that we are signing over, and then we are saying it is a hash but it does not strictly need to be 😬 in many cases it would likely be what you are signing over, and there it is often called a message even if it is really a hash of the message. Think ecrecover is calling it a hash, so might be best to go with that notation.

[benesjan]

Here is the incosistency. The message in createAuthWit(...) is messageHash here.

[benesjan]

Suggested change

	// Check that the message hash is no longer valid. Need to try to send since nullifiers are handled by sequencer.
	// Check that the authwit is no longer valid. Need to try to send since nullifiers are handled by sequencer.

I am being annoying here but think the use of authwit is clearer here in the comment given that you call cancelAuthWit above. Outsider would not be sure what is message hash here.

[sklppy88]

Wait we are using 'message hash' here referring to the output of the authwit as well?

So we have message hash that refers to both the hash of the preimage of the authwit input, but also the output of the authwit itself ? 🤯

[LHerskind]

An authwit is some authentication witness for a specific message hash. So the thing you as an user is interested in, is whether the message is valid (with a signature OR if in public as here if the message hash directly is approved in storage).

[benesjan]

Suggested change

	// Check that the message hash is no longer valid. Need to try to send since nullifiers are handled by sequencer.
	// Check that the authwit is no longer valid. Need to try to send since nullifiers are handled by sequencer.

[benesjan]

Looks good. It's a nice improvement. I would just be consistent with message vs message hash naming (it reminds me the note vs note preimage naming mess). But I am aware that that is not directly the scope of this PR so I am fine with that being addressed in another one.

[sklppy88]

Very cool, also +1 to @benesjan's points. But generally unrelated and a super opinionated take (open to being super wrong), I honestly don't like 'AuthWit' as a name in general. It has been shortened from 'AuthWitness,' which already is a bit convoluted, but as a new name, it does not stand on its own. i.e. with no context 'AuthWit' simply does not make any sense—unless we lean into and almost coin a new term for our concept of it, but it's just a bit weird.

Would prefer something that follows in the spirit of 'AuthPass', 'AuthApprove', or even 'AuthPermit'. I.e. you give someone a 'Permit' or 'Approval' to call a flow that would need your permission. Something that more clearly conveys that its a transferable approval of an action (in the sense that someone else uses it on your behalf to do an action that needs your approval).

I don't think any of the aforementioned potential replacements are good either, but I do think that maybe we should reconsider this naming, as I feel like this is something that was set early on and wasn't given too much though, maybe we should though, especially as we start truncating things

[sklppy88]

Yes I think being clear that there is no difference between a Message and Message Hash, as well as there being a Message Input (named AuthWitInput here), which is just the message preimage.

So being super clear, right now we have an AuthWitMessage and an AuthWitMessageInput (which is just the preimage of the AuthWit Message), and this function computes a "live authwit" from either one of these ?

[sklppy88]

Wait we are using 'message hash' here referring to the output of the authwit as well?

So we have message hash that refers to both the hash of the preimage of the authwit input, but also the output of the authwit itself ? 🤯