Client-side zero-knowledge range proof for anonymous vote weights

[Ehonrie]

Difficulty: Expert
Category: Feature

Context: Currently, weight validity (0 <= weight <= maxWeight, no double-counting) for anonymous votes is enforced purely by trusting Tansu.proof()'s on-chain commitment check (InvalidProof = 501, TallySeedError = 500 in errors.rs) after the fact, at reveal time — voters get no way to prove their submitted encrypted weight was in-range at vote-submission time without revealing it. Adding a client-generated range proof would let the contract (or auditors) reject invalid votes at submission rather than discovering the issue only at tally.

// dapp/src/utils/anonymousVoting.ts
export interface RangeProof {
  commitment: string;
  proof: string; // serialized Bulletproof or equivalent
}

export async function generateVoteWeightRangeProof(
  weight: number,
  maxWeight: number,
  blindingFactor: Uint8Array,
): Promise<RangeProof> {
  // !todo: Research and implement a zero-knowledge range proof (e.g. Bulletproofs,
  //        or a simpler bit-decomposition Sigma protocol) proving 0 <= weight <= maxWeight
  //        WITHOUT revealing weight, over a commitment compatible with contract_dao.rs's
  //        existing commitment/proof verification (build_commitments_from_votes).
  // !todo: Must produce a proof verifiable on-chain within Soroban's resource/instruction
  //        budget (research typical Bulletproof verification cost vs. Soroban limits first).
  // !todo: Must integrate with the existing InvalidProof (501) / BadCommitment (208)
  //        contract error semantics rather than introducing a parallel verification path.
  // !todo: Reference: Bunz et al., "Bulletproofs: Short Proofs for Confidential Transactions and More" (2018).
  throw new Error("Not implemented");
}

What contributors need to know:

• Problem: no client-side proof-of-validity exists prior to reveal; contract_dao.rs's proof entrypoint and errors.rs's TallySeedError/InvalidProof/BadCommitment codes only validate at reveal time.
• Related code: contract_dao.rs (build_commitments_from_votes, referenced in contractErrors.ts:28), crypto.ts.
• Suggested approach: this needs real cryptographic research — evaluate whether a full Bulletproof implementation is feasible within Soroban's WASM cost model, or whether a cheaper interactive/Fiat-Shamir range check suffices for this threat model.
• Acceptance criteria: a design doc covering the chosen scheme's on-chain verification cost (estimated against test_cost_estimates.rs patterns) plus a working client-side proof generator with unit tests; full contract-side verification integration may be scoped as a follow-up.