零知識證明數學推導完整指南：從密碼學基礎到以太坊應用實戰

概述

零知識證明（Zero-Knowledge Proof, ZKP）是現代密碼學中最具革命性的技術之一。這種技術允許「證明者」（Prover）在不透露任何「知識」內容的情況下，向「驗證者」（Verifier）證明自己知道某個秘密。以太坊創辦人 Vitalik Buterin 曾多次強調零知識證明對於區塊鏈隱私和擴容的重要性，將其視為以太坊未來發展的核心技術支柱。本文從數學推導的角度，全面分析零知識證明的基本原理、主要類型（SNARK、STARK、Bulletproofs）、電路設計方法，以及在以太坊上的實際應用部署。截至 2026 年第一季度，ZK-Rollup 已經處理了超過 15 億筆交易，零知識證明技術正從理論走向大規模商用。

一、零知識證明的數學基礎

1.1 形式化定義

零知識證明系統由三個核心算法組成：Setup、Prove 和 Verify。

定義 1.1.1（零知識證明系統）：一個零知識證明系統用於證明某個 NP 語言 L 的成員資格，由以下三個概率多項式時間（PPT）算法構成：

(1) Setup(1^λ, C) → pp, vp
    - 輸入：安全參數 λ，電路 C
    - 輸出：公共參數 pp，驗證金鑰 vp
    
(2) Prove(pp, x, w) → π
    - 輸入：公共參數 pp，輸入 x ∈ L，見證 w
    - 輸出：證明 π
    
(3) Verify(vp, x, π) → {accept, reject}
    - 輸入：驗證金鑰 vp，輸入 x，證明 π
    - 輸出：接受或拒絕

定義 1.1.2（完整性）：對於任何 (x, w) ∈ R，若驗證者誠實執行，則 Verify(vp, x, Prove(pp, x, w)) 總是輸出 accept，且失敗概率可忽略。

定義 1.1.3（可靠性）：對於任何 PPT 證明者 P，若 x ∉ L，則 Verify(vp, x, P(vp, x)) 輸出 accept 的概率可忽略。

定義 1.1.4（零知識性）：存在一個模擬器 Sim，使得對於任何 x ∈ L，存在一個見證 w 使得輸出分佈 {Sim(vp, x)} 與 {Prove(pp, x, w)} 在計算上不可區分。

1.2 交互式與非交互式證明

交互式零知識證明（Interactive ZKP, iZKP）：

┌─────────────┐                    ┌─────────────┐
│   Prover    │ ←──── Challenge ──→│  Verifier   │
│             │                    │             │
│  知道秘密 w │    Challenge c     │  隨機選擇   │
│             │ ──── Response r ──→│  驗證 proof │
│             │                    │             │
│  輸出 proof │                    │  輸出結果   │
└─────────────┘                    └─────────────┘

在交互式模型中，證明者與驗證者進行多輪交互。每輪中，驗證者發送一個隨機挑戰，證明者根據挑戰給出回應。交互式協議的關鍵特性是可以實現完美的零知識性（Perfect Zero-Knowledge），而不僅僅是計算零知識性。

非交互式零知識證明（NIZKP）：

Fiat-Shamir 啟發式將交互式協議轉換為非交互式版本：

證明者計算：c = Hash(x || π₁)
           r = compute_response(c, witness)

驗證者檢查：verify(c, r)

其中 Hash 是密碼學哈希函數，用於模擬驗證者的隨機挑戰。這種轉換使得證明可以被「一次性」發布和驗證，適合區塊鏈應用場景。

1.3 知識誤差與重複執行

定義 1.3.1（知識可靠性）：設 ε 為作弊證明者成功的概率。則存在一個 extractor，能在 O(1/ε) 次證明執行中提取見證。

定理 1.3.2（大數定律推論）：若一個證明系統具有知識可靠性，且作弊概率為 ε，則執行 k 次協議後，知識誤差（Knowledge Error）降為 ε^k。

證明：
P(所有 k 次嘗試都失敗) = ε^k

當 k = log_ε(2^(-λ)) 時：
ε^k = 2^(-λ)

即需要約 λ / (-log₂ ε) 次重複

二、SNARKs：簡潔非交互式知識論證

2.1 算術電路與約束系統

SNARK 的第一步是將待證明計算轉換為算術電路。

