以太坊2.0 Staking老司機指南 : 避免罰沒的三大技巧

本文討論了以太坊2.0網絡中的罰沒機制，對于Staking參與者，你需要了解哪些情況會導致罰沒，以及如何避免被罰沒。本文檔中提供的大多數信息與客戶端選擇無關，這意味著它將適用于所有用戶，而不管他們選擇運行Prysm、Lighthouse、Teku、Nimbus還是其他以太坊2.0客戶端。

原文作者是Prysmatic?Labs聯合創始人Raul?Jordan。

*重要免責聲明*

PrysmaticLabs對用戶的資金損失不承擔任何責任，無論原因是什么，包括客戶端漏洞或文檔錯誤，這種責任的免除延伸到了罰沒過程。盡管每個以太坊2.0客戶端都盡最大努力確保代碼庫是安全的，但與其他任何開發項目一樣，總是會存在出錯的可能性。參與以太坊2.0是一項有風險的活動，重要的是參與者需要研究并理解他們要承擔的風險及責任。

什么是罰沒？

當一個驗證者表現出與以太坊網絡相爭對的行為時，就會發生罰沒。罰沒不一定是因為有惡意意圖，它也有可能是因為錯誤的配置。驗證者的行為可能會使得系統變混亂，或破壞其完整性，因此，這些對網絡造成危害的驗證者，其質押的ETH就會遭到懲罰，而這是不可逆轉的。

不要將罰沒和不活動處罰混淆，罰沒的目標是抑制那些試圖傷害以太坊2.0網絡的人，并反過來獎勵那些按計劃維護、管理和運營以太坊2.0網絡的人。罰沒的的主要目的是減輕在以太坊2.0網絡上執行的攻擊，例如在不同的歷史檢查點視圖上創建相互沖突的驗證者分支。

正確遵循協議的驗證器在正常操作中永遠不會發出可遭到罰沒的投票，驗證器不會因為離線而遭到罰沒。

InfStones推出以太坊驗證者服務:4月19日消息，Web3基礎設施提供商InfStones宣布推出以太坊驗證者服務，旨在滿足以太坊上海升級后的市場需求，支持用戶一鍵設置自己的驗證節點，機構實體可以一次單擊批量處理多達1000個驗證者。此外，InfStones還將與其他流動性質押協議合作以降低32ETH質押門檻。（prnewswire）[2023/4/19 14:12:57]

罰沒的工作方式

罰沒的行為會破壞掉那些傷害以太坊網絡的驗證者的質押資金，強迫他們離開網絡，并通過促進好的參與者來加強區塊鏈的安全性。

盡管罰沒是一種懲罰方式，但即便是一個正常用戶，如果其驗證器配置不正確，仍有可能遭到罰沒。因此，了解如何正確設置和管理驗證器客戶端和操作系統是至關重要的，用戶還應避免在不了解其全部功能的情況下嘗試使用高級指令。

在以下情況下，驗證者會遭到罰沒：

驗證器在同一個slot中使用不同的root提出兩個沖突的區塊。如果這類操作沒有遭到懲罰，那么驗證者就很容易創建不必要的分叉，或造成混亂。注：簡單地提出相同的區塊兩次，并不會遭到罰沒；

驗證器在同一個slot中證明兩個沖突的區塊。這被稱為雙重投票，也意味著驗證者可能試圖創建沖突的鏈分叉。注：簡單地為相同區塊投票兩次，并不會遭到罰沒；

驗證器投出的投票“包圍”或被之前的投票“包圍”，這意味著驗證者試圖投票反對歷史，這種情況下就會遭到罰沒；

以太坊2.0surround投票，來自https://github.com/protolambda/eth2-surround

以太坊基金會資助籌建zkEVM團隊:以太坊基金會在定期公布其支持的團隊研究與開發進度的文章中表示，過去幾個月的時間已經組建了一個名為zkEVM的團隊，希望能將EVM （以太坊虛擬機）的所有操作碼直接通過ZK （零知識證明）電路實現，以實現以太坊的智能合約可以以最少的調整部署至二層網絡，比如zkSync。zkEVM團隊表示，目前處于早期階段，正在設計和構建第一個原型。[2021/8/13 1:53:34]

