feat: introduce validator client

[Maddiaa0]

Overview

This PR:

• Produces block Proposals
• Broadcasts them to other peers over p2p
• collects attestations from other validator clients (no checks are performed)
• Submits them alongside a block
• Where they are verified on the smart contract (existing work)

fixes:

• feat(vc): validator client interfaces #7680
• chore(vc): add validator client keys to the node configuration #7684
• feat(vc): track sign and forwarding attestations #7683

Right now the nodes only attest over the archive, not the entire transaction contents. It is likely that this will change to the block header.

Issues spawned from this PR

• Each node does not have a concept of who is the leader
• Each node should cache a view of the epoch locally to prevent round trips to the node to retrieve this information
• There is a callback into the validator in the p2p client to deal with received block proposals
• Add methods for nodes to request information they do not have in the p2p layer
• Out of process validator
• We are using ETH signed messages for validator attestations, which makes no sense, we should use a different signing library
• The smart contract does not remove the proposer from the expected committee signatures
• Attestation pool pruining
• Block proposals are not over transactions
• Add timeouts to attestation getting

Icks:

• The current design places the sequencer at the middle of everything, and it has all of the responsibilities. the validator is a little bit of a bolt on

[Maddiaa0]

moved into a shared file

[AztecBot]

Benchmark results

Metrics with a significant change:

