feat: outgoing messages to any address

[benesjan]

Fixes #4488

Also fixed there 2 commands broken on master.

[benesjan]

Current dependencies on/for this PR:

• master
  • PR feat: outgoing messages to any address #4512 👈

This stack of pull requests is managed by Graphite.

[github-actions]

Changes to circuit sizes

Generated at commit: d67ca330b3bfddb6bbd14ff700f4f4b43cef1a0b, compared to commit: 427f1d8567a3f68c3093c29a2999096746927548

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_app_logic	+10 ❌	+0.02%	+628 ❌	+0.26%
public_kernel_setup	+10 ❌	+0.02%	+628 ❌	+0.26%
private_kernel_inner	+8 ❌	+0.01%	+625 ❌	+0.12%
private_kernel_init	+8 ❌	+0.02%	+6 ❌	+0.00%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_app_logic	44,991 (+10)	+0.02%	243,452 (+628)	+0.26%
public_kernel_setup	44,999 (+10)	+0.02%	243,460 (+628)	+0.26%
private_kernel_inner	93,279 (+8)	+0.01%	523,292 (+625)	+0.12%
private_kernel_init	36,340 (+8)	+0.02%	331,121 (+6)	+0.00%

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 264 (-39%)
• note_trial_decrypting_time_in_ms (8): 76.6 (+83%)

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 e63f0226 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,956	181,604	724,196
l1_rollup_calldata_gas	227,192	888,716	3,535,832
l1_rollup_execution_gas	320,383	1,007,164	3,756,210
l2_block_processing_time_in_ms	1,254 (+4%)	4,482	17,829
note_successful_decrypting_time_in_ms	⚠️ 264 (-39%)	974	3,740 (+3%)
note_trial_decrypting_time_in_ms	⚠️ 76.6 (+83%)	110 (+5%)	177 (+1%)
l2_block_building_time_in_ms	18,241	72,156	290,026
l2_block_rollup_simulation_time_in_ms	13,505	53,363	214,947
l2_block_public_tx_process_time_in_ms	4,710 (+1%)	18,712 (+1%)	74,818 (+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,309 (-4%)	29,486 (-3%)
note_history_successful_decrypting_time_in_ms	2,448 (+7%)	4,660 (+1%)
note_history_trial_decrypting_time_in_ms	93.7 (+7%)	200 (-19%)
node_database_size_in_bytes	17,231,952	33,198,160
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	329 (+1%)	44,568	25,313
private-kernel-ordering	196	43,633	16,193
base-rollup	1,457	129,774	933
root-rollup	83.1 (+1%)	4,192	729
private-kernel-inner	430 (-1%)	70,859	25,313
public-kernel-private-input	243 (+1%)	33,703	26,945
public-kernel-non-first-iteration	242 (+2%)	33,745	26,945
merge-rollup	7.83	2,712	933

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 (-2%)	10.7 (-4%)	12.7 (-1%)	17.0 (-2%)	26.4 (+16%)	64.1	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.591 (-2%)	0.593 (-4%)	0.538 (-1%)	0.524 (-2%)	0.551 (+15%)	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	47.5 (-2%)	238	462 (-1%)	903 (+1%)	3,557
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.465 (-1%)	0.487 (-2%)	0.435	0.432 (-2%)	0.430	0.428
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	105 (+1%)	56.8	353	691 (-1%)	1,367	5,437
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 (+1%)	0.495	0.476 (-1%)	0.474 (-1%)	0.472	0.471
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	57.0	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.577	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	16,859	35,536

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	564 (+2%)	1,446

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.513 (+1%)	582 (+1%)

[LHerskind]

Main thing is the naming, it collides with what we are calling the full thing in solidity so could be confusing 🤔

[LHerskind]

This one gets a little strange when we also have

struct L2ToL1Msg {
    L2Actor: sender,
    L1Actor: recipient,
    bytes32: content,
}

I get that it is the only values that we are really controlling here, but just pointing it out that it can be confusing.

[benesjan]

"Addressed" this just by adding there comments in 6d5c87b

I was considering renaming the thing in Noir and TS to L2ToL1Payload but then I would have to rename new_l2_to_l1_msgs and that would worse the situation.

[LHerskind]

As earlier, this one can be really weird to follow as we have the same name for solidity and outside, but it is not talking about the same thing.

[benesjan]

"Addressed" this just by adding there comments in 6d5c87b

[sklppy88]

Looks good to me !

[sklppy88]

message_portal as a name seems weird. As is, it is a noun, but maybe we want it to be more conveying of an action ?
Like, send_message_to_portal ?

[benesjan]

Idk, I am not a native speaker but saying for example "message Esau" sounds totally fine to me and send_message_to_portal is just too long.

[sklppy88]

I think the difference is that "Message Esau", or "Message Jan" cannot be misconstrued as a singular object, as the separation between action and verb are more pronounced and these are not often used together, but "message portal" can be misunderstood. Especially when it was message_recipient (I know it is has been nuked now but just to make my point clear) i.e. if I call x.message_recipient(), I'll have an initial wonder if I'm grabbing a prop on the object named message_recipient, even if it doesn't make too much sense in the context.

But definitely if we're trying to optimize for terseness then this is the way to go for sure. And this is super nit anyways, I mainly wanted to just give more background on my precious comment 🙃 😄

[benesjan]

Oh ok, got it. You have a point. Maybe renaming it as send_message would be the best. It's short and it really can't mean anything else.

[LHerskind]

There is a { that we could probably get rid of in a comment, but otherwise seems good to me 👍

[LHerskind]

🤣

[LHerskind]

The { don't need to be here

[benesjan]

Addressed in f54ef2d