遭到罰沒后，會發生什么？

盡管存在多個防止罰沒的機制，但每個驗證器密鑰對僅被一個驗證器使用是至關重要的。這聽起來很容易，但是當配置了多個驗證器時，很容易錯誤地還原驗證器并復制已經運行的驗證器。進行更改時，請始終確認正在使用/恢復/設置正確的驗證器密鑰。

你可以在這里找到一些其他資源。

如果驗證器遭到罰沒，則會發生很多事情：

遭到罰沒的驗證器被迫在36天內退出信標鏈；

遭到罰沒的驗證器會面臨三種懲罰類型；

當被提議的舉報人在一個區塊中包含舉報信息時，將受到最低處罰；

在每個epoch周期開始進行懲罰，直到驗證器離開退出隊列；

在舉報信息被包括在一個區塊內，以及遭罰沒的驗證器退出之間的中間時間，將實施特別處罰，這一特殊處罰與在此期間有多少其他驗證器遭到罰沒成比例。所適用的最大值，可達到相關罰沒對象的所有有效余額。

這意味著，如果驗證器遭到罰沒，它會立即受到懲罰，并將持續受到約36天的處罰，直到其可以退出為止，并且在18-36天的時間內，還會受到一次性罰款，而罰沒的金額還受到同一epoch時期遭罰沒的驗證器數量的影響。有關更詳細的說明，請訪問此處。

動態 | 游戲Gods Unchained成以太坊鏈上交易量最大應用:據數據分析平臺 Alethio 的報告顯示，基于以太坊的游戲 Gods Unchained 在上周推出交易市場功能后，鏈上交易數據已遠超排名第二的 USDT。這是一款利用非同質化代幣（NFT）概念的卡牌類游戲，用戶可以通過交易市場篩選卡牌、創建卡牌組合或與其他用戶交戰。[2019/11/25]

最后，值得注意的是，遭到罰沒的驗證器無法重新進入驗證器集。如果驗證者要繼續驗證，就需要進行新的質押以及生成新的密鑰，而罰沒是不可逆的！

總的來說，遭到罰沒會導致你質押的ETH不斷變少，并在中途遭受重大損失。在36天后，你可以退出信標鏈，也可以撤回所有剩余的ETH，而在這36天的時間段內，你會損失很大一部分的ETH。

會導致罰沒的常見用戶錯誤

盡管上面提到的罰沒場景對普通用戶而言似乎是不可能發生的，但不正確的配置，很可能會導致誠實的驗證者也會遭到罰沒！以下是一些可能發生這種情況的場景：

1、相同的驗證密鑰同時運行在兩個服務器上，其中一個可能用作故障轉移，以防第一個服務器出現故障。

說明：這是最容易讓你遭到罰沒的方式，如果你的故障轉移系統誤報第一個節點已關閉，你可能會發現自己處在遭遇罰沒的境地。

請不要同時在兩個地方運行驗證密鑰！

2、你把密鑰遷移至另一臺計算機或另一個以太坊2.0客戶端，而沒有遷移你的罰沒保護歷史記錄；

說明：你的另一個節點可能有一個不正確同步的時鐘，這可能會導致你遭遇罰沒，如果你遷移了罰沒保護歷史記錄，就可以輕松避開這種情況。

聲音 | Primitive創始人萬卉：Defi是DApp概念在以太上涼了之后的以太坊自救概念:Primitive Ventures創始人萬卉發微博表示，有很多朋友讓我寫文章講Defi，其實不用寫任何文章，一句話就能解釋清楚—Defi是DApp概念在以太上涼了之后的以太坊自救概念。[2019/7/15]

3、你在驗證器客戶端中刪除或丟失了罰沒保護歷史記錄；

說明：失去罰沒保護歷史記錄，可能會導致一些問題，比如你的時鐘被弄亂，從而產生會遭到罰沒的區塊或投票。

4、使用沒有持久卷的容器化環境進行驗證

