ePBS Annotated Validator Spec

Validator assignment

PTC assignment

This section explains how a validator determines whether it performs PTC duty in the current or next epoch. Similar to determining if it is responsible for submitting beacon attestations during a slot across an epoch, PTC attestation is a subset type where the PTC committee is selected by choosing a few validators from the end of each beacon attestation committee.

def get_ptc(state: BeaconState, slot: Slot) -> Vector[ValidatorIndex, PTC_SIZE]:
    """
    Get the ptc committee for the given ``slot``
    """
    epoch = compute_epoch_at_slot(slot)
    committees_per_slot = bit_floor(min(get_committee_count_per_slot(state, epoch), PTC_SIZE))
    members_per_committee = PTC_SIZE // committees_per_slot
    
    validator_indices = [] 
    for idx in range(committees_per_slot):
        beacon_committee = get_beacon_committee(state, slot, idx)
        validator_indices += beacon_committee[:members_per_committee]
    return validator_indices

Retrieving the assignment utilizing get_ptc through requested epoch and validator_index parameters. If the validator exists in the PTC then return the assignment slot is returned otherwise, false is returned. get_ptc_assignment should be called at the start of each epoch to get the assignment for the current and next epoch (current_epoch + 1). A validator should plan for future assignments by noting their assigned PTC committee slot and planning to participate in the PTC gossip subnet.

def get_ptc_assignment(state: BeaconState,
                             epoch: Epoch,
                             validator_index: ValidatorIndex
                             ) -> Optional[Slot]:
    """
    Returns the slot during the requested epoch in which the validator with index `validator_index`
    is a member of the PTC. Returns None if no assignment is found. 
    """
    next_epoch = Epoch(get_current_epoch(state) + 1)
    assert epoch <= next_epoch

    start_slot = compute_start_slot_at_epoch(epoch)
    for slot in range(start_slot, start_slot + SLOTS_PER_EPOCH):
            if validator_index in get_ptc(state, Slot(slot)):
                return Slot(slot)
    return None

Beacon attesters and sync committee

Given intervals_per_slot modified from 3 to 4, beacon attesters and sync committee timing moved from 4s into the slot to 3s into the slot.

Beacon chain responsibilities

This section explains validator duty changes under ePBS. We'll divide them into the following subsections

1. Modified: proposer block duty
2. New: proposer inclusion list duty
3. New: PTC attester duty

Proposer block duty

At the beginning of the slot, the proposer assigned for that slot prepares and broadcasts a SignedBeaconBlock. The high-level modifications are as follows:

• Instead of including an ExecutionPayload on block body, the validator includes SignedExecutionPayloadHeader in the block body. The details of how to obtain the header is outside the scope of this document. A proposer can obtain the header through local buildings, p2p gossip networks, or other avenues like the builder's RPC ports. Strategies for dealing with the header will be discussed in the following proposer block header selection section.
• BlobSidecars is no longer part of the block body. This duty is transferred to the builders.
• PayloadAttestation is added to the block body. It consists of the aggregate of the PayloadAttestationData. The strategy for honest aggregation will be defined in the PTC attestation aggregation section.

Proposer block header selection

The proposer selects the SignedExecutionPayloadHeader to be included in the block. The header can be trusted by the local EL client or untrusted by P2P network or builder RPC interface.
If the header comes from a trusted source, the proposer can include it as is and broadcast both SignedBeaconBlock and SignedExecutionPayloadEnvelope in the respective gossip nets simultaneously.
If the header is coming from an untrusted source, the proposer should verify the header is valid before including it in their block. The header must pass the validation steps outlined in process_execution_payload_header, which are:

def validate_execution_payload_header(state: BeaconState, signed_header: `SignedExecutionPayloadHeader`) -> None:
	assert verify_execution_payload_header_signature(state, signed_header)
    # Check that the builder has funds to cover the bid
    header = signed_header.message
    builder_index = header.builder_index
    amount = header.value
    assert state.balances[builder_index] >= amount

    # Verify that the bid is for the current slot
    assert header.slot == block.slot
    # Verify that the bid is for the right parent block
    assert header.parent_block_hash == state.latest_block_hash
    assert header.parent_block_root == block.parent_root

