Merge discussion and todos from #2257

[djrtwo]

trafficstars

#2257 got the basic merge spec to a solid footing. The following are the list of discussion points and todos that were not completed within the context of that PR. These are left for future work and discussion.

Note: This is not an exhaustive merge todo list but is instead only open points from #2257

• [x] Debates around application_state_transition (should the spec know about the ApplicationState or just about its root hash)
• [ ] Consider eliminating uint256 requirement on beacon-chain side in PoWBlock and TD comparison
• [ ] Consider max block size in relation to ApplicationPayload and where should such validation happen. At gossip, inside beacon chain, or just in application gas limit. Max TX size times max txs is 16GB!
• [X] Consider Union type for transaction list with a single OPAQUE_SELECTOR for first merge fork. More specific, structured selectors for each TX type to follow
• [x] Post-London add base_fee to ApplicationPayload
• [x] Add Hash32 type to provide more specificity than Bytes32 and to further disambiguate from Root
• [ ] Modularize components of fork choice in phase 0 to better facilitate code reuse https://github.com/ethereum/eth2.0-specs/pull/2257#discussion_r599015500
• [ ] Potentially rename Eth1Data -- DepostContractData
• [x] Consider adding fields to block to ensure there is a clean one-way map from ApplicationPayload to RLP block

[vbuterin]

I would also say consider adding some fields back in despite the redundancy. Particularly, adding the block prevhash back in to the ApplicationPayload seems like it could easily do more good than harm around the transition and generally.

It feels like there's important simplifications that can come from making sure that there is a clean pure one-way map from ApplicationPayload to an RLP block.

[mkalinin]

PR addressing additional fields in ApplicationPayload, https://github.com/ethereum/eth2.0-specs/pull/2295

[vshvsh]

Can we pipe becon chain block roots to eth1x as well? Would be very useful for applications that depend on beacon chain, like staking pools, which are forced to use oracle these days.

[mcdee]

Can we pipe becon chain block roots to eth1x as well? Would be very useful for applications that depend on beacon chain, like staking pools, which are forced to use oracle these days.

The beacon state root would be a useful addition, not sure that individual block roots would gain anything.

[mkalinin]

There is a plan to introduce BEACONBLOCKROOT opcode after the Merge. Exposing block roots allows for reading data from either a block or a state.

[mkalinin]

(4) Addressed in https://github.com/ethereum/eth2.0-specs/pull/2472