Gloas add process_payload_attestation

[shane-moore]

Changes per spec

• Added:
  • process_payload_attestation
    • get_indexed_payload_attestation
    • is_valid_indexed_payload_attestation
  • get_ptc
    • compute_balance_weighted_selection
    • compute_balance_weighted_acceptance
• Modified:
  • compute_proposer_indices
  • get_next_sync_committee_indices
  • process_operations

How This Works

CL blocks will now contain payload attestations that are collected from PTC members from the previous slot. The payload attestations indicate whether the payload envelope and blobs arrived by the PTC deadline. During block processing, we will now check over the payload attestations to ensure they're valid. Hence, this PR introduces process_payload_attestation to do just that.

Since a payload attestation to validate includes a Bitvector of size PTC_SIZE, we need to map each 1 bit to the ptc committee member from the previous slot in order to validate their signatures. This is accomplished via introducing or modifying the helpers listed above.

@ethDreamer

[ethDreamer]

Since this is called in a loop, I wonder if it would be worth while to get the effective balance from the epoch cache rather than fetching it each time? To do that, you'd have to ensure the epoch cache is initialized. You could look into this or you could leave a TODO here for later.

[shane-moore]

Analysis:
The epoch cache is a singleton per each BeaconState instance. It gets initialized anytime we have a state transition as to ensure we're always getting fresh validator balances. A few places it's initialized:

• start of every per block processing
• start of every per epoch processing
• build_all_caches when loading state from disk
• during block production's produce_partial_beacon_block

compute_balance_weighted_acceptance is nested in compute_balance_weighted_selection, which will be called post-gloas by:

• compute_proposer_indices (11 call sites)
• get_next_sync_committee_indices (4 call sites)
• get_ptc (1 so far)

since cargo nextest run isn't applicable to gloas yet, we can't simply try to use epoch cache to get validator balances during compute_balance_weighted_acceptance and see what fails, so I think a TODO is the right approach for now. I'm open to other ideas as well. From investigating a few call sites of compute_proposer_indices, it seems there's a few places we'd need to initialize the epoch cache for this optimization to work.

add todo in fab18e7. lmk if is all good!

[ethDreamer]

looks good to me!

[ethDreamer]

you may need to rebase this against the latest gloas-envelope-processing branch @shane-moore

[shane-moore]

@ethDreamer, rebased! should be all set