|
| 1 | +<!DOCTYPE html> |
| 2 | +<html> |
| 3 | +<head> |
| 4 | + <title>ZIP 234: Smooth Out The Block Subsidy Issuance</title> |
| 5 | + <meta charset="utf-8" /> |
| 6 | + <script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script> |
| 7 | + <meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"> |
| 8 | +</head> |
| 9 | +<body> |
| 10 | +<pre><code>ZIP: 234 |
| 11 | +Title: Smooth Out The Block Subsidy Issuance |
| 12 | +Owners: Jason McGee <jason@shieldedlabs.com> |
| 13 | + Mark Henderson <mark@equilibrium.co> |
| 14 | + Tomek Piotrowski <tomek@eiger.co> |
| 15 | + Mariusz Pilarek <mariusz@eiger.co> |
| 16 | +Original-Authors: Nathan Wilcox |
| 17 | +Credits: |
| 18 | +Status: Draft |
| 19 | +Category: Consensus |
| 20 | +Created: 2023-08-23 |
| 21 | +License: BSD-2-Clause</code></pre> |
| 22 | +<h1 id="terminology">Terminology</h1> |
| 23 | +<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, |
| 24 | +“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as |
| 25 | +described in RFC 2119. [1]</p> |
| 26 | +<p>“Network upgrade” - to be interpreted as described in ZIP 200. |
| 27 | +[2]</p> |
| 28 | +<p>“Block Subsidy” - to be interpreted as described in the Zcash |
| 29 | +Protocol Specification (TODO ZIP Editors: link from comment).</p> |
| 30 | +<p>“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: |
| 31 | +work out if this definition is correct or can be removed).</p> |
| 32 | +<p>“<code>ZsfBalanceAfter(h)</code>” is the total ZEC available in the |
| 33 | +Zcash Sustainability Fund (ZSF) after the transactions in block |
| 34 | +<code>h</code>, described in ZIP draft-zsf.md. In this ZIP, the |
| 35 | +Sustainability Fund is used to pay out Block Subsidies from unmined ZEC, |
| 36 | +and other fund deposits.</p> |
| 37 | +<p>Let <code>PostBlossomHalvingInterval</code> be as defined in |
| 38 | +[#protocol-diffadjustment]_.</p> |
| 39 | +<h1 id="abstract">Abstract</h1> |
| 40 | +<p>This ZIP proposes a change to how nodes calculate the block |
| 41 | +subsidy.</p> |
| 42 | +<p>Instead of following a step function around the 4-year halving |
| 43 | +intervals inherited from Bitcoin, we propose a slow exponential |
| 44 | +“smoothing” of the curve. The new issuance scheme would approximate the |
| 45 | +current issuance over 4-year intervals.</p> |
| 46 | +<p>This ZIP depends on the ZIP introducing the Zcash Sustainability Fund |
| 47 | +(ZIP-XXX).</p> |
| 48 | +<h1 id="motivation">Motivation</h1> |
| 49 | +<p>The current Zcash economic model, inherited from Bitcoin, includes a |
| 50 | +halving mechanism which dictates the issuance of new coins. While this |
| 51 | +has been foundational, halvings can lead to abrupt changes in the rate |
| 52 | +of new coins being introduced to the market. Such sudden shifts can |
| 53 | +potentially disrupt the network’s economic model, potentially impacting |
| 54 | +its security and stability. Furthermore, the halvings schedule is fixed |
| 55 | +and does not provide any way to “recycle” funds into future |
| 56 | +issuance.</p> |
| 57 | +<p>To address this, we propose issuing a fixed portion of the pending |
| 58 | +funds-to-be-issued in each block. This has the effect of smoothing out |
| 59 | +the issuance curve of ZEC, ensuring a more consistent and predictable |
| 60 | +rate of coin issuance, while still preserving the overall supply cap of |
| 61 | +21,000,000 coins. This mechanism by itself (without other anticipated |
| 62 | +changes) seeks to preserve the core aspects of Zcash’s issuance policy |
| 63 | +and aims to enhance predictability and avoid sudden changes. By making |
| 64 | +this shift, the average block subsidy over time will remain predictable |
| 65 | +with very gradual changes.</p> |
| 66 | +<p>However, we anticipate schemes proposed in [#draft-zsf]_ where the |
| 67 | +amount of funds-to-be-issued may increase. In that scenario, this |
| 68 | +issuance mechanism would distribute that increase starting in the |
| 69 | +immediately following block and subsequent blocks. Because this |
| 70 | +distribution mechanism has an exponential decay, such increases will be |
| 71 | +spread out in miniscule amounts to future blocks over a long time |
| 72 | +period. This issuance mechanism thus provides a way for potential |
| 73 | +increases or decreases of issuance while constraining those changes to |
| 74 | +be small on a short time scale to avoid unexpected disruptions.</p> |
| 75 | +<p>Additionally, the current Bitcoin-style issuance does not take into |
| 76 | +account the current balance of <code>ZsfBalanceAfter(h)</code>. If |
| 77 | +[#draft-zsf]_ were to activate without a change to the issuance |
| 78 | +mechanism, then some funds would never be disbursed after they are |
| 79 | +deposited back into the ZSF.</p> |
| 80 | +<h1 id="requirements">Requirements</h1> |
| 81 | +<p>Smoothing the issuance curve is possible using an exponential decay |
| 82 | +formula that satisfies the following requirements:</p> |
| 83 | +<h2 id="issuance-requirements">Issuance Requirements</h2> |
| 84 | +<ol type="1"> |
| 85 | +<li>The issuance can be summarised into a reasonably simple |
| 86 | +explanation</li> |
| 87 | +<li>Block subsidies approximate a continuous function</li> |
| 88 | +<li>If there are funds in the ZSF, then the block subsidy must be |
| 89 | +non-zero, preventing any final “unmined” zatoshis</li> |
| 90 | +<li>For any 4 year period, all paid out block subsidies are |
| 91 | +approximately equal to half of the ZSF at the beginning of that 4 year |
| 92 | +period, if there are no deposits into the ZSF during those 4 years</li> |
| 93 | +</ol> |
| 94 | +<p>TODO daira: add a requirement that makes the initial total issuance |
| 95 | +match the previous total issuance</p> |
| 96 | +<h1 id="specification">Specification</h1> |
| 97 | +<h2 id="goals">Goals</h2> |
| 98 | +<p>We want to decrease the short-term impact of the deployment of this |
| 99 | +ZIP on block reward recipients, and minimise the potential reputational |
| 100 | +risk to Zcash of changing the block reward amount.</p> |
| 101 | +<h2 id="constants">Constants</h2> |
| 102 | +<p>Define constants:</p> |
| 103 | +<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 4126 / 10,000,000,000 or |
| 104 | +<code>0.0000004126</code></p> |
| 105 | +<p>“<code>DEPLOYMENT_BLOCK_HEIGHT</code>” = 2726400</p> |
| 106 | +<h2 id="issuance-calculation">Issuance Calculation</h2> |
| 107 | +<p>At the <code>DEPLOYMENT_BLOCK_HEIGHT</code>, nodes should switch from |
| 108 | +the current issuance calculation, to the following:</p> |
| 109 | +<p>Given the block height <code>h</code> define a function |
| 110 | +<strong>BlockSubsidy(h)</strong>, such that:</p> |
| 111 | +<p><strong>BlockSubsidy(h)</strong> = Block subsidy for a given |
| 112 | +<code>h</code>, that satisfies above requirements.</p> |
| 113 | +<p>Using an exponential decay function for <strong>BlockSubsidy</strong> |
| 114 | +satisfies requirements <strong>R1</strong> and <strong>R2</strong> |
| 115 | +above:</p> |
| 116 | +<p><code>BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)</code></p> |
| 117 | +<p>Finally, to satisfy <strong>R3</strong> above we always round up to |
| 118 | +the next zatoshi.</p> |
| 119 | +<p><code>BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))</code></p> |
| 120 | +<h1 id="rationale">Rationale</h1> |
| 121 | +<h2 id="block_subsidy_fraction"><code>BLOCK_SUBSIDY_FRACTION</code></h2> |
| 122 | +<p>Let <code>IntendedZSFFractionRemainingAfterFourYears</code> = |
| 123 | +0.5.</p> |
| 124 | +<p>The value <code>4126 / 10_000_000_000</code> satisfies the |
| 125 | +approximation within +0.002%:</p> |
| 126 | +<p><code>(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears</code></p> |
| 127 | +<p>Meaning after a period of 4 years around half of |
| 128 | +<code>ZSF_BALANCE</code> will be paid out as block subsidies, thus |
| 129 | +satisfying <strong>R4</strong>.</p> |
| 130 | +<p>The largest possible amount in the ZSF is MAX_MONEY, in the |
| 131 | +theoretically possible case that all issued funds are deposited back |
| 132 | +into the ZSF. If this happened, the largest interim sum in the block |
| 133 | +subsidy calculation would be MAX_MONEY * 4126 + 10000000000.</p> |
| 134 | +<p>This uses 62.91 bits, which is just under the 63 bit limit for 64-bit |
| 135 | +signed two’s-complement integer amount types.</p> |
| 136 | +<p>The numerator could be brought closer to the limit by using a larger |
| 137 | +denominator, but the difference in the amount issued would be very |
| 138 | +small. So we chose a power-of-10 denominator for simplicity.</p> |
| 139 | +<p>TODO for ZIP owners: How many ZEC per day?</p> |
| 140 | +<h2 |
| 141 | +id="deployment_block_height"><code>DEPLOYMENT_BLOCK_HEIGHT</code></h2> |
| 142 | +<p>The deployment should happen at the next halving, which is block |
| 143 | +<code>2726400</code>.</p> |
| 144 | +<p>Since there is a planned halving at this point, there will already be |
| 145 | +a significant “shock” caused by the drop in issuance caused by the |
| 146 | +halving. This reduces surprise and thus increases security. Also, due to |
| 147 | +the nature of the smoothed curve having a portion of the curve above the |
| 148 | +respective step function line at times, this will maximally |
| 149 | +<em>reduce</em> the issuance shock at the |
| 150 | +<code>DEPLOYMENT_BLOCK_HEIGHT</code>.</p> |
| 151 | +<h2 id="visualization-of-the-smoothed-curve">Visualization of the |
| 152 | +Smoothed Curve</h2> |
| 153 | +<p>The following graph illustrates compares issuance for the current |
| 154 | +halving-based step function vs the smoothed curve.</p> |
| 155 | +<figure> |
| 156 | +<img src="assets/images/zip-0234-block_subsidy.png" |
| 157 | +alt="A graph showing a comparison of the halving-based step function vs the smoothed curve" /> |
| 158 | +<figcaption aria-hidden="true">A graph showing a comparison of the |
| 159 | +halving-based step function vs the smoothed curve</figcaption> |
| 160 | +</figure> |
| 161 | +<p>The graph below shows the balance of the ZSF assuming smooth issuance |
| 162 | +is implemented.</p> |
| 163 | +<figure> |
| 164 | +<img src="assets/images/zip-0234-balance.png" |
| 165 | +alt="A graph showing the balance of the ZSF assuming smooth issuance is implemented" /> |
| 166 | +<figcaption aria-hidden="true">A graph showing the balance of the ZSF |
| 167 | +assuming smooth issuance is implemented</figcaption> |
| 168 | +</figure> |
| 169 | +<h1 id="deployment">Deployment</h1> |
| 170 | +<p>The implementation of this ZIP MUST be deployed at the same time or |
| 171 | +after the Zcash Sustainability Fund is established (ZIP-XXX).</p> |
| 172 | +<h1 id="appendix-simulation">Appendix: Simulation</h1> |
| 173 | +<p>The <a href="https://github.com/eigerco/zsf-simulator">ZSF |
| 174 | +simulator</a> allows us to simulate the effects of this ZIP on the ZSF |
| 175 | +balance and the block subsidy, as well as generate plots like the ones |
| 176 | +above. Its output:</p> |
| 177 | +<pre><code>Last block is 47917869 in ~113.88 years</code></pre> |
| 178 | +<p>indicates that, assuming no ZEC is ever deposited to the ZSF, its |
| 179 | +balance will be depleted after 113.88 years, and the block subsidy will |
| 180 | +be 0 ZEC after that point.</p> |
| 181 | +<p>This fragment of the output</p> |
| 182 | +<pre><code>Halving 1 at block 1680000: |
| 183 | + ZSF subsidies: 262523884819889 (~ 2625238.848 ZEC, 1.563 ZEC per block) |
| 184 | + legacy subsidies: 262500000000000 (~ 2625000.000 ZEC, 1.562 ZEC per block) |
| 185 | + difference: 23884819889 (~ 238 ZEC), ZSF/legacy: 1.0001</code></pre> |
| 186 | +<p>shows that the difference between the smoothed out and the current |
| 187 | +issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).</p> |
| 188 | +<h1 id="references">References</h1> |
| 189 | +<p>[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119</p> |
| 190 | +<p>[2] ZIP-200: https://zips.z.cash/zip-0200</p> |
| 191 | +<p>[3] ZIP-XXX: Placeholder for the ZSF ZIP</p> |
| 192 | +</body> |
| 193 | +</html> |
0 commit comments