Repository navigation
Remove support for pre-cancun blocks, simplify storage logic - #4575
cody-littley wants to merge 1 commit into
Conversation
PR SummaryHigh Risk Overview Tightens block validity to post-Cancun only: Pipeline encoding no longer waits for the prior commit when changesets only contained storage clears; Reviewed by Cursor Bugbot for commit 055b3ed. Bugbot is set up for automated code reviews on this repo. Configure here. |
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4575 +/- ##
==========================================
+ Coverage 57.66% 57.74% +0.07%
==========================================
Files 2137 2116 -21
Lines 167636 166938 -698
==========================================
- Hits 96675 96392 -283
+ Misses 70956 70541 -415
Partials 5 5
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
This PR makes the giga EVM-only executor reject pre-Cancun blocks and removes StorageClears from the changeset, the FlatKV encoder, the memory store, the OCC merge and the pipeline overlay, which also drops the store iterator from encoding. Under EIP-6780 a storage clear can only hit a contract created in the same transaction, the callers of validateBlockContext all pass a non-nil config, and no references to the removed symbols are left, so nothing blocks; codex's reading found nothing, which agrees with the absence of blockers, and it contributed no findings to keep or drop.
Non-blocking
1 finding on the changed lines, as inline comments.
Pre-existing
Already true on the base branch, not introduced here.
- suggestion — In giga/evmonly/state_db.go, nativeStateDB.GetStorageRoot always returns common.Hash{}, so go-ethereum's create-collision check never catches an address that has storage but no code or nonce (EIP-7610). A CREATE2 onto such an address succeeds and inherits its stale storage.
seidroid review · decision approve · session 7e73cf0d60f0435d9f8bb5c8b3a9ecbb · turn resp_claude_317d042f7b29259407702d3e724ab2dc · item fb6da05c4d92525c99a509b338facfa0
Findings: 0 blocking | 1 non-blocking | 1 posted inline | 1 pre-existing
| } | ||
| priorValue = s.baseState(addr, key) | ||
| } else if priorValue == newValue { | ||
| if priorValue == newValue { |
There was a problem hiding this comment.
suggestion — nativeStateDB still models a clear in memory: Finalise sets StorageCleared on a self-destruct, and committedState and the slot loader then read zero. But nothing persists that clear any more, and blockSTMState no longer tracks one either. This is only sound if a contract created in the same transaction always has empty persisted storage, and that depends on EIP-7610, which GetStorageRoot defeats by always returning the zero hash. For a codeless, zero-nonce address that already holds storage (for example from a generated genesis), the slots would read as zero for the rest of the block in sequential execution, while OCC reads and later blocks see the old values. Consider either having GetStorageRoot report non-empty storage, so CREATE fails with a collision as in geth, or dropping or asserting the StorageCleared read path, so in-block and persisted reads cannot disagree.
shemnon
left a comment
There was a problem hiding this comment.
We should fix the correction seidroid pointed out here while we are adjusting base assumptions,
suggestion — In giga/evmonly/state_db.go, nativeStateDB.GetStorageRoot always returns common.Hash{}, so go-ethereum's create-collision check never catches an address that has storage but no code or nonce (EIP-7610). A CREATE2 onto such an address succeeds and inherits its stale storage.
While it should be impossible that is no guarantee of future behavior, we should address it now.
alrevuelta
left a comment
There was a problem hiding this comment.
lgtm, but i would address the bot issue.
in a very weird case occ and sequential execution can diverge. this only happens if the account has storage slot set but no nonce/code. in theory it cant happen, but if we start adding precompiles where contracts can have slots and no code, it can in theory happen.
This PR removes support for pre-cancun blocks from the giga EVM only executor. As a result, we can simplify the storage layer (and drop use of a dangerous iterator that is a DOS vector).