feat: constraining slots

[LHerskind]

Fixes 7656.

Following an earlier PR (#7594), we added slots into the mix. This PR tackles actually using those slots for something. When adding these constraints, several fixes were needed on the sequencing clients and its components.

So why are we introducing slots? There is really two things that we are going to use the slots for:

• i) We are going to use it to deal with time within the L2
  • Previously a sequencer had flexibility on how the defined the timestamp, now it is instead defined as GENESIS + slot * slot_duration depending solely on the slot.
• ii) We will be using it as the unit of time in which a specific proposer have rights to proposer a block and where the block will be accepted on chain.
  • This means that it is a timeliness requirement for block inclusion on L1
  • Since the proposer can only use the "current" slot as the value for his block, he no flexibility on the timestamp of the L2 block.

The first term is mainly of interest to applications, but the second term is really important for how our sequencer selection works. If you do not propose within your block, you are tough out of luck, the block will not be accepted on L1.

This means that it is also very important for us to figure out a proper slot duration, since a short slot duration can lead to plenty of empty slots, while too long lead to loss in throughput.

Introducing such a strict timeliness requirement does impact our current tests quite a lot, since they are all created without that in mind (similar was the sequencer client).

Since we in our E2E are the only producer of L1 blocks as well, we have full control over those. However, using automine on Anvil as the underlying chain makes the behaviour of sequencing with slots quite odd, as things that would normally be within the same block (multiple tx) will now progress time at every tx. This meant that the tests broke horribly, as we with one tx was publishing the data for our block, and then when we wanted to publish the block afterwards the time was progressed, so we might no longer be the proposer.

This was handled by adding a combination call that is doing publishAndProcess of a block, making sure that we don't progress time unnecessarily.

Secondly, when we are using on-demand mining (automine), we won't have that we get to the "next" slot after a block have been included, so to not mess to much with timing, we have specified the SLOT_DURATION to the same as the underlying chain slot duration. Since we are using anvil, this is by default 1s. However, we also change the block interval to 12s to behave closer to ethereum.

Having just a single l1 slot for every l2 slot means that the proposer is rapidly changing as l1 blocks are coming in. Something that WILL NOT work out the box for a real chain, but is accepted as a first step here in our setup to get started.

Since we do not want to break everything just ahead of dev net, we have introduced a flag for turning off the most strict checks and rotation of the sequencers. By setting IS_DEV_NET = true in the constants.nr the rollup will accept blocks from anyone in the validator set (if not empty), without checking if it is specifically their turn. You can more specifically look at this in the Rollup contract.

Since it is now required to provide attestations from the L2 network if not IS_DEV_NET = true the sequencer client will collectAttestations before publishing the block. Currently it is a war crime of a function that is just collecting its own signature and providing that as the attestations. This mean that the current setup ONLY works for validator set size 1. This is to be addressed with the extensions that @Maddiaa0 is making with #7681.

When body and headers arrive around the same time (in same l1 block) the archive seemed to run into issues as it would sometime only have loaded the header and not the body, and then fail as it tries to combine the two into an l2 block.
If @alexghr, @spypsy, @spalladino or @PhilWindle is able to take a look to the changes made to it (mainly in e321449) that would be great.

Notable changes in this PR:

• publishAndProcess
  • Publishing the block body AND processing the pending chain is now done in the same TX to not cause issues with timeliness
• Block time is set to 12 seconds
  • When deploying the L1 contracts, we are setting the block time of the underlying Anvil chain to 12 seconds. (Still in automine).
• Introduces IS_DEV_NET flag in constants.nr
• When IS_DEV_NET = true
  • Skips some of the stricter timeliness requirements since they are not needed for centralised sequencers.
• IS_DEV_NET = false
  • Run with all checks on
  • Will need signatures from the committee (ordered correctly) to propose a block
• Made changes to the archiver as it sometimes broke when block body and header was in the same l1 block.

Future work:

• Collect attestations properly
• E2E should survive running with interval mining and SLOT_DURATION = n * ETHEREUM_SLOT_DURATION for n>1.

---

We will have the test pass with IS_DEV_NET=false and then we will do another run where we set it to true such that we do not break things for people unnecessarily.

---

Issues spawned by this pr:

• refactor: integration_l1_publisher timing issues #7849
• refactor: sequencer communication with L1 #7821
• feat: Support altering slot_duration #7850
• refactor: Add Ownable to registry #7837

[LHerskind]

