信標鏈對於驗證者行為有多種激勵機制，這些機制都由網絡的當前狀態來決定。因此，在決策如何保障節點的時候，考慮其他驗證者可能碰到問題的情況也很重要。
活躍驗證者的餘額非升即跌，不會保持不變。因此儘量降低風險不失為最大化收益的一種方式。驗證者餘額被信標鏈扣除的情形主要有以下三種：
一般懲罰：驗證者失職的時候會被施以此種懲罰 (例如離線)怠工懲罰 (Inactivity Leaks)：當網絡處於無法敲定的狀態時，驗證者失職會受到該懲罰，即和其他處於離線狀態的驗證者高度相關。罰沒 (Slashing)：當驗證者做出矛盾的區塊提議或證明時會被罰沒 (可能是攻擊行為)。注意：平均來看，單個驗證者的餘額可能不變，但只要參加了工作，就會獲得獎勵或是受到懲罰。
相關性
如果整個網絡處於健康運行狀態，那麼單個驗證者離線或是觸發罰沒的影響是很小的，也就是說懲罰力度不會很大。相反，如果網絡中有大量驗證者離線，那麼離線驗證者的餘額削減速度會快得多。
同理，如果大量驗證者同時觸發罰沒，對於信標鏈來說會這無異於攻擊行為，因此這些驗證者 100% 的質押金會被銷毀。
由於這些「反相關」激勵措施，驗證者應該更多地考慮同時會對他人產生影響的問題，而不是從孤立的、個人的角度出發。
故障原因及可能性
讓我們仔細通過一些故障案例，然後看看有多少其他驗證者會同時受到影響，以及你的驗證者將受到多大力度的懲罰。
這裡我不同意 @econoar的說法。這些問題的嚴重程度算是中等。家用 UPS 和雙 WAN 地址故障與其他用戶無關，因此從考慮範圍中排除。
網絡/電力故障
如果你是居家運行驗證者，那麼將來很可能會遇到這些問題。家用網絡和電力連接無法保障正常運行時間。當網絡斷開連接或是電力中斷時，通常是整個片區受到影響，甚至會持續數小時。
除非你的網絡或是電力非常穩定，否則因為這個原因遭到懲罰是不太值當的。這幾個小時之內你會受到懲罰，但是由於整個網絡是正常運行狀態，你的懲罰大約等同於該時間段內應得的獎勵。也就是說，如果故障時間為 k小時，那麼你的驗證者餘額可能會回退到故障k小時前的數值，然後k小時之後你的驗證者餘額又會恢復到發生故障前的數值。
Validator #12661的餘額回升速度和離線時的降低速度大致相同 -Beaconcha.in
硬體故障
類似於網絡問題，硬體故障會隨機發生，而且在發生故障時，你的節點可能會離線幾天。我們很有必要考慮驗證者整個生命周期中的預期收益與備用硬體的成本。故障的期望值 (離線罰款乘以發生的機率) 是否大於備用硬體的成本？
就個人而言，如果發生故障的機會很低，且備用硬體的成本較高，這是不值當的。但是話又說回來，我不是巨鯨。你需要根據自己的實際情況來評估所有故障情形。
雲服務故障
也許大家可能會為了避免硬體和網絡故障而選擇使用雲服務。如果使用雲服務的話，就引入了上面所說的相關性風險。有多少其他驗證者和你使用相同的雲服務商？
在創世前一周，亞馬遜的 AWS 長時間停運，對網絡了很大影響。現在如果發生類似的事件，導致大量驗證者同時離線，就會觸發怠工懲罰 (inactivity penalties)。
更壞的情況是，如果雲服務商使用新的虛擬機運行你的節點，卻意外地沒有停止運行舊節點，這可能導致你被罰沒 (如果這也對其他驗證者造成了影響，那麼懲罰力度會尤其大)。
如果你堅持要使用雲服務，可以考慮切換到比較小的服務商，可能會減少損失。
質押服務
目前主網有多種質押服務可以選擇，並且去中心化程度都不盡相同，但是把你的 ETH 託付給服務商都多少增加了相關性風險。這些服務無疑是 eth2 生態系統中不可或缺的部分，對於持有低於 32 ETH 或是缺乏質押所需技術知識的用戶來說更甚。但這些服務都是人為設計的，因此會存在缺陷。
如果質押池的規模最終會增長得和 eth1 礦池一樣大，那麼一個漏洞可能會導致其用戶被大規模罰沒或是怠工懲罰。
故障
上個月 Infura 宕機了六個小時，導致了以太坊生態系統的停滯。同理，這也是 Eth2 驗證者可能面臨的相關性風險。
另外，第三方 eth1 API 提供者必須對服務的調用進行速率限制：過去這導致了驗證者無法生產有效塊 (Medalla測試網)。
最好的解決方式就是運行你自己的 eth1 節點：你不會遇到速率限制，從而降低你的相關性風險，並且有助於提升整個網絡的去中心化程度。
Eth2 客戶端已經開始加入指定多個 eth1 節點的可能性。其好處在於，主要終端發生故障時能夠輕鬆切換備用終端 (Lighthouse: --eth1-endpoints， Prysm:PR#8062，Nimbus 和 Teku 之後可能會加入支持)。
我高度建議添加成本較低或是免費的備用 API (EthereumNodes.com中有免費和付費的 API 終端及其當前狀態)。無論你是否運行自己的 eth1 節點，這個措施都很有必要。
某個 eth2 客戶端故障
儘管進行了代碼審核、審計和測試，但 eth2 客戶端的 bug 都隱藏在某個地方。他們中的大多數都是次要的問題，並且會在產品發布前被發現，但是你所選擇的客戶端存在離線或者導致你被罰沒的可能。如果發生這種情況，你將不會希望運行多數人 (＞1/3) 使用的客戶端。
你必須在你認為最合適的客戶端和其受歡迎程度之間做出權衡。可以考慮通讀另一個客戶端的文檔，從而在你的節點發生意外時，知道如何安裝和配置一個不同的客戶端。
如果你質押了大量 ETH，運行不同的客戶端是很有必要的，避免把雞蛋都放在一個籃子裡。 Vouch是一個能夠提供多節點質押的基礎設施，目前秘密共享驗證者 (Secret Shared Validators) 也迎來了飛速進展。
黑天鵝事件
當然了，也有許多可能性不大、不可預測但影響頗大的事件會帶來風險。這無關你的質押設置和決策。例如在硬體層面的 Spectre和Meltdown，或是內核漏洞 (BleedingTooth提示整個硬體堆棧中存在某些危險)。也就是說，我們無法完全預測和避免這些問題，而是在問題發生後採取相應措施。
我需要擔心什麼？
歸根結底，這取決於計算給定故障的期望值 E(X)：事件發生的可能性以及該事件的代價。由於相關性因素會對懲罰力度造成相當大的影響，因此在 eth2 網絡其他成員的語境下考慮這些故障事件至關重要。將故障的預期成本與稀釋故障的成本進行比較，你將得到一個合理的答案，以判斷是否值得一試。
沒有人知道節點可能發生故障的所有情形，也不知道每種故障發生的可能性，但是通過對每種故障類型的可能性進行獨立估算並稀釋最大風險，「群體智慧」將發揮作用。此外，由於每個驗證者面臨的風險不同，並且對這些風險的評估也不同，你沒有考慮到的風險可能會被他人碰到，因此相關性將降低。去中心化的力量！
莫要驚慌
最後，如果你的節點真的發生了什麼意外，別要驚慌！即使是遭到怠工懲罰 ( inactivity leaks)，在短時間內懲罰數額也不大。冷靜下來思考一下發生了什麼，為什麼會發生，然後制定計劃來解決問題。在上手之前深呼吸一下！比起慌忙做出錯誤決定導致被罰沒，給自己多五分鐘的思考時間更為可取。
重中之重： 不要使用同一個驗證密鑰運行兩個節點！
感謝Danny Ryan、Joseph Schweitzer 和 Sacha Yves Saint-Leger 對本文的審校
[使用同一密鑰運行一個以上驗證者導致的罰沒 - Beaconcha.in]