Skip to content

Commit

Permalink
updates based on review comments
Browse files Browse the repository at this point in the history
  • Loading branch information
@vivek-arte
vivek-arte committed Sep 23, 2024
1 parent ec123f9 commit 3977a28
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 23 deletions.
15 changes: 7 additions & 8 deletions rendered/zip-0228.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -57,9 +57,9 @@
<p>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 <a href="#matchers">Matchers</a> heading in the <a href="#other-considerations">Other Considerations</a> section of this ZIP.)</p>
</section>
<section id="specification-protocol-changes"><h2><span class="section-heading">Specification: Protocol Changes</span><span class="section-anchor"> <a rel="bookmark" href="#specification-protocol-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The protocol is largely the same as that in the Orchard-ZSA Protocol described in ZIP 226 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0226">4</a> and ZIP 227 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0227">6</a>. 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, <a href="#specification-swap-orders">Specification: Swap Orders</a>.</p>
<p>The protocol is largely the same as that in the OrchardZSA Protocol described in ZIP 226 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0226">4</a> and ZIP 227 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0227">6</a>. 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, <a href="#specification-swap-orders">Specification: Swap Orders</a>.</p>
<section id="action-groups-and-swap-bundle"><h3><span class="section-heading">Action Groups and Swap Bundle</span><span class="section-anchor"> <a rel="bookmark" href="#action-groups-and-swap-bundle"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The transaction format is modified to group Actions <a id="footnote-reference-10" class="footnote_reference" href="#protocol-actions">12</a> into <strong>Action Groups</strong> characterized by anchors and <code>flagsOrchard</code>. Specifically, the Orchard-ZSA transaction fields <a id="footnote-reference-11" class="footnote_reference" href="#zip-0230-transaction-format">9</a> are modified as in the table below: This is the Swap Bundle, and it is pictorially represented in the figure below.</p>
<p>The transaction format is modified to group Actions <a id="footnote-reference-10" class="footnote_reference" href="#protocol-actions">12</a> into <strong>Action Groups</strong> characterized by anchors and <code>flagsOrchard</code>. Specifically, the OrchardZSA transaction fields <a id="footnote-reference-11" class="footnote_reference" href="#zip-0230-transaction-format">9</a> are modified as in the table below: This is the Swap Bundle, and it is pictorially represented in the figure below.</p>
<table>
<thead>
<tr>
Expand Down Expand Up @@ -279,10 +279,10 @@
<section id="fees"><h3><span class="section-heading">Fees</span><span class="section-anchor"> <a rel="bookmark" href="#fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We distinguish between two types of fees for Asset Swaps, namely Miner Fees and Matcher Fees.</p>
<section id="miner-fees"><h4><span class="section-heading">Miner Fees</span><span class="section-anchor"> <a rel="bookmark" href="#miner-fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>These are the fees paid to miners for including the transaction in a block. Miner fees are relevant at the time of settlement of the Swap Bundle on the chain. These continue to follow the same logic as in the ZSA Protocol, and are paid in ZEC.</p>
<p>These are the fees paid to miners for including the transaction in a block. Miner fees are relevant at the time of settlement of the Swap Bundle on the chain. These continue to follow the same logic as in the OrchardZSA Protocol, and are paid in ZEC.</p>
</section>
<section id="matcher-fees"><h4><span class="section-heading">Matcher Fees</span><span class="section-anchor"> <a rel="bookmark" href="#matcher-fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>These are the fees paid to the party performing the matching. A party that creates a Swap Order includes a Fee Action inside the Action Group Description of that Swap Order in addition to the details of the desired Swap operation (see <a href="#specification-swap-orders">Specification: Swap Orders</a>). The Matcher creates an additional Action Group to transfer the fees to an address they control during the creation of the Swap Bundle. Thus, when the Swap Bundle is settled on the chain, the two parties swap Assets and the fees are transferred to the Matcher.</p>
<p>These are the fees paid to the party performing the matching. A party that creates a Swap Order includes a Fee Action inside the Action Group Description of that Swap Order in addition to the details of the desired Swap operation (see <a href="#specification-swap-orders">Specification: Swap Orders</a>). The Matcher creates an additional Action Group to transfer the fees to an address they control during the creation of the Swap Bundle. Thus, when the Swap Bundle is settled on the chain, the two parties swap Assets and the Matcher Fees are transferred to the Matcher.</p>
</section>
</section>
<section id="rationale-for-protocol-changes"><h3><span class="section-heading">Rationale for Protocol Changes</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-protocol-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
Expand Down Expand Up @@ -325,9 +325,8 @@
<span class="math">\(\mathsf{bsk}\)</span>
“binds together" the commitments of all Actions in the Order, preventing selective extraction of specific Actions in a Swap Order by a malicious matcher.</p>
</section>
<section id="rationale-for-fees"><h4><span class="section-heading">Rationale for Fees</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>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 as in the ZSA Protocol.</p>
<p>The Matcher Fees incentivize the Matcher to search through the unmatched Swap Orders and create Swap Bundles out of matching Orders. It also compensates the Matcher for the Miner Fees that will arise when the constructed Swap Bundle is included in a transaction. For the matching to be economically viable, the fees captured by the Matcher to create the Swap Bundle must at least be higher than the fees needed to settle the bundle on the chain. We continue to use ZEC for these fees as well, since the benefit of an arbitrary Asset to a third-party matcher is unclear, and exposes the Matcher to the traded assets. This exposure may pose regulatory issues for the Matcher (e.g. if specific assets are deemed illegal in specific jurisdictions). It also provides a straightforward compensation for the Miner Fee outlay. The fees being paid in ZEC also helps alleviate concerns about other Assets piggy-backing on the Zcash network without providing value to holders of ZEC.</p>
<section id="rationale-for-matcher-fees"><h4><span class="section-heading">Rationale for Matcher Fees</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-matcher-fees"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The Matcher Fees incentivize the Matcher to search through the unmatched Swap Orders and create Swap Bundles out of matching Orders. We continue to use ZEC for these fees as well, since the benefit of an arbitrary Asset to a third-party matcher is unclear, and exposes the Matcher to the traded assets. It also provides a straightforward compensation for the Miner Fee outlay.</p>
</section>
</section>
</section>
Expand Down Expand Up @@ -407,7 +406,7 @@
and diversified transmission key
<span class="math">\(\mathsf{pk_d}\)</span>
<a id="footnote-reference-22" class="footnote_reference" href="#protocol-notes">11</a>.</p>
<p>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).</p>
<p>Each Order can be seen as an “invalid" OrchardZSA 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).</p>
<p>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 <a href="#fees">Fees</a> section for more details).</p>
<p>ZIP 226 <a id="footnote-reference-23" class="footnote_reference" href="#zip-0226">4</a>, 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:</p>
<ul>
Expand Down
22 changes: 7 additions & 15 deletions zips/zip-0228.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -67,13 +67,13 @@ This Action Groups-based transaction structure enables a wide range of use-cases
Specification: Protocol Changes
===============================

