refactor: purging portal addresses

[LHerskind]

Fixes #5836.

Purges the portal addresses from its priveleged storage position and throws it into the darkness of "normal" storage.

[LHerskind]

• refactor: purging portal addresses #5842 👈
• chore: remove get_portal_address oracle #5816
• chore: bump public call depth #5845
• chore: allow expressions in constant generation #5839
• master

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

Join @LHerskind and the rest of your teammates on Graphite

[dbanks12]

Rerun the codegen in the docs to regenerate InstructionSet.mdx from the JS file.

Also to change it everywhere, it needs to be removed in C++ as well. A follow-up pr is fine!

Otherwise all looks good to me!

[AztecBot]

Docs Preview

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

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 202 (+63%)
• note_trial_decrypting_time_in_ms (8): 93.7 (+644%)

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,844	6,844
l1_rollup_execution_gas	587,313	587,325	587,325
l2_block_processing_time_in_ms	1,438	5,318 (-2%)	10,416 (+1%)
note_successful_decrypting_time_in_ms	⚠️ 202 (+63%)	344 (-13%)	707 (+5%)
note_trial_decrypting_time_in_ms	⚠️ 93.7 (+644%)	41.4 (-56%)	111 (+34%)
l2_block_building_time_in_ms	18,860	73,513	146,117
l2_block_rollup_simulation_time_in_ms	18,645	72,751	144,640
l2_block_public_tx_process_time_in_ms	8,470	33,124	66,359 (-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	16,031 (+1%)	30,371
note_history_successful_decrypting_time_in_ms	871 (-9%)	1,731 (+3%)
note_history_trial_decrypting_time_in_ms	89.7 (-29%)	161 (+48%)
node_database_size_in_bytes	19,136,592	35,840,080
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	156	47,763	31,978
private-kernel-inner	176	80,794	31,978
private-kernel-ordering	136 (-1%)	57,732	50,043
base-parity	74.2 (-2%)	128	265
root-parity	126 (-2%)	1,244	265
base-rollup	12,224 (-1%)	110,926	957
root-rollup	49.9	4,551	821
public-kernel-app-logic	1,668 (+1%)	62,017	52,067
public-kernel-tail	4,202 (-1%)	168,566	7,491
merge-rollup	3,160 (+1%)	2,760	957
public-kernel-teardown	119 (+2%)	62,017	52,067
public-kernel-setup	119 (+1%)	62,017	52,067

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.0 (+1%)	17.6	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.641 (+1%)	0.545	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	51.3	80.2	258	501	978	1,942	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.526	0.495	0.470	0.468	0.465	0.465	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.5 (+1%)	118 (-1%)	374 (-1%)	737	1,461	2,914	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.534	0.534	0.510	0.507	0.506	0.508	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.5
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.588

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	51,411	543,524 (+1%)

Transaction size based on fee payment method

Metric	native fee payment method	fpc_public fee payment method	fpc_private fee payment method
tx_with_fee_size_in_bytes	897	1,145	1,345

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	1,264 (+1%)	861	3,501 (+1%)

Metric	1 public data writes	2 public data writes	3 public data writes	4 public data writes	5 public data writes	8 public data writes
tx_sequencer_processing_time_ms	835 (-1%)	775 (+12%)	1,370 (+2%)	915 (+1%)	2,109 (+2%)	1,103 (-5%)

[fcarreiro]

Nice, LGTM for the AVM.

[sklppy88]

some tiny nits, looks good to me 👍

[sklppy88]

Suggested change

As outlined in [Communication](../../../../learn/concepts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal don't actually need to be a contract, it could be any address on L1.

As outlined in [Communication](../../../../learn/concepts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal doesn't actually need to be a contract, it could be any address on L1.

[sklppy88]

Do we need to nuke this here as well?

[sklppy88]

Repeat of step 2, steps should all be +1 from here

[LHerskind]

It don't make a diff in the rendering, but will fix

[sklppy88]

A bit awk as is, maybe consider another way, an ex below

Suggested change

	The deployment have been cleansed from the portal addresses as a immutable value passed in differently to other variables and instead should be implemented using usual storage by those who require it using the storage that matches the usecase - likely the shared storage to support private and public.
	Deployments have been modified. No longer are portal addresses treated as a special class, being immutably set on creation of a contract. They are no longer passed in differently compared to the other variables and instead should be implemented using usual storage by those who require it. One should use the storage that matches the usecase - likely shared storage to support private and public.

[sklppy88]

Suggested change

	Some contracts on L2 might wish to talk to contract on L1 - these recipients on L1 are called portals.
	Some contracts on L2 might wish to talk to contracts on L1 - these recipients on L1 are called portals.

[fcarreiro]

I think the next release will be 0.36.0. Rahul had me rename the TBD to that but double check with him.

[nventuro]

I'd add this here:

struct Storage {
+   portal_address: SharedImmutable<AztecAddress>,
}

Can't do a proper gh suggestion since the code formatting screws up with the suggestion formatting 🤦

[LHerskind]

If done in GH, you can write "suggestion" as the language.