BTC
ETH
HTX
SOL
BNB
查看行情
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

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

以太坊爱好者
特邀专栏作者
本文約2694字,閱讀全文需要約4分鐘
本文會解釋冗餘機制給驗證者帶來的危險,並為信標鏈的VC 提議一種合理的故障轉移措施。
AI總結
展開
本文會解釋冗餘機制給驗證者帶來的危險,並為信標鏈的VC 提議一種合理的故障轉移措施。

編者按:本文來自以太坊愛好者(ID:ethfans)以太坊愛好者(ID:ethfans)

以太坊愛好者(ID:ethfans)

以太坊愛好者(ID:ethfans)

一級標題

以太坊愛好者(ID:ethfans)

以太坊愛好者(ID:ethfans)

一級標題

  • 以太坊愛好者(ID:ethfans)
  • ,作者:Aditya Asgaonkar,翻譯:阿劍,Odaily經授權轉載。
  • 一級標題

驗證者與驗證者客戶端
驗證者是信標鏈相關的概念,一個驗證者即是信標鏈共識過程的一個參與者。驗證者之間以公鑰來區別身份,而且每個驗證者都會在不同時間被分配以驗證信標鏈的任務。成功完成這些任務,就能獲得獎賞;反之,如果失職,不僅得不到獎勵,還會受到嚴厲的懲罰。在Phase 0 階段,這些指責僅限於在信標鏈上提議區塊和提交見證消息。
驗證者們需要使用一種叫驗證者客戶端(VC)的軟件來執行其職責1。所有的信標鏈客戶端團隊都將VC 作為他們的客戶端套裝軟件之一。

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

損失/懲罰的類型
獎勵落空:當一個驗證者在被分配到任務時沒能執行,TA 就不能獲得與該任務對應的獎勵。驗證者的權益(本金)不會減少,只不過失去了一次獲得獎勵的機會。

怠工懲罰:如果一個驗證者沒有發出見證消息,而那時候信標鏈又不能敲定區塊2,那驗證者的權益就會減少很小的一個數額(當然相關的獎勵也拿不到了)。

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

圖片描述

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

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

圖片描述
圖片描述

  • - 冗餘的VC 導致罰沒! -
  • VC 的故障轉移協議
  • 圖片描述

注意:我說“故障轉移”,指的是在一個VC 停止之後手動或者自動地重啟一個新的VC 實例,但是,我不建議使用自動化的故障轉移機制,因為如果實現不好,就會導致你有兩個VC 掛在線上!
上一節的要點是,驗證者在任何時候都只應該部署一個在線的VC 實例。但是, VC 總有出錯的時候,怎麼應對這種風險呢?質押者應該提前定義好自己的故障轉移協議(決定什麼使用應該重啟一個新的驗證者客戶端實例),來應對這種情況。在開發安全可靠的故障轉移協議之前,我們先來了解一種驗證者客戶端內置的安全特性:罰沒保護措施。
圖片描述

- 罰沒保護機制 -

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

完全同步的信標鏈節點(BN),來獲得關於信標鏈的信息

及時的罰沒保護數據庫,作為防故障裝置

  • 圖片描述
  • 良好的故障轉移協議必須把任一機制出錯的場景都考慮進去。前兩者是很容易保證的—— 可以維護冗餘的BN 以備新的VC 連接,而簽名密鑰也可以作為只讀文件,從備份文件夾中復制出來。
  • 注意:SD 卡不是可靠的存儲設備,所以,在樹莓派上運行VC 的質押者特別容易丟失自己的罰沒保護數據庫!

圖片描述

我所建議的故障轉移方案
一個簡單但有用的辦法是:維護一個冗餘的BN,並保證冗餘的驗證者密鑰容易取得。https://youtu.be/awBX1SrXOhk。
圖片描述
- 初始化的VC 設置與多場景的故障轉移協議 -
在這種設置下,多種錯誤都有分佈對應的處理方案:

ETH
开发者
歡迎加入Odaily官方社群