說明：如果你使用Docker運行，或者可能在云環境中運行，則需要為驗證器設置持久卷，這樣，如果pod或容器重新啟動，則不會清除罰沒保護歷史。

5、可能導致罰沒錯誤的協議漏洞

說明：測試網上發生的大規模罰沒事件的催化劑，通常是由于客戶端實現中的漏洞。但是，具有罰沒保護數據庫和正確配置的驗證器并沒有受到影響。這些示例包括時間服務器故障以及區塊ID處理不當的錯誤。當Medalla測試網中發生服務器故障時，大多數驗證器都遭到罰沒了，因為它們沒有一個持久化的罰沒歷史數據庫。

選擇驗證器時，了解如何設置、配置，升級和排除任何已安裝軟件的故障是至關重要的。在這里可以找到一個很好的資源來更好地理解參與以太坊2.0Staking的風險，這里還有另一個解釋如何檢測罰沒條件的資源。

誰在實行罰沒？

罰沒者

罰沒器是指一個單獨的軟件，其主要目的是檢測可罰沒的事件。你可以把罰沒器想象成以太坊2.0網絡的“警察”，由于檢測惡意消息所需的額外數據和進程，通常這些罰沒器是獨立于信標節點運行的。為了檢測可罰沒的消息，罰沒器記錄網絡上每個驗證器的證明和提議歷史記錄，并將該歷史記錄與廣播的內容交叉引用，以找到可罰沒的消息，例如雙重區塊或surrounding投票。

動態 | 距離以太坊硬分叉約1小時20分鐘:以太坊硬分叉實時播報：據amberdata數據，目前距離以太坊君士坦丁堡和圣彼得堡雙分叉還有約1小時20分鐘，當前區塊高度為7,279,732，距離硬分叉高度還有268個區塊。據etherscan數據，目前網絡哈希率為154844.1GH/s，與此前相比基本持平。[2019/3/1]

網絡所需要的是一個誠實的罰沒器客戶端來監視網絡，因為發現的任何罰沒都會傳播到整個網絡，以便盡快將其放入一個區塊中。

舉報人獎勵

為了激勵罰沒檢測，驗證器將獲得一種“舉報人獎勵”，這是在信標鏈上對提交具有任何有效罰沒的區塊的獎勵。這些獎勵是給予那些參與罰沒的驗證者的，通常每個驗證者大約有0.1ETH獎勵。

雖然激勵檢測是有價值的，但如果你在Prysm中發現了罰沒，僅運行一個罰沒器客戶端是不會獲得舉報人獎勵的。默認情況下，發現的任何罰沒都會廣播到網絡以盡快包含在區塊中，因此，通常在檢測到罰沒后，獎勵會立即發給提議者，而不是發給運行罰沒器的驗證者。

運營一個罰沒器并不意味著有利可圖。罰沒本就是罕見的，舉報人獎勵也被設置地很低。本質上，運營罰沒器相當于一種利他行為，再次強調，網絡中只需激活一個誠實的、功能正常的罰沒器，即可捕獲到違規行為。幸運的是，這是低門檻的，我們設想會有相當多的用戶和實體將運行罰沒器來確保網絡安全。

罰沒預防針

我們有好消息要告訴大家，罰沒是可以預防的！有很多最佳實踐可確保我們不會遭到罰沒，但重要的是要了解它們。

1、本地罰沒保護數據庫

一種由多個客戶端實現的罰沒保護方法是本地簽名歷史數據庫。該功能在Prysm的驗證者客戶端中是默認啟用的。該數據庫確保驗證器根據其自身的歷史記錄不對被視為可罰沒消息的消息進行簽名。更簡單地說，驗證器在決定是否應對消息進行簽名時，會將數據庫視為其唯一的真實來源。這種方法確保單個驗證器不會執行重復的操作。

需要注意的是，本地罰沒保護無法防止使用相同的驗證器密鑰運行多個驗證器實例。

