-
Notifications
You must be signed in to change notification settings - Fork 156
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reword, simplify, and update with newer understanding of ZSF balance
- Loading branch information
Showing
2 changed files
with
145 additions
and
333 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -13,6 +13,7 @@ | |
| Mark Henderson <[email protected]> | ||
| Tomek Piotrowski <[email protected]> | ||
| Mariusz Pilarek <[email protected]> | ||
| Paul Dann <[email protected]> | ||
| Original-Authors: Nathan Wilcox | ||
| Credits: | ||
| Status: Draft | ||
|
|
@@ -25,79 +26,44 @@ <h1 id="terminology">Terminology</h1> | |
| described in RFC 2119. [1]</p> | ||
| <p>The term “network upgrade” in this document is to be interpreted as | ||
| described in ZIP 200. [2]</p> | ||
| <p>“Block Subsidy” - the algorithmic issuance of ZEC on block creation – | ||
| part of the consensus rules. Split between the miner and the Dev Fund. | ||
| <p>“Block Subsidy” - the algorithmic issuance of ZEC on block creation. | ||
| Part of the consensus rules. Split between the miner and the Dev Fund. | ||
| Also known as Block Reward.</p> | ||
| <p>“Issuance” - The method by which unmined or unissued ZEC is converted | ||
| to ZEC available to users of the network</p> | ||
| <p>“We” - the ZIP authors, owners listed in the above front matter</p> | ||
| <p>“<code>MAX_MONEY</code>” is the ZEC supply cap. For simplicity, this | ||
| ZIP defines it to be <code>21,000,000 ZEC</code>, although this is | ||
| slightly larger than the actual supply cap of the original ZEC issuance | ||
| mechanism.</p> | ||
| <p>“Issuance” - The method by which ZEC becomes available for | ||
| circulation on the network.</p> | ||
| <p>“We” - the ZIP Owners and Authors, listed in the above front | ||
| matter.</p> | ||
| <p>“<code>MAX_MONEY</code>” is the total ZEC supply cap, defined as | ||
| 21,000,000 ZEC. This is slightly larger than the supply cap for the | ||
| current issuance mechanism, but is the value used in existing critical | ||
| consensus checks.</p> | ||
| <h1 id="abstract">Abstract</h1> | ||
| <p>This ZIP describes the motivation, the necessary changes for, and the | ||
| implementation specifications for the Zcash Sustainability Fund (ZSF). | ||
| The ZSF is a proposed alteration to the block rewards system and | ||
| accounting of unmined ZEC that allows for other sources of funding | ||
| besides unissued ZEC. This new mechanism for deposits – that new | ||
| applications or protocol designs can use to strengthen the long-term | ||
| sustainability of the network – will likely be an important step for | ||
| future economic upgrades, such as a transition to Proof of Stake or | ||
| Zcash Shielded Assets, and other potential protocol fees and user | ||
| applications.</p> | ||
| <p>The changes in this ZIP are ultimately minimal, only requiring for | ||
| the node to track state in the form of a <code>ZSF_BALANCE</code>, and | ||
| for a new transaction field to be added, called | ||
| <code>ZSF_DEPOSIT</code>. While wallet developer would be encouraged to | ||
| add the <code>ZSF_DEPOSIT</code> field to their UIs, no changes or new | ||
| behavior are absolutely required for developers or ZEC holders.</p> | ||
| <p>This ZIP does not change the current ZEC block subsidy issuance | ||
| schedule. Any additional amounts paid into the sustainability fund are | ||
| reserved for use in future ZIPs.</p> | ||
| <p>We propose defining the Zcash Sustainability Fund (ZSF) as: | ||
| <code>MAX_MONEY - ChainValue</code>, where <code>ChainValue</code> | ||
| includes all ZEC available on the network, across all value pools.</p> | ||
| <p>This definition is intended to support future mechanisms to | ||
| strengthen the long-term sustainability of the network. We anticipate | ||
| that this will lay important groundwork for future economic upgrades, | ||
| such as a transition to Proof of Stake or Zcash Shielded Assets, and | ||
| other potential protocol fees and user applications.</p> | ||
| <p>In addition, we propose a new transaction field, which would require | ||
| the introduction of a network upgrade. This field is required to support | ||
| a mechanism for depositing existing ZEC into the ZSF. From the | ||
| perspective of network users, this operation would be similar in concept | ||
| to the idea of “burning” ZEC, except that removing ZEC from circulation | ||
| increases the value of the ZSF by definition. Methods to make use of | ||
| these deposited funds will be proposed in future ZIPs.</p> | ||
| <p>While wallet developers would be encouraged to add support for ZSF | ||
| deposits to their UIs, no changes or new behavior are required for | ||
| developers or ZEC holders.</p> | ||
| <h1 id="motivation">Motivation</h1> | ||
| <p>The Zcash network’s operation and development relies fundamentally on | ||
| the block reward system inherited from Bitcoin. This system currently | ||
| looks like this:</p> | ||
| <ul> | ||
| <li>At Every New Block: | ||
| <ul> | ||
| <li>Miner and funding streams are rewarded a constant amount via | ||
| unissued ZEC (this constant amount halves at specified heights)</li> | ||
| <li>Miner is rewarded via Transaction fees | ||
| <code>(inputs - outputs)</code></li> | ||
| </ul></li> | ||
| </ul> | ||
| <p>The Zcash Sustainability Fund is a proposed replacement to that | ||
| payout mechanism, with the relevant parts in <em>bold</em> below:</p> | ||
| <ul> | ||
| <li><strong>Unmined ZEC is now accounted for as | ||
| <code>ZSF_BALANCE</code></strong></li> | ||
| <li><strong>Transaction includes optional contributions to ZSF via a | ||
| <code>ZSF_DEPOSIT</code> field</strong></li> | ||
| <li>Thus, at Every New Block: | ||
| <ul> | ||
| <li>Miner and funding streams rewarded the same constant amount, | ||
| <strong>but from <code>ZSF_BALANCE</code></strong> (this constant amount | ||
| still halves at specified heights)</li> | ||
| <li>Miner is rewarded via Transaction fees | ||
| <code>(inputs - outputs)</code>, <strong>where <code>outputs</code> | ||
| includes the <code>ZSF_DEPOSIT</code> amount</strong></li> | ||
| </ul></li> | ||
| </ul> | ||
| <p>For example, an end-user wallet application could have an option to | ||
| contribute a portion of a transaction to the ZSF, which would be | ||
| included in a <code>ZSF_DEPOSIT</code> field in the transaction, to be | ||
| taken into account by the Zcash nodes.</p> | ||
| <p>This quite simple alteration has – in our opinion – a multitude of | ||
| benefits:</p> | ||
| <ol type="1"> | ||
| <li><strong>Long Term Consensus Sustainability:</strong> This mechanism | ||
| supports long-term consensus sustainability by addressing concerns about | ||
| the sustainability of the network design shared by Bitcoin-like systems | ||
| through the establishment of deposits into the Sustainability Fund to | ||
| augment block rewards, ensuring long-term sustainability as the issuance | ||
| rate of Zcash drops and newly issued ZEC decreases over time.</li> | ||
| seeks to address concerns about the sustainability of the network design | ||
| shared by Bitcoin-like systems through the establishment of deposits | ||
| into the Sustainability Fund to augment block rewards, ensuring | ||
| long-term sustainability as the issuance rate of Zcash drops and newly | ||
| issued ZEC decreases over time.</li> | ||
| <li><strong>Benefits to ZEC Holders:</strong> Deposits to the ZSF slow | ||
| down the payout of ZEC, temporarily reducing its available supply, | ||
| benefiting current holders of unencumbered active ZEC in proportion to | ||
|
|
@@ -106,122 +72,58 @@ <h1 id="motivation">Motivation</h1> | |
| <li><strong>Recovery of “Soft-Burned” Funds:</strong> In some instances, | ||
| such as miners not claiming all available rewards, some ZEC goes | ||
| unaccounted for, though not formally burned. This proposal would recover | ||
| it through the <code>ZSF_BALANCE</code> mechanism described below.</li> | ||
| this unclaimed value, as it is already part of the ZSF if the proposed | ||
| definition of the ZSF is adopted.</li> | ||
| </ol> | ||
| <h1 id="specification">Specification</h1> | ||
| <p>In practice, The Zcash Sustainability Fund is a single global balance | ||
| maintained by the node state and contributed to via a single transaction | ||
| field. This provides the economic and security support described in the | ||
| motivation section, while also importantly keeping the fund payouts | ||
| extremely simple to describe and implement.</p> | ||
| <p>The two modifications are: 1. The re-accounting of unmined ZEC as a | ||
| node state field called <code>ZSF_BALANCE</code> 2. The addition of a | ||
| transaction field called <code>ZSF_DEPOSIT</code></p> | ||
| <h2 id="zsf_balance"><code>ZSF_BALANCE</code></h2> | ||
| <p>The ZEC issuance mechanism is re-defined to remove funds from | ||
| <code>ZSF_BALANCE</code>, which is initially set to | ||
| <code>MAX_MONEY</code> at the genesis block.</p> | ||
| <p>Consensus nodes are then required to track new per-block state:</p> | ||
| <ul> | ||
| <li><code>ZSF_BALANCE[height] : u64 [zatoshi]</code></li> | ||
| </ul> | ||
| <p>The state is a single 64 bit integer (representing units of | ||
| <code>zatoshi</code>) at any given block height, <span | ||
| class="math inline">height</span>, representing the Sustainability Fund | ||
| balance at that height. The <code>ZSF_BALANCE</code> can be calculated | ||
| using the following formula:</p> | ||
| <p><span class="math inline">$\mathsf{ZsfBalanceAfter}(\mathsf{height}) | ||
| = \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} | ||
| (\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - | ||
| \mathsf{BlockSubsidy}(h))$</span></p> | ||
| <p>where <span class="math inline">Unclaimed(height)</span> is the | ||
| portion of the block subsidy and miner fees that are unclaimed for the | ||
| block at the given height.</p> | ||
| <p>The block at height <span class="math inline">height</span> commits | ||
| to <span class="math inline">ZsfBalanceAfter(height)</span> as part of a | ||
| new block commitment in the block header, at the end of the | ||
| <code>hashBlockCommitments</code> chain in <a | ||
| href="https://zips.z.cash/zip-0244#block-header-changes">ZIP-244</a>.</p> | ||
| <p>TODO ZIP editors: consider introducing a chain state commitment hash | ||
| tree. (When we get closer to the network upgrade, we will have a better | ||
| idea what commitments that network upgrade needs.)</p> | ||
| <h2 id="deposits-into-the-sustainability-fund">Deposits into the | ||
| Sustainability Fund</h2> | ||
| <p>Sustainability fund deposits can be made via the new | ||
| <code>zsfDeposit</code> field. This can be done by: - ZEC fund holders, | ||
| in non-coinbase transactions; - Zcash miners, in coinbase | ||
| transactions.</p> | ||
| <p>In transaction versions without this new field: - unclaimed miner | ||
| fees and rewards in <strong>coinbase transactions</strong> are | ||
| re-defined as deposits into the sustainability fund, and - there are no | ||
| sustainability fund deposits from non-coinbase transactions.</p> | ||
| <p>Note: older transaction versions can continue to be supported after a | ||
| network upgrade. For example, NU5 supports both v4 and v5 transaction | ||
| formats, for both coinbase and non-coinbase transactions.</p> | ||
| <h3 id="zsfdeposit-fields-in-transactions"><code>zsfDeposit</code> | ||
| fields in transactions</h3> | ||
| <p>Each transaction can dedicate some of its excess funds to the ZSF, | ||
| and the remainder becomes the miner fee, with any excess miner | ||
| fee/reward going to the ZSF</p> | ||
| <p>The modifications required are:</p> | ||
| <ol type="1"> | ||
| <li>A mechanism to calculate the current balance of the ZSF.</li> | ||
| <li>The addition of a transaction field representing an amount to | ||
| deposit into the ZSF.</li> | ||
| <li>The consideration of ZSF deposit as an output for a given | ||
| transaction, e.g. inclusion in fee calculation.</li> | ||
| </ol> | ||
| <h2 id="current-zsf-balance">Current ZSF Balance</h2> | ||
| <p>This calculation simply involves summing all active value pools, and | ||
| subtracting this total from `MAX_MONEY’.</p> | ||
| <h2 id="deposits-into-the-zsf">Deposits into the ZSF</h2> | ||
| <p>Each transaction can dedicate some of its funds to the ZSF, and the | ||
| remainder becomes the miner fee, with any unclaimed miner reward or fee | ||
| going to the ZSF.</p> | ||
| <p>This is achieved by adding a new field to the common transaction | ||
| fields [#zip-0225-transaction-format]:</p> | ||
| <pre><code>zsfDeposit : u64 [zatoshi]</code></pre> | ||
| <p>In transaction versions without this new field:</p> | ||
| <ul> | ||
| <li><code>zsfDeposit : u64 [zatoshi]</code></li> | ||
| <li>Unclaimed miner fees and rewards in <strong>coinbase</strong> | ||
| transactions are re-defined as deposits into the Sustainability | ||
| Fund.</li> | ||
| <li>There are no Sustainability Fund deposits from | ||
| <strong>non-coinbase</strong> transactions.</li> | ||
| </ul> | ||
| <p>The <code>ZSF_BALANCE[H]</code> for a block at height <code>H</code> | ||
| can be calculated given a value of <code>ZSF_BALANCE[H-1]</code> and the | ||
| set of transactions contained in that block. First, the | ||
| <code>ZSF_DEPOSIT[H]</code> is calculated based solely on | ||
| <code>ZSF_BALANCE[H-1]</code>. This is subtracted from the previous | ||
| block’s balance to be distributed as part of the block reward. Second, | ||
| the sum of all the <code>ZSF_DEPOSIT</code> fields of all transactions | ||
| in the block is added to the balance.</p> | ||
| <h3 id="non-coinbase-transactions">Non-Coinbase Transactions</h3> | ||
| <p>If the <code>ZSF_DEPOSIT</code> field is not present in an older | ||
| transaction version, it is defined to be zero for non-coinbase | ||
| <p><strong>Note:</strong> older transaction versions can continue to be | ||
| supported after a network upgrade. For example, NU5 supports both v4 and | ||
| v5 transaction formats, for both coinbase and non-coinbase | ||
| transactions.</p> | ||
| <h4 id="consensus-rule-changes">Consensus Rule Changes</h4> | ||
| <ul> | ||
| <li>Transparent inputs to a transaction insert value into a transparent | ||
| transaction value pool associated with the transaction. Transparent | ||
| outputs <strong>and sustainability fund deposits</strong> remove value | ||
| from this pool.</li> | ||
| </ul> | ||
| <h3 id="coinbase-transactions">Coinbase Transactions</h3> | ||
| <p>Any excess miner fee/reward is sent to the ZSF.</p> | ||
| <p>In new blocks, this deposit is tracked via the | ||
| <code>ZSF_DEPOSIT</code> field in coinbase transactions.</p> | ||
| <p>If the <code>ZSF_DEPOSIT</code> field is not present in a coinbase | ||
| transaction with an older transaction version, it is defined as the | ||
| value of any unspent miner fee and miner reward. This re-defines these | ||
| previously unspendable funds as ZSF deposits.</p> | ||
| <h4 id="consensus-rule-changes-1">Consensus Rule Changes</h4> | ||
| <ul> | ||
| <li>The remaining value in the transparent transaction value pool of a | ||
| coinbase transaction is <strong>deposited in the sustainability | ||
| fund</strong>.</li> | ||
| </ul> | ||
| <h3 id="zsf_deposit-requirements"><code>ZSF_DEPOSIT</code> | ||
| Requirements</h3> | ||
| <h2 id="consensus-rule-changes">Consensus Rule Changes</h2> | ||
| <p>ZSF deposits must now be included when calculating the total output | ||
| value of a transaction. They should be treated similarly to a | ||
| transparent output.</p> | ||
| <h2 id="transaction-format-requirements">Transaction Format | ||
| Requirements</h2> | ||
| <ul> | ||
| <li>ZIP 230 [3] must be updated to include | ||
| <code>ZSF_DEPOSIT</code>.</li> | ||
| <li>ZIP 244 [4] must be updated as well to include | ||
| <code>ZSF_DEPOSIT</code>.</li> | ||
| <li>ZIP 230 [3] must be updated to include the new | ||
| <code>zsfDeposit</code> field.</li> | ||
| <li>ZIP 244 [4] must be updated as well to include the new | ||
| <code>zsfDeposit</code> field.</li> | ||
| </ul> | ||
| <h1 id="rationale">Rationale</h1> | ||
| <p>All technical decisions in this ZIP are balanced between the | ||
| necessary robustness of the ZSF mechanics, and simplicity of | ||
| implementation.</p> | ||
| <h2 id="zsf_balance-as-node-state"><code>ZSF_BALANCE</code> as node | ||
| state</h2> | ||
| <p>Tracking the <code>ZSF_BALANCE</code> value as a node state using the | ||
| above formula is very simple in terms of implementation, and should work | ||
| correctly given that the node implementations calculate the value | ||
| according to the specifications.</p> | ||
| <h2 | ||
| id="zsf_deposit-as-explicit-transaction-field"><code>ZSF_DEPOSIT</code> | ||
| as explicit transaction field</h2> | ||
| <h2 id="new-transaction-field-for-zsf-deposit">New transaction field for | ||
| ZSF deposit</h2> | ||
| <p>An explicit value distinguishes the ZEC destined to Sustainability | ||
| Fund deposits from the implicit transaction fee. Explicitness also | ||
| ensures any arithmetic flaws in any implementations are more likely to | ||
|
|
||
Oops, something went wrong.