Threshold decryption committee for anonymous vote reveal

[Ehonrie]

Difficulty: Research-Required
Category: Feature

Context: Building directly on the architectural gap of a single-key anonymous-vote reveal, this issue is the end-to-end feature implementation: a t-of-n committee of designated members must jointly produce a decryption capability for a proposal's anonymous votes, so no single member (or the initial key generator) can unilaterally reveal or delay revealing the tally.

// dapp/src/utils/thresholdReveal.ts (new)
export interface DecryptionShare {
  memberAddress: string;
  partialDecryption: string;
  proofOfCorrectness: string; // NIZK proving the share was computed correctly
}

export async function combineDecryptionShares(
  ciphertext: string,
  shares: DecryptionShare[],
  threshold: number,
): Promise<string /* plaintext */> {
  // !todo: Implement share combination for a threshold decryption scheme, verifying each
  //        share's proofOfCorrectness before combining (reject malicious/malformed shares).
  // !todo: Must integrate with contract_dao.rs's committee/member-list concept
  //        (likely needs a new on-chain "reveal committee" registration, flag as
  //        a contract-side follow-up if out of scope here).
  // !todo: Must handle the case where fewer than threshold honest shares are submitted
  //        by the voting deadline (reveal permanently blocked — document the failure mode).
  // !todo: Reference: Pedersen (1991) "A Threshold Cryptosystem without a Trusted Party".
  throw new Error("Not implemented");
}

What contributors need to know:

• Problem: builds on the key-management research issue for threshold cryptography; this issue is the reveal-flow feature itself.
• Related code: contract_dao.rs's proof/anonymous voting entrypoints, contract_membership.rs for existing member/committee concepts to potentially reuse.
• Suggested approach: treat this as a two-phase deliverable — phase 1 client-side share combination against a simulated committee, phase 2 (flag as follow-up) on-chain committee registration.
• Acceptance criteria: a simulated t=3,n=5 committee where any 3 honest shares correctly reconstruct the plaintext, and fewer than 3 (or shares with invalid proofs) correctly fail closed.