I have some questions regarding this EIP.
set 32 bytes of the execution block header after the last header field as of
FORK_TIMESTAMPto the 32 byte hash tree root of the parent beacon block
I am not sure how to interpret this. Does this imply that we add a new field to the block header after the last header field (such that we RLP encode this)? Or, do we first RLP-encode the block header and then add these 32 bytes…?
The new precompile (which it definitely is, since it does do some EVM behavior like SLOAD, but will not add these to warm slots to account for them) is located at 0xfffffffffffffffffffffffffffffffffffffffd. Why here? Why not in the precompile range 0x00..00 - 0x00..00ffff (see EIP-1352: Specify restricted address range for precompiles/system contracts, it is stagnant, but I was under the impression that those “low” addresses were indeed reserved for precompiles). I am mainly worried about RIPEMD160 scenarios (Clarification about when touchedness is reverted during state clearance · Issue #716 · ethereum/EIPs · GitHub). We can fix this on mainnet by sending 1 wei to this precompile (currently it has no eth). However since usually genesis files on testnets fill the precompiles in order to avoid this RIPEMD160 behavior, this 0xfffffffffffffffffffffffffffffffffffffffd address is not there. Is there a motivation to put this there, and not at a “low” address?