以太坊權益證明共識機制數學推導完整指南:從密碼學基礎到最終性保證

本文從數學推導的角度,全面分析以太坊 PoS 共識機制的設計原理,涵蓋 Casper FFG 最終性保證、BLS 簽名聚合、質押經濟學、隨機數生成與安全性分析等多個核心主題。提供完整的數學公式推導、程式碼範例與量化數據分析,幫助研究者和開發者深入理解這一共識機制的理論基礎與工程實踐。截至 2026 年第一季度,以太坊質押總量超過 3200 萬 ETH,驗證者數量超過 100 萬。


title: "以太坊 PoS 共識機制數學推導完整指南:從密碼學基礎到最終性保證"

summary: "以太坊從 PoW 轉向 PoS 是區塊鏈共識機制演進的重要里程碑。本文從密碼學基礎出發,完整推導 PoS 共識的數學原理,涵蓋 BLS 簽名聚合、Casper FFG 最終性機制、LMD GHOST 分叉選擇規則、LMD GHOST 安全性證明、以及 2/3 驗證者共識的嚴格數學推導。我們提供完整的數學推導過程,幫助讀者建立對以太坊共識機制的嚴格理解。"

date: "2026-03-31"

category: "technical"

tags:

difficulty: "advanced"

status: "published"

parent: null

datacutoffdate: "2026-03-31"

references:

url: "https://ethereum.org/developers"

desc: "以太坊官方共識層文檔"

tier: "tier1"

author: "Vitalik Buterin, Virgil Griffith"

year: 2017

url: "https://arxiv.org/abs/1710.09437"

desc: "Casper the Friendly Finality Gadget"

tier: "tier1"

author: "Yonatan Sompolinsky, Aviv Zohar"

year: 2013

url: "https://eprint.iacr.org/2013/881"

desc: "Greedy Heaviest-Observed Sub-Tree for Blockchains"

tier: "tier2"

author: "Dan Boneh, Ben Lynn, Hovav Shacham"

year: 2001

url: "https://www.iacr.org/archive/asiacrypt2001/22470216.pdf"

desc: "Short Signatures from the Weil Pairing"

tier: "tier2"

url: "https://github.com/ethereum/consensus-specs"

desc: "以太坊共識層規範完整實現"

tier: "tier1"

author: "Viktor Vafeiadis et al."

year: 2023

url: "https://arxiv.org/abs/2306.02193"

desc: "LMD Ghost 安全性分析"

tier: "tier3"

author: "Justin Drake"

year: 2023

url: "https://ethresear.ch/t/attestation-inclusion-predictability/11845"

desc: "驗證者預言機預測性研究"

tier: "tier3"

disclaimer: "本網站內容僅供教育與資訊目的,不構成任何技術建議或投資建議。"

knowledge_path: "technical/consensus/pos-mathematical-derivation"


以太坊 PoS 共識機制數學推導完整指南:從密碼學基礎到最終性保證

老實說,當以太坊在 2022 年完成合併(The Merge)的時候,整個幣圈都在狂歡。但我發現身邊很多工程師朋友對 PoS 共識機制的理解,其實還停留在「質押就能賺幣」這個層面。這個嘛,不能說錯,但總覺得少了點什麼——少了對底層數學邏輯的理解。

所以這篇文章,我想帶你從密碼學基礎一路推到最終性保證,用完整的數學推導讓你看清楚以太坊共識機制到底是怎麼運作的。這不是那種「圖解區塊鏈」的淺白內容,我假設你看得懂代數和一些離散數學的概念。如果你在閱讀過程中遇到卡住的地方,歡迎回頭查閱相關基礎知識。

數據截止到 2026 年 3 月,以太坊信標鏈(Beacon Chain)已經穩定運行超過三年,這讓我們有足夠的實際數據來驗證理論模型。

第一章:密碼學基礎——BLS 簽名與聚合

在深入 PoS 之前,咱們得先把密碼學的工具箱準備好。以太坊共識層大量使用了 BLS 簽名(Boneh–Lynn–Shacham Signatures),這玩意兒有個超級重要的特性:簽名聚合。

1.1 橢圓曲線密碼學回顧

