core, blockstm, state: add BlockSTM v2 parallel transaction execution #2210
Claude / Claude Code Review
completed
May 5, 2026 in 26m 28s
Code review found 1 important issue
Found 5 candidates, confirmed 3. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 1 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🔴 Important | core/blockchain.go:916-928 |
V2-failure fallback recovery cancelled before serial completes |
| 🟡 Nit | core/blockchain.go:417-420 |
BlockChain.AblationSkip* fields declared but never read |
| 🟡 Nit | core/blockstm/mvhashmap.go:33-44 |
Bloom filter h2 degenerates to 0 for address/subpath keys |
Annotations
Check failure on line 928 in core/blockchain.go
claude / Claude Code Review
V2-failure fallback recovery cancelled before serial completes
**V2-failure fallback recovery is broken.** When the parallel processor finishes first with an error (e.g., panic, ApplyMessage consensus error), `cancel()` is called before the `if result.parallel && result.err != nil` block, which interrupts the still-running serial processor at its next tx boundary. The fallback `result = <-resultChan` then receives a `context.Canceled` serial result instead of the legitimate recovery — the very recovery the PR description advertises ("falls back to serial on
Check warning on line 420 in core/blockchain.go
claude / Claude Code Review
BlockChain.AblationSkip* fields declared but never read
The four exported `AblationSkip*` fields added to `BlockChain` at core/blockchain.go:417-420 are declared but never read or written anywhere in the repo. As exported fields on a public type they enter the API surface and become a breaking change to remove later, while toggling them today does nothing — the wiring to MVHashMap.Skip* (which is consumed downstream) was lost. Either delete the four fields or thread them through to the V2 processor's MVHashMap on each ProcessBlock call.
Check warning on line 44 in core/blockstm/mvhashmap.go
claude / Claude Code Review
Bloom filter h2 degenerates to 0 for address/subpath keys
Bloom filter `h2` is constant zero for every address-only and subpath key, because `bloomHashes` reads bytes `[20:24]` while `NewAddressKey` and `NewSubpathKey` leave that range zero (only `[0:20]`, `[52]`, and `[53]` are populated). Since subpath keys (`BalancePath`/`NoncePath`) are written for nearly every tx's sender and recipient, the bloom collapses from 3-of-3 to 2-of-3 on the hottest key class, raising the false-positive rate noticeably (~0.07% → 0.35% at ~1k unique keys). No correctness
Loading