Add Sp1 Feature with deserialization methods

[katiemckeon]

🔄 Pull Request

📝 Description

This PR introduces the sp1-v3 feature to sindri-rs which adds convenience methods for transforming structs between Sindri's proof request and response types and those in the sp1-sdk package.

The main new methods of interest to SP1 users are demonstrated in examples/sp1-proof/main.rs. These will automatically transform an SP1Stdin struct into Sindri proof input. Once a proof is generated, methods are introduced to turn that Sindri proof response into the SP1ProofWithPublicValues struct or help with clientside verification.

In more generality, this PR is the start of several features which make Sindri proof responses/requests more natively compatible with the rust ZK-framework a user might be interested in:

• sindri_rs::types::ProofInfo:
  • get_proof_as_serde_json: The proof field of a ProofInfoResponse has Option<Option<Value>> type. This double_option type is used to distinguish certain cases like "a proof could exist but is not ready yet, a proof exists and is null, etc." But for most processing cases, you'd like to grab the proof or an error immediately. That's what this method does.
  • get_proof_as_bytes: Proofs for a few rust-based frameworks are naturally stored as bytes (with bincode handling the packing/unpacking), but the API returns another format. For those frameworks, this method will automatically call the correct conversion back into a vec<u8>.
• extract_single_value (internal): this method introduces a unified way of handling API proof responses that may consist of a single key-value pair. For some frameworks, a proof value may be interpretable on its own, but due to some initial API constraints, we added an identifying key. This method strips the key away without having to know what it was

🔗 Related Tickets & Documents

• Related Issue Add Halo2 integration methods #6 Add Plonky2 Integration Methods #7 Add Jolt Integration Methods #8
• Closes #

📋 Type of PR (check all applicable)

• 🔨 Refactor
• ✨ Feature
• 🐛 Bug Fix
• ⚡ Optimization
• 📚 Documentation Update

💭 Developer Notes

We have found sp1-sdk to be very faithful in semver compatibility. While our backend supports 3.0.0 and sindri-rs imports 3.0.0, we have spot checked a few other minor versions successfully. Moreover, Cargo wont let us have two simultaneous minor versions of Sp1 in our crate (even for different features).

🧪 Testing Instructions

The CI workflow has been modified to test the new SP1 v3 integration feature. In the future when we have incompatible versions, we may have to test separately (and refactor default feature tests to avoid redundancy).

The new example in examples/sp1-proof does not yet have automated testing. We choose to punt on that until a more permanent GHA workflow is created for integration and example testing (requiring Sindri key secrets)

✅ Testing Status

• Yes, tests added/updated
• No tests needed because: please explain why
• Help needed with testing