Evm parent beacon block root

[mpapierski]

Summary

This PR adds Prague-compatible EIP-4788 beacon-roots support to Casper’s EVM implementation, using Casper-native semantics for the root value:

parentBeaconBlockRoot := parent Casper block hash

The goal is to provide the standard EIP-4788 contract interface and update behavior expected by EVM smart contracts, while mapping the underlying value to a consensus object that exists natively on Casper. This keeps the EVM-facing shape compatible with Ethereum, but the meaning of the stored root is explicitly Casper-specific.

What Changed

This adds the EIP-4788 beacon roots system contract at the standard address:

0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02

The implementation includes:

• EIP-4788 constants and exact runtime bytecode in casper_types::evm.
• Automatic predeploy installation during genesis when EVM Prague is enabled.
• Automatic predeploy upsert during protocol upgrade when EVM Prague is enabled.
• Idempotent repair of missing expected predeploy entries consistent with system contracts behavior.
• A generic EVM system-call execution path using revm::SystemCallEvm.
• A block hook that runs after block globals are written and before user transactions execute.
• The hook runs for every non-genesis Prague/EVM-enabled block, including blocks with no EVM transactions.
• The hook writes the parent Casper block hash into the EIP-4788 ring-buffer contract under the current EVM block timestamp.

The system call is not modeled as a signed transaction. It does not create a user transaction, receipt, fee transfer, or transaction artifact.

Semantics

Ethereum’s EIP-4788 exposes the parent beacon block root to the EVM through a system contract. On Ethereum mainnet, this root is an SSZ beacon-chain consensus root and can be used by contracts to verify beacon-state data.

Casper does not have Ethereum beacon-chain blocks. Instead, this PR uses the parent Casper block hash as the root value. Casper block hashes are consensus-significant and commit to the Casper block header, including parent hash, state root, body hash, timestamp, era data, protocol version, proposer, gas price, and related fields.

So this implementation is interface-compatible with EIP-4788, but not semantically identical to Ethereum mainnet.

For dApp developers, this means contracts can use the standard EIP-4788 lookup flow and sidecar JSON-RPC can project parentBeaconBlockRoot to the same parent Casper block hash, so on-chain reads and eth_getBlockByNumber agree. Applications that only need a recent consensus-root oracle should work against the standard interface; applications that specifically verify Ethereum beacon-chain data must treat this as Casper-specific semantics.

Why This Approach

This gives EVM contracts a deterministic, protocol-maintained consensus-root oracle without adding a new Casper block-header field.

Compared with other EVM L1s, this sits between strict adoption and omission. Chains with Ethereum-like consensus, such as Gnosis, can implement EIP-4788 unchanged. Beacon-style EVM L1s such as Berachain/BeaconKit map native consensus data into the Ethereum execution interface. Chains without a beacon-chain analogue often skip or neutralize the feature, for example Polygon PoS, BSC, or Avalanche’s zero-valued ParentBeaconRoot compatibility field in ACP-131. Casper keeps the standard contract interface instead of omitting it, but makes the root meaningful for Casper consensus rather than pretending to expose Ethereum beacon state.

Pros

• Preserves the standard EIP-4788 address and contract interface.
• Lets EVM contracts read a protocol-maintained parent-root value by timestamp.
• Avoids a new Casper block-header field.
• Works for blocks with no EVM transactions.
• Uses revm’s intended system-call path instead of a fake signed transaction.
• Activation is automatic and idempotent at genesis/protocol upgrade.
• Provides a useful Casper consensus-root oracle for future proof and verifier work.

Tradeoffs Compared to Ethereum

• The stored value is not an Ethereum beacon block root.
• Contracts expecting Ethereum SSZ beacon-state proofs will not work unchanged.
• This is "EIP-4788 interface compatibility” not full Ethereum beacon semantics.
• Proof systems need Casper-specific header/state proof support rather than Ethereum beacon proofs.
• Multiple Casper blocks in the same second follow the EIP-4788 contract’s normal timestamp overwrite behavior.
• The semantic difference should be clearly documented for dapp developers.