[ZIP 234] Smooth Out The Block Subsidy Issuance

draft-issuance.html

@@ -0,0 +1,107 @@
+<p><code>ZIP: 
+Title: Smooth Out The Block Subsidy Issuance
+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:
+Status: Draft
+Category: Consensus
+Created: 2023-08-23
+License: BSD-2-Clause</code></p>
+<h1>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>"Network upgrade" - to be interpreted as described in ZIP 200. [2]</p>
+<p>“Block Subsidy” - to be interpreted as described in the Zcash Protocol Specification (TODO ZIP Editors: link from comment).</p>
+<p>“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out if this definition is correct or can be removed).</p>
+<p>“<code>ZsfBalanceAfter(h)</code>” is the total ZEC available in the Zcash Sustainability Fund (ZSF) after the transactions
+in block <code>h</code>, described in ZIP draft-zsf.md. In this ZIP, the Sustainability Fund is used to pay out Block Subsidies
+from unmined ZEC, and other fund deposits.</p>
+<p>Let <code>PostBlossomHalvingInterval</code> be as defined in [#protocol-diffadjustment]_.</p>
+<h1>Abstract</h1>
+<p>This ZIP proposes a change to how nodes calculate the block subsidy.</p>
+<p>Instead of following a step function around the 4-year halving intervals inherited
+from Bitcoin, we propose a slow exponential “smoothing” of the curve. The new issuance
+scheme would approximate the current issuance over 4-year intervals.</p>
+<h1>Motivation</h1>
+<p>The current Zcash economic model, inherited from Bitcoin, includes a halving mechanism which dictates the issuance of new coins. While this has been foundational, halvings can lead to abrupt changes in the rate of new coins being introduced to the market. Such sudden shifts can potentially disrupt the network's economic model, potentially impacting its security and stability.</p>
+<p>To address this, we propose smoothing out the issuance curve of ZEC, ensuring a more consistent and predictable rate of coin issuance, while still preserving the overall supply cap of 21,000,000 coins. This modification does not seek to change the core aspects of Zcash's issuance policy. Instead, it solely aims to enhance predictability and avoid sudden changes. By making this shift, the average block subsidy over time will remain consistent, and the funds for block subsidies will be available for a similar duration.</p>
+<p>Additionally, the current Bitcoin-style issuance does not take into account the current balance of <code>ZsfBalanceAfter(h)</code>. If [#draft-zsf]_ were to activate without a change to the issuance mechanism, then some funds would never be disbursed after they are deposited back into the ZSF.</p>
+<p>In summary, by introducing a smoother emissions curve, we:
+- maintain the economic viability of Zcash
+- provide clarity on distribution of deposits into the ZSF
+- enhance Zcash's stability as the network evolves.</p>
+<h1>Requirements</h1>
+<p>Smoothing the issuance curve is possible using an exponential decay formula that
+satisfies the following requirements:</p>
+<h2>Issuance Requirements</h2>
+<ol>
+<li>The issuance can be summarised into a reasonably simple explanation</li>
+<li>Block subsidies approximate a continuous function</li>
+<li>If there are funds in the ZSF, then the block subsidy must be non-zero, preventing any final “unmined” zatoshis</li>
+<li>For any 4 year period, all paid out block subsidies are approximately equal to half of the ZSF at the beginning of that 4 year period, if there are no deposits into the ZSF during those 4 years
+TODO daira: add a requirement that makes the initial total issuance match the previous total issuance  </li>
+<li>This functionality MUST be introduced as part of a network upgrade</li>
+</ol>
+<h1>Specification</h1>
+<h2>Constants</h2>
+<p>Define constants:</p>
+<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 41 / 100,000,000 or <code>0.00000041</code></p>
+<h2>Issuance Calculation</h2>
+<p>Given the block height <code>h</code> define a function <strong>BlockSubsidy(h)</strong>, such that:</p>
+<p><strong>BlockSubsidy(h)</strong> = Block subsidy for a given <code>h</code>, that satisfies above requirements.</p>
+<p>Using an exponential decay function for <strong>BlockSubsidy</strong> satisfies requirements <strong>R1</strong> and <strong>R2</strong> above:</p>
+<p><code>BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)</code></p>
+<p>Finally, to satisfy <strong>R3</strong> above we always round up to the next zatoshi.</p>
+<p><code>BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))</code></p>
+<h1>Rationale</h1>
+<h2><code>BLOCK_SUBSIDY_FRACTION</code></h2>
+<p>Let <code>IntendedZSFFractionRemainingAfterFourYears</code> = 0.5.</p>
+<p>The value <code>41 / 100_000_000</code> satisfies the approximation:</p>
+<p><code>(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears</code></p>
+<p>Meaning after a period of 4 years around half of <code>ZSF_BALANCE</code> will be paid out
+as block subsidies, thus satisfying <strong>R4</strong>.</p>
+<h2>Visualization of the Smoothed Curve</h2>
+<p>The following graph, taken from the ECC blog post, illustrates the smoothed curve. Note that depending on when the network upgrade takes place the disbursement may temporarily <em>increase</em>.</p>
+<p><img alt="A graph showing a comparison of the halving-based step function vs the smoothed curve" src="./draft-zip-smoothed-issuance-curve.png" /></p>
+<h2>Other Notes</h2>
+<p>The suggested implementation avoids using float numbers. Rust and C++ will both round
+the result of the final division up, satisfying <strong>R3</strong> above.</p>
+<h1>Appendix: Simulation</h1>
+<p>We encourage readers to run the following Rust code, which simulates block subsidies.
+According to this simulation, assuming no deflationary action, block subsidies would
+last for approximately 113 years:</p>
+<h2>Rust Code</h2>
+<p>```rust
+fn main() {
+    // approximate available subsidies in August of 2023
+    let mut available_subsidies: i64 = 4671731 * 100_000_000;
+    let mut block: u32 = 0;</p>
+<pre><code>while available_subsidies &gt; 0 { 
+    let block_subsidy = (available_subsidies * 41 + 99_999_999) / 100_000_000;
+    available_subsidies -= block_subsidy;
+
+    println!(
+        "{} ({} years): {}({} ZEC) {}({} ZEC)",
+        block,                             // current block
+        block / 420_768,                   // ~ current year
+        block_subsidy,                     // block subsidy in zatoshis
+        block_subsidy / 100_000_000,       // block subsidy in ZEC
+        available_subsidies,               // available subsidies in zatoshis
+        available_subsidies / 100_000_000  // available subsidies in ZEC
+    );
+
+    block += 1;
+}
+</code></pre>
+<p>}
+```</p>
+<p>Last line of output of the above program is:</p>
+<p><code>47699804 (113 years): 1(0 ZEC) 0(0 ZEC)</code></p>
+<p>Note the addition of 99,999,999 before division to force rounding up of non-zero values.</p>
+<h1>References</h1>
+<p>[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119</p>
+<p>[2] ZIP-200: https://zips.z.cash/zip-0200</p>
+<p>[3] ZIP-XXX: Placeholder for the ZSF ZIP</p>

draft-issuance.md

@@ -0,0 +1,162 @@
+```
+ZIP: 
+Title: Smooth Out The Block Subsidy Issuance
+Owners: Jason McGee <jason@shieldedlabs.com>
+        Mark Henderson <mark@equilibrium.co>
+        Tomek Piotrowski <tomek@eiger.co>
+        Mariusz Pilarek <mariusz@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits:
+Status: Draft
+Category: Consensus
+Created: 2023-08-23
+License: BSD-2-Clause
+```
+
+# Terminology
+
+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]
+
+"Network upgrade" - to be interpreted as described in ZIP 200. [2]
+
+“Block Subsidy” - to be interpreted as described in the Zcash Protocol Specification (TODO ZIP Editors: link from comment).
+
+“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out if this definition is correct or can be removed).
+
+“`ZsfBalanceAfter(h)`” is the total ZEC available in the Zcash Sustainability Fund (ZSF) after the transactions
+in block `h`, described in ZIP draft-zsf.md. In this ZIP, the Sustainability Fund is used to pay out Block Subsidies
+from unmined ZEC, and other fund deposits.
+
+Let `PostBlossomHalvingInterval` be as defined in [#protocol-diffadjustment]_.
+
+
+# Abstract
+
+This ZIP proposes a change to how nodes calculate the block subsidy.
+
+Instead of following a step function around the 4-year halving intervals inherited
+from Bitcoin, we propose a slow exponential “smoothing” of the curve. The new issuance
+scheme would approximate the current issuance over 4-year intervals.
+
+# Motivation
+
+The current Zcash economic model, inherited from Bitcoin, includes a halving mechanism which dictates the issuance of new coins. While this has been foundational, halvings can lead to abrupt changes in the rate of new coins being introduced to the market. Such sudden shifts can potentially disrupt the network's economic model, potentially impacting its security and stability.
+
+To address this, we propose smoothing out the issuance curve of ZEC, ensuring a more consistent and predictable rate of coin issuance, while still preserving the overall supply cap of 21,000,000 coins. This modification does not seek to change the core aspects of Zcash's issuance policy. Instead, it solely aims to enhance predictability and avoid sudden changes. By making this shift, the average block subsidy over time will remain consistent, and the funds for block subsidies will be available for a similar duration.
+
+Additionally, the current Bitcoin-style issuance does not take into account the current balance of `ZsfBalanceAfter(h)`. If [#draft-zsf]_ were to activate without a change to the issuance mechanism, then some funds would never be disbursed after they are deposited back into the ZSF.
+
+In summary, by introducing a smoother emissions curve, we:
+- maintain the economic viability of Zcash
+- provide clarity on distribution of deposits into the ZSF
+- enhance Zcash's stability as the network evolves.
+
+# Requirements
+
+Smoothing the issuance curve is possible using an exponential decay formula that
+satisfies the following requirements:
+
+## Issuance Requirements
+
+1. The issuance can be summarised into a reasonably simple explanation
+2. Block subsidies approximate a continuous function
+3. If there are funds in the ZSF, then the block subsidy must be non-zero, preventing any final “unmined” zatoshis
+4. For any 4 year period, all paid out block subsidies are approximately equal to half of the ZSF at the beginning of that 4 year period, if there are no deposits into the ZSF during those 4 years
+TODO daira: add a requirement that makes the initial total issuance match the previous total issuance  
+5. This functionality MUST be introduced as part of a network upgrade
+
+
+# Specification
+
+## Constants
+
+Define constants:
+
+“`BLOCK_SUBSIDY_FRACTION`” = 41 / 100,000,000 or `0.00000041`
+
+## Issuance Calculation
+
+Given the block height `h` define a function **BlockSubsidy(h)**, such that:
+
+**BlockSubsidy(h)** = Block subsidy for a given `h`, that satisfies above requirements.
+
+Using an exponential decay function for **BlockSubsidy** satisfies requirements **R1** and **R2** above:
+
+`BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)`
+
+Finally, to satisfy **R3** above we always round up to the next zatoshi.
+
+`BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))`
+
+# Rationale
+
+## `BLOCK_SUBSIDY_FRACTION`
+
+Let `IntendedZSFFractionRemainingAfterFourYears` = 0.5.
+
+The value `41 / 100_000_000` satisfies the approximation:
+
+`(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears`
+
+Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out
+as block subsidies, thus satisfying **R4**.
+
+## Visualization of the Smoothed Curve
+
+The following graph, taken from the ECC blog post, illustrates the smoothed curve. Note that depending on when the network upgrade takes place the disbursement may temporarily _increase_.
+
+![A graph showing a comparison of the halving-based step function vs the smoothed curve](./draft-zip-smoothed-issuance-curve.png)
+
+## Other Notes
+
+The suggested implementation avoids using float numbers. Rust and C++ will both round
+the result of the final division up, satisfying **R3** above.
+
+# Appendix: Simulation
+
+We encourage readers to run the following Rust code, which simulates block subsidies.
+According to this simulation, assuming no deflationary action, block subsidies would
+last for approximately 113 years:
+
+## Rust Code
+
+```rust
+fn main() {
+    // approximate available subsidies in August of 2023
+    let mut available_subsidies: i64 = 4671731 * 100_000_000;
+    let mut block: u32 = 0;
+
+    while available_subsidies > 0 { 
+        let block_subsidy = (available_subsidies * 41 + 99_999_999) / 100_000_000;
+        available_subsidies -= block_subsidy;
+
+        println!(
+            "{} ({} years): {}({} ZEC) {}({} ZEC)",
+            block,                             // current block
+            block / 420_768,                   // ~ current year
+            block_subsidy,                     // block subsidy in zatoshis
+            block_subsidy / 100_000_000,       // block subsidy in ZEC
+            available_subsidies,               // available subsidies in zatoshis
+            available_subsidies / 100_000_000  // available subsidies in ZEC
+        );
+
+        block += 1;
+    }   
+}
+```
+
+Last line of output of the above program is:
+
+`47699804 (113 years): 1(0 ZEC) 0(0 ZEC)`
+
+Note the addition of 99,999,999 before division to force rounding up of non-zero values.
+
+
+# References
+
+[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119
+
+[2] ZIP-200: https://zips.z.cash/zip-0200
+
+[3] ZIP-XXX: Placeholder for the ZSF ZIP