{"id":27535573,"url":"https://github.com/ciphercurve/toyni","last_synced_at":"2025-04-18T19:07:25.253Z","repository":{"id":287767914,"uuid":"965729477","full_name":"ciphercurve/toyni","owner":"ciphercurve","description":"Toyni is a new, emerging ZK proof system in Rust, developed by Ciphercurve.","archived":false,"fork":false,"pushed_at":"2025-04-13T20:19:32.000Z","size":479,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-04-13T20:34:11.573Z","etag":null,"topics":["formal-verification","open-source","proof-system","research","rust","stark","zero-knowledge","zero-knowledge-proofs"],"latest_commit_sha":null,"homepage":"https://ciphercurve.com","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/ciphercurve.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,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-04-13T19:30:27.000Z","updated_at":"2025-04-13T20:19:35.000Z","dependencies_parsed_at":"2025-04-13T20:34:15.257Z","dependency_job_id":"8458d331-c6b0-4239-ab3d-834346353d50","html_url":"https://github.com/ciphercurve/toyni","commit_stats":null,"previous_names":["ciphercurve/toyni"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ciphercurve%2Ftoyni","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ciphercurve%2Ftoyni/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ciphercurve%2Ftoyni/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ciphercurve%2Ftoyni/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ciphercurve","download_url":"https://codeload.github.com/ciphercurve/toyni/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249535840,"owners_count":21287496,"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","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":["formal-verification","open-source","proof-system","research","rust","stark","zero-knowledge","zero-knowledge-proofs"],"created_at":"2025-04-18T19:07:24.796Z","updated_at":"2025-04-18T19:07:25.243Z","avatar_url":"https://github.com/ciphercurve.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Toyni: A STARK Implementation in Progress\n\u003e [!WARNING]\n\u003e Toyni was migrated from [jonas089's Github](https://github.com/jonas089/Toyni)\n\u003e Click [here](https://github.com/jonas089/Toyni) to see the past commit history.\n\nWelcome to Toyni! This is an implementation of a STARK (Scalable Transparent Argument of Knowledge) proving system in Rust. While it's not yet a full zero-knowledge STARK, it provides a solid foundation for understanding how STARKs work.\n\n\n![toyniii](art/toyniii.jpg)\n\nMeet the amazing artist behind this creation, [Kristiana Skrastina](https://www.linkedin.com/in/kristiana-skrastina/)\n\n\n\u003e [!WARNING]  \n\u003e This is a research project and hasn't been audited. Use at your own risk.\n\n## 0. Background, STARK Verifier: Constraint vs FRI Layer Checks\n\n## ✅ Constraint Check (Single Layer)\n- For each randomly sampled point `x`:\n  - Verifier checks:\n    ```\n    Q(x) * Z(x) == C(x)\n    ```\n  - Ensures that the execution trace satisfies all constraints\n  - **This check is done once per point**\n  - **Not done across layers**\n  - Merkle proof is optional (depends on how C(x) and Q(x) are committed)\n\n---\n\n## ✅ FRI Layer Checks (Multiple Layers)\n- Purpose: Prove that `Q(x)` is a **low-degree polynomial**\n- Process:\n  1. Start with evaluations of `Q(x)` over the domain (Layer 0)\n  2. Recursively apply `fri_fold()` to reduce degree at each layer\n  3. At each layer:\n     - Verifier checks Merkle proofs for sampled values\n     - Verifies that folding is consistent with previous layer\n  4. Final layer should be constant or degree-1, checked directly\n\n- ✅ Merkle proofs are **checked at each FRI layer**\n- ✅ Folding correctness is verified at each layer\n\n---\n\n## 🔍 STARK Verifier Flow: Visual Diagram\n\n```mermaid\nsequenceDiagram\n    participant Proof_Data\n    participant Constraint_Check\n    participant FRI_Protocol\n    participant FRI_Merkle_Commitment\n    participant FRI_Consistency\n    participant FRI_Layers\n    participant Accept_Proof\n\n    Proof_Data--\u003eConstraint_Check: Check Q(x)·Z(x) == C(x)\n    Proof_Data--\u003eFRI_Protocol: Begin FRI protocol\n    FRI_Protocol--\u003eFRI_Merkle_Commitment: Verify Merkle proofs\n    FRI_Merkle_Commitment--\u003eFRI_Consistency: Check folding inputs + β\n    FRI_Consistency--\u003eFRI_Layers: Fold with β0..βn\n    FRI_Layers--\u003eAccept_Proof: ✅ Accept Proof\n```\n\n\u003e[!NOTE]\n\u003e FRI folding equation:\n\u003e f_{i+1}(x²) = (fᵢ(x) + fᵢ(–x) + βᵢ · (fᵢ(x) – fᵢ(–x))) / 2\n\n## 🔐 STARK Verifier: Security Parameters for 128-bit Soundness\n\n### FRI QUERIES\nTo achieve **128-bit soundness** in STARK proofs, the total probability that a cheating prover is accepted must be less than `2⁻¹²⁸`.\n\nThis involves carefully choosing parameters for:\n\n- Constraint checks (`Q(x)` evaluations)\n- FRI protocol (number of layers and queries per layer)\n\n\u003e Example:\n\u003e - If `L = 20` layers → `log₂(20) ≈ 4.3`\n\u003e - Then: `m ≈ 133` queries per layer\n---\n\n### CONSTRAINT CHECKS\n\u003e Example:\n\u003e - If `d / N = 1/4`, then `log₂(N/d) = 2`\n\u003e - So: `n = 128 / 2 = 64` spot checks\n\n\u003e - If `d / N = 1/8`, then `log₂(N/d) = 3`\n\u003e - So: `n = 128 / 3 ≈ 43`, but round up to be safe\n---\n\n### ✅ Practical Recommendation:\nUse `n = 64–80` spot checks for strong 128-bit soundness across typical domain/degree ratios.\n\n### ✅ Recommendations for 128-bit Security\n\n| Component              | Suggested Value                    |\n|-----------------------|------------------------------------|\n| Constraint checks `n` | 64–80                              |\n| FRI layers `L`        | log₂(N / degree of final poly)     |\n| FRI queries `m`       | ≥ log₂(L) + 128 (e.g., 133)        |\n| Total soundness error | ε_total = ε_constraints + ε_fri ≤ 2⁻¹²⁸ |\n\n## 🔁 Summary\n\n| Check Type         | Equation Checked              | Merkle Proofs | Multiple Layers? |\n|--------------------|-------------------------------|----------------|-------------------|\n| Constraint Check   | `Q(x) * Z(x) == C(x)`          | Optional       | ❌ No             |\n| FRI Layer Check    | Folding consistency, low-degree| ✅ Yes          | ✅ Yes            |\n\n\n## 1. Introduction\n\nSTARKs are a powerful cryptographic tool that enables proving the correct execution of a computation without revealing the underlying data. Think of it as a way to convince someone that you know the solution to a puzzle without actually showing them the solution. This property, known as zero-knowledge, is crucial for privacy-preserving applications in areas like financial transactions, voting systems, and private identity verification.\n\n### 2. Why STARKs Matter\n\n| Scalability | Transparency | Zero-Knowledge |\n|-------------|--------------|----------------|\n| • O(log² n) proof size | • No trusted setup | • Privacy |\n| • Fast verify | • Public parameters | • Confidentiality |\n| • Efficient | | • Data protection |\n| | | • Secure sharing |\n\n### 3. Real-World Applications\n\n| Financial | Identity | Computing |\n|-----------|----------|-----------|\n| • Private payments | • Age verification | • Confidential computing |\n| • Asset ownership | • Credential validation | • Private ML |\n| | | • Secure MPC |\n\n## 4. Technical Overview\n\nAt its heart, Toyni consists of three main components working together:\n\n| Virtual Machine | Constraint System | STARK Prover |\n|----------------|-------------------|--------------|\n| • Executes programs | • Defines rules | • Generates proofs |\n| • Creates traces | • Validates states | • Uses FRI protocol |\n\n### 5. How It Works\n\n| Program Execution | Execution Trace | Verification |\n|------------------|-----------------|--------------|\n| • Run program | • Record states | • Sample positions |\n| • Track state | • Build constraints | • Check constraints |\n| • Generate trace | | |\n\nHere's a simple example that demonstrates how Toyni works. We'll create a program that proves a sequence of numbers increments by 1 each time:\n\n```rust\nfn test_valid_proof() {\n    let mut trace = ExecutionTrace::new(4, 1);\n    for i in 0..4 {\n        let mut row = HashMap::new();\n        row.insert(\"x\".to_string(), i);\n        trace.insert_column(row);\n    }\n\n    let mut constraints = ConstraintSystem::new();\n    constraints.add_transition_constraint(\n        \"increment\".to_string(),\n        vec![\"x\".to_string()],\n        Box::new(|current, next| {\n            let x_n = Fr::from(*current.get(\"x\").unwrap() as u64);\n            let x_next = Fr::from(*next.get(\"x\").unwrap() as u64);\n            x_next - x_n - Fr::ONE\n        }),\n    );\n    constraints.add_boundary_constraint(\n        \"starts_at_0\".to_string(),\n        0,\n        vec![\"x\".to_string()],\n        Box::new(|row| Fr::from(*row.get(\"x\").unwrap() as u64)),\n    );\n\n    let prover = StarkProver::new(\u0026trace, \u0026constraints);\n    let proof = prover.generate_proof();\n    let verifier = StarkVerifier::new(\u0026constraints, trace.height as usize);\n    assert!(verifier.verify(\u0026proof));\n}\n```\n\nThis example demonstrates how Toyni can prove that a sequence of numbers follows a specific pattern (incrementing by 1) without revealing the actual numbers. The proof can be verified by anyone, but the actual values remain private.\n\n### 6. Security Properties\n\nSTARKs achieve their security through a combination of domain extension and low-degree testing. Here's how it works:\n\n| Domain Extension | Low-Degree Testing | Soundness Guarantees |\n|-----------------|-------------------|---------------------|\n| • Extend domain | • FRI protocol | • Soundness error: (1/b)^q |\n| • Blowup factor | • Polynomial degree | • Query complexity |\n\nThe security of a STARK proof relies on two key mechanisms:\n\n1. **Domain Extension (Blowup)**: The composition polynomial is evaluated over a domain that's `b` times larger than the original trace length, where `b` is the blowup factor.\n\n2. **Low-Degree Testing**: The FRI protocol ensures that the polynomial being tested is close to a valid low-degree polynomial.\n\nThe soundness error (probability of accepting an invalid proof) is bounded by:\n\n```\nPr[undetected cheat] = (1/b)^q\n```\n\nwhere:\n- `b` is the blowup factor (e.g., 8 in our example)\n- `q` is the number of queries made by the verifier\n\nThis means that if a prover tries to cheat by modifying a fraction 1/b of the domain, the verifier will detect this with probability at least 1 - (1/b)^q. For example, with a blowup factor of 8 and 10 queries, the soundness error is at most (1/8)^10 ≈ 0.0000001.\n\n## 7. Project Structure\n\nThe codebase is organized into logical components:\n\n| Math | VM | Library |\n|------|----|---------|\n| • Polynomial | • Constraints | • Entry point |\n| • Domain | • Trace | • Public API |\n| • FRI | • Execution | • Documentation |\n| • STARK | | |\n\n\n### 8. Current Features\n\n| Constraint System | FRI Protocol | Mathematical Operations |\n|------------------|--------------|------------------------|\n| • Transition constraints | • Low-degree testing | • Polynomial arithmetic |\n| • Boundary constraints | • Interactive verification | • Field operations |\n| • Quotient verification | • FRI folding layers | • Domain operations |\n\n### 9. Missing Components\n\n| Zero-Knowledge | Merkle Commitments | Fiat-Shamir Transform |\n|----------------|-------------------|----------------------|\n| • Trace privacy | • Tree structure | • Deterministic hashing |\n| • State protection | • Proof generation | • Non-interactive |\n\nWhile we have a working STARK implementation with quotient polynomial verification, it's not yet a full zero-knowledge system. The main limitations are:\n\n1. We're using random number generation instead of the Fiat-Shamir transform, making the protocol interactive.\n2. The proof system lacks Merkle commitments for the FRI layers, which are essential for zero-knowledge properties. - instead all evaluations are passed to the verifier. This will be addressed soon.\n\nTo achieve full zero-knowledge capabilities, we need to:\n- Implement Merkle tree commitments for the FRI layers\n- Replace random number generation with deterministic hashing (Fiat-Shamir transform)\n- Add trace blinding and random masks to the composition polynomial\n- Optimize the proof generation and verification process\n\n### 10. Next Steps\n\n1. **Merkle Commitments**\n   - Implement Merkle tree structure for FRI layers\n   - Add commitment verification in the FRI protocol\n   - Optimize commitment size and verification time\n\n2. **Fiat-Shamir Transform**\n   - Replace random number generation with deterministic hashing\n   - Implement transcript-based challenge generation\n   - Ensure security properties of the transform\n\n3. **Constraint System Improvements**\n   - Add higher-level abstractions for constraint definition\n   - Implement more complex constraint types\n   - Optimize constraint evaluation\n\n4. **Zero-Knowledge Properties**\n   - Add trace blinding\n   - Implement random masks for the composition polynomial\n   - Ensure privacy of witness data\n\n5. **Random Linear Combinations**\n   - Add random linear combinations to the constraint polynomial\n\n## 11. Contributing\n\nWe welcome contributions to Toyni! Our current focus is on implementing zero-knowledge properties and improving the overall system. We're particularly interested in:\n\n1. Implementing Merkle tree commitments and the Fiat-Shamir transform\n2. Adding comprehensive test coverage and security audits\n3. Improving documentation and adding more examples\n4. Optimizing performance and reducing proof sizes\n\n# 12. Associated With\n\n\u003cdiv align=\"center\"\u003e\n\n| \u003ca href=\"https://timewave.computer/\"\u003e\u003cimg src=\"https://timewave.computer/assets/logo.png\" width=\"80\" height=\"80\" alt=\"Timwave Computer\"\u003e\u003c/a\u003e | \u003ca href=\"https://ciphercurve.com\"\u003e\u003cimg src=\"https://ciphercurve.com/logo02.png\" width=\"200\" height=\"50\" alt=\"Ciphercurve\"\u003e\u003c/a\u003e |\n|:---:|:---:|\n| [Timwave Computer](https://timewave.computer/) | [Ciphercurve](https://ciphercurve.com) |\n\n\u003c/div\u003e\n\n---\n\n\u003cdiv align=\"center\"\u003e\n  \u003ch3\u003e2025 Ciphercurve, Timewave Computer\u003c/h3\u003e\n  \u003cp\u003e\u003cem\u003eBuilding the future of privacy-preserving computation\u003c/em\u003e\u003c/p\u003e\n\u003c/div\u003e\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fciphercurve%2Ftoyni","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fciphercurve%2Ftoyni","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fciphercurve%2Ftoyni/lists"}