EVM: Store EIP-4788 history in block-global state#5430
Open
mpapierski wants to merge 2 commits into
Open
Conversation
Replace beacon-roots system calls with atomic ring-buffer writes through TrackingCopyExt. Handle direct CALL and STATICCALL lookups natively while preserving bytecode for EXTCODE, DELEGATECALL, and CALLCODE semantics. Move EIP-4788 helpers to casper-storage and retain legacy key encoding.
mpapierski
requested review from
EdHastingsCasperAssociation,
darthsiroftardis and
zajko
July 17, 2026 12:53
EdHastingsCasperAssociation
approved these changes
Jul 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR replaces repeated EIP-4788 bytecode execution with a native, Global State-backed implementation.
Previously, each block executed the beacon-roots contract to update its EVM storage, and every lookup executed the deployed bytecode and performed storage reads. We now write the parent block hash directly into a fixed-size ring buffer in Casper Global State and serve canonical calls through the EVM precompile handler.
What changed
A new
BlockGlobalAddr::BlockParentHash { slot }key stores an atomic(timestamp, block_hash)tuple. The slot is derived using the EIP-4788 rule:The write occurs at the same pre-transaction point as the previous EVM system call and uses the same parent hash. Casper’s millisecond block timestamp is converted to EVM seconds before deriving the slot.
Direct
CALLandSTATICCALLoperations to the EIP-4788 address are handled natively. The implementation:u64.The lookup does not use locally retained block history, so full-history and fast-synced nodes execute against the same Merkleized Global State.
Preserving EVM behavior
The EIP-4788 bytecode and code hash remain deployed for
EXTCODE*compatibility.Only calls that use the predeploy’s own storage context are intercepted.
DELEGATECALLandCALLCODEcontinue to execute the deployed bytecode because they run it against the caller’s storage context. Replacing those calls with the native Global State lookup would change normal EVM semantics.Crate ownership and compatibility
EIP-specific constants, bytecode, hashing, slot derivation, and tuple encoding now live in
casper-storage.casper-typesretains only the generic block-global key representation.Existing
BlockGlobalAddrandKey::BlockGlobalencodings remain backward compatible. Legacy block-global addresses are still one byte, and existing block-global keys remain 33 bytes.Gas behavior
The native lookup charges no additional interpreted-bytecode or
SLOADgas. Ordinary call and address-access costs still apply, and the address is not initially warmed.Activation
This change assumes activation before a network has populated the old EIP-4788 contract-storage ring. If that assumption does not hold, the existing bounded ring must be migrated during activation.
Testing
Coverage includes: