Note that removing any “implied” components of the state transition is certainly favorable for an eth1+eth2 integration because any implied historic components put additional requirements on the data that a rapidly changing committee must retrieve from the network.
Copied from Eth1+eth2 client relationship thread:
You’re right. I wasn’t aware of this implied component of the eth1 state transition. Assuming we don’t integrate the headers into state (I think doing so is a good idea), the beacon committees would need to sync forward from the latest crosslink in state and back-fill headers (and computed roots) to have the 256 block hashes on demand. It’s doable but puts more bandwidth overhead on the rapidly changing beacon committees.
We’ve been careful with the eth2 state transition function to ensure it is a pure function of
(pre_state, block)and not have any implied requirements. Ensure that eth1x stateless blocks are just a function of the block would make this integration much more elegant