@aztec/stdlib 5.0.0-private.20260319 → 5.0.0-rc.1

package/src/timetable/README.md

@@ -0,0 +1,609 @@
+# Block Building Timetable Spec
+
+This document specifies the timing model for pipelined block building, checkpoint validation, attestation collection, and L1 publishing.
+
+## Goals
+
+The timetable has these goals:
+
+- schedule block sub-slots so the proposer produces a checkpoint at a predictable cadence;
+- enforce consensus-critical deadlines so validators and the next proposer agree on the proposed chain, by agreeing on when a proposal is too late to build on;
+- maximize the time available for the L1 publish transaction by making the payload ready before the ideal L1 send time, which is one Ethereum slot before the target L2 slot;
+- accept late checkpoint proposals until the next-proposer handoff deadline, and late attestations until the latest useful L1 publish deadline.
+
+Pipelining is the only production mode. For target slot `target_slot`, the proposer builds during the preceding `build_slot` and the L1 transaction is meant to land inside `target_slot`.
+
+This model does not describe deterministic automine or other synchronous local-mining modes. Those modes may publish inside the same slot and do not use the pipelined build-slot/target-slot timetable.
+
+## Example
+
+This example uses the production-like values proposed below: `aztec_slot_duration = 72s`,
+`ethereum_slot_duration = 12s`, `block_duration = 6s`, `p2p_propagation_time = 2s`,
+`checkpoint_proposal_prepare_time = 1s`, and `checkpoint_proposal_init_time = 1s`.
+
+All times are offsets from `build_frame_start`. Rows are ordered by the ideal path; deadline-path values show late acceptance cutoffs for the same activity.
+
+| Step | Ideal path | Deadline path |
+| --- | ---: | ---: |
+| Build frame opens | +0s (`build_frame_start`) | +0s (`build_frame_start`) |
+| First sub-slot opens | +1s (`first_subslot_start`) | +1s (`first_subslot_start`) |
+| Block 1 build deadline | +7s (`block_build_deadline(0)`) | +7s (`block_build_deadline(0)`) |
+| Build slot starts | +12s (`build_slot_start`) | +12s (`build_slot_start`) |
+| Latest useful block-building start | +59s (`start_deadline`) | +59s (`start_deadline`) |
+| Last block build time | +61s (`last_block_build_time`) | +61s (`last_block_build_time`) |
+| Checkpoint proposal sent | +62s (`checkpoint_proposal_send_time`) | +62s (`checkpoint_proposal_send_time`) |
+| Checkpoint proposal received | +64s (`checkpoint_proposal_receive_ideal_time`) | +66s (`checkpoint_proposal_receive_deadline`) |
+| Proposal validation complete and attestation sent | +70s (`proposal_validation_ideal_time`) | +132s (`attestation_deadline`) |
+| Next-proposer handoff complete | +70s (`next_proposer_handoff_ideal_time`) | +72s (`next_proposer_handoff_deadline`) |
+| Attestation received / deadline | +72s (`attestation_receive_ideal_time`) | +132s (`attestation_deadline`) |
+| Next proposer build frame opens | +72s (`next_proposer_build_frame_start`) | +72s (`next_proposer_build_frame_start`) |
+| L1 publish tx sent / latest useful send | +72s (`l1_publish_ideal_time`) | +132s (`attestation_deadline`) |
+
+The ideal path is the proposer scheduling target for maximizing L1 publishing time. The deadline path is the latest consensus-safe path: validators and the next proposer use `checkpoint_proposal_receive_deadline`, which depends only on the target slot timing and `block_duration`.
+
+### Example timeline diagram
+
+The diagram highlights the most relevant steps from the table above, as offsets from `build_frame_start` (`target_slot_start - aztec_slot_duration - ethereum_slot_duration`). Blue marks build/structural deadlines, green marks the ideal path, and red marks the late-acceptance deadlines. Dashed lines are slot boundaries.
+
+_Mermaid version (evenly spaced):_
+
+```mermaid
+timeline
+    title Example timetable (offsets from build_frame_start)
+    section Build frame
+        +0s : Build frame opens
+        +61s : Last block build time
+    section Dead zone / handoff
+        +64s : Checkpoint proposal received (ideal)
+        +66s : Checkpoint proposal received (deadline)
+        +72s : Attestations received (ideal) : Next proposer frame opens : L1 publish tx sent (ideal)
+    section Target L2 slot
+        +132s : Attestation deadline : L1 publish latest useful send
+```
+
+_SVG version (proportional):_
+
+![Example timetable (proportional SVG)](./timetable-example.svg)
+
+## Inputs
+
+All timing inputs are expressed in seconds unless otherwise stated. Inputs are grouped by how they are controlled.
+
+### Protocol Constants
+
+These values come from the rollup protocol or network definition. Nodes should not tune them locally.
+
+| Input | Meaning |
+| --- | --- |
+| `genesis_time` | L1 timestamp for L2 slot zero. |
+| `aztec_slot_duration` | Duration of one L2 slot. |
+| `ethereum_slot_duration` | Duration of one Ethereum slot. |
+| `block_duration` | Normal sub-slot duration allocated to building one block and to validator re-execution. |
+
+`block_duration` should be treated as a network-wide timing constant. Validators use it as the expected re-execution
+budget, so proposer and validator nodes must agree on it.
+
+### Build Configuration
+
+These values are operational timing budgets. They may differ between production and local test profiles, but nodes in the
+same network should use the same values for coordinated proposer and validator behavior.
+
+| Input | Meaning |
+| --- | --- |
+| `min_block_duration` | Minimum block-building time that is still worth allocating if the proposer starts late. |
+| `p2p_propagation_time` | One-way propagation budget for proposals and attestations. |
+| `checkpoint_proposal_prepare_time` | Local time between the last block build finishing and the checkpoint proposal being ready for p2p send. |
+| `checkpoint_proposal_init_time` | Proposer budget reserved at the start of the build frame for sync, the proposer check, and checkpoint initialization before the first block sub-slot opens. |
+
+`checkpoint_proposal_prepare_time` includes `completeCheckpoint`, local checkpoint validation, header validation simulation, checkpoint proposal signing, proposed-checkpoint archiver sync, and the immediate call into p2p broadcast.
+
+### Parameters
+
+These values change per timetable evaluation.
+
+| Input | Meaning |
+| --- | --- |
+| `target_slot` | The L2 slot the checkpoint commits to and whose proposer is building this checkpoint. |
+
+## Derived Slot Times
+
+The model derives all wall-clock times from `target_slot`, `genesis_time`, and the slot durations.
+
+```text
+target_slot_start = genesis_time + target_slot * aztec_slot_duration
+
+build_slot = target_slot - 1
+
+build_slot_start = genesis_time + build_slot * aztec_slot_duration
+
+build_frame_start = build_slot_start - ethereum_slot_duration
+
+next_proposer_build_frame_start = target_slot_start - ethereum_slot_duration
+```
+
+The build frame starts one Ethereum slot before the build slot starts.
+
+## L1 Publish and Attestation Deadline
+
+The model distinguishes an ideal L1 send time from a single hard attestation deadline.
+
+```text
+l1_publish_ideal_time = target_slot_start - ethereum_slot_duration
+```
+
+This is the time by which we want the L1 transaction ready and submitted to maximize the chance of inclusion in the first Ethereum block of `target_slot`.
+
+```text
+last_ethereum_block_in_target_slot = target_slot_start + aztec_slot_duration - ethereum_slot_duration
+
+attestation_deadline = last_ethereum_block_in_target_slot - ethereum_slot_duration
+```
+
+`attestation_deadline` is the hard deadline by which validators must have completed re-execution/validation and signed their attestation. It is also the latest useful L1 send time if the only requirement is for the tx to land in the final Ethereum block inside `target_slot`.
+
+This deadline is consensus-driven, not operational. It is used for inactivity/slashing decisions, so all nodes must agree
+on it. It is derived only from slot timing protocol constants.
+
+With `aztec_slot_duration = 72` and `ethereum_slot_duration = 12`:
+
+```text
+l1_publish_ideal_time = target_slot_start - 12
+attestation_deadline  = target_slot_start + 48
+```
+
+## Ideal Times vs Deadlines
+
+_Be conservative in what you send, be liberal in what you accept._
+
+The timetable has two rails:
+
+- **Ideal times** describe when work should complete on the happy path to maximize the L1 publishing window.
+- **Deadlines** describe the latest time work can complete under the rule that applies to that activity.
+
+The proposer should schedule block production and checkpoint proposal sending against ideal L1 publishing. Validators and p2p should enforce consensus deadlines, late attestation deadlines, and small clock-disparity tolerances. This lets delayed validators contribute attestations while keeping the proposer from planning around the slow path.
+
+Checkpoint proposal timing has both an ideal target and a hard deadline. The ideal target is derived from the L1 publish path and is not a consensus gate. The hard receive deadline is derived only from the next-proposer handoff constraint.
+
+## Checkpoint Proposal Deadlines
+
+The checkpoint proposal affects consensus: it determines the proposed checkpoint the next proposer may build on top of. For that reason, the receive deadline used for validation must not depend on operational budgets such as p2p propagation or L1 publish preparation time.
+
+The ideal receive time is a proposer scheduling target. It is the receive time that leaves enough room for validators to re-execute the checkpoint and send attestations back by `l1_publish_ideal_time`:
+
+```text
+checkpoint_proposal_receive_ideal_time = proposal_validation_ideal_time - block_duration
+```
+
+The hard receive deadline is the consensus gate. Validators reject checkpoint proposals that arrive after this time, and the next proposer does not build on them. It is derived from the next proposer's own build frame:
+
+```text
+checkpoint_proposal_receive_deadline = next_proposer_build_frame_start - block_duration
+```
+
+The send time is proposer-owned and is derived by subtracting one propagation hop from the ideal receive time:
+
+```text
+checkpoint_proposal_send_time = checkpoint_proposal_receive_ideal_time - p2p_propagation_time
+```
+
+The sequencer does not need to wait for this send time. It should send the checkpoint proposal as soon as the final block and local checkpoint proposal preparation are complete. The proposer schedules block building only against the ideal L1 publish path:
+
+```text
+last_block_build_time = checkpoint_proposal_send_time - checkpoint_proposal_prepare_time
+```
+
+The first consensus boundary for the checkpoint proposal is `checkpoint_proposal_receive_deadline`, not a send deadline.
+
+## Checkpoint Proposal Materialization and Orphan Pruning
+
+After an in-time checkpoint proposal is received, it still has to validate and materialize into the archiver's
+proposed-checkpoint state before the next proposer can safely build on it. The materialization deadline is:
+
+```text
+checkpoint_proposal_synced_deadline = next_proposer_build_frame_start + checkpoint_proposal_sync_grace
+```
+
+`checkpoint_proposal_sync_grace` is a consensus/network value, defaulting to `2 * block_duration`. It is not an
+operator-tuned archiver knob: nodes need to agree on when a received proposal has had enough time to materialize.
+
+Orphan proposed-block pruning has two branches:
+
+- If no checkpoint proposal was received for the orphan slot, the archiver prunes once strictly past
+  `checkpoint_proposal_receive_deadline + orphan_prune_no_proposal_tolerance`.
+- If a checkpoint proposal was received but has not materialized into proposed archiver state, the archiver prunes
+  once strictly past `checkpoint_proposal_synced_deadline`.
+
+`orphan_prune_no_proposal_tolerance` is archiver-local tolerance, defaulting to 1 second. It only covers
+polling and timer skew in the no-proposal branch; it does not define whether a checkpoint proposal is buildable.
+
+The no-proposal branch deliberately does not wait for `attestation_deadline`. A malicious proposer can broadcast
+block proposals while withholding transaction data and never send the checkpoint proposal. Other nodes may then
+spend the remaining validation window trying to collect missing transactions and re-execute a checkpoint that will
+not be buildable by the next proposer. Pruning after the receive deadline plus local tolerance restores next-proposer
+liveness.
+
+The received-proposal branch gives bounded time for validation and archiver insertion. Validators that do not
+finish re-execution before `checkpoint_proposal_synced_deadline` may fail to attest on time and may only follow the
+checkpoint once it is re-synced from L1.
+
+## Proposal Validation and Attestation Times
+
+The relevant validator-side activity is proposal validation: receiving proposals, collecting transactions if needed, re-executing blocks, validating the checkpoint, and then signing an attestation.
+
+For intermediate block proposals within the checkpoint, the same principle applies at each sub-slot: validators should receive the proposal, collect any missing transactions, and re-execute the block within the block's validation budget. For the final checkpoint proposal, `proposal_validation_ideal_time` is the aggregate end-of-checkpoint validation target.
+
+Ideal validation completion is computed from the ideal L1 send time:
+
+```text
+attestation_receive_ideal_time = l1_publish_ideal_time
+
+proposal_validation_ideal_time = attestation_receive_ideal_time - p2p_propagation_time
+```
+
+The hard validation deadline is `attestation_deadline`:
+
+```text
+block_validation_deadline = attestation_deadline
+checkpoint_validation_deadline = attestation_deadline
+```
+
+The ideal difference between validation completion and attestation receipt is one propagation hop:
+
+```text
+attestation_receive_ideal_time - proposal_validation_ideal_time = p2p_propagation_time
+```
+
+The proposer should aim to have enough attestations by `attestation_receive_ideal_time`. Validators may still validate blocks, validate the checkpoint, and sign attestations until `attestation_deadline`. This deadline is the same for all block proposals and the final checkpoint proposal. It must be consensus-driven because inactivity/slashing checks use it to decide whether a validator failed to attest on time.
+
+The `attestation_deadline` above is a validation/re-execution deadline, not an arrival gate. Arrival at the p2p layer is gated separately and more tightly: intermediate block proposals share the checkpoint proposal's receive window as their arrival gate. Every block proposal for a slot is sent before that slot's checkpoint proposal, so nothing legitimate can arrive after `checkpoint_proposal_receive_deadline`. A block proposal arriving after that deadline is therefore rejected at p2p ingress, exactly as a late checkpoint proposal would be. The `attestation_deadline` remains the validation/re-execution deadline for any block or checkpoint proposal that did arrive in time.
+
+## Block Sub-Slots
+
+Block sub-slots are fixed windows counted from the first sub-slot start, which sits one `checkpoint_proposal_init_time` after `build_frame_start`. `min_block_duration` is the spec name for the minimum execution headroom currently called `minExecutionTime`.
+
+`checkpoint_proposal_init_time` is the proposer budget reserved at the start of the build frame for sync, the proposer check, and checkpoint initialization. The proposer rarely begins building exactly at `build_frame_start` — it enters the build loop only after that prologue completes — so the sub-slot grid is offset by this budget. Without it, any non-zero prologue eats into the first sub-slot, and when `min_block_duration` equals `block_duration` (tight fast profiles) the first sub-slot becomes unstartable, leaving the checkpoint under-packed. This is an operational proposer budget, so it lives in the proposer timetable and does not affect any consensus-acceptance deadline.
+
+```text
+first_subslot_start = build_frame_start + checkpoint_proposal_init_time
+
+block_build_start(block_index) = first_subslot_start + block_index * block_duration
+
+block_build_deadline(block_index) = first_subslot_start + (block_index + 1) * block_duration
+```
+
+where `block_index` is zero-based.
+
+Sub-slot starts and deadlines do not move when earlier blocks finish early or late. If block `k` finishes early, the proposer waits until `block_build_deadline(k)` before attempting block `k + 1`. If block `k` finishes late, the next sub-slot keeps its original deadline and therefore has less remaining headroom.
+
+The number of full-duration block sub-slots a node's local operational budgets compute is:
+
+```text
+computed_blocks_per_checkpoint = floor((last_block_build_time - first_subslot_start) / block_duration)
+```
+
+The effective `max_blocks_per_checkpoint` is this computed value, clamped down to the explicit network value when
+the network value is lower. A network value at or above the computed count has no effect and the computed count is
+used. When the local budgets compute more blocks than the network allows, the computed count is clamped down to the
+network value and a warning is emitted. Clamping never raises the effective value above what the local budgets can
+fit, preserving the invariant that every offered sub-slot's build deadline stays within `last_block_build_time`.
+
+`max_blocks_per_checkpoint` is also an input to the network tx admission limits (it divides the per-checkpoint gas budgets into a per-block share); see [`../gas/README.md`](../gas/README.md) under "Gas and Data Limits".
+
+The start deadline is the latest time at which the proposer can still squeeze one minimum-duration block and make the ideal L1 publish path:
+
+```text
+start_deadline = last_block_build_time - min_block_duration
+```
+
+If the sequencer reaches the build frame after `start_deadline`, it should abandon block production for the slot. A later
+checkpoint proposal might still satisfy the consensus receive deadline, but the proposer timetable intentionally does not
+plan around that path because it prioritizes publishing at `l1_publish_ideal_time`. If it starts before `start_deadline`
+but is late for a particular sub-slot, it should skip to the next available sub-slot with at least `min_block_duration`
+remaining.
+
+When choosing whether to start a block, the proposer scans the sub-slots in order and selects the first one whose
+deadline is at least `min_block_duration` in the future:
+
+```text
+block_build_deadline(block_index) - now >= min_block_duration
+```
+
+Sub-slots that do not satisfy this condition are skipped. This is also the rule while waiting for enough transactions. If
+the proposer is waiting for txs for a selected sub-slot, it may wait only until:
+
+```text
+wait_for_txs_deadline(block_index) = block_build_deadline(block_index) - min_block_duration
+```
+
+If enough txs arrive before `wait_for_txs_deadline(block_index)`, the proposer starts building in that sub-slot. If not,
+the sub-slot is dropped without committing a block, the proposer waits until the sub-slot deadline, and then retries with
+the next available sub-slot. If the dropped sub-slot was the final sub-slot, block production for the checkpoint ends.
+Empty-checkpoint forcing may override the tx-count rule, but it must not remove the `min_block_duration` headroom
+requirement.
+
+`block_build_deadline(block_index)` is an execution cutoff, not only a scheduling hint. Block building should stop public
+tx execution at that deadline and then finalize the block from whatever txs were successfully executed. Finalization may
+spill slightly past the deadline, but later sub-slot starts and deadlines must not move.
+
+## Parallel Execution
+
+For non-final blocks, proposer building and committee validation are pipelined. After the proposer finishes and broadcasts
+block `k`, validators receive it, collect any missing txs, and re-execute it while the proposer waits for or starts block
+`k + 1`.
+
+This is why `block_duration` is used both as the proposer’s normal build cadence and as the validator re-execution
+budget. The system does not wait for committee validation of block `k` before beginning block `k + 1`; it relies on the
+fixed sub-slot cadence and p2p propagation budget to keep both sides aligned.
+
+The final block is different. There is no block `k + 1` to build in parallel, and the final block should not be broadcast
+as a regular block proposal. The proposer holds it and includes it in the checkpoint proposal, then spends the dead zone
+assembling and sending that checkpoint proposal, waiting for committee re-execution and attestations, and preparing the
+L1 publish request.
+
+## Handling Timing Variations
+
+The sub-slot schedule is fixed, so timing variation changes how much headroom remains; it does not move deadlines.
+
+- If the proposer initializes early, the first block gets extra time before its fixed deadline.
+- If the proposer initializes late but the current sub-slot still has at least `min_block_duration` remaining, it may
+  build in that sub-slot.
+- If initialization or a previous block overrun leaves less than `min_block_duration` before the current sub-slot deadline, that sub-slot is skipped.
+- If a block finishes early, the proposer waits until the next sub-slot boundary before attempting the next block.
+- If a block finishes late, the next block may still start if some later sub-slot has enough remaining headroom.
+- If a block cannot be built because there are not enough txs, the current sub-slot is dropped and the proposer retries at the next available sub-slot, unless the dropped sub-slot was the final one.
+
+## Dead Zone
+
+The dead zone is the time between the previous proposer finishing its final block and the next proposer starting its own build frame. During this interval no proposer is actively building new blocks.
+
+```text
+dead_zone = next_proposer_build_frame_start - last_block_build_time
+```
+
+Expanded through the ideal L1 publish path:
+
+```text
+dead_zone = checkpoint_proposal_prepare_time
+  + p2p_propagation_time
+  + block_duration
+  + p2p_propagation_time
+```
+
+The two `p2p_propagation_time` terms are different hops:
+
+- checkpoint proposal propagation from proposer to validators;
+- attestation propagation from validators back to the proposer.
+
+The dead zone is deliberate. It buys enough time to assemble and broadcast the checkpoint proposal, let validators re-execute it, and receive attestations back before `l1_publish_ideal_time`. A later checkpoint proposal may still satisfy the consensus handoff deadline, but the proposer does not size block production around that fallback.
+
+## Next-Proposer Handoff
+
+The next proposer must have enough time to receive and re-execute the previous checkpoint before its own build frame starts. This is the consensus-critical receive deadline:
+
+```text
+next_proposer_handoff_deadline = checkpoint_proposal_receive_deadline + block_duration
+
+next_proposer_handoff_deadline = next_proposer_build_frame_start
+```
+
+The handoff driven by the ideal path that maximizes L1 inclusion times is earlier:
+
+```text
+next_proposer_handoff_ideal_time = checkpoint_proposal_receive_ideal_time + block_duration
+
+next_proposer_handoff_ideal_time = next_proposer_build_frame_start - p2p_propagation_time
+```
+
+Therefore:
+
+```text
+next_proposer_handoff_ideal_time <= next_proposer_build_frame_start
+
+next_proposer_handoff_deadline = next_proposer_build_frame_start
+```
+
+The ideal handoff margin is:
+
+```text
+next_proposer_build_frame_start - next_proposer_handoff_ideal_time =   p2p_propagation_time
+```
+
+The consensus handoff deadline is `p2p_propagation_time` later than the ideal handoff target. That slack is for accepting otherwise valid late checkpoint proposals, not for sizing normal block production.
+
+## Constraints
+
+### Input constraints
+
+```text
+target_slot > 0
+aztec_slot_duration > 0
+ethereum_slot_duration > 0
+aztec_slot_duration >= ethereum_slot_duration
+aztec_slot_duration % ethereum_slot_duration == 0
+block_duration > 0
+min_block_duration > 0
+min_block_duration <= block_duration
+p2p_propagation_time >= 0
+checkpoint_proposal_prepare_time >= 0
+checkpoint_proposal_init_time >= 0
+```
+
+### Build frame constraint
+
+```text
+build_frame_start = build_slot_start - ethereum_slot_duration
+```
+
+### P2P propagation constraints
+
+```text
+checkpoint_proposal_receive_ideal_time - checkpoint_proposal_send_time = p2p_propagation_time
+
+attestation_receive_ideal_time - proposal_validation_ideal_time = p2p_propagation_time
+```
+
+### Next proposer constraint
+
+```text
+checkpoint_proposal_receive_deadline = next_proposer_build_frame_start - block_duration
+
+next_proposer_handoff_deadline = checkpoint_proposal_receive_deadline + block_duration
+
+next_proposer_handoff_deadline = next_proposer_build_frame_start
+```
+
+The ideal target must be no later than the consensus handoff:
+
+```text
+next_proposer_handoff_ideal_time = checkpoint_proposal_receive_ideal_time + block_duration
+
+next_proposer_handoff_ideal_time = next_proposer_build_frame_start - p2p_propagation_time
+
+next_proposer_handoff_ideal_time <= next_proposer_handoff_deadline
+```
+
+### Attestation deadline constraints
+
+```text
+attestation_deadline = last_ethereum_block_in_target_slot - ethereum_slot_duration
+
+block_validation_deadline = attestation_deadline
+
+checkpoint_validation_deadline = attestation_deadline
+```
+
+### Checkpoint proposal preparation constraint
+
+```text
+checkpoint_proposal_send_time - last_block_build_time = checkpoint_proposal_prepare_time
+```
+
+### Minimum useful checkpoint constraint
+
+```text
+start_deadline >= build_frame_start
+max_blocks_per_checkpoint >= 1
+```
+
+Expanded:
+
+```text
+last_block_build_time - min_block_duration >= build_frame_start
+```
+
+### Ideal-before-deadline constraints
+
+```text
+l1_publish_ideal_time <= attestation_deadline
+attestation_receive_ideal_time <= attestation_deadline
+proposal_validation_ideal_time <= attestation_deadline
+checkpoint_proposal_receive_ideal_time <= checkpoint_proposal_receive_deadline
+```
+
+### Happy-path readiness constraint
+
+To maximize the L1 publishing window, the proposer should not plan around late attestation acceptance. On the happy path:
+
+```text
+actual_checkpoint_proposal_receive_time <= checkpoint_proposal_receive_ideal_time
+
+actual_proposal_validation_complete_time <= proposal_validation_ideal_time
+
+actual_attestation_receive_time <= attestation_receive_ideal_time
+```
+
+Then the L1 publish tx can be sent at:
+
+```text
+l1_publish_ideal_time
+```
+
+For consensus acceptance:
+
+```text
+actual_checkpoint_proposal_receive_time <= checkpoint_proposal_receive_deadline
+actual_block_validation_complete_time <= attestation_deadline
+actual_checkpoint_validation_complete_time <= attestation_deadline
+actual_attestation_signed_time <= attestation_deadline
+```
+
+## Suggested Constants
+
+These are proposed values for the new model. They intentionally separate production settings from local e2e settings with mocked p2p networks.
+
+### Production
+
+| Input | Proposed value | Rationale |
+| --- | ---: | --- |
+| `aztec_slot_duration` | 72s | Mainnet-like L2 slot duration. |
+| `ethereum_slot_duration` | 12s | Ethereum mainnet slot duration. |
+| `block_duration` | 6s | Allows up to 10 blocks while still targeting the ideal L1 publish time. |
+| `min_block_duration` | 2s | Conservative minimum useful execution budget. |
+| `p2p_propagation_time` | 2s | Conservative one-way proposal/attestation propagation budget. |
+| `checkpoint_proposal_prepare_time` | 1s | Conservative checkpoint assembly and broadcast preparation budget. |
+| `checkpoint_proposal_init_time` | 1s | Sync + proposer-check + init budget reserved before the first sub-slot. |
+
+Derived shape with these values:
+
+```text
+l1_publish_ideal_time is 12s before target_slot_start
+attestation_deadline is 48s after target_slot_start
+attestation_receive_ideal_time is 12s before target_slot_start
+proposal_validation_ideal_time is 14s before target_slot_start
+checkpoint_proposal_receive_ideal_time is 20s before target_slot_start
+checkpoint_proposal_receive_deadline is 18s before target_slot_start
+checkpoint_proposal_send_time is 22s before target_slot_start
+last_block_build_time is 23s before target_slot_start
+dead_zone = 11s
+max_blocks_per_checkpoint = 10
+```
+
+The ideal publish path is the normal scheduling target: it reserves one attestation propagation hop, validator re-execution time, one checkpoint proposal propagation hop, and local checkpoint proposal preparation. The hard checkpoint proposal receive deadline is later and is used for consensus acceptance.
+
+### Local e2e with mocked p2p
+
+For mocked p2p networks, local profiles can use shorter propagation and preparation budgets. A fast profile should still
+preserve the same ordering constraints as production.
+
+These fast-profile budgets are applied automatically when `ethereum_slot_duration` is below `FAST_PROFILE_ETHEREUM_SLOT_DURATION` (8s): the timetable clamps `p2p_propagation_time`, `checkpoint_proposal_prepare_time`, and `min_block_duration` down to the fast values below. Without this, a fast network would inherit the conservative production budgets (e.g. `p2p_propagation_time = 2s`), which shrink the per-checkpoint build window and under-pack checkpoints. The clamp only lowers budgets, so an operator that explicitly configures a smaller value keeps it; `checkpoint_proposal_init_time` is a proposer prologue budget and is not affected by the profile.
+
+Recommended fast local profile:
+
+| Input | Proposed value | Rationale |
+| --- | ---: | --- |
+| `aztec_slot_duration` | 36s | Fast local e2e slot duration for epoch tests. |
+| `ethereum_slot_duration` | 4s | Fast anvil-style Ethereum slot duration. |
+| `block_duration` | 6s | Fast block cadence while still leaving room for validation. |
+| `min_block_duration` | 1s | Local execution and mocked p2p are faster; preserves late-start behavior. |
+| `p2p_propagation_time` | 0.5s | Mocked one-way proposal/attestation propagation budget. |
+| `checkpoint_proposal_prepare_time` | 0.5s | Short local checkpoint assembly and broadcast preparation budget. |
+| `checkpoint_proposal_init_time` | 1s | Sync + proposer-check + init budget reserved before the first sub-slot. |
+
+Derived shape with these values:
+
+```text
+l1_publish_ideal_time is 4s before target_slot_start
+attestation_deadline is 28s after target_slot_start
+attestation_receive_ideal_time is 4s before target_slot_start
+proposal_validation_ideal_time is 4.5s before target_slot_start
+checkpoint_proposal_receive_ideal_time is 10.5s before target_slot_start
+checkpoint_proposal_receive_deadline is 10s before target_slot_start
+checkpoint_proposal_send_time is 11s before target_slot_start
+last_block_build_time is 11.5s before target_slot_start
+dead_zone = 7.5s
+max_blocks_per_checkpoint = 4
+```
+
+Alternative slower-block local profile:
+
+| Input | Proposed value | Rationale |
+| --- | ---: | --- |
+| `aztec_slot_duration` | 36s |
+| `ethereum_slot_duration` | 4s |
+| `block_duration` | 8s |
+| `min_block_duration` | 1s |
+| `p2p_propagation_time` | 0.5s |
+| `checkpoint_proposal_prepare_time` | 0.5s |
+| `checkpoint_proposal_init_time` | 1s |
+
+This yields `max_blocks_per_checkpoint = 3` for a 36s/4s/8s local profile.