該數據庫僅跟蹤該本地實例中驗證器的簽名事件。這也意味著，如果用戶將其驗證器更改為其他客戶端，或轉移到新的硬件設置，那么還必須遷移簽名歷史數據庫。這將確保在任何新客戶端上保留過去操作的歷史記錄。

2、遠程罰沒保護

防止罰沒的另一種替代實現方式是使用罰沒器。罰沒器記錄它收到的所有證明和區塊，驗證器在同意簽署消息之前會引用它。與本地簽名歷史數據庫相比，這種方法是一種更強的罰沒保護方式，但與數據庫一樣，此方法無法防止運行同一驗證器的多個實例。

防止罰沒的另一種實現，是將罰沒器本身用作信標節點和驗證器客戶端之間的中間件。在驗證器客戶端提交區塊或證明之前，它首先詢問罰沒器這是否是可罰沒的。

如果檢查通過，數據將通過信標節點。這是最先進的罰沒保護形式，因為理想情況下，罰沒器了解網絡中發生的所有事件，并記錄了每個驗證器的區塊和證明歷史。但有一點需要注意的是，在Prysm中，遠程罰沒保護還沒有優化，因為我們的罰沒器仍然是資源消耗大戶。鑒于我們的罰沒器資源消耗很高，這可能會導致你的驗證器錯過證明或區塊。遠程罰沒保護旨在作為本地罰沒保護之上的附加層運行。出于安全原因，用戶無法在Prysm中禁用本地罰沒保護。

3、遷移你的罰沒保護歷史

在驗證過程中的某個特定時刻，質押者可能需執行的一個重要活動，是將其驗證密鑰遷移到另一臺機器或不同的以太坊2.0客戶端。

有時，你可能希望切換Staking機器，或者你可能希望遷移到適合你的不同的以太坊2.0客戶端。無論如何，你都應始終攜帶好你的罰沒保護記錄。

罰沒保護標準：EIP-3076

目前有一個官方標準用于遷移以太坊2.0客戶端之間的罰沒保護歷史記錄，它被稱為EIP-3076。該標準建議在JSON文件中表示驗證器的罰沒保護歷史記錄。該文件包含了：

有關驗證歷史記錄的鏈的初始狀態信息；

有關用戶正在運行的驗證器公鑰的所有簽名區塊以及簽名證明信息；

通過導出此文件，并在遷移到另一臺計算機或以太坊2.0客戶端時導入它，你將獲得大量好處，并能夠免受未存儲此本地歷史記錄的情況下的簡單罰沒條件。

將現有的驗證密鑰導入Prysm

截至發稿時，在Prysm的v1.0.1版本中，Prysm不允許用戶將EIP-3076罰沒保護JSON文件導入驗證器客戶端。這是Prysm團隊的首要任務，可能會在以太坊2.0主網上線后的下一個版本中實現這個功能。

從Prysm導出你的罰沒保護歷史

截至發稿時，在Prysm的v1.0.1版本中，Prysm不允許用戶將罰沒保護歷史記錄導出到EIP-3076罰沒保護JSON文件中，同樣的，Prysm團隊正在抓緊實現這一目標。

如果你確定希望遷移機器，我們建議你等到Prysm支持導出罰沒保護歷史記錄之后。如果實在等不及，請記住以下一些重要事項：

關閉你的信標節點以及機器1上的驗證器，確保它沒有作為系統進程運行。你可以使用操作系統的進程監視器工具或命令行工具進行檢查，并檢查是否包含名稱“prysm”，“validator”或“beacon”。

請注意你的錢包目錄位置。如果你在啟動Prysm時使用默認值，則可以在“驗證者帳戶列表”輸出的頂部查看其路徑，該路徑因操作系統而異。

獲取整個目錄并將其遷移至你的下一臺計算機。

如果你修改了驗證器的datadir，也請將該目錄遷移到下一臺計算機。

至少等待幾個epoch時間段，在第二臺機器上同步信標節點，然后在第二臺機器上啟動驗證器客戶端。

確保不在機器1或其他任何地方運行相同的密鑰。

Tags：以太坊PRYETHING以太坊交易所清算PRY幣EthereumPayEagle King Coin

PEPE