You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore(fast-inbox): delete legacy per-checkpoint and 128-bit message paths in the archiver (A-1388)
Removes the legacy getL1ToL2Messages(checkpointNumber) flow, the padded
per-checkpoint index invariants, the inboxTreeInProgress readiness gate, and the
L1ToL2MessagesNotReadyError. InboxMessage drops the 128-bit keccak rollingHash and
the vacuous derived checkpointNumber, so messages carry only the compact global
index and the full-width consensus rolling hash; the store serialization changes and
ARCHIVER_DB_VERSION bumps to 9 (nodes resync, no migration). Reorg detection now
compares the local consensus rolling hash and total against the Inbox's current
rolling-hash bucket via new getBucket/getCurrentBucketSeq/getCurrentBucket wrappers,
replacing the 128-bit getState comparison. Test fakes/mocks move to compact indexing.
Copy file name to clipboardExpand all lines: yarn-project/archiver/README.md
+4-5Lines changed: 4 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,9 +44,9 @@ Two independent syncpoints track progress on L1:
44
44
45
45
### L1-to-L2 Messages
46
46
47
-
Messages are synced from the Inbox contract. The sync compares local state (message count and rolling hash) against the Inbox contract state on L1, downloads any missing messages, and verifies consistency afterwards. On success, the syncpoint advances to the current L1 block. On failure (L1 reorg or inconsistency), the syncpoint rolls back to the last known-good message and the operation retries (up to 3 times within the same sync iteration).
47
+
Messages are synced from the Inbox contract. The sync compares local state (message count and consensus rolling hash) against the Inbox's current rolling-hash bucket on L1, downloads any missing messages, and verifies consistency afterwards. On success, the syncpoint advances to the current L1 block. On failure (L1 reorg or inconsistency), the syncpoint rolls back to the last known-good message and the operation retries (up to 3 times within the same sync iteration).
48
48
49
-
1. Query Inbox state at the current L1 block (message count + rolling hash)
49
+
1. Query the Inbox's current bucket at the current L1 block (cumulative message count + consensus rolling hash)
50
50
2. Compare local state against remote
51
51
3. If they match, advance syncpoint and return
52
52
4. If mismatch, fetch `MessageSent` events in batches and store them
@@ -55,7 +55,7 @@ Messages are synced from the Inbox contract. The sync compares local state (mess
55
55
- If still mismatched (e.g., messages missed due to a concurrent L1 reorg), rollback and retry
56
56
6. On success, advance the syncpoint
57
57
58
-
The syncpoint and the `inboxTreeInProgress` marker (which tracks which checkpoint's messages are currently being filled on L1) are updated atomically. The marker is only advanced after messages are stored, so concurrent reads don't see an unsealed checkpoint as readable before its messages are available.
58
+
Messages are stored with compact (unpadded) global indices matching the Inbox's insertion order, and each carries the consensus rolling hash (a truncated sha256 chain) and the sequence of the Inbox bucket it was absorbed into (AZIP-22 Fast Inbox). Bucket snapshots let the sequencer and validator resolve message bundles per block.
59
59
60
60
### Checkpoints
61
61
@@ -70,13 +70,12 @@ Checkpoints are synced from the Rollup contract via `handleCheckpoints()`:
70
70
- Verify archive matches (checkpoint still in chain)
- Skip invalid checkpoints (see "Invalid Checkpoints" in Edge Cases)
73
-
- Verify `inHash` matches expected value (see below)
74
73
- Store valid checkpoints with their blocks
75
74
6. Update proven checkpoint again (may have advanced after storing new checkpoints)
76
75
7. Handle epoch prune if applicable
77
76
8. Check for checkpoints behind syncpoint (L1 reorg case)
78
77
79
-
The `inHash` is a hash of all L1-to-L2 messages consumed by a checkpoint. The archiver computes the expected `inHash` from locally stored messages and compares it against the checkpoint header. A mismatch indicates a bug (messages out of sync with checkpoints) and causes a fatal error.
78
+
L1 enforces at propose time that a checkpoint header's consensus rolling hash matches the Inbox bucket the checkpoint consumes through (AZIP-22 Fast Inbox), so the archiver does not re-derive or cross-check a per-checkpoint message hash while syncing.
80
79
81
80
The `blocksSynchedTo` syncpoint is updated:
82
81
- When checkpoints are stored: set to the L1 block of the last stored checkpoint
0 commit comments