定義 2.1.1（算術電路）：算術電路是由加法和乘法門組成的有向無環圖，輸入為域元素，輸出為域元素。

電路表示：C(x, w) = 0

其中：
- x：公共輸入
- w：私有見證
- C：約束系統

約束系統形式：

常見的約束系統形式包括：

• R1CS（Rank-1 Constraint System）
• Plonkish 約束
• AIR（Algebraic Intermediate Representation）

R1CS 約束：

每個約束是三個線性組合的乘法等式：

<A, X> × <B, X> - <C, X> = 0

其中 A, B, C 是權重向量
X 是變量向量（包含 x 和 w）

2.2 多項式承諾

多項式承諾是構建 SNARK 的核心密碼學構件。

定義 2.2.1（多項式承諾方案）：

Commit(f) → C
Open(f, z) → π
Verify(C, z, y, π) → accept/reject

其中：
- f：多項式，deg(f) ≤ d
- z：挑戰點
- y = f(z)：評估值
- C：承諾
- π：開啟證明

KZG 承諾方案（Kate, Zaverucha, Goldberg）：

假設存在一個可信設置，產生：

• 結構化參考字串（SRS）：(g^τ⁰, g^τ¹, ..., g^τᵈ)
• τ ∈ Z_p 是隨機秘密（設置後需廢棄）

承諾計算：

f(X) = a₀ + a₁X + a₂X² + ... + a_dX^d

C = g^{f(τ)} = ∏ (g^{τ^i})^{a_i}
    = ∏ (g^{τ^i})^{a_i}

開啟證明：

令 h(X) = f(X) - f(z) / (X - z)
     = q(X) （多項式除法）

π = g^{h(τ)} = g^{q(τ)}

驗證：

e(C / g^{f(z)}, g) = e(π, g^{τ} / g^{z})
e(C · g^{-f(z)}, g) = e(π, g^{τ-z})

2.3 Groth16 協議推導

Groth16 是最廣泛使用的 SNARK 構造之一，基於雙線性配對。

設置階段：

給定約束系統 C 和電路矩陣 A, B, C：

選擇隨機數 r, s ∈ Z_p
計算：

α = g_1^τ · ∏ A_i(τ)^{a_i} · ∏ B_i(τ)^{b_i}
β = g_1^{rτ} · ∏ B_i(τ)^{b_i}
γ = g_2^τ
δ = g_2^{sτ}

生成 CRS：
CRS = {g_1^{τ^i}, g_2^{τ^i}, g_α, g_β, g_γ, g_δ}

證明生成：

輸入：見證 (a, b)，公共輸入 x

步驟 1：計算 a = Σ a_i(x, w)
步驟 2：計算 b = Σ b_i(x, w)
步驟 3：隨機選擇 r, t ∈ Z_p
步驟 4：計算：
   A = g_1^{a + rδ}
   B = g_2^{b + tδ}
   C = h(X) + (a - r)(b - t) + δ(-r)(b - t) + δ(其他約束)

輸出：π = (A, B, C)

驗證方程：

e(A, B) = e(g_α, g_β) · e(g_γ, g_δ)^{-x} · e(C, g_δ)

展開驗證：
左邊：e(g_1^{a+rδ}, g_2^{b+tδ})
    = e(g_1^a, g_2^b) · e(g_1^{rδ}, g_2^{tδ})
    
右邊：e(g_1^{α}, g_2^{β}) · e(g_1^{γx}, g_2^{δ})^{-1} · e(g_1^C, g_2^{δ})
    = e(g_1^{α - γx + C}, g_2^{β}) · e(g_1^{δ}, g_2^{δ})^{-t}

2.4 Plonkish 電路約束

Plonk 採用「通用且可更新」的信任設置，適用於任意電路。

約束形式：

Plonkish 約束分為三類：

1. 線性約束（Gate Constraints）：
   q_L·a + q_R·b + q_O·c + q_M·a·b + q_C = 0
   
2. 複製約束（Permutation Arguments）：
   證明某些線性組合相等
   
3. 查找約束（Lookup Arguments）：
   證明某值屬於預定義集合

複製約束的證明：

Plonk 使用「位置交換論證」（Permutation Argument）來處理複製約束：

目標：證明 wire (a_i, b_i, c_i) 的某種排列相等

定義 σ：電路位置到「邏輯位置」的置換

需要證明：σ² identity，即 σ 形成正確的分組

使用 Grand Product 論證：
Π (1 + β·X_i) = Π (1 + β·σ(X_i))

展開後需要驗證：
Σ β^i · X_i = Σ β^i · σ(X_i)  （循環等價類中）

三、ZK-STARKs：透明且可擴展的知識論證

3.1 STARK 與 SNARK 的核心區別

3.2 FRI 協議：快速 Reed-Solomon 交互式 Oracle 接近論證

STARK 的核心是 FRI 協議，用於證明某多項式位於低次數集合。

Reed-Solomon 編碼：

原始多項式：f(X) ∈ F_p[X], deg(f) ≤ d
編碼長度：n = 2^k ≥ 2d

編碼點：(x_i, f(x_i)) for i = 0, 1, ..., n-1
其中 x_i 是域的子群元素

FRI 協議步驟：

Function FRI(f, code):
    if deg(f) ≤ d_max:
        return accept
    
    // Merkle 承諾編碼
    C = MerkleCommit(f(x_i) for all x_i)
    send(C)
    
    // 隨機擾動
    α = Hash(C)
    
    // 將兩個多項式組合成下一層
    f_even(x) = (f(x) + f(-x)) / 2
    f_odd(x)  = (f(x) - f(-x)) / (2x)
    
    f'(X) = f_even(X) + α · f_odd(X)
    
    // 遞歸
    return FRI(f', code')

正確性證明：

若 f' 的次數接近 d/2，則 f 的次數接近 d：

令 f(x) = g(x²) + x·h(x²)

其中：
- g, h 的次數 ≤ d/2

則：
f_even(x) = g(x²)
f_odd(x)  = h(x²)

f'(x) = g(x²) + α·h(x²)

若 f' 的次數 > d/2，則 h(x²) 非零
即 f(x) 不在由 g(x²) 張成的空間中
即 f 的實際次數 > d

3.3 低次數測試

定義 3.3.1（低次數測試）：給定 oracle 訪問 f 的編碼，驗證 f 的代數次數 ≤ d。

直和測試：

目的：證明多項式在兩個不相交集合上的取值滿足某種關係

給定：
- f1: S1 → F
- f2: S2 → F

證明：f1(x) = f2(x) 對所有 x ∈ S1 ∩ S2

使用：
P = Σ_{x∈S1} β^x f1(x) + Σ_{x∈S2} β^x f2(x)
Q = Σ_{x∈S1∩S2} β^x f1(x)

若 f1 和 f2 處處相等，則 P = Q + Σ_{x∈S2\S1} β^x f2(x)

3.4 STARK 的完整構造

┌────────────────────────────────────────────┐
│              STARK 證明生成                 │
├────────────────────────────────────────────┤
│                                            │
│  1. 約束系統 → 代數 Intermediate Rep      │
│              ↓                              │
│  2. 約束多項式 → 低次多項式 P(x)           │
│              ↓                              │
│  3. 估值 oracle → Merkle tree             │
│              ↓                              │
│  4. FRI 論證 → 遞歸多項式證明              │
│              ↓                              │
│  5. 一次性壓縮 → 最終 proof               │
│                                            │
└────────────────────────────────────────────┘

四、以太坊上的 ZK 應用

4.1 zk-SNARK 電路設計：約束建模

以下是一個簡單的餘額轉帳電路的約束設計：

電路目標：驗證 Alice 轉帳給 Bob，餘額非負

公共輸入：(address_A, address_B, amount, root_before, root_after)
私有見證：(balance_A_before, balance_B_before, balance_A_after, balance_B_after, nonce_A)

約束系統：

1. 餘額約束：
   balance_A_after = balance_A_before - amount
   balance_B_after = balance_B_before + amount

2. 非負約束（使用範圍證明）：
   0 ≤ balance_A_after ≤ balance_A_before
   0 ≤ balance_B_after

3. 餘額證明：
   MerkleProof(address_A, balance_A_before, root_before) = true
   MerkleProof(address_B, balance_B_before, root_before) = true
   MerkleProof(address_A, balance_A_after, root_after) = true
   MerkleProof(address_B, balance_B_after, root_after) = true

4. 狀態根轉換：
   hash(merkle_tree_before) = root_before
   hash(merkle_tree_after) = root_after

R1CS 約束表示：

