以太坊密碼學形式化驗證：從共識安全到智能合約的數學證明之旅

概述

每次看到密碼學論文裡那些密密麻麻的數學推導，你是不是也跟曾經的我一樣，直接翻到結論部分假裝看懂了？我懂。但老實說，如果你想真正理解以太坊的安全性，光看結論不夠。你得知道那些看起來很嚇人的數學證明到底在幹嘛。

這篇文章就是要當你的翻譯機。我會用最白話的方式，帶你走一遍以太坊密碼學中最關鍵的幾個形式化驗證：從 Casper 共識的安全性證明，到 BLS 簽章的安全性分析，再到智能合約的形式化驗證方法。中間會穿插一些程式碼範例，讓理論落地。

讀完這篇，你起碼能看懂以太坊安全性白皮書的數學部分，知道那些「顯然可得」「由引理 3.1 可知」的跳步到底跳了什麼。讓我們開始吧。

第一章：為什麼需要形式化驗證

1.1 一個真實的故事：並髏掉的 Parity 多簽錢包

2017 年，Parity 的多簽錢包合約因為一個小小的 typo，損失了 3000 萬美元的 ETH。問題出在這行代碼：

function initMultiowned(address[] _owners, uint _required) {
    // ...
    m_numOwners = _required++;  // 這裡！應該是 =
    // ...
}

就是一個 = 寫成了 ++=，導致了可怕的後果。傳統的代碼審查和測試都沒發現這個問題。

形式化驗證（Formal Verification）就是要用數學方法，系統性地檢查這類錯誤。它不是「測試很多種情況看看有沒有問題」，而是數學上證明「在所有可能的輸入下，這段代碼都不會出問題」。

1.2 形式化驗證的三個層次

形式化驗證在密碼學領域通常分為三個層次：

層次一：符號驗證（Symbolic Verification）

用符號表示消息和攻擊者的能力，檢查協議在各種攻擊場景下是否安全。典型工具是 ProVerif、Tamarin。

層次二：計算驗證（Computational Verification）

在複雜度量下證明協議的安全性。需要數學上證明「任何多項式時間攻擊者成功破解的安全性」。

層次三：程序驗證（Program Verification）

對實際代碼進行形式化分析。典型工具是 Coq、Isabelle/HOL、F。

以太坊的密碼學組件通常涉及層次一和層次二，而智能合約越來越多地使用層次三的技術。

1.3 以太坊密碼學的安全威脅模型

在開始之前，我們得先搞清楚攻擊者的能力範圍。以太坊假設的威脅模型是：

Dolev-Yao 威脅模型：

攻擊者控制網路，可以：

• 攔截、修改、重放任何網路消息
• 發起新的會話
• 冒充任意參與者
• 但無法破解密碼學假設（如 ECDLP）

密碼學假設：

以太坊依賴以下數學假設（這些是「被相信為困難」的問題，目前沒有已知的高效解法）：

第二章：Casper 共識的安全性證明

2.1 Casper 的核心思想

Casper 是以太坊的 PoS 共識機制。跟傳統的 BFT 系統比起來，Casper 的特點是「安全性可證明」——你可以用數學方法證明攻擊者無法破壞網路的活性或一致性。

Casper 的安全性核心是「Friendly Finality Gadget」（FFG），基於以下不變量：

安全性不變量（Safety Invariant）：

不可能有兩個相互矛盾的區塊被最終確認（Finalized）

這句話看起來很直觀，但要數學上證明它，需要引入一堆定義和引理。

2.2 準備知識：超majority 投票

Casper 使用「超級多數投票」（Supermajority Vote）來達成共識：

定義一個「投票」為一對區塊哈希：

• source：被投票的最近被最終確認的區塊
• target：被投票的新區塊

投票的有效性需要滿足：

1. source 是 target 的祖先
2. 投票者是一個驗證者
3. 投票者之前沒有投過反對 target 的票

