Skip to content

[Graphite MQ] Draft PR GROUP:spec_8a684e (PRs 871, 872, 873, 874, 875, 876)#908

Closed
graphite-app[bot] wants to merge 6 commits intomainfrom
gtmq_spec_8a684e_1756797190606-8218a410-f2de-48c2-a1ec-6111505e968c
Closed

[Graphite MQ] Draft PR GROUP:spec_8a684e (PRs 871, 872, 873, 874, 875, 876)#908
graphite-app[bot] wants to merge 6 commits intomainfrom
gtmq_spec_8a684e_1756797190606-8218a410-f2de-48c2-a1ec-6111505e968c

Conversation

@graphite-app
Copy link
Copy Markdown

@graphite-app graphite-app bot commented Sep 2, 2025

This draft PR was created by the Graphite merge queue.
Trunk will be fast forwarded to the HEAD of this PR when CI passes, and the original PRs will be closed.

The following PRs are included in this draft PR:

### TL;DR

Add serialization support for constraint systems to enable persistence and cross-process sharing.

### What changed?

- Implemented `SerializeBytes` and `DeserializeBytes` traits for `ConstraintSystem` and its components
- Added version tracking with `SERIALIZATION_VERSION` constant for compatibility
- Created binary reference file for testing serialization compatibility
- Added documentation for the serialization format and testing approach
- Added new dependencies: `bytes` for serialization and `rand` for testing

### How to test?

- Run the existing test suite which includes comprehensive serialization tests
- To regenerate the reference binary file:
- To verify compatibility with the reference binary:

### Why make this change?

Serialization support enables:

1. Persistence of constraint systems to disk
2. Sharing constraint systems between different processes
3. Caching compiled circuits to avoid recomputation
4. Versioning to ensure backward compatibility as the format evolves

The implementation includes careful validation during deserialization and version checking to maintain compatibility over time.
# Add PublicWitness struct for zero-knowledge proof verification

### TL;DR

Introduces a new `PublicWitness` type to represent the public portion of witness data in zero-knowledge proofs.

### What changed?

- Added a new `PublicWitness<'a>` struct that uses `Cow<'a, [Word]>` to efficiently store public witness data
- Implemented serialization/deserialization with version compatibility
- Added conversion methods from various types (`Vec<Word>`, `&[Word]`, `&ValueVec`)
- Added utility methods for accessing and manipulating the witness data
- Created a reference binary file `public_witness_v1.bin` for serialization testing
- Updated test documentation to include information about the new reference file

### How to test?

- Run the test suite to verify the implementation works correctly:
- The tests include serialization round-trips, version compatibility checks, and conversion tests

### Why make this change?

Public witness data is a critical component in zero-knowledge proof systems, representing the public inputs and constants that both provers and verifiers need to agree on. This implementation provides a standardized way to handle this data with efficient memory usage through `Cow`, allowing both borrowed and owned variants depending on the use case.
### TL;DR

Added new data structures for zero-knowledge proof serialization and improved value vector handling.

### What changed?

- Renamed `PublicWitness` to `ValuesData` to make it more generic for both public and non-public values
- Added `ValueVec::new_from_data()` method to create a value vector from separate public and private parts
- Added `ValueVec::non_public()` method to access non-public values
- Added new `Proof` data structure for serializing zero-knowledge proofs with challenger type information
- Fixed test data paths by moving files to the correct location and using `include_bytes!` instead of file I/O
- Updated documentation in test_data/README.md to reflect the new structures

### How to test?

- Run the test suite to verify serialization/deserialization works correctly:
  ```
  cargo test -p binius-core
  ```
- The tests include round-trip serialization tests for the new `Proof` structure and the renamed `ValuesData` structure
- Reference binary files are included for compatibility testing

### Why make this change?

These changes support cross-host verification of zero-knowledge proofs by providing proper serialization of proof transcripts along with challenger type information. The renamed `ValuesData` structure is more flexible, allowing it to represent both public and non-public values. The new methods on `ValueVec` enable splitting and recombining value vectors, which is useful for distributed proving scenarios where public and private inputs need to be handled separately.
# Add save subcommand to example CLI for artifact export