• avm_simulation_time_ms (FeeJuice:mint_public): 38.3 (-33%)

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,768	1,559	701 (-1%)	758	761 (-1%)
proof_construction_time_sha256_30_ms	11,861	3,179 (-1%)	1,402 (-1%)	1,440	1,459 (-1%)
proof_construction_time_sha256_100_ms	45,456	12,009 (-2%)	5,422 (-1%)	5,714 (+5%)	5,393
proof_construction_time_poseidon_hash_ms	79.0 (+1%)	34.0	34.0	58.0 (-3%)	87.0 (-1%)
proof_construction_time_poseidon_hash_30_ms	1,534	423	202	227 (-1%)	266 (-1%)
proof_construction_time_poseidon_hash_100_ms	5,647	1,546 (+2%)	693 (+2%)	744 (-2%)	750 (+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	4,324	7,844	14,852
l1_rollup_calldata_gas	49,672	92,360	177,584
l1_rollup_execution_gas	1,383,166	2,130,822	3,958,085
l2_block_processing_time_in_ms	255 (-2%)	433 (-1%)	798 (-2%)
l2_block_building_time_in_ms	9,260	18,130	36,235 (+1%)
l2_block_rollup_simulation_time_in_ms	9,259	18,129	36,235 (+1%)
l2_block_public_tx_process_time_in_ms	7,814	16,579	34,648 (+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	2,820 (-2%)	3,738 (-1%)
node_database_size_in_bytes	12,648,528	16,711,760
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
private-kernel-init	96.0	400 (-4%)	21,673	44,858	N/A
private-kernel-inner	162 (-1%)	713 (-1%)	72,309	45,005	N/A
private-kernel-reset-tiny	499 (-3%)	898 (-1%)	65,974	44,844	N/A
private-kernel-tail	206 (-1%)	184 (+10%)	50,728	52,256	N/A
base-parity	5.57 (-1%)	N/A	160	96.0	N/A
root-parity	33.3	N/A	69,084	96.0	N/A
base-rollup	2,854 (-1%)	N/A	187,817	664	N/A
root-rollup	38.8	N/A	54,525	716	N/A
public-kernel-setup	98.2 (-3%)	N/A	103,760	71,222	N/A
public-kernel-app-logic	103 (-1%)	N/A	103,599	71,222	N/A
public-kernel-tail	578	N/A	409,190	16,414	N/A
private-kernel-reset-small	489 (-3%)	N/A	66,085	45,629	N/A
private-kernel-tail-to-public	1,073 (+5%)	661	492,960	1,697	N/A
public-kernel-teardown	92.0 (-3%)	N/A	104,005	71,222	N/A
merge-rollup	19.1	N/A	35,742	664	N/A
undefined	N/A	N/A	N/A	N/A	66,128

Stats on running time collected for app circuits

Function	input_size_in_bytes	output_size_in_bytes	witness_generation_time_in_ms
ContractClassRegisterer:register	1,344	11,731	344 (-1%)
ContractInstanceDeployer:deploy	1,408	11,731	18.3 (-1%)
MultiCallEntrypoint:entrypoint	1,920	11,731	425 (-1%)
FeeJuice:deploy	1,376	11,731	388
SchnorrAccount:constructor	1,312	11,731	105 (-2%)
SchnorrAccount:entrypoint	2,304	11,731	434
Token:privately_mint_private_note	1,280	11,731	145 (+1%)
FPC:fee_entrypoint_public	1,344	11,731	29.1 (+6%)
Token:transfer	1,312	11,731	276 (-5%)
Benchmarking:create_note	1,344	11,731	105 (+3%)
SchnorrAccount:verify_private_authwit	1,280	11,731	27.8
Token:unshield	1,376	11,731	561
FPC:fee_entrypoint_private	1,376	11,731	752 (-2%)

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
FeeJuice:_increase_public_balance	53.8	8,139
FeeJuice:set_portal	11.0 (-13%)	2,362
Token:constructor	81.5 (-3%)	31,107
FPC:constructor	53.8	22,380
FeeJuice:mint_public	⚠️ 38.3 (-33%)	6,150
Token:mint_public	44.5 (+2%)	11,720
Token:assert_minter_and_mint	71.0 (+4%)	8,028
AuthRegistry:set_authorized	36.9 (-20%)	4,537
FPC:prepare_fee	235 (-2%)	8,812
Token:transfer_public	21.4 (-27%)	47,374
FPC:pay_refund	53.8 (-7%)	12,114
Benchmarking:increment_balance	968	7,450
Token:_increase_public_balance	38.8	8,960
FPC:pay_refund_with_shielded_rebate	64.8 (-3%)	12,663

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.159

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.15 (-1%)	3.88 (-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.112	0.110	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.7 (-4%)	58.9	112 (-1%)
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.103 (-1%)	0.0996 (-5%)	0.101	0.101
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	14.3 (-3%)	25.7 (-1%)	43.5 (-3%)	82.5 (+1%)	163
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.108 (-3%)	0.104 (+1%)	0.105 (-2%)	0.102 (+1%)	0.104
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	16.3 (-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.105 (-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	64,779	668,997

Transaction size based on fee payment method

| Metric | |
| - | |

[AztecBot]

Docs Preview

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

[LHerskind]

Potentially interesting for you to check #7989, guess it depends on who merges first 😎

[LHerskind]

For this, I think we could be a bit smarter just to avoid the issue.

In the getProposerAt we end up drawing a committee if there is not one already. Think we could likely just make a version of that which just don't draw from the set but just returns it 🤷 Seems slightly better for us to not have the option where someone ends up calling it directly. Something I have done in the past have been having an extension to a contract with extra view functions that is not necessarily used within itself, essentially separating the external views 🤷.

We could potentially just alter the `getEpochCommittee(uint256 _epoch)

function getCommitteeAt(uint256 _ts) public view override(ILeonidas) returns (address) {
    uint256 epochNumber = getEpochAt(_ts);
    uint256 slot = getSlotAt(_ts);
    if (epochNumber == 0) {
      return new address[1]();
    }

    Epoch storage epoch = epochs[epochNumber];

    if (epoch.sampleSeed != 0) {
      uint256 committeeSize = epoch.committee.length;
      if (committeeSize == 0) {
        return new address[1]();
      }
      return epoch.committee;
    }

    // Allow anyone if there is no validator set
    if (validatorSet.length() == 0) {
      return new address[1]();
    }

    // Emulate a sampling of the validators
    uint256 sampleSeed = _getSampleSeed(epochNumber);
    return _sampleValidators(epochNumber, sampleSeed);
  }

[LHerskind]

See below.

[LHerskind]

Temp?

Teasing aside. Yes think we will move it to the header hash as discussed in #7727 (comment)

[LHerskind]

🫡

[LHerskind]

Related to earlier.

[LHerskind]

I don't particularly like that we can add a bunch of attestations to the attestation pool even if they are attesting to different data 🤷. It seems like it would be useful to only be able to add things that match the digest already in there.

[Maddiaa0]

#8028

[LHerskind]

As mentioned in the test. I think it is slightly weird here that we don't try matching the attestation with what is signed over beyond just taking the slot number as gospel. Haven't seen where it is used yet, but seems like it would be good for us to ensure that we don't end up with a bunch of useless attestations in here.

[Maddiaa0]

#8028

[LHerskind]

Related to earlier, not sure where the best place to check for it would be, but think we gotta check somewhere to make sure we don't end up thinking that we have enough attestations, but it is because we just stored a lot of garbage attestations.

[LHerskind]

Issue?

[just-mitch]

Just a fun tip: you can
signers = Array.from({ length: NUMBER_OF_SIGNERS_PER_TEST }, generateAccount);

[just-mitch]

🔥

[just-mitch]

Empty file

[Maddiaa0]

good spot

[just-mitch]

Can you explain the magic number?

[Maddiaa0]

Its a multiaddr prefix https://multiformats.io/multiaddr/

[just-mitch]

I agree with the abstraction concerns around the callback interface (and the p2p client generally), and the structural concerns w.r.t. the validator client being a bolt-on to the sequencer client (what even is a sequencer anymore?).

But I think this is good for now.