Action Groups and Swap Bundle

The transaction format is modified to group Actions 10 into Action Groups characterized by anchors and flagsOrchard. Specifically, the Orchard-ZSA transaction fields 7 are modified as in the table below: This is the Swap Bundle, and it is pictorially represented in the figure below.

Action Group Description Encoding

The ActionGroupDescription data type contains the following fields:

Bytes	Name	Data Type	Description
varies	preAuthActionGroup	ActionGroupDescriptionPreAuth	The pre-authorization Action Group description, without authorizing signatures.
64 * preAuthActionGroup.nActionsOrchard	vSpendAuthSigsOrchard	byte[64][preAuthActionGroup.nActionsOrchard]	Authorizing signatures for the inclusion of each Action of the Action Group in a transaction. See Spend Authorization Signature Changes for details.

The pre-authorization Action Group description data type, ActionGroupDescriptionPreAuth, contains the following fields:

Bytes	Name	Data Type	Description
varies	nActionsOrchard	compactSize	The number of Action descriptions in vActionsOrchard.
852 * nActionsOrchard	vActionsOrchard	OrchardZSAAction[nActionsOrchard]	A sequence of ZSA Swap Action descriptions in the Action Group.
1	flagsOrchard	byte	As defined in Section 7.1 of the Protocol Specification 12.
32	anchorOrchard	byte[32]	As defined in Section 7.1 of the Protocol Specification 12.
varies	sizeProofsOrchard	compactSize	As defined in Section 7.1 of the Protocol Specification 12.
sizeProofsOrchard	proofsOrchard	byte[sizeProofsOrchard]	The aggregated zk-SNARK proof for all Actions in the Action Group.
4	timeLimit	uint32	The block number (in the future) after which the Actions of the Action Group become invalid and should be rejected by consensus.

Spend Authorization Signature Changes

The spend authorization signature is computed in the manner specified in Section 4.15 of the protocol specification 11, 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.

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:

orchard_digest
├── orchard_action_groups_digest
│   ├── orchard_actions_compact_digest
│   ├── orchard_actions_memos_digest
│   ├── orchard_actions_noncompact_digest
│   ├── flagsOrchard
│   ├── anchorOrchard
│   └── timeLimit
└── valueBalanceOrchard

T.4a: orchard_action_groups_digest   (32-byte hash output)
T.4b: valueBalanceOrchard            (64-bit signed little-endian)

"ZTxIdOrchardHash"

BLAKE2b-256("ZTxIdOrchardHash", [])

T.4a.i  : orchard_actions_compact_digest      (32-byte hash output)
T.4a.ii : orchard_actions_memos_digest        (32-byte hash output)
T.4a.iii: orchard_actions_noncompact_digest   (32-byte hash output)
T.4a.iv : flagsOrchard                        (1 byte)
T.4a.v  : anchorOrchard                       (32 bytes)
T.4a.vi : timeLimit                           (4 bytes)

"ZTxIdOrcActGHash"

BLAKE2b-256("ZTxIdOrcActGHash", [])

Binding Signature Changes

The binding signature is generated using the Orchard Binding Signature scheme, by signing the SIGHASH, computed as described in the SIGHASH Computation Changes section, using the signing key \(\mathsf{bsk}\) computed as described below.

The party performing the matching has some Swap Orders \(\mathsf{SO}_i\) , each of which contains a \(\mathsf{bsk}_i\) . The party generates the \(\mathsf{bsk}\) for the binding signature by summing up the \(\mathsf{bsk}_i\) values of the Swap Orders that are matched into the Swap Bundle. For example, if Swap Orders \(\mathsf{SO}_i\) and \(\mathsf{SO}_j\) are matched, then the \(\mathsf{bsk} = \mathsf{bsk}_i + \mathsf{bsk}_j\) . The consensus check remains the same, using these updated values.

Consensus Rule Changes

The transaction verification becomes a nested loop, iterating over all Action Groups and verifying the Actions they contain. Each spend authorization signature MUST be a valid \(\mathsf{SpendAuthSig^{Orchard}}\) signature over \(\mathsf{AGHash}\) using \(\mathsf{rk}\) 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):

• for all AG in ActionGroups do:
  • check that AG.timeLimit <= current block height
  • for (i = 0; i < AG.nActionsOrchard; i++):
    • check the result of ZKAction.Verify on the proof AG.proofsOrchard[i]
    • hash[i] = BLAKE2b-256("ZcashActionGroup", vActionGroupsOrchard[i].preAuthActionGroup)
    • check SpendAuthSig.Validate(AG.vActionsOrchard[i].rk, hash[i], AG.vSpendAuthSigsOrchard[i])

Rationale for Protocol Changes

We cover here the reasons for the different design choices in different sections.

Rationale for Swap Orders

