跳到正文
Financial Context Wiki

弱主觀性：可信檢查點與安全 PoS 同步

弱主觀性讓權益證明節點在獲得足夠新的受信任檢查點後，能夠客觀地向前驗證。了解舊簽名如何支持長期歷史、檢查點的新穎性和來源獨立性如何被驗證，以及檢查點同步不證明什麼。

更新於

僅供教育用途；非投資建議。投資可能導致損失。

直接回答

弱主觀性是一種權益證明安全模型，其中節點可以在從通過信任或社會確認管道獲得的足夠近期檢查點開始後，根據協議規則驗證區塊、狀態轉換、投票和分叉選擇。“弱”主觀輸入即為起點。這並不意味著可以隨意選擇後續區塊：一旦固定，節點必須拒絕不包含該檢查點的歷史，並照常向前驗證。

問題在於歷史的不確定性。一個敵手如果從已退出且無法再被經濟懲罰的驗證者那裡獲取鑰匙，可能構建一個擁有看似有效簽名的長期替代歷史。一個在那些驗證者可被削減期間觀察過正規鏈的節點保留了有用的記憶。一個全新的節點、其資料庫已被刪除的節點，或者超過協議安全近期窗口而離線的節點，可能無法僅從創世資料和點對點訊息中辨識社會公認的歷史。

在 Ethereum 上，弱主觀性檢查點是一個 epoch 和 block_root，客戶端將其視為絕對錨點。成功的同步必須證明該規範路徑在該時期包含該根；不匹配是嚴重錯誤，而不是分叉選擇投票。弱主觀性檢查點也不同於普通的最終化檢查點：如果節點首次遇到兩個互相衝突的最終化歷史且沒有先前記憶，僅靠最終性規則無法確定哪個社會歷史是規範的。

不要將 Ethereum 的機制普及化。CometBFT 輕客戶端從配置好的 trusting_period 中的一個受信任標頭開始，並使用驗證者集合的重疊、簽名、時間界限以及見證者來傳遞信任。Ouroboros Genesis 研究則定義了一個鏈選擇規則，旨在根據其所述的安全模型從受信任的創世區塊啟動。因此，「權益證明」並不意味著單一的檢查點格式、單一的週期公式或單一的啟動程序。

同樣要將弱主觀性與同步捷徑區分開來。檢查點同步可以減少啟動時間和歷史狀態處理，但速度並不是安全性的定義。受信任的根不會驗證提供它的網站，不會驗證客戶端所述假設之外的執行負載，不會恢復已修剪的歷史，不會證明數據可用性，也不會使被遮蔽的節點集合變得誠實。

如何驗證弱主觀性自舉

1. 識別確切的協議和安全模型

記錄 network、chain ID、創世根或雜湊值、活躍分叉或運行時、客戶端版本、檢查點類型及共識規範。確定該協議是否需要最近的社會檢查點、可信標頭加驗證者集合、最終性證明鏈，或僅在不同模型下使用創世塊。切勿在沒有其規則的情況下，將 Ethereum 的 compute_weak_subjectivity_period 或 CometBFT 的 trusting_period 移植到其他鏈中。

2. 決定現有的信任是否仍然有效

盤點節點最後一次本地驗證的已最終化檢查點，其紀元或高度及時間、當前的時間來源，以及任何資料庫恢復情況。使用協議的即時規則和狀態計算年齡，而不是依靠記憶的日曆估算。對於 Ethereum，Phase 0 指南測試 current_epoch <= ws_state_epoch + ws_period；Electra 將期間計算改為依賴總活躍餘額和餘額流動。如果信任已過期，應透過帶外方式獲取新的錨點，而不是在不受信任的節點上更加努力嘗試。

3. 獲取並核實檢查點

從獨立管理且資料來源獨立的管道取得同一檢查點，例如自行運行的節點、其他營運者、多個用戶端團隊，以及採用不同基礎設施的區塊瀏覽器。記錄每個來源、取得時間、網路、epoch 和完整根。五個複製同一上游的 URL 仍屬於一個故障域。簡單多數不能取代來源獨立性、認證傳輸或社會事件審查。

4. 綁定每個檢查點欄位

