Merge pull request #29 from okx/dev

Merge dev to main

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @muursh @wborgeaud @Nashtare

.github/workflows/continuous-integration-workflow.yml

@@ -27,6 +27,11 @@ jobs:
       - name: Checkout sources
         uses: actions/checkout@v4
 
+      - name: Add SSH private keys for submodule repositories
+        uses: webfactory/[email protected]
+        with:
+          ssh-private-key: ${{ secrets.CRYPTOGRAPHY_CUDA_READ_ONLY }}
+
       - name: Install nightly toolchain
         uses: dtolnay/rust-toolchain@nightly
 
@@ -51,14 +56,6 @@ jobs:
           CARGO_INCREMENTAL: 1
           RUST_BACKTRACE: 1
 
-      - name: Check in evm subdirectory
-        run: cargo check --manifest-path evm/Cargo.toml
-        env:
-          RUSTFLAGS: -Copt-level=3 -Cdebug-assertions -Coverflow-checks=y -Cdebuginfo=0
-          RUST_LOG: 1
-          CARGO_INCREMENTAL: 1
-          RUST_BACKTRACE: 1
-
       - name: Run cargo test
         run: cargo test --workspace
         env:
@@ -67,50 +64,20 @@ jobs:
           CARGO_INCREMENTAL: 1
           RUST_BACKTRACE: 1
 
-  wasm32:
-    name: wasm32 compatibility
-    runs-on: ubuntu-latest
-    timeout-minutes: 30
-    if: "! contains(toJSON(github.event.commits.*.message), '[skip-ci]')"
-    steps:
-      - name: Checkout sources
-        uses: actions/checkout@v4
-
-      - name: Install nightly toolchain
-        uses: dtolnay/rust-toolchain@nightly
-        with:
-          targets: wasm32-unknown-unknown
-
-      - name: Set up rust cache
-        uses: Swatinem/rust-cache@v2
-        with:
-            cache-on-failure: true
-
-      - name: Check in plonky2 subdirectory
-        run: cargo check --manifest-path plonky2/Cargo.toml --target wasm32-unknown-unknown --no-default-features
-        env:
-          RUSTFLAGS: -Copt-level=3 -Cdebug-assertions -Coverflow-checks=y -Cdebuginfo=0
-          RUST_LOG: 1
-          CARGO_INCREMENTAL: 1
-          RUST_BACKTRACE: 1
-
-      - name: Check in starky subdirectory
-        run: cargo check --manifest-path starky/Cargo.toml --target wasm32-unknown-unknown --no-default-features
-        env:
-          RUSTFLAGS: -Copt-level=3 -Cdebug-assertions -Coverflow-checks=y -Cdebuginfo=0
-          RUST_LOG: 1
-          CARGO_INCREMENTAL: 1
-          RUST_BACKTRACE: 1
-
   lints:
-    name: Formatting and Clippy
+    name: Formatting
     runs-on: ubuntu-latest
     timeout-minutes: 10
     if: "! contains(toJSON(github.event.commits.*.message), '[skip-ci]')"
     steps:
       - name: Checkout sources
         uses: actions/checkout@v4
 
+      - name: Add SSH private keys for submodule repositories
+        uses: webfactory/[email protected]
+        with:
+          ssh-private-key: ${{ secrets.CRYPTOGRAPHY_CUDA_READ_ONLY }}
+
       - name: Install nightly toolchain
         uses: dtolnay/rust-toolchain@nightly
         with:
@@ -123,6 +90,3 @@ jobs:
 
       - name: Run cargo fmt
         run: cargo fmt --all --check
-
-      - name: Run cargo clippy
-        run: cargo clippy --all-features --all-targets -- -D warnings -A incomplete-features

.gitignore

