[ZIP TBD] Shielded Voting Protocol#1200
Open
p0mvn wants to merge 58 commits into
Open
Conversation
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
The VAN commitment formula was written as a single 7-input Poseidon hash, but the implementation uses two separate invocations: ConstantLength<6> for the structural fields, then ConstantLength<2> to fold in the commitment randomness. These produce different outputs because each layer finalizes with its own padding before the next begins. Split the formula into two steps in all four places it appears: the VAN data structure definition, VAN integrity in the Delegation Proof, and old/new VAN integrity in the Vote Proof.
The Share Reveal circuit has 7 public inputs with no anchor_height — only the Vote Proof (ZKP #2) includes it. The tree root alone is sufficient to anchor to a specific tree state. Removed from three places: the Vote Reveal Proof public inputs list, the out-of-circuit verification step, and the Share Reveal Message table.
The circuit constrains only the x-coordinates of the El Gamal ciphertext (two field elements), not full curve points. The full points are carried in the share reveal message for homomorphic accumulation during tally, but the ZKP only needs x-coordinates for the Poseidon-based share commitment binding. Using full points as public inputs would double the instance cells for no security gain, and an implementer following the old spec literally would produce an incompatible circuit.
Shielded voting ZIP: fix spec-vs-implementation discrepancies Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
…are mode - Phase 3/4 summary: client-chosen submit_at, last-moment single-share - Share Submission Payload: add submit_at field - Why N_s Shares: add single-share last-moment exception and rationale
Voting protocol ZIP: client-controlled timing and single-share mode
b806764 to
1df97ea
Compare
The voting round identifier was used as an opaque Pallas scalar input to several Poseidon constructions in this ZIP (van_core, vc, van_nullifier, gov_null_i, ρ_signed, the Vote Reveal Proof public inputs) without ever being defined. Specify it as a deterministic Poseidon hash over the eight setup-field inputs that uniquely characterise a round. Place the new subsection at the top of the Data Structures section, before Vote Authority Note, since voting_round_id is the most foundational data structure: every other on-chain construction in this ZIP takes it as an input. Reference the canonical Poseidon Instantiation section for the parameter set and add a row for the new hash to its inventory table. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
18 tasks
aphelionz
reviewed
May 27, 2026
aphelionz
left a comment
Member
There was a problem hiding this comment.
Some preliminary comments, didn't get through all of it just yet
| converts proven Orchard balance into a Vote Authority Note on a | ||
| purpose-built vote chain. Second, a *vote proof* consumes a VAN to | ||
| produce a Vote Commitment containing $N_s$ El Gamal-encrypted shares of | ||
| the voter's ballot count, split across vote options. Third, a *vote |
Member
There was a problem hiding this comment.
This is the first time I'm seeing this term so I'm unclear whether this means the quesdtions on the ballot, the choices per question, or something else. It might be helpful to add "vote option" to Terminology.
Comment on lines
+145
to
+148
| The protocol is motivated by coinholder governance in the Zcash | ||
| ecosystem, where participants vote on proposals weighted by their ZEC | ||
| holdings. The same mechanism applies to any stake-weighted polling system | ||
| over an Orchard-like shielded pool. |
Member
There was a problem hiding this comment.
This section should acknowledge that coinholder polling is but one of many polls including ZCAP and the Engineering Caucus, etc...
aphelionz
reviewed
Jun 2, 2026
| **Balance hiding via vote splitting.** A voter's total ballot count is | ||
| decomposed into $N_s$ shares encrypted under the election authority's | ||
| public key. Each share is submitted independently (potentially via | ||
| different submission servers at randomized delays), preventing an |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR introduces Shielded Voting Protocol — a complete specification for stake-weighted governance voting over the Zcash Orchard shielded pool. Holders prove their ZEC balance via the Orchard Proof-of-Balance and cast votes without revealing their identity, individual balances, or vote allocations.
This is the core governance ZIP in the approved ZIP breakdown, building on two previously submitted ZIPs:
Protocol at a glance
The protocol proceeds in five phases:
Key privacy properties
nkTest plan
make draft-valargroup-shielded-voting.htmlmake linkcheckpasses for cross-references to Balance Proof, Nullifier PIR, and EA Key Ceremony ZIPs