{"id":26788267,"url":"https://github.com/qedprotocol/plonky2-merkle-config","last_synced_at":"2025-09-11T13:05:43.474Z","repository":{"id":204859747,"uuid":"712833398","full_name":"QEDProtocol/plonky2-merkle-config","owner":"QEDProtocol","description":"Plonky2 with MerkleTreeHasher added to Generic Config to support hardware acceleration","archived":false,"fork":false,"pushed_at":"2023-11-01T09:46:05.000Z","size":9829,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-29T13:16:36.724Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/QEDProtocol.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-11-01T09:44:10.000Z","updated_at":"2023-11-01T09:46:11.000Z","dependencies_parsed_at":null,"dependency_job_id":"d6d9ffdc-9815-4fb5-8f79-540f07361c61","html_url":"https://github.com/QEDProtocol/plonky2-merkle-config","commit_stats":null,"previous_names":["qedprotocol/plonky2-merkle-config"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/QEDProtocol/plonky2-merkle-config","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/QEDProtocol%2Fplonky2-merkle-config","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/QEDProtocol%2Fplonky2-merkle-config/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/QEDProtocol%2Fplonky2-merkle-config/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/QEDProtocol%2Fplonky2-merkle-config/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/QEDProtocol","download_url":"https://codeload.github.com/QEDProtocol/plonky2-merkle-config/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/QEDProtocol%2Fplonky2-merkle-config/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":274640911,"owners_count":25322843,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-09-11T02:00:13.660Z","response_time":74,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-03-29T13:16:40.599Z","updated_at":"2025-09-11T13:05:43.456Z","avatar_url":"https://github.com/QEDProtocol.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Plonky2 \u0026 more\n\nThis repository was originally for Plonky2, a SNARK implementation based on techniques from PLONK and FRI. It has since expanded to include tools such as Starky, a highly performant STARK implementation.\n\n\n## Documentation\n\nFor more details about the Plonky2 argument system, see this [writeup](plonky2/plonky2.pdf).\n\nPolymer Labs has written up a helpful tutorial [here](https://polymerlabs.medium.com/a-tutorial-on-writing-zk-proofs-with-plonky2-part-i-be5812f6b798)!\n\n\n## Examples\n\nA good starting point for how to use Plonky2 for simple applications is the included examples:\n\n* [`factorial`](plonky2/examples/factorial.rs): Proving knowledge of 100!\n* [`fibonacci`](plonky2/examples/fibonacci.rs): Proving knowledge of the hundredth Fibonacci number\n* [`range_check`](plonky2/examples/range_check.rs): Proving that a field element is in a given range\n* [`square_root`](plonky2/examples/square_root.rs): Proving knowledge of the square root of a given field element\n\nTo run an example, use\n\n```sh\ncargo run --example \u003cexample_name\u003e\n```\n\n\n## Building\n\nPlonky2 requires a recent nightly toolchain, although we plan to transition to stable in the future.\n\nTo use a nightly toolchain for Plonky2 by default, you can run\n```\nrustup override set nightly\n```\nin the Plonky2 directory.\n\n\n## Running\n\nTo see recursion performance, one can run this bench, which generates a chain of three recursion proofs:\n\n```sh\nRUSTFLAGS=-Ctarget-cpu=native cargo run --release --example bench_recursion -- -vv\n```\n\n## Jemalloc\n\nPlonky2 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\nto your `main.rs`:\n\n```rust\nuse jemallocator::Jemalloc;\n\n#[global_allocator]\nstatic GLOBAL: Jemalloc = Jemalloc;\n```\n\nJemalloc 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.\n\n\n## Guidance for external contributors\n\nDo you feel keen and able to help with Plonky2? That's great! We\nencourage external contributions!\n\nWe want to make it easy for you to contribute, but at the same time we\nmust manage the burden of reviewing external contributions. We are a\nsmall team, and the time we spend reviewing external contributions is\ntime we are not developing ourselves.\n\nWe also want to help you to avoid inadvertently duplicating work that\nis already underway, or building something that we will not\nwant to incorporate.\n\nFirst and foremost, please keep in mind that this is a highly\ntechnical piece of software and contributing is only suitable for\nexperienced mathematicians, cryptographers and software engineers.\n\nThe Polygon Zero Team reserves the right to accept or reject any\nexternal contribution for any reason, including a simple lack of time\nto maintain it (now or in the future); we may even decline to review\nsomething that is not considered a sufficiently high priority for us.\n\nTo avoid disappointment, please communicate your intention to\ncontribute openly, while respecting the limited time and availability\nwe have to review and provide guidance for external contributions. It\nis a good idea to drop a note in our public Discord #development\nchannel of your intention to work on something, whether an issue, a\nnew feature, or a performance improvement. This is probably all that's\nreally required to avoid duplication of work with other contributors.\n\nWhat follows are some more specific requests for how to write PRs in a\nway that will make them easy for us to review. Deviating from these\nguidelines may result in your PR being rejected, ignored or forgotten.\n\n\n### General guidance for your PR\n\nObviously PRs will not be considered unless they pass our Github\nCI. The Github CI is not executed for PRs from forks, but you can\nsimulate the Github CI by running the commands in\n`.github/workflows/ci.yml`.\n\nUnder no circumstances should a single PR mix different purposes: Your\nPR is either a bug fix, a new feature, or a performance improvement,\nnever a combination. Nor should you include, for example, two\nunrelated performance improvements in one PR. Please just submit\nseparate PRs. The goal is to make reviewing your PR as simple as\npossible, and you should be thinking about how to compose the PR to\nminimise the burden on the reviewer.\n\nAlso note that any PR that depends on unstable features will be\nautomatically rejected. The Polygon Zero Team may enable a small\nnumber of unstable features in the future for our exclusive use;\nnevertheless we aim to minimise the number of such features, and the\nnumber of uses of them, to the greatest extent possible.\n\nHere are a few specific guidelines for the three main categories of\nPRs that we expect:\n\n\n#### The PR fixes a bug\n\nIn the PR description, please clearly but briefly describe\n\n1. the bug (could be a reference to a GH issue; if it is from a\n   discussion (on Discord/email/etc. for example), please copy in the\n   relevant parts of the discussion);\n2. what turned out to the cause the bug; and\n3. how the PR fixes the bug.\n\nWherever possible, PRs that fix bugs should include additional tests\nthat (i) trigger the original bug and (ii) pass after applying the PR.\n\n\n#### The PR implements a new feature\n\nIf you plan to contribute an implementation of a new feature, please\ndouble-check with the Polygon Zero team that it is a sufficient\npriority for us that it will be reviewed and integrated.\n\nIn the PR description, please clearly but briefly describe\n\n1. what the feature does\n2. the approach taken to implement it\n\nAll PRs for new features must include a suitable test suite.\n\n\n#### The PR improves performance\n\nPerformance improvements are particularly welcome! Please note that it\ncan be quite difficult to establish true improvements for the\nworkloads we care about. To help filter out false positives, the PR\ndescription for a performance improvement must clearly identify\n\n1. the target bottleneck (only one per PR to avoid confusing things!)\n2. how performance is measured\n3. characteristics of the machine used (CPU, OS, #threads if appropriate)\n4. performance before and after the PR\n\n\n## Licenses\n\nAs this is a monorepo, see the individual crates within for license information.\n\n\n## Security\n\nThis code has not yet been audited, and should not be used in any production systems.\n\nWhile 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).\n\nPlonky2'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.\n\n\n## Links\n\n- [System Zero](https://github.com/0xPolygonZero/system-zero), a zkVM built on top of Starky (no longer maintained)\n- [Waksman](https://github.com/0xPolygonZero/plonky2-waksman), Plonky2 gadgets for permutation checking using Waksman networks (no longer maintained)\n- [Insertion](https://github.com/0xPolygonZero/plonky2-insertion), Plonky2 gadgets for insertion into a list (no longer maintained)\n- [u32](https://github.com/0xPolygonZero/plonky2-u32), Plonky2 gadgets for u32 arithmetic (no longer actively maintained)\n- [ECDSA](https://github.com/0xPolygonZero/plonky2-ecdsa), Plonky2 gadgets for the ECDSA algorithm (no longer actively maintained)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fqedprotocol%2Fplonky2-merkle-config","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fqedprotocol%2Fplonky2-merkle-config","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fqedprotocol%2Fplonky2-merkle-config/lists"}