Merge pull request #18 from okx/dev-cliff-upgrade-v0.2.0

Dev cliff upgrade v0.2.0

.github/CODEOWNERS

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

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

@@ -51,14 +51,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,8 +59,8 @@ jobs:
           CARGO_INCREMENTAL: 1
           RUST_BACKTRACE: 1
 
-  wasm32:
-    name: wasm32 compatibility
+  wasm:
+    name: Check wasm32 compatibility
     runs-on: ubuntu-latest
     timeout-minutes: 30
     if: "! contains(toJSON(github.event.commits.*.message), '[skip-ci]')"
@@ -86,22 +78,57 @@ jobs:
         with:
             cache-on-failure: true
 
-      - name: Check in plonky2 subdirectory
+      - name: Check in plonky2 subdirectory for wasm targets
         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
+      - name: Check in starky subdirectory for wasm targets
         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
 
+  no_std:
+    name: Test Suite in no-std
+    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@master
+        with:
+          toolchain: nightly-2024-02-01
+
+      - name: Set up rust cache
+        uses: Swatinem/rust-cache@v2
+        with:
+            cache-on-failure: true
+
+      - name: Run cargo test in plonky2 subdirectory (no-std)
+        run: cargo test --manifest-path plonky2/Cargo.toml --no-default-features --lib
+        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 in starky subdirectory (no-std)
+        run: cargo test --manifest-path starky/Cargo.toml --no-default-features --lib
+        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
     runs-on: ubuntu-latest

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,32 @@
 [workspace]
-members = ["evm", "field", "maybe_rayon", "plonky2", "starky", "util",  "gen"]
+members = ["field", "maybe_rayon", "plonky2", "starky", "util",  "gen"]
 resolver = "2"
 
+[workspace.dependencies]
+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

evm/Cargo.toml

@@ -2,7 +2,6 @@
 name = "plonky2_evm"
 description = "Implementation of STARKs for the Ethereum Virtual Machine"
 version = "0.1.1"
-license = "MIT or Apache-2.0"
 authors = ["Daniel Lubarov <[email protected]>", "William Borgeaud <[email protected]>"]
 readme = "README.md"
 repository = "https://github.com/0xPolygonZero/plonky2"
@@ -14,7 +13,7 @@ edition = "2021"
 anyhow = "1.0.40"
 bytes = "1.4.0"
 env_logger = "0.10.0"
-eth_trie_utils = { git = "https://github.com/0xPolygonZero/eth_trie_utils.git", rev = "7fc3c3f54b3cec9c6fc5ffc5230910bd1cb77f76" }
+eth_trie_utils = { git = "https://github.com/0xPolygonZero/eth_trie_utils.git", rev = "e9ec4ec2aa2ae976b7c699ef40c1ffc716d87ed5" }
 ethereum-types = "0.14.0"
 hex = { version = "0.4.3", optional = true }
 hex-literal = "0.4.1"
@@ -60,7 +59,3 @@ required-features = ["asmtools"]
 [[bench]]
 name = "stack_manipulation"
 harness = false
-
-# Display math equations properly in documentation
-[package.metadata.docs.rs]
-rustdoc-args = ["--html-in-header", ".cargo/katex-header.html"]