[ZIP 234] Format and re-render

2024-08-27 12:29:19 -06:00 · 2024-08-27 12:29:19 -06:00 · 996f3b470c
parent 6464118b45
commit 996f3b470c
4 changed files with 268 additions and 135 deletions
--- a/README.rst
+++ b/README.rst
@ -128,6 +128,7 @@ written.
    <tr> <td>230</td> <td class="left"><a href="zips/zip-0230.rst">Version 6 Transaction Format</a></td> <td>Draft</td>
    <tr> <td><span class="reserved">231</span></td> <td class="left"><a class="reserved" href="zips/zip-0231.rst">Decouple Memos from Transaction Outputs</a></td> <td>Reserved</td>
    <tr> <td>233</td> <td class="left"><a href="zips/zip-0233.md">Establish the Zcash Sustainability Fund on the Protocol Level</a></td> <td>Draft</td>
    <tr> <td>234</td> <td class="left"><a href="zips/zip-0234.md">Smooth Out The Block Subsidy Issuance</a></td> <td>Draft</td>
    <tr> <td>236</td> <td class="left"><a href="zips/zip-0236.rst">Blocks should balance exactly</a></td> <td>Draft</td>
    <tr> <td>245</td> <td class="left"><a href="zips/zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
    <tr> <td>302</td> <td class="left"><a href="zips/zip-0302.rst">Standardized Memo Field Format</a></td> <td>Draft</td>
@ -250,6 +251,7 @@ Index of ZIPs
    <tr> <td>230</td> <td class="left"><a href="zips/zip-0230.rst">Version 6 Transaction Format</a></td> <td>Draft</td>
    <tr> <td><span class="reserved">231</span></td> <td class="left"><a class="reserved" href="zips/zip-0231.rst">Decouple Memos from Transaction Outputs</a></td> <td>Reserved</td>
    <tr> <td>233</td> <td class="left"><a href="zips/zip-0233.md">Establish the Zcash Sustainability Fund on the Protocol Level</a></td> <td>Draft</td>
    <tr> <td>234</td> <td class="left"><a href="zips/zip-0234.md">Smooth Out The Block Subsidy Issuance</a></td> <td>Draft</td>
    <tr> <td>236</td> <td class="left"><a href="zips/zip-0236.rst">Blocks should balance exactly</a></td> <td>Draft</td>
    <tr> <td>239</td> <td class="left"><a href="zips/zip-0239.rst">Relay of Version 5 Transactions</a></td> <td>Final</td>
    <tr> <td>243</td> <td class="left"><a href="zips/zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
--- a/rendered/index.html
+++ b/rendered/index.html
@ -93,6 +93,7 @@
  <tr> <td>230</td> <td class="left"><a href="zip-0230">Version 6 Transaction Format</a></td> <td>Draft</td>
  <tr> <td><span class="reserved">231</span></td> <td class="left"><a class="reserved" href="zip-0231">Decouple Memos from Transaction Outputs</a></td> <td>Reserved</td>
  <tr> <td>233</td> <td class="left"><a href="zip-0233">Establish the Zcash Sustainability Fund on the Protocol Level</a></td> <td>Draft</td>
  <tr> <td>234</td> <td class="left"><a href="zip-0234">Smooth Out The Block Subsidy Issuance</a></td> <td>Draft</td>
  <tr> <td>236</td> <td class="left"><a href="zip-0236">Blocks should balance exactly</a></td> <td>Draft</td>
  <tr> <td>245</td> <td class="left"><a href="zip-0245">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
  <tr> <td>302</td> <td class="left"><a href="zip-0302">Standardized Memo Field Format</a></td> <td>Draft</td>
@ -196,6 +197,7 @@
  <tr> <td>230</td> <td class="left"><a href="zip-0230">Version 6 Transaction Format</a></td> <td>Draft</td>
  <tr> <td><span class="reserved">231</span></td> <td class="left"><a class="reserved" href="zip-0231">Decouple Memos from Transaction Outputs</a></td> <td>Reserved</td>
  <tr> <td>233</td> <td class="left"><a href="zip-0233">Establish the Zcash Sustainability Fund on the Protocol Level</a></td> <td>Draft</td>
  <tr> <td>234</td> <td class="left"><a href="zip-0234">Smooth Out The Block Subsidy Issuance</a></td> <td>Draft</td>
  <tr> <td>236</td> <td class="left"><a href="zip-0236">Blocks should balance exactly</a></td> <td>Draft</td>
  <tr> <td>239</td> <td class="left"><a href="zip-0239">Relay of Version 5 Transactions</a></td> <td>Final</td>
  <tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