// 約束 1：非負性
(balance_A_after + 1) · (balance_A_after + 2) / 2 ≥ 0
// 這轉換為一組平方和約束

// 約束 2：Merkle 驗證
path_elements · hash_computation = root

4.2 以太坊 Gas 優化分析

在 EVM 上驗證 ZK 證明需要大量的 Gas 消耗。以下是各操作的 Gas 成本分析：

Gas 消耗分析（EIP-1559 後）：

1. Keccak256 哈希：30 gas/byte
2. 橢圓曲線配對驗證：34,000 gas + 80 gas/validiation
3. BN128 乘法：6 gas
4. BN128 加法：150 gas
5. 記憶體操作：3 gas/word + 二次擴展費

典型 Groth16 驗證 Gas 分解：
├── 配對檢查：34,000 × 3 ≈ 102,000 gas
├── 群加法：150 × 12 ≈ 1,800 gas
├── 群乘法：6 × 8 ≈ 48 gas
├── 哈希操作：30 × 64 ≈ 1,920 gas
└── 總計：約 110,000-150,000 gas

典型 Plonk 驗證 Gas 分解：
├── 配對檢查：34,000 × 2 ≈ 68,000 gas
├── 多標量乘法：約 50,000 gas
├── 記憶體讀寫：約 20,000 gas
└── 總計：約 140,000-200,000 gas

4.3 Groth16 驗證合約實作

以下是以太坊合約中 Groth16 驗證的關鍵代碼：

// 簡化版 Groth16 驗證器
contract Groth16Verifier {
    // G1 點結構
    struct G1Point {
        uint X;
        uint Y;
    }
    
    // G2 點結構
    struct G2Point {
        uint[2] X;
        uint[2] Y;
    }
    
    // 驗證函數
    function verifyProof(
        // 公共輸入
        uint[2] memory a_p,
        uint[4] memory b_p,
        uint[2] memory c_p,
        // 電路公共輸入
        uint[] memory inputs
    ) public view returns (bool) {
        // 計算 A × B
        G1Point memory A = G1Point(a_p[0], a_p[1]);
        G2Point memory B = G2Point([b_p[0], b_p[1]], [b_p[2], b_p[3]]);
        G1Point memory A_mul_B = pairingMultiply(A, B);
        
        // 計算驗證方程的左邊
        // e(A, B) = e(α, β) · e(-γ, δ) · e(Σ inputs_i · β_i, δ)
        
        // 配對檢查
        uint[12] memory input = new uint[12](12);
        input[0] = A_mul_B.X;
        input[1] = A_mul_B.Y;
        input[2] = IC[0][0];  // α
        input[3] = IC[0][1];
        input[4] = neg_G2_X0;  // -γ
        input[5] = neg_G2_X1;
        input[6] = neg_G2_Y0;
        input[7] = neg_G2_Y1;
        input[8] = publicInputSum;  // Σ inputs_i · β_i
        input[9] = 0;
        input[10] = G2_delta_X0;    // δ
        input[11] = G2_delta_Y0;
        
        return pairing(input);
    }
    
    // 配對乘法的優化實現
    function pairingMultiply(G1Point memory p1, G2Point memory p2) 
        internal view returns (G1Point memory) 
    {
        // 使用預編譯合約 0x08
        uint[4] memory input;
        input[0] = p1.X;
        input[1] = p1.Y;
        input[2] = p2.X[0];
        input[3] = p2.X[1];
        input[4] = p2.Y[0];
        input[5] = p2.Y[1];
        // ... 執行配對運算
    }
}

4.4 zkEVM 架構分析

zkEVM 將 EVM 執行環境移植到 ZK 電路中，實現以太坊交易的有效性證明。

zkEVM 電路組成：

┌──────────────────────────────────────────────┐
│               zkEVM 約束系統                    │
├──────────────────────────────────────────────┤
│                                              │
│  1. Execution Trace Circuit                  │
│     ├── 追蹤 EVM 執行狀態                    │
│     ├── 生成 witness                         │
│     └── 計算電路輸入                         │
│                                              │
│  2. ALU Circuit                             │
│     ├── 算術運算約束                         │
│     ├── 位運算約束                           │
│     └── 比較運算約束                         │
│                                              │
│  3. Memory Circuit                          │
│     ├── 讀寫一致性                           │
│     ├── 地址對齊                             │
│     └── 層級驗證                             │
│                                              │
│  4. Keccak Circuit                          │
│     ├── Keccak 排列約束                     │
│     └── 電路友好型替換                       │
│                                              │
│  5. Poseidon Circuit                        │
│     └── 電路友好型哈希                       │
│                                              │
└──────────────────────────────────────────────┘

