Research Directions
This page describes active and planned research areas that may influence Specter's protocol evolution. These are not committed roadmap items — they are directions being investigated, with varying levels of maturity. Some may be adopted in future protocol upgrades; others may prove impractical or unnecessary.
Recursive Proofs
Problem
Currently, each Summon (reveal) operation requires independent on-chain verification of a Groth16 proof. When batch operations process N reveals, the verifier must check N proofs, each costing approximately 200K gas. Verification cost scales linearly with batch size.
Research Direction
Recursive proof composition allows a prover to generate a single proof that attests: "I have verified N inner proofs, and all of them are valid." The on-chain verifier checks only the outer proof — a constant cost regardless of N.
Challenges
- Cycle of curves: Recursive verification requires that the proof system's verification algorithm can be efficiently expressed in its own circuit. For BN254-based Groth16, this requires either a cycle of pairing-friendly curves or a different inner proof system.
- Proof generation time: Recursive proofs are computationally expensive to generate. The aggregation step may take minutes for large batches.
- Complexity: Recursive proof circuits are significantly more complex than the base circuits, increasing the audit surface.
Potential Impact
If feasible, recursive proofs reduce batch verification cost from O(N) to O(1), enabling orders-of-magnitude improvement in throughput for high-volume use cases like bulk credential issuance or mass token distribution.
PLONK/Halo2 Migration
Problem
Groth16 requires a circuit-specific trusted setup ceremony. Every time a circuit is modified — even a minor change to the constraint system — a new trusted setup is required. This imposes significant operational overhead and ceremony logistics for each protocol upgrade.
Research Direction
PLONK and Halo2 are proof systems that use a universal and updatable structured reference string (SRS):
| Property | Groth16 | PLONK | Halo2 |
|---|---|---|---|
| Setup type | Circuit-specific | Universal (one-time) | No trusted setup (transparent) |
| Proof size | ~128 bytes (3 group elements) | ~400-800 bytes | ~400-800 bytes |
| Verification time | ~1ms (1 pairing check) | ~3-5ms | ~5-10ms |
| Prover time | Fast | Moderate | Moderate-slow |
| Circuit changes | Require new setup | Reuse existing SRS | No setup at all |
- PLONK with a universal SRS means one trusted setup ceremony supports all circuits, now and in the future. Circuit upgrades do not require new ceremonies.
- Halo2 eliminates the trusted setup entirely using an inner product argument (IPA). No toxic waste. No ceremony. Fully transparent.
Challenges
- Proof size increase: PLONK/Halo2 proofs are 3-6x larger than Groth16 proofs, increasing on-chain storage and verification gas costs.
- Verification cost: On-chain verification is more expensive without pairing-based optimizations.
- EVM compatibility: Efficient on-chain verification of PLONK/Halo2 proofs may require custom precompiles or significant gas investment.
- Migration complexity: Changing the proof system requires replacing all circuits, verifier contracts, and client-side proving logic.
Potential Impact
Eliminating the trusted setup requirement removes the single most operationally complex and trust-sensitive component of the protocol. It also enables rapid circuit iteration — bug fixes and optimizations can be deployed without ceremony overhead.
Lattice-Based ZK Proofs
Problem
Specter's current defense-in-depth against quantum computers relies on the Keccak-256 quantum commitment layer — a symmetric primitive that provides 128-bit post-quantum security for commitment binding. However, the ZK proof system itself (Groth16 on BN254) is not quantum-resistant. A quantum adversary could forge proofs.
Research Direction
Lattice-based ZK proof systems derive their security from the hardness of lattice problems (Learning With Errors, Short Integer Solution), which are believed to be resistant to both classical and quantum attacks.
Challenges
- Proof size: Current lattice-based ZK proofs are orders of magnitude larger than Groth16 proofs (kilobytes to megabytes vs. 128 bytes).
- Prover efficiency: Lattice-based proving is significantly slower than Groth16.
- Maturity: Lattice-based ZK systems are in early research stages. No production-grade implementation exists with the efficiency required for on-chain verification.
- Hash function compatibility: Lattice-friendly hash functions may be required to replace Poseidon, adding migration complexity.
Potential Impact
Full quantum resistance across the entire proof stack — not just the commitment layer. This would make Specter's privacy guarantees robust against any future quantum advancement.
Private Smart Contract Execution
Problem
Currently, Specter's privacy guarantees cover data commitments and reveals — you can commit arbitrary data (credentials, tokens, keys, images) and prove properties about that data without revealing it. However, arbitrary computation on private data is not supported. If you want to execute a smart contract function on private inputs and get a private output, the current protocol cannot do this.
Research Direction
Private smart contract execution extends the ZK proof paradigm from proving properties of committed data to proving correct execution of arbitrary programs on private inputs.
Approaches under investigation:
| Approach | Description | Maturity |
|---|---|---|
| zkVM | A virtual machine where every instruction is proven in ZK. Compile contracts to zkVM bytecode; execution produces a proof of correct computation. | Active research (RISC Zero, SP1, Valida) |
| Circuit compilation | Compile specific smart contract functions into ZK circuits. Each function has a dedicated circuit that proves correct execution. | Moderate maturity (Circom, Noir) |
| MPC-based | Multiple parties compute a function on their combined private inputs without revealing those inputs to each other. | Mature for specific applications |
Challenges
- General-purpose zkVM performance: Proving arbitrary computation in ZK is orders of magnitude slower than native execution. A simple ERC-20 transfer might take minutes to prove.
- Contract language changes: Developers may need to use ZK-specific languages (Noir, Leo) rather than Solidity.
- Composability: Private contract state must compose with public contract state, requiring careful interface design.
- Verification cost: On-chain verification of general-purpose computation proofs is significantly more expensive than verifying specialized circuits.
Potential Impact
Private smart contract execution would transform Specter from a data privacy protocol into a private computation platform — enabling use cases like private DEX trading, private governance voting, private credential verification with complex logic, and private machine learning inference.
Enhanced Anonymity Sets
Problem
The anonymity set for a given reveal is the set of all commitments in the Merkle tree that the reveal could plausibly correspond to. Larger anonymity sets provide stronger privacy. Currently, the anonymity set is limited to commitments on the Specter chain within a single Merkle tree (or shard).
Research Direction
Two complementary approaches to expanding anonymity sets:
1. Cross-Chain Anonymity Set Sharing
If commitments exist on multiple chains (Specter, Ethereum L2s, other Cosmos chains), a reveal on one chain could prove membership in a cross-chain Merkle tree that includes commitments from all chains. This dramatically increases the anonymity set.
2. Time-Delayed Reveals
Enforcing a minimum delay between commit and reveal (already partially supported via time-lock policies) ensures that additional commitments accumulate before any reveal occurs, guaranteeing a minimum anonymity set size.
Challenges
- Cross-chain root synchronization: Maintaining a consistent view of multiple chains' Merkle roots requires reliable cross-chain communication with low latency.
- Proof complexity: Cross-chain Merkle membership proofs are more complex than single-chain proofs, increasing circuit size and proving time.
- Time-delay trade-off: Longer delays improve anonymity but degrade user experience. Finding the right balance requires empirical analysis.
Potential Impact
Cross-chain anonymity sets could provide anonymity set sizes orders of magnitude larger than any single chain, approaching the aggregate privacy of the entire cross-chain ecosystem.
Formal Verification
Problem
Specter's correctness guarantees currently rely on testing, auditing, and code review. These approaches find many bugs but cannot prove the absence of all bugs. For a protocol handling private data and value, stronger guarantees are desirable.
Research Direction
Formal verification uses mathematical proof to verify that the implementation matches its specification:
| Target | What Is Verified | Tool Candidates |
|---|---|---|
| Circuit constraints | Every valid proof corresponds to a valid witness; every invalid witness produces no valid proof | Ecne, Picus, manual Lean/Coq proofs |
| Solvency invariants | The total value committed minus the total value revealed equals the expected outstanding balance at all times | Certora, Halmos |
| Nullifier uniqueness | No two distinct reveals can produce the same nullifier; no single commitment can be revealed twice | Circuit-level formal proof |
| Merkle tree consistency | The on-chain tree state is always a valid Merkle tree with correct root computation | Contract-level formal verification |
| Policy composability | Composed policies enforce the intersection of their individual constraints, not a weaker condition | Property-based specification |
Challenges
- Specification effort: Writing a formal specification is as difficult as writing the implementation. Errors in the specification are as dangerous as errors in the code.
- Tooling maturity: Formal verification tools for ZK circuits are nascent. Most mature tools target smart contracts (Solidity/EVM), not Circom/R1CS.
- Ongoing maintenance: Every code change requires updating the formal proofs, adding significant development overhead.
Potential Impact
Formal verification provides the highest possible assurance of correctness. For a privacy protocol, where bugs can silently leak data or enable theft, this level of assurance is exceptionally valuable. Even partial formal verification (e.g., proving the circuit constraints are sound) would significantly strengthen the protocol's security story.
Research Prioritization
| Direction | Impact | Feasibility (Near-Term) | Priority |
|---|---|---|---|
| Recursive proofs | High (scaling) | Moderate | High |
| PLONK/Halo2 migration | High (operational) | Moderate | High |
| Formal verification | High (security) | Moderate | High |
| Enhanced anonymity sets | High (privacy) | Moderate | Medium |
| Lattice-based ZK proofs | Critical (quantum) | Low | Medium (long-term) |
| Private smart contract execution | Transformative | Low | Low (long-term) |
Priorities are based on the combination of impact and near-term feasibility. Recursive proofs and PLONK/Halo2 migration are highest priority because they address immediate operational and scaling challenges. Lattice-based proofs and private execution are long-term research investments.