Epoch Boundary: Validator Shuffle

Council Proposals TNIP
1

Joining the Network

New validators need to join the PoS network.

Glossary

Terms used in this post:

CVV: Committee-Voting Validator
  • A validator node that votes in the current epoch as part of the validator committee. A quorum of CVV votes are needed to reach consensus.
NVV: Non-Voting Validator
  • A validator that observes and executes consensus, but does not participate in the voting process. These nodes support data availability and may become CVVs in future epochs.
e

e is the variable that indicates the last round of an epoch. If an epoch is 16 rounds long, e = 16.

New Node Process

  1. Verify credentials and obtain NFT from Council: Verification takes place off-chain through social governance.
  2. Stake TEL to validator staking contract: NFT allows access to stake on the staking contract. The amount staked is outside the scope of this proposal.
  3. Launch validator node with static IP, firewall, and sufficient hardware: Once online, the node becones a non-voting validator (NVV) and must find peers.
  4. NVV reaches out to peers and initiates handeshake: How much data is needed to “sync” with the chain? Consensus can start at any epoch boundary, but TN needs to maintain historic data as well. TA snapshots?
  5. Peers verify NVVs handshake with execution state: Peers are CVVs and other NVVs. Once peers verify a handshake, they should gossip the exchange to their other peers to help the new node with discovery. CVVs maintain only one NVV peer connection to limit their bandwidth burden. NVVs should also know if they are the single peer for a CVV and only accept this status once to prevent a single NVV from being the only peer for multiple CVVs. NVVs should have multiple NVV peers.
  6. NVV successfully joined the network and starts receiving gossip from consensus: NVV should download, store, and execute all consensus data it receives. NVV should support workers and public RPC requests. NOTE: This has implications for bridge and sending transactions that need to be discussed further.
  7. NVV becomes eligible to become CVV after some time: The main goal of an NVV is to become a CVV and earn TEL issuance. NVVs are only eligible to become CVVs after one full epoch. For example: NVV joins in epoch 1 and can become a CVV as soon as epoch 4. NVV completes it’s first full epoch in epoch 2, which makes it eligible starting in epoch 3. At the end of epoch 3, it could be selected as CVV for epoch 4.

Epoch Boundary

The epoch boundary must be robust. It is a checkpoint where CVVs are shuffled and the consensus network starts fresh.

Things that change

  • Committee changes
  • Transactions are submitted through different nodes. We want UX to be the same, but RPCs need to be aware of where to forward transactions so they are correctly sequenced.
  • Consensus database starts at round 0 (el block data should be (epoch, round))
  • Staking contract is updated with rewards (slashes and withdrawals at boundary or per block?)

Technical discussion

Committees are created with a predefined number of rounds they are expected to commit, e. During the current epoch, CVVs must reach consensus on the next committee starting at e + 1, so the next committee must be deterministic based on random values. CVVs require execution data to make this decision, and the decision should be handled at the Primary level (not workers) through system messages. Should committee size be adjustable (through protocol upgrades)? If so, on-chain committee info needs to be flexible.

Nominating the next committee

Aggregate BLS signatures provide sufficient randomness for selecting the next committee and are available to all CVVs. They are hard to predict and easy to verify. Ethereum uses xor instead of hashes to prevent a certain style of attack but this may not be strictly necessary for TN because slot leaders are selected on the fly.

The current committee should only nominate peers that are eligible via the staking contract. Ethereum chooses committees two epochs in advance.

How can current committee confirm new committee?

The longer the epoch, the more important it is to ensure healthy incoming CVVs.

  • Should there be a continual “healthcheck” for upcoming committee?
    • This seems expensive and doesn’t solve the problem. CVV could still go down on first round of new epoch. All this does is increase overhead.
  • Rely exclusively on stake?
    • Byzantine CVVs are slashed
    • Only practical for shorter epochs? Not good if a node is down for entire epoch
  • How can NVVs participate in verifying epoch transition to increase security?

TBC

2 Likes