WIP: First pass at adding to glossary and readme

[OisinKyne]

I have a question about the term co-validator @adiasg, here are some excerpts that I don't think are consistent.

from glossary.md

**Co-Validator**: A threshold BLS public key participating in the DV protocol for a *particular* Validator.

Software to participate as a Co-Validator by running the DV protocol

Each Co-Validator is running the Distributed Validator Client software to participate the in the Distributed Validator.

from ./dvspec/spec.py

@dataclass
class ValidatorIdentity:
    """Identity of the Ethereum validator.
    """
    # Ethereum public key
    pubkey: BLSPubkey
    # Index of Ethereum validator
    index: ValidatorIndex


@dataclass
class CoValidator:
    """Identity of distributed co-validator participating in the DV protocol.
    """
    # Identity of Ethereum validator that this co-validator performs duties for
    validator_identity: ValidatorIdentity
    # Secret-shared public key
    pubkey: BLSPubkey
    # Index of the co-validator in the distributed validator protocol
    index: ValidatorIndex


@dataclass
class DistributedValidator:
    """State object that tracks a single Ethereum validator being run using the distributed validator protocol.
    """
    validator_identity: ValidatorIdentity
    co_validators: List[CoValidator]
    slashing_db: SlashingDB

In the first example, a co-validator is a single BLS key, in the next two a co-validator is what we have been calling an operator. In the python file, the CoValidator class is closer to the BLS key concept.

Might I suggest that co-validator is ambiguous, and that maybe the terms Operator and Distributed Validator Key Share are more clear? Or we could keep co-validator to mean key share but I would say co-validator key not just co-validator as is, because most people I have talked to infer co-validator to mean operator/person, not private key. Obviously this is a reflection of the eth2 spec itself considering people don't differentiate between person who runs a validator, a validator client, and a validator key, all of them get ambiguously called validator too.

Would like to get your thoughts on this before this PR is ready to merge, as I have only touched the markdown files, and haven't made any changes to the .py files until I've gotten your perspective, and would like to reflect what we pick in both places rather than adding even more inconsistency.

[OisinKyne]

Oh, and apologies for the extra whitespace and changing *italic* to _italic_, I have formatOnSave activated and had the changes committed before I realised

[adiasg]

Thanks @OisinKyne for opening this issue.

We require a term to describe an participating entity existing only inside the Distributed Validator Protocol, and which is identified by a unique BLS key and has assigned responsibilities in the protocol. The term Co-Validator was chosen for this entity, which is grander than just a BLS key. class CoValidator doesn't have a lot in it right now, but that will change in later versions. For example, a Co-Validator might have separate keys for Ethereum message signing, consensus message signing, and network identity. In modifications of this protocol with an incentive system, a Co-Validator may have an associated stake. For these reasons, I think Co-Validator is more appropriate than other variations that mention "key".

This is similar in spirit to the Ethereum spec, where the Validator is identified by its BLS key, but is a grander concept than just that - it has a balance, different types of keys (staking & withdrawal), etc.

I agree that we need another term for the entity running a Co-Validator using DVC software, for which Operator is appropriate.

[OisinKyne]

Okay cool, that works for me :) Operator for the entity running a DV Node, Co-validator for "the role/set of tasks that an entity identified by a BLS key in a DV must complete".

One more question/point of clarification.

Co-Validator might have separate keys for Ethereum message signing, consensus message signing, and network identity

To make sure I have this right, a co-validator could consist both of the BLS key that is part of the threshold signing scheme and a separate SECP256K1 key used for the p2p discovery/peering layer of the DVC, yes?