超級多數：在一個 epoch 內，超過 2/3 的驗證者質押量投票給同一個 checkpoint。

2.3 安全性證明的核心引理

引理 2.1（可追責性，Accountable Safety）：

如果兩個相互矛盾的區塊被最終確認，則至少有 1/3 的驗證者質押量被罰沒（Slashed）。

證明思路：

1. 假設存在兩個被最終確認的矛盾區塊 A 和 B
2. 最終確認 A 需要一個超級多數投票 V_A
3. 最終確認 B 需要一個超級多數投票 V_B
4. 由於 A 和 B 矛盾，存在一個「最小分割點」C，使得 VA 和 VB 來自不同的分支
5. 在 C 之後，VA 和 VB 的投票者集合至少有 1/3 重疊
6. 這些重疊的投票者違反了「不雙重投票」規則
7. 因此這些投票者的質押量會被罰沒

數學表達：

|validators(V_A) ∩ validators(V_B)| ≥ 1/3 * total_stake

這個引理告訴我們：如果你能讓兩個衝突的區塊都最終確認，攻擊者必然會損失大量押金。

2.4 活性的證明

光有安全性不夠，網路還得能繼續前進才行。Casper 的活性證明稍微複雜一點。

定理 2.1（Plausible Liveness）：

即使攻擊者控制了超過 1/3 的驗證者，只要網路最終是同步的，區塊鏈就能繼續確認新的區塊。

證明的直覺：

1. 假設網路最終同步，收斂時間為 Δ
2. 在一個長期的同步窗口內誠實節點能看到彼此的消息
3. 誠實節點的質押量 > 2/3（否則安全性已被破壞）
4. 誠實節點可以在同一個 checkpoint 上累積超級多數投票
5. 因此下一個 checkpoint 可以被最終確認

關鍵洞察：即使有 1/3 的攻擊者，誠實節點的質押量仍然 > 2/3，所以能達成共識。

2.5 從 Casper 到 Casper-Gasper

以太坊的最終共識協議叫 Casper-Gasper，是 Casper FFG 的增強版，加入了 LMD GHOST 分叉選擇規則。

Gasper 的安全性證明可以總結為：

Theorem (Gasper Safety):
    不可能存在兩個高度相同但內容不同的区块被最终确认

Proof Sketch:
    1. 由 Casper FFG 的 Accountable Safety：
       冲突区块的存在 → ≥ 1/3 验证者被罚没
    2. 由 LMD GHOST 的 Chain Quality：
       攻击者的区块很难被诚实节点接受
    3. 结合两者，攻击者无法在不损失押金的情况下创建冲突区块
    QED

這個證明框架被用 Coq 形式化了，可以在以太坊基金會的 formal-verification 倉庫找到。

第三章：BLS 簽章的形式化驗證

3.1 BLS 簽章基礎

BLS（Boneh–Lynn–Shacham）簽章是以太坊共識層使用的簽章方案。相比 ECDSA，BLS 的優點是：

• 簽章聚合：多個簽章可以聚合成一個
• 簡單的閾值方案
• 更好的安全性證明

簽章生成：

s = H(m)^x

其中：

• x 是私鑰
• H(m) 是消息的哈希，映射到曲線上的一個點
• s 是簽章

驗證：

e(s, G) == e(H(m), P)

其中 e 是雙線性配對，P = x * G 是公鑰。

3.2 安全性證明框架

BLS 簽章的安全性基於以下假設：

**假設（BLS 安全性）：

對任何 PPT（概率多項式時間）攻擊者 A，優勢

Adv_BLS[A] = Pr[A 赢取 BLS 游戏] 

是可忽略的。

BLS 遊戲的定義：

1. Challenger 生成密鑰對 (sk, pk)
2. A 獲得 pk，可以請求任意消息的簽章
3. A 输 出 (m, σ)
4. A 赢 如果 σ 是 m 的有效簽章，且 m* 不是查询过的消息

