Zcash Shielded Asset Swaps and Transaction Acceptance

Community Grants Applications
24

Dear Zcash Community,

We’re sharing here our progress in the last few weeks on the Asset Swaps implementation and transaction acceptance design.

Asset Swaps ZIPs

  • In preparation for the implementation, we revisited the content of ZIP 228 and we have improved the clarity of the specification in various places.
  • We have also added some more rationale and separated that from the actual specification.
  • Our PR for the Asset Swaps ZIP is PR#780. We’d love to hear further comments on the design on there.

Asset Swaps Implementation (orchard, librustzcash, Zebra)

  • We have begun updating the orchard crate to add support for Action Groups as proposed in ZIP 228.
  • We are currently working through what changes to the OrchardZSA circuit (if any) would be required in order to securely allow for Swaps.
  • We are also in the midst of creating new data structures / updating existing ones for the Orchard Bundle, the Orchard Action, and the Orchard Action Group.

Asset Swap Matching Implementation (matcher, tx_tool)

  • While the protocol itself will require development and tests in the repositories listed in the previous section, actual use by the community would require the ability to create Swap Orders, and also to match these Swap Orders, create a Swap Bundle, and submit that on chain.
  • The Matcher is designed to collect Swap Orders, match them efficiently, combine them, and submit the complete Swap Bundles to the blockchain.
  • The architectural design for the Matcher is currently underway.
  • We will also be updating our zcash_tx_tool, which we have been using to generate transactions for Zebra nodes, to also be able to generate Swap Orders on the client side.

Transaction Acceptance (User Control) Design

  • We have begun research into possible designs to add the proposed ability to accept / reject incoming transactions.
  • Here’s a list of some of the questions we are thinking about in this regard. Please feel free to raise more!
    • One core design consideration is regarding the default behavior: i.e. requiring explicit approval vs explicit rejection from the recipient. The use-cases are one way of assessing this.
    • What is the threat model? We have to consider in the threat model both malicious senders (who want to expose other users to Assets they do not consent to, for example), and malicious recipients (who could try to hold up funds by not providing explicit approval, or fall back on deniability if they didn’t provide explicit rejection).
    • Should the approval/rejection of a transaction be stored on chain, or can it just happen off-chain between the sender and receiver?
    • Who should pay the fees, and should there be extra fees for acceptance/rejection? This is more relevant if an on-chain record is to be maintained. But the responsibility of submitting to the chain moves from the sender to the recipient (post-approval), which needs to be considered as well.
    • Extent: Should this user control extend to every transaction, or only transactions of larger than a certain threshold, or only ZSAs, and so on? While answering this question we have to be mindful about indistinguishability. If we allow the choice per transaction, the choice should be the recipient’s.

Looking forward to hearing from you all!

Best,

The QEDIT Team.

10 Likes