PoS 長程攻擊與弱主觀性：為什麼新節點必須信任近期檢查點

摘要：PoS 的長程攻擊不是“重組幾百個區塊”

PoS 長程攻擊（Long-Range Attack）的危險點不在於攻擊者實時打敗當前驗證者集，而在於歷史驗證者退出後，其舊私鑰對當前鏈不再有經濟約束。若一個新節點從零開始同步，只按照“最長鏈”或“最高權重歷史”這類客觀規則選擇鏈，它可能無法分辨當前社會共識鏈和一條從很久以前分叉、由歷史私鑰簽署出來的幽靈鏈。弱主觀性（Weak Subjectivity）不是 PoS 的臨時補丁，而是安全模型的一部分：節點必須從可信來源獲得一個近期檢查點，再用共識規則向前驗證。本文從 Casper FFG、Gasper、LMD-GHOST、驗證者退出、弱主觀性期、VDF 和前向安全簽名出發，分析非對稱長程攻擊的數學邊界，以及它對跨鏈路由、橋驗證和 AllSwap 退款最終性的影響。

問題邊界：攻擊面在新節點視角

本文是防禦性協議分析，不提供私鑰收集、僞鏈生成、節點欺騙或目標選擇流程。系統角色包括：當前驗證者、已退出驗證者、新同步節點、檢查點提供者、輕客戶端、跨鏈橋、交易路由器和用戶。攻擊者能力假設爲：可以獲得某些歷史驗證者的舊簽名密鑰，可以構造一條歷史分叉鏈，可以向新節點展示完整但過時的鏈歷史；不假設攻擊者能破壞當前誠實驗證者多數、僞造 BLS 簽名、繞過客戶端實現或控制所有可信檢查點渠道。

短程重組和長程攻擊要分開。短程重組發生在當前驗證者仍有經濟約束的時間窗口內，Casper FFG 的 slashing 條件可以懲罰雙籤或環繞投票。長程攻擊發生在更靠後的時間尺度：驗證者已經退出並完成提款，舊私鑰即使被濫用，也未必還能被有效削減。攻擊對象也不同。短程攻擊主要影響在線節點的 fork choice；長程攻擊主要影響離線很久的節點、新安裝節點、輕客戶端和跨鏈驗證器。

這正是“弱主觀性”的含義。PoS 鏈不是完全主觀，也不是完全客觀。節點仍然用密碼學簽名、最終性規則和 fork choice 驗證鏈；但它必須從現實世界獲得一個足夠新的檢查點。只要檢查點位於弱主觀性期內，節點就不需要信任之後的每個區塊生產者，只需按共識規則驗證向前歷史。

弱主觀性期的模型

把時間分爲三段：

```text t0: 檢查點時間 t1: 當前節點開始同步 t2: 當前鏈頭 ```

若 `t1 - t0` 小於弱主觀性期，節點從 `t0` 檢查點開始驗證到 `t2`，安全性依賴當前或近期驗證者集的 slashing 約束。若 `t1 - t0` 過大，大量驗證者可能已經退出，舊密鑰的經濟約束消失，攻擊者就可能用歷史權重構造另一條看似完整的鏈。弱主觀性期本質上是“檢查點必須多新”的上界。

形式化地，設 `S_active(t)` 爲時間 `t` 的活躍驗證者權重，`S_exited(t0, t1)` 爲從 `t0` 到 `t1` 期間退出且不再承受有效懲罰的歷史權重。若一個新節點的檢查點過舊，攻擊者可用 `S_exited` 中的密鑰給舊分叉追加投票，而這些簽名不再對應當前可罰沒資本。安全邊界要求可信檢查點足夠新，使得任何衝突歷史都仍需牽涉可歸因、可懲罰或社會上可識別的當前權重。

以太坊規範中的弱主觀性計算和驗證者退出限制，核心思想都是限制驗證者集合變化速度。退出不能無限快；因此一個近期檢查點之後，驗證者集不會在很短時間內完全替換。新節點獲得該檢查點後，可以用 Casper FFG 最終性和 LMD-GHOST fork choice 驗證後續鏈，而不是從創世區塊開始做“純客觀”判斷。

