Forking mainnet with createMemoryClient returns the wrong genesis block hash

[gnidan]

The following jest test fails with the wrong block hash for mainnet's genesis block:

import { expect, it } from "@jest/globals";
import { http } from "viem";
import { createMemoryClient } from "tevm";
import { mainnet } from "tevm/common";

// obviously change this
const mainnetUrl = "http://erigon.dappnode:8545";

it("forks correctly", async () => {
  const client = createMemoryClient({
    fork: { transport: http(mainnetUrl)({}) },
    common: mainnet
  });

  // @ts-ignore
  const tevmBlock = await client.request({
    method: "eth_getBlockByNumber",
    params: ["0x00"]
  });

  expect(tevmBlock.hash)
    .toEqual("0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3");
});

The result I'm getting is "0xeff8054e319d68b09a444777360ba5d400372488a05cabc30d851b3d987b90d3", which is not the actual genesis block

[linear]

TEV-1349 Forking mainnet with `createMemoryClient` returns the wrong block hash

[roninjin10]

This is expected because the mainnet common uses latest mainnet hardforks and eips. We enable EIPs 4844 and 1559 by default. For this reason tevm isn't gonna provide 100% fidelity on historical blocks and is more optimized for recent blocks.

Ethereumjs supports switching eip and hardfork based on block number but the code to do so is problematic with regard to tree shaking so when tevm adds support it will be optional and look different

This issue is very low on the priority list so gonna add a "looking for help" label

[roninjin10]

Looks like foundry just uses fork as source of truth for block hash for past blocks but otherwise isn't doing anything to keep hash correct. I'm not seeing anything that sets the EVM and uses the fork as source of truth on pre fork json rpc requests like eth_call.

Using the fork as source of truth even for computed values like blockHash feels like an easy fix and a good one. Will make a ForkedBlock class for this.

I also think adding a passThrough: true option that will do this behavior of using forked chain as source of truth whenever possible is a good compromise if hardfork during execution matters too for methods like eth_call.

[roninjin10]

Closing in favor of #1360