跳转到内容
Jason's Study

PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge

是什么

PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge 提出：PLONK：通用 SRS 的置换论证 SNARK。

日常类比：像一次可信仪式后，很多电路共用同一把证明钥匙。

读论文时先抓「威胁模型/假设→核心构造→复杂度/开销」三件事。

为什么重要

  • zkSync/Polygon 主流
  • 理解 permutation argument
  • 对照 ben-sasson-stark-2018 无 SRS
  • ZK Rollup 基础

核心要点

  1. 问题设定：作者要解决什么不可能三角（安全/性能/易用）。
  2. 关键技巧：一个构造或定理把难题拆成可实现步骤。
  3. 安全假设：信任根、敌手能力、失败概率。
  4. 工程映射：开源库与 RFC 如何落地论文思想。
  5. 局限：已知攻击面、参数选取、未来工作。

核心算法细节

置换论证（Permutation Argument）

PLONK 的核心是用多项式编码电路线值的”拷贝约束”：同一信号出现在不同门的不同位置时，需证明这些值相等。PLONK 将此转化为置换检查：

  1. 构造置换 σ，将线连接关系编码为对 domain H = {ω^0, …, ω^{n-1}} 的置换。
  2. 用”grand product argument”：证明 ∏(f_i / g_σ(i)) = 1，等价于多项式 Z(X) 满足 Z(ωX) · (f(X) + β·id(X) + γ) = Z(X) · (f(X) + β·σ(X) + γ)。
  3. 将此约束折叠进单一多项式等式，用 KZG 承诺一次性验证。

门约束多项式

PLONK 使用算术化门约束 q_L · a + q_R · b + q_O · c + q_M · a·b + q_C = 0，其中 a, b, c 为左、右、输出线值，q 系数向量由电路编译器确定。相比 R1CS 每行只有一次乘法，PLONK 允许更丰富的门（UltraPLONK 引入自定义门和查找表 plookup）。

KZG 多项式承诺

PLONK 依赖 Kate-Zaverucha-Goldberg（KZG）承诺：

  • Commit: com(f) = f(τ)·G₁（τ 为 SRS 中隐藏的有毒废料）
  • Open: 证明者提供商 π = (f(x) - f(z))/(X - z) 的承诺
  • Verify: 用配对检查 e(com(f) - f(z)·G₁, G₂) = e(π, (τ-z)·G₂)

单次验证只需 2 次配对（约 3 ms），证明大小 ~400 字节，远小于 Groth16 的 200 字节但通用性远强于它。

通用可更新 SRS

PLONK 只需一次 SRS 生成仪式，所有不同大小的电路都可以复用，无需电路特定的 trusted setup。SRS 可以安全地增量更新（updatable）：任意新参与者加入后，只需其中一人诚实，SRS 就仍是安全的。

zkEVM 中的 PLONK 变体

变体特性代表项目
TurboPLONK自定义门，支持高效哈希Aztec
UltraPLONKplookup 查找表Aztec Connect
Halo2递归无 trusted setupZcash, Scroll
BoojumGPU 友好，支持 zkEVMzkSync Era

工程实现要点

  • 域选取：BN254 曲线的标量域大小 ~254 位，既支持 KZG 配对又满足 NTT 友好（对 2^28 次根存在）。
  • FFT 瓶颈：证明生成 80% 时间在 FFT/iFFT，建议用 GPU 加速（cuFFT 或 Icicle 库）。
  • plookup 优化：将范围检查、位运算、SHA256 等非算术操作转化为表查找，可将门数降低 10-100×。
  • 递归证明：Halo2 去掉配对改用 inner product argument，可在 enclave 或合约内验证递归证明。

实践案例

案例 1：画威胁模型表

列：资产、敌手、能力、目标；对照论文假设勾选覆盖项。

案例 2：找开源实现

Terminal window
# 搜索论文标题 + library 名称，读 README 的 security note

案例 3：与邻居论文对照

阅读 ben-sasson-stark-2018，画时间线：哪篇解决 setup/性能/证明长度。

案例 4：面试复述

用「类比 + 三要点」在 2 分钟内讲清；准备一条「为什么不用更简单方案」。

案例 5：与双千 atlas 交叉阅读

在 papers-atlas 找同子类 1 篇，对比实践案例是否覆盖实验/参数/失败模式。

踩过的坑

  1. 把理想模型当产品默认：论文参数在工业界常被放宽。
  2. 忽略组合开销：多个原语组合时安全界不是简单相加。
  3. 误读实验规模：小数据集上的 ε 不可直接外推。
  4. 混淆相似缩写：如 DP/LDP、SNARK/STARK 场景不同。
  5. 行数与模板：交付前用 quality-gate 扫一遍。

适用 vs 不适用场景

适用：

  • 安全/系统/architecture 面试深挖
  • 选型隐私或密码组件前的理论扫盲
  • 读源码前的概念地图

不适用：

  • 不做威胁建模直接上生产
  • 替代官方标准文本（FIPS/RFC）
  • 数学证明细节（请读原文附录）

历史小故事（可跳过）

  • 论文常是多年社区实践的第一次形式化。
  • 标准机构（NIST/IETF）往往在论文后收敛算法名。
  • 开源实现与论文版本存在参数漂移，以 release 为准。
  • 近年与 ML、TEE、区块链场景强交叉。

学到什么

  • 安全方案先问威胁模型，再问漂亮数学。
  • 工程落地看常量与实现漏洞，不只看渐近复杂度。
  • 论文链式阅读比单篇精读更高效。
  • 与站内 neighbors 互链能形成可复习的知识图。

延伸阅读

关联

维护备注

  • 引用格式保持单引号包裹 来源 字段。

反向链接