這裏不要誤解爲“PoS 不安全”。PoW 也需要外部時間和軟件分發信任，例如新節點需要知道真實網絡、客戶端代碼和工作量歷史沒有被局部隔離。PoS 把這類假設顯式化：節點需要一個近期檢查點。顯式假設更容易工程化，比如寫入客戶端配置、檢查點同步、社會恢復流程和輕客戶端證明策略。

非對稱長程攻擊爲何不對稱

非對稱性來自成本曲線。誠實鏈要在現實時間中持續運行，當前驗證者需要鎖定資本、保持在線、承擔 slashing 風險。長程攻擊者如果獲得歷史私鑰，則可以在鏈下快速生成一條覆蓋多年曆史的分叉鏈，因爲這些歷史簽名的生產不再需要重新質押資本。攻擊者不必擊敗當前鏈的實時出塊能力，只需要讓一個沒有近期錨點的新節點相信“這條歷史也有效”。

這也是爲什麼單純比較鏈長度、區塊數量或歷史投票總量不足以防禦。PoS 的安全性來自“簽名權重和可罰沒資本在時間上的綁定”。當簽名權重屬於已經退出的驗證者，歷史簽名仍然可驗證，但經濟含義已經改變。密碼學驗證只能證明“某個私鑰簽過消息”，不能證明“簽名者當前仍對該消息承擔經濟風險”。

Casper FFG 的 slashing 條件約束同一驗證者對沖突檢查點的投票行爲；Gasper 把 FFG 最終性與 LMD-GHOST fork choice 組合起來，爲正常在線節點提供安全與活性。但這些規則默認節點處於足夠新的視角。如果節點離線超過弱主觀性期，它需要人工或客戶端信任渠道獲得新檢查點，而不能只靠創世狀態自動恢復。

一個實用的新節點同步流程應是：

```text obtain_recent_checkpoint() verify_checkpoint_from_multiple_sources() sync_headers_and_states_forward() apply_fork_choice_and_finality_rules() reject_histories_conflicting_before_checkpoint() ```

關鍵在最後一步。檢查點不是普通緩存，而是安全邊界。節點不應該在檢查點之前重新開放 fork choice 競爭，否則長程歷史會重新進入候選集合。

VDF 與前向安全簽名能解決什麼

可驗證延遲函數（Verifiable Delay Function / VDF）常被提議用來增加物理時間約束。若每段歷史都必須包含連續 VDF 輸出，攻擊者即使擁有舊私鑰，也不能在鏈下瞬間生成跨越多年物理時間的有效歷史。VDF 的價值在於把“生成歷史”的成本從並行簽名變成順序時間。但它也帶來硬件公平性、參數選擇、驗證成本、延遲容忍和協議集成問題。VDF 不是對弱主觀性的直接替代，更像是一種增強長曆史不可僞造性的時間錨。

前向安全簽名（Forward-Secure Signatures）是另一條路徑。若驗證者簽名密鑰隨 epoch 單向演進，舊 epoch 私鑰在更新後被銷燬，那麼未來泄露的密鑰不能回頭簽署過去消息。理論上，這能削弱歷史私鑰交易的價值。問題在於區塊鏈驗證者需要可恢復、可審計、可輪換的密鑰管理；一旦密鑰演進失敗，驗證者可能無法簽名或無法證明自己無惡意。BLS 聚合簽名在當前 PoS 系統中有高效聚合優勢，直接替換爲前向安全結構還涉及聚合、驗證、客戶端兼容和硬件錢包支持。

更現實的路線是組合防禦：弱主觀性檢查點是基礎；VDF 或時間證明可以提高僞造長曆史成本；前向安全簽名可以降低舊密鑰價值；客戶端和橋系統則必須拒絕過舊檢查點。任何單一機制都不能把 PoS 變成“從創世開始完全無外部假設”的系統。

檢查點分發的工程路徑

弱主觀性檢查點的安全性取決於兩個問題：誰提供檢查點，以及客戶端如何判斷它足夠新。最弱的實現是單個 RPC 返回 checkpoint root，客戶端直接接受。更穩健的實現會從客戶端發行包、多個獨立 RPC、區塊瀏覽器、基金會公告、社區簽名列表和本地已知節點中交叉驗證。檢查點不是隱私數據，也不是中心化控制開關；它應當是多渠道公開、可複覈、可緩存的安全錨。

工程上，檢查點對象不應只有 block root。至少需要包含：

```text checkpointRoot, slot, epoch, finalizedRoot, validatorSetDigest, source, signature, observedAt ```

