This strongly resonates with me. I also wonder.
Some historical context, this approach was once suggested for blockhash, with EIP-210: Blockhash refactoring
@axic already posted that link, however, I think that was early in the discussion, when the beacon root EIP also included an opcode? Later on, the opcode was dropped, and the EIP is now in a situation where it could be replaced by:
- A contract
X - A system-call to
X, invoking it with the latest beaconroot+number at the start of block processing.
The contract X would store new values if the sender is system-address, otherwise respond with the value requested (as per the pseudo-code in the current version of the EIP).
The address of X could either be pre-determined, like a precompile, or we could just create it with CREATE2 in advance – before the hardfork, and then just ‘bless it’ at cancun by beginning the population of values (optional: the ‘blessing’ could also include auto-inclusion into the prepopulated access-list).
In that case, the core of the EIP would basically be:
At the start of processing any execution block where
block.timestamp >= FORK_TIMESTAMP(i.e. before processing any transactions), make a transaction to theHISTORY_STORAGE_ADDRESS, with calldataBEACONROOT, senderSYSTEM_SENDERand gas100_000.
The internals of what the contract does would not be consensus-critical (any more than other contract internals)