3.3 從 Cozian 假設到 BLS 安全性

BLS 簽章的安全性最早就被證明依賴於以下兩個假設：

假設一：Decision Diffie-Hellman (DDH) 在 G_T 中是困難的

給定 (g^a, g^b, g^c, z)，判斷 z == e(g, g)^{abc}。

假設二：Collision Resistance of Hash-to-Curve

哈希函數 H 映射消息到曲線上的點是抗碰撞的。

定理（BLS 簽章安全性）：

如果上述兩個假設成立，則 BLS 簽章在選擇消息攻擊下是存在性不可偽造（EUF-CMA）的。

證明結構：

Proof Sketch:
1. 假設存在攻擊者 A 能夠偽造 BLS 簽章
2. 我們構造一個 Challenger C 來解決 DDH 問題
3. C 將 DDH 實例注入到 BLS 參數中
4. A 的偽造可以被轉化為 DDH 解決方案
5. 這與 DDH 困難性矛盾
6. 因此不存在這樣的 A

3.4 實際的 Coq 驗證

以太坊的 BLS 簽章實現已經通過 Coq 進行了形式化驗證：

(* BLS 簽章驗證的 Coq 形式化 *)
Module Type BLS_PARAMS.
  Parameter G : group.
  Parameter GT : group.
  Parameter e : G -> G -> GT.  (* 雙線性配對 *)
  Parameter g : G.               (* 生成元 *)
  Parameter H : message -> G.    (* Hash to curve *)
  
  (* 安全性參數 *)
  Parameter q : nat.  (* 查詢次數上界 *)
End BLS_PARAMS.

Module Type BLS_SECURITY.
  Declare Module BP : BLS_PARAMS.
  
  (* 簽章驗證函數 *)
  Definition verify (pk : G) (m : message) (sig : G) : bool :=
    e sig BP.g =? e (BP.H m) pk.
    
  (* 安全性定理 *)
  Theorem security :
    forall (A : adversary),
      advantage A <= negl (SecurityParameter).
End BLS_SECURITY.

第四章：智能合約的形式化驗證

4.1 為什麼智能合約需要形式化驗證

智能合約一旦部署就很難修改，而且管理的往往是真金白銀。2016 年的 DAO 攻擊就是一個血的教訓——攻擊者利用重入漏洞盜走了 360 萬 ETH。

形式化驗證的優勢：

• 窮舉所有可能的執行路徑
• 發現測試無法觸及的邊界條件
• 提供數學上的安全性保證

4.2 EVM 的形式化語義

形式化驗證的第一步是定義 EVM 的形式化語義。這方面有幾個著名的項目：

K Framework / KEVM：

KEVM 定義了 EVM 的正式語義，用 Maude 和 Coq 實現：

// K Framework 中的 EVM 語義（示意性代碼）
syntax KResult ::= EurState

