You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Computing attestation aggregation currently takes at least 200ms on holesky node.
We could implement a strategy to trigger the aggregation in parallel with the block production flow.
there is a spike PR #9122 demonstrating it could save us time during block production.
In that PR description I reported some thoughts.
The main benefits will be to parallelize head processing (preparation_process_head step) with attestations aggregation (which happens in beacon_block_prepared), by optimistically passing the state from our current head (processed into the next slot), making sure to rerun the aggregation again if, during the actual block preparation we selected a "compatible" state.
The "compatibility" boils down to shuffling\committeeSizes compatibility and isValid compatibility (no differences in AttestationDataValidator checks).
We could wait Pectra activation to see aggregation timings and evaluate if it is worthy going down to this path.
The text was updated successfully, but these errors were encountered:
Computing attestation aggregation currently takes at least 200ms on holesky node.
We could implement a strategy to trigger the aggregation in parallel with the block production flow.
there is a spike PR #9122 demonstrating it could save us time during block production.
In that PR description I reported some thoughts.
Slow Block Production *** Slot: 3635966 start 1ms, preparation_on_tick +0ms, preparation_apply_deferred_attestations +0ms, preparation_process_head +337ms, retrieve_state +3ms, beacon_block_prepared +362ms, local_get_payload +16ms, beacon_block_created +1ms, state_transition +230ms, state_hashing +18ms, complete +0ms total: 967ms
The main benefits will be to parallelize head processing (
preparation_process_head
step) with attestations aggregation (which happens inbeacon_block_prepared
), by optimistically passing the state from our current head (processed into the next slot), making sure to rerun the aggregation again if, during the actual block preparation we selected a "compatible" state.The "compatibility" boils down to shuffling\committeeSizes compatibility and
isValid
compatibility (no differences inAttestationDataValidator
checks).We could wait Pectra activation to see aggregation timings and evaluate if it is worthy going down to this path.
The text was updated successfully, but these errors were encountered: