T'was the day before genesis, when all was prepared, geth was in sync, my beacon node paired. Firewalls configured, VLANs galore, hours of preparation meant nothing ignored.
Then all at once everything went awry, the SSD in my system decided to die. My configs were gone, chain data was history, nothing to do but trust in next day delivery.
I found myself designing backups and redundancies. Complicated systems consumed my fantasies. Thinking further I came to realise: worrying about these kinds of failures was quite unwise.
Sự kiện
Chuỗi beacon có một số cơ chế để khuyến khích hành vi của trình xác thực, tất cả đều phụ thuộc vào trạng thái hiện tại của mạng, vì vậy điều quan trọng là phải xem xét các trường hợp lỗi này trong bối cảnh lớn hơn về cách các trình xác thực khác có thể thất bại khi quyết định cái gì và cái gì không, những cách đáng giá để bảo vệ (các) nút của bạn.
Là một trình xác thực đang hoạt động, số dư của bạn tăng hoặc giảm, nó không bao giờ đi ngang *. Do đó, một cách khá hợp lý để tối đa hóa lợi nhuận của bạn, là giảm thiểu những mặt trái của bạn. Có 3 cách để giảm số dư của bạn bằng chuỗi báo hiệu:
- Hình phạt được phát hành khi trình xác thực của bạn bỏ lỡ một trong các nhiệm vụ của họ (ví dụ: vì họ ngoại tuyến)
- Rò rỉ không hoạt động được giao cho người xác thực không thực hiện nhiệm vụ của họ trong khi mạng không hoàn thành (tức là khi trình xác thực của bạn ngoại tuyến có mối tương quan cao với trình xác thực khác đang ngoại tuyến)
- Chém được trao cho những người xác thực tạo ra các khối hoặc chứng thực mâu thuẫn và do đó có thể được sử dụng trong một cuộc tấn công
* Trung bình, số dư của trình xác thực có thể giữ nguyên, nhưng đối với bất kỳ nhiệm vụ cụ thể nào, họ sẽ được thưởng hoặc bị trừng phạt.
Tương quan
Ảnh hưởng của một trình xác thực duy nhất đang ngoại tuyến hoặc thực hiện hành vi có thể cắt được là rất nhỏ về sức khỏe tổng thể của chuỗi báo hiệu. Do đó nó không bị trừng phạt nặng nề. Ngược lại, nếu nhiều trình xác thực ngoại tuyến, số dư của trình xác thực ngoại tuyến có thể giảm nhanh hơn nhiều.
Tương tự, nếu nhiều trình xác thực thực hiện các hành động có thể cắt được cùng một lúc, theo quan điểm của chuỗi beacon, thì điều này không thể phân biệt được với một cuộc tấn công. Do đó, nó được xử lý như vậy và 100% cổ phần của những người xác thực vi phạm sẽ bị đốt cháy.
Vì những khuyến khích “chống lại mối tương quan” này, người xác nhận nên lo lắng hơn về những thất bại có thể ảnh hưởng đến những người khác cùng lúc hơn là những vấn đề riêng lẻ, riêng lẻ.
Nguyên nhân và xác suất của chúng.
Vì vậy, chúng ta hãy suy nghĩ về một số trường hợp thất bại và xem xét chúng qua lăng kính xem có bao nhiêu người khác sẽ bị ảnh hưởng cùng một lúc và người xác nhận của bạn sẽ bị trừng phạt nặng như thế nào.
Tôi không đồng ý với @econoar nơi đây rằng đây là trường hợp xấu nhất vấn đề. Đây là những vấn đề ở mức độ vừa phải hơn. Lỗi địa chỉ Home UPS và Dual WAN không liên quan đến những người dùng khác và do đó, bạn nên bỏ qua danh sách các mối quan tâm của mình.
🌍 Internet / mất điện
Nếu bạn đang xác thực tại nhà, thì rất có thể bạn sẽ gặp phải một trong những lỗi này vào một thời điểm nào đó trong tương lai. Các kết nối Internet và nguồn điện trong khu dân cư không đảm bảo thời gian hoạt động. Tuy nhiên, khi internet bị ngắt hoặc mất điện, sự cố mất điện thường chỉ giới hạn trong khu vực của bạn và thậm chí sau đó chỉ trong vài giờ.
Trừ khi bạn có rất Internet / nguồn điện không rõ ràng, có thể không đáng trả tiền cho các kết nối bị rơi. Bạn sẽ nhận được một vài giờ hình phạt, nhưng vì phần còn lại của mạng đang hoạt động bình thường, hình phạt của bạn sẽ gần bằng với phần thưởng của bạn trong cùng khoảng thời gian. Nói cách khác, một k lỗi kéo dài một giờ đặt số dư của trình xác thực của bạn trở lại gần đúng như ban đầu k vài giờ trước khi thất bại, và trong k giờ bổ sung số dư của trình xác thực của bạn sẽ trở lại số tiền trước khi thất bại.
[Validator #12661 regaining ETH as quickly as it was lost – Beaconcha.in
🛠 Hardware failure
Like internet failure, hardware failure strikes randomly, and when it does, your node might be down for a few days. It is valuable to consider the expected rewards over the lifetime of the validator versus the cost of redundant hardware. Is the expected value of the failure (the offline penalties times the chance of it happening) greater than the cost of the redundant hardware?
Personally, the chance of failure is low enough and the cost of fully redundant hardware high enough, that it almost certainly isn’t worth it. But then again, I am not a whale 🐳 ; as with any failure scenario, you need to evaluate how this applies to your particular situation.
☁️ Cloud services failure
Maybe, to avoid the risks of hardware or internet failure altogether, you decide to go with a cloud provider. With a cloud provider, you have introduced the risk of correlated failures. The question that matters is, how many other validators are using the same cloud provider as you?
A week before genesis, Amazon AWS had a prolonged outage which affected a large portion of the web. If something similar were to happen now, enough validators would go offline at the same time that the inactivity penalties would kick in.
Even worse, if a cloud provider were to duplicate the VM running your node and accidentally leave the old and the new node running at the same time, you could be slashed (the penalties incurred would be especially bad if this accidental duplication affected many other nodes too).
If you are insistent on relying on a cloud provider, consider switching to a smaller provider. It may end up saving you a lot of ETH.
🥩 Staking Services
There are several staking services on mainnet today with varying degrees of decentralisation, but they all contain an increased risk of correlated failures if you trust them with your ETH. These services are necessary components of the eth2 ecosystem, especially for those with less than 32 ETH or without the technical know-how to stake, but they are architected by humans and therefore imperfect.
If staking pools eventually grow to be as large as eth1 mining pools, then it is conceivable that a bug could cause mass slashings or inactivity penalties for their members.
🔗 Infura Failure
Last month Infura went down for 6 hours causing outages across the Ethereum ecosystem; it is easy to see how this is likely to result in correlated failures for eth2 validators.
In addition, 3rd party eth1 API providers necessarily rate-limit calls to their service: In the past this has caused validators to be unable to produce valid blocks (on the Medalla testnet).
The best solution is to run your own eth1 node: you won’t encounter rate-limiting, it will reduce the likelihood of your failures being correlated, and it will improve the decentralisation of the network as a whole.
Eth2 clients have also started adding the possibility of specifying multiple eth1 nodes. This makes it easy to switch to a backup endpoint, in the event your primary endpoint fails (Lighthouse: –eth1-endpoints, Prysm: PR#8062, Nimbus & Teku will likely add support somewhere in the future).
I highly recommend adding backup API options as cheap/free insurance (EthereumNodes.com shows the free and paid API endpoints and their current status). This is useful whether you are running your own eth1 node or not.
🦏 Failure of a particular eth2 client
Despite all the code review, audits, and rockstar work, all of the eth2 clients have bugs hiding somewhere. Most of them are minor and will be caught before they present a major problem in production, but there is always the chance that the client you choose will go offline or cause you to be slashed. If this were to happen, you would not want to be running a client with > 1/3 of the nodes on the network.
You must strike a tradeoff between what you deem to be the best client vs how popular that client is. Consider reading through the documentation of another client so that if something happens to your node, you know what to expect in terms of installing and configuring a different client.
If you have lots of ETH at stake, it is probably worth running multiple clients each with some of your ETH to avoid putting all your eggs in one basket. Otherwise, Vouch is an interesting offering for multi-node staking infrastructure, and Secret Shared Validators are seeing rapid development.
🦢 Black swans
There are of course many unlikely, unpredictable, yet dangerous scenarios that will always present a risk. Scenarios that lie outside the obvious decisions about your staking set-up. Examples such as Spectre and Meltdown at the hardware level, or kernel bugs such as BleedingTooth hint at some of the hazards that exist across the entire hardware stack. By definition, it is not possible to entirely predict and avoid these problems, instead you generally must react after the fact.
What to worry about
Ultimately this comes down to calculating the expected value E(X) of a given failure: how likely an event is to happen, and what the penalties would be if it did. It is vital to consider these failures in the context of the rest of the eth2 network since the correlation greatly affects the penalties at hand. Comparing the expected cost of a failure to the cost of mitigating it will give you the rational answer as to whether it is worth getting in front of.
No one knows all the ways a node can fail, nor how likely each failure is, but by making individual estimates of the chances of each failure type and mitigating the biggest risks, the “wisdom of the crowd” will prevail and on average the network as a whole will make a good estimate. Furthermore, because of the different risks each validator faces, and the differing estimates of those risks, the failures you did not account for will be caught by others and therefore the degree of correlation will be reduced. Yay decentralisation!
📕 DON’T PANIC
Finally, if something does happen to your node, don’t panic! Even during inactivity leaks, penalties are small on short time scales. Take a few moments to think through what happened and why. Then make a plan of action to fix the problem. Then take a deep breath before you proceed. An extra 5 minutes of penalties is preferable to being slashed because you did something ill-advised in a rush.
Most of all: 🚨 Do not run 2 nodes with the same validator keys! 🚨
Thanks Danny Ryan, Joseph Schweitzer, and Sacha Yves Saint-Leger for review
[Slashings because validators ran >1 node – Beaconcha.in]
