feat: generalize monad in SigmaProtocol - #418
Conversation
🤖 PR SummaryMathematical Formalization
Refactoring
Statistics
Lean Declarations ✏️ **Affected:** 10 declaration(s) (line number changed)
📋 **Additional Analysis**The pull request performs a significant refactoring of the 📄 **Per-File Summaries**
Last updated: 2026-06-24 13:05 UTC. |
# Conflicts: # VCVio/CryptoFoundations/FiatShamir/Sigma/Fork.lean # VCVio/CryptoFoundations/FiatShamir/Sigma/Reductions.lean # VCVio/CryptoFoundations/FiatShamir/Sigma/Stateful/Bridge.lean # VCVio/CryptoFoundations/FiatShamir/Sigma/Stateful/Chain.lean # VCVio/CryptoFoundations/FiatShamir/Sigma/Stateful/Compatibility.lean # VCVio/CryptoFoundations/Fischlin.lean # VCVio/CryptoFoundations/SigmaProtocol.lean
This PR generalizes the monad in SigmaProtocol from ProbComp to any monad
m, and adds a field for a monadic challenge sampling procedure. Call sites get HasEvalSPMF m, or are specified to use the ProbComp monad where that's necessary.This is part of an attempt to generalize SigmaProtocol enough to express the Kilian transformation as returning a SigmaProtocol. This might also require separating out the extractor so I can define non-special soundness, and making the verifier possibly non-deterministic.
I am still not quite sure if this is a good change - I want to understand better to what degree these generalizations can be pushed through downstream without compromising proofs (although perhaps it is a good change even if it can't be pushed through for the existing code, because future code might be able to take advantage of the generalization).