In a Swap Order, senders only manipulate their funds. This means that senders of Orders spend their notes (input) denominated in an Asset \(\mathsf{A}_1\) 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 \(\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:

• One Action for the Proposed Asset.
• One Action for the Desired Asset.
• One Action for the fees ( \(\mathsf{ZEC}\) ).

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.

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.

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 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.

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).

Matchers

The Swap protocol has been described above for the peer-to-peer setting between parties. However, it also supports other use cases such as transaction relays and centralized matching services. This is achieved via Matchers, who are entities (or a network of entities) that run an Order Matching process. This Matching process (i.e. instance of computer program) carries out the Matching operation on a set of received Orders. The Matcher produces Bundles from Orders and then sends them on-chain for settlement. Some supported possibilities are sketched in the figures below.

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.

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: ( \(\mathsf{SO}_i.\mathsf{qty}(A_1) = \mathsf{SO}_j.\mathsf{qty}(A_2)\) & \(\mathsf{SO}_i.\mathsf{qty}(A_2) = \mathsf{SO}_j.\mathsf{qty}(A_1))\)
• Match on same price (with possibly different quantities). The check is: \(\mathsf{SO}_i.\mathsf{price}(A_1) = \mathsf{SO}_j.\mathsf{price}(A_1)\)
• Match on price window (e.g., pass a “slippage parameter”, \(\epsilon\) ). The check is: \(\mathsf{SO}_i.\mathsf{price}(A_1) = \mathsf{SO}_j.\mathsf{price}(A_1) \pm \epsilon\)

Each of these policies have pros and cons and suggest different trading environments. For instance, Policy 2 and Policy 3 may allow partial fills for Swap Orders, while Policy 1 does not (see Limitation: Partial Fills for more discussion on partial fills). Selecting an appropriate matching policy is key, as it heavily influences the trading experience on the system. Opting for a rigid policy may either lead to a poorly used protocol (users staying on existing trading venues) or may force users to interact with the protocol in a way that harms and compromises their on-chain privacy (e.g., carrying out funds consolidation on chain to trade via the Matcher, leaking lots of information in the process). As such, designing a protocol with flexibility in mind is key to minimize information leakage, but it is also fundamental for liquidity consolidation on the system.

Limitation: Partial Fills

In this ZIP, we assume that orders are matched perfectly, and we do not support partial fills. In practice though, modern CLOBs offer partial fills to their users, allowing trades with matching prices to be matched even if quantities don't align perfectly. Offering partial fills without making strong assumptions on the Matcher (e.g. “The Matcher is a market maker that takes the other side of each trade”) or on the availability of traders (e.g. “Traders stay online and stay connected to the Matcher to split their orders on-demand”) is hard. This is particularly at odds with the protocol in this ZIP, since the Matcher is non-custodian and thus only manipulates commitments and notes, which are generated before the matching occurs: traders commit to values, which may need to be changed - in the future - to align with the matching operation of the Matcher (done at a subsequent time).

Some of the proposals to allow for this are:

• The use of standard denomination for orders.
• The inclusion of a special flag “partialFill = true” to flag to the Matcher that the trader is willing to stay online to split orders on demand.
• Existence of a third party Market Maker providing liquidity to the many ZSA pairs traded on the system.

All of these proposals have their pros and cons, and warrant further study and discussion.

Fairness

It is important to provide a good execution for both sides of a Swap. As such, one side should not have an advantage against the other. Every trading party must be able to withdraw their trading intent (i.e., cancel their orders). The main considerations here are:

• Provide a mechanism for time-limiting Swaps to reduce freezing up of Assets due to their being locked up in Swaps that have not been completed, and to align with dynamically changing “exchange rates” between different Assets.
• Consider repercussions of, and possible mitigations for, the “free option” that becomes available to the party that performs the last step of the protocol. That is, it is possible for that party to abort the protocol at this last step if the Swap is no longer beneficial for it.

Denial-of-Service (DoS) Prevention

The implementation of a fee mechanism is not enough to provide DOS prevention. In fact, the presence of a fee in a Swap Order doesn't ensure this fee is payable. A trader, Alice, can promise to pay 1000 ZEC, but this promise has no value unless it can be verified. The same applies to fees. The Matcher must be able to carry out quick validity checks on Swap Orders to assess their probability to form valid Swap Bundles when matched. This includes, verifying the ability for traders to pay the fees they must pay as part of the protocol. These checks are probabilistic (the state of the blockchain can change in the meantime), but provide some guarantees to the Matcher that it will be paid for its services.

Some helpful checks in this regard will be:

• Verifying the nullifiers: “Does the order spend notes that have already been spent?” (This might require querying the chain.)
• Verifying the ZKPs: “Does the order contain valid Actions?”
• Verifying the \(\mathsf{rcv}\) values and other extra data attached to the Swap Order.
• Verifying the time limit: “Has the order expired?”
• Verifying the fee payment: “Can the Order pay the promised fee?”