The protocol is largely the same as that in the Orchard-ZSA Protocol described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. The changes to the protocol are described in this section.
The protocol is largely the same as that in the OrchardZSA Protocol described in ZIP 226 [#zip-0226]_ and ZIP 227 [#zip-0227]_. 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`_.

Action Groups and Swap Bundle
-----------------------------

The transaction format is modified to group Actions [#protocol-actions]_ into **Action Groups** characterized by anchors and ``flagsOrchard``. Specifically, the Orchard-ZSA transaction fields [#zip-0230-transaction-format]_ are modified as in the table below:
The transaction format is modified to group Actions [#protocol-actions]_ into **Action Groups** characterized by anchors and ``flagsOrchard``. Specifically, the OrchardZSA transaction fields [#zip-0230-transaction-format]_ are modified as in the table below:
This is the Swap Bundle, and it is pictorially represented in the figure below.

+-----------------------------+--------------------------+--------------------------------------------------+---------------------------------------------------------------------+
Expand Down Expand Up @@ -236,15 +236,15 @@ Miner Fees

These are the fees paid to miners for including the transaction in a block.
Miner fees are relevant at the time of settlement of the Swap Bundle on the chain.
These continue to follow the same logic as in the ZSA Protocol, and are paid in ZEC.
These continue to follow the same logic as in the OrchardZSA Protocol, and are paid in ZEC.

Matcher Fees
````````````

These are the fees paid to the party performing the matching.
A party that creates a Swap Order includes a Fee Action inside the Action Group Description of that Swap Order in addition to the details of the desired Swap operation (see `Specification: Swap Orders`_).
The Matcher creates an additional Action Group to transfer the fees to an address they control during the creation of the Swap Bundle.
Thus, when the Swap Bundle is settled on the chain, the two parties swap Assets and the fees are transferred to the Matcher.
Thus, when the Swap Bundle is settled on the chain, the two parties swap Assets and the Matcher Fees are transferred to the Matcher.

Rationale for Protocol Changes
------------------------------
Expand Down Expand Up @@ -312,20 +312,12 @@ To be able to spend a subset of the Actions in a Swap Order, the matcher would h
Given that :math:`\mathsf{bsk}` is a modular addition of random field elements, extracting specific values without additional context isn't possible.
Hence, :math:`\mathsf{bsk}` “binds together" the commitments of all Actions in the Order, preventing selective extraction of specific Actions in a Swap Order by a malicious matcher.

Rationale for Fees
``````````````````

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 as in the ZSA Protocol.
Rationale for Matcher Fees
``````````````````````````

The Matcher Fees incentivize the Matcher to search through the unmatched Swap Orders and create Swap Bundles out of matching Orders.
It also compensates the Matcher for the Miner Fees that will arise when the constructed Swap Bundle is included in a transaction.
For the matching to be economically viable, the fees captured by the Matcher to create the Swap Bundle must at least be higher than the fees needed to settle the bundle on the chain.
We continue to use ZEC for these fees as well, since the benefit of an arbitrary Asset to a third-party matcher is unclear, and exposes the Matcher to the traded assets.
This exposure may pose regulatory issues for the Matcher (e.g. if specific assets are deemed illegal in specific jurisdictions).
It also provides a straightforward compensation for the Miner Fee outlay.
The fees being paid in ZEC also helps alleviate concerns about other Assets piggy-backing on the Zcash network without providing value to holders of ZEC.

Specification: Swap Orders
==========================
Expand Down Expand Up @@ -369,7 +361,7 @@ To support a Closed Ledger Order Book (CLOB)-like trading environment, the Order
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 :math:`\mathsf{d}` and diversified transmission key :math:`\mathsf{pk_d}` [#protocol-notes]_.

Each Order can be seen as an “invalid" ZSA transaction to oneself, which is unbalanced w.r.t each ZSA AssetBase.
Each Order can be seen as an “invalid" OrchardZSA 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.
Expand Down

0 comments on commit 3977a28

Please sign in to comment.