編譯 | Bite@YouMeLiveAPP
12月1日，以太坊2.0正式順利上線，在獲得收益的同時，也應了解其中的懲罰措施。本篇文章對懲罰做一個詳細解讀，無論選擇運行Prysm、Lighthouse、Teku、Nimbus或其它驗證客戶端，本文中的大部分資訊適用于所有用戶。
1. 什么是罰沒？
當驗證者在太坊網路中存在違反行為時，就會發生罰沒，罰沒不一定是惡意行為，例如，客戶端配置錯誤也可能導致罰沒。驗證者的行為可能會混淆或破壞系統的完整性，就會“罰沒”違規驗證者部分現有質押金額，造成ETH損失，至到驗證者被強制驅逐出驗證者行列并標記為“SLASHED”。此過程不可逆，
請不要將罰沒與怠惰處罰相混淆，怠惰處罰是驗證者離線時間長，無法履行職責而產生的正常資金損失，
罰沒的目標是阻止那些試圖損害以太坊2.0網路的驗證者，并反過來獎勵那些維護、管理和按預期操作網路的驗證者，罰沒的主要目的是為了減少在以太坊2.0網路上進行攻擊，比如在不同的史檢查點視圖上創建相互沖突的分叉驗證者，
正確遵循協議的驗證者在正常操作中永遠不會罰沒， 驗證者不會僅因為離線狀態而被罰沒，
2. 罰沒如何運行？
罰沒的目的是為了抑制那些試圖損害以太坊2.0網路的人，并通過促進好的行為者來加強鏈的安全性。雖然罰沒是一種懲罰方式，但作為一個善良的驗證者，如果客戶端配置不當，仍然有可能被罰沒，因此，如何了解正確設置和管理驗證者客戶端和操作系統至關重要，避免在不了解功能的情況下嘗試高級指令，
以下情況會發生罰沒
（1） 驗證者在同一slot提出兩個沖突區塊，其根數不同（基本上是內部數據的散列），如果這種行為不受到懲罰，驗證者在鏈中就會制造不必要的分叉和混亂，
（2） 驗證者在同一個slot上證明了兩個沖突區塊，這被稱為重復投票，同時也意味著驗證者可能試圖制造沖突的鏈上分叉，注意：僅僅對完全相同的區塊投了兩次票，并不是一種罰沒違法行為，
（3） 驗證者投出“環繞”票，也就是說驗證者是想投出違背史的票，這是一種罰沒違法行為，
3. 罰沒后會發生什么？
盡管有多種預防罰沒機制，但是每個驗證者只能對應一個密鑰對。這聽起來很簡單，但當配置了多個驗證者時，很容易錯誤地還原驗證者身份并復制一個已經運行的驗證者，在進行修改時，一定要確認使用/還原/設置正確的驗證者密鑰。
如果驗證者被罰沒，會發生一些事情：
（1） 被罰沒的驗證者將被迫在未來36天內退出信標鏈；
（2） 罰沒的驗證者會有三種懲罰類型；
（3） 當“吹哨人”將檢舉資訊包含在區塊中時，就會產生最低限度的懲罰；
（4） 在每個epoch開始時進行懲罰，直到驗證者離開退出為止；
（5） 在舉報資訊被列入區塊到違法者退出過程中，中間會有一個特殊的懲罰，這個特殊懲罰與在此期間還有多少其他驗證者也被罰沒成正比，罰沒最高額度可達到違規者的剩余余額，
這意味著，如果驗證者被罰沒，它將立即接受懲罰，并將繼續36天，直到退出結束，在第18天還會收到一次懲罰，罰沒的金額還受到同一時間段內同樣被發現有違法行為的驗證者數量的影響（即是協同攻擊還是單個不良行為者）。
最后，值得注意的是，被罰沒的驗證者不能重新進入驗證者隊伍行列中。如果想重新參與，需要生成一個新質押和密鑰才能繼續驗證者， 整個罰沒過程不可逆！
被罰沒的結果基本上就可以看作是質押ETH的緩慢“流血”過程，中途還會“大出血”，就這樣等36天后才可以退出信標鏈，剩余質押的ETH也同時退出，但在這段時間內會有相當一部分ETH流失。
4. 用戶常見錯誤導致罰沒
盡管前面提到的罰沒場景，一個普通用戶似乎是不可能做到，但作為誠實的驗證者，很可能一個不恰當的配置就會導致罰沒！以下是一些常見的可能出現的情況：
（1） 相同驗證密鑰同時在兩臺服務器上運行，其中一臺可能作為故障轉移，以防第一臺服務器宕機。
解釋：這是面臨罰沒最簡單的方法。如果故障轉移系統錯誤地認為第一個節點宕機了，那么可能會發現自己陷入了可能被罰沒的違法行為中。不要在兩臺機器同時運行驗證者密鑰，
（2） 在沒有遷移罰沒保護史記錄情況下，你可以將密鑰遷移到另一臺機器或另一個eth2客戶端。
解釋：另一個節點可能存在錯誤的時鐘同步情況，導致觸犯罰沒的違法行為，如果導入了罰沒保護史，就可以輕松避免。
（3） 在驗證者客戶端中刪除或丟失了罰沒保護史，
解釋：沒有罰沒保護史可能會導致一些問題，比如時鐘被打亂，無法創建罰沒區塊或投票。
（4） 使用沒有持久卷的容器化環境進行驗證
解釋：如果你正在使用Docker或者可能在Kubernetes等云環境中運行，需要為你的驗證者設置持久卷，這樣如果重新啟動pod或容器，罰沒保護史就不會清除。
（5） 可能導致罰沒錯誤的協議bug（這種情況不太可能）
解釋：在測試網上發生的大規模罰沒事件的催化劑往往是由于錯誤的操作流程所導致，然而，擁有罰沒保護資料庫和適當配置的驗證者卻沒有受到影響，例如時間服務器故障的bug，以及對區塊ID的不當處理。當Medalla測試網時間服務器發生故障，由于沒有罰沒史資料庫，大多數驗證者會被罰沒。
在選擇驗證者時，了解如何設置，配置，升級和排除任何安裝軟體的故障至關重要，在這里可以找到一個很好的資源來更好地理解質押Eth2的風險，
5. 誰來執行罰沒？
（1） Slasher
Slasher指的是一個獨立的軟體，其主要目的是檢測Slasher事件，你可以把Slasher看作是網路“警察”，由于檢測惡意消息需要額外的數據和進程，通常它與信標節點分開運行。為了檢測可罰沒消息，Slasher記錄了網路上每個驗證者的證明和提議史，并將這些史與廣播的內容進行交叉參考，以找到罰沒消息，如雙塊或周圍的投票。
網路只需要1個誠實的Slasher客戶端來監控網路，任何發現的罰沒都會傳播到整個網路，以便盡快將其放入一個區塊中，
（2） “吹哨人”獎勵
為了激勵罰沒檢測，會給予“吹哨人”驗證者獎勵，即提交一個有任何有效罰沒的區塊時，在信標鏈上獲得的獎勵。這些獎勵是給予針對罰沒中的驗證者，通常每個驗證者的獎勵約為0.1ETH，
雖然激勵檢測是有價值，但如果在Prysm中發現了罰沒，僅僅運行罰沒者客戶端并不能讓你獲得“吹哨人”獎勵，默認情況下，發現任何罰沒都會傳播到網路中，以盡快納入區塊，所以通常在檢測到罰沒后，獎勵會立即給提議者，而不是給運行Slasher的驗證者，
運行Slasher并不是為了盈利，而是一種利他行為，再次強調，只需要在網路中正常運作一個誠實的Slashe，就能抓到可罰沒的違法行為。值得慶幸的是，這是一個很低的準入門檻，我們設想有相當多的用戶和實體會運行Slasher確保網路安全，
6. 防止罰沒
罰沒是可預防的！有一些最佳做法可以確保不發生罰沒事件，但關鍵是要理解這些做法，使其發揮最佳作用，
（1） 本地罰沒保護資料庫
一些客戶端實現的防罰沒方法是本地簽名史資料庫，這個功能在Prysm的驗證者客戶端中是默認啟用。這個資料庫可以確保驗證者不會根據史記錄來簽署被認為是可罰沒的消息；更簡單地說，驗證者在決定是否應該簽署一個消息時，將資料庫視為唯一的真理來源，這種方法保證了單個驗證者不會執行重復的操作。
本地罰沒保護并不能防止使用相同的驗證者密鑰運行多個驗證者客戶端實例，因為資料庫是與其配對的驗證者本地資料庫，
資料庫只跟蹤該本地實例中驗證者的簽名。這也意味著，如果用戶將驗證者更換為不同的客戶端（例如，從Lighthouse轉移到Nimbus），或者轉移到新硬件設置（安裝新linux機器上，轉移到托管解決方案），也必須遷移簽名史資料庫，這將確保在任何新的客戶端上，過去的操作史都會被保留下來。
（2） 遠程罰沒保護
防止罰沒的另一種方式是使用Slasher，Slasher記錄了所有證明和區塊，驗證者在同意簽署消息之前會引用它。這種方法是一種比本地簽名史資料庫更強的防罰沒保護形式，但是和資料庫一樣，這種方法不能防止運行同一個驗證者的多個實例，
防止罰沒的另一種實現是使用slasher本身作為信標節點和驗證者客戶端之間的中間件。在驗證者客戶端提交區塊或證明之前，它會先詢問slasher是否可以罰沒，如果通過，數據將通過信標節點，這是最先進的罰沒保護形式，因為理想情況下，Slasher知道網路中發生的一切，并且記錄了每個驗證者的區塊和證明史。
7. 遷移罰沒保護史
在驗證過程中的某一階段，質押者可能需要執行的一項重要活動是將驗證者密鑰遷移到不同的機器或eth2客戶端上，有時，你可能想更質押客戶端以滿足需求。無論怎樣，你應該始終帶著罰沒保護史，
罰沒保護標準：EIP-3076
在eth2客戶端之間遷移罰沒保護史的官方標準，稱為EIP-3076。這個標準建議用JSON文件表示驗證者的罰沒保護史。在高層次上，這個文件包含：
1. 驗證史所對應鏈的生成狀態資訊（以區分測試網和主網）；
2. 關于正在運行的驗證者公鑰所有簽名區塊和證明的資訊；
通過導出這個文件，并遷移到另一臺計算機或eth2客戶端時導入它，你會得到很多好處，并且能夠保持保護，防止在你沒有存儲這個本地史記錄時可能發生的簡單罰沒狀況，
文章來源：
Eth2 Slashing Prevention Tips：
https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50
