zips
zips copied to clipboard
zcash
Call for comments: ZSA Swaps base proposal
Hi everyone,
I am opening this issue to collect comments - if any - about ZSA Swaps in order to advance the discussion on the topic and gather feedback from the community on the work done.
As you might know, QED-it was awarded a grant to work on ZSA Swaps. As such, we have designed a protocol improvement proposal that introduces a new Zcash transaction format enabling multiple use cases such as P2P ZSA Swap, Transaction Relays or ZSA Swaps via a 3rd party Matcher - to only name a few. For now, we assume perfect matching (i.e. only orders with equal quantities can be matched), with matching fees being paid in ZEC.
Motivational use-case: We want to let 2 traders, Alice and Bob, swap assets on Zcash. E.g. Alice wants 100 AAA (ask) for 20 BBB (offer) and Bob wants 20 BBB (ask) for 100 AAA (offer). Alice and Bob may or may not know each other. We want to reuse as many of the Zcash data structures as possible to build on battle-tested engineering and protocol design. Since the two traders Alice and Bob may not know each other - thus may not be able to coordinate -, may trade at different times etc; Alice and Bob may generate Orchard Actions for their Swap Orders, using different commitment tree Merkle roots, which means that they may generate their Orchard Actions/Proofs over different blockchain states. In the current version of the Zcash protocol (NU5), each transaction contains at most one Orchard anchor (a Merkle root of the commitment tree), and thus doesn't allow to "bundle" together 2 sets of Actions/Proofs generated over different anchors, in a same transaction object.
Summary: This proposal's main contribution is the introduction of ActionGroups as a substitute to Actions in the Zcash transaction object. An ActionGroup is a set of actions/proofs along with the anchor over which these are generated. Using ActionGroups in the Zcash transaction object allows to bundle together 2 (or more) sets of Actions generated over different views of the Zcash blockchain into a single transaction, which facilitates the implementation of ZSA Swap use cases, but also paves the way for a wide range of relay-based designs on Zcash. Additional fields are introduced in ActionGroups to add robustness to the protocol and further protocol changes are needed to account for the new transaction structure (i.e. a transaction now has a set of "actions 'namespaces'").
The full details of the current Swap protocol can be found here: https://docs.google.com/document/d/1MabmK6UAj946mOoFV5vR5XmgakCVVVazS1tsTU2M0gI/edit?usp=sharing - which lists the assumptions, pros and cons of the design, lists the protocol changes, the limitations and future work. More background and context can also be found in the appendix of the document.
Our goal is to enable the Swap use case on top of ZSAs, offering a flexible building block on top of which to build trading protocols for the Zcash ecosystem; while limiting protocol changes as much as possible to reuse as much of the Zcash logic and limit additional complexity.
If you have any questions/feedback or remarks, I'd be grateful if you could share them either here or in the document linked above. Thank you very much!
[EDIT] Clarified that the proposed transaction structure doesn't require the need to use a centralized Matcher. This ZIP is introducing a new transaction structure that can be used across a range of settings to design trading protocols and Zcash relays.
I'm super excited to see Zcash DEX efforts! I wasn't aware this project was this far along until just now. Nice work!
I have high level critical feedback that isn't specific to the proposal, but the bigger picture approach:
I have a belief that AMMs are more useful / beneficial than CLOBs for (very roughly) similar complexity, for a variety of reasons: One is that AMMs are "immediately available" to users, whereas CLOBs require waiting for matching parties. Another is that CLOBs require privileged order book match-makers (or sophisticated protocols for that piece). CLOBs also seem more prone to MEV, which I hope to avoid as much as possible in Zcash.
Have you investigated possible AMM designs or approaches?
I realize this is a substantially different approach than this proposal, but I feel like it's important enough to carefully consider since both would require a significant amount of complexity in the protocol and effort to deploy.
If swaps have low enough complexity, I'd be a fan of doing both swaps and AMM work (as fast as possible for either one). If each is relatively complex by itself, I'd urge being more cautious so that we can avoid significant effort and complexity if one approach would be used significantly more than the other.
Two AMM designs I'm curious to investigate more:
- Penumbra Swaps because they are privacy-preserving and MEV-resistant (although they seem fairly complex).
- Nate's Quick'n'Dirty Strawman Design:
- Clone Uniswap v2 by implementing the liquidity provision and exchange logic in transparent Zcash rules (no circuit changes).
- Add new transaction field types for the Zcash-clone-of-Uniswap-v2 operations. These may need to be specialized to only interacting with Orchard+ZSAs. (This would also mean ZSA asset types need to be representable by these new AMM fields.)
Rationale of this approach is it attempts to be as simple as possible to implement: Uniswap v2 is chosen because it's the simplest AMM design I'm aware of, and the second bullet is aimed at avoiding any circuit changes. Basically this approach optimizes for time-to-market and design simplicity, while it would have worse privacy, liquidity, and cost properties vs the Penumbra design.
Thanks for your comments/feedback @nathan-at-least! :)
One is that AMMs are "immediately available" to users, whereas CLOBs require waiting for matching parties [...] CLOBs also seem more prone to MEV, which I hope to avoid as much as possible in Zcash.
I guess it all boils down to use cases and types of assets traded (liquidity is required in both cases, though it's provisioned differently for AMMs and CLOBs). On the MEV side of things, I think this is heavily design dependent. Certain AMM design can be very prone to MEV too, and some CLOB designs can be relatively immune to MEV, especially in the context of Zcash-type protocols where funds are shielded and committed to notes and where signatures are used to provide spend authority etc, making it hard to access messages' content and maul/replay them.
Two AMM designs I'm curious to investigate more:
- Penumbra Swaps because they are privacy-preserving and MEV-resistant (although they seem fairly complex).
AFAIK, implementing a Penumbra-like ZSwap would come with a set of drawbacks that would need further consideration. For instance, as far as I know, Penumbra Swaps are done in 2 steps: a burn operation and a claim operation. Splitting swap operations in 2 steps will increase the amount of transactions to be mined (i.e. increased miner revenues, but increased state growth). Each "leg" of this 2-step process would be an "imbalanced” Zcash transaction (i.e. the binding sig’s value balance wouldn’t hold for each leg, a bit like the Swap Orders in our proposal above -> although Swap Orders never hit the chain). So, while we could draft a specific Swap message (with a possibly different statement), it'll be very tricky to ensure indistinguishability between Swap txs and “normal txs”, which probes for further analysis (if indistinguishability is even possible and/or required...). It's also not clear to me how much indistinguishability matters as the set of use cases grows on Zcash.
Our goal is to limit changes to the protocol as much as possible to build on top of battle-tested designs and implementations, but also to keep the complexity of the protocol under control by avoiding to "bake" too many use cases in the protocol.
Importantly, by introducing ActionGroups, we can enable a wide-class of relay-based use cases on Zcash (such as Matchers which can also be used in the P2P setting) while keeping the protocol fairly use-case agnostic and limiting changes.
- Nate's Quick'n'Dirty Strawman Design:
- Clone Uniswap v2 by implementing the liquidity provision and exchange logic in transparent Zcash rules (no circuit changes).
- Add new transaction field types for the Zcash-clone-of-Uniswap-v2 operations. These may need to be specialized to only interacting with Orchard+ZSAs. (This would also mean ZSA asset types need to be representable by these new AMM fields.)
Rationale of this approach is it attempts to be as simple as possible to implement: Uniswap v2 is chosen because it's the simplest AMM design I'm aware of, and the second bullet is aimed at avoiding any circuit changes. Basically this approach optimizes for time-to-market and design simplicity, while it would have worse privacy, liquidity, and cost properties vs the Penumbra design.
As you mentioned, this design seems to optimize for time to market and simplicity. If the goal is for Zcash to be the "privacy preserving ecosystem", such approach wouldn't be adequate IMHO. Chains compete with one another to attract LPs, so, simplicity of the design aside, why would LPs provide liquidity on a transparent Zcash AMM when they can do so on a PoS chain (where they may also be able to stake etc)? Attracting LPs on the Zcash AMM would mean providing higher LP returns than on other chains - which surely is possible (e.g. returns can be inflated by subsidizing liquidity provisioning), but need to be strategized for. As far as I understand, the USP of Zcash is the strong privacy guarantee provided by the system, so it seems strategic to maximize for "privacy" when introducing such building blocks in the protocol, especially given that an unshielded AMM would induce specific behavior on Zcash users, probing for more z2t operations which could undermine the overall privacy guarantees of the system. Having a privacy preserving swap use-case would be a differentiator to attract traders willing to swap privately, which would increase trade volume and which would - in fine - inflate LP returns, attracting validators and liquidity providers to the chain.
I agree with Nathan - unfortunately I fear a 1:1 match-only orderbook will have little to no use. Hope to be proven wrong!
