execution: update EIP-7954 MaxCodeSizeAmsterdam = 64KB - #22088
Conversation
27973d0 to
b591ac1
Compare
75df13a to
a0ff706
Compare
…tech#22139) ## What Removes the `branches:` allowlist from the `pull_request` trigger in `ci-gate.yml`, so the CI Gate runs on PRs targeting **any** base branch. Previously the gate only fired for PRs whose base was `main`, `release/**`, `performance`, or `performance-stable`. PRs targeting long-lived integration branches (e.g. `glamsterdam-devnet-*`) got no gate at all — `gh pr checks` reported *"no checks reported on the branch"*. ## Why We want CI to verify PRs regardless of which base branch they target, so stacked/feature PRs against integration branches get the same lint + test coverage as PRs to `main`. ## Real-world example: the glamsterdam-devnet-6 EIP stack A hardfork is rolled out as a chain of small, stacked PRs — one EIP per PR, each branch based on the previous one's head: ``` main └─ glamsterdam-devnet-6-fixtures erigontech#22023 devnet fixtures ← runs CI today └─ worktree-gd6-eip-2780 erigontech#22053 EIP-2780 ← NO CI today └─ worktree-gd6-eip-8038 erigontech#22060 EIP-8038 ← NO CI today └─ worktree-gd6-eip-8282 erigontech#22093 EIP-8282 ← NO CI today └─ worktree-gd6-eip-8037 erigontech#22122 EIP-8037 ← NO CI today └─ worktree-gd6-eip-8246 erigontech#22136 EIP-8246 ← NO CI today └─ worktree-gd6-eip-7954 erigontech#22088 EIP-7954 ← NO CI today ``` Each PR's base is the branch directly above it in the stack. Only the root, erigontech#22023, targets `main` and runs the gate today; the six EIP PRs on top of it (erigontech#22053 → erigontech#22060 → erigontech#22093 → erigontech#22122 → erigontech#22136 → erigontech#22088) all target `worktree-gd6-eip-*` branches that aren't in the old allowlist, so **all six run zero CI**. With this change, each of the six runs the full gate against its own parent branch. Because a PR's diff is just its own increment on top of everything below it, a bug introduced by, say, EIP-8282 (erigontech#22093) is caught on **erigontech#22093's own run** — isolated to that one EIP. Today that bug stays invisible until the entire stack eventually lands on `main`, at which point a single red gate can't tell you which of the six EIPs broke it, and you're bisecting after the fact. For incremental rollouts assembled by chaining like this, that per-step isolation is the whole point — it catches the regression at the PR that introduced it. ## Impact - The gate now runs on every PR. The heavy leaves (tests, race, hive, kurtosis, sonar, …) stay gated behind the `changes` job, so docs-only PRs remain cheap. - `merge_group` and `workflow_dispatch` triggers are unchanged. - Expect increased CI usage for PRs against integration/devnet branches that previously ran nothing. Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
122b796 to
092ef93
Compare
yperbasis
left a comment
yperbasis
left a comment
There was a problem hiding this comment.
Verified against the devnet-6 pin (EELS d0338f56): Amsterdam MAX_CODE_SIZE = 0x10000, MAX_INIT_CODE_SIZE = 2× — the new values match exactly, and all enforcement points (tx-level, deposit, CREATE/CREATE2, txpool) pick them up through the fork-aware helpers.
One non-blocking follow-up: the txpool's txnMaxSize = 4 * txnSlotSize = 131,072 now equals MaxInitCodeSizeAmsterdam, so a creation transaction with initcode near the top of the newly legal range serializes above the cap and hits ErrRlpTooBig before CheckMaxInitCodeSize — consensus-valid but unpoolable/unpropagatable. Pre-Amsterdam the 49,152-byte limit never approached the cap, so this interaction is new. Consider a fork-aware bump of txnMaxSize, and checking what geth ships for devnet-6 to avoid asymmetric propagation of large deploys.
taratorio
changed the title
f376c98 to
63c3d20
Compare
let's leave that as a follow up since it needs to be coordinated |
2 participants
merge after #22136
closes #22085
ref https://eips.ethereum.org/EIPS/eip-7954