`checkpointRoot` 用於同步起點；`slot` 和 `epoch` 用於計算年齡；`finalizedRoot` 表示該檢查點處於最終性邊界；`validatorSetDigest` 幫助輕客戶端確認自己驗證的是哪一組權重；`source` 和 `signature` 用於審計檢查點來源；`observedAt` 防止客戶端把本地緩存誤當作新數據。若這些字段缺失，用戶界面只能顯示“已同步”，卻無法解釋同步安全性。

檢查點分發還要考慮恢復場景。若客戶端發現多個檢查點來源衝突，它不應該自動選擇“權重更高”的那條歷史，因爲衝突本身就是安全事件。更穩妥的狀態是 `checkpointConflict`：暫停跨鏈釋放、禁止新輕客戶端根更新、允許用戶查詢和退款，等待人工或社會層確認。這個狀態機比靜默接受某條歷史更安全，也比完全停機更可控。

跨鏈輕客戶端的字段邊界

跨鏈橋和輕客戶端不能只存一個最新 root。對 PoS 源鏈，它們至少需要維護 `trustedCheckpoint`、`checkpointAge`、`finalizedHeader`、`validatorSetRoot`、`syncCommitteeOrValidatorDigest`、`lastUpdateSlot` 和 `maxStaleness`。這些字段決定目標鏈合約是否仍處在有效安全窗口內。若目標鏈合約只驗證簽名聚合，卻不檢查可信根年齡，它可能在密碼學上正確、在經濟安全上過期。

輕客戶端還應區分三種狀態。`fresh` 表示檢查點和驗證者集合都在允許窗口內；`staleButRecoverable` 表示不應接受新釋放，但仍可通過新檢查點恢復；`unsafe` 表示檢查點衝突或超過最大年齡，必須暫停依賴該源鏈的風險動作。不同狀態對應不同產品行爲：新訂單、在途訂單、退款、歷史查詢和管理員恢復不應被混成一個全局開關。

這種字段化設計對跨鏈路由很重要。路由器可以在報價階段過濾掉 `unsafe` 路徑，在執行階段重新檢查 `fresh` 狀態，在退款階段記錄導致失敗的是價格、橋、檢查點還是目標鏈執行。最終用戶看到的是簡單狀態；系統內部保留的是可審計的共識時間錨。

失敗模式與檢測信號

第一種失敗模式是節點使用過舊檢查點。表現爲客戶端從創世或很老的狀態開始同步，並接受一個與當前社會共識不一致的 finalized 歷史。防禦是 checkpoint sync、多來源檢查、客戶端默認弱主觀性警告和拒絕超過期限的 checkpoint。

第二種失敗模式是輕客戶端或橋驗證器沒有更新可信根。跨鏈橋若長期使用舊驗證者集合或舊 finalized root，攻擊者不需要攻擊當前鏈，只要圍繞舊根構造可驗證歷史，就可能影響目標鏈判斷。防禦是爲輕客戶端設置最大檢查點年齡、驗證者集合更新窗口和異常暫停狀態。

第三種失敗模式是把簽名有效性誤當成經濟有效性。舊 BLS 簽名能通過密碼學驗證，但簽名者已經退出，當前沒有足夠可罰沒資本。檢測信號包括驗證路徑沒有檢查 epoch、withdrawal/exit 狀態或 validator set freshness。防禦是把簽名驗證、驗證者狀態和經濟約束綁定在同一狀態機裏。

第四種失敗模式是檢查點來源單一。若客戶端只依賴一個 API、一個節點或一個未認證鏡像，新節點可能被定向餵給錯誤檢查點。防禦是多來源檢查、客戶端發行版內置 checkpoint、社區可驗證簽名、DNSSEC/HTTPS 之外的額外簽名鏈，以及用戶界面明確顯示檢查點來源。

第五種失敗模式是跨鏈應用忽略弱主觀性。路由器或橋只看“源鏈已經 finalized”，卻沒有記錄自己所依賴的檢查點年齡和輕客戶端同步狀態。防禦是將 `checkpointAge`、`validatorSetFreshness`、`finalitySource` 和 `syncStatus` 納入路由風控字段。

AllSwap 相關性：跨鏈最終性必須帶時間錨

