lodestar
lodestar copied to clipboard
ChainSafe
Do early notifyNewPayload call to execution engine
Problem description
As an execution client, Nethermind expects consensus client to call notifyNewPayload as soon as possible.
Solution description
Prysm already does that almost right after they receive gossip block https://github.com/prysmaticlabs/prysm/blob/373c853d17300a0a96e3ceca0ebb77683b6ebc1f/beacon-chain/blockchain/receive_block.go#L105
while lodestar only call notifyNewPayload api after it passes gossip validation, we should be able to do the same to Prysm right after we receive a gossip block. This is expected to improve block time to head which improve attestation performance too.
Additional context
No response
As an execution client, Nethermind expects consensus client to call notifyNewPayload as soon as possible.
Do you mean all EL clients expect new payload as soon as CL client receives a gossip block, or is it only Nethermind?
I might need to look up if other non-prysm clients have this mechanism in place
We only discussed this with Nethermind as they ran tests for which consensus client connected to them was delivering newPayload the fastest. My assumption as that all EL clients should expect this ASAP so they can be fast for attestation but we have purposefully delayed this until after gossip validation whereas Prysm does not. The results showed that Prysm was first in delivering the calls ~75% of the time, Teku second about ~20% of the time and Lighthouse 3rd at ~5% of the time.
this is not as high priority as it seems to be, now the "till become head" depends a lot on how early blob comes since deneb
Some analysis also from today by Nethermind on our attestation metrics without having tried this. If there's no real benefit to experimenting with doing this task now that it's dependent on blob arrivals, we could close this. If the effort is low to see what benefits we might get, it might still be worth trying though. However, will note the lower priority requirement here.
with EIP-7732, we'll execution payload is processed separately from block so we don't need this anymore, closing the issue cc @philknows
see https://eips.ethereum.org/EIPS/eip-7732