If the header is sourced from a p2p network, the p2p gossip validation pipeline has likely already performed the necessary checks, so there is no need to validate it again. However, if the header is obtained through builder RPC, the check should be performed separately to ensure its validity before inclusion in the block.

Proposer PTC attestation aggregation

The proposer aggregates recently verified PayloadAttestationMessage into PayloadAttestation for inclusion in the block body. Up to MAX_PAYLOAD_ATTESTATIONS can be included. The honest PTC selection and aggregation strategy are defined as follows:

• Advance head state state to the proposal slot.
• The proposer retrieves all PayloadAttestationMessage from the local mempool where data.slot + 1 == state.slot. It is assumed that the PTC attestations have been verified as they came through the P2P gossip network.
• The proposer determines which payload_status to include by checking if the payload was supposed to be present in the previous slot using state.latest_full_slot == slot - 1. If the payload was supposed to be present, it filters for PayloadAttestationMessage where data.payload_status == PAYLOAD_PRESENT. If the payload is not supposed to be present, it filters for data.payload_status == PAYLOAD_ABSENT || data.payload_status == PAYLOAD_WITHHELD.
• The proposer now has all the payload attestations that satisfy the slot and payload status requirements. It aggregates these attestations similarly to how beacon attestations are aggregated. It fills the payload_attestation.aggregation_bit s field using the relative position of the validator indices with respect to the PTC obtained from `get_ptc(state, slot—1)``.
• Finally, the proposer fills the payload_attestation.signature field with the aggregated signature and includes it in the beacon block.

Note:

1. Including a payload status that diverges from the canonical chain's view will result in the proposer being penalized by 2*proposer_penalty_numerator // proposer_reward_denominator per PTC attestation.
2. In the beacon chain's state transition, the payload attestation processing function will unset the flags if they were set by an equivocating PTC attestation. The justification for this approach is that there are no slashing conditions for equivocations on the PTC attestations. Attesters are incentivized to submit both PAYLOAD_PRESENT and PAYLOAD_ABSENT attestations, and proposers are incentivized to include both, allowing them to be rewarded in either case.

PTC attestation duty

Suppose the attester is part of the PTC, as determined by get_ptc_assignment for your validator index in any of the slots of the current or next epoch. In that case, the PTC attester should prepare and broadcast a PayloadAttestationMessage at the SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT mark of the slot. The PayloadAttestationData includes the beacon_block_root, which is the block root of the current slot, and the slot, which refers to the current slot. The payload_status is defined as follows.

Consensus block status	Execution payload status	Payload status
seen	on time	PAYLOAD_PRESENT
seen	late	PAYLOAD_ABSENT
seen	withhold	PAYLOAD_WITHHOLD
late	on time	PAYLOAD_PRESENT
late	late	PAYLOAD_ABSENT
late	withhold	PAYLOAD_WITHHOLD
skipped	skipped	do nothing

Assuming you have PayloadAttestationData, you can construct a PayloadAttestationMessage by signing over the PayloadAttestationData. Then, input validator_index as your index and signature as the result of the get_payload_attestation_data_signature.

def get_payload_attestation_data_signature(state: BeaconState, data: PayloadAttestationData, privkey: int) -> BLSSignature:
    domain = get_domain(state, DOMAIN_PTC_ATTESTER, compute_epoch_at_slot(data.slot))
    signing_root = compute_signing_root(data, domain)
    return bls.Sign(privkey, signing_root)

No change to attester duty

If the validator, assumed to be an attester of a slot, is also part of the PTC, one might argue that attester duty can be skipped since the reward will not be counted. However, for implementation simplicity, it is recommended to just gossip the attestation anyway, as there is no penalty, and signing and verifying the signatures are inexpensive. The benefit is that the attestation's fork choice weight remains useful over P2P.