Skip to content

Custody Game -- Honest Validator

Notice: This document is a work-in-progress for researchers and implementers. This is an accompanying document to Custody Game -- The Beacon Chain, which describes the expected actions of a "validator" participating in the shard data Custody Game.

Table of contents

Introduction

Prerequisites

This document is an extension of the Sharding -- Validator. All behaviors and definitions defined in the Sharding doc carry over unless explicitly noted or overridden.

All terminology, constants, functions, and protocol mechanics defined in the Custody Game -- The Beacon Chain docs are requisite for this document and used throughout. Please see the Custody Game docs before continuing and use them as a reference throughout.

Becoming a validator

Becoming a validator in Custody Game is unchanged from Phase 0. See the Phase 0 validator guide for details.

Beacon chain validator assignments

Beacon chain validator assignments to beacon committees and beacon block proposal are unchanged from Phase 0. See the Phase 0 validator guide for details.

Custody slashings

Up to MAX_CUSTODY_SLASHINGS, CustodySlashing objects can be included in the block. The custody slashings must satisfy the verification conditions found in custody slashings processing. The validator receives a small "whistleblower" reward for each custody slashing included (THIS IS NOT CURRENTLY THE CASE BUT PROBABLY SHOULD BE).

Custody key reveals

Up to MAX_CUSTODY_KEY_REVEALS, CustodyKeyReveal objects can be included in the block. The custody key reveals must satisfy the verification conditions found in custody key reveal processing. The validator receives a small reward for each custody key reveal included.

Early derived secret reveals

Up to MAX_EARLY_DERIVED_SECRET_REVEALS, EarlyDerivedSecretReveal objects can be included in the block. The early derived secret reveals must satisfy the verification conditions found in early derived secret reveal processing. The validator receives a small "whistleblower" reward for each early derived secret reveal included.

Construct attestation

attestation.data, attestation.aggregation_bits, and attestation.signature are unchanged from Phase 0. But safety/validity in signing the message is premised upon calculation of the "custody bit" [TODO].

How to avoid slashing

Proposer and Attester slashings described in Phase 0 remain in place with the addition of the following.

Custody slashing

To avoid custody slashings, the attester must never sign any shard transition for which the custody bit is one. The custody bit is computed using the custody secret:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
def get_custody_secret(state: BeaconState,
                       validator_index: ValidatorIndex,
                       privkey: int,
                       epoch: Epoch=None) -> BLSSignature:
    if epoch is None:
        epoch = get_current_epoch(state)
    period = get_custody_period_for_validator(validator_index, epoch)
    epoch_to_sign = get_randao_epoch_for_custody_period(period, validator_index)
    domain = get_domain(state, DOMAIN_RANDAO, epoch_to_sign)
    signing_root = compute_signing_root(Epoch(epoch_to_sign), domain)
    return bls.Sign(privkey, signing_root)

Note that the valid custody secret is always the one for the attestation target epoch, not to be confused with the epoch in which the shard block was generated. While they are the same most of the time, getting this wrong at custody epoch boundaries would result in a custody slashing.