We need to clarify which inputs are required by the CRISP proof verifier on-chain and how each of them should be provided or retrieved from the existing contracts. The goal is to ensure consistency between the proof generation off-chain and the verification logic on-chain.
Public inputs:
prev_ct → Already stored in the Validator contract inside the voteSlots mapping. It can be retrieved directly from the slot associated with the voter.params → Static BFV parameters. These are deployed with the program, and in principle, they could be hardcoded inside the circuit for efficiency.public_key → Published for every E3 request. We should check if it can be retrieved on-chain or if only a commitment should be stored instead.merkle_root → Can be retrieved from the Validator contract.slot_address → Passed explicitly with the proof.is_first_vote → Can be derived on-chain: if the slot is empty, pass true; otherwise, false.
This issue depends on: #983
We need to clarify which inputs are required by the CRISP proof verifier on-chain and how each of them should be provided or retrieved from the existing contracts. The goal is to ensure consistency between the proof generation off-chain and the verification logic on-chain.
Public inputs:
prev_ct→ Already stored in the Validator contract inside thevoteSlotsmapping. It can be retrieved directly from the slot associated with the voter.params→ Static BFV parameters. These are deployed with the program, and in principle, they could be hardcoded inside the circuit for efficiency.public_key→ Published for every E3 request. We should check if it can be retrieved on-chain or if only a commitment should be stored instead.merkle_root→ Can be retrieved from the Validator contract.slot_address→ Passed explicitly with the proof.is_first_vote→ Can be derived on-chain: if the slot is empty, pass true; otherwise, false.This issue depends on: #983