以太坊使用的是 BLS12-381 橢圓曲線,這條曲線的參數定義在一個有限域 $\mathbb{F}_p$ 上:

$$E: y^2 = x^3 + 4 \pmod{p}$$

其中 $p = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001$,是一個 381 位的質數。

曲線上的點構成一個循環群 $G_1$,階(order)為:

$$r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001$$

這個 $r$ 也是基於配對(pairing)運算的配對群 $G_T$ 的階。

BLS 簽名安全性基於以下假設:

決定性橢圓曲線 Diffie-Hellman 假設(DECDH):給定 $(P, aP, bP)$,計算 $abP$ 是困難的。

1.2 BLS 簽名方案

BLS 簽名方案包含三個算法:

金鑰生成 (KeyGen):

$$sk \leftarrow \mathbb{F}_r, \quad pk = sk \cdot P$$

其中 $P$ 是 $G_1$ 的生成元,$sk$ 是隨機選取的秘密金鑰。

簽名 (Sign):

$$\sigma = sk \cdot H(m)$$

其中 $H: \{0,1\}^ \rightarrow G_1^$ 是一個密碼學雜湊函數,將任意訊息映射到曲線上的點。

驗證 (Verify):

$$e(\sigma, P) \stackrel{?}{=} e(H(m), pk)$$

驗證等式的數學依據:

$$e(\sigma, P) = e(sk \cdot H(m), P) = e(H(m), sk \cdot P) = e(H(m), pk)$$

1.3 簽名聚合:關鍵魔法

BLS 真正厲害的地方在於簽名聚合。假設有 $n$ 個驗證者對同一個訊息 $m$ 簽名:

$$\sigma1 = sk1 \cdot H(m), \quad \sigma2 = sk2 \cdot H(m), \quad \ldots, \quad \sigman = skn \cdot H(m)$$

聚合簽名定義為:

$$\sigma{agg} = \sigma1 + \sigma2 + \cdots + \sigman = (sk1 + sk2 + \cdots + sk_n) \cdot H(m)$$

驗證聚合簽名只需一次配對運算:

$$e(\sigma{agg}, P) \stackrel{?}{=} e(H(m), \sum{i=1}^n pk_i)$$

這個特性的重要性在於:不管有多少驗證者,驗證成本都是 O(1)。如果用傳統的 ECDSA 簽名,$n$ 個簽名就需要 $n$ 次驗證,鏈上成本會爆炸式成長。

1.4 實務上的批次驗證

以太坊的驗證者委員會使用「子群檢查」(subgroup check)來防止惡意攻擊者構造無效的聚合簽名。這是因為攻擊者可能嘗試使用非 $G_1$ 群的點來構造偽造簽名。

// 簡化的 BLS 簽名聚合驗證邏輯
async function verifyAggregatedSignature(
  messageHash: Uint8Array,
  publicKeys: G1Point[],
  aggregatedSignature: G2Point,
  domain: Uint8Array
): Promise<boolean> {
  // Step 1: 計算聚合公鑰
  const aggregatedPubKey = aggregatePublicKeys(publicKeys);
  
  // Step 2: 計算訊息哈希
  const messagePoint = hashToG1(messageHash, domain);
  
  // Step 3: 執行配對檢查
  const leftPairing = await pairing(aggregatedSignature.toG2Point(), G1_GENERATOR);
  const rightPairing = await pairing(messagePoint, aggregatedPubKey.toG2Point());
  
  return leftPairing.equals(rightPairing);
}

第二章:Casper FFG:最終性機制的數學原理

Casper FFG(Casper the Friendly Finality Gadget)是以太坊 PoS 的最終性引擎。它的核心思想來自於拜占庭將軍問題的變體:當 2/3 以上的驗證者對某個區塊達成共識,這個區塊就永遠無法被 revert。

2.1 安全的核心:不可能性定理

咱們得先理解為什麼 2/3 是個神奇的數字。回顧 Lamport、Shostak 和 Pease 的經典論文《拜占庭將軍問題》:

定理(拜占庭容錯上限):在一個有 $n$ 個節點的系統中,最多只能容忍 $f < n/3$ 個 Byzantine(任意錯誤)節點。

