Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ZSA][Fees] Refactoring the ZSA Fees #71

Open
wants to merge 1 commit into
base: zsa_fees
Choose a base branch
from
Open

[ZSA][Fees] Refactoring the ZSA Fees #71

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 21 additions & 14 deletions rendered/zip-0317.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@
Jonathan Rouach
Pablo Kogan
Vivek Arte
Status: Draft
Status: Revision 0: Active, Revision 1: Draft
Category: Standards / Wallet
Obsoletes: ZIP 313
Created: 2022-08-15
Expand All @@ -39,27 +39,34 @@
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users.</p>
<p>This ZIP also explicitly defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 <a id="footnote-reference-5" class="footnote_reference" href="#zip-0226">6</a> and ZIP 227 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0227">7</a>.</p>
<p>Revision 1 of this ZIP additionally defines the fee mechanism associated with the Zcash Shielded Assets (ZSA) protocol as described in ZIP 226 <a id="footnote-reference-5" class="footnote_reference" href="#zip-0226">6</a> and ZIP 227 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0227">7</a>.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In light of recent Mainnet network activity, it is time to review and update the standard 1,000 zatoshi transaction fee set in ZIP 313 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0313">8</a>.</p>
<p>The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as specified in ZIP 313. This allowed exploration of novel use cases of the Zcash blockchain. The Zcash network has operated for almost 2 years at a conventional transaction fee of 1,000 zatoshis, without consideration for the total number of inputs and outputs in each transaction. Under this conventional fee, some usage of the chain has been characterized by high-output transactions with 1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.</p>
<p>The objective of the new fee policy, once it is enforced, is for fees paid by transactions to fairly reflect the processing costs that their inputs and outputs impose on various participants in the network. This will tend to discourage usage patterns that cause either intentional or unintentional denial of service, while still allowing low fees for regular transaction use cases.</p>
<p>The proposed upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol <a id="footnote-reference-8" class="footnote_reference" href="#zip-0226">6</a>, as well as additional considerations for the issuance protocol <a id="footnote-reference-9" class="footnote_reference" href="#zip-0227">7</a> such as fees for asset issuance.</p>
<p>Specifically, the ZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. When it comes to Issuance of ZSA, however, we believe that there should be a disincentive that will stop users from flooding the chain with useless asset identifiers.</p>
<p>In the case of Issuance, the computational power needed to verify the bundle is not large. The transaction size, however, can be an issue as the number of output notes can be large. Furthermore, as defined in ZIP 227 <a id="footnote-reference-10" class="footnote_reference" href="#zip-0227">7</a>, there is an additional data structure in the global state that needs to be maintained as part of the consensus. This motivates further the addition of an Issuance-specific fee.</p>
<section id="revision-1"><h3><span class="section-heading">Revision 1:</span><span class="section-anchor"> <a rel="bookmark" href="#revision-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The upgrade to the ZSA protocol will also need to define a fee structure consistent with the above objectives. This involves adaptation for the transfer protocol <a id="footnote-reference-8" class="footnote_reference" href="#zip-0226">6</a>, as well as additional considerations for the issuance protocol <a id="footnote-reference-9" class="footnote_reference" href="#zip-0227">7</a> such as fees for asset issuance.</p>
<p>Specifically, the ZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. When it comes to Issuance of ZSA, however, there should be a disincentive that will stop users from flooding the chain with useless asset identifiers.</p>
<p>In the case of Issuance, the computational power needed to verify the bundle is not large. The transaction size, however, can be an issue as the number of output notes can be large. Furthermore, as defined in ZIP 227 <a id="footnote-reference-10" class="footnote_reference" href="#zip-0227">7</a>, there is an additional data structure in the global state that needs to be maintained as part of the consensus. This motivates further the addition of an Issuance-specific fee.</p>
</section>
</section>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>The conventional fee formula should not favour or discriminate against any of the Orchard, Sapling, or transparent protocols.</li>
<li>The fee for a transaction should scale linearly with the number of inputs and/or outputs.</li>
<li>Users should not be penalised for sending transactions constructed with padding of inputs and outputs to reduce information leakage. (The default policy employed by zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool used by the transaction).</li>
<li>Users should be able to spend a small number of UTXOs or notes with value below the marginal fee per input.</li>
<li>Post the upgrade to the ZSA protocol, users should be discouraged from issuing new “garbage” custom Assets.</li>
<li>Post the upgrade to the ZSA protocol, users should be discouraged from finalizing Assets frivolously.</li>
<li>Revision 1: Users should be discouraged from issuing new “garbage” custom Assets. The fee should reflect the cost of adding new data to the global state.</li>
</ul>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="revisions"><h3><span class="section-heading">Revisions</span><span class="section-anchor"> <a rel="bookmark" href="#revisions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>Revision 0: The initial version of this specification.</li>
<li>Revision 1: This version adds to the fees mechanism post the adoption of the ZSA Protocol. It adds additional fee considerations for the issuance and finalization of custom Zcash Shielded Assets.</li>
</ul>
</section>
<section id="notation"><h3><span class="section-heading">Notation</span><span class="section-anchor"> <a rel="bookmark" href="#notation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(\mathsf{min}(a, b)\)</span>
Expand Down Expand Up @@ -285,7 +292,7 @@
</details></section>
</section>
</section>
<section id="zsa-fee-calculation"><h3><span class="section-heading">ZSA Fee calculation</span><span class="section-anchor"> <a rel="bookmark" href="#zsa-fee-calculation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="revision-1-zsa-fee-calculation"><h3><span class="section-heading">Revision 1: ZSA Fee calculation</span><span class="section-anchor"> <a rel="bookmark" href="#revision-1-zsa-fee-calculation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In addition to the parameters defined in the <a href="#fee-calculation">Fee calculation</a> section, the ZSA protocol upgrade defines the following additional parameters:</p>
<table>
<thead>
Expand All @@ -301,7 +308,7 @@
<span class="math">\(issuance\_fee\)</span>
</td>
<td>
<span class="math">\(1000000\)</span>
<span class="math">\(100 \cdot marginal\_fee\)</span>
</td>
<td>zatoshis per issuance action (as defined below)</td>
</tr>
Expand All @@ -310,7 +317,7 @@
<span class="math">\(finalize\_fee\)</span>
</td>
<td>
<span class="math">\(1000000\)</span>
<span class="math">\(20 \cdot marginal\_fee\)</span>
</td>
<td>zatoshis per issuance action (as defined below)</td>
</tr>
Expand All @@ -323,7 +330,7 @@
zsa\_logical\_actions &amp;=&amp; logical\_actions \;+ \\
&amp; &amp; nTotalOutputsZsaIssuance \\
zsa\_conventional\_fee &amp;=&amp; marginal\_fee \cdot \mathsf{max}(grace\_actions, zsa\_logical\_actions) \;+ \\
&amp; &amp; issuance\_fee \cdot nIssueActions \;+ \\
&amp; &amp; issuance\_fee \cdot nIssueActions \;- \\
&amp; &amp; finalize\_fee \cdot nFinalizeActions
\end{array}\)</div>
<p>The inputs to this formula are taken from transaction fields defined in the Zcash protocol specification <a id="footnote-reference-13" class="footnote_reference" href="#protocol-txnencoding">3</a>. They are defined in the <a href="#fee-calculation">Fee calculation</a> section above, with additional definitions in the table below. Note that
Expand Down Expand Up @@ -562,8 +569,8 @@
</ul>
<p><cite>zebra</cite> uses a similar relay threshold rule to <cite>zcashd</cite>, but additionally enforces a minimum fee of 100 zatoshis (this differs from <cite>zcashd</cite> only for valid transactions of less than 1000 bytes, assuming that <cite>zcashd</cite> uses its default value for <code>-minrelaytxfee</code>).</p>
</section>
<section id="deployment-of-zsa-changes"><h3><span class="section-heading">Deployment of ZSA changes</span><span class="section-anchor"> <a rel="bookmark" href="#deployment-of-zsa-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 <a id="footnote-reference-18" class="footnote_reference" href="#zip-0226">6</a> and ZIP 227 <a id="footnote-reference-19" class="footnote_reference" href="#zip-0227">7</a>), which is currently projected to be with Network Upgrade 6.</p>
<section id="revision-1-deployment-of-zsa-changes"><h3><span class="section-heading">Revision 1: Deployment of ZSA changes</span><span class="section-anchor"> <a rel="bookmark" href="#revision-1-deployment-of-zsa-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The parts of this ZIP that list out changes to the fee mechanism for the ZSA protocol SHOULD be deployed at the time of the deployment of the ZSA protocol (ZIP 226 <a id="footnote-reference-18" class="footnote_reference" href="#zip-0226">6</a> and ZIP 227 <a id="footnote-reference-19" class="footnote_reference" href="#zip-0227">7</a>), which is currently projected to be with Network Upgrade 7.</p>
</section>
</section>
<section id="considered-alternatives"><h2><span class="section-heading">Considered Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#considered-alternatives"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
Expand Down Expand Up @@ -592,7 +599,7 @@
<span class="math">\(grace\_actions\)</span>
threshold. This is no longer expressible with the formula specified above.)</p>
</section>
<section id="zsa-fee-considerations"><h2><span class="section-heading">ZSA Fee Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#zsa-fee-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="revision-1-zsa-fee-considerations"><h2><span class="section-heading">Revision 1: ZSA Fee Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#revision-1-zsa-fee-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>We choose to maintain the native ZEC Asset as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.</p>
<p>An alternative proposal for the ZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.</p>
</section>
Expand Down
Loading