From 0b269df91d799a789a79d0e03ca7047d89438900 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 8 Sep 2024 11:56:27 +0530 Subject: [PATCH 1/3] resolving comments on Asset Swaps ZIP --- rendered/zip-0228.html | 30 +++++++++++++++--------------- zips/zip-0228.rst | 31 ++++++++++++++++--------------- 2 files changed, 31 insertions(+), 30 deletions(-) diff --git a/rendered/zip-0228.html b/rendered/zip-0228.html index c94504188..8c89c4e40 100644 --- a/rendered/zip-0228.html +++ b/rendered/zip-0228.html @@ -54,7 +54,7 @@
The P2P setting, where two traders swap Assets between themselves.

A key challenge is that Swap Orders that match may contain Actions and Zero Knowledge Proofs generated using different blockchain states and roots of note commitment trees. In the current (NU5) protocol, each transaction contains a set of Actions and Proofs generated using a single anchor/Merkle root, and there is no way to combine independently generated halo2 proofs into a single combined proof.

-

To enable combining Actions and Proofs from different blockchain states, the concept of an Action Group is introduced in this ZIP. An Action Group groups together Actions and Proofs generated using a common commitment tree root. Action Groups replace Actions in the Zcash transaction format. This allows for creating a single Zcash transaction from different sets of Actions and Proofs generated using different anchors and blockchain states. This Action Groups-based transaction structure enables a wide range of use-cases to be built on Zcash, such as: P2P ZSA Swaps, Zcash transaction relays or ZSA Swaps via a centralized Matcher - to name a few (More details are under the Matchers heading in the Other Considerations section of this ZIP).

+

To enable combining Actions and Proofs from different blockchain states, the concept of an Action Group is introduced in this ZIP. An Action Group groups together Actions and Proofs generated using a common commitment tree root. Action Groups replace Actions in the Zcash transaction format. This allows for creating a single Zcash transaction from different sets of Actions and Proofs generated using different anchors and blockchain states. This Action Groups-based transaction structure enables a wide range of use-cases to be built on Zcash, such as: P2P ZSA Swaps, Zcash transaction relays or ZSA Swaps via a centralized Matcher - to name a few. (More details are under the Matchers heading in the Other Considerations section of this ZIP.)

Specification: Protocol Changes

The protocol is largely the same as that in the Orchard-ZSA Protocol described in ZIP 226 4 and ZIP 227 5. The changes to the protocol are described in this section. The specification of the structure of Swap Orders (that are sent off-chain) is provided in the next section, Specification: Swap Orders.

