Skip to content

feat: merge-train/spartan#22814

Merged
alexghr merged 28 commits intonextfrom
merge-train/spartan
Apr 29, 2026
Merged

feat: merge-train/spartan#22814
alexghr merged 28 commits intonextfrom
merge-train/spartan

Conversation

@AztecBot
Copy link
Copy Markdown
Collaborator

@AztecBot AztecBot commented Apr 28, 2026

BEGIN_COMMIT_OVERRIDE
chore: pass through p2p tx pool size (#22804)
feat: track sequencer state time (#22800)
feat(rpc)!: updated rpc api for blocks and checkpoints (#22781)
feat(pipelining): complete attestations by build-slot end (#22735)
feat(archiver): handle multiple proposed checkpoints (#22784)
feat: scrape bench-10tps (#22803)
feat!: make proposals EIP-712 (#22531)
chore: remove default env (#22837)
chore: remove default env (#22839)
chore: grafana provisioning (#22843)
feat: add extra getters (#22563)
fix: use number config helper for NaN protection (#22598)
test(e2e): relax blocks per checkpoint in high tps e2e (#22846)
test(e2e): equivocation recovery under proposer pipelining (#22831)
feat: scrape metrics data (#22840)
END_COMMIT_OVERRIDE

alexghr and others added 7 commits April 27, 2026 12:48
This env var wasn't being passed through to the pods
Implements the new JSON RPC API proposal for blocks and checkpoints.
Next steps:
- Remove the methods flagged as deprecated
- Align the internal archiver API (and potentially storage) with this
new external node API so we can get rid of the block response adapters
- Review the chain tips structure (in particular the
`proposedCheckpoint`)
- Review the APIs that return checkpoints on when we return proposed vs
mined checkpoints

Fixes A-974
spalladino and others added 5 commits April 28, 2026 12:29
## Motivation

Under today's pipelining schedule, attestations for slot N's checkpoint
trail into slot N+1 by `blockDuration + p2pPropagationTime` (~8s with
defaults), which delays the L1 `propose` tx and pushes it toward the 3rd
L1 block of the target slot. Shifting the broadcast ~8s earlier lets
attestations finish by the build-slot boundary so the proposer can
submit to L1 immediately at the target-slot start.

## Approach

Updates the pipelined timing model to reserve assembly, round-trip p2p,
and last-block re-execution at the *end* of the build slot (rather than
leaking into the target slot). Proposal broadcast now fires at ~T =
slotDuration − timeReservedAtEnd inside the build slot, so attestations
arrive before the boundary. Receiver acceptance windows are tightened
accordingly: `proposalWindowIntoTargetSlot` drops from
`p2pPropagationTime` to 0 (only clock-disparity grace remains) and
`attestationWindowIntoTargetSlot` shrinks from `slotDuration −
l1PublishingTime` (60s at defaults) to `2·p2pPropagationTime` (4s).

No new p2p validation path is needed: the main `messageSlot ===
targetSlot || messageSlot === nextSlot` check already covers the steady
state under pipelining.

## Changes

- **stdlib (timetable)**:
`PipelinedCheckpointTimingModel.timeReservedAtEnd` is now
`checkpointAssembleTime + 2·p2pPropagationTime + blockDuration`;
`pipeliningAttestationGracePeriod` drops to 0 under pipelining.
`proposalWindowIntoTargetSlot` drops to 0 and
`attestationWindowIntoTargetSlot` shrinks to `2·p2pPropagationTime`.
- **p2p (msg_validators)**: Tightens `PipeliningWindow.acceptsProposal`
/ `acceptsAttestation` via the new timing-model values;
`isWithinPipeliningWindow` JSDoc is refreshed to describe the
straggler-acceptance role explicitly.
- **sequencer-client (README)**: Rewrites the pipelining section to
describe the new schedule (broadcast inside build slot, attestations in
hand by slot boundary, L1 submission at target-slot boundary) and
refreshes the worked example.
- **tests (stdlib, p2p, sequencer-client)**: Updates pipelined timing /
window-size assertions and tightens acceptance tests for the shorter
straggler windows.

## Rollout notes

The tightened straggler windows mean a receiver running this change will
reject stale-schedule proposals that arrive more than 500ms into the
target slot and stale-schedule attestations that arrive more than 4.5s
into the target slot. Expect to roll this out across validators together
(the merge-train/spartan flow already batches validator upgrades) rather
than mixing old and new schedules on a live network.

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Updates the archiver data store model so that we can account for more
than a single proposed checkpoint. Under pipelining, it's possible we
receive the proposal for the next checkpoint before we've managed to
sync the previous one from L1, thus having two checkpoints unmined.

Also fixes `addProposedCheckpoint` in the archiver so that it goes
through the queue, instead of potentially injecting it in the middle of
an L1 sync.

Next steps is to review the archiver and node APIs that return
checkpoints, and unify whether we return proposed checkpoints along
mined checkpoints or not. Related to #22781.

Fixes A-910
This changes proposal-path validator signatures from `eth_sign` /
`personal_sign` style payload signing to EIP-712 typed-data signing.
Proposal and attestation signatures are now bound to both the L1
`chainId` and the rollup contract address, which closes cross-chain and
cross-rollup replay for block proposals, checkpoint proposals,
checkpoint attestations, and the proposer signature over packed
attestations/signers.

On the Solidity side, the rollup path now computes EIP-712 digests
through `CoordinationSignatureLib.sol`, reusing the existing `Aztec
Rollup` domain name and version `1`, and threads the verifying contract
explicitly where needed. On the TypeScript side, proposal-path signing
and recovery now require a `{ chainId, rollupAddress }` signature
context, validator duties sign typed data instead of raw messages, and
the shared helper surface was renamed to `CoordinationSignature*` to
match Solidity.

Tests were updated to check digest parity between TS and Solidity,
sender recovery under the correct domain, failure under the wrong
`chainId` or rollup address, and the affected contract flows that verify
or invalidate checkpoint-related signatures.

Historically, it was possible to reason about replay from archives and
chain history, but it was not always stupid-simple. With the EIP-712
domain binding, the replay boundary is explicit in the signature itself,
so checking whether a signature targets the wrong chain or wrong rollup
becomes straightforward and only depends on current L1 state.
Copy link
Copy Markdown
Collaborator

@ludamad ludamad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Auto-approved

@AztecBot AztecBot added this pull request to the merge queue Apr 28, 2026
@AztecBot
Copy link
Copy Markdown
Collaborator Author

🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass.

@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 28, 2026
@alexghr alexghr requested a review from charlielye as a code owner April 29, 2026 10:00
alexghr and others added 8 commits April 29, 2026 12:13
Adds external getters for the last three `RollupConfig` fields that were
previously unreachable from outside the contract:
- `getVkTreeRoot()`
- `getProtocolContractsHash()`
- `getEpochProofVerifier()`
These were omitted originally because the rollup was tight on bytecode.
Recent size reductions (TMNT-509, TMNT-513, TMNT-514) freed enough room
to add them directly in `Rollup.sol` without needing ExtLib delegation.
Inconsistent CI times means that sometimes we don't get to build all
blocks within a checkpoint, so we relax the assertion to _at least_ one
checkpoint having all blocks.

See also
https://gist.github.com/AztecBot/c18984c05764251bc6136af08831517a
Adds a new e2e test that checks that the network can recover from a
checkpoint posted to L1 that differs from the one broadcasted via p2p.

Fixes A-870
@alexghr alexghr enabled auto-merge April 29, 2026 21:46
@alexghr alexghr added this pull request to the merge queue Apr 29, 2026
Merged via the queue into next with commit 22ec297 Apr 29, 2026
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants