返回 Expert 笔记
Expert Day 270

Expert Day 270 (附): Phase 4 资深密码学面试题集（30道）

Expert Day 270 (附): Phase 4 资深密码学面试题集（30道）

2027-01-26
Phase 4 综合产出
面试题密码学ZK求职

日期: 2027-01-26 方向: 密码学工程 / ZK / FHE / MPC / TEE 阶段: Phase 4 综合产出 标签: #面试题 #密码学 #ZK #求职

题目分布与难度

类别题号数量来源 Day 范围
一、密码学数学类Q1-Q66Day 181-194
二、经典密码学类Q7-Q126Day 195-208
三、ZK 理论类Q13-Q186Day 209-222
四、ZK 工程类Q19-Q257Day 223-243
五、隐私技术类Q26-Q305Day 244-258

难度分布：资深 18 / 高 8 / 中 4 ⭐ 高频核心题（top 6）：Q1, Q8, Q13, Q14, Q19, Q20, Q26（7 道，全文用 ⭐ 标记）

使用方法：

  1. "简短回答"必须 30 秒能讲出
  2. "详细回答"用 STAR-T 结构，2-3 分钟
  3. "追问准备"是层层深挖时的弹药库
  4. 涉及公式/代码的题，准备好白板复现

一、密码学数学类（Q1-Q6）

⭐ Q1. 解释椭圆曲线点加法的几何意义 + 代数公式 + 为什么需要 special case

类别: 椭圆曲线 / 数学基础 难度: 资深 考察点: 几何直觉、代数推导、边界情况、与 ZK/签名的关联

简短回答（30秒）: 椭圆曲线 y² = x³ + ax + b 上的点加法 P + Q 几何上是"过 P、Q 作直线交曲线于第三点 R'，再关于 x 轴反射得到 R"。代数上是用斜率 λ 和 P 坐标推出 R。Special case 出现在 P = Q（切线代替割线）和 P = -Q（直线竖直无第三交点，定义为无穷远点 O）。这两个 special case 不是数学瑕疵，而是让点加法在所有情况下封闭的必需机制——这才使椭圆曲线上的点构成阿贝尔群。

详细回答（2-3分钟）:

  1. 背景/定义： 椭圆曲线 E: y² = x³ + ax + b（在素数域 F_p 上），加上无穷远点 O，构成阿贝尔群。点加法是这个群的群运算，是 ECDSA、ECDH、BLS、所有基于 EC 的 ZK 方案的基础原语。

  2. 核心机制：

    几何直觉（先于代数）：

        Case 1: P ≠ Q, P ≠ -Q
    ──────
      过 P, Q 作割线 → 与曲线交于第三点 R'
      R' 关于 x 轴反射 → R = P + Q

    Case 2: P = Q (倍点)
    ──────
      过 P 作切线（割线退化）→ 与曲线交于 R'
      R' 关于 x 轴反射 → R = 2P

    Case 3: P = -Q (Q = (x, -y))
    ──────
      过 P, Q 的直线竖直，无第三交点
      结果定义为 O（无穷远点）

    代数公式（secp256k1，a = 0）：

    斜率 λ:
  Case 1 (P ≠ Q):    λ = (y_Q - y_P) / (x_Q - x_P) mod p
  Case 2 (P = Q):    λ = (3 x_P²) / (2 y_P) mod p   ← 切线导数

结果 R = (x_R, y_R):
  x_R = λ² - x_P - x_Q mod p
  y_R = λ (x_P - x_R) - y_P mod p

  3. 关键 trade-off：

    计算成本Case 1 (加)Case 2 (倍)
    域乘法次数2M + 1S + 1I2M + 2S + 1I
    是否需要分支是是

    分支是侧信道攻击（timing attack）的源头。生产中用统一公式（unified formulas，如 Edwards curves）或完备公式（complete formulas, Renes-Costello-Batina 2016）消除分支。

  4. 真实案例/数据：

    • secp256k1（比特币、以太坊）：a = 0, b = 7, p = 2^256 - 2^32 - 977
    • Curve25519（Signal、TLS 1.3）：用 Montgomery 形式 + 统一公式，无 special case 分支
    • BLS12-381（以太坊 2.0、Filecoin）：embedding degree 12，支持 pairing
    • 特性比较：secp256k1 加法 ~1µs；BLS12-381 G1 加法 ~5µs，G2 加法 ~30µs（因为 F_p² 上）

  5. 我的观点： Special case 不是"麻烦"，而是揭示了"群的封闭性"是数学构造刻意为之的。理解这一点之后再去看 ECDSA / Schnorr 签名才会真正"通"——所有 EC 上的协议本质上都是在这个群结构上设计逆向不可解的问题（DLP）。

追问准备:

  • Q: 为什么椭圆曲线点加法构成的群是阿贝尔的？ → A: 几何对称性：交换 P, Q 后割线不变，所以 P + Q = Q + P。结合律来自 Bezout 定理（推导较复杂）。
  • Q: 为什么不直接在 R 上做而是 F_p 上？ → A: 离散性是密码安全的前提。F_p 上的 DLP 才有指数级困难，R 上有连续逆映射。
  • Q: 倍点公式里用导数这事如何严格化？ → A: 在代数几何意义下，切线是相切的极限割线；公式上把 (y_Q - y_P)/(x_Q - x_P) 求 Q → P 极限即得。

Q2. 比较 secp256k1 / Curve25519 / BLS12-381 / BN254 在 Web3 中的用途

类别: 椭圆曲线选型 难度: 高 考察点: 曲线特性、性能对比、应用场景、历史包袱

简短回答（30秒）: secp256k1 历史选择（比特币、以太坊签名），有 endomorphism 加速但无 pairing；Curve25519 性能/安全性最佳，TLS/Signal 主流；BLS12-381 有 pairing + 高安全级（128-bit），以太坊 2.0/Filecoin 使用；BN254 历史上 ZK 主流（Groth16），但安全级降到 ~100-bit，已逐步被 BLS12-381 取代。

详细回答:

  1. 核心对比表：

    曲线安全级Pairing主用途关键特性
    secp256k1128-bit无BTC/ETH 签名endomorphism 加速 ~30%
    Curve25519128-bit无TLS/Signal/SSHMontgomery, 无 special case
    BLS12-381128-bit有ETH2/Filecoin/Aleopairing-friendly, embedding 12
    BN254 (alt_bn128)~100-bit有早期 ZK SNARKprecompile in EVM since Byzantium

  2. 安全级降级 BN254：

    • 2016 年 BN254 估计 ~128-bit
    • 2017 Kim-Barbulescu 攻击降到 ~110-bit
    • 当前估计 ~100-bit，已不推荐新项目使用
    • EIP-2537 引入 BLS12-381 precompile 以替代

  3. EVM 内置：

    • secp256k1: ECRECOVER (gas 3000)
    • BN254 ADD/MUL/PAIRING: 0x06/0x07/0x08 precompile (since Byzantium)
    • BLS12-381: EIP-2537 (尚未 finalize 但 Pectra 2025 引入)

  4. 真实案例：

    • 以太坊 1.0 Groth16 验证用 BN254 → 早期 Tornado Cash, Aztec v1
    • 以太坊 2.0 BLS 签名聚合用 BLS12-381 → 100k 验证者签名聚合
    • Filecoin 用 BLS12-381 做 PoSt 证明聚合

  5. 我的观点： 选曲线时优先 BLS12-381，除非 (a) 需要 EVM precompile 内 verify ZK 证明（仍用 BN254 + EIP-2537 过渡）或 (b) 历史包袱（如继承 secp256k1 钱包）。Curve25519 是非 pairing 协议的现代默认。

追问准备:

  • Q: pairing-friendly 是什么意思？ → A: embedding degree k 适中（不太大不太小），让 G_T = F_{p^k} 上的 DLP 仍然安全的同时 pairing 计算可行。
  • Q: 为什么不全用 BLS12-381？ → A: 性能。BLS12-381 G1 加法 ~5µs vs secp256k1 ~1µs。无 pairing 场景没必要付这个开销。

Q3. 双线性 pairing 的 3 条性质？为什么需要嵌入度（embedding degree）？

类别: 双线性映射 / pairing 难度: 资深 考察点: 数学定义、安全参数、ZK SNARK 基础

简短回答: Bilinear pairing e: G1 × G2 → G_T 满足三性质：(1) 双线性 e(aP, bQ) = e(P, Q)^(ab)，(2) 非退化 e(P, Q) ≠ 1，(3) 可计算性。Embedding degree k 是最小整数使 r | p^k - 1（r 是 G1 阶），决定了 G_T 在 F_{p^k} 上。k 太小（如 1）会让 MOV 攻击把 ECDLP 转换为 F_{p^k} 上的 DLP（容易解）；k 太大计算 pairing 太慢。BLS12-381 的 k = 12 是性能/安全平衡点。

详细回答:

  1. 三性质详细：

    双线性: e(aP, bQ) = e(P, bQ)^a = e(P, Q)^(ab)
非退化: 存在 P, Q 使 e(P, Q) ≠ 1_GT
可计算: 存在多项式时间算法计算 e

  2. embedding degree 的意义：

    • 定义：最小 k 使 r | p^k - 1，即 G_T = F_{p^k}^*
    • MOV 攻击：把 G1 上 ECDLP 转换为 F_{p^k} 上 DLP
    • F_{p^k} 上 DLP 用 index calculus 是亚指数级，比 EC 上 sqrt(r) 快
    • 所以 k 必须大到 F_{p^k} 上 DLP 仍 ≥ 128-bit 安全
    • 但 k 太大（如 100）pairing 计算指数爆炸

  3. 常见曲线的 k：

    • BN254: k = 12
    • BLS12-381: k = 12
    • BLS24-XXX: k = 24（更高安全级别用）

  4. 3 类 pairing：

    • Type 1: G1 = G2（symmetric）
    • Type 2: G2 上有 efficient hashing 但 no efficient endomorphism
    • Type 3: G1 ≠ G2，无 efficient hash to G2（最常用）

  5. 真实案例：BLS 签名 verify 用一次 pairing：e(σ, g_2) =? e(H(m), pk)。Groth16 验证用 3 次 pairing。

追问准备:

  • Q: BN254 vs BLS12-381 的 k 都是 12，为什么安全级不同？ → A: BN254 用 BN family 构造，p ≈ 254-bit；BLS12-381 用 BLS family，p ≈ 381-bit，所以 F_{p^12} ≈ 4572-bit vs 3048-bit。
  • Q: Tate vs Weil pairing 区别？ → A: Tate 计算更快，是工程实现首选；Weil 是数学上更对称的定义。

Q4. 解释 CRT（中国剩余定理）在 RSA 加速中的应用

类别: 数论 / RSA 难度: 中 考察点: 数论基础、性能优化、侧信道隐患

简短回答: RSA 解密 m = c^d mod N（N = pq）需要 |d| ≈ 2048 次模乘。用 CRT 把计算拆到 mod p 和 mod q 上：m_p = c^(d mod p-1) mod p, m_q = c^(d mod q-1) mod q，再用 CRT 重构 m。每次指数运算操作数从 2048-bit 降到 1024-bit，单次模乘快 4 倍，总共加速 ~4×。但 CRT 实现有侧信道风险：Bellcore 错误攻击只需一次错误结果就能分解 N。