@@ -143,8 +143,8 @@ 852 * nActionsOrchard vActionsOrchard - OrchardZSAAction[nActionsOrchard] - A sequence of ZSA Swap Action descriptions in the Action Group. + OrchardZsaAction[nActionsOrchard] + A sequence of ZSA Swap Action descriptions in the Action Group. The ''OrchardZsaAction'' type is defined in ZIP 230 [#zip-0230]. 1 @@ -190,7 +190,7 @@ , which is defined to be \(\mathsf{AGHash} := \mathsf{BLAKE2b}\texttt{-}\mathsf{256}(\texttt{"ZcashActionGroup"}, \mathsf{preAuthActionGroup})\) .

-

This change ensures that no changes are required in the Action Statement to be proved.

+

This change ensures that no changes are required in the Action statement to be proved.

SIGHASH Computation Changes

The addition of Action Groups to the Zcash transaction as another level of abstraction requires a change in the way transactions are hashed to compute the SIGHASH in ZIP 244, specifically in the orchard_digest section 8. We update the structure of the orchard_digest component of the SIGHASH as follows:

@@ -254,11 +254,11 @@ \(\mathsf{AGHash}\) using \(\mathsf{rk}\) - as the validating key. (That is, the signature is over + as the validating key (That is, the signature is over \(\mathsf{AGHash}\) instead of \(\mathsf{SigHash}\) - .) The time limit also needs to be checked during verification. Specifically, the consensus rule becomes (if any checks fail, the transaction MUST be rejected):

+ ). The time limit also needs to be checked during verification. Specifically, the consensus rule becomes (if any checks fail, the transaction MUST be rejected):

  • for all AG in ActionGroups do: @@ -389,14 +389,14 @@ and create a note for themself, to receive the desired amount of another Asset \(\mathsf{A}_2\) .

    -

    To support a CLOB like trading environment, the Order senders do not know in advance with whom their orders will be matched, so they do not know, in advance, who is the recipient of the funds they offer to swap. As such, they cannot create notes for a recipient other than themself. To form an Order, the sender must generate Actions with output notes and associated commitments, that use their own diversifier +

    To support a Closed Ledger Order Book (CLOB)-like trading environment, the Order senders do not know in advance with whom their orders will be matched, so they do not know, in advance, who is the recipient of the funds they offer to swap. As such, they cannot create notes for a recipient other than themself. To form an Order, the sender must generate Actions with output notes and associated commitments, that use their own diversifier \(\mathsf{d}\) and diversified transmission key \(\mathsf{pk_d}\) 9.

    Each Order can be seen as an “invalid" ZSA transaction to oneself, which is unbalanced w.r.t each ZSA AssetBase. Each Order only “becomes valid” in the context of a Swap Bundle, whose overall value is balanced across Asset Bases (i.e. the two Orders balance each other).

    Furthermore, each Order contains a specific Action that pays "matching fees" to the party performing the matching. This Action, paying fees, in ZEC, to the matcher, is generated using the matcher's details to generate output notes, since we assume, generally, that the matcher is known by all trading parties. In the P2P case the matcher is simply the second party out of the two (See the Fees section for more details).

    -

    ZIP 226 4, that this ZIP builds on, introduces changes to the NU5 circuit to include support for different Assets. The structure there requires that the input and output notes of the OrchardZSA Action must have the same asset base. This ZIP continues with the same idea, i.e. the manipulation of a single Asset Base per Action. Therefore, Swap Orders are expected to generally have at least three Actions:

    +

    ZIP 226 4, that this ZIP builds on, introduces changes to the NU5 circuit to include support for different Assets. The structure there requires that the input and output notes of the OrchardZSA Action must have the same Asset Base. This ZIP continues with the same idea, i.e. the manipulation of a single Asset Base per Action. Therefore, Swap Orders are expected to generally have at least three Actions:

    • One Action for the Proposed Asset.
    • One Action for the Desired Asset.
      • @@ -407,7 +407,7 @@

Security and Privacy Considerations

-

Protection against Replay attacks

+

Protection Against Replay attacks

We consider whether our change from signing the SIGHASH in the spend authorization signature to signing the Action Group Hash opens any possibilities of replay attacks.

This is prevented by the use of the updated SIGHASH in the binding signature. If an adversary tries to extract an Action Group and associated Spend Authorization Signature from a transaction on the network to replay it within another transaction - which would potentially be detrimental to the matcher as it could make their bundle invalid (if the replayed Action Group gets included first on-chain) - the adversary will also need to be able to generate a binding signature on their replayed transaction, which is not possible without knowing the \(\mathsf{bsk}\) @@ -416,17 +416,17 @@ is sent within the Swap Order, which is assumed to be communicated over a secure channel off-chain between the parties. This precludes the possibility of replay attacks.

Non-Malleability of the Time Limit

-

We protect against the malleation of the time limit field by a malicious matching party (in order to take advantage of the "free option" that it could obtain by extending the validity of an Order) by including the time limit inside the Action Group Hash that is signed using the Spend Authorization Signature (see more details in Rationale for Time Limit). The security of the Spend Authorization Signature and the collision resistance of the BLAKE2b-256 hash then ensures that the time limit remains the same as the one mandated by the creator of the Swap Order.

+

We protect against the malleation of the timeLimit field by a malicious matching party (in order to take advantage of the "free option" that it could obtain by extending the validity of an Order) by including the time limit inside the Action Group Hash that is signed using the Spend Authorization Signature (see more details in Rationale for Time Limit). The security of the Spend Authorization Signature and the collision resistance of the BLAKE2b-256 hash then ensures that the time limit remains the same as the one mandated by the creator of the Swap Order.

Other Considerations

Fees

The primary goal of a fee mechanism is twofold:

    -
  • It should disincentivize malicious users from flooding the network with spam Swap offers that are unlikely to be matched.
    • +
  • It should disincentivize malicious users from flooding the network with spam Swap Orders that are unlikely to be matched.
  • It should incentivize the party performing the matching to perform the additional work required to match orders and bundle them together.
-

For the matching to be economically viable, the fees captured by the matcher to create the bundle must at least be higher than the fees needed to settle the bundle on the chain.

+

For the matching to be economically viable, the fees captured by the Matcher to create the bundle must at least be higher than the fees needed to settle the bundle on the chain.

The proposed changes to the transaction structure and the consensus checks also require a change in the fees paid to miners. The use of Action Groups adds information to the transaction object, and adds more bytes to the blockchain state. This needs to be paid for by network users and will result in an increase in the expected fee, though the logic is the same.

The fees being paid in ZEC helps alleviate concerns about other Assets piggy-backing on the Zcash network without providing value to holders of ZEC. Even beyond that, taking fees in the traded assets exposes the Matcher to all traded assets. This may pose regulatory issues for the Matcher (e.g. if specific assets are deemed illegal in specific jurisdictions). The effect of this may be the re-creation of mechanisms of central exchanges, where only a specific list of assets are accepted for trading by matchers (similar to the “asset listing” approach of centralized exchanges).

@@ -446,16 +446,16 @@

The Matcher must be able to receive incoming Swap Orders from traders willing to use it to Swap ZSAs. We assume that a Matcher is discoverable by market participant (e.g. it has a website), that traders can send Orders to the Matcher (e.g. using a secure 1-to-1 communication channel) and that a Matcher defines its own logic to process the received Swap Orders. Examples of such logic are:

  • A set of validity checks to run on the received Swap Orders, e.g. to prevent DoS attacks (See Denial-of-Service (DoS) Prevention). If the verification of a Swap Order fails, the Swap Order gets rejected.
    • -
  • A set of operations to manage the valid Swap Orders waiting to be matched. This could include, for instance, a set of data structures and operations to manage a mempool/Central Limit Order Book (CLOB), following a chosen ordering policy (See, CLOB and Matching Policies for more details), etc.
    • +
  • A set of operations to manage the valid Swap Orders waiting to be matched. This could include, for instance, a set of data structures and operations to manage a mempool/CLOB, following a chosen ordering policy (See, CLOB and Matching Policies for more details), etc.
-
Create Swap Bundles and Settle
+
Create Swap Bundles and Send on-chain

This step performs a set of operations, which from a set of matched Orders (see the previous step) builds a Swap Bundle to be sent on-chain as a Zcash transaction for settlement.

CLOB and Matching Policies

-

The Matcher-based trading protocol for ZSA is primarily modeled after Central Limit Order Book (CLOB)-based execution 13. The Matcher is assumed to receive Swap Orders, add and order them in a data structure and match them when their terms align. Generally, sorting in a CLOB is made according to: 1st prices and 2nd the time at which an order is received by the Matcher.

+

The Matcher-based trading protocol for ZSA is primarily modeled after CLOB-based execution 13. The Matcher is assumed to receive Swap Orders, add and order them in a data structure and match them when their terms align. Generally, sorting in a CLOB is made according to: 1st prices and 2nd the time at which an order is received by the Matcher.

We can identify different ways to “consume” the CLOB, i.e., match Swap Orders together: