EIP-4788: Beacon root in EVM

we can always use the “last” opcode as a pointer to an extension table so in fact there is unlimited opcode address space

a big motivator for the stateful precompile approach is facilitating the migration to a stateless world w/ Verkle tries and stateless clients

having everything required for protocol execution live w/in the execution state means the state transition function can be a function of the pre state and next block, to get the post state; which is cleaner for stateful clients and makes proofs for stateless clients easier to manage

a close analog to the functionality provided in this EIP is the BLOCKHASH opcode which just summons some history alongside the execution state – so now to validate an ethereum block you don’t need just the state but also this small buffer on the side of the last 256 hashes; this makes the stateless paradigm a bit more awkward so its better to design in the direction of 4788

there are even EIPs floating around to change BLOCKHASH so that it follows the pattern of 4788