Bump valar-orchard to 0.12 and voting-circuits to 0.2#20
Merged
Conversation
voting-circuits 0.2.0 is the first release that depends on valar-orchard 0.12, which carries the post-0.12.0 upstream-orchard fixes plus the governance-visibility additions that the shielded-voting Halo 2 circuits need. Staying on 0.11 leaves this crate out of step with the rest of the shielded-voting stack (vote-sdk/circuits is already on 0.12/0.2, and the librustzcash fork is moving behind valargroup/librustzcash#42), and produces duplicate valar-orchard nodes in any consumer that pulls in both. voting-circuits 0.2.0 gates share_reveal behind a feature flag that it did not enforce in 0.1.0, so the feature is requested explicitly for the existing share_tracking code path. The orchard_compat byte-round-trip bridge and the orchard_upstream dep on upstream orchard 0.11 stay in place: crates.io zcash_keys 0.12.0 and valar-pczt 0.5.1 still pin upstream orchard ^0.11, so the two-orchard problem is not yet gone. FullViewingKey and SpendingKey wire formats did not change between upstream orchard 0.11 and 0.12, so the bridge is still correct; the doc comment is tightened to say so explicitly. Collapse this bridge (and orchard_upstream) once the librustzcash fork republishes zcash_keys/valar-pczt on top of valar-orchard. halo2_proofs 0.3.0 -> 0.3.2 in Cargo.lock is forced by the halo2_gadgets 0.4.0 that valar-orchard 0.12 and voting-circuits 0.2.0 pull in: it references Error::IllegalHashFromPrivatePoint, which was only added in halo2_proofs 0.3.2. Verified: - cargo check --workspace --all-features --tests -> OK - cargo test --workspace --all-features -> 84 passed, 1 ignored (same ignored test as main), including the vote_commitment_tree <-> voting-circuits Poseidon cross-validation tests that anchor the halo2_gadgets 0.3.1 / 0.4.0 coexistence to the same halo2_poseidon output. Made-with: Cursor
p0mvn
added a commit
that referenced
this pull request
Apr 25, 2026
…voting-circuits PR #20 Companion to the previous "Migrate to orchard 0.13 + librustzcash zcash/main" commit (which only flipped the Cargo.toml [patch.crates-io] entries). This commit catches the lockfile and the surrounding documentation up to where the orchard / voting-circuits stack actually lives now. * Cargo.lock — regenerated against the git URL pins so a fresh `cargo build` reproduces the exact dep graph that the migration was tested against: orchard 7fa213ae valargroup/orchard valar/0.13-spend-auth-g = orchard 0.13.0 + cherry-picks of zcash/orchard #489 (SpendAuthG fixed-base multiplication) + zcash/orchard #495 (NoteValue::ZERO public associated constant) (tracked by valargroup/orchard PR #19) voting-circuits ec6d3adb valargroup/voting-circuits valar/orchard-0.13 (= valargroup/voting-circuits PR #20 head) pczt / zcash_address / zcash_encoding / zcash_keys / zcash_primitives / zcash_protocol / zcash_transparent 976efa76ca zcash/librustzcash main (commit-pinned) * Cargo.toml + zcash_voting/Cargo.toml — comments now mention both zcash/orchard #489 and #495, tracked by valargroup/orchard PR #19, instead of just #489. No semantic change. * zcash_voting/README.md — drop the "depends on valar-orchard + valar-pczt" wording (those forks are retired), replace with the current pin: orchard 0.13 + valargroup/orchard PR #19 (carrying zcash/orchard #489 + #495), plus a librustzcash commit-pin pointing at zcash/main now that PRs #2281 / #2283 / #2284 are merged upstream. Notes that the pin collapses back to the published `orchard 0.14` crate + a librustzcash release once both upstream PRs land. Verification: * `cargo check --tests --workspace --all-features` clean. * No drift between Cargo.toml [patch.crates-io] entries and the resolved [[package]] sources in Cargo.lock. Made-with: Cursor
p0mvn
added a commit
that referenced
this pull request
Apr 25, 2026
…ts PR #20 head) valargroup/voting-circuits PR #20 was rewritten/force-pushed since the previous lockfile bump in this branch, so the `ec6d3adb` SHA the lock referenced is no longer reachable on the PR. Re-resolve the `branch = "valar/orchard-0.13"` patch entry and pick up the current two-commit PR head: voting-circuits ec6d3adb → 84726847 = valargroup/voting-circuits commits 1d5a455 Drop vendored valar-orchard 0.12 fork; depend on orchard 0.13 via git 8472684 Migrate to orchard 0.13 public APIs (NoteValue::ZERO, Nullifier accessors, local assign_constant) = valargroup/voting-circuits#20 No source or Cargo.toml changes — strictly a lockfile pin bump so a fresh `cargo build` against this branch resolves to the actual head of the upstream PR rather than a force-pushed-out SHA. Verification: * `cargo check --tests --workspace --all-features` clean. * No drift between Cargo.toml [patch.crates-io] entries and the resolved [[package]] sources in Cargo.lock. Made-with: Cursor
greg0x
added a commit
that referenced
this pull request
Apr 25, 2026
The assertion was hardcoded to 12 in the test's initial commit, but the
delegation circuit's `to_halo2_instance()` has produced 13 inputs since
voting-circuits was split out of the monorepo, and 14 since the
ZIP-1199 alignment commit added the `dom` public input
(`Poseidon("governance authorization", vote_round_id)`) used by the
alternate-nullifier hash. voting-circuits' own MockProver test in
`delegation/circuit.rs` correctly asserts 14.
The test is `#[ignore]`'d, so the stale assertion never tripped in CI;
it surfaced when the orchard 0.13 / librustzcash zcash/main migration
made the surrounding workspace build clean enough to actually run
`--ignored` end-to-end again.
The proof itself generates and verifies correctly under the new orchard
0.13 + voting-circuits PR #20 dep graph; only the count assertion
needed adjusting.
greg0x
added a commit
that referenced
this pull request
Apr 25, 2026
Aligns this repo's direct deps with the rest of the migration: orchard 0.13 and voting-circuits PR #20 already use halo2_gadgets 0.4. After this bump, imt-tree 0.1.0 (transitive via vote-commitment-tree) is the only remaining 0.3 contributor in the lockfile — separate follow-up in vote-nullifier-pir. The bump is purely a Cargo.toml edit: the only halo2_gadgets surface this crate uses is `halo2_gadgets::poseidon::primitives::*`, which in both 0.3.1 and 0.4.0 is `pub use ::halo2_poseidon as primitives` — a re-export of the standalone halo2_poseidon 0.1.0 crate (single version in the graph). So the imported types are identical regardless of which halo2_gadgets we go through.
greg0x
added a commit
that referenced
this pull request
Apr 25, 2026
Now that valargroup/orchard PR #19 and valargroup/voting-circuits PR #20 are merged, repoint both from migration branches to the respective merge commits on main: - orchard → c26a6ec6 (PR #19 merge) - voting-circuits → 66777e27 (PR #20 merge) Retires the valar/0.13-spend-auth-g and valar/orchard-0.13 branch refs as manifest dependencies in favor of deterministic rev pins.
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
1 participant
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
valar-orchard0.11.0 → 0.12.0 andvoting-circuits0.1.0 → 0.2.0 in bothzcash_votingand thevote-commitment-treedev-deps.orchard_compatbyte-round-trip bridge (and theorchard_upstreamdep on upstreamorchard 0.11) — crates.iozcash_keys 0.12.0andvalar-pczt 0.5.1still pin upstreamorchard ^0.11, so the two-orchard problem is not yet gone.FullViewingKey/SpendingKeywire formats did not change between upstream orchard 0.11 and 0.12, so the bridge is still correct; the doc comment is tightened to say so explicitly.Why
voting-circuits 0.2.0is the first release that depends onvalar-orchard 0.12, which carries the post-0.12.0 upstream-orchard fixes plus the governance-visibility additions the shielded-voting Halo 2 circuits need. Staying on 0.11 leaves this crate out of step with the rest of the shielded-voting stack —vote-sdk/circuitsis already on 0.12/0.2, and the librustzcash fork is moving behind valargroup/librustzcash#42 — and produces duplicatevalar-orchardnodes in any consumer that pulls in both.voting-circuits 0.2.0gatesshare_revealbehind a feature flag it did not enforce in 0.1.0, so the feature is requested explicitly for the existingshare_trackingcode path.Lockfile
halo2_proofs 0.3.0 → 0.3.2is forced by thehalo2_gadgets 0.4.0thatvalar-orchard 0.12andvoting-circuits 0.2.0pull in: it referencesError::IllegalHashFromPrivatePoint, which was only added inhalo2_proofs 0.3.2.halo2_gadgets 0.3.1stays in the graph for upstream orchard 0.11,imt-tree,vote-commitment-tree, and this crate — both versions resolve to the sharedhalo2_poseidon 0.1, which is why the cross-validation tests below pass.Follow-up (out of scope)
Collapse the
orchard_compatbridge and drop theorchard_upstreamdep once the librustzcash fork republisheszcash_keys/valar-pczton top ofvalar-orchard.Test plan
cargo check --workspace --all-features --tests→ OKcargo test --workspace --all-features→ 84 passed, 0 failed, 1 ignored (zkp1::tests::test_real_delegation_proof, already ignored on main)halo2_gadgetsversions agree on thehalo2_poseidon 0.1output:vote_commitment_tree::tests::test_vote_commitment_hash_cross_validates_with_orchardvote_commitment_tree::tests::test_domain_vc_matches_orchardzcash_voting::elgamal::tests::test_cross_validation_with_circuit_helperNote:
cargo clippy --workspace --all-features --all-targets -- -D warningsfails with 22 + 29 errors, but the same errors reproduce onmainwithout any of this branch's changes (verified withgit stash). These are pre-existing lints (needless_range_loop,manual_memcpy,too_many_arguments, etc.) and are not introduced by this bump; CI (lockfile.yml) does not run clippy.Made with Cursor