zkEVM 效能瓶頸與優化：

效能瓶頸分析（2026 年第一季度）：

1. Keccak 哈希：
   - 每筆交易需要 ~20-40 次 Keccak 調用
   - 每個 Keccak 約束約 2^15 個 constraint
   - 佔總約束數的 40-60%

2. 記憶體約束：
   - EVM 有 1024 slot 的棧
   - 每個 slot 操作需要 2-4 個約束
   - 棧操作約佔 15-20% 約束

3. 配對驗證：
   - 每個最終性證明需要 2 個配對
   - 每個配對約 170,000 gas

典型交易證明約束數：
- 簡單 ETH 轉帳：~100,000 constraints
- ERC-20 轉帳：~200,000 constraints
- Uniswap swap：~500,000-1,000,000 constraints

證明時間（使用 GPU prover）：
- 簡單交易：~1-2 分鐘
- 複雜 DeFi 交互：~5-15 分鐘

五、實證數據與量化分析

5.1 ZK-Rollup 採用數據（截至 2026 年第一季度）

Layer 2 網路零知識證明採用統計：

zkSync Era：
├── 總交易量：~8 億筆
├── TVL：~$15 億
├── 日均證明生成：~500,000 筆交易/天
└── 平均證明時間：~2-5 分鐘

StarkNet：
├── 總交易量：~6 億筆
├── TVL：~$12 億
├── 日均證明生成：~400,000 筆交易/天
└── 平均證明時間：~3-8 分鐘

Polygon zkEVM：
├── 總交易量：~3 億筆
├── TVL：~$8 億
├── 日均證明生成：~200,000 筆交易/天
└── 平均證明時間：~2-4 分鐘

Scroll：
├── 總交易量：~1.5 億筆
├── TVL：~$3 億
├── 日均證明生成：~100,000 筆交易/天
└── 平均證明時間：~3-6 分鐘

5.2 Gas 節省量化分析

Gas 消耗比較（典型 ERC-20 轉帳）：

Layer 1 直接執行：
├── Gas 消耗：~65,000 gas
├── 單筆成本（@ 30 gwei）：~$15
└──  TPS：~15-30（受限於區塊 gas limit）

Optimistic Rollup（7 天最終性）：
├── L2 執行：~1,000 gas
├── 挑戰期成本分攤：~500 gas/筆
├── 單筆成本：~$0.05-0.10
└── TPS：~3,000-5,000

ZK Rollup（數分鐘最終性）：
├── L2 執行：~1,000 gas
├── 證明驗證分攤：~100-200 gas/筆
├── 單筆成本：~$0.10-0.30
└── TPS：~2,000-4,000（取決於批量大小）

ZK Rollup 隱私版本：
├── 額外隱私電路約束：~10,000-50,000 gas/筆
├── 單筆成本：$0.50-5.00
└── TPS：~500-2,000

5.3 電路約束複雜度統計

不同電路類型的約束數量（對數尺度）：

電路類型                  約束數量     相對複雜度
─────────────────────────────────────────────────
簡單餘額檢查              10^4         1x
Merkle 樹驗證 (深度 20)   10^5         10x
SHA-256 壓縮函數          10^6         100x
Keccak-256 (電路版)       10^7         1,000x
ECDSA 簽名驗證            10^8         10,000x
EVM 完整執行 trace        10^9         100,000x
zkEVM Type 2 (完整兼容)   10^10        1,000,000x

六、進階主題：zkML 與未來方向

6.1 零知識機器學習（zkML）

zkML 將機器學習推理轉換為 ZK 電路，實現 AI 模型推理的可驗證性。

zkML 約束電路設計：

# 簡化版神經網路約束電路

def neural_network_circuit(weights, biases, input_x, output_commitment):
    """
    約束一個簡單的全連接層：
    y = ReLU(Wx + b)
    """
    
    #矩陣乘法約束
    for i in range(output_dim):
        linear_sum = 0
        for j in range(input_dim):
            # 乘積約束
            mul_constraint(weights[i][j], input_x[j])
            linear_sum += weights[i][j] * input_x[j]
        
        # 加 bias
        linear_sum += biases[i]
        
        # ReLU 約束
        # y_i = max(0, linear_sum)
        # 需要引入 auxiliary 變量
        y_i = relu(linear_sum)
    
    # 輸出承諾約束
    output_hash = keccak256(y_i for i in range(output_dim))
    assert output_hash == output_commitment

zkML 應用場景：

1. 去中心化 AI 推理市場：
   - 模型所有者提供 zk-proof
   - 證明特定輸入產生了特定輸出
   - 無需透露模型權重

2. 個人化推薦系統：
   - 用戶數據本地處理
   - 只上傳推理結果和 zk-proof
   - 保護用戶隱私

3. 遊戲防作弊：
   - 遊戲邏輯在鏈下執行
   - 提交 zk-proof 證明操作有效性
   - 防止前端作弊

6.2 聚合證明技術

遞歸證明聚合：

目的：將多個證明合併為單一證明

理論基礎：
若存在 NIZKP 系統 Π，則可以構造：
- Π 的證明可以驗證另一個 Π 證明
- 這允許「證明的證明」的構造

實際應用：
- zkBridge：跨鏈證明聚合
-zkEmail：郵件簽名聚合
- 批量交易所結算證明

Supernova 方案：

新型遞歸方案，支持不同電路的證明聚合：

特點：
1. 允許證明者是「可復用的」
2. 每次遞歸切換到不同電路
3. 只需一個 final verification key

應用場景：
- 多應用 ZK 應用
- 漸進式電路升級
- 異構計算驗證

6.3 後量子 ZK 趨勢

後量子安全 ZK 構造研究（2026 年第一季度）：

1. 基於格的 ZK：
   - Lattice-based commitments
   - 優點：抗量子攻擊
   - 缺點：證明大小較大

2. 基於哈希的 ZK（STARK 已是後量子）：
   - 進一步縮小證明大小
   - 減少Verifier時間

3. 基於 MQ 的 ZK（Multivariate Quadratic）：
   - 新的研究方向
   - 理論上有更小證明

代表性項目：
├── Moonshot（StarkWare）
├── zkSHA（ConsensSys）
├── LatticeZK（ETH Foundation）
└── BASS（MIT research）

七、結論

零知識證明技術經過四十年的發展，從理論密碼學構造走向了實際工程部署。以太坊的 ZK-Rollup 生態系統在 2025-2026 年經歷了爆發式增長，成為區塊鏈擴容和隱私保護的核心技術支柱。

從數學角度看，SNARK 基於雙線性配對的精妙構造，STARK 基於代數編碼和哈希的簡潔設計，都在實際應用中展現了強大的生命力。隨著電路設計工具的成熟、硬體加速的進步，以及後量子安全研究的深入，零知識證明技術將繼續引領區塊鏈隱私和擴容的創新前沿。

理解零知識證明的數學基礎，不僅對於密碼學研究者至關重要，對於希望深入理解 Layer 2 技術架構的以太坊開發者和投資者同樣不可或缺。隨著 zkEVM、zkML 等新興應用的成熟，零知識證明將成為 Web3 時代最重要的底層技術之一。

參考來源

1. Goldwasser, S., Micali, S., & Rackoff, C. "The Knowledge Complexity of Interactive Proof-Systems." SIAM Journal on Computing, 1989.
2. Groth, J. "On the Size of Pairing-based Non-interactive Arguments." EUROCRYPT 2016.
3. Plonk: "Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge." Gabizon et al., 2020.
4. Ben-Sasson, E. et al. "STARKs: Proofs with Verifiable Computation." STARK paper series, 2018.
5. Ethereum Foundation. "Zero-Knowledge Proofs." ethereum.org/developers/docs/scaling/zk-rollups, 2026.
6. StarkWare Industries. "StarkNet: A DecentralizedValidity Proofs Layer 2." starknet.io, 2026.
7. zkSync Team. "zkEVM Architecture." docs.zksync.io, 2026.
8. Buterin, V. "An Incomplete Guide to Rollups." vitalik.ca, 2021.
9. Polygon zkEVM Team. "Polygon zkEVM Technical Documentation." docs.polygon.technology, 2026.
10. ETHStorage. "ZK Proof Systems Comparison." ethstorage.github.io, 2026.