Migrate to orchard 0.13 + librustzcash zcash/main#22
Merged
Conversation
Drops every reference to the retired valargroup/librustzcash and valar-orchard forks and pins to the upstream rebases instead: - Workspace [patch.crates-io] now redirects orchard, voting-circuits, pczt, transparent and the four librustzcash crates to a single set of authoritative sources (valargroup/orchard valar/0.13-spend-auth-g, valargroup/voting-circuits valar/orchard-0.13, zcash/librustzcash rev 976efa76ca). The old sapling-crypto git pin is removed because sapling-crypto 0.7.0 is now published on crates.io and matches what zcash_primitives 0.27 expects. - Inner zcash_voting crate drops the `package = "valar-orchard"` rename, switches orchard to `version = "0.13"` with the new `unstable-voting-circuits` feature (required by zkp1.rs integration tests that use `Note::new`/`Note::dummy`/`Rho::from_nf_old`), and swaps every git-pinned librustzcash dep for upstream version specs that resolve through the workspace patches. - vote-commitment-tree dev-dep follows the same orchard rename cleanup. All governance librustzcash PRs (#2283, #2284, #2281) are merged upstream so the fork retires entirely; orchard 0.13 added the `unstable-voting-circuits` feature flag that exposes the same internals our valar-orchard fork carried. Made-with: Cursor
…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
…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
This was referenced 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.
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.
imt-tree 0.1.1 (just published to crates.io) now depends on halo2_gadgets 0.4 instead of 0.3, matching the rest of the orchard 0.13 stack. Updating the lockfile drops the duplicate halo2_gadgets 0.3.1 we'd been pulling transitively through the older imt-tree 0.1.0 (vote-commitment-tree depends on imt-tree).
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.
5 tasks
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
2 participants
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
Catches
zcash_votingup to the workspace-wide migration off thevalargroup/librustzcash+valar-orchardforks and onto upstreamzcash/main+orchard 0.13(with the newunstable-voting-circuitsfeature gate).The workspace
[patch.crates-io]block now redirects to a single set of authoritative sources:orchardvalargroup/orchardvalar/0.13-spend-auth-g(orchard 0.13.0 + cherry-picks of zcash/orchard #489 and #495, tracked by valargroup/orchard PR #19)7fa213aevoting-circuitsvalargroup/voting-circuitsvalar/orchard-0.13(= valargroup/voting-circuits PR #20)ec6d3adbpczt,zcash_address,zcash_encoding,zcash_keys,zcash_primitives,zcash_protocol,zcash_transparentzcash/librustzcashrev976efa76ca(zcash/main HEAD at migration time)976efa76caThe previous
valargroup/librustzcashfork (carrying shielded-voting getters inpcztand the governance helpers inzcash_*) is fully retired now that the relevant PRs (#2281, #2283, #2284) have all merged upstream. Thesapling-cryptogit pin is also gone —sapling-crypto 0.7.0is published on crates.io and matches whatzcash_primitives 0.27expects.The whole pin block collapses back to the published
orchard 0.14crate + a futurelibrustzcashrelease once both upstreamorchardPRs land.Why a separate PR?
This PR is the consumer-side companion to:
orchard 0.13.0+ SpendAuthG +NoteValue::ZEROvalar-orchard, port to orchard 0.13 public APIszcash_voting's own non-test source code didn't need API changes against the new orchard. The integration tests inzcash_voting/tests/zkp1.rs(which useNote::new,Note::dummy,Rho::from_nf_old) are why the inner crate enables the newunstable-voting-circuitsfeature.Changes
Cargo.toml([patch.crates-io])orchard,voting-circuits,pczt,zcash_address,zcash_encoding,zcash_keys,zcash_primitives,zcash_protocolandtransparent(renamed fromzcash_transparent) to the migration branches above.sapling-cryptogit pin.zcash_voting/Cargo.tomlpackage = "valar-orchard"rename.orchardtoversion = "0.13", features = ["unstable-voting-circuits"].librustzcashdep for upstream version specs that resolve through the workspace patches.vote-commitment-tree/Cargo.tomlzcash_voting/Cargo.toml.zcash_voting/README.mdvalar-orchard+valar-pczt" wording (those forks are retired) and document the currentorchard 0.13+librustzcashmainpins, including the cherry-pick / upstream PR breakdown.Cargo.lockcargo buildreproduces the exact dependency graph the migration was tested against.Test plan
cargo check --tests --workspace --all-featurescleanCargo.toml[patch.crates-io]entries and the resolved[[package]]sources inCargo.lockCargo.lockmatch the heads of the listed migration brancheszkp1.rsintegration test suite end-to-end against a live chain stackMerge sequencing
This PR depends on the heads it pins; merge in this order:
valar/0.13-spend-auth-gbranch tip stable)zcash_votingSHA, currently has a lockfile conflict withmainthat gets re-resolved against the new SHA shipped hereMade-with: Cursor
Made with Cursor