{"id":31943206,"url":"https://github.com/zksecurity/zprize-ecdsa-varuna","last_synced_at":"2025-10-14T09:50:08.408Z","repository":{"id":198132943,"uuid":"693030300","full_name":"zksecurity/zprize-ecdsa-varuna","owner":"zksecurity","description":"specs \u0026 benchmarks for the ZPrize 3 - High Throughput Signature Verification","archived":false,"fork":false,"pushed_at":"2023-10-04T22:51:51.000Z","size":26,"stargazers_count":3,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2023-10-05T15:25:09.215Z","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/zksecurity.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-09-18T07:53:35.000Z","updated_at":"2023-10-05T03:03:53.000Z","dependencies_parsed_at":null,"dependency_job_id":"afe7823b-0f09-49d8-9c80-c69f06ecebfd","html_url":"https://github.com/zksecurity/zprize-ecdsa-varuna","commit_stats":null,"previous_names":["zksecurity/zprize-ecdsa-varuna"],"tags_count":0,"template":null,"template_full_name":null,"purl":"pkg:github/zksecurity/zprize-ecdsa-varuna","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zksecurity%2Fzprize-ecdsa-varuna","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zksecurity%2Fzprize-ecdsa-varuna/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zksecurity%2Fzprize-ecdsa-varuna/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zksecurity%2Fzprize-ecdsa-varuna/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zksecurity","download_url":"https://codeload.github.com/zksecurity/zprize-ecdsa-varuna/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zksecurity%2Fzprize-ecdsa-varuna/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279018555,"owners_count":26086404,"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-10-14T02:00:06.444Z","response_time":60,"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-10-14T09:50:02.123Z","updated_at":"2025-10-14T09:50:08.404Z","avatar_url":"https://github.com/zksecurity.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Zprize: High Throughput Signature Verification\n\nHow fast do you think you can verify our ECDSA signatures on Aleo?\n\nThis year's Zprize is winner-take-all. Join and compete for $500,000.\n\nThe competition will start on September 15th, 2023, and will end in February, 2024.\n\nRead on the learn more about the _High Throughput Signature Verification_ prize.\n\n## What is ECDSA?\n\n[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) is the most widely used digital signature scheme as of today. It is based on the now depreciated [DSA](https://en.wikipedia.org/wiki/Digital_Signature_Algorithm) standard, which was already based on Schnorr signatures at the time (but different enough to avoid [patents](https://en.wikipedia.org/wiki/Digital_Signature_Algorithm#History)).\n\nECDSA is defined on elliptic curves, must often with the [P-256](https://credelius.com/credelius/?p=97) curve, but in the cryptocurrency world the [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) curve is most often found instead.\n\nA signature scheme is usually always accompanied with a hash function. ECDSA is commonly used with the SHA-256 hash function, but other hash functions can be used as well. For example, Ethereum uses the [keccak256](https://medium.com/0xcode/hashing-functions-in-solidity-using-keccak256-70779ea55bb0) hash function (which is essentially SHA-3 with custom parameters).\n\n## Why ECDSA signature verification?\n\nVerifying ECDSA signatures allows bridging on-chain applications with either off-chain applications or other web3 platforms that make use of the signature standard (for example, Ethereum, Celestia, Bitcoin, etc.)\n\nIn addition, many of the problems that have to be optimized in order to make ECDSA signature verification more efficient in SNARKs are found in other useful use cases as well (see next section).\n\n## Why is it hard?\n\nVerifying ECDSA signature(s) inside a SNARK is considered _problematic_, as it involves:\n\n- **bitwise operations** (XOR, ROT, etc.) for the hash function which is not SNARK-friendly\n- **non-native arithmetic** (NNA) for the elliptic curve operations that are not native to the field used by the circuit\n\nOn top of this, you need to implement elliptic curve operations (like scalar multiplication) and the ECDSA verifier algorithm itself. Due to this, every seemingly-benign operation will tend to blow up, causing the ECDSA verifier circuit to be very large.\n\n## What is the prize about?\n\nDifferent projects and proof systems use different techniques, and techniques used in one project don't often easily translate to other projects as they involve a lot of ad-hoc manual work.\n\nFor this reason, it is a good idea to narrow the context of this competition to make it useful for a specific proof system and framework.\n\nFor this prize, we'll specifically target the Aleo proof system [Varuna](https://drive.google.com/file/d/1W9vsn5xT1vUmJbzO8VXoNS4W1wGWLDHN/view?usp=sharing) based on the [Marlin proof system](https://eprint.iacr.org/2019/1047) ([see here for a nice explainer](https://github.com/ingonyama-zk/papers/blob/main/Marlin_and_me.pdf)).\n\n## What am I allowed to do?\n\nThe proof system of Aleo, Varuna, is based on the R1CS arithmetization. As such, your first leverage is to optimize the R1CS circuit itself. You can do this in two ways: by using the high-level DSL [Leo](https://developer.aleo.org/leo/), [Aleo instructions](https://developer.aleo.org/aleo), or by writing R1CS directly in Rust using Aleo's embedded DSL (more on that later). Writing R1CS directly is usually preferred when one is trying to reduce the number of constraints as much as they can. But low-level R1CS gadgets can be exposed to Leo through [Leo operators](https://developer.aleo.org/leo/operators/).\n\nYour second line of attack is to blindly optimize the prover's implementation. We do not expect the most impressive changes to come from there, and as such we will not place a lot of emphasis on this part of the solution. Furthermore, we won't allow GPU and more generally approaches making use of hardware acceleration.\n\nFinally, we're also doing something special: we'll allow protocol-level modifications on Varuna, as long as they're contained and realistic. That is, they should not dramatically increase the prover time and memory usage for current programs that people are writing. The proof sizes should not drastically increase as well. In general, we expect people to take advantage of lookup tables, which are specified in the latest [Varuna specification](https://drive.google.com/file/d/1W9vsn5xT1vUmJbzO8VXoNS4W1wGWLDHN/view?usp=sharing).\n\n\u003e Note: another way to tackle this problem could be to use a different proof system, as long as that other proof system is secure, and that a proof for that different proof system can be safely wrapped in a Varuna proof (that is, you can write a verifier circuit with the Varuna stack).\n\n## How should I start?\n\nFirst, you should take a look at the `zprize_2023` branch of the [SnarkVM](https://github.com/AleoHQ/snarkVM/tree/zprize_2023/) repository.\n\nIf you want to write in Aleo instructions, the `vm/` folder contains [various tests which show how to write and prove programs](https://github.com/AleoHQ/snarkVM/tree/zprize_2023/synthesizer/tests).\n\nIf you want to write R1CS or lookups directly in Aleo's embedded DSL, you can take a look at the tests in the [`circuit/`](https://github.com/AleoHQ/snarkVM/blob/zprize_2023/circuit) folder. The subfolders contain gadgets showing how to create R1CS or lookup constraints.\n\nA naive solution should be the start of any solution :) you can look at [xJsnark](https://akosba.github.io/papers/xjsnark.pdf) and [Gnark's pure R1CS optimizations for non-native arithmetic](https://www.youtube.com/watch?v=05JemsgfEX4\u0026list=PLj80z0cJm8QHm_9BdZ1BqcGbgE-BEn-3Y). These solutions could be implemented using Aleo's embedded DSL.\n\nTo get a sense of how costs scale asymptotically, participants can either run a benchmark or look at the [Varuna specification](https://drive.google.com/file/d/1W9vsn5xT1vUmJbzO8VXoNS4W1wGWLDHN/view?usp=sharing).\n\nDon't hesitate to check prior work in lookups (e.g. the XOR table optimization in [this paper](https://github.com/ingonyama-zk/papers/blob/main/lookups.pdf)).\n\n## Security first\n\nPlaying with constraint optimizations, or protocol-level changes can be dangerous. You should always make sure that your changes are sound and secure.\n\nAs such, security will be the first metric we'll use to judge results. As it will be hard for us to review different solutions that explore different (potentially dangerous) techniques, we will place a lot of emphasis in clarity, readability, and auditability of the code and the associated documentation.\n\nIn other words, if your solution looks like [this PR](https://github.com/0xPolygonMiden/miden-vm/pull/123), this is not going to work for us :)\n\n## What are the other metrics for the prize?\n\nThe competition will start in a free-form format, but later in September we will release a set of benchmarks that will be used to judge the different solutions.\n\nWe're expecting these to be Rust benchmarks that you'll be able to run locally with your code to measure how long it takes to verify our random ECDSA signatures. Note that messages should be hashed in-circuit, not outside.\n\nAs such, you can expect benchmarks that will attempt to verify proofs with the following public inputs: ECDSA signatures, public keys, and messages (all unrelated). The ECDSA configuration will use secp256k1 and keccak256. \n\nCompetitors will be able to split these public inputs over several proofs if needed (for example, if you need 4 proofs to verify our 3 signatures, you can do that).\n\n## Licensing\n\nAll submission code must be open-sourced at the time of submission. Code and documentation must be dual-licensed under both the MIT and Apache-2.0 licenses\n\n## Questions\n\nIf there are any questions about this prize, please contact [david@zksecurity.xyz](mailto:david@zksecurity.xyz\u0026subject=zprize) or ask your question on [Discord](https://discord.com/channels/954403678079578173/1131190201205665862).\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzksecurity%2Fzprize-ecdsa-varuna","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzksecurity%2Fzprize-ecdsa-varuna","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzksecurity%2Fzprize-ecdsa-varuna/lists"}