rule <k> exec(INstr) => exec(INstr') ...</k>
     <state> STATE </state>
  requires exec(INstr, STATE) => INstr' :: STATE

Eth-Isabelle / EIP：

劍橋大學的形式化驗證項目，用 Isabelle/HOL 定義了 EVM 的完整語義。

Certora Prover：

基於驗證條件生成（VCG）的自動化工具，專注於合約安全性。

4.3 簡單的合約驗證實例

讓我們用 Certora Prover 的 DSL 來驗證一個簡單的代幣合約：

// 被驗證的代幣合約
contract SimpleToken {
    mapping(address => uint) public balanceOf;
    
    function transfer(address to, uint amount) public {
        require(balanceOf[msg.sender] >= amount);
        balanceOf[msg.sender] -= amount;
        balanceOf[to] += amount;
    }
}

// Certora 驗證規則
ruleset balanceCheck {
    rule "Balance should not go negative" {
        env e;
        uint256 balanceBefore = balanceOf[e.msg.sender];
        transfer(e, to, amount);
        uint256 balanceAfter = balanceOf[e.msg.sender];
        
        // 如果 transfer 成功，餘額必然減少
        if (balanceBefore >= amount) {
            assert balanceAfter == balanceBefore - amount;
        }
    }
}

Certora 會自動窮舉所有可能的執行路徑，檢查規則是否總是成立。

4.4 用 F* 驗證密碼學實現

F 是一個函數式編程語言，可以用於驗證密碼學實現的正確性。以太坊的某些密碼學組件用 F 進行了驗證：

// F* 中的 ECDSA 驗證（示意性代碼）
module ECDSA
open LowStar.Monads.Intrinsics
open FStar.Mul

// 曲線參數
let curve_params = {
    p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F;
    n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141;
    g = (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
         0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8);
}

// 簽章驗證函數
val verify : pk:point -> msg:bytes -> sig:signature -> bool

let verify pk msg sig =
    let (r, s) = sig in
    let e = hash_to_int(msg) in
    let w = inv_mod(s, curve_params.n) in
    let u1 = (e * w) mod curve_params.n in
    let u2 = (r * w) mod curve_params.n in
    let v = point_add(point_mul(curve_params.g, u1), point_mul(pk, u2)) in
    v.x mod curve_params.n = r

第五章：密碼學假設的層級結構

5.1 為什麼要研究假設的層級

密碼學的安全性建立在各種數學假設之上。但這些假設並不是平等的，有些假設比另一些更「基礎」。

層級結構的好處：

• 如果底層假設被破解，上層的構造仍然安全（如果能被重新證明）
• 便於比較不同構造的安全性強度
• 有助於理解密碼學的「信任基礎」

5.2 以太坊的密碼學假設層級

┌─────────────────────────────────────────────────────────┐
│                    高層構造                             │
│  (BLS 聚合簽章、Casper 共識、zkSNARK 驗證)              │
├─────────────────────────────────────────────────────────┤
│                    密碼學假設                            │
│  (BLS 安全性、配對假設、多項式承諾)                      │
├─────────────────────────────────────────────────────────┤
│                    底層數學問題                          │
│  (ECDLP、CDH、DDH、q-Slogan、KZG)                       │
├─────────────────────────────────────────────────────────┤
│                    計算複雜度理論                        │
│  (P ≠ NP 等經典問題)                                    │
└─────────────────────────────────────────────────────────┘

5.3 形式化驗證與可重複使用性

形式化驗證的一個重要好處是「模塊化」。

一旦你驗證了某個密碼學原語（如配對函數）的安全性，你就可以在不重新驗證的情況下，使用這個原語構造更複雜的系統。

以太坊的形式化驗證框架提供了以下可重用構件：

• 橢圓曲線運算的正確性證明
• 配對函數的安全性分析
• 哈希函數到曲線的映射安全性
• 隨機預言機模型中的協議安全性

結語：形式化驗證不是萬能的

寫到這裡，我想說幾句實話。

形式化驗證很強大，但不是萬能的。它只能驗證你用數學語言描述的「規格」是否正確。如果你對系統的描述本身就有問題，或者忽略了某個實際的威脅模型，形式化驗證也幫不了你。

而且，形式化驗證的成本很高。一個複雜的智能合約可能要幾個月的時間才能完成形式化驗證，這在快速迭代的 Web3 開發環境中並不現實。

我的建議是：

1. 核心的、涉及大量資產的合約一定要做形式化驗證
2. 可以先用符號執行工具（如 Mythril、Slither）做快速掃描
3. 形式化驗證應該是「最後一道防線」，而不是替代其他安全措施
4. 最重要的是培養安全意識，形式化驗證只是工具

希望這篇能幫你建立對以太坊密碼學安全性的系統性理解。繼續加油！

標籤

formal-verification, cryptography, ethereum, casper, bls, consensus, security-proof, coq, smart-contract, zero-knowledge, tutorial, academic