@@ -14,4 +14,5 @@ docs/**bench**
 
 **/*/libposeidon-permute-c-mac.a
 **/*/go-iden3-crypto/
+node_modules
 .vscode

CHANGELOG.md

@@ -0,0 +1,19 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## Unreleased
+
+- Fix CTLs with exactly two looking tables ([#1555](https://github.com/0xPolygonZero/plonky2/pull/1555))
+- Make Starks without constraints provable ([#1552](https://github.com/0xPolygonZero/plonky2/pull/1552))
+
+## [0.2.1] - 2024-03-01 (`starky` crate only)
+
+### Changed
+- Always compile cross_table_lookups::debug_utils ([#1540](https://github.com/0xPolygonZero/plonky2/pull/1540))
+
+## [0.2.0] - 2024-02-20
+- Initial CHANGELOG tracking.

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# Guidance for external contributors
+
+Do you feel keen and able to help with Plonky2? That's great! We
+encourage external contributions!
+
+We want to make it easy for you to contribute, but at the same time we
+must manage the burden of reviewing external contributions. We are a
+small team, and the time we spend reviewing external contributions is
+time we are not developing ourselves.
+
+We also want to help you to avoid inadvertently duplicating work that
+is already underway, or building something that we will not
+want to incorporate.
+
+First and foremost, please keep in mind that this is a highly
+technical piece of software and contributing is only suitable for
+experienced mathematicians, cryptographers and software engineers.
+
+The Polygon Zero Team reserves the right to accept or reject any
+external contribution for any reason, including a simple lack of time
+to maintain it (now or in the future); we may even decline to review
+something that is not considered a sufficiently high priority for us.
+
+To avoid disappointment, please communicate your intention to
+contribute openly, while respecting the limited time and availability
+we have to review and provide guidance for external contributions. It
+is a good idea to drop a note in our public Discord #development
+channel of your intention to work on something, whether an issue, a
+new feature, or a performance improvement. This is probably all that's
+really required to avoid duplication of work with other contributors.
+
+What follows are some more specific requests for how to write PRs in a
+way that will make them easy for us to review. Deviating from these
+guidelines may result in your PR being rejected, ignored or forgotten.
+
+
+## General guidance for your PR
+
+Obviously PRs will not be considered unless they pass our Github
+CI. The Github CI is not executed for PRs from forks, but you can
+simulate the Github CI by running the commands in
+`.github/workflows/ci.yml`.
+
+Under no circumstances should a single PR mix different purposes: Your
+PR is either a bug fix, a new feature, or a performance improvement,
+never a combination. Nor should you include, for example, two
+unrelated performance improvements in one PR. Please just submit
+separate PRs. The goal is to make reviewing your PR as simple as
+possible, and you should be thinking about how to compose the PR to
+minimise the burden on the reviewer.
+
+Also note that any PR that depends on unstable features will be
+automatically rejected. The Polygon Zero Team may enable a small
+number of unstable features in the future for our exclusive use;
+nevertheless we aim to minimise the number of such features, and the
+number of uses of them, to the greatest extent possible.
+
+Here are a few specific guidelines for the three main categories of
+PRs that we expect:
+
+
+### The PR fixes a bug
+
+In the PR description, please clearly but briefly describe
+
+1. the bug (could be a reference to a GH issue; if it is from a
+   discussion (on Discord/email/etc. for example), please copy in the
+   relevant parts of the discussion);
+2. what turned out to the cause the bug; and
+3. how the PR fixes the bug.
+
+Wherever possible, PRs that fix bugs should include additional tests
+that (i) trigger the original bug and (ii) pass after applying the PR.
+
+
+### The PR implements a new feature
+
+If you plan to contribute an implementation of a new feature, please
+double-check with the Polygon Zero team that it is a sufficient
+priority for us that it will be reviewed and integrated.
+
+In the PR description, please clearly but briefly describe
+
+1. what the feature does
+2. the approach taken to implement it
+
+All PRs for new features must include a suitable test suite.
+
+
+### The PR improves performance
+
+Performance improvements are particularly welcome! Please note that it
+can be quite difficult to establish true improvements for the
+workloads we care about. To help filter out false positives, the PR
+description for a performance improvement must clearly identify
+
+1. the target bottleneck (only one per PR to avoid confusing things!)
+2. how performance is measured
+3. characteristics of the machine used (CPU, OS, #threads if appropriate)
+4. performance before and after the PR

Cargo.toml

@@ -1,12 +1,40 @@
 [workspace]
-members = ["evm", "field", "maybe_rayon", "plonky2", "starky", "util",  "gen"]
+members = ["field", "maybe_rayon", "plonky2", "starky", "util", "gen"]
 resolver = "2"
 
+[workspace.dependencies]
+cryptography_cuda = { git = "ssh://[email protected]/okx/cryptography_cuda.git", rev = "173510160183f3299f4765b30bd4f2c1685353f9", features = [
+    "no_cuda",
+] }
+ahash = { version = "0.8.7", default-features = false, features = [
+    "compile-time-rng",
+] } # NOTE: Be sure to keep this version the same as the dependency in `hashbrown`.
+anyhow = { version = "1.0.40", default-features = false }
+hashbrown = { version = "0.14.3", default-features = false, features = [
+    "ahash",
+    "serde",
+] } # NOTE: When upgrading, see `ahash` dependency.
+itertools = { version = "0.11.0", default-features = false }
+log = { version = "0.4.14", default-features = false }
+num = { version = "0.4", default-features = false, features = ["rand"] }
+rand = { version = "0.8.4", default-features = false }
+serde = { version = "1.0", default-features = false, features = ["derive"] }
+static_assertions = { version = "1.1.0", default-features = false }
+unroll = { version = "0.1.5", default-features = false }
+
 [profile.release]
 opt-level = 3
 incremental = true
 #lto = "fat"
 #codegen-units = 1
 
 [profile.bench]
-opt-level = 3
+opt-level = 3
+
+[workspace.package]
+edition = "2021"
+license = "MIT OR Apache-2.0"
+homepage = "https://github.com/0xPolygonZero/plonky2"
+repository = "https://github.com/0xPolygonZero/plonky2"
+keywords = ["cryptography", "SNARK", "PLONK", "FRI", "plonky2"]
+categories = ["cryptography"]

README.md

@@ -14,4 +14,63 @@ git submodule update --init --recursive
 - cuda NTT
 ```
 cargo run --release -p plonky2_field --features=cuda --example fft
-```
+```
+
+## Running
+
+To see recursion performance, one can run this bench, which generates a chain of three recursion proofs:
+
+```sh
+RUSTFLAGS=-Ctarget-cpu=native cargo run --release --example bench_recursion -- -vv
+```
+
+## Jemalloc
+
+Plonky2 prefers the [Jemalloc](http://jemalloc.net) memory allocator due to its superior performance. To use it, include `jemallocator = "0.5.0"` in your `Cargo.toml` and add the following lines
+to your `main.rs`:
+
+```rust
+use jemallocator::Jemalloc;
+
+#[global_allocator]
+static GLOBAL: Jemalloc = Jemalloc;
+```
+
+Jemalloc is known to cause crashes when a binary compiled for x86 is run on an Apple silicon-based Mac under [Rosetta 2](https://support.apple.com/en-us/HT211861). If you are experiencing crashes on your Apple silicon Mac, run `rustc --print target-libdir`. The output should contain `aarch64-apple-darwin`. If the output contains `x86_64-apple-darwin`, then you are running the Rust toolchain for x86; we recommend switching to the native ARM version.
+
+## Contributing guidelines
+
+See [CONTRIBUTING.md](./CONTRIBUTING.md).
+
+## Licenses
+
+All crates of this monorepo are licensed under either of
+
+* Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
+* MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
+
+at your option.
+
+
+## Security
+
+This code has not yet been audited, and should not be used in any production systems.
+
+While Plonky2 is configurable, its defaults generally target 100 bits of security. The default FRI configuration targets 100 bits of *conjectured* security based on the conjecture in [ethSTARK](https://eprint.iacr.org/2021/582).
+
+Plonky2's default hash function is Poseidon, configured with 8 full rounds, 22 partial rounds, a width of 12 field elements (each ~64 bits), and an S-box of `x^7`. [BBLP22](https://tosc.iacr.org/index.php/ToSC/article/view/9850) suggests that this configuration may have around 95 bits of security, falling a bit short of our 100 bit target.
+
+
+## Links
+
+#### Actively maintained
+
+- [Polygon Zero's zkEVM](https://github.com/0xPolygonZero/zk_evm), an efficient Type 1 zkEVM built on top of Starky and plonky2
+
+#### No longer maintained
+
+- [System Zero](https://github.com/0xPolygonZero/system-zero), a zkVM built on top of Starky
+- [Waksman](https://github.com/0xPolygonZero/plonky2-waksman), Plonky2 gadgets for permutation checking using Waksman networks
+- [Insertion](https://github.com/0xPolygonZero/plonky2-insertion), Plonky2 gadgets for insertion into a list
+- [u32](https://github.com/0xPolygonZero/plonky2-u32), Plonky2 gadgets for u32 arithmetic
+- [ECDSA](https://github.com/0xPolygonZero/plonky2-ecdsa), Plonky2 gadgets for the ECDSA algorithm

SECURITY.md

@@ -0,0 +1,17 @@
+# Polygon Technology Security Information
+
+## Link to vulnerability disclosure details (Bug Bounty).
+- Websites and Applications: https://hackerone.com/polygon-technology
+- Smart Contracts: https://immunefi.com/bounty/polygon
+
+## Languages that our team speaks and understands.
+Preferred-Languages: en
+
+## Security-related job openings at Polygon.
+https://polygon.technology/careers
+
+## Polygon security contact details.
+[email protected]
+
+## The URL for accessing the security.txt file.
+Canonical: https://polygon.technology/security.txt

circom/circuits/goldilocks.circom

@@ -0,0 +1,35 @@
+pragma circom 2.0.9;
+
+template GlExp() {
+  signal input x;
+  signal input n;
+  signal output out;
+
+  signal e2[65];
+  signal temp1[64];
+  signal temp2[64];
+  signal mul[65];
+  mul[0] <== 1;
+  e2[0] <== x;
+  for (var i = 0; i < 64; i++) {
+    temp1[i] <-- (n >> i) & 1;
+    temp2[i] <== e2[i] * temp1[i] + 1 - temp1[i];
+    mul[i + 1] <== mul[i] * temp2[i];
+    e2[i + 1] <== e2[i] * e2[i];
+  }
+
+  out <== mul[64];
+}
+
+template GlExtMul() {
+  signal input a[2];
+  signal input b[2];
+  signal output out[2];
+
+  var W = 7;
+  signal tmp1 <== W * a[1] * b[1];
+  signal tmp2 <== a[1] * b[0];
+
+  out[0] <== a[0] * b[0] + tmp1;
+  out[1] <== a[0] * b[1] + tmp2;
+}