Conversation
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
## 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
Fix A-931 A-946
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.
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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