fractalyze/zorch

# zorch 面向现代 SNARK 的 FRX 原生构建块。 `zorch` 位于 **FRX** —— Fractalyze 的 [JAX](https://github.com/jax-ml/jax) 分支 —— 与使用它的证明系统之间：FRX 提供追踪和代码生成，通过 **Fractalyze XLA**（它对原版 [XLA](https://github.com/openxla/xla) 进行了分叉并添加了原生域和椭圆曲线类型）进行降级。 `zorch` 提供了用于组装证明系统的可复用组件。 现代 SNARK 是 **IOP + PCS**。就像深度学习堆叠 `Layer` 一样，`zorch` 堆叠了 **`Round`** —— 这是其余所有内容所贯穿的可组合单元。 ## 设计哲学 - **证明方案无关。** 这些构建块涵盖了*所有*证明方案，而不仅仅是其中一种。 `Round` / Fiat-Shamir / `Polynomial` / `PCS` / fold / zero-check 可组合成 FRI、sumcheck、GKR、STARK、Basefold、WHIR 等；基于配对的方案只需通过替换 `PCS` 模块即可插入（例如 KZG 风格的承诺）。 - **实现无关。** `zorch` 针对的是证明方案，而不是任何特定的下游实现 —— 如 zkVM、zkML 证明器、zkTLS 证明器。每一个都作为*消费者*插入；没有任何特定于实现的细节泄露到构建块中。 - **融合优先。** 每个 `Round` —— 以及每个 `commit`/`open`、每个 `absorb`/`squeeze`、每个 fold 步骤，甚至是哈希排列的内部轮次 —— 都必须降级为**单一融合 kernel**。我们通过*构造*而非编译器中基于每个原语的模式匹配器来实现这一点。 - **易于组装。** 这些都是构建块；API 的设计旨在让它们能像拼积木一样轻松拼接在一起。 ## 构建块 **唯一的单元是 `Round` —— 也就是 IOP 中证明者与验证者之间的一次交互**：一条被记录到 Fiat-Shamir 副本中的消息，随后采样得到的一个挑战（通过 `__call__` 实现 `observe`→`sample`）。`Round` 是可以**嵌套**的 —— 一个针对单个变量的步骤就是一个 `Round`，而一整个 sumcheck（将其针对各个变量的 `Round` 打包）本身也是一个 `Round`。这正是 **`SNARK = Σ IOP Round`** 的字面含义：经过 Fiat-Shamir 编译的 IOP 是由这些轮次构成的一棵树，`Σ` 将其展平至叶子节点级别的交互。 将 `Round` 进行分组，要么会得到一个更大的 `Round`（例如由其各变量轮次构成的 sumcheck），要么 —— 当该分组作为顶层阶段时 —— 会得到一个 `Stage`。两种角色组织了这种组合；它们本身都是 `Round`，因为一条链本身也是一个 `Round`： - **`Stage`** 是一个 `Round`，它是方案的 `prove_chain` 中的一个阶段 —— 即方案*所包含*的 Stages 序列（trace-commit、logup-gkr、zero-check、PCS opening）。 - **`Bridge`** 是一个仅涉及副本操作的 `Round`，用于满足可靠性或安全性的要求 —— 例如 grind（获取安全比特）、带框架的 observe 或域分隔符（弥补 Fiat-Shamir 的可靠性漏洞）、采样后丢弃的挑战（与参考方案的时间表保持一致）。它通常位于某个 Stage *内部*；方案也可以直接在 `prove_chain` 的两个 Stage 之间放置一个 Bridge（例如将它们的声明进行 RLC 批处理）。 因此其结构是递归的 —— `prove_chain` 由多个 `Stage` 组成（偶尔在它们之间穿插 `Bridge`）；一个 `Stage` 串联起多个 `Round` 和 `Bridge`；而一个 `Round` 本身也可能串联起多个 `Round`，直至叶子节点级别的交互： ``` prove() — the prove_chain is Stages; a Stage holds Rounds and Bridges ────────────────────────────────────────────────────────────────────── Stage trace-commit commit the witness columns Stage logup-gkr the interaction argument: Bridge grind a PoW inside the stage (buys security bits) Round layer L one layer — itself a Round of Rounds: Round bind x₀ a leaf: one observe → sample Round bind x₁ Round layer L-1 Stage zero-check the constraint sumcheck: Bridge observe(framing) bind the transcript first (soundness) Round bind x₀ a leaf: one observe → sample Round bind x₁ Stage jagged-evals the PCS opening ``` | | **`Round`** | **`Stage`** | **`Bridge`** | | ----------- | ------------------------------------- | ------------------------------------------------------ | --------------------------------------------- | | **是什么** | 证明者↔验证者交互；支持嵌套 | 构成 `prove_chain` 某个阶段的 `Round` 序列 | 仅涉及副本操作的连接性 `Round` | | **做什么** | 在叶子节点进行 `observe`→`sample` | witness + 真实计算（内部 sumcheck、open 操作） | 可靠性/安全性所需的副本操作 | | **示例** | sumcheck 的单轮，或一整个 sumcheck | trace-commit, logup-gkr, zero-check, jagged-evals | grind、带框架的 observe、被丢弃的采样 | `Stage` 和 `Bridge` 共享相同的 `Round` 接口 —— 这正是链能够嵌套的方式，也是验证者能够*逐轮*镜像证明者的方式 —— 但读者是通过它们扮演的角色来进行区分和导航的。 **边界在哪里划分。** 一个叶子 `Round` 就是每一次证明者与验证者的交互（`observe`→`sample`）；多个 Rounds 打包成一个更大的 `Round`，或者在 `prove_chain` 的某个阶段打包成一个 `Stage`；而 `Bridge` 则被放置在参考方案的可靠性论证需要执行副本操作的任何地方 —— 可以是在 Stage 内部，也可以是在 `prove_chain` 的两个 Stage 之间。完整的关于状态流转与衔接的约定位于 [`docs/composition/stage-composition.md`](docs/composition/stage-composition.md)。 **经典组件的定位。** ZK 领域的读者通常预期 Fiat-Shamir、`Polynomial`、`PCS` 和 sumcheck 是顶层的“模块”。但在当前的架构图中，它们并不是与 `Round` 平级的存在： - **Fiat-Shamir、`Polynomial` 和 fold** 是 `Round` 主体在进行计算时所使用的*基础素材* —— 即它所串联的副本、它所求值的多项式，以及它在每一步所应用的 fold（2-to-1 归约，每轮一个挑战）。 - **`PCS` opening 和 zero-check 则是 `Stage`** —— 每一个都是一个独立的阶段：zero-check 会归约为一个 sumcheck，而 `PCS` opening 会执行其承诺打开和求值检查（即上文提到的 *jagged-evals* 阶段）。 ## 开发说明 `zorch` 是基于 FRX 的纯 Python 实现，通过其 GPU 插件运行。使用固定版本工具链的 virtualenv： ``` python3.11 -m venv .venv && . .venv/bin/activate pip install -r requirements.in \ --extra-index-url https://fractalyze.github.io/pypi/simple/ ``` 使用明确指定的两个阶段名称来安装 git hooks。单纯的 `pre-commit install` 命令只会接入 `pre-commit` 阶段，这会导致 commit-message linter 保持未激活状态 —— 结果就是，当代码格式化 hook 触发时，格式错误的 commit message 却能一路畅通无阻地进入 CI： ``` pre-commit install --install-hooks --hook-type pre-commit --hook-type commit-msg ``` Commit message 需遵循 [Conventional Commits](https://www.conventionalcommits.org) 规范： 包含有效的类型、不带句号结尾的小写摘要、长度不超过 80 个字符的 Header，并且除了 `docs` 类型外，其余都必须包含 body。相同的 linter 也会在 CI 中对 Pull Request 中的每一个 commit 以及 PR 标题执行检查，这一点在这里至关重要，因为本仓库在执行 squash-merge 时，会将 PR 标题作为合并提交的 subject。 关于开发流程 —— 如按工作区划分的 venv、基于本地 Fractalyze XLA 构建进行开发、FRX 编译缓存规则等 —— 详见 [`docs/reference/development.md`](docs/reference/development.md)。 ## 文档 - **基于任务索引的文档中心：** [`docs/README.md`](docs/README.md) —— 根据您要完成的任务索引了所有设计文档。 ## 许可证 基于 Apache License, Version 2.0 授权（详见 [LICENSE](LICENSE)）。

标签：JAX, SNARKs, 多项式承诺, 密码学, 底层组件, 手动系统调用, 逆向工具, 零知识证明