Hi all,
Grant application (GitHub): [https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/311\]
I want to share an idea and a working proof of concept, and get feedback from the community and @ZcashGrants before this goes through review.
THE GAP: PCZT (Partially Created Zcash Transactions) is now the basis for hardware wallets, multisig, and air-gapped signing, and several teams are implementing it independently (OneKey, Ledger, Hito, Keystone, and the reference code in librustzcash). But there is no shared way to confirm these implementations interoperate. The `pczt` crate has a single end-to-end test where librustzcash plays every role, and `zcash-test-vectors` has no PCZT vectors at all. So a serialization or role-handling mismatch between two implementations would only show up when a real user tries to move funds between them.
THE PROPOSAL: Build an open-source cross-implementation test suite for PCZT: canonical serialized test vectors contributed to `zcash-test-vectors`, plus a harness that runs the create then sign then finalize flow across implementations through a small adapter, with per-role diagnostics. This is the same idea BIP-174/370 (PSBT) used: ship canonical vectors so wallets interoperate.
How this relates to #307: The open Cross-Implementation ZIP Conformance Test Suite (#307) covers ZIPs 244, 225, 321, 32, and 316. PCZT has no ZIP, so it is out of #307’s scope. I see this as complementary and would coordinate to keep it that way.
Proof of concept (already built): Rather than just describe it, I built a small runnable PoC first: GitHub - AngryDavee/pczt-interop: Proof of concept: PCZT round-trip, role-boundary, and test-vector generation for cross-implementation interop testing · GitHub
It uses the `pczt` crate to create a base PCZT, round-trips it and checks the serialization is byte-stable, demonstrates the Combiner role boundary (two parties, one merged PCZT), and emits a canonical test vector. `cargo run` and `cargo test` both work.
I would value feedback on: the scope, whether the adapter-at-the-serialized-boundary approach is the right way to test sign-only hardware devices, and how best to coordinate with #307 and the zcash-devtool maintainers. Thanks.