feat: Handle multiple blocks per slot in validators (#19240)

## Summary

Implements Multiple Blocks Per Slot (MBPS) consensus model where
validators attest to checkpoints (aggregations of blocks) instead of
individual blocks. This is a foundational change for improving L2
throughput by allowing multiple blocks to be built within a single L1
slot.

## Key Changes

### New Consensus Types
- **CheckpointAttestation**: Validators sign checkpoint payloads (header
+ archive) instead of individual blocks
- **CheckpointProposal**: Proposers broadcast checkpoint proposals
containing the last block and aggregated checkpoint header
- **BlockAttestation deleted**: Fully replaced by CheckpointAttestation
- no traces remain in active code paths

### Validator Behavior
- Validators now call `attestToCheckpointProposal()` instead of
`attestToProposal()`
- Checkpoint number is derived from parent block's checkpoint info, not
computed from block number
- Block comparison during re-execution validates full struct (header +
archive), not just archive root
- Validators use `FullNodeCheckpointsBuilder` instead of block builder,
enabling multi-block checkpoint re-execution and validation

### P2P Layer
- New gossip topics: `checkpoint_proposal`, `checkpoint_attestation`
- Removed `block_attestation` topic handling
- Attestation pool interface simplified to only handle checkpoint
attestations
- Proposal validators consolidated into shared `proposal_validator/`
directory

### Packages Modified
- **stdlib**: New `CheckpointAttestation`, `CheckpointProposal` classes;
deleted `BlockAttestation`
- **p2p**: Updated pool, validators, libp2p service, encoding
- **validator-client**: Updated attestation creation and block handling
- **sequencer-client**: Fixed checkpoint number computation
- **end-to-end**: Added MBPS-specific e2e tests

## New E2E Tests
**These are pending review**
- `epochs_multiple_blocks_per_slot.test.ts`: Single sequencer with mock
gossip
- `mbps_checkpoint_consensus.test.ts`: Multi-validator with real P2P
networking

## Commits

This PR is split into multiple commits for easier review. Note that
intermediate commits may not build.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: PhilWindle

yarn-project/.claude/rules/typescript-style.md

@@ -174,6 +174,30 @@ export class CheckpointProposal { ... }
 - Prefer `undefined` over `null`
 - Use `compactArray()` from foundation to filter undefined values
 
+## Resource Management
+
+Prefer `using`/`await using` over `try`/`finally` for cleanup of disposable resources:
+
+```typescript
+// Good: using statement ensures cleanup even on exceptions
+using fork = await this.worldState.fork(blockNumber);
+const result = await processWithFork(fork);
+return result;
+
+// Bad: try/finally is more verbose and error-prone
+const fork = await this.worldState.fork(blockNumber);
+try {
+  const result = await processWithFork(fork);
+  return result;
+} finally {
+  await fork.close();
+}
+```
+
+- Use `using` for `Disposable` resources (implements `[Symbol.dispose](): void`)
+- Use `await using` for `AsyncDisposable` resources (implements `[Symbol.asyncDispose](): Promise<void>`)
+- When the resource is obtained asynchronously but disposed synchronously, use `using x = await getResource()`
+
 ## General Style
 
 - Prefer `const` over `let`

yarn-project/.claude/settings.json

@@ -3,7 +3,7 @@
     "allow": [
       "Bash(yarn:*)",
       "Bash(forge:*)",
-      "Bash(env LOG_LEVEL:* yarn:*)",
+      "Bash(env LOG_LEVEL=* yarn *)",
       "Bash(./bootstrap.sh:*)",
       "Bash(git status:*)",
       "Bash(git diff:*)",

yarn-project/CLAUDE.md

@@ -195,6 +195,19 @@ Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/):
 - **Backport**: Fix in release branch -> forward-port to `next`
 - **Forward-port**: Fix in `next` -> backport if needed
 
+### Determining the Base Branch
+
+**Never assume the base branch is `master`**. Most branches are based on `next`, not `master`. When you need to compare commits or understand changes on a branch:
+
+```bash
+# If there's an open PR, check its base branch
+gh pr view --json baseRefName -q '.baseRefName'
+
+# Compare against the correct base
+git log origin/<base-branch>..HEAD   # commits on this branch
+git diff origin/<base-branch>...HEAD  # changes on this branch
+```
+
 ### Port Commits
 
 When porting PRs between branches, include reference to original PR(s) in the PR body. Use the exact same commit message with the original PR number.

yarn-project/archiver/README.md

@@ -13,25 +13,25 @@ The interfaces defining how the data can be consumed from the archiver are `L2Bl
 
 The archiver sync process periodically checks its current state against the Rollup contract on L1 and updates its local state.
 
-### Handling invalid blocks
+### Handling invalid checkpoints
 
-After the implementation of [delayed attestation verification](https://github.com/AztecProtocol/engineering-designs/pull/69), the Rollup contract on L1 no longer validates committee attestations. Instead, these are posted in calldata, and L2 nodes are expected to verify them as they download blocks. The archiver handles this validation during its sync process.
+After the implementation of [delayed attestation verification](https://github.com/AztecProtocol/engineering-designs/pull/69), the Rollup contract on L1 no longer validates committee attestations. Instead, these are posted in calldata, and L2 nodes are expected to verify them as they download checkpoints. The archiver handles this validation during its sync process.
 
-Whenever the archiver detects a block with invalid attestations, it skips it. These blocks are not meant to be part of the chain, so the archiver ignores them and continues processing the next blocks. It is expected that an honest proposer will eventually invalidate these blocks, removing them from the chain on L1, and then resume the sequence of valid blocks.
+Whenever the archiver detects a checkpoint with invalid attestations, it skips it. These checkpoints are not meant to be part of the chain, so the archiver ignores them and continues processing the next checkpoints. It is expected that an honest proposer will eventually invalidate these checkpoints, removing them from the chain on L1, and then resume the sequence of valid checkpoints.
 
 > [!WARNING]
-> If the committee for the epoch is also malicious and attests to a descendant of an invalid block, nodes should also ignore these descendants, unless they become proven. This is currently not implemented. Nodes assume that the majority of the committee is honest.
+> If the committee for the epoch is also malicious and attests to a descendant of an invalid checkpoint, nodes should also ignore these descendants, unless they become proven. This is currently not implemented. Nodes assume that the majority of the committee is honest.
 
-When the current node is elected as proposer, the `sequencer` needs to know whether there is an invalid block in L1 that needs to be purged before posting their own block. To support this, the archiver exposes a `pendingChainValidationStatus`, which is the state of the tip of the pending chain. This status can be valid in the happy path, or invalid if the tip of the pending chain has invalid attestations. If invalid, this status also contains all the data needed for purging the block from L1 via an `invalidate` call to the Rollup contract. Note that, if the head of the chain has more than one invalid consecutive block, this status will reference the earliest one that needs to be purged, since a call to purge an invalid block will automatically purge all descendants. Refer to the [InvalidateLib.sol](`l1-contracts/src/core/libraries/rollup/InvalidateLib.sol`) for more info.
+When the current node is elected as proposer, the `sequencer` needs to know whether there is an invalid checkpoint in L1 that needs to be purged before posting their own checkpoint. To support this, the archiver exposes a `pendingChainValidationStatus`, which is the state of the tip of the pending chain. This status can be valid in the happy path, or invalid if the tip of the pending chain has invalid attestations. If invalid, this status also contains all the data needed for purging the checkpoint from L1 via an `invalidate` call to the Rollup contract. Note that, if the head of the chain has more than one invalid consecutive checkpoint, this status will reference the earliest one that needs to be purged, since a call to purge an invalid checkpoint will automatically purge all descendants. Refer to the [InvalidateLib.sol](`l1-contracts/src/core/libraries/rollup/InvalidateLib.sol`) for more info.
 
 > [!TIP]
-> The archiver can be configured to `skipValidateBlockAttestations`, which will make it skip this validation. This cannot be set via environment variables, only via a call to `nodeAdmin_setConfig`. This setting is only meant for testing purposes.
-
-As an example, let's say the chain has been progressing normally up until block 10, and then:
-1. Block 11 is posted with invalid attestations. The archiver will report 10 as the latest block, but the `pendingChainValidationStatus` will point to block 11.
-2. Block 11 is purged, but another block 11 with invalid attestations is posted in its place. The archiver will still report 10 as latest, and the `pendingChainValidationStatus` will point to the new block 11 that needs to be purged.
-3. Block 12 with invalid attestations is posted. No changes in the archiver.
-4. Block 13 is posted with valid attestations, due to a malicious committee. The archiver will try to sync it and fail, since 13 does not follow 10. This scenario is not gracefully handled yet.
-5. Blocks 11 to 13 are purged. The archiver status will not yet be changed: 10 will still be the latest block, and the `pendingChainValidationStatus` will point to 11. This is because the archiver does **not** follow `BlockInvalidated` events.
-6. Block 11 with valid attestations is posted. The archiver pending chain now reports 11 as latest, and its status is valid.
+> The archiver can be configured to `skipValidateCheckpointAttestations`, which will make it skip this validation. This cannot be set via environment variables, only via a call to `nodeAdmin_setConfig`. This setting is only meant for testing purposes.
+
+As an example, let's say the chain has been progressing normally up until checkpoint 10, and then:
+1. Checkpoint 11 is posted with invalid attestations. The archiver will report 10 as the latest checkpoint, but the `pendingChainValidationStatus` will point to checkpoint 11.
+2. Checkpoint 11 is purged, but another checkpoint 11 with invalid attestations is posted in its place. The archiver will still report 10 as latest, and the `pendingChainValidationStatus` will point to the new checkpoint 11 that needs to be purged.
+3. Checkpoint 12 with invalid attestations is posted. No changes in the archiver.
+4. Checkpoint 13 is posted with valid attestations, due to a malicious committee. The archiver will try to sync it and fail, since 13 does not follow 10. This scenario is not gracefully handled yet.
+5. Checkpoints 11 to 13 are purged. The archiver status will not yet be changed: 10 will still be the latest checkpoint, and the `pendingChainValidationStatus` will point to 11. This is because the archiver does **not** follow `CheckpointInvalidated` events.
+6. Checkpoint 11 with valid attestations is posted. The archiver pending chain now reports 11 as latest, and its status is valid.
 

yarn-project/archiver/src/archiver/archiver.test.ts

@@ -30,7 +30,7 @@ import type { L1RollupConstants } from '@aztec/stdlib/epoch-helpers';
 import { InboxLeaf, computeInHashFromL1ToL2Messages } from '@aztec/stdlib/messaging';
 import {
   makeAndSignCommitteeAttestationsAndSigners,
-  makeAttestationFromCheckpoint,
+  makeCheckpointAttestationFromCheckpoint,
   makeStateReference,
   mockCheckpointAndMessages,
 } from '@aztec/stdlib/testing';
@@ -509,9 +509,9 @@ describe('Archiver', () => {
     const committee = signers.map(signer => signer.address);
     epochCache.getCommitteeForEpoch.mockResolvedValue({ committee } as EpochCommitteeInfo);
 
-    // Setup spy to listen for InvalidBlockDetected events
-    const invalidBlockDetectedSpy = jest.fn();
-    archiver.on(L2BlockSourceEvents.InvalidAttestationsBlockDetected, invalidBlockDetectedSpy);
+    // Setup spy to listen for InvalidCheckpointDetected events
+    const invalidCheckpointDetectedSpy = jest.fn();
+    archiver.on(L2BlockSourceEvents.InvalidAttestationsCheckpointDetected, invalidCheckpointDetectedSpy);
 
     // Add messages for all good checkpoints
     messagesPerCheckpoint.map((messages, i) =>
@@ -584,15 +584,15 @@ describe('Archiver', () => {
       }),
     );
 
-    // Check that InvalidBlockDetected event was emitted for the bad block
-    expect(invalidBlockDetectedSpy).toHaveBeenCalledWith(
+    // Check that InvalidCheckpointDetected event was emitted for the bad checkpoint
+    expect(invalidCheckpointDetectedSpy).toHaveBeenCalledWith(
       expect.objectContaining({
-        type: L2BlockSourceEvents.InvalidAttestationsBlockDetected,
+        type: L2BlockSourceEvents.InvalidAttestationsCheckpointDetected,
         validationResult: expect.objectContaining({
           valid: false,
           reason: 'invalid-attestation',
           invalidIndex: 0,
-          block: expect.objectContaining({ blockNumber: 2 }),
+          checkpoint: expect.objectContaining({ checkpointNumber: 2 }),
         }),
       }),
     );
@@ -615,8 +615,8 @@ describe('Archiver', () => {
     expect(await archiver.getCheckpointNumber()).toEqual(CheckpointNumber(1));
     let validationStatus = await archiver.getPendingChainValidationStatus();
     assert(!validationStatus.valid);
-    expect(validationStatus.block.blockNumber).toEqual(2);
-    expect(validationStatus.block.archive.toString()).toEqual(badCheckpoints[1].archive.root.toString());
+    expect(validationStatus.checkpoint.checkpointNumber).toEqual(2);
+    expect(validationStatus.checkpoint.archive.toString()).toEqual(badCheckpoints[1].archive.root.toString());
 
     // Now another loop, where we propose a checkpoint 3 with bad attestations
     logger.warn(`Adding new checkpoint 3 with bad attestations`);
@@ -637,24 +637,24 @@ describe('Archiver', () => {
     expect(await archiver.getCheckpointNumber()).toEqual(CheckpointNumber(1));
     validationStatus = await archiver.getPendingChainValidationStatus();
     assert(!validationStatus.valid);
-    expect(validationStatus.block.blockNumber).toEqual(2);
-    expect(validationStatus.block.archive.toString()).toEqual(badCheckpoints[1].archive.root.toString());
+    expect(validationStatus.checkpoint.checkpointNumber).toEqual(2);
+    expect(validationStatus.checkpoint.archive.toString()).toEqual(badCheckpoints[1].archive.root.toString());
 
-    // Check that InvalidBlockDetected event was also emitted for bad block 3
-    expect(invalidBlockDetectedSpy).toHaveBeenCalledWith(
+    // Check that InvalidCheckpointDetected event was also emitted for bad checkpoint 3
+    expect(invalidCheckpointDetectedSpy).toHaveBeenCalledWith(
       expect.objectContaining({
-        type: L2BlockSourceEvents.InvalidAttestationsBlockDetected,
+        type: L2BlockSourceEvents.InvalidAttestationsCheckpointDetected,
         validationResult: expect.objectContaining({
           valid: false,
           reason: 'invalid-attestation',
           invalidIndex: 0,
-          block: expect.objectContaining({ blockNumber: 3 }),
+          checkpoint: expect.objectContaining({ checkpointNumber: 3 }),
         }),
       }),
     );
 
     // Should have been called three times total: bad checkpoint 2, bad checkpoint 2b, and bad checkpoint 3
-    expect(invalidBlockDetectedSpy).toHaveBeenCalledTimes(3);
+    expect(invalidCheckpointDetectedSpy).toHaveBeenCalledTimes(3);
 
     // Now we go for another loop, where proper checkpoints 2 and 3 are proposed with correct attestations
     // IRL there would be an "Invalidated" event, but we are not currently relying on it
@@ -2441,7 +2441,7 @@ describe('Archiver', () => {
    */
   const makeRollupTx = (checkpoint: Checkpoint, signers: Secp256k1Signer[] = []) => {
     const attestations = signers
-      .map(signer => makeAttestationFromCheckpoint(checkpoint, signer))
+      .map(signer => makeCheckpointAttestationFromCheckpoint(checkpoint, signer))
       .map(attestation => CommitteeAttestation.fromSignature(attestation.signature))
       .map(committeeAttestation => committeeAttestation.toViem());
     const header = checkpoint.header.toViem();