Commit 2842270
committed
feat(fast-inbox): reject over-cap block counts at attestation time (A-1539)
The checkpoint root circuit caps how many blocks a checkpoint may contain, but L1 cannot enforce that cap when the
checkpoint is proposed: `ProposedHeader` carries no block count, only `blockHeadersHash`. An over-cap checkpoint would
therefore be accepted on L1 and then be unprovable, forcing an epoch reorg — so validators have to reject it before
attesting, the same enforcement pattern the streaming Inbox uses for `MAX_L1_TO_L2_MSGS_PER_CHECKPOINT`.
The checkpoint-proposal check already existed but only fired for an operator-configured `maxBlocksPerCheckpoint`. It
now always applies the protocol cap, with the operator limit only able to tighten it.
Test: an over-cap checkpoint proposal is rejected with no operator limit configured.1 parent a8cbe0c commit 2842270
2 files changed
Lines changed: 30 additions & 4 deletions
Lines changed: 20 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1 | 1 | | |
2 | 2 | | |
3 | | - | |
| 3 | + | |
4 | 4 | | |
5 | 5 | | |
6 | 6 | | |
| |||
196 | 196 | | |
197 | 197 | | |
198 | 198 | | |
| 199 | + | |
| 200 | + | |
| 201 | + | |
| 202 | + | |
| 203 | + | |
| 204 | + | |
| 205 | + | |
| 206 | + | |
| 207 | + | |
| 208 | + | |
| 209 | + | |
| 210 | + | |
| 211 | + | |
| 212 | + | |
| 213 | + | |
| 214 | + | |
| 215 | + | |
| 216 | + | |
| 217 | + | |
199 | 218 | | |
200 | 219 | | |
201 | 220 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
4 | 4 | | |
5 | 5 | | |
6 | 6 | | |
| 7 | + | |
7 | 8 | | |
8 | 9 | | |
9 | 10 | | |
| |||
1282 | 1283 | | |
1283 | 1284 | | |
1284 | 1285 | | |
1285 | | - | |
1286 | | - | |
1287 | | - | |
| 1286 | + | |
| 1287 | + | |
| 1288 | + | |
| 1289 | + | |
| 1290 | + | |
| 1291 | + | |
| 1292 | + | |
| 1293 | + | |
| 1294 | + | |
1288 | 1295 | | |
1289 | 1296 | | |
1290 | 1297 | | |
| |||
0 commit comments