Skip to content

Remove support for pre-cancun blocks, simplify storage logic - #4575

Open
cody-littley wants to merge 1 commit into
mainfrom
cjl/cancun
Open

cody-littley wants to merge 1 commit into
mainfrom
cjl/cancun

Conversation

@cody-littley

Copy link
Copy Markdown
Contributor

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).

@cursor

cursor Bot commented Oct 20, 2026 •

Copy link
Copy Markdown

PR Summary

High Risk
Mandating Cancun+ breaks older chain configs, and removing store-backed storage prefix clears changes how self-destruct and unread slots persist—app hashes and state commits must stay consistent across restarts.

Overview
Drops StorageClears from the block StateChangeSet and commits storage only via explicit per-slot Storage updates/deletes. FlatKV encoding no longer takes a CommitStore or scans the live store to expand prefix clears (removing a DoS-prone iterator); callers use NewFlatKVChangeSetEncoder() with no arguments. The same model is applied to MemoryStore, OCC merge/overlay logic, and docs/tests that previously required clear-before-storage ordering.

Tightens block validity to post-Cancun only: validateBlockContext rejects pre-Cancun blocks (errPreCancunBlock) and always requires BaseFee and BlobBaseFee, replacing fork-conditional London/Cancun checks. Legacy pre-Cancun self-destruct / storage-clear tests and legacySelfDestructChainConfig helpers are removed; pipeline and self-destruct tests now expect storage to remain unless slots are written.

Pipeline encoding no longer waits for the prior commit when changesets only contained storage clears; encodingReadsTheStore depends solely on whether the optional block changeset encoder reads the store. App-hash golden vectors in sei-tendermint are updated to match the new changeset shape.

Reviewed by Cursor Bugbot for commit 055b3ed. Bugbot is set up for automated code reviews on this repo. Configure here.

@github-actions

Copy link
Copy Markdown

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedOct 20, 2026, 5:16 PM

@codecov

codecov Bot commented Oct 20, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.74%. Comparing base (efc8585) to head (055b3ed).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            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              
Flag Coverage Δ
sei-chain 55.79% <100.00%> (+0.07%) ⬆️
sei-db 75.17% <ø> (ø)
sei-db-state-db 80.18% <100.00%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
giga/evmonly/cmd/evmonly-loadtest/pipeline.go 78.94% <100.00%> (-0.30%) ⬇️
giga/evmonly/executor.go 89.58% <100.00%> (ø)
giga/evmonly/flatkv_changeset.go 96.29% <100.00%> (+4.62%) ⬆️
giga/evmonly/giga_store.go 85.61% <100.00%> (-1.37%) ⬇️
giga/evmonly/memory_store.go 88.36% <100.00%> (+0.29%) ⬆️
giga/evmonly/occ.go 92.08% <100.00%> (-0.04%) ⬇️
giga/evmonly/occ_shards.go 93.47% <100.00%> (-0.14%) ⬇️
giga/evmonly/pipeline_overlay.go 91.37% <ø> (-0.69%) ⬇️
giga/evmonly/state.go 91.25% <ø> (-1.53%) ⬇️
giga/evmonly/state_db.go 91.90% <100.00%> (-0.07%) ⬇️
... and 2 more

... and 52 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@seidroid seidroid Bot left a comment •

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread giga/evmonly/state_db.go
}
priorValue = s.baseState(addr, key)
} else if priorValue == newValue {
if priorValue == newValue {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 shemnon left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 alrevuelta left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants