Week 30 复习 — 签名体系整合

日期: 2026-11-18 方向: 密码学 / 经典原语 阶段: Phase 4 - 经典密码学 (Day 195-208) 标签: #密码学 #签名 #复习 #决策树

---

今日目标

---

一、五大签名族总览

---

二、按 Web3 应用场景的决策树

需要数字签名? 
├── 是否多方协作签名?
│   ├── 否（单签 EOA）
│   │   ├── 兼容现有标准 (ETH/BTC)? → ECDSA secp256k1
│   │   ├── 性能/侧信道优先 → Ed25519
│   │   └── 跨链未来扩展 → Schnorr (BIP340)
│   │
│   └── 是（多签/聚合）
│       ├── 全部签同一消息 + 大规模 → BLS (Eth2 范式)
│       ├── 不同消息聚合 → BLS aggregate (但验证慢)
│       ├── 比特币环境 → MuSig2 (Schnorr)
│       └── 阈值签名 → FROST (Schnorr) / GG20 (ECDSA) / Threshold BLS
│
├── 验证发生在?
│   ├── 链上 (gas 贵) → 短签名 + EIP-2537 BLS precompile
│   ├── 客户端 (CPU 充裕) → 任意
│   └── ZK 电路内 → Schnorr (Pasta) / Plonky3 友好签名
│
├── 私钥存储在?
│   ├── HSM / TPM → ECDSA (标准支持) / Ed25519
│   ├── 浏览器钱包 (MetaMask) → ECDSA + EIP-191 prefix
│   ├── Ledger/Trezor → ECDSA + RFC6979 (内部 secure element)
│   └── MPC 网络 (Fireblocks) → ECDSA GG18/20 阈值
│
└── 后量子需求?
    ├── 即时切换 → Dilithium / FALCON (NIST PQC)
    ├── 5-10 年 → BLS 现在用，准备 hybrid
    └── 不急 → ECDSA / Schnorr 仍可用 10+ 年

---

三、安全模型对比

3.1 EUF-CMA 严格安全证明

紧致归约的意义: 攻击 BLS 的成功率 $\epsilon$ 直接对应 co-CDH 的 $\epsilon$。Forking Lemma 的非紧致归约下，攻击 Schnorr 的 $\epsilon$ 对应 DLP 的 $\epsilon^2$ → 安全余量更小。实践影响有限。

3.2 Malleability 风险

Malleability(Bitcoin tx 角度): 同 tx 不同 sig 改 txid → mempool 双花

3.3 Nonce 失败模式

---

四、性能 Benchmark (实测)

# benchmark.py - 跨签名族测试
import time
from coincurve import PrivateKey  # ECDSA
import nacl.signing  # Ed25519
from py_ecc.bls12_381 import G1, multiply, pairing  # BLS

# 单核 Skylake @ 3.4 GHz, Python 3.11

# ECDSA secp256k1
sk = PrivateKey()
msg = b'a' * 32
t0 = time.perf_counter()
for _ in range(1000):
    sk.sign(msg)
print(f"ECDSA sign: {(time.perf_counter()-t0)*1000:.0f} μs/op")
# Output: ~50 μs

# Ed25519
sk = nacl.signing.SigningKey.generate()
t0 = time.perf_counter()
for _ in range(1000):
    sk.sign(msg)
print(f"Ed25519 sign: {(time.perf_counter()-t0)*1000:.0f} μs/op")
# Output: ~30 μs

# BLS12-381 (py_ecc 纯 Python)
# ~500 ms / op — 实际产线用 blst 库 ~500 μs / op

实测数据 (production libs)

---

五、典型协议设计案例

5.1 Bitcoin: 从 ECDSA 到 Schnorr 的演进

5.2 Ethereum: ECDSA 不变 + AA 路径

EOA 永远 ECDSA（向后兼容）。但 AA (ERC-4337) 让 smart account 自定义 verify():

• BLS account: 适合频繁多签
• WebAuthn account: 用浏览器/手机生物识别
• ZK account: 用 PLONK 证明所有权
• Quantum-resistant account: Dilithium / Falcon

EIP-7702 (Pectra 2025) 让 EOA 临时变 smart account → 渐进迁移。

5.3 以太坊 PoS: BLS 全栈

• Validator deposit: BLS keypair + PoP
• Attestation: BLS sign $(slot, head, source, target)$
• Aggregator: BLS aggregate
• Block: 含 ≤ 128 aggregate attestations
• Sync committee: 512 验证者 BLS 聚合 → 轻客户端验证

5.4 Solana: Ed25519 极简主义

每 tx 含 Ed25519 sig (64 B) + pubkey (32 B)。无聚合，但单核 100 μs 验证 → 50k TPS 物理上可行。

5.5 跨链桥的签名异构

LayerZero / Wormhole / Axelar 网络 19 个验证者，但每条链原生支持的签名不同:

• Eth: ECDSA / 未来 EIP-2537 BLS
• Solana: Ed25519
• Cosmos: Ed25519
• Aptos: Ed25519

桥的多签需在每条链生成对应格式 → 用 ECDSA GG20 + Ed25519 重签 + ... 复杂。

---

六、决策矩阵 — Product Manager 视角

---

七、常见陷阱整合 (Top 10)

1. ECDSA nonce 重用 = 私钥灾难 (Sony PS3)
2. 签名 malleability: ECDSA 必须 low-s
3. Hash-to-scalar 偏置: 截断哈希不模 q
4. BLS Rogue Key Attack: 必须 PoP
5. Subgroup check 缺失: small subgroup attack
6. Cross-chain signature replay: 缺 chain ID 域分离
7. Signature padding mismatch: SHA-3 vs Keccak (Solidity 坑)
8. EIP-191 / EIP-712 prefix 缺失: 钱包签名跨用途
9. ecrecover 失败返 zero: 必须显式检查
10. PoP 缺失 in BLS deposit 流程

---

八、签名族选择 Cheatsheet

┌─────────────────────────────────────────────────────────────┐
│ 签名族 速选指南 (Web3, 2026)                                │
├─────────────────────────────────────────────────────────────┤
│ 1. EVM EOA?                            → ECDSA secp256k1     │
│ 2. Bitcoin Taproot / future BTC L2?   → Schnorr BIP-340     │
│ 3. Solana / Sui / Aptos / Cosmos?     → Ed25519             │
│ 4. PoS 共识层 (Eth/Filecoin)?          → BLS12-381           │
│ 5. ZK rollup?                          → Schnorr or Plonky3 │
│ 6. MPC custody (Coinbase/Fireblocks)? → ECDSA GG20 / FROST  │
│ 7. 量子敏感场景?                       → Dilithium hybrid    │
│ 8. PKI / 法律证据?                     → RSA-PSS / ECDSA     │
└─────────────────────────────────────────────────────────────┘

---

九、Week 30 学习成果检验

完成本周学习后应能:

• 推导 Schnorr 签名 + Forking Lemma 直觉
• 解释 ECDSA nonce 重用导致私钥泄漏的数学
• 实现 BLS 签名聚合 + 防 Rogue Key Attack
• 选择适合不同 Web3 场景的签名方案
• 识别签名相关漏洞: malleability / subgroup / nonce / fault
• 阐述 Eth2 attestation 聚合的工程权衡
• 设计跨链桥的多签方案

---

十、面试题（综合）

Q1: Bitcoin Taproot 升级最大的密码学变化是什么？ A: 引入 Schnorr 签名 (BIP-340)，取代 ECDSA。三个根本变化: (1) 签名线性聚合 → MuSig2 让 n-of-n 多签上链时与单签无法区分（隐私 + 节省费用）; (2) 32 字节 x-only pubkey + 64 字节签名（ECDSA DER 70+ 字节）; (3) 配合 MAST 的 Tapscript 隐藏未走分支。

Q2: 为什么 Cosmos validators 用 Ed25519 但账户用 secp256k1？ A: 历史遗产 + 性能。Tendermint 设计期 Ed25519 是高性能 PoS 标准，BLS 不成熟。账户用 secp256k1 是为了 ETH-style 钱包兼容。新一代链（Aptos, Sui）二者都用 Ed25519，新一代 PoS（Eth2）走 BLS。

Q3: 如果让你设计一个新链的签名方案，怎么权衡？ A: 关键问题:

• 验证者数量: <100 → Ed25519, >1k → BLS
• ZK 证明友好? → Plonky3 sig / Schnorr on Pasta
• EVM 兼容? → 必须 ECDSA
• 量子时间窗? → 5+ 年内可能要 hybrid

我会选 BLS 共识层 + Ed25519 用户层 + AA 让 smart account 自由切换（Ethereum 2026 路线）。

Q4: MuSig2 vs FROST 的区别？ A: 都是 Schnorr 阈值签名。差异:

• MuSig2: n-of-n 总签名，无 dealer，2 round 通信
• FROST: t-of-n，有 DKG，1 round (with preprocessing)
• MuSig2 更适合多签钱包（所有方都签）；FROST 适合 t-of-n 阈值（如 9-of-15 跨链桥）
• FROST 已被 IETF 标准化 (RFC 9591)

Q5: 为什么阈值 ECDSA (GG18/20) 比阈值 BLS / FROST 复杂得多？ A: ECDSA 含 $k^{-1}$ 项，破坏线性。GG18/20 需要安全多方计算 $k^{-1}, k^{-1} z, k^{-1} r d$ 的 share，使用 Paillier 加密 + 零知识证明，轮数多 + 安全证明复杂。BLS / Schnorr 直接用 Shamir + Lagrange 即可（线性同态）。这就是为什么 ECDSA 阈值方案有过多次漏洞 (Alpha-Rays 2021、TSSHOCK 2022)，而 FROST 简单干净。

---

十一、明日预告

Day 202: 承诺方案 — 进入承诺方案领域。Pedersen 承诺基于离散对数，提供完美隐藏 + 计算绑定，是几乎所有 ZK 协议的基本积木。手写 Pedersen + 同态加法演示。