The problem I have with this argument is that I think deploying ZSAs is focusing on activating on the Product-Market Fit discovered via swaps and CrossPay.
The Zashi/Zodl swap and CrossPay functionality using NEAR Intents is heavily dependent on NEAR: the blockchain, the associated infrastructure, and the company and its staff (operations, management, lawyers, etc).
I like NEAR Intents. I think its designers are competent and have made appropriate design decisions for the context. But it is a central point of failure. If you request a refund because you or your wallet made a mistake when doing a swap or cross-chain payment, then someone has to manually decide whether you’re trying to scam them and if they decide you’re not, they need to manually fix it (if they can, which depends on a bunch of details about what mistake was made). They do risk management that might result in some swaps and cross-chain payments getting censored. It works, and it provides functionality that users want and need, but it’s not what a cipherpunk would design and it’s potentially vulnerable to legal and other attempted attacks.
I also strongly support the work that has been done to support swaps using Maya that allow shielded transfers on the Zcash side, but even after further planned improvements it will have similar privacy and centralization limitations.
ZSAs are complementary to cross-chain DEXes (which, despite the name, are only partially decentralized). At the base mechanism layer, ZSAs are truly permissionless, fully decentralized, and fully private — with support for selective transparency and with an anonymity set that both benefits from and contributes to that of ZEC transfers. These properties don’t rely on any privacy policies or any potentially fallible or coercible member of a company’s staff*.
*Other than attack vectors against consensus node software that are already present, and can be mitigated by review processes, working in public, published audits, reproducible builds, dependency vetting, etc.
Obviously stuff built on ZSAs might depend on other things, and any given Custom Asset depends on the holders of its issuance keys not to issue against policy before it is finalized, but that’s fine for now: issuance is publically auditable, it can use a FROST multisig and potentially HSMs or TEEs, and there can be competition between assets and future extensions to how it is done.
I get that ZSAs have risks. I get that they complicate the protocol, and to some extent wallet UX. It does mildly frustrate me that people throw around the term “attack surface” as a reason to exclude new features without either having an understanding of the protocol, or being willing to trust the experience and judgement of people who do. (It frustrates me even more that apparently most of the same people want to reject proposals such as ZIP 2003 that would remove attack surface in parts of the protocol that have been deprecated for years.)
In any case, I think that ZSAs could be an invaluable mechanism to build a decentralized, fully private, multi-token ecosystem. Some of that potential can likely only be unlocked in combination with scaling and/or programmability improvements. But that doesn’t mean ZSAs should block on those improvements; in fact they likely can’t if we want to activate them at all.
To be more concrete, what I’m proposing is:
- Design NU7 in such a way that it would allow for a deployment of ZSAs in a subsequent upgrade that is smoother and free of security compromises: add \mathsf{AssetBase} to Orchard lead-byte \mathtt{0x03} note plaintexts (which are needed anyway for Orchard Quantum Recoverability), and deploy extensible transactions with an Orchard bundle type that would allow ZSA-using and non-ZSA-using bundles to be indistinguishable. These are extremely low-risk changes and I can have a spec PR for them ready
this weekwhen I come back from HACS and RWC. - After appropriate review, merge the ZSA code into Zebra, librustzcash, and other relevant crates under a compilation flag. This will avoid the problem of the ZSA branches bitrotting and becoming unmergeable.
- Encourage the use of ZSAs on a public, well-maintained ZSA-testnet.
- Defer whether to deploy ZSAs on mainnet to a future governance decision.
I can think of lots of folks who don’t want powerful DEX’es to prosper.