### TL;DR

Adds a new `save` subcommand to the examples CLI that allows exporting circuit artifacts to files.

### What changed?

- Added a new `save` subcommand to the example CLI that can export:
    - Constraint system binary
    - Public witness values
    - Non-public data values
- Implemented a helper function `write_serialized` to handle serialization and file writing
- Updated the README with documentation for all CLI subcommands, including detailed usage examples for the new `save` command

### How to test?

Run any example with the new save subcommand:

```
# Save only the constraint system
cargo run --release --example my_circuit -- save --cs-path out/cs.bin

# Save public values and non-public values
cargo run --release --example my_circuit -- save \
    --pub-witness-path out/public.bin \
    --non-pub-data-path out/non_public.bin

# Save all three artifacts
cargo run --release --example my_circuit -- save \
    --cs-path out/cs.bin \
    --pub-witness-path out/public.bin \
    --non-pub-data-path out/non_public.bin
```

### Why make this change?

This change enables developers to export circuit artifacts for external analysis, debugging, or integration with other tools. The ability to save constraint systems and witness data separately provides flexibility for different workflows and testing scenarios.
### TL;DR

Added a standalone prover binary example that can generate proofs from serialized constraint systems and witnesses.

### What changed?

- Added a new `prover` example binary that reads a constraint system and witness data from disk and produces a serialized proof
- Implemented a `From<ValuesData<'a>>` trait for `Vec<Word>` to simplify conversion of witness data
- Updated the examples README with documentation for the new prover binary, including usage instructions
- Added the binary to the examples crate manifest

### How to test?

1. Generate artifacts from an example circuit:

```
cargo run --release --example sha256 -- save \
    --cs-path out/sha256/cs.bin \
    --pub-witness-path out/sha256/public.bin \
    --non-pub-data-path out/sha256/non_public.bin
```

1. Produce a proof using the new prover binary:

```
cargo run --release --example prover -- \
    --cs-path out/sha256/cs.bin \
    --pub-witness-path out/sha256/public.bin \
    --non-pub-data-path out/sha256/non_public.bin \
    --proof-path out/sha256/proof.bin \
    --log-inv-rate 1
```

### Why make this change?

This change enables cross-host proof generation pipelines by providing a standalone binary that can generate proofs from serialized inputs. This is useful for scenarios where the constraint system is generated on one machine but the proof needs to be generated on another, potentially more powerful machine optimized for proving.
### TL;DR

Add a verifier binary to verify the serialized proofs using the serialized constraint system and public witness data.

### What changed?

- Added a new `verifier` example binary that reads a constraint system, public witness, and proof from disk and verifies the proof
- Updated `Cargo.toml` to include the new verifier example
- Added documentation for the verifier binary in the README, including usage instructions and command-line arguments

### How to test?

Run the verifier on a proof generated by the prover example:

```
# First generate a proof with the prover
cargo run --release --example prover -- \
    --cs-path out/sha256/cs.bin \
    --pub-witness-path out/sha256/public.bin \
    --priv-witness-path out/sha256/private.bin \
    --proof-path out/sha256/proof.bin \
    --log-inv-rate 1

# Then verify the proof
cargo run --release --example verifier -- \
    --cs-path out/sha256/cs.bin \
    --pub-witness-path out/sha256/public.bin \
    --proof-path out/sha256/proof.bin \
    --log-inv-rate 1
```

### Why make this change?

This completes the example workflow by providing a way to verify proofs generated by the prover example. The verifier demonstrates how to load and verify proofs, including checking that the challenger type in the proof matches the verifier's expected challenger type (HasherChallenger\<Sha256>).
@graphite-app graphite-app bot closed this Sep 2, 2025
@graphite-app graphite-app bot deleted the gtmq_spec_8a684e_1756797190606-8218a410-f2de-48c2-a1ec-6111505e968c branch September 2, 2025 07:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant