Improving UX with detection keys

Let me preface this by stating that I (currently) believe that, in the long term, Zcash will migrate to a succinct blockchain (á la Mina) or similar zkrollup-based* architecture. However, that’s a long way off (and a subject for a different topic). In the medium term, detection keys seem to be an option that’s worth exploring. It’s a topic that comes up during Arborist calls every so often (e.g. December 2022, September 2023).

Personally, I’d like to establish a cross-ecosystem team, with engineers from ECC and ZF (plus others, if they’re interested in contributing) to draft a strawman design proposal for deploying detection keys, with a more specific/concrete objective of figuring out what changes would need to be made to the transaction format to support detection keys, with a view to including those changes in the V6 transaction format. That way we could lay the groundwork so that we could roll out detection keys without needing to do another network upgrade.

﹡ I’ve crossed out “zkrollup-based” to avoid people jumping to the conclusion that I’m in favour of Zcash becoming a L2 token on another project’s blockchain. For the record, I’m not. I believe that Zcash should remain on its own L1, and I expect that the L1 architecture Zcash uses in the future will leverage ZKPs to become more scalable (versus today’s UTXO/note-based architecture).

5 Likes