详细回答:

  1. CRT 公式：

    d_p = d mod (p-1),  d_q = d mod (q-1)
m_p = c^d_p mod p,  m_q = c^d_q mod q
q_inv = q^(-1) mod p   (precomputed)
h = q_inv · (m_p - m_q) mod p
m = m_q + h · q

  2. 加速原因：模乘复杂度 O(n²)（schoolbook）或 O(n log n)（FFT），所以 1024-bit 模乘比 2048-bit 快约 4 倍；做两次 1024-bit 总开销仍 ~50% of 一次 2048-bit。

  3. Bellcore 攻击：

    • 在计算 m_p 时引入故障 → m_p' ≠ m_p
    • 攻击者拿到 σ = m_q + q · q_inv · (m_p' - m_q)
    • 计算 gcd(σ^e - c, N) = q
    • 一次故障解 N

  4. 生产中防护：

    • 计算后做完整性校验：σ^e =? c mod N
    • 用恒定时间实现，禁止条件分支
    • HSM 内做硬件级一致性检查

  5. 真实案例：OpenSSL 历史上多次 CRT 侧信道 CVE（如 2016 CacheBleed）。

追问准备:

  • Q: 为什么 d mod (p-1) 而不是 d mod p？ → A: Fermat 小定理 a^(p-1) ≡ 1 mod p，所以 c^d = c^(d mod p-1) mod p。

Q5. FFT 如何实现 O(n log n) 多项式乘法？为什么对 KZG 重要？

类别: FFT / 多项式承诺 难度: 高 考察点: 算法、KZG 性能、ZK 应用

简短回答: FFT 利用单位根的递归对称性，把 n-阶多项式求值从 O(n²) 降到 O(n log n)。原理是 P(x) = P_even(x²) + x · P_odd(x²)，在 ω, -ω 求值合并。KZG 承诺需要 prover 计算 commitment = Σ a_i · [τ^i]，本质是多项式在 trusted setup 上的求值；FFT 把 prover time 从 O(n²) 降到 O(n log n)，是大电路（n = 2^28 = 268M）可行的关键。

详细回答:

  1. FFT 算法核心：

    def fft(a, omega):  # a: 长度 n 系数向量
    if len(a) == 1: return a
    a_even = fft(a[0::2], omega²)
    a_odd  = fft(a[1::2], omega²)
    y = [0] * len(a)
    for k in range(len(a) // 2):
        y[k]            = a_even[k] + omega^k · a_odd[k]
        y[k + n // 2]   = a_even[k] - omega^k · a_odd[k]
    return y

    每层做 n 次乘加，共 log n 层，O(n log n)。

  2. 多项式乘法：

    p(x) · q(x):  系数表示 → FFT → 点值 → 逐点乘 → IFFT → 系数
总开销: O(n log n) 远好于 schoolbook O(n²)

  3. 对 KZG 的意义：

    • KZG commit: C = Σ a_i · [τ^i]_1（G1 上的标量乘求和）
    • n = 2^28 时朴素需要 268M 次 G1 标量乘
    • MSM (multi-scalar multiplication) + FFT 让 prover 在分钟级完成
    • Groth16 trusted setup 用 FFT 计算 σ_1.A_i, σ_1.B_i 等

  4. NTT (Number Theoretic Transform)：

    • FFT 在 R 上数值不稳，密码学用 NTT（FFT 在 F_p 上）
    • 需要 p 中含 2^k 次单位根（NTT-friendly prime, e.g. Goldilocks p = 2^64 - 2^32 + 1）

  5. 真实数据：

    • Groth16 prover 14M 约束: ~2 分钟（笔记本）
    • PlonK prover 同规模: ~5 分钟（更多 polys）
    • 不用 FFT 估算: ~天级

追问准备:

  • Q: 为什么选 Goldilocks 64-bit 而不是 BN254 scalar field? → A: Plonky2 用 64-bit field 让 NTT 在 SIMD 上跑得更快，trade-off 是需要更多约束数。

Q6. 后量子计算威胁下，crypto 该选哪些方案？

类别: 后量子 / 长期安全 难度: 高 考察点: 量子算法影响、PQC 候选方案、迁移策略

简短回答: Shor 算法破 ECDLP/RSA（多项式时间），Grover 把对称密钥安全减半。NIST PQC 标准化（2024）选定：(1) ML-KEM (Kyber) for KEM, (2) ML-DSA (Dilithium) for signature, (3) SLH-DSA (SPHINCS+) for hash-based signature, (4) FALCON for NTRU-based。Web3 还要考虑 ZK 系统：Hash-based ZK（FRI/STARK）已经天然 PQ-safe；pairing-based（Groth16/PlonK-KZG）会被破。建议 2030 年前完成迁移。

详细回答:

  1. 量子威胁矩阵：

    算法量子破法影响迁移紧迫性
    RSAShor完全破高
    ECDSAShor完全破高
    AES-256Grover安全级 → 128低
    SHA-256Groverpreimage 安全 → 128低
    Groth16Shor on EC完全破中（看链何时迁移）
    STARK (FRI)无不受影响 ✅无

  2. NIST PQC 选定方案（FIPS 203/204/205, 2024-08）：

    • ML-KEM (Kyber): lattice-based KEM
    • ML-DSA (Dilithium): lattice-based signature
    • SLH-DSA (SPHINCS+): hash-based signature
    • FALCON: NTRU lattice signature

  3. Web3 迁移挑战：

    • 比特币/以太坊：硬分叉 + 新地址类型
    • 历史 UTXO/账户：暴露 pubkey 后被破解
    • 量子存储攻击：今天截获密文，量子机出现后解密
    • 建议：2027-2030 引入 PQ-safe 签名（如 Dilithium）作为可选

  4. ZK 选型：

    • 长期项目（>10 年）：选 STARK/FRI
    • 短期应用：Groth16/PlonK 仍 fine
    • 混合：Halo2 用 IPA 不是 PQ-safe（DL 假设），但比 KZG 灵活

  5. 真实进展：

    • Cloudflare 已部署 Kyber + X25519 hybrid
    • StarkWare 内嵌 STARK 已经是 PQ-safe ZK L2
    • 以太坊 PQ roadmap：2030+ 可能引入 Dilithium 签名 EOA

追问准备:

  • Q: lattice 安全假设是什么？ → A: LWE (Learning With Errors) / SIS (Short Integer Solution) / NTRU。当前最有效攻击是 BKZ lattice reduction，亚指数级。
  • Q: 为什么不直接全部切到 STARK？ → A: prover time 慢 10x、proof size 大 100x（kB vs 192 byte）。

二、经典密码学类（Q7-Q12）

Q7. 解释 Schnorr 签名的安全证明（基于 ROM 和 Forking Lemma）

类别: 数字签名 / 安全证明 难度: 资深 考察点: ROM、reduction、Forking Lemma 直觉

简短回答: Schnorr 签名 (R, s) = (kG, k + H(R || m) · d) 在 Random Oracle Model 下安全归约到 ECDLP。证明用 Forking Lemma：假设有伪造者 A，rewind 它两次（同 R、不同 hash 输出），得到 (s_1, h_1) 和 (s_2, h_2)，联立 s_1 - s_2 = (h_1 - h_2) · d，解出 d。这就把伪造能力归约到了 DLP 求解。安全级是 q²/2^n（q 是 hash query 数）。

详细回答:

  1. Schnorr 签名：

    Sign(d, m):
  k ← random
  R = k · G
  e = H(R || m)
  s = k + e · d mod n
  return (R, s)

Verify(P, m, R, s):
  e = H(R || m)
  return s · G =? R + e · P

  2. Forking Lemma 直觉：

    • 假设伪造者 A 在 hash query q 次后输出有效签名 (R, s)
    • 把 A 当 oracle，rewind 到他查询 H(R || m) 那一刻
    • 第二次跑用不同的 hash 答案 h'，A 输出 (R, s')
    • 联立： 
      s · G = R + h · P
s' · G = R + h' · P
→ (s - s') · G = (h - h') · P
→ d = (s - s') / (h - h') mod n
    • 解出私钥 = 解 ECDLP

  3. ROM 的争议：

    • ROM 假设 hash function 是真随机函数
    • Canetti-Goldreich-Halevi 2004 证明：ROM-secure 不蕴含 std-model-secure
    • 但实践中 ROM-secure 被认为"够用"

  4. 关键参数：

    • q hash queries → 成功概率 1/q²（forking lemma）
    • 想要 128-bit 安全 → curve order n ≥ 2^256

  5. 真实案例：

    • BIP-340 (Taproot): Schnorr 替代 ECDSA，签名聚合更简单
    • 以太坊正在讨论 Schnorr precompile

追问准备:

  • Q: Schnorr vs ECDSA 优势？ → A: 线性（聚合友好）、可证明安全、无可锻性、签名 64 byte（ECDSA 也 64-72）。
  • Q: forking lemma 为什么是 1/q² 而不是 1/q？ → A: rewind 后必须命中同一个 hash query，所以再有 1/q 因子。

⭐ Q8. ECDSA nonce 重用如何导致私钥泄漏？Sony PS3 案例分析

类别: 签名 / 安全事件 难度: 资深 考察点: ECDSA 数学、侧信道、真实漏洞复盘

简短回答（30秒）: ECDSA 用同一 k 签两条不同消息时，可联立两个签名方程消掉 k，直接解出私钥 d。Sony PS3 用静态 k 签固件升级，2010 fail0verflow 在 27C3 演示用两个不同固件签名 5 行代码解出 root key。从此 ECDSA 不能用确定性 k。RFC 6979 规定 k = HMAC(d, m) 强制确定但 unique。

详细回答（2-3分钟）:

  1. ECDSA 数学：

    Sign(d, m):
  k ← random  (1 ≤ k < n)
  R = k · G,  r = R.x mod n
  s = k^(-1) (H(m) + r · d) mod n
  return (r, s)

  2. k 重用攻击：

    两个签名 (r, s_1) on m_1 和 (r, s_2) on m_2 (相同 r → 相同 k)

s_1 = k^(-1) (h_1 + r d)
s_2 = k^(-1) (h_2 + r d)

s_1 - s_2 = k^(-1) (h_1 - h_2)
→ k = (h_1 - h_2) / (s_1 - s_2) mod n

d = (s_1 · k - h_1) / r mod n   ← 私钥

    一行 Python 解出私钥。

  3. Sony PS3 案例（2010-12-29 27C3）：

    • PS3 固件升级签名用 Lv0 root key
    • 实现 bug：k 写死成常数（懒得做随机化）
    • fail0verflow 取两个不同固件的签名
    • 用上式解出 Sony 的 ECDSA private key
    • PS3 整代加密体系崩溃，从此无法关闭 jailbreak

  4. 类似案例：

    • Android 2013 SecureRandom 弱：多个 BTC 钱包同 k → 私钥泄漏
    • 2019 多个硬件钱包侧信道泄漏 k 高位 bit → lattice 攻击解 d
    • Trezor One 2019 fault injection 泄漏 nonce

  5. 防御：

    • RFC 6979：k = HMAC-DRBG(d, H(m))，确定但每条消息不同
    • 侧信道防护：恒定时间标量乘，blinding（k → k + λ·n）
    • Schnorr 替代：Schnorr 签名对 k 重用不那么致命（但仍泄漏 d）

追问准备:

  • Q: 为什么 RFC 6979 要把 d 放进 HMAC 的 key？ → A: 让攻击者即使知道 m 也不能预测 k。如果 k = H(m) 攻击者也能算，重用风险变高。
  • Q: 部分泄漏 k 的位（如 8 位）能否解 d？ → A: 能。Howgrave-Graham-Smart 2001 用 lattice + Bleichenbacher 攻击，30 个签名 + 8 bit leak 解出 d。
  • Q: 为什么 Schnorr 比 ECDSA 更"健壮"？ → A: Schnorr 公式 s = k + e·d 是线性的，多签可聚合；ECDSA 公式有 k^(-1) 非线性，难以聚合。但 k 重用都同样致命。

Q9. BLS 聚合签名的优势？以太坊 2.0 如何使用？

类别: 聚合签名 / 共识 难度: 高 考察点: pairing 应用、聚合机制、ETH2 设计

简短回答: BLS 签名 σ = d · H(m)，验证 e(σ, g_2) = e(H(m), pk)。N 个签名可聚合为 σ_agg = Σ σ_i，验证 e(σ_agg, g_2) = Π e(H(m_i), pk_i)（同消息时简化为 e(H(m), Σ pk_i)）。以太坊 2.0 用 BLS 聚合 100k+ validator 同 epoch 投票为单签名 + 单 verify，否则共识带宽爆炸。代价：pairing 验证慢（10ms/次），但 N 个签名只验一次。

详细回答:

  1. BLS 签名：

    KeyGen: d ← Z_r,  pk = d · g_1
Sign(d, m): σ = d · H(m)         (H 哈希到 G2)
Verify(pk, m, σ): e(σ, g_2) =? e(H(m), pk)

  2. 聚合：

    σ_agg = σ_1 + σ_2 + ... + σ_N    (G2 加法)
pk_agg = pk_1 + pk_2 + ... + pk_N (G1 加法)
Verify (same m): e(σ_agg, g_2) =? e(H(m), pk_agg)

    N 个签名 → 1 个签名 + 2 次 pairing。

  3. 以太坊 2.0 应用：

    • 每 epoch (32 slot ≈ 6.4min)，每个 validator 投 attestation
    • 100k validator → 100k 签名 → 聚合为 ~1 签名
    • 节省网络/存储/验证：100k× → 1×
    • subnet aggregation：先在子网内聚合，再上 beacon chain

  4. Rogue Key 攻击防护：

    • 朴素聚合 + 任意 pk 选择 → 攻击：选 pk_2 = -pk_1 + g·d_2，能伪造
    • Proof of Possession：注册时提交 σ_pop = d · H(pk)，验证 e(σ_pop, g_2) = e(H(pk), pk)
    • 以太坊 2.0 deposit 强制 PoP

  5. 真实数据：

    • BLS sign: ~1ms (BLS12-381)
    • BLS verify (single): ~5ms (1 pairing + 1 hash-to-curve)
    • BLS verify (aggregated 100): ~5ms (相同 cost)
    • 节省 100×

追问准备:

  • Q: BLS vs Schnorr 聚合对比？ → A: BLS 非交互聚合（多个签名直接相加）；Schnorr MuSig2 需要 2 轮交互（共享 nonce 承诺）。
  • Q: BLS 签名为什么慢？ → A: pairing 是核心 bottleneck，~3ms。优化方向：multi-pairing（同一 verify 多个 pairing 共享 final exponentiation）。

Q10. KZG 承诺与 Merkle Tree 承诺的 trade-off？以太坊 4844 如何选？

类别: 多项式承诺 / 数据可用性 难度: 资深 考察点: 多项式承诺、proof 大小、抽样、DA

简短回答: KZG 承诺常数大小（48 byte），点开值 proof 也 48 byte，verifier O(1)；Merkle proof 是 O(log n)（~10 个 hash, ~320 byte）。KZG 缺点：需要 trusted setup，prover 需要 G1 上的 MSM（O(n log n)）。以太坊 4844 (proto-danksharding) 选 KZG 因为 (a) blob 数据可达 128 KB × 6 = 768 KB/block，需要恒定 commitment 大小；(b) data availability sampling 需要 polynomial 抽样开值，KZG 天然支持。

详细回答:

  1. 核心对比：

    特性KZGMerkle
    Commitment 大小48 byte (G1 point)32 byte (hash)
    Single proof48 byteO(log n) hashes
    Multi proof48 byte (batch)O(k log n)
    Verifier1 pairingO(log n) hashes
    Trusted setup是否
    PQ-safe否是
    Algebraic 性质强（可在密文计算）弱

  2. KZG 工作原理：

    Setup: τ random, [τ^i]_1 for i = 0..n-1   ← trusted, must destroy τ
Commit(p): C = Σ p_i [τ^i]_1 = [p(τ)]_1
Open at z: π = [(p(x) - p(z)) / (x - z)]_1 at x = τ
Verify: e(C - [p(z)]_1, g_2) =? e(π, [τ - z]_2)

  3. EIP-4844 选 KZG 原因：

    • DAS (Data Availability Sampling)：随机取 polynomial 上 k 个点开值；KZG 支持 batch open in O(k)
    • Commitment 恒定：1 blob = 4096 evals → 1 个 commitment
    • versioned hash：H(commitment) 作为链上引用
    • Merkle 替代会让 proof 大 100×（4096 leaf）

  4. Trusted setup：

    • KZG ceremony 2023：14 万人贡献，只要一人诚实即安全
    • 单点失败 = τ 没销毁 → 任意伪造 commitment 开值
    • Halo / FRI 不需要 trusted setup（用 Reed-Solomon + 抽样）

  5. 真实数据：

    • Blob 大小：128 KB
    • 4096 evals × 48 byte commitment overhead = ~3% overhead
    • 验证一个 blob commitment: ~5ms

追问准备:

  • Q: 为什么 4844 不用 FRI/STARK？ → A: FRI proof 太大（kB 级），不适合塞进 block header。KZG 48-byte 极简。
  • Q: 如果未来 quantum 来了 KZG 怎么办？ → A: 正在研究 PQ-safe polynomial commitment（如 hash-based / lattice-based），但仍是研究中。

Q11. FROST 阈值签名相比 GG20 的优势？

类别: MPC / 阈值签名 难度: 高 考察点: t-of-n、轮数、安全模型

简短回答: FROST (Komlo-Goldberg 2020) 是 Schnorr-based t-of-n 阈值签名，2 轮签名（offline preprocess + online sign）；GG20 (Gennaro-Goldfeder 2020) 是 ECDSA-based，6+ 轮。FROST 优势：(a) 轮数少 → 适合 mobile / async；(b) Schnorr 线性可组合，易实现；(c) 抗 ROS 攻击。劣势：要求底层 Schnorr，老系统（BTC pre-Taproot, ETH）需要 ECDSA，仍需 GG20。

详细回答:

  1. FROST 流程：

    Preprocess (offline, 1-time per signer):
  d_i, e_i ← random
  D_i = d_i · G,  E_i = e_i · G
  publish (D_i, E_i)

Round 1 (sign on m):
  B = (D_i, E_i) for participants
  ρ_i = H(i, m, B)
  R = Σ (D_i + ρ_i · E_i)
  c = H(R || pk || m)
  z_i = d_i + ρ_i · e_i + λ_i · s_i · c   (s_i = share of d, λ_i Lagrange coef)
  publish z_i

Round 2 (combine):
  z = Σ z_i
  signature = (R, z)

  2. GG20 流程（ECDSA 阈值）：

    • Round 1-2: MtA (multiplicative-to-additive) for k_i · γ_i
    • Round 3-4: zero-knowledge consistency proofs
    • Round 5: reveal s_i shares
    • Round 6: combine
    • 需要 Paillier 加密 + ZK proof（重）

  3. 关键对比：

    维度FROSTGG20
    底层签名SchnorrECDSA
    轮数 (sign)2 (1+1 with preprocess)6+
    Identifiable abort是是
    性能 (3-of-5)~50ms~2s
    库成熟度中（ZF Frost）高（Coinbase, Fireblocks）

  4. 应用：

    • FROST: Coinbase prime, ZF 提议比特币 Taproot 多签
    • GG20: Fireblocks, Curv, Binance custody (ECDSA 依赖)

  5. 真实考量： ECDSA 不是聚合友好的（k^(-1) 非线性），所以 GG20 必须用 Paillier 同态加密绕开。FROST 利用 Schnorr 的线性，自然 t-of-n 友好。

追问准备:

  • Q: ROS attack 是什么？ → A: Reduction Of Schnorr，Wagner generalized birthday attack，对 nonce 选择有约束。FROST 通过 binding factor ρ_i 防御。
  • Q: t-of-n 怎么处理 abort？ → A: identifiable abort：哪个参与者不诚实可被识别并 blame，避免 DoS。

Q12. Verkle Tree 取代 Merkle Patricia Trie 的核心动机？

类别: 数据结构 / 状态承诺 难度: 高 考察点: 树结构、proof 大小、stateless client

简短回答: MPT proof 大小是 O(log_16 n) = ~4-5 KB（每层 16 个 hash 兄弟）。Verkle Tree 用 KZG/IPA 向量承诺替换 hash tree，每层只需 1 个 commitment 而不是 16 个 hash sibling，proof 缩到 ~200 byte。这是以太坊 stateless client 的关键：witness 从几 MB 缩到 KB 级，让验证者无需存全状态。代价：Verkle 用 EC 操作（每个 node ~10ms），比 hash 慢 100×；需要 trusted setup。

详细回答:

  1. MPT 的问题：

    • Patricia (16-ary radix tree) + Merkle (hash 父节点 = hash(子))
    • witness for 1 leaf：路径上每层 15 个 hash sibling
    • n = 5 亿账户：log_16(5e8) ≈ 7 层 × 15 hashes × 32 byte = 3.4 KB / leaf
    • 一个 block 1000 个状态访问 → 3.4 MB witness
    • stateless client 不切实际

  2. Verkle 解法：

    • 用 Verkle Polynomial Commitment（或 IPA）替换 hash
    • 每节点是 vector commitment to 子节点
    • 256-ary 树（不再 16-ary）：log_256(5e8) ≈ 3-4 层
    • 单 leaf proof：每层 1 个 KZG/IPA 开值 ~48 byte × 4 = ~200 byte
    • width × depth 都改善

  3. Trade-off：

    维度MPTVerkle
    Insert/lookuphash 32 byte ~1µsEC 操作 ~10ms
    Witness 大小~5 KB/leaf~200 byte/leaf
    Trusted setup否是（KZG）/ 否 (IPA)
    PQ-safe是否
    工程成熟度高中（仍在 testnet）

  4. 以太坊路线：

    • EIP-6800 提议 Verkle 转换
    • 2024-2025 Verkle testnet
    • 主网迁移：2026-2027 (Pectra 后续)
    • 同时考虑 STARK-based replacement（不需 trusted setup）

  5. 真实意义： stateless client → 移动端 / 浏览器钱包能直接验证，无需 archive node。这是以太坊"轻客户端化"的关键路径。

追问准备:

  • Q: 为什么不直接用 binary Merkle 但 256-ary 来缩小 proof？ → A: 256-ary hash tree witness 还有 255 个 sibling/层；Verkle commitment 把 255 个 sibling 压缩成 1 个 commitment，这是核心。
  • Q: PQ 担忧怎么办？ → A: 后续切到 hash-based (FRI) 替代 EC commitment，但 proof 会大。

三、ZK 理论类（Q13-Q18）

⭐ Q13. 解释完备性 / 可靠性 / 零知识三个性质（含模拟器构造直觉）

类别: ZK 基础 / 安全定义 难度: 资深 考察点: 形式定义、模拟器直觉、知识证明 vs 零知识

简短回答（30秒）: ZK 协议三性质：(1) 完备性 — 诚实 prover 总能让诚实 verifier 接受；(2) 可靠性 — 不诚实 prover 让 verifier 接受的概率 ≤ ε（计算 / 信息论）；(3) 零知识 — 存在多项式时间模拟器 S，无需 witness 就能产生与真实 transcript 计算/统计/完美不可区分的 transcript。模拟器是关键：它是"证明 verifier 没有从交互中学到 witness 信息"的形式工具。模拟器只能在 verifier 接受的分支上做模拟，所以"作弊一次"是允许的（这就是 simulation paradox）。

详细回答（2-3分钟）:

  1. 三性质形式定义（语句 x ∈ L，witness w）：

    Completeness:
  ∀ x ∈ L, w 是 valid witness:
    Pr[<P(w), V>(x) = accept] = 1

Soundness:
  ∀ x ∉ L, ∀ P*:
    Pr[<P*, V>(x) = accept] ≤ ε    (negligible)

Zero-Knowledge:
  ∃ PPT S: ∀ x ∈ L, ∀ V*:
    View_V*<P(w), V*>(x) ≈ S(x)

  2. 模拟器构造直觉：

    • 真实交互：V* 看到 (commit, challenge, response)
    • 模拟器：先采样 challenge，再反向构造 commit
    • 关键：通过"控制 random oracle / rewind verifier"，模拟器可以在不知道 witness 的情况下作弊一次
    • 因为模拟器"控制环境"，verifier 看不出区别

  3. 三种 ZK 强度：

    类型不可区分性应用
    Perfect ZK分布完全相同rare（信息论 ZK）
    Statistical ZK统计距离 negligiblerare
    Computational ZK计算上不可区分主流 SNARK

  4. 可靠性 vs 知识健全性 (PoK)：

    • Soundness：x ∉ L 时不被接受
    • Knowledge soundness：被接受时存在 extractor E 能从 P* 提取 w
    • SNARK 通常要求 PoK（用于身份认证、可信计算）

  5. 真实例子（Schnorr 是 ZK）：

    语句：知道 d 使 P = d · G
Round 1: P → r = k · G  (commit)
Round 2: P ← e (challenge, random)
Round 3: P → s = k + e · d  (response)
Verify: s · G =? r + e · P

模拟器：先采 e, 再采 s, 计算 r = s·G - e·P
  → transcript (r, e, s) 与真实分布相同（因 k 也是 random）
  → 完美零知识

追问准备:

  • Q: 模拟器证明的是 verifier 没学到 witness。但攻击者有可能从协议外部信息攻击吗？ → A: 标准 ZK 定义只覆盖 view inside protocol。"非黑盒模拟"和"UC-secure"是更强的安全定义。
  • Q: rewinding 模拟器有什么问题？ → A: 在并发场景（多个 verifier 同时跑）下 rewinding 不收敛。需要 non-rewinding simulator (e.g., NIZK in CRS model)。
  • Q: 为什么 Fiat-Shamir 把交互式变成非交互式但仍 ZK？ → A: ROM 下 hash 等价于 random oracle，模拟器可以"编程" RO。

⭐ Q14. Groth16 三元组 (A, B, C) 的设计思路？为什么 3 个点足够？

类别: SNARK / Groth16 难度: 资深 考察点: QAP、pairing 等式、为什么这种设计

简短回答（30秒）: Groth16 把电路编码为 QAP (Quadratic Arithmetic Program)：A(x)·B(x) = C(x) + h(x)·t(x)。Proof 是 (A, B, C)，A 在 G1，B 在 G2，C 在 G1。验证等式 e(A, B) = e(α, β) · e(L_input, γ) · e(C, δ)。3 个点足够是因为 QAP 等式三个 polynomial 评估自然映射到三个 commit；A、C 在 G1 而 B 在 G2 是因为 pairing e: G1 × G2 → GT 需要"两边对称"。192 byte proof（3 × 64 byte 压缩）是迄今最小的通用 SNARK。

详细回答（2-3分钟）:

  1. 从电路到 QAP：

    • R1CS: A·s ⊙ B·s = C·s （s 是赋值向量）
    • 通过插值变成多项式：A(x), B(x), C(x) 在 root x_i 处取 R1CS 第 i 行的值
    • 等价于：A(x)·B(x) - C(x) = h(x)·t(x)，t(x) = Π (x - x_i)

  2. Proof 构造：

    Setup (trusted):
  τ, α, β, γ, δ ← random
  CRS = ([τ^i]_1, [τ^i]_2, [α]_1, [β]_2, ...)

Prove (knows witness w):
  A = α + Σ a_i [u_i(τ)]_1 + r·δ        ∈ G1
  B = β + Σ b_i [v_i(τ)]_2 + s·δ        ∈ G2
  C = (Σ_(public) ... ) / γ + ((A·B - α·β - L) / δ) ... ∈ G1

  3. 验证等式（核心）：

    e(A, B) =? e(α, β) · e(L_input, γ) · e(C, δ)
    • LHS：encode A·B
    • RHS 第 1 项：常数 α·β
    • RHS 第 2 项：public input encoded
    • RHS 第 3 项：private witness 部分 + h(x)·t(x)

  4. 为什么 3 个点足够：

    • QAP 三个 polynomial → 三个 commit (A, B, C)
    • α, β, γ, δ 是 setup 的随机化（防止伪造）
    • 配对验证一次性把"乘法关系"变成"加法关系"在 G_T 上验证
    • 数学上：Type 3 pairing 让 A、C 必须在 G1（小，~48 byte），B 在 G2（大，~96 byte）

  5. 为什么 A 在 G1 而 B 在 G2：

    • 效率：G2 上操作慢 ~5×。把多数 commit 放 G1 让 prover 快
    • 安全：A·B 必须涉及两边，否则 pairing 无意义
    • 可压缩：Type 3 不要求 G1 = G2，BLS12-381 G1 48 byte / G2 96 byte

  6. Trade-off：

    • 优：proof 192 byte（最小通用 SNARK），verifier 3 pairing
    • 缺：每电路独立 trusted setup（PlonK 用 universal setup 改进）
    • 缺：只支持 R1CS（不支持自定义门）

追问准备:

  • Q: 为什么 Groth16 不能 universal setup？ → A: A, B, C 中 α, β, γ, δ 是 circuit-specific（涉及 u_i, v_i 多项式插值）。PlonK 通过 permutation argument 抽象出来。
  • Q: trusted setup 怎么 ceremony？ → A: powers-of-tau ceremony。每个参与者贡献一个 random τ_i，最终 τ = Π τ_i。只要一个参与者诚实即安全。
  • Q: 如果 trusted setup 泄漏 τ 会怎样？ → A: 任意人能伪造任何 statement 的 proof（soundness 完全破）。但 ZK 性质不破。

Q15. PlonK 相比 Groth16 的核心创新（universal setup + custom gates）

类别: SNARK / PlonK 难度: 资深 考察点: universal setup、permutation argument、Plonkish

简短回答: PlonK 两大创新：(1) Universal setup — 一次 powers-of-tau 适用于所有电路（≤ 某 size），Groth16 每个电路独立 setup；(2) Custom gates — 支持任意多项式门（不止 R1CS 的 a·b = c），让特定运算（hash、ECC）gate 数减少 5-10×。代价：proof 384-768 byte（vs Groth16 192 byte），verifier 多次 pairing。

详细回答:

  1. Universal setup：

    • PlonK trusted setup 只 commit 到 [τ^i]_1 i = 0..N，与电路无关
    • 任何 circuit (size ≤ N) 都用同一 SRS
    • 一次 ceremony 终身用（如 Aztec ignition ceremony）

  2. Permutation Argument：

    • 关键技术，把 wire 之间的"copy 约束"用 permutation polynomial 表达
    • 不需要 R1CS 的 (A, B, C) 三个 polynomial
    • 替代为：witness polynomial 在不同 row 取相同值，由 grand product check 保证

  3. Custom Gates：

    q_L · a + q_R · b + q_O · c + q_M · a · b + q_C = 0

    selector polynomial (q_*) 决定每行什么类型的 gate。可扩展到：

    • Plookup: 查表门（hash, range）
    • 椭圆曲线门：1 个门替代 ~30 个 R1CS 约束
    • Halo2 列设计：可定义任意 degree 多项式约束

  4. 对比表：

    维度Groth16PlonK
    Trusted setupper-circuituniversal
    Proof size192 byte384-768 byte
    Prover timeO(n log n)O(n log n) ~3×
    Verifier3 pairing5-7 pairing
    Custom gates否是

  5. 真实应用：

    • Aztec, ZkSync Era, Mina, Polygon zkEVM 都基于 PlonK / PlonKish
    • Halo2 是 PSE 维护的 PlonK 变种（IPA 替代 KZG）

追问准备:

  • Q: Plookup 是什么？ → A: PlonK + lookup gates，让"在表中查值"成为单一约束。SHA 类电路 5-10× 更小。
  • Q: PlonK 为什么 prover 慢一些？ → A: 多了 grand product polynomial、permutation polynomial 等多项式，FFT/MSM 开销更大。

Q16. STARK 相比 SNARK 的 3T 优势？什么场景应该选 STARK？

类别: STARK / FRI 难度: 高 考察点: hash-based、PQ、proof size、应用场景

简短回答: STARK 三 T 优势：(1) Transparent 无 trusted setup（用 hash + Reed-Solomon 抽样）；(2) post-quanTum PQ-safe；(3) scalable proving Time 大电路 prover 比 SNARK 渐近更快。代价：proof 大（40-200 KB vs 192 byte），verifier 慢（10-50ms vs 1ms）。适合场景：(a) 大批量计算（StarkNet 状态转移），(b) 不愿做 trusted setup 的项目，(c) 长期 PQ-safe 需求。

详细回答:

  1. STARK 核心：

    • AIR (Algebraic Intermediate Representation)：trace polynomial + constraint polynomial
    • FRI (Fast Reed-Solomon IOP)：通过低度测试 + Merkle 抽样保证 polynomial degree
    • 全程只用 hash function（如 Poseidon），无 EC

  2. 3 T 详解：

    • Transparent：FRI 不需 SRS，所有 randomness 来自 Fiat-Shamir + public coin
    • Post-quanTum：hash function 仍 PQ-safe（Grover 把安全级减半但仍可用）
    • Scalable Time：prover 是 O(n log² n)，常数小；超大电路（n > 2^25）比 SNARK 快

  3. trade-off 矩阵：

    维度Groth16PlonKSTARK
    Setuptrusted, per-circuittrusted, universalnone
    Proof size192 byte384 byte40-200 KB
    Verifier3 pairing (~3ms)5-7 pairing (~5ms)hashes (~10-50ms)
    PQ-safe否否是
    Prover (per gate)慢但稳定中大电路下最快

  4. 应用决策树：

    需要 PQ-safe？      → STARK
on-chain 验证 (gas敏感)？ → SNARK (proof 小)
超大电路 (>2^25 gates)？ → STARK
trusted setup 风险？ → STARK
不在意 setup 但要 short proof? → Groth16
通用 + 短 proof？    → PlonK

  5. 真实案例：

    • StarkNet / StarkEx: STARK，每天处理 100M+ tx
    • Polygon Hermez: SNARK (PlonK)
    • Mina: Pickles（Halo-based recursive）
    • Polygon Miden: STARK (zkVM)

追问准备:

  • Q: STARK 怎么在以太坊上验证？ → A: 直接 verify 太贵（40 KB proof, ms 级 hash），所以 StarkNet 用 SHARP（共享 prover）+ on-chain verifier 摊薄。
  • Q: FRI 抽样的安全级如何调？ → A: 增加 query 次数（~50 query 给 ~100-bit conjecture security）。

Q17. Halo recursion 的 cycle of curves 是什么？为什么需要？

类别: Halo / Recursion 难度: 资深 考察点: recursion 数学、cycle of curves、amortization

简短回答: Recursive SNARK 是"用一个 proof 验证另一个 proof"。Verifier 包含 EC scalar mul，要在电路中嵌入 EC 算术——但电路里的 field 是 EC 的 base field 还是 scalar field？这会无限递归。Cycle of curves 是两条曲线 E1/F_p 和 E2/F_q 满足：E1 的 scalar field = E2 的 base field 反之亦然。两条曲线交替使用让 recursion 闭环。Halo 进一步用 amortization 把"某些 verifier 工作延后到下一个 proof 中"，避免每层都付出 EC 全验证开销。

详细回答:

  1. recursion 的数学难题：

    电路在 F_q 上做约束（q = scalar field of E1）
验证 SNARK 涉及 EC scalar mul on E1
EC mul: P + k·G 涉及 base field F_p 的算术
F_p ≠ F_q → 不能在 F_q-circuit 里直接做

    传统方案：用"non-native arithmetic"模拟，但成本巨大（~1000 约束 / 域元素）。

  2. Cycle of curves：

    E1: y² = x³ + b1, base field F_p, scalar field F_q
E2: y² = x³ + b2, base field F_q, scalar field F_p

关键：E1 的 scalar = E2 的 base 反之亦然

    Pasta curves（Pallas/Vesta）是 ZF 为 Halo2 设计的 cycle。

  3. 使用方式：

    Layer 1 SNARK on E1 (electrons in F_q):
  verifier 涉及 E1 算术 → 电路在 F_q
  ↓
Layer 2 SNARK on E2 (electrons in F_p):
  verify Layer 1 的 EC ops → 电路在 F_p
  ↓
交替迭代，每层用 ~12k 约束完成 verifier

  4. Amortization：

    • 不是每层都做完整 verifier
    • 把"deferred operation"（如 IPA 最终内积）累加到下一层
    • n 次 recursion 后做一次 final check
    • prover 工作 O(n)，每层增量 O(1)

  5. 真实案例：

    • Halo2 / Mina：用 Pallas/Vesta cycle
    • Halo2 → zkSync Boojum：用 BN256 + Grumpkin cycle（不完美但够用）
    • Nova/SuperNova/HyperNova：folding-based recursion，进一步优化

追问准备:

  • Q: 为什么不用同一条曲线 + non-native？ → A: 单层 EC mul ~30 万约束 vs cycle 方案 ~5 千约束。差 60×。
  • Q: Halo 不需要 trusted setup 怎么做到的？ → A: IPA-based polynomial commitment，安全只依赖 DL 假设。

Q18. Sumcheck protocol 如何实现？为什么是 PIOP 的核心？

类别: Sumcheck / PIOP 难度: 资深 考察点: sumcheck round 流程、HyperPlonK 应用

简短回答: Sumcheck protocol 让 prover 让 verifier 相信 Σ_{x ∈ {0,1}^n} g(x) = H，无需 verifier 算所有 2^n 项。流程：每轮 prover 发一个单变量多项式 g_i(X)（关于 i-th 变量积分了之后的值），verifier 检查 g_i(0) + g_i(1) = 上一轮 expected value，再发随机 r_i 替代该变量。n 轮后 verifier 只需评估 g 在一点 r 处。复杂度从 O(2^n) 降到 O(n) verifier work + O(n · 2^n) prover work。Sumcheck 是 HyperPlonK / Spartan / Lasso 等现代 PIOP 的基础——多变量多项式承诺让 PlonKish 的"列"更灵活。

详细回答:

  1. Sumcheck 流程（n 个变量）：

    Goal: prove Σ_{x ∈ {0,1}^n} g(x_1, ..., x_n) = H

Round 1:
  P → V: g_1(X) = Σ_{x_2..x_n ∈ {0,1}} g(X, x_2, ..., x_n)
  V check: g_1(0) + g_1(1) = H
  V → P: r_1 ← random
  New target: H_2 = g_1(r_1)

Round 2:
  P → V: g_2(X) = Σ_{x_3..x_n} g(r_1, X, x_3, ..., x_n)
  V check: g_2(0) + g_2(1) = H_2
  V → P: r_2 ← random

...

Round n:
  P → V: g_n(X)
  V check: g_n(0) + g_n(1) = H_n
  V → P: r_n

Final: V evaluate g(r_1, ..., r_n) (1 oracle query)

  2. soundness：

    • 如果 prover 作弊 → g_1 是错的多项式
    • 用 Schwartz-Zippel: P(error in g_1) = deg(g_1) / |F|
    • 总错误概率 ≤ n · deg / |F|

  3. 为什么是 PIOP 核心：

    • 任意多元多项式求和 → 减到对单点的 oracle query
    • 适合 multivariate polynomial commitment（如 multilinear KZG）
    • 比 univariate (FRI/KZG over standard polynomial) 灵活

  4. 应用：

    • HyperPlonK: PlonK 的 multivariate 版本
    • Spartan: 基于 sumcheck + R1CS 的 SNARK
    • Lasso/Jolt: lookup arguments using sumcheck
    • GKR (Goldwasser-Kalai-Rothblum): layered circuit proof

  5. 真实数据：

    • HyperPlonK prover 比 PlonK 快 ~2×（避免 FFT）
    • sumcheck verifier work O(n)，extremely fast

追问准备:

  • Q: GKR 和 sumcheck 关系？ → A: GKR 用 sumcheck 在每层 circuit 上验证 layer-i 的求和，递归到 input layer。
  • Q: 为什么 multivariate 比 univariate 好？ → A: 不需 FFT（FFT 在 univariate 上是 O(n log n)，多变量 O(n)），且适合 boolean hypercube domain。

四、ZK 工程类（Q19-Q25）

⭐ Q19. 设计一个隐私混币的电路（含 commitment / nullifier / Merkle proof）

类别: ZK 应用 / 系统设计 难度: 资深 考察点: 三大原语、电路设计、防 double-spending

简短回答（30秒）: 隐私混币（Tornado-style）核心三原语：(1) Commitment = Hash(secret, nullifier_hash) 公开存到 Merkle tree；(2) Nullifier = Hash(nullifier_secret) 提现时公开，合约维护 spent set 防 double spend；(3) Merkle proof 证明 commitment 在 tree 中。电路要 prove：知道 (secret, nullifier_secret) 使 commit 在 root 中且 nullifier 公开匹配。隐私来自不公开 secret，链接性破坏来自 commit ↔ nullifier 在 hash 下不可关联。

详细回答（2-3分钟）:

  1. 系统架构：

    Deposit:
  User: secret, nullifier_secret ← random
        commitment = Poseidon(secret, nullifier_secret)
  Contract: insert commitment into Merkle tree (depth 20)
            update root

Withdraw:
  User: nullifier = Poseidon(nullifier_secret)
        Compute Merkle proof for commitment
        Generate ZK proof
  Contract: verify proof
            check nullifier ∉ spent[]
            mark nullifier spent
            transfer to recipient

  2. 电路输入/输出：

    Public inputs:
  - root              (current Merkle root)
  - nullifier         (公开标识)
  - recipient         (防 frontrun)
  - relayer, fee      (gasless 支付)

Private inputs (witness):
  - secret
  - nullifier_secret
  - merkle_path[20]
  - merkle_path_indices[20]

  3. 电路约束（伪 Circom）：

    template Withdraw(LEVELS) {
    // public
    signal input root;
    signal input nullifier;
    signal input recipient;
    signal input relayer;
    signal input fee;
    
    // private
    signal input secret;
    signal input nullifier_secret;
    signal input pathElements[LEVELS];
    signal input pathIndices[LEVELS];
    
    // 1. Compute commitment
    component commHash = Poseidon(2);
    commHash.inputs[0] <== secret;
    commHash.inputs[1] <== nullifier_secret;
    
    // 2. Compute nullifier
    component nullifierHash = Poseidon(1);
    nullifierHash.inputs[0] <== nullifier_secret;
    nullifierHash.out === nullifier;  // public check
    
    // 3. Merkle proof
    component tree = MerkleTreeChecker(LEVELS);
    tree.leaf <== commHash.out;
    tree.root <== root;
    for (var i = 0; i < LEVELS; i++) {
        tree.pathElements[i] <== pathElements[i];
        tree.pathIndices[i] <== pathIndices[i];
    }
    
    // 4. Anti-frontrun: include recipient/relayer/fee in computation
    //    (no constraint, but they are public inputs so changing them invalidates proof)
    signal recipientSquare;
    recipientSquare <== recipient * recipient;
}

  4. 关键设计点：

    • Hash 选 Poseidon：SNARK-friendly (~150 约束/hash) vs Keccak (~24k 约束)
    • Tree depth 20：支持 2^20 ≈ 100 万次存款
    • Anti-frontrun：recipient/fee 作为 public input 但不约束 → 改了 input 就 invalidate proof
    • Domain separation：commitment hash 和 nullifier hash 分开，避免碰撞

  5. 真实案例：

    • Tornado Cash: 上述设计，2019-2022 累计存款 7B+，2022 被 OFAC 制裁
    • Aztec: 类似但支持任意 ERC20，UTXO 模型
    • Privacy Pools v2: 加入"合规证明"，证明 deposit 不来自黑名单
    • Zcash: 类似但用 Sapling circuit，支持 shielded address

  6. 典型攻击 & 防护：

    • Double spend: 用 spent[nullifier] mapping
    • Frontrun: recipient 作为 public input
    • Linking via amount: 固定面值（如 0.1/1/10 ETH 池）
    • Linking via timing: 等 anonymity set 增长再提

  7. 隐私分析：

    • 链上分析仍可能通过 (deposit 时间, withdrawal 时间, IP, gas pattern) 关联
    • anonymity set 是关键 metric：Tornado Cash 100 ETH pool ~10000 deposit
    • Privacy Pools v2 引入"association set" 让用户主动证明合规

追问准备:

  • Q: 为什么需要 commitment 而不是直接 hash(secret)？ → A: nullifier_secret 是用于"提现时不暴露 secret"的独立 randomness。如果 commitment = H(secret) 那 nullifier 也得用 secret 派生 → 互相暴露。
  • Q: relayer 用来做什么？ → A: 用户提现时如果用自己的地址支付 gas → 链上身份暴露。relayer 代付 gas 收 fee。
  • Q: 为什么 Tornado Cash 被制裁？ → A: 朝鲜 Lazarus 等用其洗钱。OFAC 直接制裁合约地址。后续社区分裂为 Privacy Pools v2 等"合规友好"版本。
  • Q: Merkle proof 在 zk 电路里贵不贵？ → A: 20 层 × Poseidon ~150 约束 = ~3k 约束。比 Keccak 版本（24k × 20 = 480k）便宜 100×。

⭐ Q20. zkEVM Type 1-4 的区别？哪种更接近以太坊兼容性？

类别: zkEVM 难度: 资深 考察点: zkEVM 设计哲学、性能 trade-off、生产选择

简短回答（30秒）: Vitalik 2022 提出 zkEVM Type 1-4：(1) Type 1 完全等价以太坊（含 Patricia trie / Keccak / 所有 precompile）—Taiko；(2) Type 2 等价 EVM 但状态树/hash 不同—Scroll；(3) Type 2.5 部分 opcode 修改—Polygon zkEVM；(4) Type 3 多数兼容但缺 precompile—早期 Polygon；(5) Type 4 编译高级语言到 ZK-friendly 字节码—zkSync Era。Type 1 兼容性最高（直接复用以太坊节点），但 prover 慢；Type 4 prover 最快但需要重新编译合约。

详细回答（2-3分钟）:

  1. Vitalik 分类：

    Type兼容性Prover 慢代表
    1完全等价 (re-prove ETH block)最慢 (1000s)Taiko
    2EVM 等价但 trie/hash 改慢 (100s)Scroll
    2.5部分 opcode gas 调中Polygon zkEVM
    3多数 opcode 但缺 precompile较快早期 zkEVM
    4重新编译到 ZK 字节码最快 (10s)zkSync Era, Starknet

  2. 核心设计选择：

    • Type 1: 用 Keccak hash + Patricia trie → 在 ZK 中证 Keccak 极贵（每 hash ~24k 约束）
    • Type 2: 改用 Poseidon trie → ZK-friendly，但 ETH 节点需要"re-state"
    • Type 4: 直接绕过 EVM 字节码，用 LLVM-like 中间表示 + ZK-native 指令

  3. Trade-off 维度：

    维度Type 1Type 2Type 4
    兼容性100%95%70%
    Prover speed慢中快
    Dev tooling 复用100%90%50%
    EVM equivalence test通过大部分通过多数失败

  4. 生产选择：

    • Scroll (Type 2): 押注 EVM 长期等价 + 改进 prover
    • zkSync Era (Type 4): 押注 prover 速度 + 可接受兼容性损失
    • Taiko (Type 1): 押注 EVM 字节码不会再大改
    • Polygon zkEVM (Type 2.5): 中间路线

  5. 关键案例：

    • Scroll: Halo2 + 自研 zkEVM circuit，2023 主网，2024 TVL 200M
    • zkSync Era: LLVM 编译 Solidity 到 EraVM，TVL 500M
    • Taiko: SGX-prover + ZK-prover 双重证明，2024 主网

  6. 未来收敛趋势：

    • 所有 zkEVM 都向"高 prover throughput + EVM 等价"收敛
    • 关键技术：Plonky3, GKR, Lasso 等 prover 加速
    • 2027 年估计 Type 1 prover < 60s/block 可能达到

追问准备:

  • Q: 为什么不所有人用 Type 1？ → A: 当前 prover 太慢，无法实时跟上 mainnet 12s block time。
  • Q: zkSync 不能跑 vyper 怎么办？ → A: 必须用 EraVM 编译器。是 Type 4 的关键限制。
  • Q: Optimistic vs ZK rollup 的"以太坊兼容"差异？ → A: Optimistic 直接跑 EVM（用 fault proof 验证），ZK rollup 必须把 EVM 编进电路。

Q21. under-constrained 是什么？如何在审计中识别？

类别: ZK 审计 / 安全 难度: 资深 考察点: 约束完整性、审计方法、真实漏洞

简短回答: Under-constrained 是电路约束不足以唯一确定 witness，导致 prover 可以选择 fake witness 让 verifier 接受。最常见模式：(1) bit decomposition 没约束 0/1，(2) 范围检查遗漏，(3) selector 没强制互斥。检测方法：fuzz、formal verification (Picus/Ecne)、SMT solver、code review with checklist。Aztec 2022 audit 发现 20+ under-constrained bug。是 ZK 漏洞 #1 类型，占 40%+。

详细回答:

  1. 数学定义：

    • 良好约束系统：witness w 唯一满足 R(x, w) = 0
    • Under-constrained：存在 w_1 ≠ w_2 都满足 R(x, w) = 0
    • 攻击者用 w_2（fake witness）pass verifier

  2. 常见模式与例子：

    模式 1: Bit decomposition 不约束

    // BAD
signal bits[8];
var sum = 0;
for (var i = 0; i < 8; i++) {
    sum += bits[i] * 2**i;
}
sum === in;
// bits[i] 没约束 0/1，可以是任意 field 元素

// GOOD
for (var i = 0; i < 8; i++) {
    bits[i] * (bits[i] - 1) === 0;
}

    模式 2: 范围检查遗漏

    // 假设 fee ≤ amount
amount - fee ==> result;  // 没检查 fee ≤ amount
// 攻击者: fee = amount + 1，result wrap-around

    模式 3: Selector 没互斥

    // selector should be one-hot
signal sel[3];
// BAD: 没约束 Σ sel = 1
// 攻击者: sel = [1, 1, 0] 同时激活两个分支

  3. 审计方法：

    方法工具覆盖
    Manual reviewchecklist高，但漏
    Fuzzechidna-zk中
    SMTZ3, Picus高（小电路）
    FormalEcne, Coda完整但贵
    Differential testingrun vs reference中

  4. Trail of Bits ZK Checklist（2024）：

    • All bit decompositions constrained?
    • All numeric ops range-checked?
    • All selectors mutually exclusive?
    • All Merkle proof leaves binding to commitment?
    • Domain separation in hashes?
    • Field overflow handled?
    • No "free" witness signals?

  5. 真实漏洞：

    • Aztec 2022: bit decomp under-constrained，可伪造任意 deposit amount
    • 0x PARC PlonK 2023: permutation argument 边界 bug
    • zkSync 2024: under-constrained in arithmetic op，赏金 70 万 USD
    • Polygon Hermez 2023: range check 漏 → infinite mint

  6. 资源：

    • Trail of Bits: zk circuit audit handbook
    • Veridise: Picus formal verifier
    • Privacy Scaling Explorations: zk-bug-tracker

追问准备:

  • Q: SMT vs formal 区别？ → A: SMT 是检查具体 instance 是否可满足；formal verification 是证明对所有 input 性质成立。后者更强但更贵。
  • Q: 为什么 ZK bug 比传统智能合约 bug 更难发现？ → A: (a) 数学层抽象，(b) 工具不成熟，(c) 大多数审计师不熟悉 R1CS / PIOP。

Q22. zkML 的 3 种方案（EZKL / Risc Zero / TEE-ML）trade-off

类别: zkML / 应用 难度: 高 考察点: ZK 验证 ML、性能、信任假设

简短回答: zkML 三方案：(1) EZKL 把 ONNX 模型直接编译为 Halo2 电路，proof 端到端但 prover 慢（一次推理 ~10 分钟）；(2) Risc Zero 用 zkVM 跑 ML 推理代码，灵活但 prover 更慢（~小时）；(3) TEE-ML（Phala/Marlin）用 Intel SGX/TDX 在硬件 TEE 内跑模型，秒级但信任硬件厂商。短期 TEE 占主导，长期 ZK 方案优势。

详细回答:

  1. 方案对比：

    方案原理Proving timeTrust
    EZKLONNX → Halo2 circuit5-30 mincrypto
    Risc ZeroRISC-V zkVM 跑 ML 代码30 min - hcrypto
    opMLoptimistic + fraud proof秒级 + 7 天挑战challenger
    TEE-MLIntel SGX 内推理秒级hardware
    MPC-MLsecret sharing 推理分钟级t-of-n

  2. EZKL 详解：

    • 把 PyTorch/TF model export 到 ONNX
    • 量化为定点（INT8 / INT16）
    • 每个 op (matmul, conv, relu) → Halo2 gate
    • 模型 size ~1-100M 参数 currently feasible

  3. 典型用例：

    • 链上验证 oracle ML 预测（如保险理赔）
    • DeFi 风控 score
    • 链上 LLM agent 决策证明
    • DeFAI 信号验证

  4. 限制（2027 现状）：

    • 大模型（>1B 参数）EZKL 不可行
    • 浮点精度损失大
    • prover hardware 要求高（GPU/FPGA）

  5. 真实进展：

    • EZKL: 2024 推出，Modulus Labs 用作链上 ML
    • Risc Zero zkML: 2025 BobaPay 信用 score
    • Phala TEE: 2025 链上 GPT4 推理
    • opML (ORA): 2024 主网

追问准备:

  • Q: zkML 比 trusted oracle 优势？ → A: Trustless：oracle 可能作恶，zkML 数学保证。
  • Q: 为什么大模型 ZK 还做不了？ → A: prover 时间随参数 quasi-linear，70B LLM 约束数 ~10^12，prover 时间天级。

Q23. Aztec 网络架构相比 zkSync 的差异（隐私 L2 vs 公开 L2）

类别: 隐私 L2 / 架构 难度: 高 考察点: 隐私 vs 公开模型、UTXO vs 账户、性能

简短回答: zkSync 是透明 ZK Rollup：所有交易公开，ZK 仅用于 proof of correctness。Aztec 是隐私 ZK Rollup：交易 amount/recipient 加密（基于 UTXO + commitment + nullifier），ZK 同时保证正确性和隐私。Aztec 用 PXE (Private Execution Environment) 在客户端生成 proof，仅公开 nullifier。代价：UTXO 模型限制可组合性，前端开发复杂 5×。

详细回答:

  1. 架构对比：

    zkSync Era:
  User TX (plaintext) → Sequencer → Prover → ETH L1 (state diff)
  所有 amount/sender/recipient 公开

Aztec:
  User → PXE (local proof) → Sequencer (only sees commitments/nullifiers)
     → Prover (recursive aggregate) → ETH L1 (commitment tree root)
  amount/recipient 加密

  2. 关键差异：

    维度zkSyncAztec
    模型账户 (account)UTXO + 账户
    隐私无是（amount, recipient, ...）
    可组合性强中（需 cross-contract Aztec note）
    Prover中心化 sequencer客户端 + sequencer
    TPS高（千级）中（百级，受 client prover 限制）

  3. Aztec UTXO + Note 模型：

    • 资产是 "note" = (amount, owner_pubkey, secret)
    • 转账：销毁旧 note + 创建新 note + nullifier
    • 与 Solidity 模型不兼容，需新语言 (Noir)

  4. 挑战：

    • 用户体验：每次转账需要客户端 ZK 证明（10 秒）
    • 钱包要保存 note shielded 状态
    • 可组合性受限：跨合约调用必须传 nullifier/commitment

  5. 真实案例：

    • Aztec Connect (v2, 2022-2023): 链上 shielded ETH/DAI
    • Aztec v3 (2025): 完整隐私 L2 + Noir 编程语言
    • zkSync Era: 完全透明，TVL 500M+

追问准备:

  • Q: 为什么不用 Aztec 模型？这看起来更安全。 → A: 可组合性是 DeFi 命脉。Uniswap 的 amount 隐私化后 LP 怎么算？许多 DeFi primitive 在隐私下重设计很难。

Q24. ZK 桥的安全模型相比 Optimistic Bridge 优势

类别: 跨链桥 / 安全模型 难度: 高 考察点: 信任假设、延迟、成本

简短回答: Optimistic bridge（如 Across, Connext）依赖 7 天挑战期 + 1-of-N 守护者；ZK bridge（Polyhedra, Succinct, =nil）用 ZK 证明源链状态/事件 → 信任源于数学，无挑战期。优势：(1) 即时 finality（无 7 天等待），(2) 1-of-N 信任假设替换为 0-trust（仅信加密假设）。代价：每次状态证明 prover cost $0.5-5，证明 light client header 所需 ZK 证明仍贵。

详细回答:

  1. 三类桥对比：

    类型信任假设延迟成本
    Multisig (Wormhole, Multichain)t-of-n committee分钟$0.1-1
    Optimistic (Across, Hop)1-of-N watcher7 天$0.5-2
    ZK (Polyhedra, =nil, Succinct)加密假设即时-1h$0.5-5

  2. ZK Bridge 工作原理：

    • Light client：prove 源链 block header valid
    • Storage proof：prove "source chain state has X = Y"
    • 状态证明聚合到 ZK proof
    • 目标链 verify proof → 释放对应资产

  3. 真实案例：

    • Polyhedra zkBridge: 跨 BSC/ETH/Arbitrum 等
    • Succinct SP1: prove ETH consensus
    • =nil; Foundation: ZK proof aggregation
    • Lagrange: state query bridge

  4. 优势量化：

    • 7 天 vs 1 小时 finality → DeFi 流动性效率 168×
    • 1-of-N 假设 vs 0-trust：消除"committee compromise"风险
    • 历史桥被黑：Wormhole 320M, Ronin 600M, Nomad 190M（都是非 ZK）

  5. 挑战：

    • 每次 light client 证明 cost
    • 源链 consensus 改变（ETH PoS upgrade）需要电路升级
    • Cross-chain message ordering 仍复杂

追问准备:

  • Q: ZK bridge 真的 trustless 吗？ → A: 不完全。仍信 (a) trusted setup 安全，(b) 源链 consensus 不被攻击。但比 multisig 更安全。

Q25. 选 Circom 还是 Noir 还是 Halo2？项目场景如何决策？

类别: ZK DSL / 选型 难度: 高 考察点: ZK DSL 生态、性能、学习曲线

简短回答: Circom 生态最成熟（Tornado/Worldcoin 都用），DSL 简单但抽象低；Noir 是 Aztec 出品的 Rust-like ZK 语言，类型系统好、自动微分约束，但仍较新；Halo2 是底层 Rust 库，性能最强但学习曲线陡。决策：MVP/教育选 Circom，应用层（隐私 DApp）选 Noir，性能极致/zkEVM 选 Halo2。

详细回答:

  1. 三 DSL 对比：

    维度CircomNoirHalo2
    抽象层级中（template）高（Rust-like）低（库 API）
    学习曲线1 周1-2 周1-2 月
    BackendGroth16, PlonKUltraPlonk (PlonKish)PlonKish
    工具链snarkjs (mature)Aztec stackRust ecosystem
    性能中中-高最高
    生态大（5+ years）中（2 years）中

  2. 代码风格示例：

    Circom:

    template Multiplier() {
    signal input a; signal input b;
    signal output c;
    c <== a * b;
}

    Noir:

    fn main(a: Field, b: Field) -> pub Field {
    a * b
}

    Halo2:

    // ~50 行配置 + Custom column / region

  3. 决策树：

    教学/Demo？        → Circom
隐私 DApp 业务？   → Noir
zkEVM/zkRollup？   → Halo2
需 PQ-safe？       → Plonky3 / RISC0 (RISC-V zkVM)
极致 prover 性能？ → Halo2 / Plonky3

  4. 真实选择：

    • Worldcoin: Circom (Semaphore protocol)
    • Tornado Cash: Circom
    • Aztec / Privacy Pools v2: Noir
    • Scroll / zkSync: Halo2 (forked)
    • Polygon Miden: 自研 Miden Assembly

  5. 趋势：

    • Circom 仍主流但 Noir 增长快
    • 长期看 Noir 类型系统优势大

追问准备:

  • Q: 为什么不用 Solidity-like ZK 语言？ → A: ZK 约束语义和 EVM 完全不同（无控制流、无 storage）。Circom/Noir 必须 ZK-native。

五、隐私技术类（Q26-Q30）

⭐ Q26. FHE / MPC / TEE / ZK 的 trade-off（信任假设/性能/可表达性）

类别: 隐私技术对比 / 选型 难度: 资深 考察点: 4 大隐私范式、维度对比、场景选型

简短回答（30秒）: 四技术不在同一维度。ZK 是单方计算 + 多方验证（隐藏证人，信任数学）；MPC 多方协作计算共同函数（信任 t-of-n）；FHE 单方在密文上代客户端算（信任数学，但慢 100-10000×）；TEE 硬件安全飞地（信任 Intel/AMD + chip 不被破）。性能 TEE > MPC > ZK > FHE。可表达性 FHE/TEE 最强（任意程序），ZK 仅对 NP 关系，MPC 需协议设计。

详细回答（2-3分钟）:

  1. 核心对比表：

    维度ZKMPCFHETEE
    信任假设数学（DLP/lattice）t-of-n 诚实数学（lattice/RLWE）硬件 + manufacturer
    数据处于单方有 plaintextshared secret加密（ciphertext）加密（enclave 内 plaintext）
    性能 vs plain1-10× (proof + verify)10-100×1000-10000×1-2×
    可表达性NP 关系任意（需协议）任意（理论）任意
    PQ-safe多数否（ZK SNARK）部分是（多数）N/A (not crypto)
    工程成熟度高 (zkSync 上线)高（threshold sig）低（实验性）高（部署广泛）

  2. 每种技术的"独到之处"：

    • ZK: 适合"我能证我的算法对，但不告诉你输入"。隐私混币、ZK rollup、身份证明。
    • MPC: 适合"多方一起算结果但不分享各自数据"。阈值签名、隐私拍卖、联邦统计。
    • FHE: 适合"我把加密数据交给你算，结果还在加密态"。云上隐私 ML、医疗数据计算。
    • TEE: 适合"我信硬件厂商，但不信云供应商"。机密计算、TEE-bridge、TEE-MEV protect。

  3. 场景选型决策树：

    只信数学，不信硬件 + 算法是 NP 关系？  → ZK
多方协作 + 信任 t-of-n 一方诚实？      → MPC
不信对方但要他帮算（加密计算）？        → FHE
信硬件 + 极致性能 + 任意程序？          → TEE

  4. 混合方案趋势：

    • TEE + ZK: TEE 内跑 + ZK 证 TEE 输出（Phala + Risc Zero）
    • MPC + ZK: MPC 各方对自己份额生成 ZK 证明（zkMPC）
    • FHE + ZK: FHE 计算 + ZK 证 ciphertext 计算正确（Zama）

  5. 真实生产 status (2027)：

    • ZK: zkSync/StarkNet 主网，TVL 数十亿
    • MPC: Coinbase Prime, Fireblocks, Curv 全部用阈值签名
    • FHE: Zama TFHE 实验性，单次 op ~10ms（vs plain ~ns）
    • TEE: AWS Nitro, Phala, Marlin，主流云供应商

  6. 未来 5 年判断：

    • ZK 应用扩张到 ML / DePIN
    • MPC 主流化（钱包默认）
    • FHE 算法/硬件突破后 5-10 年生产化
    • TEE 短期主导，长期被 ZK + FHE 替代

追问准备:

  • Q: 为什么 FHE 仍未生产化？ → A: bootstrapping 操作 ms 级（vs nanoseconds plaintext），10000× slowdown。最新 CGGI bootstrap ~5ms 仍贵。
  • Q: TEE 攻击面有什么？ → A: SGX 过去多次侧信道（Foreshadow, ÆPIC, Downfall）。AWS Nitro 攻击面更小但仍有。
  • Q: ZK + FHE 怎么结合？ → A: FHE 算密文 + ZK 证 FHE 计算正确 → 双重保护。但当前性能不可行。

Q27. Privacy Pools v2 如何在合规与隐私之间平衡？

类别: 隐私 + 合规 难度: 高 考察点: 合规设计、association set、Tornado 教训

简短回答: Tornado Cash 被制裁后，Buterin 等 2023 提出 Privacy Pools v2：用户提现时主动证明 deposit 来自 "association set"（合规白名单）而非黑名单。机制：(a) 链下 prover 维护 deposit 白名单 Merkle tree，(b) 用户 zk 证明 deposit ∈ 白名单 但不暴露具体哪个。这让"诚实用户保留隐私 + 黑名单资金无法提现"两不误。是合规友好型隐私的代表设计。

详细回答:

  1. 背景：

    • Tornado Cash 2022-08 被 OFAC 制裁
    • 合约被 ban，开发者 Roman Storm 被起诉
    • 但隐私需求合法存在 → 必须设计"合规友好"方案

  2. Privacy Pools v2 设计（Buterin et al. 2023）：

    Standard pool: 任何人可加入 (Tornado-style)

Association set:
  - 多个第三方 prover 维护"合规 deposit 集合"
  - 用户提现时选择 association set X
  - ZK 证明: 我的 deposit ∈ X AND deposit ∈ pool
  - X 不含已知黑钱地址（OFAC list, hack proceeds）

  3. 关键性质：

    • 隐私保留：仍不暴露具体 deposit
    • 合规可证：Association set 公开可审计
    • 用户主动选择：可选不同合规等级
    • 市场化 prover：多个 association set provider 竞争

  4. 电路修改（vs Tornado）：

    • 原电路：prove deposit ∈ pool Merkle tree
    • 新电路：prove deposit ∈ pool ∩ association_set
    • 增加 ~3k 约束（一个额外 Merkle proof）

  5. 挑战：

    • association set 维护方（prover）如何监管？
    • 跨司法辖区 compliance 不一致
    • "黑名单"边界（如和平抗议账户被列入？）

  6. 真实部署：

    • 0xbow.io: 2024 主网部署 Privacy Pools v2
    • Aztec v3: 类似机制但更深度集成

追问准备:

  • Q: 为什么不直接 KYC？ → A: KYC 暴露身份 → 链上行为 deanonymized。Privacy Pools 平衡：身份/账户隐私保留，仅证不来自黑名单。
  • Q: association set 被 hack 怎么办？ → A: 用户可切换其他 prover；多 prover 提供冗余。

Q28. TEE 的 SGX 等芯片的攻击面？AWS Nitro Enclave 有何不同？

类别: TEE / 安全 难度: 高 考察点: SGX 历史漏洞、Nitro 设计、信任根

简短回答: Intel SGX 攻击面：(1) 侧信道（Foreshadow / SGAxe / ÆPIC / Downfall），多次完全破坏；(2) 物理攻击（power analysis）；(3) Intel 主密钥单点信任。AWS Nitro 不同：基于 KVM hypervisor + ARM 物理隔离，无 EPC cache 侧信道；attestation 由 AWS root of trust + Nitro Card 协同；攻击面比 SGX 小 ~10×，但信任 AWS 而非 Intel。

详细回答:

  1. Intel SGX 攻击史：

    年份漏洞影响
    2018Foreshadow (L1TF)完全破，需微码修复
    2019LVI部分破
    2019Plundervolt电压 fault 注入
    2020SGAxe / CrossTalk完全破 attestation
    2022ÆPIC Leak内存读
    2023Downfall (Gather)跨 enclave 读

  2. SGX vs Nitro 对比：

    维度Intel SGXAWS Nitro
    信任根Intel 主密钥AWS HSM + Nitro Card
    隔离方式EPC + memory encryptionhypervisor + 物理
    AttestationDCAP / EPIDNSM Vsock
    侧信道历史多次重大较少
    性能 vs plain5-20% overhead<2% overhead
    部署bare metal / few cloudsAWS only

  3. AWS Nitro Enclave 设计：

    • VM-level 隔离（KVM-based）
    • 无网络 / 无持久存储 / 无键盘
    • vsock 通信
    • Attestation via NSM (Nitro Security Module)

  4. 生产 TEE 系统：

    • Phala Network: SGX-based confidential smart contracts
    • Marlin: AWS Nitro + Intel SGX 多 TEE 联邦
    • Oasis: SGX-based Sapphire ParaTime

  5. 缓解措施：

    • 微码补丁（性能损失 5-20%）
    • 限制 attestation 范围
    • 多 TEE 联邦（如 Marlin 用多家硬件冗余）
    • TEE + ZK 混合（用 ZK 证 TEE 输出）

追问准备:

  • Q: SGX 还能信吗？ → A: 适合"非高价值"场景。高价值（金融）应混合 ZK / 多 TEE。
  • Q: Nitro 信任 AWS 不是问题吗？ → A: 是。但 AWS 经济上无 incentive 攻破自己的产品（vs Intel 可能被国家强制）。trust model 不同。

Q29. 为什么 2026-2027 年 FHE 仍未生产化？瓶颈在哪？

类别: FHE / 性能 难度: 高 考察点: bootstrap、ciphertext 大小、应用瓶颈

简短回答: FHE 三大瓶颈：(1) bootstrapping：每次密文运算后 noise 累积，必须刷新 ciphertext，单次 ~5-50ms vs plaintext ns，慢 10000×；(2) ciphertext expansion：密文比明文大 100-1000×，1KB 数据 → 1MB 密文；(3) 可编程性弱：FHE 操作集仅 ADD/MUL（depth 受限），需要 compiler 把任意程序映射到 FHE-friendly。当前 Zama TFHE 在专用任务（隐私推理）上可用，但通用计算仍 1000-10000× 慢。

详细回答:

  1. FHE 三种 generation：

    代代表bootstrap速度
    1 (Gentry'09)概念证明30 分钟不可用
    2 (BGV/BFV)SEAL, OpenFHE秒级实验性
    3 (CKKS)float-friendly秒级ML 用
    4 (TFHE/CGGI)比特级，bootstrap 5ms5ms微批可用

  2. 核心瓶颈：

    bootstrap：

    ciphertext c₁ + c₂ → noise(c) ↑
noise > threshold → 解密失败
bootstrap: 加密重置 noise → 5-50ms
每个 op 后必须 bootstrap → 10000× slowdown

    ciphertext expansion：

    plaintext bit → CKKS 32 KB ciphertext
1 KB plain → 1 MB cipher
网络带宽 / 存储 / GPU 内存压力

    operations：

    • 只有加法、乘法（深度受限）
    • 比较 / 排序 / 分支：必须用多项式拟合
    • 任意程序 → bootstrapping 树

  3. 现状：

    • Zama Concrete: 专用任务可达 ~10× plain
    • 隐私 ML 推理：可行 (~分钟级)
    • 通用计算：仍 1000-10000× slow

  4. 加速路线：

    • 硬件：Intel HEXL, NVIDIA Hopper FHE primitives
    • 算法：CGGI bootstrap 优化
    • 混合：FHE + MPC + TEE + ZK

  5. 预测：

    • 2030 前后达到 100× slowdown
    • 实用化首先在医疗 / 联邦学习 / DeFi 隐私

追问准备:

  • Q: FHE 能做 LLM inference 吗？ → A: 理论上可，但 70B 模型 FHE 推理估计 ~天级。当前仅小模型 (BERT-tiny ~分钟)。

Q30. 设计一个合规友好的隐私 L1，关键决策点？

类别: 系统设计 / 隐私 L1 难度: 资深 考察点: 隐私 L1 全栈、合规集成、决策框架

简短回答（30秒）: 关键决策：(1) 隐私范围 — 仅交易隐私 (Aztec) vs 全 state 隐私 (Aleo) vs 智能合约可选隐私；(2) 合规机制 — Privacy Pools v2 association set / 强制 KYC / 选择性披露 (selective disclosure)；(3) 共识 — 是否对验证者要求 attestation；(4) 桥接 — 如何与公开链交互（Aztec 用 shielded ETH）；(5) DSL — Solidity-like (Aztec Noir) vs 全新 (Aleo Leo)。需要在隐私强度 / 监管接受度 / 开发生态 / 性能上做四维权衡。

详细回答:

  1. 5 大决策维度：

    维度选项trade-off
    隐私范围TX-only / state / 可选强度 vs 复杂度
    合规机制Pools / KYC / 选择性披露隐私 vs 监管
    共识层PoS / TEE-attested PoS性能 vs 信任
    DSLSolidity-like / ZK-native开发者 vs 性能
    桥接bridge / 内嵌跨链可组合性

  2. 架构 blueprint：

    ┌─────────────────────────────────────┐
│  应用层: 隐私 DEX / 隐私借贷 / RWA   │
├─────────────────────────────────────┤
│  DSL: Noir / Leo                     │
├─────────────────────────────────────┤
│  执行层: PXE (client-side prover)   │
├─────────────────────────────────────┤
│  排序层: Sequencer + ZK aggregator  │
├─────────────────────────────────────┤
│  共识: PoS validator                │
├─────────────────────────────────────┤
│  数据层: 加密 commitment tree        │
├─────────────────────────────────────┤
│  合规层: Association set + viewer key│
└─────────────────────────────────────┘

  3. 关键设计原则：

    • 隐私 by default：不要让用户选 "private mode"
    • 合规 opt-in：用户主动证 deposit 来自合规集
    • selective disclosure：用户给税务局 viewer key（不给世界）
    • 可组合性：跨合约调用必须 design 进 protocol

  4. 真实参照：

    • Aztec: TX-only privacy, Noir, association set
    • Aleo: state privacy, Leo, no built-in 合规
    • Iron Fish: BTC-style shielded UTXO
    • Penumbra (Cosmos): shielded multi-asset DEX

  5. 合规挑战：

    • FATF Travel Rule（>1000 USD 转账识别 sender/receiver）
    • 各国矛盾（US vs EU vs 亚洲）
    • 监管不确定性（Tornado 案例）

  6. 个人观点： 未来 5 年成功的隐私 L1 必须解决合规 question。Aztec v3 + Privacy Pools v2 模式（隐私 by default + association set）是最可行路径。Aleo 模式（无内置合规）可能在长期遇阻。

追问准备:

  • Q: 选 ZK SNARK 还是 STARK 做底层？ → A: 应用层（client-side prover）选 SNARK（proof 小，client 易做）；rollup 聚合层可选 STARK（PQ-safe + scalable）。
  • Q: 隐私 L1 vs 公开 L1 + 隐私 L2 优劣？ → A: 隐私 L1 隐私强度高（默认）但生态小；公开 L1 + 隐私 L2 可组合性强但需 bridge 隐私。当前主流是后者。
  • Q: 监管会 ban 隐私 L1 吗？ → A: 欧洲 MiCA / FATF 倾向限制。但 Privacy Pools 模式让监管"识别异常"而非"看所有数据"，是可接受妥协。

总结与使用指南

一、6 道核心题 ⭐

完成 30 道后，重点反复操练这 6 道：

Q主题核心难点
Q1EC 点加法几何 + 代数 + special case 三层
Q8ECDSA nonce 重用数学推导 + Sony 案例细节
Q13完备/可靠/零知识模拟器构造直觉
Q14Groth16 三元组为什么是 3 个 + G1/G2 选择
Q19隐私混币电路commit/nullifier/Merkle 组装
Q20zkEVM Type 1-4兼容性 vs prover 性能 trade
Q26FHE/MPC/TEE/ZK四维度对比框架

二、白板必复现公式

  • Schnorr 签名 verify equation
  • ECDSA k-reuse 解 d 公式
  • Groth16 verify pairing equation
  • KZG open verify pairing equation
  • BLS aggregate signature equation

三、Phase 1-4 题集对比

Phase题数核心域难度峰值
Phase 130机构 DeFi/RWA资深
Phase 230量化/微观结构资深
Phase 330AI 系统工程资深
Phase 430密码学/ZK/FHE最高

总 120 道资深题，覆盖求职面试 80%+ 高频问题。

四、链接

  • Phase 1 题集: EXPERT-DAY60-INTERVIEW.md
  • Phase 2 题集: EXPERT-DAY120-INTERVIEW.md
  • Phase 3 题集: EXPERT-DAY180-INTERVIEW.md
  • 270 天总结: EXPERT-DAY270.md
上一篇
Day 270: 270 天总结 — 从金融老兵到 4 方向资深的完整复盘