eth2.0-specs/specs/deneb/validator.md
Jacek Sieka 5fafcd8274
Rebalance duty times
As the chain keeps growing and duties are being added to the block
construction and verification pipeline, it becomes increasingly
difficult for clients to complete block duties on time leading to poor
attestation performance and reorg frequency increases.

This PR proposes to rebalance the relative timings of the 3 main
activites, namely block production, attestation and aggregation such
that they happen on 0/6/9 seconds into each slot instead of 0/4/8.

This reduces the time for attestations to reach aggregators and
aggregates to reach block producers but increases the time the consensus
and execution clients have to produce and validate blocks.

Each upgrade has so far increased complexity and processing requirements
around block production and so will future upgraddes: due to increased
size, blocks with blobs will take longer to dissemenate and additional
verification / cryptography is needed to validate them.
2023-06-15 21:43:35 +02:00

6.5 KiB

Deneb -- Honest Validator

Notice: This document is a work-in-progress for researchers and implementers.

Table of contents

Introduction

This document represents the changes to be made in the code of an "honest validator" to implement Deneb.

Prerequisites

This document is an extension of the Capella -- Honest Validator guide. All behaviors and definitions defined in this document, and documents it extends, carry over unless explicitly noted or overridden.

All terminology, constants, functions, and protocol mechanics defined in the updated Beacon Chain doc of Deneb are requisite for this document and used throughout. Please see related Beacon Chain doc before continuing and use them as a reference throughout.

Helpers

BlobsBundle

[New in Deneb:EIP4844]

@dataclass
class BlobsBundle(object):
    commitments: Sequence[KZGCommitment]
    proofs: Sequence[KZGProof]
    blobs: Sequence[Blob]

Modified GetPayloadResponse

@dataclass
class GetPayloadResponse(object):
    execution_payload: ExecutionPayload
    block_value: uint256
    blobs_bundle: BlobsBundle  # [New in Deneb:EIP4844]

Protocol

ExecutionEngine

Modified get_payload

Given the payload_id, get_payload returns the most recent version of the execution payload that has been built since the corresponding call to notify_forkchoice_updated method.

def get_payload(self: ExecutionEngine, payload_id: PayloadId) -> GetPayloadResponse:
    """
    Return ExecutionPayload, uint256, BlobsBundle objects.
    """
    # pylint: disable=unused-argument
    ...

Beacon chain responsibilities

All validator responsibilities remain unchanged other than those noted below.

Block and sidecar proposal

Constructing the BeaconBlockBody

Blob KZG commitments

[New in Deneb:EIP4844]

  1. After retrieving the execution payload from the execution engine as specified in Capella, use the payload_id to retrieve blobs, blob_kzg_commitments, and blob_kzg_proofs via get_payload(payload_id).blobs_bundle.
  2. Set block.body.blob_kzg_commitments = blob_kzg_commitments.

Constructing the SignedBlobSidecars

[New in Deneb:EIP4844]

To construct a SignedBlobSidecar, a signed_blob_sidecar is defined with the necessary context for block and sidecar proposal.

Sidecar

Blobs associated with a block are packaged into sidecar objects for distribution to the network.

Each sidecar is obtained from:

def get_blob_sidecars(block: BeaconBlock,
                      blobs: Sequence[Blob],
                      blob_kzg_proofs: Sequence[KZGProof]) -> Sequence[BlobSidecar]:
    return [
        BlobSidecar(
            block_root=hash_tree_root(block),
            index=index,
            slot=block.slot,
            block_parent_root=block.parent_root,
            blob=blob,
            kzg_commitment=block.body.blob_kzg_commitments[index],
            kzg_proof=blob_kzg_proofs[index],
        )
        for index, blob in enumerate(blobs)
    ]

Then for each sidecar, signed_sidecar = SignedBlobSidecar(message=sidecar, signature=signature) is constructed and published to the associated sidecar topic, the blob_sidecar_{subnet_id} pubsub topic.

signature is obtained from:

def get_blob_sidecar_signature(state: BeaconState,
                               sidecar: BlobSidecar,
                               privkey: int) -> BLSSignature:
    domain = get_domain(state, DOMAIN_BLOB_SIDECAR, compute_epoch_at_slot(sidecar.slot))
    signing_root = compute_signing_root(sidecar, domain)
    return bls.Sign(privkey, signing_root)

The subnet_id for the signed_sidecar is calculated with:

  • Let blob_index = signed_sidecar.message.index.
  • Let subnet_id = compute_subnet_for_blob_sidecar(blob_index).
def compute_subnet_for_blob_sidecar(blob_index: BlobIndex) -> SubnetID:
    return SubnetID(blob_index % BLOB_SIDECAR_SUBNET_COUNT)

After publishing the peers on the network may request the sidecar through sync-requests, or a local user may be interested.

The validator MUST hold on to sidecars for MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epochs and serve when capable, to ensure the data-availability of these blobs throughout the network.

After MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS nodes MAY prune the sidecars and/or stop serving them.

Validator duties

The timing for sending attestation, aggregate, sync committee messages and contributions change.

Attestations

A validator must create and broadcast the attestation to the associated attestation subnet as soon as the validator has received a valid block from the expected block proposer for the assigned slot.

If the block has not been observed at SECONDS_PER_SLOT / 2 seconds into the slot, the validator should send the attestation voting for its current head as selected by fork choice.

Aggregates

If the validator is selected to aggregate (is_aggregator), then they broadcast their best aggregate as a SignedAggregateAndProof to the global aggregate channel (beacon_aggregate_and_proof) SECONDS_PER_SLOT * 3 / 4 seconds after the start of the slot.

Sync committee messages

This logic is triggered upon the same conditions as when producing an attestation.

Sync committee contributions

This logic is triggered upon the same conditions as when producing an aggregate.