sizeProofsOrchard |
@@ -185,15 +185,15 @@
Spend Authorization Signature Changes 
- The spend authorization signature is computed in the manner specified in Section 4.15 of the protocol specification , except that the signature is generated over the Action Group Hash,
+
The spend authorization signature is computed in the manner specified in Section 4.15 of the protocol specification , except that the signature is generated over the Action Group Hash,
\(\mathsf{AGHash}\)
, 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 . We update the structure of the orchard_digest component of the SIGHASH as follows:
+ 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 . We update the structure of the orchard_digest component of the SIGHASH as follows:
orchard_digest
├── orchard_action_groups_digest
│ ├── orchard_actions_compact_digest
@@ -219,7 +219,7 @@
T.4a.iv : flagsOrchard (1 byte)
T.4a.v : anchorOrchard (32 bytes)
T.4a.vi : timeLimit (4 bytes)
- The content of T.4a.i, T.4a.ii, and T.4a.iii are the same as T.4a, T.4b, and T.4c of the txid_digest defined in ZIP 244 , over the Actions in the Action Group, and therefore are not expanded on for the sake of brevity.
+ The content of T.4a.i, T.4a.ii, and T.4a.iii are the same as T.4a, T.4b, and T.4c of the txid_digest defined in ZIP 244 , over the Actions in the Action Group, and therefore are not expanded on for the sake of brevity.
The personalization field of this hash is set to:
"ZTxIdOrcActGHash"
In the case that the transaction has no Action Groups, orchard_action_groups_digest is
@@ -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:
@@ -291,7 +291,7 @@
The timeLimit is an integer that represents the max block height in which a given Action Group can be included on the chain. As such, the time limit truly represents the settlement time limit, not the execution time limit. This distinction is important because in our example, execution is happening offchain on the Matcher and settlement happens on the chain (i.e. introducing the Matcher to create bundles and match SO's together adds a step to the lifecycle of the trade and decouples execution and settlement, which otherwise happen at the same time, on-chain). So, if we want the time limit to be part of the validity checks of a transaction on Zcash, we have to treat the time limit as a settlement parameter rather than an execution one. As a result, it is plausible that the party performing the matching and sending it for settlement will not match orders having a time limit that is near enough that it might not get settled on time due to the expected delay between the matching and the inclusion within a block.
Rationale for Spend Authorization Signature Changes
- In the current (NU5) Zcash protocol, each Action includes a Spend Authorization Signature that binds a specific spend instruction to a specific transaction and prevents replay attacks. However, in the context of Asset Swaps, there are two problems that prevent this mechanism from being carried over unchanged.
+ In the current (NU5) Zcash protocol, each Action includes a Spend Authorization Signature that binds a specific spend instruction to a specific transaction and prevents replay attacks. However, in the context of Asset Swaps, there are two problems that prevent this mechanism from being carried over unchanged.
- The SIGHASH represents a hash over a full consensus-compliant transaction object. Since a Swap Order is a trade intent to be used by the party performing the matching to form a valid bundle/transaction, the sender of the Swap Order cannot compute a SIGHASH as per ZIP244. This trader doesn't know all the transaction fields in advance, as they are set when the full bundle transaction is formed and sent to the chain.
- The
timeLimit parameter is a new addition to the protocol, and is therefore not included in the existing SIGHASH. Swap Orders need to be made non-malleable in order to ensure that the party performing the matching cannot change the time limit unilaterally.
@@ -373,7 +373,7 @@
32 |
asset_base |
byte[32] |
- The Asset Base of the input/output of the Swap Order. |
+ The Asset Base of the input/output of the Swap Order. |
8 |
@@ -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}\)
- .
+ .
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 , 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 , 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,26 +407,26 @@
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}\)
associated with the Action Group being replayed. The
\(\mathsf{bsk}\)
- 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.
+ is sent within the Swap Order. The Swap Order 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 . 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 . 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:
- Match on exact same quantities for proposed and desired assets. The check is: (
@@ -552,10 +552,18 @@