[Feature]: implement eip-2935

[yihuang]

Summary

EIP-2935 is a new feature introduced in Prague hardfork to save historical block hash into state, see: https://eips.ethereum.org/EIPS/eip-2935, it provides an alternative way to query historical block hash than the BLOCKHASH opcode.

Problem Definition

No response

Proposed Feature

Right now, cosmos EVM has a historical block hash issue, see: #235, EIP-2935 can be an alternative way to solve it.

EIP-2935 itself don't fix the BLOCKHASH opcode itself, it expects users to migrate away from that opcode to query the system contract directly.

But we can change the GetHashFn to query this contract storage to serve the historical block hash in the BLOCKHASH opcode, and avoid duplicated storage (see #236).

Work Breakdown

#### Must have
- [ ] discuss proposal (if proposal rejected, close EPIC)
- [ ] create ADR (if ADR rejected, close EPIC)
- [ ] add sub-tasks needed to implement the proposed feature

#### Nice to have
- [ ] add sub-tasks that are nice to have for the proposed feature

[linear]

EVM-190 [Feature]: implement eip-2935

[zsystm]

@yihuang

Hi! Thanks for raising this issue.

As far as I understand, EIP-2935 is primarily motivated by the need to support stateless clients or applications requiring access to block hashes beyond the standard 256-block window.

At the moment, Cosmos/EVM doesn’t natively target stateless execution or Verkle tree support, and we haven’t seen strong demand from dApps that rely on deeper historical block hashes via contract calls. Given that, we haven’t prioritized implementing this system contract yet.

That said, it’d be super helpful if you could share more about why you think EIP-2935 is important in your use case.

• Are you working on a zk or rollup-related project that needs this data?
• Do you need extended history access for some on-chain proof or oracle logic?

Understanding the context would help us evaluate whether this is something we should consider adding sooner rather than later.

Thanks again!

cc: @vladjdk @cloudgray

[yihuang]

The main reason is that blockhash opcode is already broken (see #235), so the idea is that we can directly do this, and fix blockhash opcode at the same time.