在檢查點值之前驗證網絡和創世身份。保留完整的根而不截斷，並將其與精確的紀元或區塊高度配對，如有需要，還需包括狀態、分叉版本和獲取時間。Ethereum 的指南使用 block_root:epoch_number；CometBFT 初始化還綁定了受信任的區塊頭和驗證者集合以及信任參數。附加到錯誤鏈或高度的正確根不是有效的錨點。

5. 強制執行失效關閉的同步路徑

透過用戶端的文件化介面設定檢查點並保留啟動日誌。同步期間，要求檢查點紀元的規範路徑等於所提供的 block_root。Ethereum 指南要求在斷言失敗時輸出描述性嚴重錯誤並退出程序。不要靜默丟棄檢查點、回退到對等方多數、以較新的對等方回應覆蓋它，或在驗證者的共識視圖不明確時繼續簽署。

6. 分離已驗證和未驗證的層

分別跟踪共識檢查點信任、信標或共識區塊驗證、執行負載狀態、執行狀態同步、歷史回填以及應用證明。Ethereum 樂觀同步允許檢查點錨的 ExecutionPayload 被假定為 VALID，而無需先將其提供給執行引擎，同時樂觀節點不得執行驗證者職責。Lighthouse 檢查點回填檢查歷史哈希鏈完整性和提議者簽名，但預設情況下不重建每一個歷史狀態。

7. 刷新、監控並演練恢復

在適用期限內保留充足餘量，設定提醒並及時更新檢查點。監控最終化、時鐘狀態、用戶端分歧、execution_optimistic 狀態、對等節點多樣性、檢查點年齡和回填缺口。演練如何從資料庫遭刪除、檢查點過期、來源互相矛盾或服務商不可用的情況復原。保留錨點與決策的簽署記錄，但不要把封存的檢查點當成永久可信的近期檢查點。

範例解析

Ethereum 檢查點剩餘餘量

使用一個示例狀態，其適用的 Electra 參考計算給出 ws_period = 3,532 epochs。假設 current_epoch = 420,000 且獨立驗證的檢查點為 checkpoint_epoch = 418,200：

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

指南的近期性測試是 420,000 <= 418,200 + 3,532，因此檢查點在此期間內。在 32 slots * 12 seconds = 6.4 minutes per epoch 時，其年齡為 1,800 * 6.4 / 1,440 = 8 days。剩餘餘量為 3,532 - 1,800 = 1,732 epochs，或 1,732 * 6.4 / 1,440 = 7.6978 days。這使用的是參考表期間，而非實時網路承諾；客戶端必須從實際分叉和狀態計算。

過期的檢查點無法由更多節點修復

假設 current_epoch = 500,000、checkpoint_epoch = 496,000，以及適用的 ws_period = 3,532 epochs：

checkpoint_age = 500,000 - 496,000 = 4,000 epochs。

因為 500,000 > 496,000 + 3,532，檢查點已經過期 4,000 - 3,532 = 468 epochs。在每個時期 6.4 分鐘下，這超出了 468 * 6.4 / 60 = 49.92 hours 的界限。從 100 個節點下載相同的過期根不會恢復該假設；運營者需要從受信任、經證實的渠道獲取足夠最近的檢查點。

來源數量與來源獨立性

一名操作員收到五個回應。四個報告 epoch = 600,000 和一個標示為 root_A 的相同完整根，而一個報告不同的完整根標示為 root_B。調查顯示，三個一致的網站都代理相同的託管節點；第四個是操作員自己的節點。表面上的一致性為 4 / 5 = 80%，但它僅代表兩個獨立的分支。在要求三個獨立管理和數據路徑的政策下，該檢查點尚未被批准。第三個獨立操作員確認 root_A，異議的服務被孤立，來源記錄解釋了這一決定。

CometBFT 風格的信任期預算

考慮一條配置為 unbonding_period = 21 days 的鏈，以及運營者選擇的 trusting_period = 14 days，符合信任期必須短於解鎖期的要求。一個經過 11 days 時間的受信任區塊頭具有 14 - 11 = 3 days 的餘量。每日刷新目標留下操作餘量。如果客戶端在 16 days 後返回，該區塊頭已超過其信任期兩天，必須通過新的受信任初始化來替換；Ethereum 週期公式無法決定此 CometBFT 情況。

