信標鏈驗證者：冗餘風險和故障轉移

PA荐读｜2020-12-31 9:19

驗證者是信標鏈相關的概念，一個驗證者即是信標鏈共識過程的一個參與者。

驗證者與驗證者客戶端

驗證者是信標鏈相關的概念，一個驗證者即是信標鏈共識過程的一個參與者。驗證者之間以公鑰來區別身份，而且每個驗證者都會在不同時間被分配以驗證信標鏈的任務。成功完成這些任務，就能獲得獎賞；反之，如果失職，不僅得不到獎勵，還會受到嚴厲的懲罰。在Phase 0 階段，這些指責僅限於在信標鏈上提議區塊和提交見證消息。

驗證者們需要使用一種叫驗證者客戶端（VC）的軟件來執行其職責 1。所有的信標鏈客戶端團隊都將VC 作為他們的客戶端套裝軟件之一。

毋庸置疑，驗證者肯定希望自己的客戶端能全時在線，這樣才能獲得最大收益、避免所有懲罰。實現高可用的常見方法是設置冗餘和故障轉移機制。本文會解釋冗餘機制給驗證者帶來的危險，並為信標鏈的VC 提議一種合理的故障轉移措施。

損失/懲罰的類型

驗證者會面臨三種類型的損失，嚴重程度從小到大排列如下：

獎勵落空：當一個驗證者在被分配到任務時沒能執行，TA 就不能獲得與該任務對應的獎勵。驗證者的權益（本金）不會減少，只不過失去了一次獲得獎勵的機會。怠工懲罰：如果一個驗證者沒有發出見證消息，而那時候信標鏈又不能敲定區塊 2，那驗證者的權益就會減少很小的一個數額（當然相關的獎勵也拿不到了）。罰沒懲罰：若一個驗證者發出了違反Casper FFG 規則的見證消息，則該驗證者會立即被罰沒—— 該驗證者的權益會減少一定的比例3，而且該驗證者會被踢出，不能再參與共識（因此也與未來的獎勵無緣）。而且，因為現在信標鏈還不能轉讓和取回質押的ETH，所以驗證者剩下的錢會全部鎖在信標鏈上、無法動用（直到信標鏈開啟相關功能）。

（譯者註：作者在此處遺漏了一種損失：當信標鏈無法獲得終局性的時候，不僅沒有發出見證消息的驗證者會受到怠工懲罰，發出了消息的見證者也會有所損失，只是損失比前者更小；不過，作者在本文裡主要討論的是與驗證者離線相關的損失，所以也情有可原。）

前兩種損失類型是VC 掉線的驗證者可能會遭遇到的，但第三種，是只有不正確設置VC（或者是信標鏈遭遇明確攻擊時）的驗證者才會遇到的。

那麼談到故障轉移和冗餘措施，最要緊的應該是盡一切可能避免罰沒，然後才是提高在線時間，以減少獎勵落空和怠工懲罰的概率。

冗餘VC 設施的危險性

有些質押者可能認為，運行冗餘的VC 是對某一個VC 掉線的保險。但實際上，冗餘的VC 設施是不安全的，最終很有可能導致驗證者被罰沒！

來看一個實際的例子：

- 冗餘的VC 導致罰沒！ -

這個驗證者運行了兩個客戶端實例C1 和C2，兩個都配有在線的VC。不穩定的網絡條件（對等節點/鏈接問題、消息傳遞延遲、網絡分區，等等），導致兩個客戶端實例對哪條分叉才是主鏈沒有形成一致，C1 和C2 分別以B1 和B2 為當前的頂端檢查點（注意，是頂端檢查點，而不是頂端區塊，這種頂端檢查點的不一致可以在沒有任何惡意行為時發生）。輪到該驗證者執行其驗證者任務時，兩個客戶端實例各自發出了一條以自己所認定主鏈檢查點為目標檢查點的投票消息。結果就是這兩條見證消息的目標檢查點不同（但都是同一個高度）。這就是雙重投票，違反了Casper FFG 的規則，會導致該驗證者被罰沒。

VC 的故障轉移協議

注意：我說“故障轉移”，指的是在一個VC 停止之後手動或者自動地重啟一個新的VC 實例，但是，我不建議使用自動化的故障轉移機制，因為如果實現不好，就會導致你有兩個VC 掛在線上！

上一節的要點是，驗證者在任何時候都只應該部署一個在線的VC 實例。但是， VC 總有出錯的時候，怎麼應對這種風險呢？質押者應該提前定義好自己的故障轉移協議（決定什麼使用應該重啟一個新的驗證者客戶端實例），來應對這種情況。在開發安全可靠的故障轉移協議之前，我們先來了解一種驗證者客戶端內置的安全特性：罰沒保護措施。

- 罰沒保護機制-

罰沒保護機制：所有信標鏈客戶端團隊開發的VC 軟件都有罰沒保護機制，作為應對意外事件的自動防故障裝置。根據罰沒規則，只有成對的見證消息才會導致罰沒，只需檢查這一對消息就可判斷結果。那麼，VC 可以存儲自己所簽名過的所有消息和區塊，存儲在本地的罰沒保護數據庫裡面。在簽名任何新的見證消息/區塊時，VC 只需檢查新消息與數據庫中的舊消息是否衝突（是否會形成被罰沒的消息對），並且只簽名不會衝突的新消息即可。

因此，VC 需要三項機制來保證正確和安全的運營：

完全同步的信標鏈節點（BN），來獲得關於信標鏈的信息驗證者簽名私鑰，來實際簽署消息及時的罰沒保護數據庫，作為防故障裝置

良好的故障轉移協議必須把任一機制出錯的場景都考慮進去。前兩者是很容易保證的—— 可以維護冗餘的BN 以備新的VC 連接，而簽名密鑰也可以作為只讀文件，從備份文件夾中復制出來。

但最後一項—— 及時（up-to-date）的罰沒保護數據—— 不容易備份及保證可用！有很多種可能發生的錯誤都會導致數據庫完全丟失：文件系統崩潰、硬盤故障、不可抗力造成的硬件丟失，等等。數據備份和可用性是一個價值數十億美元的問題，現在也已經有很多方案了，例如，逐個區塊/逐個文件監控備份，RAID 可用性，等等。不過，我們有一個小技巧，可以用來重建丟失的罰沒保護數據庫！數據庫可以按最小化格式重建出來，並不需要所有已簽名消息的完整歷史。此種重建方法的實用程序可以在adiasg/eth2-slashing-protection-rebuild 代碼庫中找到。

注意：SD 卡不是可靠的存儲設備，所以，在樹莓派上運行VC 的質押者特別容易丟失自己的罰沒保護數據庫！

我所建議的故障轉移方案

一個簡單但有用的辦法是：維護一個冗餘的BN，並保證冗餘的驗證者密鑰容易取得。