Generating state pre-images with Erigon Unlike some other clients, Erigon actually stores the plain-state (or pre-images of keys) of the state. The MPT root calculation takes places in a different stage of block execution/processing. So, once an erigon node is synced, it's database can be used to generate and export a file containing these pre-images in a sorted order. This order will, thus, coincide with the order of keys in the MPT APPROACH 1 While walking over all the entries in the table called PlainState, do: If the key (which is also the account address) doesn't have any storage slots, push it to the ETL collector, as is, with {key: hash(acc), val: acc} If the key has storage slots, push the storage slots of the account in the same ETL collector, each with {key: hash(acc) + hash(storage_slot_i), val: storage_slot_i}

For Erigon-2, Go to branch release/2.61 or pectra_e2 make evm Go to the eip-2537-evm-benchmarks repo directory, then run GETH_EVM=/home/somnath/Documents/code/erigon1/build/bin/evm ./benchmark_all.sh Running the individual commands within the benchmark shell scripts:- GETH_EVM=/home/somnath/Documents/code/erigon1/build/bin/evm --codefile bytecodes/bench-one.hex --inputfile benchmark_inputs/g1msm28.hex --prestate ./genesis.json --bench run

Thoughts about Splitting the Pectra Fork in Two Initially, the Pectra fork was meant to be relatively small. However, it is widely agreed upon that there is no such thing as a small fork. This is because inclusion of various EIPs warrants a lot of efforts in terms of development, testing and security discussions. Yet, we often fill the time till the fork with more discussions and possible inclusion of dangling EIPs. For Pectra, a few notable EIPs were included, like the EL-CL requests interface, new transactions supporting code, BLS precompiles, and the pre-verkle storage history modifications. We have already spent 3 devnets in ironing out issues with the included EIPs, and naturally coordinating testing of these simple implementations is still a significant task. Down the line, however, we also decided to include PeerDAS and EOF into the Pectra fork. From my perspective it does make sense for a large change like EOF to be included before Verkle, lest it loses momentum. When almost all client teams agreed to go forth with EOF, however, we certainly lost the smallness of the Pectra fork. The discussion is now pivoting towards breaking down Pectra into two forks, let's say Pectra-1 and Pectra-2. On the surface it makes sense to ship unrelated EIPs in different fork parts. This could potentially let us focus on some of the EIPs first and then move on to the others. A great example of how we may achieve this is by postponing EOF and PeerDAS to the second split and shipping the rest in the first split. This does inherently add a few extra months before the next fork (Verkle) could happen.