Beacon Chain Validators: Redundancy Risks and Failover

特邀专栏作者

2020-12-30 18:42 (UTC+8)

This article is about 2694 words, reading the full article takes about 4 minutes

This article explains the dangers of redundancy to validators and proposes a reasonable failover for VCs in the beacon chain.

AI Summary

Expand

This article explains the dangers of redundancy to validators and proposes a reasonable failover for VCs in the beacon chain.

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, Author: Aditya Asgaonkar, translation: A Jian, reprinted by Odaily with authorization.

first level title

Validators and Validator Clients

A verifier is a concept related to the beacon chain, and a verifier is a participant in the consensus process of the beacon chain. Verifiers are identified by public keys, and each verifier will be assigned the task of verifying the beacon chain at different times. If you successfully complete these tasks, you will be rewarded; on the contrary, if you neglect your duties, you will not only not be rewarded, but will also be severely punished. In Phase 0, these accusations are limited to proposing blocks and submitting attestations on the beacon chain.

Validators need to use a software called a validator client (VC) to perform their duties1. All beacon chain client teams use VC as one of their client software packages.

Needless to say, validators want their clients to be online 24/7 so that they can reap maximum benefits and avoid all penalties. A common way to achieve high availability is to set up redundancy and failover mechanisms. This article explains the dangers of redundancy to validators and proposes a reasonable failover for VCs in the beacon chain.
Type of loss/penalty
Validators face three types of losses, in ascending order of severity:

Reward Frustration: When a validator fails to perform when assigned to a task, the TA cannot receive the reward corresponding to the task. The validator's equity (principal) will not decrease, but just loses a chance to get the reward.

Slow work penalty: If a verifier does not send a witness message, and the beacon chain cannot finalize block 2 at that time, the verifier's equity will be reduced by a small amount (of course, the relevant rewards will not be obtained).

Slashing penalty: If a validator sends a witness message that violates the Casper FFG rules, the validator will be slashed immediately - the validator's equity will be reduced by a certain ratio 3, and the validator will be kicked out and cannot be used again Participate in consensus (and thus also cut out from future rewards). Moreover, because the beacon chain cannot transfer and retrieve the pledged ETH, all the remaining money of the verifier will be locked on the beacon chain and cannot be used (until the beacon chain enables related functions).

(Translator's Note: The author missed a loss here: when the beacon chain cannot obtain finality, not only will the verifiers who did not send the witness message be punished for slowing down, but the witnesses who sent the message will also suffer losses. , but the loss is smaller than the former; however, the author mainly discusses the loss related to the offline of the verifier in this article, so it is also understandable.)

The first two loss types are likely to be experienced by validators whose VC is offline, but the third, is only experienced by validators who have incorrectly set up VC (or when the beacon chain is explicitly attacked).

Dangers of Redundant VC Facilities

Some stakers may believe that running redundant VCs is insurance against one VC going offline. But in fact, redundant VC facilities are not safe, and it is very likely that validators will be fined eventually!

Let's see a practical example:

image description

- Redundant VC leads to slashing! -

VC's failover protocol

Note: When I say "failover", I mean manually or automatically restarting a new VC instance after a VC is stopped, however, I do not recommend using an automated failover mechanism, because if implemented poorly, it can cause you There are two VCs hanging on the line!

The takeaway from the previous section is that validators should only have one live VC instance deployed at any one time. However, VCs always make mistakes, how to deal with this risk? Stakers should define their own failover protocol (determining what uses should restart a new validator client instance) in advance to deal with this situation. Before developing a secure and reliable failover protocol, let's first look at a security feature built into validator clients: slashing protection.

image description

- Slash protection mechanism -
Slash protection mechanism: All VC software developed by the beacon chain client team has a slash protection mechanism as an automatic fail-safe device for unexpected events. According to the slashing rules, only pairs of attestation messages will result in slashing, only need to check this pair of messages to judge the result. Then, VC can store all the messages and blocks signed by itself in the local slash protection database. When signing any new attestation message/block, VC only needs to check whether the new message conflicts with the old message in the database (whether it will form a slashed message pair), and only sign the new message that does not conflict.
Therefore, VC needs three mechanisms to ensure correct and safe operation:

Fully synchronized Beacon Chain Nodes (BNs) to obtain information about the Beacon Chain

The verifier signs the private key to actually sign the message

Timely slashing protects the database as a failsafe

A good failover protocol must account for the failure of either mechanism. The first two are easy to guarantee - a redundant BN can be maintained for new VC connections, and the signing key can also be copied from the backup folder as a read-only file.

Note: SD cards are not reliable storage devices, so stakers running VC on a Raspberry Pi are especially vulnerable to losing their slash-protected databases!

My suggested failover solution

A simple but useful solution is to maintain a redundant BN and ensure that redundant verifier keys are easily accessible.

image description
- Initial VC settings and multi-scenario failover protocols -
In this setting, a variety of errors have a distribution corresponding to the processing scheme: