Learn about the correct posture for assessing the risk of Eth2 verifiers in one article

source|Ethereum Blog

source|

The Beacon Chain has multiple incentive mechanisms for validator behavior, all of which are determined by the current state of the network. Therefore, when deciding how to secure a node, it is also important to consider situations where other validators may encounter problems.

• The balance of active validators will either rise or fall, and will not remain the same. Therefore, reducing risk as much as possible is a way to maximize returns. There are three main situations in which the verifier’s balance is deducted by the beacon chain:

• General penalty: This penalty will be imposed when the verifier fails to do his duty (such as offline)

• Inactivity Leaks: When the network is in a state where finalization cannot be finalized, verifiers will be punished for dereliction of duty, that is, they are highly related to other verifiers who are offline.

Note: On average, a single validator may have a constant balance, but will be rewarded or penalized for participating in the work.

Correlation

Correlation

If the entire network is in a healthy state, the impact of a single validator going offline or triggering a slash is small, which means that the punishment will not be very severe. Conversely, if a large number of validators in the network are offline, the balance of offline validators will be cut much faster.

Similarly, if a large number of validators trigger slashing at the same time, it will be tantamount to an attack on the beacon chain, so 100% of the pledged funds of these validators will be destroyed.

Because of these "anti-correlation" incentives, validators should think more about issues that simultaneously impact others, rather than in isolation, personally.

Failure cause and possibility

Let's go through some failure cases and see how many other validators are affected at the same time, and how heavily your validator will be penalized.@econoarI disagree here

statement. The severity of these problems is considered moderate. Home UPS and dual WAN address failures are not relevant to other users and are excluded from consideration.

🌍 Internet/power failure

If you are running a validator from home, chances are you will run into these issues in the future. Home network and power connections do not guarantee uptime. When the network is disconnected or the power goes out, it is often the entire area that is affected, even for hours.

Validator #12661Unless your network or electricity is very stable, it is not worth being penalized for this reason. You will be penalized for a few hours, but since the entire network is running normally, your penalty is approximately equal to the reward you deserved during that time period. That is, if the failure time is k hours, then your validator balance may roll back to the value before the failure k hours, and then k hours later your validator balance will return to the value before the failure.Beaconcha.in

The balance returns at about the same rate as it decreases offline -

🛠 Hardware failure

Similar to network issues, hardware failures happen randomly, and when they do, your nodes may be offline for days. It is important to consider the expected benefits over the lifetime of a validator versus the cost of spare hardware. Is the expected value of failure (offline penalty multiplied by the chance of occurrence) greater than the cost of spare hardware?

Personally, it's not worth it if the chance of failure is low and the cost of spare hardware is high. But then again, I'm not a giant whale 🐳. You need to evaluate all failure scenarios according to your actual situation.

☁️ Cloud service failure

Perhaps you may choose to use cloud services in order to avoid hardware and network failures. If cloud services are used, the above-mentioned related risks are introduced. How many other validators use the same cloud provider as you?One week before creation,Amazon's AWS is down for an extended period of time

, had a great impact on the network. Now if a similar event occurs, causing a large number of validators to go offline at the same time, inactivity penalties will be triggered.

Worse, if the cloud service provider runs your node with a new virtual machine, but accidentally does not stop running the old node, this may result in you being slashed (if this also affects other validators, then the penalty will be particularly large).

If you insist on using cloud services, you can consider switching to a smaller service provider, which may reduce losses.

🥩 Staking ServiceCurrently the main network hasVarious pledge services

You can choose, and the degree of decentralization varies, but entrusting your ETH to a service provider somewhat increases the risk of correlation. These services are undoubtedly an integral part of the eth2 ecosystem, especially for users who hold less than 32 ETH or lack the technical knowledge required to stake. But these services are human-designed, so there will be flaws.

If the staking pool eventually grows to be as large as the eth1 mining pool, a bug could result in massive slashing or slowdown penalties for its users.

🔗 failureInfura was down for six hours last month

, leading to the stagnation of the Ethereum ecosystem. In the same way, this is also a related risk that Eth2 validators may face.

Additionally, third-party eth1 API providers must rate-limit calls to the service: in the past this has resulted in validators not being able to produce valid blocks (Medalla testnet).

The best solution is to run your own eth1 node: you won't run into rate limits, reducing your risk of correlation and helping to improve the decentralization of the entire network.PR#8062Eth2 clients have started adding the possibility to specify multiple eth1 nodes. The benefit is that the backup endpoint can be easily switched if the primary endpoint fails (Lighthouse: --eth1-endpoints, Prysm:

, Nimbus and Teku may add support later).EthereumNodes.comI highly recommend adding a lower cost or free alternative API (

There are free and paid API endpoints and their current status in ). This measure is necessary whether or not you run your own eth1 nodes.

🦏 A certain eth2 client is down

Despite code reviews, audits, and testing, bugs in the eth2 client are hiding somewhere. Most of them are minor issues and will be caught before the product is released, but there is a chance that your chosen client will go offline or get you slashed. If this happens, you won't want to run a client that most people (>1/3) use.

You have to make a trade-off between which client you think is most suitable and its popularity. Consider reading through the other client's documentation so you know how to install and configure a different client should something happen to your node.VouchIf you stake a lot of ETH, it is necessary to run different clients to avoid putting all your eggs in one basket.Secret Shared Validatorsis an infrastructure capable of providing multi-node staking, currently secret-sharing validators (

) has also ushered in rapid progress.

Of course, there are also many unlikely, unpredictable but high-impact events that pose risks. This has nothing to do with your staking settings and decisions. For example at the hardware levelSpectreandMeltdownandBleedingTooth, or a kernel vulnerability (

hints at certain hazards throughout the hardware stack). In other words, we cannot fully predict and avoid these problems, but take corresponding measures after the problem occurs.

What do I need to worry about?

Ultimately, it comes down to computing the expected value E(X) of a given failure: the likelihood of the event occurring and the cost of that event. Since correlation factors can have a considerable impact on the severity of penalties, it is critical to consider these failure events in the context of other members of the eth2 network. Compare the expected cost of a failure to the cost of a diluted failure, and you'll get a reasonable answer as to whether it's worth a shot.

No one knows all the situations in which a node could fail, nor the likelihood of each failure, but by making independent estimates of the likelihood of each failure type and diluting the maximum risk, the "wisdom of the crowd" comes into play. Also, since each validator faces different risks and evaluates those risks differently, risks you didn't account for may be encountered by others and therefore less relevant. The power of decentralization!

📕 Don't panic

Finally, if something really happens to your node, don't panic! Even if you are punished for inactivity leaks, the amount of punishment in a short period of time is not large. Calm down and think about what happened, why it happened, and then make a plan to fix it. Take a deep breath before getting started! Giving yourself an extra five minutes to think is far better than rushing to make the wrong decision and getting fined.

Top priority: 🚨 Don't run two nodes with the same verification key! 🚨

Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact eth@ecn.co Authorize.Beaconcha.in]

Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact eth@ecn.co Authorize.

Official Account: ETH Chinese Station

Official Account: ETH Chinese Station