這個定理的直覺證明:

  1. 假設系統有 $n = 3f + 1$ 個節點
  2. 正確節點需要 $2f + 1$ 票才能達成決定(超過多數)
  3. Byzantine 節點最多有 $f$ 個
  4. 即使 Byzantine 節點全部投反對票,正確節點仍然有 $2f + 1 > f$ 票

反過來說:

2.2 FFG 的懸掛攻擊(Nothing-at-Stake)解決方案

PoW 系統之所以安全,是因為攻擊者需要控制超過 50% 的算力才能發動 51% 攻擊。在 PoS 中,如果驗證者可以同時在多個分叉上投票,理論上他們沒有任何損失——這就是「無利害關係」(Nothing-at-Stake)問題。

Casper FFG 透過罰款機制解決這個問題:

定義質押存款(stake):

$$S_i \text{ 代表驗證者 } i \text{ 的質押金額}$$

定義裁決條件(Slashing Conditions):

條件一(雙重投票):驗證者不得對同一個 epoch 的兩個不同區塊簽署兩條衝突的投票。

$$\exists (e, s1, s2, b1, b2): \text{justified}(e, s1, b1) \land \text{justified}(e, s2, b2) \land s1 \neq s2$$

條件二(環繞投票):驗證者不得簽署包含另一個已簽署投票的投票。

$$\exists (e1, s1, t1, e2, s2, t2): \text{justified}(e1, s1, b1) \land \text{justified}(e2, s2, b2) \land e1 < e2 < t1 < t2$$

違反任一條件的驗證者將被罰沒全部質押存款。

2.3 最終性的數學定義

在 FFG 中,「最終性」(Finality)有嚴格的數學定義:

定義(檢查點最終性):區塊 $B$ 被最終確認(finalized)當且僅當:

  1. $B$ 是一個檢查點(每 32 個 epoch 的最後一個區塊)
  2. 存在一個超級多數(supermajority),即超過 $2/3$ 的活躍質押量對 $B$ 投票

定義 epoch $e$ 的投票(attestation)為一個二元組 $(s, t)$,其中:

定義(超級多數連結):超級多數連結 $(s, t)$ 存在當且僅當:

$$\sum{v \in V: v \text{ 投了 } (s,t)} stake(v) > \frac{2}{3} \cdot \sum{v \in active} stake(v)$$

定理(最終性保證):如果區塊 $B$ 被最終確認,則在保守假設(少於 $1/3$ 質押量被罰沒)下,$B$ 不可能被 revert。

2.4 最終性的安全性證明

我們用反證法來證明這個定理:

假設:區塊 $B$ 已被最終確認,但存在一個替代鏈包含不同的區塊 $B' \neq B$。

已知條件:

  1. 最終確認 $B$ 需要 $> 2n/3$ 的驗證者投票(假設總驗證者質押量為 $n$)
  2. 替代 $B$ 同樣需要 $> 2n/3$ 的驗證者投票

推導:

根據疊加原理(superposition principle),同時滿足這兩個條件的驗證者數量為:

$$|VB \cap V{B'}| \geq |VB| + |V{B'}| - n > \frac{2n}{3} + \frac{2n}{3} - n = \frac{n}{3}$$

這意味著至少有 $n/3$ 個驗證者同時投票給了兩個衝突的區塊。

矛盾:這 $n/3$ 個驗證者違反了 FFG 的裁決條件,根據協議他們的質押存款將被全部罰沒。

結論:這 $n/3$ 個驗證者在「最終確認 $B$」的投票中也包含在 $> 2n/3$ 裡,但根據裁決條件他們不可能同時做兩件事。因此,假設不成立,$B$ 不可能被 revert。

第三章:LMD GHOST 分叉選擇規則

光有最終性還不夠,咱們還需要一個規則來決定:當網路分叉時,哪條鏈是「正確」的?這就是 LMD GHOST(Latest Message-Driven Greedy Heaviest Observed SubTree)的作用。

3.1 原始 GHOST 協議

GHOST(Greedy Heaviest Observed SubTree)最初由 Sompolinsky 和 Zohar 在 2013 年提出,是為了解決比特幣區塊傳播延遲導致的「自私挖礦」問題。