AllSwap 關注的是跨鏈交換、退款和可解釋結算。用戶不需要理解弱主觀性期的公式，但產品必須知道某條鏈的最終性證明是否來自新鮮、可驗證的檢查點。若一條路線依賴的橋或輕客戶端長時間未更新可信根，那麼“源鏈已最終確定”這句話就不夠完整；它還要說明最終性基於哪個檢查點、該檢查點是否仍在安全窗口內。

路由系統可以把 PoS 長程風險拆成幾項：`checkpointAgeRisk`、`validatorChurnRisk`、`lightClientFreshnessRisk`、`bridgeRootRisk`、`recoveryRisk`。`checkpointAgeRisk` 衡量可信根距離當前時間多遠；`validatorChurnRisk` 衡量驗證者集變化速度；`lightClientFreshnessRisk` 衡量目標鏈驗證器是否及時跟進源鏈最終性；`bridgeRootRisk` 衡量橋是否仍接受舊根；`recoveryRisk` 衡量異常時能否暫停釋放和退款。

對跨鏈交換來說，最危險的不是正常在線鏈上的小重組，而是“系統組件以爲自己在驗證當前鏈，實際驗證的是過時安全上下文”。因此訂單狀態應區分 `sourceFinalized`、`checkpointFresh`、`bridgeRootUpdated`、`targetReleaseReady` 和 `refundSafe`。如果檢查點過舊，系統可以暫停新路線、允許退款、要求重新同步輕客戶端，而不是繼續執行目標鏈釋放。

在訂單級別，檢查點過期不應被歸類爲普通執行失敗。普通失敗可能是滑點、餘額或目標鏈 Gas 問題；檢查點過期意味着最終性來源失去時效。更合理的處理是凍結目標鏈釋放、保留源鏈支付憑證、記錄檢查點來源和過期時間，並把訂單推入可審計退款隊列。 恢復執行前，還應重新驗證橋根和目標鏈釋放條件。 恢復記錄必須可追溯。

這不是把 AllSwap 寫成共識協議。它只是把共識層時間錨變成路由質量的一部分。更便宜或更快的跨鏈路徑，如果依賴陳舊檢查點或長期未更新的輕客戶端，可能比稍慢但檢查點新鮮的路徑更危險。

未解決問題

第一，弱主觀性檢查點的分發仍缺少完全統一標準。客戶端、瀏覽器錢包、橋、RPC 和輕客戶端都可能有自己的檢查點來源，用戶很難比較它們。

第二，VDF 的工程化成本仍不確定。它可以給歷史附加時間成本，但硬件公平、延遲參數、驗證開銷和協議升級路徑都需要謹慎設計。

第三，前向安全簽名和 BLS 聚合之間存在工程張力。前者降低舊密鑰價值，後者支撐當前 PoS 高效聚合，二者如何組合仍是開放問題。

第四，跨鏈橋對弱主觀性的表達不足。很多橋顯示最終性高度，卻不顯示可信根年齡、驗證者集合新鮮度和檢查點來源。

第五，社會恢復與自動化恢復邊界仍難設計。檢查點錯誤時，完全自動化可能放大錯誤，完全人工化又會影響用戶退出和退款。

參考資料

[1] Ethereum Consensus Specs, Weak Subjectivity, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md

[2] Ethereum Consensus Specs, Beacon Chain, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md

[3] Ethereum Consensus Specs, Fork Choice, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md

[4] Ethereum Consensus Specs, Honest Validator, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md

[5] Ethereum.org, Weak Subjectivity, https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

[6] Vitalik Buterin, Proof of Stake FAQ, https://vitalik.eth.limo/general/2017/12/31/pos_faq.html

[7] Vitalik Buterin and Virgil Griffith, Casper the Friendly Finality Gadget, arXiv 2017, https://arxiv.org/abs/1710.09437

[8] Hsiao-Wei Wang et al., Gasper: Combining GHOST and Casper, arXiv 2020, https://arxiv.org/abs/2003.03052

[9] Ethereum PoS Evolution, https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md

[10] Benjamin Wesolowski, Simple Verifiable Delay Functions, IACR ePrint 2018/183, https://eprint.iacr.org/2018/183

[11] Mihir Bellare and Sara K. Miner, A Forward-Secure Digital Signature Scheme, https://cseweb.ucsd.edu/~mihir/papers/fsig.pdf

[12] Ethereum Annotated Specification, Consensus, https://eth2book.info/capella/part2/consensus/