風險與審查失敗

  • 網路錯誤： 來自測試網、分叉鏈、複製鏈或不同創世區塊的有效根，可能把節點錨定到錯誤歷史。
  • 檢查點過期： 超出適用期間的根，不再滿足對近期驗證者集合的安全假設。
  • 期間公式錯誤： 分叉升級、驗證者餘額、輪換規則、解綁期和安全參數都可能改變期限。
  • 來源單一： 多個端點可能共用同一節點、雲端帳號、資料庫、DNS 服務商或營運方。
  • 散布管道遭入侵： 惡意版本、網站、套件、DNS 回應或支援訊息都可能替換檢查點。
  • 截斷比對： 只比對前綴、截圖或格式化識別碼，可能掩蓋完整根的差異。
  • 欄位不匹配： 正確的根若配上錯誤的紀元、高度、狀態、分叉或鏈，就不是同一個檢查點。
  • 依賴對等節點多數： 遭遇日蝕攻擊的節點可能看見大量惡意對等節點；節點數量不能推翻可信錨點。
  • 靜默回退： 用戶端或封裝器若忽略被拒絕的檢查點，就會破壞預期的故障關閉控制。
  • 相互衝突的最終歷史： 新節點不能只靠兩個分支都標示為最終狀態來解決共識故障。
  • 時鐘錯誤： 本機時間不準會破壞時隙、紀元、年齡、信任期和未來區塊標頭檢查。
  • 樂觀狀態混淆： 已匯入的共識區塊仍可能包含尚未完全驗證的執行酬載。
  • 過早履行驗證者職責： 在樂觀、未同步或錨點不確定時簽署，可能造成錯誤投票或罰沒。
  • 歷史完整性混淆： 即使即時鏈頭有效，檢查點同步與回填也可能不包含歷史狀態。
  • 回填簽章無效： 透過雜湊相連的歷史區塊，仍須執行協議要求的提議者簽章檢查。
  • 執行或應用證明不足： 共識錨定不能證明任意 RPC 值、合約主張或鏈外索引正確。
  • 資料可用性缺口： 知道狀態根不代表能取得每個區塊本體、Blob、見證或歷史記錄。
  • 復原計畫失效： 營運者若在故障期間才發現檢查點過期，可能找不到獨立來源。
  • 社會協調遭俘獲： 治理方、用戶端團隊、區塊瀏覽器、交易所和營運者可能共享誘因或依賴。
  • 錯誤地視為通用規則： 其他 PoS 設計可能採用不同假設、證明鏈、信任期或創世引導保證。

常見的誤解

弱主觀性是否意味著啟動後協議規則是主觀的？

不。節點通過社交或受信任的渠道接受特定的最新錨點，然後向前應用確定性的驗證和分叉選擇規則。與錨點衝突的區塊將被拒絕。

任何已完成的檢查點是否自動成為安全的啟動檢查點？

不。它必須屬於指定的網絡和正典社會歷史，依據適用規則要夠近期，包含必要欄位，並通過可信的經證實路徑。對攻擊者提供的歷史首次觀察到的最終性並不建立來源。

從創世區塊同步會消除長程攻擊問題嗎？

不適用於其安全模型需要最近弱主體性檢查點的協議。從創世區塊重播內部有效的簽名，無法告訴新節點社群實際遵循了哪一個舊的最終化歷史。其他協議可能在不同假設下提供不同的創世引導保證。

檢查點同步是否驗證所有歷史執行和狀態？

不。客戶端行為是分層且依實作而異的。節點可能信任或樂觀地匯入錨點，分別同步當前執行狀態，並僅回填區塊鏈結和提議者簽名，而不重建所有歷史狀態。

一個硬編碼的檢查點可以永遠被信任嗎？

不。一個檢查點是綁定到特定網路的，沒別的。它可以作為審計記錄或歷史約束保持其用途，但一個最近信任假設已過期的節點，需要一個適當近期的錨點，或者遵循該協議指定的恢復過程。

相關主題

來源

導覽

搜尋知識庫...