原始 GHOST 的核心思想:區塊的「重量」不只是自己,而是包含所有後代區塊的累加。

數學定義:

$$Weight(B) = \sum_{B' \in Descendants(B)} w(B')$$

其中 $w(B')$ 是區塊 $B'$ 的基本權重(對 PoW 來說是工作量的倒數,對 PoS 來說是質押量)。

GHOST 分叉選擇:

$$ForkChoice(B) = \underset{B' \in Ancestors(B_{head})}{\arg\max} Weight(B')$$

3.2 LMD 改進:只計算最新消息

「Latest Message-Driven」是 GHOST 的關鍵改進。它的核心洞察是:舊消息不應該重複計算。

考慮這個場景:

如果我們簡單地計算所有投票,A 和 B 各得到一票。但實際上,$v1$ 的 slot 5 投票是一個更新的決定——它明確表示 $v1$ 認為 C 所在的鏈是最優的。

LMD 規則:每個驗證者在每個 slot 只能投一次票。分叉選擇時,只計算每個驗證者的最新投票(latest message)。

定義 slot $s$ 的驗證者 $v$ 的投票權重:

$$W_v(s) = \begin{cases} stake(v) & \text{if } v \text{ has attested in slot } s \\ 0 & \text{otherwise} \end{cases}$$

3.3 完整 LMD GHOST 算法

LMD GHOST 分叉選擇算法:

輸入:區塊樹結構,驗證者最新投票集合
輸出:區塊樹中的某個區塊作為區塊頭

1. 初始化:current_block = genesis_block

2. 迭代擴展 current_block:
   a. 找出 current_block 的所有有效子區塊 children
   b. 如果 children 為空,返回 current_block(這是葉子區塊)
   c. 對每個子區塊 child,計算其 GHOST 分數:
      score(child) = sum of W_v(latest_slot(v)) 
                     for all v where latest_attestation(v) 
                     is in subtree rooted at child
   d. 選擇 score 最高的子區塊:current_block = argmax_child(score(child))
   e. 如果多個子區塊分數相同,選擇哈希值最小的(打破平局)

3. 返回 current_block

3.4 LMD GHOST 與 FFG 的整合

以太坊的共識引擎同時運行 LMD GHOST(用於區塊生產者選擇分叉)和 Casper FFG(用於最終確認)。這兩者的互動如下:

  1. 區塊生產:提議者(proposer)使用 LMD GHOST 來決定當前的「區塊頭」(head)
  2. 投票/見證:驗證者對 LMD GHOST 決定的 head 進行投票
  3. 最終確認:每隔一個 epoch,Casper FFG 檢查是否存在超級多數連結來最終確認區塊

這種設計的優點:

第四章:驗證者委員會與 BLS 聚合

以太坊的設計中,每個 slot(約 12 秒)大約有 128 個驗證者組成一個委員會。所有委員會成員同時對同一個區塊進行投票,然後使用 BLS 簽名聚合將 128 個簽名合併成一個。

4.1 驗證者 Committee 分配機制

驗證者被分配到委員會的過程涉及兩個層面的隨機性:

RANDAO:這是一個由所有驗證者共同決定的隨機數。每個 epoch 的 RANDAO 是前一個 epoch RANDAO 加上該 epoch 所有驗證者貢獻的隨機種子。

VDF(Verifiable Delay Function):為了防止驗證者操縱 RANDAO,以太坊使用 VDF 來延遲 RANDAO 的揭露。VDF 需要經過一定時間的序列計算才能完成,這確保了在 RANDAO 揭露之前,沒有人能預先知道它的值。

驗證者分配到委員會的數學表示:

$$\text{committee}(epoch, slot) = \text{RandomSeed}(epoch) \oplus \text{ValidatorIndex}(v) \gg \text{slot\_index}$$

這個設計確保了:

  1. 委員會組成是不可預測的(攻擊者無法事先知道誰會驗證某個區塊)
  2. 委員會組成是不可操縱的(攻擊者無法通過選擇性退出來影響委員會)

4.2 聚合驗證的數學複雜度

假設每個委員會有 128 個驗證者,這是聚合驗證的複雜度分析:

操作原始方式(無聚合)BLS 聚合
簽名數量1281
公鑰數量1281(聚合公鑰)
簽名驗證128 次配對1 次配對
驗證時間O(n)O(1)
區塊空間O(n)O(1)

配對運算是橢圓曲線密碼學中最昂貴的操作。BLS 聚合將這個成本從 O(n) 降低到 O(1),這是以太坊能夠支持大量驗證者的關鍵。

第五章:共識安全性量化分析

咱們終於要討論每個人都關心的問題了:以太坊 PoS 到底有多安全?

5.1 攻擊成本分析

51% 攻擊:

要控制以太坊網路,攻擊者需要控制超過 2/3 的質押量(才能繞過 FFG 的最終性)。截至 2026 年 3 月,以太坊質押總量約為 3300 萬 ETH,假設 ETH 價格為 2500 美元:

$$AttackCost = \frac{2}{3} \times 33,000,000 \times \$2,500 \approx \$27.5 \text{ 億美元}$$

這個數字遠超過比特幣 51% 攻擊的成本(理論上可以透過租用算力大幅降低)。

遠程攻擊(Long-Range Attack):

攻擊者嘗試從區塊鏈的早期階段重寫歷史。但以太坊的弱主觀性(Weak Subjectivity)要求新加入的驗證者從最近一個 epoch 的狀態開始同步,這堵住了遠程攻擊的路。

5.2 最終確認時間與安全性權衡

以太坊的最終確認時間是 2 個 epoch(約 12.8 分鐘)。但這個數字背後有什麼數學含義?

定義:重組風險(Reorg Risk)

假設網路中存在 $f$ 個惡意驗證者,總驗證者數量為 $n$,則:

$$P(\text{finalized block reorgs}) \leq \left(\frac{f}{n}\right)^{n - f}$$

這個公式的直覺是:要 revert 一個最終確認的區塊,幾乎所有驗證者都需要同時出錯——這是一個極不可能的事件。

實際上,當 $f/n < 1/3$ 時(這是協議的安全假設),revert 的概率是指數級衰減的:

$$P(\text{reorg}) \leq \left(\frac{1}{3}\right)^{n}$$

即使只有 100 個驗證者(實際上有數十萬),這個概率也是:

$$\left(\frac{1}{3}\right)^{100} \approx 1.5 \times 10^{-48}$$

這個數字比宇宙中存在智慧生命的概率還要小得多。

5.3 活性(liveness)保證

安全性之外,咱們還需要問:網路是否能持續運作?

定義 Epoch 進度:一個 epoch 被「解決」當且僅當:

  1. 超過 2/3 的驗證者提交了該 epoch 的見證消息
  2. 沒有發現裁決條件違規

活性定理:如果網路延遲不超過 SLOTS_PER_EPOCH * SECONDS_PER_SLOT / 3,網路將持續達成共識。

以太坊的設計允許最多 4 個 slot 的連續提案者失敗,而不會影響最終確認的進度。這是對網路中斷和驗證者離線的容錯設計。

第六章:實作程式碼解讀

咱們已經把理論搞清楚了,現在來看看以太坊共識層的實際實現。

6.1 信標鏈狀態轉換

信標鏈的狀態轉換是共識引擎的核心。每個 slot 的處理流程:

def process_slot(state: BeaconState, slot: Slot) -> None:
    """
    處理單個 slot 的狀態轉換
    
    包含三個主要階段:
    1. 區塊提議(如果你是提議者)
    2. 見證處理(收集驗證者投票)
    3. 分叉選擇更新(基於 LMD GHOST)
    """
    # 取得當前 slot 的 proposer
    proposer_index = get_beacon_proposer_index(state)
    
    if is_current_slot_proposer(state, validator_index):
        # 生成新區塊
        block = generate_block(state, slot)
        
        # 簽署區塊
        block_signature = sign_block(block, validator_privkey)
        block.signature = block_signature
        
        # 更新分叉選擇視圖
        update_lmd_ghost(state, block)
    
    # 處理見證消息
    for attestation in pending_attestations:
        process_attestation(state, attestation)

6.2 FFG 裁決條件檢查

def check_ffg_slashing_conditions(
    attestation_1: Attestation,
    attestation_2: Attestation,
    validator_index: ValidatorIndex
) -> bool:
    """
    檢查 FFG 裁決條件
    
    返回 True 如果發現裁決條件違規(即需要罰沒)
    """
    # 條件一:雙重投票
    # 兩個投票有相同的目標 epoch 但不同的來源 epoch
    is_double_vote = (
        attestation_1.data.target.epoch == attestation_2.data.target.epoch
        and attestation_1.data.source.epoch != attestation_2.data.source.epoch
    )
    
    # 條件二:環繞投票
    # 投票 A 的範圍完全被投票 B 的範圍包含
    is_surround_vote = (
        attestation_1.data.source.epoch < attestation_2.data.source.epoch
        and attestation_2.data.target.epoch < attestation_1.data.target.epoch
    )
    
    if is_double_vote or is_surround_vote:
        slash_validator(validator_index)
        return True
    
    return False

6.3 分叉選擇實現

def compute_lmd_ghost_head(
    state: BeaconState,
    block_pool: Dict[Root, BeaconBlock]
) -> Root:
    """
    實現 LMD GHOST 分叉選擇算法
    
    從創世區塊開始,沿著「最重」的子樹向下直到葉子區塊
    """
    # 從最近的確認區塊開始(確保弱主觀性)
    start_root = state.finalized_checkpoint.root
    
    current_root = start_root
    current_block = block_pool[current_root]
    
    while True:
        children = get_children(current_block.root, block_pool)
        
        if not children:
            # 到達葉子區塊
            return current_root
        
        # 計算每個子區塊的分數
        child_scores = {}
        for child in children:
            score = compute_weight_in_subtree(child.root, state)
            child_scores[child.root] = score
        
        # 選擇分數最高的子區塊
        current_root = max(child_scores, key=child_scores.get)
        current_block = block_pool[current_root]

def compute_weight_in_subtree(
    block_root: Root,
    state: BeaconState
) -> int:
    """
    計算子樹的總權重(使用 LMD 規則)
    
    每個驗證者只計算其最新投票所在的子樹
    """
    total_weight = 0
    
    # 遍歷所有驗證者的最新投票
    for validator_index, latest_attestation in state.latest_attestations.items():
        # 檢查投票是否在指定子樹中
        if is_in_subtree(latest_attestation.block_root, block_root):
            total_weight += get_effective_balance(state, validator_index)
    
    return total_weight

結語:PoS 的優雅與挑戰

經過這麼長的數學推導,咱們終於可以把以太坊 PoS 的全貌看清楚:

優雅之處:

  1. BLS 簽名聚合讓數十萬驗證者的高效共識成為可能
  2. Casper FFG 的裁決條件用經濟激勵解決了 Byzantine 共識的理論問題
  3. LMD GHOST 在活性與安全性之間找到了平衡點

挑戰之處:

  1. 驗證者獎勵的數學均衡點仍在實驗中調整(2026 年已經調整過多次)
  2. 質押中心化風險(大量 ETH 集中在少數質押服務商)是個隱憂
  3. 對抗審查攻擊(censor attack)仍是開放性問題

這篇文章的目標不是讓你成為共識機制的專家,而是讓你在聽到「Casper FFG」、「LMD GHOST」、「BLS 聚合」這些名詞的時候,能夠明白它們背後的數學原理到底是什麼。

下次有人跟你吹噓以太坊 PoS 有多安全的時候,你可以淡定地問他:「那你能幫我推導一下 2/3 這個閾值是怎麼來的嗎?」


本篇文章的最後更新:2026 年 3 月。以太坊共識層規範仍在持續演進中,部分具體參數可能已調整。

主要參考來源:

COMMIT: Complete Ethereum PoS consensus mathematical derivation guide

延伸閱讀與來源

這篇文章對您有幫助嗎?

評論

發表評論

注意:由於這是靜態網站,您的評論將儲存在本地瀏覽器中,不會公開顯示。

目前尚無評論,成為第一個發表評論的人吧!