--- a/rendered/zip-0234.html
+++ b/rendered/zip-0234.html
@ -1,4 +1,13 @@
-<p><code>ZIP: 
+<!DOCTYPE html>
 <html>
 <head>
    <title>ZIP 234: Smooth Out The Block Subsidy Issuance</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: 234
 Title: Smooth Out The Block Subsidy Issuance
 Owners: Jason McGee &lt;jason@shieldedlabs.com&gt;
        Mark Henderson &lt;mark@equilibrium.co&gt;
@ -9,111 +18,176 @@ Credits:
 Status: Draft
 Category: Consensus
 Created: 2023-08-23
-License: BSD-2-Clause</code></p>
+License: BSD-2-Clause</code></pre>
-<h1>Terminology</h1>
+<h1 id="terminology">Terminology</h1>
-<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, “OPTIONAL”,
+<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
-and “REQUIRED” in this document are to be interpreted as described in RFC 2119. [1]</p>
+“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as
-<p>"Network upgrade" - to be interpreted as described in ZIP 200. [2]</p>
+described in RFC 2119. [1]</p>
-<p>“Block Subsidy” - to be interpreted as described in the Zcash Protocol Specification (TODO ZIP Editors: link from comment).</p>
+<p>“Network upgrade” - to be interpreted as described in ZIP 200.
-<p>“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out if this definition is correct or can be removed).</p>
+[2]</p>
-<p>“<code>ZsfBalanceAfter(h)</code>” is the total ZEC available in the Zcash Sustainability Fund (ZSF) after the transactions
+<p>“Block Subsidy” - to be interpreted as described in the Zcash
-in block <code>h</code>, described in ZIP draft-zsf.md. In this ZIP, the Sustainability Fund is used to pay out Block Subsidies
+Protocol Specification (TODO ZIP Editors: link from comment).</p>
-from unmined ZEC, and other fund deposits.</p>
+<p>“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors:
-<p>Let <code>PostBlossomHalvingInterval</code> be as defined in [#protocol-diffadjustment]_.</p>
+work out if this definition is correct or can be removed).</p>
-<h1>Abstract</h1>
+<p>“<code>ZsfBalanceAfter(h)</code>” is the total ZEC available in the
-<p>This ZIP proposes a change to how nodes calculate the block subsidy.</p>
+Zcash Sustainability Fund (ZSF) after the transactions in block
-<p>Instead of following a step function around the 4-year halving intervals inherited
+<code>h</code>, described in ZIP draft-zsf.md. In this ZIP, the
-from Bitcoin, we propose a slow exponential “smoothing” of the curve. The new issuance
+Sustainability Fund is used to pay out Block Subsidies from unmined ZEC,
-scheme would approximate the current issuance over 4-year intervals.</p>
+and other fund deposits.</p>
-<h1>Motivation</h1>
+<p>Let <code>PostBlossomHalvingInterval</code> be as defined in
-<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. Furthermore, the halvings schedule is fixed and does not provide any way to "recycle" funds into future issuance.</p>
+[#protocol-diffadjustment]_.</p>
-<p>To address this, we propose issuing a fixed portion of the pending funds-to-be-issued in each block. This has the effect of 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 mechanism by itself (without other anticipated changes) seeks to preserve the core aspects of Zcash's issuance policy and aims to enhance predictability and avoid sudden changes. By making this shift, the average block subsidy over time will remain predictable with very gradual changes.</p>
+<h1 id="abstract">Abstract</h1>
-<p>However, we anticipate schemes proposed in [#draft-zsf]_ where the amount of funds-to-be-issued may increase. In that scenario, this issuance mechanism would distribute that increase starting in the immediately following block and subsequent blocks. Because this distribution mechanism has an exponential decay, such increases will be spread out in miniscule amounts to future blocks over a long time period. This issuance mechanism thus provides a way for potential increases or decreases of issuance while constraining those changes to be small on a short time scale to avoid unexpected disruptions. </p>
+<p>This ZIP proposes a change to how nodes calculate the block
-<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>
+subsidy.</p>
-<p>In summary, by introducing a smoother emissions curve, we:
+<p>Instead of following a step function around the 4-year halving
- maintain the economic viability of Zcash
+intervals inherited from Bitcoin, we propose a slow exponential
- provide predictability of the issuance rate, allowing only miniscule changes over short time ranges
+“smoothing” of the curve. The new issuance scheme would approximate the
- enhance Zcash's stability as the network evolves.</p>
+current issuance over 4-year intervals.</p>
-<h1>Requirements</h1>
+<p>This ZIP depends on the ZIP introducing the Zcash Sustainability Fund
-<p>Smoothing the issuance curve is possible using an exponential decay formula that
+(ZIP-XXX).</p>
-satisfies the following requirements:</p>
+<h1 id="motivation">Motivation</h1>
-<h2>Issuance Requirements</h2>
+<p>The current Zcash economic model, inherited from Bitcoin, includes a
-<ol>
+halving mechanism which dictates the issuance of new coins. While this
-<li>The issuance can be summarised into a reasonably simple explanation</li>
+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. Furthermore, the halvings schedule is fixed
 and does not provide any way to “recycle” funds into future
 issuance.</p>
 <p>To address this, we propose issuing a fixed portion of the pending
 funds-to-be-issued in each block. This has the effect of 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 mechanism by itself (without other anticipated
 changes) seeks to preserve the core aspects of Zcash’s issuance policy
 and aims to enhance predictability and avoid sudden changes. By making
 this shift, the average block subsidy over time will remain predictable
 with very gradual changes.</p>
 <p>However, we anticipate schemes proposed in [#draft-zsf]_ where the
 amount of funds-to-be-issued may increase. In that scenario, this
 issuance mechanism would distribute that increase starting in the
 immediately following block and subsequent blocks. Because this
 distribution mechanism has an exponential decay, such increases will be
 spread out in miniscule amounts to future blocks over a long time
 period. This issuance mechanism thus provides a way for potential
 increases or decreases of issuance while constraining those changes to
 be small on a short time scale to avoid unexpected disruptions.</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>
 <h1 id="requirements">Requirements</h1>
 <p>Smoothing the issuance curve is possible using an exponential decay
 formula that satisfies the following requirements:</p>
 <h2 id="issuance-requirements">Issuance Requirements</h2>
 <ol type="1">
 <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>If there are funds in the ZSF, then the block subsidy must be
-<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
+non-zero, preventing any final “unmined” zatoshis</li>
-TODO daira: add a requirement that makes the initial total issuance match the previous total issuance  </li>
+<li>For any 4 year period, all paid out block subsidies are
-<li>This functionality MUST be introduced as part of a network upgrade</li>
+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</li>
 </ol>
-<h1>Specification</h1>
+<p>TODO daira: add a requirement that makes the initial total issuance
-<h2>Goals</h2>
+match the previous total issuance</p>
-<p>We want to decrease the short-term impact of the deployment of this ZIP on block reward recipients, and minimise the potential reputational risk to Zcash of changing the block reward amount.</p>
+<h1 id="specification">Specification</h1>
-<h2>Constants</h2>
+<h2 id="goals">Goals</h2>
 <p>We want to decrease the short-term impact of the deployment of this
 ZIP on block reward recipients, and minimise the potential reputational
 risk to Zcash of changing the block reward amount.</p>
 <h2 id="constants">Constants</h2>
 <p>Define constants:</p>
-<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 4126 / 100,000,000 or <code>0.0000004126</code></p>
+<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 4126 / 10,000,000,000 or
-<p>"<code>DEPLOYMENT_BLOCK_HEIGHT</code>" = 2726400</p>
+<code>0.0000004126</code></p>
-<h2>Issuance Calculation</h2>
+<p>“<code>DEPLOYMENT_BLOCK_HEIGHT</code>” = 2726400</p>
-<p>At the <code>DEPLOYMENT_BLOCK_HEIGHT</code>, nodes should switch from the current issuance calculation, to the following:</p>
+<h2 id="issuance-calculation">Issuance Calculation</h2>
-<p>Given the block height <code>h</code> define a function <strong>BlockSubsidy(h)</strong>, such that:</p>
+<p>At the <code>DEPLOYMENT_BLOCK_HEIGHT</code>, nodes should switch from
-<p><strong>BlockSubsidy(h)</strong> = Block subsidy for a given <code>h</code>, that satisfies above requirements.</p>
+the current issuance calculation, to the following:</p>
-<p>Using an exponential decay function for <strong>BlockSubsidy</strong> satisfies requirements <strong>R1</strong> and <strong>R2</strong> above:</p>
+<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>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>
-<h2>Deployment</h2>
+<h1 id="rationale">Rationale</h1>
-<p>TBD</p>
+<h2 id="block_subsidy_fraction"><code>BLOCK_SUBSIDY_FRACTION</code></h2>
-<h1>Rationale</h1>
+<p>Let <code>IntendedZSFFractionRemainingAfterFourYears</code> =
-<h2><code>BLOCK_SUBSIDY_FRACTION</code></h2>
+0.5.</p>
-<p>Let <code>IntendedZSFFractionRemainingAfterFourYears</code> = 0.5.</p>
+<p>The value <code>4126 / 10_000_000_000</code> satisfies the
-<p>The value <code>4126 / 100_000_000</code> satisfies the approximation within +0.002%:</p>
+approximation within +0.002%:</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
+<p>Meaning after a period of 4 years around half of
-as block subsidies, thus satisfying <strong>R4</strong>.</p>
+<code>ZSF_BALANCE</code> will be paid out as block subsidies, thus
 satisfying <strong>R4</strong>.</p>
 <p>The largest possible amount in the ZSF is MAX_MONEY, in the
 theoretically possible case that all issued funds are deposited back
 into the ZSF. If this happened, the largest interim sum in the block
 subsidy calculation would be MAX_MONEY * 4126 + 10000000000.</p>
 <p>This uses 62.91 bits, which is just under the 63 bit limit for 64-bit
 signed two’s-complement integer amount types.</p>
 <p>The numerator could be brought closer to the limit by using a larger
 denominator, but the difference in the amount issued would be very
 small. So we chose a power-of-10 denominator for simplicity.</p>
 <p>TODO for ZIP owners: How many ZEC per day?</p>
-<h2><code>DEPLOYMENT_BLOCK_HEIGHT</code></h2>
+<h2
-<p>The deployment should happen at the next halving, which is block <code>2726400</code>.</p>
+id="deployment_block_height"><code>DEPLOYMENT_BLOCK_HEIGHT</code></h2>
-<p>Since there is a planned halving at this point, there will already be a significant "shock" caused by the drop in issuance caused by the halving. This reduces surprise and thus increases security. Also, due to the nature of the smoothed curve having a portion of the curve above the respective step function line at times, this will maximally <em>reduce</em> the issuance shock at the <code>DEPLOYMENT_BLOCK_HEIGHT</code>.</p>
+<p>The deployment should happen at the next halving, which is block
-<h2>Visualization of the Smoothed Curve</h2>
+<code>2726400</code>.</p>
-<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>Since there is a planned halving at this point, there will already be
-<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>
+a significant “shock” caused by the drop in issuance caused by the
-<p>[TODO: We should update this graph now showing the deployment at <code>2726400</code>]</p>
+halving. This reduces surprise and thus increases security. Also, due to
-<h2>Other Notes</h2>
+the nature of the smoothed curve having a portion of the curve above the
-<p>The suggested implementation avoids using float numbers. Rust and C++ will both round
+respective step function line at times, this will maximally
-the result of the final division up, satisfying <strong>R3</strong> above.</p>
+<em>reduce</em> the issuance shock at the
-<h1>Appendix: Simulation</h1>
+<code>DEPLOYMENT_BLOCK_HEIGHT</code>.</p>
-<p>We encourage readers to run the following Rust code, which simulates block subsidies.
+<h2 id="visualization-of-the-smoothed-curve">Visualization of the
-According to this simulation, assuming no deflationary action, block subsidies would
+Smoothed Curve</h2>
-last for approximately 113 years:</p>
+<p>The following graph illustrates compares issuance for the current
-<h2>Rust Code</h2>
+halving-based step function vs the smoothed curve.</p>
-<p>```rust
+<figure>
-fn main() {
+<img src="assets/images/zip-0234-block_subsidy.png"
-    // approximate available subsidies in August of 2023
+alt="A graph showing a comparison of the halving-based step function vs the smoothed curve" />
-    let mut available_subsidies: i64 = 4671731 * 100_000_000;
+<figcaption aria-hidden="true">A graph showing a comparison of the
-    let mut block: u32 = 0;</p>
+halving-based step function vs the smoothed curve</figcaption>
-<pre><code>while available_subsidies &gt; 0 {
+</figure>
-    let block_subsidy = (available_subsidies * 41 + 99_999_999) / 100_000_000;
+<p>The graph below shows the balance of the ZSF assuming smooth issuance
-    available_subsidies -= block_subsidy;
+is implemented.</p>
-
+<figure>
-    println!(
+<img src="assets/images/zip-0234-balance.png"
-        "{} ({} years): {}({} ZEC) {}({} ZEC)",
+alt="A graph showing the balance of the ZSF assuming smooth issuance is implemented" />
-        block,                             // current block
+<figcaption aria-hidden="true">A graph showing the balance of the ZSF
-        block / 420_768,                   // ~ current year
+assuming smooth issuance is implemented</figcaption>
-        block_subsidy,                     // block subsidy in zatoshis
+</figure>
-        block_subsidy / 100_000_000,       // block subsidy in ZEC
+<h1 id="deployment">Deployment</h1>
-        available_subsidies,               // available subsidies in zatoshis
+<p>The implementation of this ZIP MUST be deployed at the same time or
-        available_subsidies / 100_000_000  // available subsidies in ZEC
+after the Zcash Sustainability Fund is established (ZIP-XXX).</p>
-    );
+<h1 id="appendix-simulation">Appendix: Simulation</h1>
-
+<p>The <a href="https://github.com/eigerco/zsf-simulator">ZSF
-    block += 1;
+simulator</a> allows us to simulate the effects of this ZIP on the ZSF
-}
+balance and the block subsidy, as well as generate plots like the ones
-</code></pre>
+above. Its output:</p>
-<p>}
+<pre><code>Last block is 47917869 in ~113.88 years</code></pre>
-```</p>
+<p>indicates that, assuming no ZEC is ever deposited to the ZSF, its
-<p>Last line of output of the above program is:</p>
+balance will be depleted after 113.88 years, and the block subsidy will
-<p><code>47699804 (113 years): 1(0 ZEC) 0(0 ZEC)</code></p>
+be 0 ZEC after that point.</p>
-<p>Note the addition of 99,999,999 before division to force rounding up of non-zero values.</p>
+<p>This fragment of the output</p>
-<h1>References</h1>
+<pre><code>Halving  1 at block  1680000:
  ZSF subsidies:    262523884819889 (~ 2625238.848 ZEC,        1.563 ZEC per block)
  legacy subsidies: 262500000000000 (~ 2625000.000 ZEC,        1.562 ZEC per block)
  difference:           23884819889 (~         238 ZEC),         ZSF/legacy: 1.0001</code></pre>
 <p>shows that the difference between the smoothed out and the current
 issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).</p>
 <h1 id="references">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>
 </body>
 </html>
--- a/zips/zip-0234.md
+++ b/zips/zip-0234.md
@ -1,5 +1,5 @@
 ```
-ZIP: 
+ZIP: 234
 Title: Smooth Out The Block Subsidy Issuance
 Owners: Jason McGee <jason@shieldedlabs.com>
        Mark Henderson <mark@equilibrium.co>
@ -20,13 +20,16 @@ and “REQUIRED” in this document are to be interpreted as described in RFC 21
 "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).
+“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).
+“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
+“`ZsfBalanceAfter(h)`” is the total ZEC available in the Zcash Sustainability
-in block `h`, described in ZIP draft-zsf.md. In this ZIP, the Sustainability Fund is used to pay out Block Subsidies
+Fund (ZSF) after the transactions in block `h`, described in ZIP draft-zsf.md.
-from unmined ZEC, and other fund deposits.
+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]_.
@ -35,41 +38,71 @@ Let `PostBlossomHalvingInterval` be as defined in [#protocol-diffadjustment]_.
 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
+Instead of following a step function around the 4-year halving intervals
-from Bitcoin, we propose a slow exponential “smoothing” of the curve. The new issuance
+inherited from Bitcoin, we propose a slow exponential “smoothing” of the curve.
-scheme would approximate the current issuance over 4-year intervals.
+The new issuance scheme would approximate the current issuance over 4-year
 intervals.
-This ZIP depends on the ZIP introducing the Zcash Sustainability Fund (ZIP-XXX).
+This ZIP depends on the ZIP introducing the Zcash Sustainability Fund
 (ZIP-XXX).
 # 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. Furthermore, the halvings schedule is fixed and does not provide any way to "recycle" funds into future issuance.
+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.
 Furthermore, the halvings schedule is fixed and does not provide any way to
 "recycle" funds into future issuance.
-To address this, we propose issuing a fixed portion of the pending funds-to-be-issued in each block. This has the effect of 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 mechanism by itself (without other anticipated changes) seeks to preserve the core aspects of Zcash's issuance policy and aims to enhance predictability and avoid sudden changes. By making this shift, the average block subsidy over time will remain predictable with very gradual changes.
+To address this, we propose issuing a fixed portion of the pending
 funds-to-be-issued in each block. This has the effect of 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 mechanism by itself (without other anticipated changes) seeks to preserve
 the core aspects of Zcash's issuance policy and aims to enhance predictability
 and avoid sudden changes. By making this shift, the average block subsidy over
 time will remain predictable with very gradual changes.
-However, we anticipate schemes proposed in [#draft-zsf]_ where the amount of funds-to-be-issued may increase. In that scenario, this issuance mechanism would distribute that increase starting in the immediately following block and subsequent blocks. Because this distribution mechanism has an exponential decay, such increases will be spread out in miniscule amounts to future blocks over a long time period. This issuance mechanism thus provides a way for potential increases or decreases of issuance while constraining those changes to be small on a short time scale to avoid unexpected disruptions. 
+However, we anticipate schemes proposed in [#draft-zsf]_ where the amount of
 funds-to-be-issued may increase. In that scenario, this issuance mechanism
 would distribute that increase starting in the immediately following block and
 subsequent blocks. Because this distribution mechanism has an exponential
 decay, such increases will be spread out in miniscule amounts to future blocks
 over a long time period. This issuance mechanism thus provides a way for
 potential increases or decreases of issuance while constraining those changes
 to be small on a short time scale to avoid unexpected disruptions. 
-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.
+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.
 # Requirements
-Smoothing the issuance curve is possible using an exponential decay formula that
+Smoothing the issuance curve is possible using an exponential decay formula
-satisfies the following requirements:
+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
+3. If there are funds in the ZSF, then the block subsidy must be non-zero,
-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
+   preventing any final “unmined” zatoshis
-TODO daira: add a requirement that makes the initial total issuance match the previous total issuance  
+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  
 # Specification
 ## Goals
-We want to decrease the short-term impact of the deployment of this ZIP on block reward recipients, and minimise the potential reputational risk to Zcash of changing the block reward amount.
+We want to decrease the short-term impact of the deployment of this ZIP on
 block reward recipients, and minimise the potential reputational risk to Zcash
 of changing the block reward amount.
 ## Constants
@ -81,13 +114,16 @@ Define constants:
 ## Issuance Calculation
-At the `DEPLOYMENT_BLOCK_HEIGHT`, nodes should switch from the current issuance calculation, to the following:
+At the `DEPLOYMENT_BLOCK_HEIGHT`, nodes should switch from the current issuance
 calculation, to the following:
 Given the block height `h` define a function **BlockSubsidy(h)**, such that:
-**BlockSubsidy(h)** = Block subsidy for a given `h`, that satisfies above requirements.
+**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:
+Using an exponential decay function for **BlockSubsidy** satisfies requirements
 **R1** and **R2** above:
 `BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)`
@ -108,11 +144,17 @@ The value `4126 / 10_000_000_000` satisfies the approximation within +0.002%:
 Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out
 as block subsidies, thus satisfying **R4**.
-The largest possible amount in the ZSF is MAX_MONEY, in the theoretically possible case that all issued funds are deposited back into the ZSF. If this happened, the largest interim sum in the block subsidy calculation would be MAX_MONEY * 4126 + 10000000000.
+The largest possible amount in the ZSF is MAX_MONEY, in the theoretically
 possible case that all issued funds are deposited back into the ZSF. If this
 happened, the largest interim sum in the block subsidy calculation would be
 MAX_MONEY * 4126 + 10000000000.
-This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed two's-complement integer amount types.
+This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed
 two's-complement integer amount types.
-The numerator could be brought closer to the limit by using a larger denominator, but the difference in the amount issued would be very small. So we chose a power-of-10 denominator for simplicity.
+The numerator could be brought closer to the limit by using a larger
 denominator, but the difference in the amount issued would be very small. So we
 chose a power-of-10 denominator for simplicity.
 TODO for ZIP owners: How many ZEC per day?
@ -120,31 +162,43 @@ TODO for ZIP owners: How many ZEC per day?
 The deployment should happen at the next halving, which is block `2726400`.
-Since there is a planned halving at this point, there will already be a significant "shock" caused by the drop in issuance caused by the halving. This reduces surprise and thus increases security. Also, due to the nature of the smoothed curve having a portion of the curve above the respective step function line at times, this will maximally _reduce_ the issuance shock at the `DEPLOYMENT_BLOCK_HEIGHT`.
+Since there is a planned halving at this point, there will already be a
 significant "shock" caused by the drop in issuance caused by the halving. This
 reduces surprise and thus increases security. Also, due to the nature of the
 smoothed curve having a portion of the curve above the respective step function
 line at times, this will maximally _reduce_ the issuance shock at the
 `DEPLOYMENT_BLOCK_HEIGHT`.
 ## Visualization of the Smoothed Curve
-The following graph illustrates compares issuance for the current halving-based step function vs the smoothed curve.
+The following graph illustrates compares issuance for the current halving-based
 step function vs the smoothed curve.
-![A graph showing a comparison of the halving-based step function vs the smoothed curve](./zsf_block_subsidy.png)
+![A graph showing a comparison of the halving-based step function vs the smoothed curve](../rendered/assets/images/zip-0234-block_subsidy.png)
-The graph below shows the balance of the ZSF assuming smooth issuance is implemented.
+The graph below shows the balance of the ZSF assuming smooth issuance is
 implemented.
-![A graph showing the balance of the ZSF assuming smooth issuance is implemented](./zsf_balance.png)
+![A graph showing the balance of the ZSF assuming smooth issuance is implemented](../rendered/assets/images/zip-0234-balance.png)
 # Deployment
-The implementation of this ZIP MUST be deployed at the same time or after the Zcash Sustainability Fund is established (ZIP-XXX).
+The implementation of this ZIP MUST be deployed at the same time or after the
 Zcash Sustainability Fund is established (ZIP-XXX).
 # Appendix: Simulation
-The [ZSF simulator](https://github.com/eigerco/zsf-simulator) allows us to simulate the effects of this ZIP on the ZSF balance and the block subsidy, as well as generate plots like the ones above. Its output:
+The [ZSF simulator](https://github.com/eigerco/zsf-simulator) allows us to
 simulate the effects of this ZIP on the ZSF balance and the block subsidy, as
 well as generate plots like the ones above. Its output:
 ```
 Last block is 47917869 in ~113.88 years
 ```
-indicates that, assuming no ZEC is ever deposited to the ZSF, its balance will be depleted after 113.88 years, and the block subsidy will be 0 ZEC after that point.
+indicates that, assuming no ZEC is ever deposited to the ZSF, its balance will
 be depleted after 113.88 years, and the block subsidy will be 0 ZEC after that
 point.
 This fragment of the output 
@ -155,7 +209,8 @@ Halving  1 at block  1680000:
  difference:           23884819889 (~         238 ZEC),         ZSF/legacy: 1.0001
 ```
-shows that the difference between the smoothed out and the current issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).
+shows that the difference between the smoothed out and the current issuance
 schemes is 238 ZEC after 1680000 blocks (aroound 4 years).
 # References