Gloas -- Honest Validator¶
Note: This document is a work-in-progress for researchers and implementers.
- Introduction
- Configuration
- Time parameters
- Validator assignment
- Payload timeliness committee
- Lookahead
- Beacon chain responsibilities
- Attestation
- Sync Committee participations
- Block proposal
- Payload timeliness attestation
- Modified functions
- Modified
get_data_column_sidecars_from_column_sidecar
Introduction¶
This document represents the changes to be made in the code of an "honest validator" to implement 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¶
Payload timeliness committee¶
A validator may be a member of the new Payload Timeliness Committee (PTC) for a
given slot. To check for PTC assignments, use
get_ptc_assignment(state, epoch, validator_index) where epoch <= next_epoch,
as PTC committee selection is only stable within the context of the current and
next epoch.
Lookahead¶
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
DataColumnSidecarobjects, as this becomes a builder's duty. - Some attesters are selected per slot to become PTC members, these validators
must broadcast
PayloadAttestationMessageobjects during the assigned slot before the deadline ofget_payload_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
Broadcasting SignedProposerPreferences¶
At the beginning of each epoch, a validator MAY broadcast
SignedProposerPreferences messages to the proposer_preferences gossip topic
for each slot returned by get_upcoming_proposal_slots(state, validator_index).
This allows builders to construct execution payloads with the validator's
preferred fee_recipient and gas_limit. If a validator does not broadcast a
SignedProposerPreferences message, this implies that the validator will not
accept any trustless bids for that slot.
To construct each SignedProposerPreferences:
- Instantiate a new
ProposerPreferencesobject aspreferences. - Set
preferences.proposal_slottoupcoming_proposal_slots[i]. - Set
preferences.validator_indexto the validator's index. - Set
preferences.fee_recipientto the execution address where the validator wishes to receive the builder payment. - Set
preferences.gas_limitto the validator's preferred gas limit for this execution payload. - Instantiate a new
SignedProposerPreferencesobject assigned_preferences. - Set
signed_preferences.messagetopreferences. - Set
signed_preferences.signatureto the result ofget_proposer_preferences_signature(state, preferences, privkey).
Constructing signed_execution_payload_bid¶
To obtain signed_execution_payload_bid, a block proposer building a block on
top of a state MUST take the following actions in order to construct the
signed_execution_payload_bid field in BeaconBlockBody:
- Listen to the
execution_payload_bidgossip global topic and save an acceptedsigned_execution_payload_bidfrom a builder. The block proposer MAY obtain these signed messages by other off-protocol means. - The
signed_execution_payload_bidMUST satisfy the verification conditions found inprocess_execution_payload_bidwith the aliasbid = signed_execution_payload_bid.message, that is: - For external builders, the signature MUST be valid.
- For self-builds, set
bid.builder_indextoBUILDER_INDEX_SELF_BUILD. - For self-builds, the signature MUST be
bls.G2_POINT_AT_INFINITYand thebid.valueMUST be zero. - The builder balance can cover the
bid.value. - The
bid.slotis for the proposal block slot. - The
bid.parent_block_hashequals the state'slatest_block_hash. - The
bid.parent_block_rootequals the current block'sparent_root. - Select one bid and set
body.signed_execution_payload_bid = signed_execution_payload_bid.
Note: The execution address encoded in the fee_recipient field in the
signed_execution_payload_bid.message will receive the builder payment.
Constructing payload_attestations¶
Up to MAX_PAYLOAD_ATTESTATIONS aggregate payload attestations can be included
in the block. The block proposer MUST take the following actions in order to
construct the payload_attestations field in BeaconBlockBody:
- Listen to the
payload_attestation_messagegossip global topic. - Added payload attestations MUST satisfy the verification conditions found in payload attestation gossip validation and payload attestation processing.
- 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 MUST aggregate all payload attestations with the same data into a
given
PayloadAttestationobject. For this the proposer 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).
Preparing ExecutionPayload¶
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 within the first
get_payload_attestation_due_ms(epoch) milliseconds of the 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. Follow the logic below to
create the payload_attestation_message and broadcast to the global
payload_attestation_message pubsub topic within the first
get_payload_attestation_due_ms(epoch) milliseconds of the slot.
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 hash tree root of the beacon block seen for the assigned slot. - Set
data.slotto be the assigned slot. - If a previously seen
SignedExecutionPayloadEnvelopereferences the block with rootdata.beacon_block_root, setdata.payload_presenttoTrue; otherwise, setdata.payload_presenttoFalse. - 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.
Note: Validators do not need to check the full validity of the
ExecutionPayload contained in within the envelope, but the checks in the
Networking specifications should pass for the
SignedExecutionPayloadEnvelope.