Lib.rs

Plonky3 是一个用于实现多项式 IOPs (PIOPs) 的工具包，例如 PLONK 和 STARKs。它旨在支持多种多项式承诺方案，如 Brakedown。

这是“核心”存储库，但计划在 API 稳定后，将每个 crate 移动到自己的存储库。

状态

字段

• Mersenne31
  • “复杂”扩展域
  • ~128 位扩展域
  • AVX2
  • AVX-512
  • NEON
• BabyBear
  • ~128 位扩展域
  • AVX2
  • AVX-512
  • NEON
• Goldilocks
  • ~128 位扩展域

通用向量承诺方案

• 通用 Merkle 树

多项式承诺方案

• FRI 基础 PCS
• 张量 PCS
• 一元到多元适配器
• 多元到一元适配器

PIOPs

• 一元 STARK
• 多元 STARK
• PLONK

代码

• Brakedown
• Reed-Solomon

插值

• 重心插值
• 基数-2 DIT FFT
• 基数-2 Bowers FFT
• 四步 FFT
• Mersenne 圆组 FFT

哈希

• Rescue
• Poseidon
• Poseidon2
• BLAKE3
  • 调整 BLAKE3 以适应小叶子的修改
• Keccak-256
• Monolith

基准测试

我们有时使用 Keccak AIR 来比较 Plonky3 的性能与其他库，如 Plonky2。这里有多种变化，包括不同的字段等，但以下是一个示例

RUST_LOG=info cargo run --example prove_baby_bear_keccak --release --features parallel

CPU 功能

Plonky3 包含依赖于较新 CPU 指令的优化，这些指令在旧处理器中不可用。这些指令集包括 x86 的 BMI1 和 2、AVX2 和 AVX-512。Rustc 默认不会生成这些指令；它们必须通过 target-feature 编译器选项（或通过设置 target-cpu）显式启用。要启用您机器上支持的所有功能，可以将 target-cpu 设置为 native。例如，要运行测试

RUSTFLAGS="-Ctarget-cpu=native" cargo test

对某些指令的支持，例如AVX-512，仍处于实验阶段。它们仅可在Rustc的夜间构建中找到，并且通过nightly-features功能标志启用。要使用它们，您必须在Rustc中启用标志（例如，通过设置target-feature）并启用nightly-features功能。

仅夜间构建的优化

某些优化（尤其是AVX-512优化的数学）依赖于目前仅在Rustc的夜间构建中可用的功能。要使用它们，您需要启用nightly-features功能。例如，要运行测试

cargo test --features nightly-features

许可证

根据您的选择许可

• Apache许可证版本2.0，(LICENSE-APACHE或http://www.apache.org/licenses/LICENSE-2.0)
• MIT许可证 (LICENSE-MIT或http://opensource.org/licenses/MIT)

任选其一。

对外部贡献者的指南

您是否热衷并有能力帮助Plonky3？那太好了！我们鼓励外部贡献！

我们希望使您能够轻松贡献，但同时也必须管理审查外部贡献的负担。我们是一个小型团队，我们花费在审查外部贡献上的时间是我们不能用于自我开发的时间。

我们还希望帮助您避免无意中重复正在进行中的工作，或者构建我们不希望整合的东西。

首先，请记住，这是一个高度技术性的软件，只有经验丰富的数学家、密码学家和软件工程师才适合贡献。

Polygon Zero团队保留根据任何理由接受或拒绝任何外部贡献的权利，包括现在或将来缺乏维护它的时间；我们甚至可能拒绝审查我们认为优先级不高的东西。

为了避免失望，请公开沟通您想要贡献的意图，同时尊重我们有限的审查和为外部贡献提供指导的时间。在公共Discord #development频道中留下一条关于您想要工作的消息（无论是问题、新功能还是性能改进）是个好主意。这可能是避免与其他贡献者重复工作的真正所需。

以下是一些关于如何编写易于我们审查的PR的具体请求。偏离这些指南可能会导致您的PR被拒绝、忽略或遗忘。

关于您的PR的一般指导

显然，除非PR通过我们的Github CI，否则不会考虑它们。对于分支的PR，不会执行Github CI，但您可以通过运行.github/workflows/ci.yml中的命令来模拟Github CI。

在任何情况下，单个PR都不应混合不同的目的：您的PR要么是错误修复，要么是新功能，要么是性能改进，永远不应该是两者的组合。例如，您也不应该在单个PR中包含两个不相关的性能改进。请只提交单独的PR。目标是使审查您的PR尽可能简单，您应该考虑如何组成PR以最小化对审阅者的负担。

Plonky3使用稳定的Rust，因此任何依赖于不稳定功能的PR很可能会被拒绝。我们可能会在未来放宽这项政策，但我们的目标是尽量减少不稳定功能的使用；在启用任何功能之前，请与我们讨论。

以下是我们期望的三个主要类别Pull Requests（PR）的一些具体指南

PR修复了一个错误

在PR描述中，请清晰地但简要地描述

1. 错误（可以是GH问题的引用；如果是来自讨论（例如Discord/电子邮件等），请复制讨论的相关部分）；
2. 导致错误的根本原因；以及
3. PR如何修复错误。

wherever possible，修复错误的PR应包括额外的测试，这些测试（i）触发原始错误，并且（ii）在应用PR后通过。

PR实现了一个新功能

如果您计划贡献新功能的实现，请与Polygon Zero团队确认，这是否是我们优先级足够高的事项，以便对其进行审查和集成。

在PR描述中，请清晰地但简要地描述

1. 该功能的作用
2. 实现该功能的采用方法

所有新功能的PR都必须包含合适的测试套件。

PR提高了性能

性能改进特别受欢迎！请注意，确定我们关心的工作负载的真实改进可能相当困难。为了帮助筛选出假阳性，性能改进的PR描述必须清楚地识别

1. 目标瓶颈（每个PR仅一个，以避免混淆！）
2. 性能的测量方法
3. 使用机器的特性（CPU、操作系统、如果适用则线程数）
4. PR前后的性能

许可

除非您明确表示，否则您提交的任何旨在包含在您的工作中的贡献，如Apache-2.0许可中定义，应按上述方式双许可，不附加任何额外的条款或条件。