EIP-7732 -- Honest Validator¶
Note: This document is a work-in-progress for researchers and implementers.
- Introduction
- Validator assignment
- Lookahead
- Beacon chain responsibilities
- Attestation
- Sync Committee participations
- Block proposal
- Payload timeliness attestation
- Modified functions
- Modified
prepare_execution_payload
Introduction¶
This document represents the changes and additions to the Honest validator guide included in the EIP-7732 fork.
Validator assignment¶
A validator may be a member of the new Payload Timeliness Committee (PTC) for a
given slot. To check for PTC assignments the validator uses the helper
get_ptc_assignment(state, epoch, validator_index)
where epoch <= next_epoch
.
PTC committee selection is only stable within the context of the current and next epoch.
Lookahead¶
[New in EIP7732]
get_ptc_assignment
should be called at the start of each epoch to get the
assignment for the next epoch (current_epoch + 1
). A validator should plan for
future assignments by noting their assigned PTC slot.
Beacon chain responsibilities¶
All validator responsibilities remain unchanged other than the following:
- Proposers are no longer required to broadcast
BlobSidecar
objects, as this becomes a builder's duty. - Some validators are selected per slot to become PTC members, these validators
must broadcast
PayloadAttestationMessage
objects during the assigned slot before the deadline of3 * SECONDS_PER_SLOT // INTERVALS_PER_SLOT
seconds into the slot.
Attestation¶
The attestation deadline is implicitly changed by the change in
INTERVALS_PER_SLOT
. Moreover, the attestation.data.index
field is now used
to signal the payload status of the block being attested to
(attestation.data.beacon_block_root
). With the alias
data = attestation.data
, the validator should set this field as follows:
- If
block.slot == current_slot
(i.e.,data.slot
), then always setdata.index = 0
. - Otherwise, set
data.index
based on the payload status in the validator's fork-choice: - Set
data.index = 0
to signal that the payload is not present in the canonical chain (payload status isEMPTY
in the fork-choice). - Set
data.index = 1
to signal that the payload is present in the canonical chain (payload status isFULL
in the fork-choice).
Sync Committee participations¶
Sync committee duties are not changed for validators, however the submission
deadline is implicitly changed by the change in INTERVALS_PER_SLOT
.
Block proposal¶
Validators are still expected to propose SignedBeaconBlock
at the beginning of
any slot during which is_proposer(state, validator_index)
returns true
. The
mechanism to prepare this beacon block and related sidecars differs from
previous forks as follows
Constructing the new signed_execution_payload_header
field in BeaconBlockBody
¶
To obtain signed_execution_payload_header
, a block proposer building a block
on top of a state
must take the following actions:
- Listen to the
execution_payload_header
gossip global topic and save an acceptedsigned_execution_payload_header
from a builder. Proposer MAY obtain these signed messages by other off-protocol means. - The
signed_execution_payload_header
must satisfy the verification conditions found inprocess_execution_payload_header
, that is - The header signature must be valid
- The builder balance can cover the header value
- The header slot is for the proposal block slot
- The header parent block hash equals the state's
latest_block_hash
. - The header parent block root equals the current block's
parent_root
. - Select one bid and set
body.signed_execution_payload_header = signed_execution_payload_header
Constructing the new payload_attestations
field in BeaconBlockBody
¶
Up to MAX_PAYLOAD_ATTESTATIONS
, aggregate payload attestations can be included
in the block. The validator will have to
- Listen to the
payload_attestation_message
gossip global topic - The payload attestations added must satisfy the verification conditions found in payload attestation gossip validation and payload attestation processing. This means
- The
data.beacon_block_root
corresponds toblock.parent_root
. - The slot of the parent block is exactly one slot before the proposing slot.
- The signature of the payload attestation data message verifies correctly.
- The proposer needs to aggregate all payload attestations with the same data
into a given
PayloadAttestation
object. For this it needs to fill theaggregation_bits
field by using the relative position of the validator indices with respect to the PTC that is obtained fromget_ptc(state, block_slot - 1)
.
Blob sidecars¶
The blob sidecars are no longer broadcast by the validator, and thus their construction is not necessary. This deprecates the corresponding sections from the honest validator guide in the Electra fork, moving them, albeit with some modifications, to the honest Builder guide
Payload timeliness attestation¶
Some validators are selected to submit payload timeliness attestations.
Validators should call get_ptc_assignment
at the beginning of an epoch to be
prepared to submit their PTC attestations during the next epoch.
A validator should create and broadcast the payload_attestation_message
to the
global execution attestation subnet not after
SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT
seconds since the start of slot
Constructing a payload attestation¶
If a validator is in the payload attestation committee for the current slot (as
obtained from get_ptc_assignment
above) then the validator should prepare a
PayloadAttestationMessage
for the current slot, according to the logic in
get_payload_attestation_message
below and broadcast it not after
SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT
seconds since the start of the slot,
to the global payload_attestation_message
pubsub topic.
The validator creates payload_attestation_message
as follows:
- If the validator has not seen any beacon block for the assigned slot, do not submit a payload attestation. It will be ignored anyway.
- Set
data.beacon_block_root
be the HTR of the beacon block seen for the assigned slot - Set
data.slot
to be the assigned slot. - If a
SignedExecutionPayloadEnvelope
has been seen referencing the blockdata.beacon_block_root
setdata.payload_present = True
. Otherwise set it toFalse
. - Set
payload_attestation_message.validator_index = validator_index
wherevalidator_index
is the validator chosen to submit. The private key mapping tostate.validators[validator_index].pubkey
is used to sign the payload timeliness attestation. - Sign the
payload_attestation_message.data
using the helperget_payload_attestation_message_signature
.
Notice that the attester only signs the PayloadAttestationData
and not the
validator_index
field in the message. Proposers need to aggregate these
attestations as described above.
Remark Validators do not need to check the full validity of the
ExecutionPayload
contained in within the envelope, but the checks in the
P2P guide should pass for the
SignedExecutionPayloadEnvelope
.
Modified functions¶
Modified prepare_execution_payload
¶
Note: The function prepare_execution_payload
is modified to handle the
updated get_expected_withdrawals
return signature.