Prysm 中 Safe Head 的快速確認規則（上）
本文檔重點介紹我們在 Prysm 中實現的快速確認算法，這是更廣泛探索的第一部分。我們稱之為第一部分，是因為這項工作仍處於早期階段——目前已有白皮書和安全證明，但尚未經過全面審查，而且據我們所知，目前還沒有其他客戶端實現該算法。與所有實現一樣，算法中也存在一些 bug 和錯誤。在本文中，我們將介紹我們在 Prysm 中的實現，並分享在主網運行過程中的一些有趣觀察。
參考：
- 以太坊 PoS 確認規則，作者：Aditya Asgaonkar，Francesco D'Amato、Roberto Saltini、Luca Zanolini 和 Chenyi Zhang 參與貢獻
- 以太坊共識協議的快速確認規則，作者：Aditya Asgaonkar、Francesco D'Amato、Roberto Saltini、Luca Zanolini 和 Chenyi Zhang
- Aditya Asgaonkar 和 Terence 編寫的Prysm 快速確認實現代碼
- Terence 的Prysm Forkchoice 實現講解
背景
什麼是安全頭？
在以太坊上，安全區塊是指被認為不會發生短期重組的最新區塊，這意味著它不太可能因分叉而被其他區塊取代。當一個區塊植根於一個已證明的檢查點並獲得足夠多的驗證者證明時，它最終會變得安全。傳統上，客戶端將最新的已證明的檢查點（也是 LMD GHOST 分叉選擇算法的起點）稱為安全區塊，或將最新的未實現的已證明的檢查點（無論是否已在鏈上實現）稱為安全區塊。安全區塊允許鏈上的消費者安全地推進，而無需等待需要更長時間才能實現的最終性。
如何獲得安全頭？
執行層客戶端（例如 Geth、NethermindETC）公開專用的 RPC 端點來查詢區塊頭、安全區塊頭以及最終確定的執行區塊。區塊鏈實時數據的消費者可以決定如何根據這些信息採取行動：
- 最終確定的頭部：
eth_getBlockByHash("finalized", ...) - 安全頭：
eth_getBlockByHash("safe", ...) - 頭部：
eth_getBlockByHash("latest", ...)
安全頭是如何傳遞給EL的？
安全區塊頭通過引擎 API從共識層傳遞到執行層，具體來說，是在區塊頭更新期間通過engine_forkchoiceUpdated方法傳遞。不同的 CL 客戶端對安全的理解可能有所不同，例如使用 1.) 最新的合理檢查點，而其他客戶端（例如默認的 Prysm）則使用 2.) 最新的未實現合理檢查點。在本文中，我們將探討一種替代方案：使用 3.)快速確認的區塊作為安全區塊。
{ "jsonrpc" : "2.0" , "method" : "engine_forkchoiceUpdatedV2" , "params" : [ { "headBlockHash" : "0x..." , "safeBlockHash" : "0x..." , ← this is the safe head "finalizedBlockHash" : "0x..." } , { "timestamp" : "0x..." , "random" : "0x..." , "suggestedFeeRecipient" : "0x..." } ] , "id" : 1 }什麼是快速確認區塊？
快速確認區塊是指在同步網絡（證明消息到達時間少於 8 秒）和有限的對抗能力下，即使在最終確定之前，也極有可能保留在規範鏈上的區塊。快速確認規則為用戶和應用程序提供了一種啟發式方法，使其能夠在區塊提議後的幾秒到一分鐘內將其視為已確認。它通過檢查The Block是否已獲得足夠多的可觀察驗證者投票並滿足特定的安全閾值來做到這一點。與通過罰沒條件保證不可逆性的最終性不同，快速確認基於網絡條件和驗證者行為，提供了更快但更弱的保證。
Prysm 實現
本節概述了 Prysm 在實驗性PR中實現的安全區塊頭。由於該實現仍處於積極開發階段，可能會有所變更，您可以直接跳至測試觀察部分。為了啟用快速確認作為安全區塊，必須設置兩個標誌：
- 選擇安全塊模式：
-safe-block=fast-confirmation（默認值：unrealized-justified） - 指定拜占庭Threshold：
-fast-confirmation-byzantine-threshold=33（默認值：33）- 這裡的拜占庭指的是惡意行為，例如拒絕證明、在衝突的子樹上投票ETC。
快速確認時間表
在時隙n的第 0 秒，在理想情況下，Prysm 信標節點會定期調用UpdateHead更新頭信息。從n - 1的第n-1秒開始，它開始收集、驗證和統計及時塊時隙n-1證明信息。如果一切順利， n-1的The Block可以在 8 秒內快速確認（假設拜占庭Threshold低於 30%，我們稍後會解釋為什麼會這樣計算）。
修改 forkchoice 和 node 對象
Forkchoice F o r k c o i c e對象現在緩存一個新字段：safe head root。
節點N o d e添加了新的方法，用於計算從起始 slot 到當前 slot 可能獲得的最大支持率。該方法基於委員會權重和 slot/epoch 結構：
- 如果範圍在單個 epoch 內，則返回總支持度為： CommitteeWeight × SlotCount C o m m i t t e e W e i g h t × S l o t C o n t 。
- 如果範圍跨越整個時期，則返回一個時期的權重： CommitteeWeight * 32 C o m m i t t e e W e i g h t ∗ 32 。
- 如果它進入一個新的紀元而沒有完全跨越它，它會根據每個紀元段中的時隙數按比例計算支持。
在更新最佳後代時，該函數會接收當前槽的秒數和當前鏈的委員會權重
- 如果前一個插槽的最佳子項被快速確認，它會遞歸地將BestConfirmedDescendant Best ConfirmedDescendant設置為最深的確認子項。
- 如果未確認，則直接分配最佳子項或將BestConfirmedDescendant Best ConfirmedDescendant設置為nil nil 。
這確保了快速確認狀態在鏈中向後流動。
最後，為了確定一個節點是否被確認，它會將未應用提議者提升的節點權重與安全Threshold進行比較。邏輯檢查如下：
- 該節點的槽位必須早於當前槽位。
- 它計算最大可能的支持度和提議者提升權重。
- 確認條件為：
voteOnlyWeight > ( maxPossibleSupport + proposalerBoostWeight ) / 2 + maxPossibleSupport / 3僅投票權重> (最大可能支持+提議者支持權重) / 2 +最大可能支持/ 3
在哪裡：
提議者BoostWeight = (委員會權重*提議者得分Boost ) / 100提議者Boost權重= (委員會權重∗提議者得分Boost ) / 100
觀察＃1
（以下所有數據均在 2025 年 4 月 13 日至 2025 年 4 月 14 日期間獲取）
滿意情況：對於在時隙n準時提出的有效區塊，到時隙n+1開始時，The Block通常僅通過訂閱聚合證明子網就能獲得大約97%的驗證者支持。
在此圖中，假設從 slot n開始， node0在 slot n-1處阻塞， node1在 slot n-2:
區塊延遲情況：如果n區塊的The Block延遲發佈，那麼到n+1開始時，它將無法獲得足夠的支持。在這種情況下，快速確認通常需要3 個以上的時間，前提是後續區塊會重組延遲發佈的區塊。
觀察＃2
正如預期的那樣，信標槽重組比安全塊重組發生得更頻繁，在過去 12 小時內觀察到 8 次信標重組和 0 次安全塊重組。
觀察＃3
正如預期，快速確認（安全）區塊的出現頻率高於未實現的合理化（安全）區塊，而後者又高於最終確認區塊。這反映了確認速度與安全保障強度之間的權衡——快速確認提供了更快的保障，但保障強度較低；而最終確認提供了最強的保障，但延遲時間較長。
這是按小時顯示的視圖，其中綠色代表已確認的時期，黃色代表未實現的已確認時期，藍色代表快速確認的時期，橙色代表最新時期。如圖所示，快速確認的時期緊跟最新時期，而已確認和未實現的已確認時期則往往滯後：
這是 30 分鐘的視圖：
觀察＃4
最新的頭部槽和安全槽之間的差異通常在每小時視圖中平均為 2 個槽，在 5 分鐘窗口內範圍為 2 到 4 個槽：
觀察＃5
當使用 33% 的拜占庭Threshold時，單個 slot 內就無法確認區塊。這是由於更嚴格的確認條件：
vote > (max_support + pb_score) / 2 + max_support * 0.33直觀地講，這意味著The Block需要：
- 50%（LMD GHOSTThreshold）
- 20%（提議者增幅的一半）
- 33%（拜占庭Threshold）
總計達到103% ，超過了 100% 的最大可能投票權重。
為了將Threshold推廣到多個時隙，我們將其建模為：
threshold = ((n * 0.5 ) + 0.2 + (n * 0.33 )) / n其中n是The Block提出以來的時隙數。此公式包含以下內容：
-
n * 0.5：LMD 投票要求 n * 0.33：拜占庭行為的安全緩衝區0.2：固定提議者提升貢獻
隨著n增加，提議者提升的影響力逐漸減小，Threshold收斂到0.83。這意味著，要在兩個時隙內快速確認一個區塊，它必須獲得至少 93% 的委員會總權重。
| 自提案以來的槽數（n） | LMD 投票 (n * 0.5) | 提議者提升 (/2) | 拜占庭Threshold（n * 0.33） | 全部的 | 歸一化Threshold（總計/n） |
|---|---|---|---|---|---|
| 1 | 0.50 | 0.20 | 0.33 | 1.03 | 1.03 |
| 2 | 1.00 | 0.20 | 0.66 | 1.86 | 0.93 |
| 3 | 1.50 | 0.20 | 0.99 | 2.69 | 0.89 |
| 4 | 2.00 | 0.20 | 1.32 | 3.52 | 0.88 |
| 5 | 2.50 | 0.20 | 1.65 | 4.35 | 0.87 |
正如此圖所示，上圖顯示了來自n-1區塊，其中黃色表示需要快速確認的Threshold，綠色表示未應用提議者提升的節點權重。該區塊始終低於Threshold，且始終短 2% 到 4%，因此無法確認。下圖中，The Block來自n-2 ，其權重比Threshold高 1% 到 2%，因此可以確認。
觀察#6
在 25% 的拜占庭Threshold下，我們可以在不到一個 slot 的時間內（大約 8 秒）確認一個區塊。重新查看一下頭 slot 減去安全 slot 的圖表，以及節點 0 權重與安全Threshold圖表。
後續事項
安全區塊的重組永遠都是不可接受的。例如，如果交易所依賴安全區塊處理提現，重組可能會導致雙重支付。在我們的實驗中，我們觀察到了安全區塊的重組，但僅限於初始同步到鏈頭期間。這似乎更多的是一個實現問題。一個潛在的解決方案是，僅當The Block具有當前 slot 時間戳時才應用快速確認算法（h/t potuz），否則，回退到使用未實現的合理算法來確保安全。
- 今天，Prysm 的 PR 中已經提到了這一點
論文中描述的快速確認安全證明將受益於更多人的關注。該證明接受的審核和審查越多越好——參見第1點。安全區塊的重組可能會很危險，具體取決於它們在實踐中的使用方式。
如果有人有任何疑問或反饋，請隨時聯繫我們。我們將繼續努力，確保此實現可用於生產環境，進行長期測試，併發布包含最新發現的第二部分報告。
