core/vm: add kzg precompile back for madhugiri forks#2140
core/vm: add kzg precompile back for madhugiri forks#2140manav2401 merged 7 commits intov2.7.0-candidatefrom
Conversation
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## v2.7.0-candidate #2140 +/- ##
===================================================
Coverage ? 51.58%
===================================================
Files ? 882
Lines ? 154208
Branches ? 0
===================================================
Hits ? 79552
Misses ? 69482
Partials ? 5174
🚀 New features to boost your workflow:
|
|
@claude review |
|
Claude finished @adamdossa's task in 1m 3s —— View job Review of PR #2140
Verdict: Looks good. This is a correct and necessary bugfix. AnalysisThe PR adds
Why this is correct: Both Madhugiri and MadhugiriPro forks were deployed with the KZG precompile active (inherited from the Cancun/Prague lineage). Removing it from these maps would cause nodes to reject historical blocks that called the Consistency check across all fork precompile maps:
Question
No other issues found — the change is minimal, correct, and addresses a real sync-breaking bug. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| common.BytesToAddress([]byte{0x07}): &bn256ScalarMulIstanbul{}, | ||
| common.BytesToAddress([]byte{0x08}): &bn256PairingIstanbul{}, | ||
| common.BytesToAddress([]byte{0x09}): &blake2F{}, | ||
| common.BytesToAddress([]byte{0x0a}): &kzgPointEvaluation{}, |
There was a problem hiding this comment.
🔴 PrecompiledContractsLisovoPro (line 252) is also missing the KZG precompile at 0x0a — it jumps from 0x09 (blake2F) directly to 0x0b (bls12381G1Add). Since activePrecompiledContracts checks IsLisovoPro first, nodes running the latest fork will lack the KZG point evaluation precompile, which is consensus-affecting. The same common.BytesToAddress([]byte{0x0a}): &kzgPointEvaluation{} entry added to the other maps needs to be added here too.
Extended reasoning...
What the bug is
This PR restores the KZG point evaluation precompile (kzgPointEvaluation at address 0x0a) to PrecompiledContractsPrague, PrecompiledContractsMadhugiri, and PrecompiledContractsMadhugiriPro. However, PrecompiledContractsLisovoPro — which suffers from the exact same omission — is not fixed. Looking at lines 252–270, the map jumps from 0x09 (blake2F) directly to 0x0b (bls12381G1Add) with no 0x0a entry.
Why this matters
The activePrecompiledContracts function (line 327) uses a switch statement where rules.IsLisovoPro is the first case checked. This means for nodes running the latest fork rules, PrecompiledContractsLisovoPro is the active precompile set. Any call to address 0x0a (the KZG point evaluation precompile) will fail because the address is not registered in that map.
Proof by example
- A contract on the LisovoPro fork calls address
0x0ato perform a KZG point evaluation. - The EVM calls
activePrecompiledContracts(rules), which returnsPrecompiledContractsLisovoPro(line 328). - The precompile lookup for address
0x0afinds no entry in the map. - The call is treated as a call to a regular (empty) account, not as a precompile — returning unexpected results.
- Meanwhile, the predecessor fork
PrecompiledContractsLisovo(line 229) does include0x0a: &kzgPointEvaluation{}, so this is a regression from Lisovo to LisovoPro.
Impact
This is a consensus-affecting bug. Nodes running LisovoPro will disagree with nodes that expect KZG to be available (as it was in every fork from Cancun/Prague onward). The PR description itself states the KZG precompile "was removed while enabling LisovoPro HF," yet the fix does not restore it to the LisovoPro precompile set.
Fix
Add the missing line to PrecompiledContractsLisovoPro:
common.BytesToAddress([]byte{0x0a}): &kzgPointEvaluation{},between the 0x09 (blake2F) and 0x0b (bls12381G1Add) entries, matching what was done for Prague, Madhugiri, and MadhugiriPro in this same PR.
There was a problem hiding this comment.
This is not true. When an EVM instance is created (in NewEVM function in core/vm/evm.go file), it activates precompiles based on current block number. So, if bor is executing an old block, it would activate a precompile activated at that block (and not the latest). This means old blocks in Madhugiri (and other forks) will still have kzg precompile enabled but blocks after LisovoPro won't have it enabled. Moreover, LisovoPro HF removes kzg precompile fully so it's intentional.
There was a problem hiding this comment.
Pull request overview
Re-enables the EIP-4844 KZG point-evaluation precompile (0x0a) for older Bor hardfork eras to prevent “bad block” errors when syncing historical blocks across Madhugiri/MadhugiriPro → Lisovo/LisovoPro transitions.
Changes:
- Add
kzgPointEvaluation(0x0a) toPrecompiledContractsMadhugiri - Add
kzgPointEvaluation(0x0a) toPrecompiledContractsMadhugiriPro - Add
kzgPointEvaluation(0x0a) toPrecompiledContractsPrague
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| common.BytesToAddress([]byte{0x07}): &bn256ScalarMulIstanbul{}, | ||
| common.BytesToAddress([]byte{0x08}): &bn256PairingIstanbul{}, | ||
| common.BytesToAddress([]byte{0x09}): &blake2F{}, | ||
| common.BytesToAddress([]byte{0x0a}): &kzgPointEvaluation{}, | ||
| common.BytesToAddress([]byte{0x0b}): &bls12381G1Add{}, |
| common.BytesToAddress([]byte{0x08}): &bn256PairingIstanbul{}, | ||
| common.BytesToAddress([]byte{0x09}): &blake2F{}, | ||
| common.BytesToAddress([]byte{0x0a}): &kzgPointEvaluation{}, | ||
| common.BytesToAddress([]byte{0x0b}): &bls12381G1Add{}, | ||
| common.BytesToAddress([]byte{0x0c}): &bls12381G1MultiExp{}, |
There was a problem hiding this comment.
Pull request overview
Reintroduces the KZG point evaluation precompile (0x0a) for the Bor-specific Madhugiri/MadhugiriPro hardfork precompile sets to prevent “bad block” errors when syncing historical ranges where those forks expected the precompile to exist.
Changes:
- Add
kzgPointEvaluation(0x0a) back intoPrecompiledContractsMadhugiriandPrecompiledContractsMadhugiriPro. - Update the existing test to assert KZG precompile presence/absence across multiple fork rule configurations.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| core/vm/contracts.go | Re-adds KZG (0x0a) to Madhugiri/MadhugiriPro precompile maps (and adds a note in Osaka’s map). |
| core/vm/contracts_test.go | Refactors the KZG precompile test into a table-driven check across forks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR restores the KZG point-evaluation precompile (0x0a) for the Bor-specific Madhugiri and MadhugiriPro forks to avoid “bad block” errors when syncing historical blocks across the Madhugiri↔Lisovo fork range.
Changes:
- Re-enabled the
kzgPointEvaluationprecompile at address0x0ainPrecompiledContractsMadhugiriandPrecompiledContractsMadhugiriPro. - Updated the unit test to validate KZG precompile presence across multiple forks (pre-Madhugiri, Madhugiri/MadhugiriPro/Lisovo, and removal at LisovoPro).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
core/vm/contracts.go |
Adds 0x0a -> kzgPointEvaluation to Madhugiri and MadhugiriPro precompile sets. |
core/vm/contracts_test.go |
Adjusts the KZG precompile test to cover multiple hardfork rule configurations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
|
Description
Add KZG precompile back for Madhugiri / MadhugiriPro.
It was removed while enabling LisovoPro HF from all previous precompiles while those blocks already used the precompile. This PR adds it back so that nodes don't return bad block errors while syncing past blocks (between Madhugiri/MadhugiriPro and Lisovo/LisovoPro).
Changes
Breaking changes
Please complete this section if any breaking changes have been made, otherwise delete it
Nodes audience
In case this PR includes changes that must be applied only to a subset of nodes, please specify how you handled it (e.g. by adding a flag with a default value...)
Checklist
Cross repository changes
Testing
Manual tests
Please complete this section with the steps you performed if you ran manual tests for this functionality, otherwise delete it
Additional comments
Please post additional comments in this section if you have them, otherwise delete it