• feat: constraining slots #7758 👈
• 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]

Benchmark results

Metrics with a significant change:

• proof_construction_time_sha256_100_ms (16): 5,668 (-24%)
• proof_construction_time_sha256_30_ms (16): 1,403 (-25%)
• protocol_circuit_proving_time_in_ms (public-kernel-teardown): 16,402 (-16%)
• l1_rollup_calldata_gas (4): 49,744 (+641%)
• l1_rollup_calldata_gas (8): 92,476 (+1277%)
• l1_rollup_calldata_gas (16): 177,680 (+2555%)
• l1_rollup_calldata_size_in_bytes (4): 4,324 (+484%)
• l1_rollup_calldata_size_in_bytes (8): 7,844 (+960%)
• l1_rollup_calldata_size_in_bytes (16): 14,852 (+1907%)
• l1_rollup_execution_gas (4): 1,292,263 (+111%)
• l1_rollup_execution_gas (8): 2,039,963 (+233%)
• l1_rollup_execution_gas (16): 3,867,206 (+532%)

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,725 (-1%)	1,538 (-2%)	709 (-1%)	749 (-2%)	767 (-1%)
proof_construction_time_sha256_30_ms	11,749 (-4%)	3,139 (-6%)	⚠️ 1,403 (-25%)	1,448 (-13%)	1,460 (-7%)
proof_construction_time_sha256_100_ms	43,849 (-2%)	12,489 (-3%)	⚠️ 5,668 (-24%)	5,565 (-13%)	5,502 (-9%)
proof_construction_time_poseidon_hash_ms	78.0 (-1%)	34.0 (-3%)	34.0 (-3%)	59.0 (-2%)	87.0 (-2%)
proof_construction_time_poseidon_hash_30_ms	1,517 (-1%)	416 (-1%)	201	227 (+1%)	265 (-2%)
proof_construction_time_poseidon_hash_100_ms	5,609 (-2%)	1,516 (-2%)	680 (-2%)	717 (-3%)	747

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 (+484%)	⚠️ 7,844 (+960%)	⚠️ 14,852 (+1907%)
l1_rollup_calldata_gas	⚠️ 49,744 (+641%)	⚠️ 92,476 (+1277%)	⚠️ 177,680 (+2555%)
l1_rollup_execution_gas	⚠️ 1,292,263 (+111%)	⚠️ 2,039,963 (+233%)	⚠️ 3,867,206 (+532%)
l2_block_processing_time_in_ms	253 (-1%)	443 (-1%)	818 (+1%)
l2_block_building_time_in_ms	9,488 (-1%)	18,636 (-2%)	36,910
l2_block_rollup_simulation_time_in_ms	9,488	18,636 (-2%)	36,909
l2_block_public_tx_process_time_in_ms	7,889 (-1%)	16,801 (-1%)	35,012

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	2,905 (+7%)	3,836 (+4%)
node_database_size_in_bytes	12,718,160	16,896,080
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	proof_size_in_bytes	num_public_inputs	size_in_gates
private-kernel-init	100 (-1%)	412 (+5%)	21,846	44,858	N/A	N/A	N/A	N/A
private-kernel-inner	167 (-1%)	725 (+5%)	72,545	45,005	N/A	N/A	N/A	N/A
private-kernel-tail	667	774 (+2%)	52,710	52,256	N/A	N/A	N/A	N/A
base-parity	6.06 (+3%)	596 (+1%)	160	96.0	1,685 (-4%)	13,188	19.0	65,536
root-parity	108 (-1%)	118 (-9%)	69,084	96.0	28,030 (-11%)	13,188	19.0	4,194,304
base-rollup	2,959 (-2%)	5,748 (+4%)	187,824	664	86,886 (-14%)	14,020	45.0	16,777,216
root-rollup	97.2	106 (-14%)	54,525	716	25,318 (-11%)	13,988	44.0	4,194,304
public-kernel-setup	92.1	2,755 (-4%)	104,025	71,222	15,348 (-13%)	129,220	3,645	2,097,152
public-kernel-app-logic	105 (-1%)	4,137 (+1%)	104,025	71,222	8,742 (-15%)	129,220	3,645	1,048,576
public-kernel-tail	570	29,431 (+1%)	409,190	16,414	94,273 (-12%)	34,308	679	16,777,216
private-kernel-reset-tiny	181 (-2%)	876 (+5%)	68,621	44,750	N/A	N/A	N/A	N/A
private-kernel-tail-to-public	2,684 (-3%)	1,576 (+3%)	931,564	1,697	N/A	N/A	N/A	N/A
public-kernel-teardown	86.3 (-1%)	4,195 (+1%)	104,025	71,222	⚠️ 16,402 (-16%)	129,220	3,645	2,097,152
merge-rollup	60.1 (+1%)	N/A	35,742	664	N/A	N/A	N/A	N/A
undefined	N/A	N/A	N/A	N/A	66,498 (-4%)	N/A	N/A	N/A

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
ContractClassRegisterer:register	1,344	11,731	339	N/A	N/A
ContractInstanceDeployer:deploy	1,408	11,731	18.2	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	11,731	472	N/A	N/A
FeeJuice:deploy	1,376	11,731	388 (-1%)	N/A	N/A
SchnorrAccount:constructor	1,312	11,731	176	N/A	N/A
SchnorrAccount:entrypoint	2,304	11,731	546 (+2%)	N/A	N/A
Token:privately_mint_private_note	1,280	11,731	227 (+4%)	N/A	N/A
FPC:fee_entrypoint_public	1,344	11,731	33.6 (+8%)	N/A	N/A
Token:transfer	1,312	11,731	449 (+2%)	N/A	N/A
AuthRegistry:set_authorized (avm)	18,491	N/A	N/A	147,296	2,547 (+2%)
FPC:prepare_fee (avm)	22,958	N/A	N/A	147,360	3,277 (+3%)
Token:transfer_public (avm)	61,614	N/A	N/A	147,360	17,556 (-4%)
AuthRegistry:consume (avm)	41,719	N/A	N/A	147,328	7,319 (-9%)
FPC:pay_refund (avm)	26,227	N/A	N/A	147,328	7,146 (-3%)
Benchmarking:create_note	1,344	11,731	171 (+1%)	N/A	N/A
SchnorrAccount:verify_private_authwit	1,280	11,731	27.4 (-2%)	N/A	N/A
Token:unshield	1,376	11,731	655 (-3%)	N/A	N/A
FPC:fee_entrypoint_private	1,376	11,731	874	N/A	N/A

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
FeeJuice:_increase_public_balance	92.9 (-1%)	8,139
FeeJuice:set_portal	11.4 (+3%)	2,362
Token:constructor	121 (-1%)	31,107
FPC:constructor	93.3 (-1%)	22,380
FeeJuice:mint_public	78.5 (-7%)	6,150
Token:mint_public	92.2 (+9%)	11,720
Token:assert_minter_and_mint	79.9 (-12%)	8,028
AuthRegistry:set_authorized	9.35 (-11%)	4,537
FPC:prepare_fee	290 (-4%)	8,812
Token:transfer_public	28.8 (-21%)	47,374
FPC:pay_refund	66.8 (+9%)	12,114
Benchmarking:increment_balance	1,011 (-1%)	7,450
Token:_increase_public_balance	11.7 (+16%)	8,960
FPC:pay_refund_with_shielded_rebate	138	12,663

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.154 (-12%)

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.12	3.81 (-1%)	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.110	0.108	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	11.5	17.8 (+1%)	30.6 (+1%)	58.7 (-3%)	114 (+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.111	0.104 (+1%)	0.0997 (+1%)	0.101 (-3%)	0.102 (+3%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	14.1 (-2%)	25.6 (-2%)	43.3	82.0 (-2%)	161
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.107 (-1%)	0.103 (-1%)	0.105 (+1%)	0.102 (-1%)	0.101
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	16.2 (-1%)	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	132 (-1%)	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.104	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,756	668,997

Transaction size based on fee payment method

| Metric | |
| - | |

[AztecBot]

Docs Preview

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

[Maddiaa0]

so slot number is not inferred from the mapping key? Does this imply block number !== slot

[LHerskind]

They are not directly linked. Every slot is essentially an option for a block, so you don't really know what slot it belongs to if not explicit. You can say that it will implicitly be part of the archive if you open up the last header, but this was essentially as it was easier to provide the information and more clear what validation we were doing.

[Maddiaa0]

I guess the hacky stuff will be cleaned up when the attestors come in, so looks good to me

[Maddiaa0]

Ill sort this stuff out soon

[Maddiaa0]

seconded

[Maddiaa0]

nice idea

[LHerskind]

Setting the IS_DEV_NET = true to not cause pain and suffering for those guys, but it seems likely that we will end up with some pain later because of it 🫡