Gloas -- Honest Validator¶
Note: This document is a work-in-progress for researchers and implementers.
- Introduction
- Configuration
- Time parameters
- Validator assignment
- Lookahead
- Beacon chain responsibilities
- Attestation
- Sync Committee participations
- Block proposal
- Payload timeliness attestation
- Modified functions
- Modified
prepare_execution_payload - Data column sidecars
- Modified
get_data_column_sidecars_from_column_sidecar
Introduction¶
This document represents the changes and additions to the Honest validator guide included in Gloas.
Configuration¶
Time parameters¶
| Name | Value | Unit | Duration |
|---|---|---|---|
ATTESTATION_DUE_BPS_GLOAS |
uint64(2500) |
basis points | 25% of SLOT_DURATION_MS |
AGGREGATE_DUE_BPS_GLOAS |
uint64(5000) |
basis points | 50% of SLOT_DURATION_MS |
SYNC_MESSAGE_DUE_BPS_GLOAS |
uint64(2500) |
basis points | 25% of SLOT_DURATION_MS |
CONTRIBUTION_DUE_BPS_GLOAS |
uint64(5000) |
basis points | 50% of SLOT_DURATION_MS |
PAYLOAD_ATTESTATION_DUE_BPS |
uint64(7500) |
basis points | 75% of SLOT_DURATION_MS |
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 Gloas: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
BlobSidecarobjects, as this becomes a builder's duty. - Some validators are selected per slot to become PTC members, these validators
must broadcast
PayloadAttestationMessageobjects during the assigned slot before the deadline ofget_attestation_due_ms(epoch)milliseconds into the slot.
Attestation¶
The attestation deadline is changed with ATTESTATION_DUE_BPS_GLOAS. 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.indexbased on the payload status in the validator's fork-choice: - Set
data.index = 0to signal that the payload is not present in the canonical chain (payload status isEMPTYin the fork-choice). - Set
data.index = 1to signal that the payload is present in the canonical chain (payload status isFULLin the fork-choice).
Sync Committee participations¶
Sync committee duties are not changed for validators, however the submission
deadline is changed with SYNC_MESSAGE_DUE_BPS_GLOAS.
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_bid field in BeaconBlockBody¶
To obtain signed_execution_payload_bid, a block proposer building a block on
top of a state must take the following actions:
- Listen to the
execution_payload_bidgossip global topic and save an acceptedsigned_execution_payload_bidfrom a builder. Proposer MAY obtain these signed messages by other off-protocol means. - The
signed_execution_payload_bidmust satisfy the verification conditions found inprocess_execution_payload_bid, that is: - For external builders: The header signature must be valid
- For self-builds: The signature must be
bls.G2_POINT_AT_INFINITYand the bid amount must be zero - 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_bid = signed_execution_payload_bid
Note: The execution address encoded in the field fee_recipient in the
signed_execution_payload_bid.message is the recipient of the builder payment.
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_messagegossip 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_rootcorresponds 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
PayloadAttestationobject. For this it needs to fill theaggregation_bitsfield 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 Fulu 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
get_payload_attestation_due_ms(epoch) milliseconds 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
get_payload_attestation_due_ms(epoch) milliseconds 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_rootbe the HTR of the beacon block seen for the assigned slot - Set
data.slotto be the assigned slot. - If a
SignedExecutionPayloadEnvelopehas been seen referencing the blockdata.beacon_block_rootsetdata.payload_present = True. Otherwise set it toFalse. - Set
payload_attestation_message.validator_index = validator_indexwherevalidator_indexis the validator chosen to submit. The private key mapping tostate.validators[validator_index].pubkeyis used to sign the payload timeliness attestation. - Sign the
payload_attestation_message.datausing 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.
Data column sidecars¶
[Modified in Gloas]