zcash · daira · Aug 27, 2024 · Jul 31, 2023 · Jul 31, 2023 · Jul 31, 2023
diff --git a/draft-zsf.html b/draft-zsf.html
@@ -0,0 +1,273 @@
+<!DOCTYPE html>
+<html>
+<head>
+    <title>Draft zsf: Establish the Zcash Sustainability Fund on the Protocol Level</title>
+    <meta charset="utf-8" />
+    <script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
+    <meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css">
+</head>
+<body>
+<pre><code>ZIP: 
+Title: Establish the Zcash Sustainability Fund on the Protocol Level
+Owners: Jason McGee &lt;jason@shieldedlabs.com&gt;
+        Mark Henderson &lt;mark@equilibrium.co&gt;
+        Tomek Piotrowski &lt;tomek@eiger.co&gt;
+        Mariusz Pilarek &lt;mariusz@eiger.co&gt;
+Original-Authors: Nathan Wilcox
+Credits: Nathan Wilcox
+         Mark Henderson
+         Jason McGee
+         Tomek Piotrowski
+         Mariusz Pilarek
+Status: Draft
+Category: Ecosystem
+Created: 2023-08-
+License: BSD-2-Clause</code></pre>
+<h1 id="terminology">Terminology</h1>
+<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
+“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as
+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>The term “Block Rewards” refers to the algorithmic issuance of ZEC to
+every block’s creator – part of the consensus rules.</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>
+<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>
+<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 sometihng like this:</p>
+<ul>
+<li>At Every New Block:
+<ul>
+<li>Miner rewarded via unissued ZEC</li>
+<li>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 still rewarded <strong>from
+<code>ZSF_BALANCE</code></strong></li>
+<li>Transaction fees <code>(inputs - outputs)</code>, <strong>including
+the <code>ZF_DEPOSIT</code> amount</strong></li>
+</ul></li>
+</ul>
+<p>This design gives similar clarity and algorithmic control benefits,
+while also allowing other sources of funds for Block Rewards in addition
+to newly issued ZEC, via ZSF Deposits.</p>
+<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 ZIP is explicitly agnostic as to the recipients of block rewards
+so that acceptance or adoption of the Sustainability Fund does not
+introduce or bundle reallocation decisions with the primary
+proposal.</p>
+<p>This quite simple alternation 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 and eventually replace 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
+their holdings without requiring them to opt into any scheme,
+introducing extra risk, active oversight, or accounting complexity.</li>
+<li><strong>Network Sustainability:</strong> This mechanism involves
+temporarily reducing the supply of ZEC similar to asset burning in
+Ethereum’s EIP-1559, but with potential long-term sustainability
+benefits as the redistribution of deposits contributes to issuance
+rewards and network development, making it an attractive option for
+current and future Zcash users.</li>
+<li><strong>Reduce “Governance Attack Surface”:</strong> The proposal’s
+policies aim to enhance predictability, financial sustainability, and
+minimize governance capture risks, ensuring Zcash’s successful evolution
+as a global currency with a growing userbase and stakeholdership.</li>
+<li><strong>Ecosystem Benefits of Longer Time Horizons:</strong> A
+reliable and long-term functioning Zcash blockchain allows users to make
+secure long-term plans, leading to a sustainable and virtuous adoption
+cycle, rather than being influenced by short-term trends.</li>
+<li><strong>Consensus Continuity During Lulls:</strong> Rate-limited
+payouts from the Sustainability Fund help maintain blockchain security
+during periods of low activity by utilizing savings from high activity
+periods, whereas direct miner rewards tied to short-term activity may
+favor miners with significant savings reserves or access to credit,
+reducing mining competitiveness and overall ecosystem certainty about
+mining capacity.</li>
+<li><strong>Mitigate Payment-to-Self Vulnerabilities:</strong> The risk
+of miners benefiting from “spoofing” transactions and the desire for a
+fixed eventual supply goal lead to considering alternatives like the
+Sustainability Fund, which pays out fees over a long enough time horizon
+to prevent recouping costs, allowing Zcash to remain closer to its
+supply goal and offering an alternative to other protocol designs that
+destroy or burn funds.</li>
+<li><strong>Recovery of “Soft-Burned” Funds:</strong> In some instances,
+such as miners not claim 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>
+</ol>
+<p><em>Disclaimer 1: Long term success depends on the specific
+mechanisms of deposits, the quantities involved, and broader economic
+considerations. For such as if the payout rate is both sufficient and
+not excessive enough to threaten sustainability.</em></p>
+<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>
+<p>Please note that a <strong>network upgrade is required</strong> for
+this work to be fully implemented.</p>
+<h2 id="zsf_balance"><code>ZSF_BALANCE</code></h2>
+<p>Upon activation at height <code>H</code>, the ZEC issuance mechanism
+is permanently suspended, the value of <code>ZSF_BALANCE[H]</code> is
+set to the remainder of unissued ZEC. This must be done before the
+<code>Block Rewards Payout Rule</code> is enforced for the block at
+height <code>H</code>. <strong>This is not a pre-mine.</strong> This is
+simply a re-accounting of unissued ZEC that comes with the benefit of
+other possible sources of funding.</p>
+<p>Consensus nodes are then required to track new per-block state:</p>
+<ul>
+<li><code>ZSF_BALANCE[H] : 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, <code>H</code>,
+representing the Sustainability Fund balance at that height,
+<code>H</code>. The <code>ZSF_BALANCE</code> can be calculated using the
+following formula:</p>
+<p><code>TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS</code></p>
+<p>This formula holds for all future blocks. It is safe and semantically
+consistent to consider all blocks prior to the activation height to have
+a value of <code>0</code> in this field. This is not required by this
+proposal but may be convenient in designs or implementations.</p>
+<h3 id="zsf_balance-requirements"><code>ZSF_BALANCE</code>
+Requirements</h3>
+<ul>
+<li>The value of <code>ZSF_BALANCE</code> SHOULD equal <code>0</code>
+for all blocks prior to the activation height <code>H</code>.</li>
+<li>The above described formula
+<code>TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS</code>
+MUST hold for all future blocks.</li>
+<li>Future protocol changes MUST NOT reduce or redistribute the funds in
+the ZSF, and they may not increase the payout rate to a reasonable
+approximation beyond the four year half-life constraint.</li>
+</ul>
+<h2 id="zsf_deposit"><code>ZSF_DEPOSIT</code></h2>
+<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>This is achieved by adding a new field to all transactions:</p>
+<ul>
+<li><code>ZSF_DEPOSIT : u64 [zatoshi]</code></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>
+<p>It is safe and consistent to treat older transactions using
+pre-Sustainability Fund formats as if they have this field implicitly
+present with a value of 0 where that simplifies designs or
+implementations.</p>
+<p>Note: this field is not generally considered an “output” because it
+differs from other outputs in several significant ways:</p>
+<ul>
+<li>All <code>ZSF_DEPOSIT</code> fields contribute to a single global
+balance rather than a user-specific output state,</li>
+<li>Consensus validation can account for this field by updating
+<code>ZSF_BALANCE[H]</code> and do not need to track any transaction
+field specific state after this accounting in contrast to e.g. UTXOs
+which must be tracked until spent.</li>
+<li>This field does not contribute to the transaction graph of senders
+or recipients whether transparent or protected by cryptography.</li>
+</ul>
+<h3 id="zsf_deposit-requirements"><code>ZSF_DEPOSIT</code>
+Requirements</h3>
+<ul>
+<li>There MUST be only one <code>ZSF_DEPOSIT</code> field per
+transaction</li>
+<li>ZIP 225 [3] MUST be updated to include <code>ZSF_DEPOSIT</code>. ZIP
+244 MAY be updated as well.</li>
+<li>Separate programming language implementations (C++, Rust, etc) MUST
+guarantee that the calculations described above are consistent</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>
+<h3 id="alternative-zsf_balance-as-block-header-commitment">Alternative:
+<code>ZSF_BALANCE</code> as block header commitment</h3>
+<p>An alternative to node state could be to include the
+<code>ZSF_BALANCE</code> field as a block header and require a block
+header commitment.</p>
+<p>Requiring block-header-rooted commitments of global fund balances
+such as the Sustainability Fund ensures that any consensus deviating
+bugs in accounting of this balance are immediately detected in the
+earliest impacted block. It also removes some of the need for explorer
+sites and other analytics services from tracking this value
+independently, assuming the committed value is made available by common
+APIs. This helps ensure that all explorers track and report the correct
+value.</p>
+<h2
+id="zsf_deposit-as-explicit-transaction-field"><code>ZSF_DEPOSIT</code>
+as explicit transaction field</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
+be observed and caught immediately.</p>
+<h1 id="references">References</h1>
+<p><strong>[1]: <a
+href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in
+RFCs to Indicate Requirement Levels</a></strong></p>
+<p><strong>[2]: <a href="https://zips.z.cash/zip-0200">ZIP 200: Network
+Upgrade Mechanism</a></strong></p>
+<p><strong>[3]: <a href="https://zips.z.cash/zip-0225">ZIP 225: Version
+5 Transaction Format</a></strong></p>
+</body>
+</html>