Pawan Dhananjay

Resolved the conflicts. Would be awesome if we can roll this on some nodes with validators and check that block production works without any hitch 🙏

Thanks for reviewing and fixing up everything Michael ❤️

@varun-doshi sounds good. We basically have to add a new receipts root optional field to the `ExecutionBlockHeader` and `EncodableExecutionBlockHeader` and bubble up all the changes. Let me know if you...

Yep, The `requests_root` needs to be calculated from the`ExecutionPayload's` `deposit_requests`, `withdrawal_requests` and `consolidation_requests` fields. Its specified in the `Block header` section of https://eips.ethereum.org/EIPS/eip-7685

Sorry forgot to post in the issue 😅 I implemented this as part of the electra alpha 8 specs here https://github.com/sigp/lighthouse/commit/27ce1a08d98e2b3ec1b49af03778d214d9854861

Yep, sorry

@Gua00va wrt your question, `ExecutionPayloadRef` is generated by the superstruct macro as a reference to the underlying type. See https://sigp.github.io/superstruct/codegen/ref-and-refmut.html for more info

Not sure if this is ready for review? Its crashing on mainnet with ``` Jun 16 10:40:58.395 CRIT Task panic. This is a bug! location: "/Users/pawan/ethereum/lighthouse/beacon_node/network/src/sync/network_context/block_components_by_range. rs:461:18", msg_id: "TODO: don't...

> Why not use the same strategy for backfill sync too? I don't want to nuke the existing coupled strategy we have got just yet. Also, for backfill, since its...

This one should be ready for another round of review. Used claude to fix up the sync tests, lmk if you wanted a different approach. I don't have strong opinions...