docs(l1): refresh forks roadmap#6728
Conversation
|
🤖 Kimi Code ReviewThis is a documentation-only update to the Amsterdam hardfork roadmap. The restructuring from chronological status updates to a current-devnet-centric view is a significant improvement for readability. Minor suggestions:
Correctness check:
The documentation structure is clear and the technical details appear accurate. The removal of historical status sections (February/March updates) in favor of the "Current Devnet" + "Active Work" model reduces maintenance burden going forward. Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt |
🤖 Claude Code ReviewReview: docs(l1): refresh forks roadmap for bal-devnet-7This is a documentation-only PR — no code changes. The restructuring from a historical changelog into a forward-looking document is a clear improvement. Overall it's clean and well-organized. A few observations worth considering: EIP-8025 Status InconsistencyThe "Core Amsterdam EIPs" table marks EIP-8025 as
These two statements appear contradictory to a reader unfamiliar with the context. It would be clearer to qualify the "Implemented" status in the table, e.g., Hardcoded Line Numbers in Active WorkThe EIP-7702 delegation BAL exclusion block references concrete source locations:
Line numbers in a Markdown roadmap file are fragile — any unrelated refactor or insertion can silently invalidate these pointers. Consider using function names only (which you already do in the prose) and omitting the line numbers, or noting them with a "(as of bal-devnet-7)" qualifier so future readers know they may have drifted. Near-Term Date Without a Tracking IssueThe Active Work section opens with:
That date is three days from now (today is 2026-05-26). If the release slips, this line becomes immediately stale. The document already has [#6583] for devnet-7 tracking — it would be worth linking or cross-referencing a fixture-pin tracking issue here too, so readers know where to watch for the actual drop rather than relying on a hard date. Removed Link Definitions for Completed WorkA large number of PR links ( Minor Nits
SummaryThe restructuring is solid — removing stale status-update noise and replacing it with an actionable forward view is the right call. The EIP-8025 inconsistency (Point 1) is the only item that could actively mislead a reader; the rest are minor polish suggestions. Automated review by Claude (Anthropic) · sonnet · custom prompt |
🤖 Codex Code ReviewFindings:
No code correctness, security, gas-accounting, or consensus-risk findings here beyond the documentation issues above. I checked the concrete pinned values against Automated review by OpenAI Codex · gpt-5.4 · custom prompt |
Greptile SummaryThis is a documentation-only refresh of
Confidence Score: 4/5Documentation-only change; no production code or tests are modified, so the risk of merging is minimal. The rewrite is accurate and well-structured. Two small clarifications would improve it: EIP-8159 is marked Implemented with no supporting PR link (unlike the other two newly-promoted EIPs), and the "Out of Scope / Deferred" label for debug_getRawBlockAccessList contradicts the inline note saying it is required for bal-devnet-7, which could cause confusion about whether the work is planned or abandoned. docs/roadmaps/forks-roadmap.md — specifically the EIP-8159 row and the Out of Scope section heading.
|
| Filename | Overview |
|---|---|
| docs/roadmaps/forks-roadmap.md | Docs-only refresh for bal-devnet-7: collapses historical status updates, adds Active Work / Out of Scope sections, and marks EIPs 7954/8025/8159 as Implemented. Minor: EIP-8159 row has no PR reference or owner; "Out of Scope" description for debug_getRawBlockAccessList mildly contradicts the inline note that it is "required for bal-devnet-7 protocol-side." |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["bal-devnet-7\ntests-bal@v7.2.0\nEELS a3e5201a5"] --> B["Active: tests-bal@v7.3.0\n(~2026-05-29)\nEIP-8037 + EIP-7928 patches"]
A --> C["Active: EIPs#11699\nEIP-7702 delegation\nBAL exclusion"]
A --> D["Active: eth_simulateV1\n#6212"]
B --> E["glamsterdam- devnets\n(future prefix)"]
A --> F["Out of Scope / Deferred\n• debug_getRawBlockAccessList\n• Debug receipt fields\n• Deferred-on-success gas\n• zkboost fixtures\n• Gas repricing EIPs"]
Prompt To Fix All With AI
Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
docs/roadmaps/forks-roadmap.md:44
**EIP-8159 row missing implementation evidence**
EIP-8159 (`eth/71 Block Access List Exchange`) is listed as `✅ Implemented` but unlike the other newly-promoted EIPs (8025 links `[#6361]`, 7954 was `[#6214]`), there is no PR reference, owner, or implementation note in the row. Given that the PR description explicitly calls this out as one of the three EIPs "moved to Implemented", adding a link to the implementing PR or commit would keep the table auditable and consistent with the entries around it.
### Issue 2 of 2
docs/roadmaps/forks-roadmap.md:80-81
**"Out of Scope" label conflicts with the inline note for `debug_getRawBlockAccessList`**
The bullet describes this RPC as "required for bal-devnet-7 protocol-side; tracked separately," which reads as in-scope work that simply lives in another tracking document. Labelling it "Out of Scope / Deferred" may mislead readers into thinking ethrex won't implement it for bal-devnet-7. Consider renaming the section (e.g., "Tracked Elsewhere" or "Not in this Document") or rewording the bullet so the distinction between "out of this doc's scope" and "out of the project's scope" is explicit.
Reviews (1): Last reviewed commit: "docs(l1): refresh forks roadmap for bal-..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| | **7976** | Increase Calldata Floor Cost | ✅ Implemented | CFI | | | ||
| | **7981** | Increase Access List Cost | ✅ Implemented | CFI | | | ||
| | **7954** | Increase Max Contract Size (24→32 KiB) | ✅ Implemented | CFI | | | ||
| | **7872** | Max Blob Flag for Local Builders | ✅ Implemented | PFI | Edgar | |
There was a problem hiding this comment.
EIP-8159 (eth/71 Block Access List Exchange) is listed as ✅ Implemented but unlike the other newly-promoted EIPs (8025 links [#6361], 7954 was [#6214]), there is no PR reference, owner, or implementation note in the row. Given that the PR description explicitly calls this out as one of the three EIPs "moved to Implemented", adding a link to the implementing PR or commit would keep the table auditable and consistent with the entries around it.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/roadmaps/forks-roadmap.md
Line: 44
Comment:
**EIP-8159 row missing implementation evidence**
EIP-8159 (`eth/71 Block Access List Exchange`) is listed as `✅ Implemented` but unlike the other newly-promoted EIPs (8025 links `[#6361]`, 7954 was `[#6214]`), there is no PR reference, owner, or implementation note in the row. Given that the PR description explicitly calls this out as one of the three EIPs "moved to Implemented", adding a link to the implementing PR or commit would keep the table auditable and consistent with the entries around it.
How can I resolve this? If you propose a fix, please make it concise.| ### [EIPs#11699] — EIP-7702 delegation BAL exclusion | ||
|
|
There was a problem hiding this comment.
debug_getRawBlockAccessList
The bullet describes this RPC as "required for bal-devnet-7 protocol-side; tracked separately," which reads as in-scope work that simply lives in another tracking document. Labelling it "Out of Scope / Deferred" may mislead readers into thinking ethrex won't implement it for bal-devnet-7. Consider renaming the section (e.g., "Tracked Elsewhere" or "Not in this Document") or rewording the bullet so the distinction between "out of this doc's scope" and "out of the project's scope" is explicit.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/roadmaps/forks-roadmap.md
Line: 80-81
Comment:
**"Out of Scope" label conflicts with the inline note for `debug_getRawBlockAccessList`**
The bullet describes this RPC as "required for bal-devnet-7 protocol-side; tracked separately," which reads as in-scope work that simply lives in another tracking document. Labelling it "Out of Scope / Deferred" may mislead readers into thinking ethrex won't implement it for bal-devnet-7. Consider renaming the section (e.g., "Tracked Elsewhere" or "Not in this Document") or rewording the bullet so the distinction between "out of this doc's scope" and "out of the project's scope" is explicit.
How can I resolve this? If you propose a fix, please make it concise.Per EIP-7773 (Glamsterdam meta) and EIP-8081 (Hegotá meta): - relabel implemented Amsterdam EIPs as SFI (not CFI) where applicable - list Amsterdam EL CFI candidates not yet evaluated by ethrex - add CL-side ePBS (7732) and notable DFI list - expand Hegotá section with SFI (7805 FOCIL), CFI (8141), PFI (4758, 7709, 7716, 8025, 8188, 8205, 8253)
edg-l
changed the title
| - Amsterdam consume-engine hive tests added to PR CI (~1000 tests) | ||
| - Amsterdam hive tests marked as optional (fork spec still evolving) | ||
| ethrex currently matches the **old** spec. When EELS merges: | ||
| - Move delegation `code_address` BAL recording from `record_bal_call_touch` (`crates/vm/levm/src/opcode_handlers/system.rs:889`) to after the `sender_balance`/depth guards inside `generic_call` (~line 962). |
There was a problem hiding this comment.
nit: the line numbers (system.rs:889, ~962) are accurate today — I verified both against this branch — but this is a forward-looking action item ("when EELS merges, do X"), and system.rs will almost certainly shift before that happens, leaving an implementer chasing the wrong lines. Function-name anchors are more durable than line numbers for a "do this later" note:
Move delegation
code_addressBAL recording out ofrecord_bal_call_touchto after thesender_balance/depth guards ingeneric_call(both insystem.rs).
Low priority — just so the breadcrumb doesn't rot between now and the EELS merge.
4 participants
Updates
docs/roadmaps/forks-roadmap.mdto reflect current state as of bal-devnet-7.📄 Rendered: https://github.com/lambdaclass/ethrex/blob/docs/forks-roadmap-bal-devnet-7/docs/roadmaps/forks-roadmap.md
No code or test changes.