-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ZIP 234] Smooth Out The Block Subsidy Issuance #706
base: main
Are you sure you want to change the base?
Changes from 11 commits
3e4ca01
753d180
b0c142f
54317ed
2d691eb
66dab1e
907fe1c
8b725d8
087f7b9
e3a28eb
609a3c6
5e6c367
013dcc1
bf090f4
dca1174
de30fea
45ff587
8cc6f92
9f4e7fd
c2a591a
8ea2ecc
4983a32
c5f83c1
1e977ba
74649db
2448c6c
e1aa108
f603576
5d5bc35
31d05c5
4b6d62c
44d5b95
3f77205
732e65a
d5ea3da
44fc779
212244f
fedfd9e
54e349d
7c64666
900b868
3f6eb54
776295c
c315670
86049bb
b580625
0c42f7b
f5224f8
be2140a
7133f29
f4d84e9
20a12da
96169eb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,159 @@ | ||
<!DOCTYPE html> | ||
<html> | ||
<head> | ||
<title>Draft issuance: 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: | ||
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: Nathan Wilcox | ||
Mark Henderson | ||
Jason McGee | ||
Status: Draft | ||
Category: Consensus | ||
Created: 2023-08-23 | ||
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>“Network upgrade” - 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. | ||
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>AVAILABLE_SUBSIDIES(h)</code>” is the total ZEC available to | ||
pay out Block Subsidies from at block height <code>h</code>, ie. “not | ||
yet mined ZEC at h”.</p> | ||
<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 41 / 100,000,000 or | ||
<code>0.00000041</code></p> | ||
<h1 id="abstract">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 four-year halving | ||
cycle inherited from Bitcoin, we propose a slow exponential “smoothing” | ||
of the curve. The new issuance scheme would approximate the current 4 | ||
year cycle, and results in the last zatoshi being spent in around 113 | ||
years.</p> | ||
<h1 id="motivation">Motivation</h1> | ||
<p>Zcash’s economic model is inherited from Bitcoin and includes the | ||
concept of a halving mechanism to regulate the issuance of new coins. | ||
This approach, though foundational, invites a reevaluation amid Zcash’s | ||
ongoing evolution. As the network matures, the need to address potential | ||
future challenges and ensure a sustained and stable economic ecosystem | ||
becomes apparent. The transition to a smoothed emissions curve offers an | ||
opportunity to adjust the network’s issuance dynamics while maintaining | ||
the supply cap of 21,000,000 coins. By doing so, Zcash endeavors to | ||
optimize its economic framework, accommodating changing circumstances | ||
while maintaining predictability and stability in rewards | ||
distribution.</p> | ||
<p>This proposal outlines a solution to address challenges associated | ||
with the existing block subsidy issuance mechanism in the Zcash network. | ||
The primary goal of this proposal is to introduce a more predictable and | ||
stable issuance of ZEC by smoothing out the issuance curve while | ||
preserving the supply cap. It’s important to note that this proposal | ||
does not seek to alter the fundamental aspects of Zcash’s issuance | ||
policy. The average block subsidy size over time will remain the same | ||
and the funds for block subsidies will last a similar amount of time. | ||
Instead, it focuses solely on enhancing the predictability and | ||
consistency of the block subsidy issuance process.</p> | ||
<p>Smoothing the emissions curve helps ensure that the network remains | ||
economically viable and stable as it transitions from a traditional | ||
issuance mechanism to one that maintains a sustainable and predictable | ||
issuance of rewards over time. It prevents abrupt changes in the rate of | ||
newly issued coins, which could lead to disruptions in the network’s | ||
economic model and potentially impact its security and sustainability. A | ||
smoother emissions curve allows for a more gradual and controlled | ||
transition, providing ZEC stakeholders and participants with a clear | ||
understanding of how rewards will be distributed over time.</p> | ||
<h1 id="specification">Specification</h1> | ||
<p>Smoothing the issuance curve is possible using an exponential decay | ||
formula that satisfies the following requirements:</p> | ||
<h2 id="requirements">Requirements</h2> | ||
<ol type="1"> | ||
<li>Block subsidies MUST be weakly decreasing</li> | ||
<li>Block subsidies SHOULD approximate a continuous function</li> | ||
<li>When <code>AVAILABLE_SUBSIDIES(h) > 0</code> then block subsidies | ||
for block <code>h</code> MUST always be <code>> 0</code>, preventing | ||
a final “unmined” zatoshi</li> | ||
<li>For any 4 year period, all paid out block subsidies MUST equal | ||
approximately half of <code>AVAILABLE_SUBSIDIES</code> at the beginning | ||
of that 4 year period</li> | ||
<li>This functionality MUST be introduced as part of a network | ||
upgrade</li> | ||
</ol> | ||
<p>The above requirements assume no deflationary action, i.e. that no | ||
ZEC is added to <code>AVAILABLE_SUBSIDIES</code>. They are referenced | ||
below as <strong>Rn</strong>.</p> | ||
<h2 id="solution">Solution</h2> | ||
<p>Given the block height <code>h</code> define a function | ||
<strong>S</strong>, such that:</p> | ||
<p><strong>S(h)</strong> = Block subsidy for a given <code>h</code>, | ||
that satisfies above requirements.</p> | ||
<p>Please note that</p> | ||
<p><code>AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h)</code> | ||
assuming no deflationary action.</p> | ||
<p>An exponential decay function <strong>S</strong> satisfies | ||
<strong>R1</strong> and <strong>R2</strong> above:</p> | ||
<p><code>S(h) = BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h)</code></p> | ||
<p>Finally, to satisfy <strong>R3</strong> above we need to always round | ||
up to at least 1 Zatoshi if | ||
<code>AVAILABLE_SUBSIDIES(h) > 0</code>:</p> | ||
<p><code>S(h) = ROUND_UP(BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h))</code></p> | ||
<h1 id="rationale">Rationale</h1> | ||
<h2 id="block_subsidy_fraction"><code>BLOCK_SUBSIDY_FRACTION</code></h2> | ||
<p>That value of <code>41 / 100_000_000</code> was selected so that it | ||
satisfies the equation:</p> | ||
<p><code>(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ~ ½</code></p> | ||
<p>Meaning after a period of 4 years around half of | ||
<code>AVAILABLE_SUBSIDIES</code> will be paid out as block subsidies, | ||
thus satisfying <strong>R4</strong>.</p> | ||
<h2 id="other-notes">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 id="appendix-simulation">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 id="rust-code">Rust Code</h2> | ||
<div class="sourceCode" id="cb2"><pre | ||
class="sourceCode rust"><code class="sourceCode rust"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="kw">fn</span> main() <span class="op">{</span></span> | ||
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a> <span class="co">// approximate available subsidies in August of 2023</span></span> | ||
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a> <span class="kw">let</span> <span class="kw">mut</span> available_subsidies<span class="op">:</span> <span class="dt">i64</span> <span class="op">=</span> <span class="dv">4671731</span> <span class="op">*</span> <span class="dv">100_000_000</span><span class="op">;</span></span> | ||
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a> <span class="kw">let</span> <span class="kw">mut</span> block<span class="op">:</span> <span class="dt">u32</span> <span class="op">=</span> <span class="dv">0</span><span class="op">;</span></span> | ||
<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a></span> | ||
<span id="cb2-6"><a href="#cb2-6" aria-hidden="true" tabindex="-1"></a> <span class="cf">while</span> available_subsidies <span class="op">></span> <span class="dv">0</span> <span class="op">{</span> </span> | ||
<span id="cb2-7"><a href="#cb2-7" aria-hidden="true" tabindex="-1"></a> <span class="kw">let</span> block_subsidy <span class="op">=</span> (available_subsidies <span class="op">*</span> <span class="dv">41</span> <span class="op">+</span> <span class="dv">99_999_999</span>) <span class="op">/</span> <span class="dv">100_000_000</span><span class="op">;</span></span> | ||
<span id="cb2-8"><a href="#cb2-8" aria-hidden="true" tabindex="-1"></a> available_subsidies <span class="op">-=</span> block_subsidy<span class="op">;</span></span> | ||
<span id="cb2-9"><a href="#cb2-9" aria-hidden="true" tabindex="-1"></a></span> | ||
<span id="cb2-10"><a href="#cb2-10" aria-hidden="true" tabindex="-1"></a> <span class="pp">println!</span>(</span> | ||
<span id="cb2-11"><a href="#cb2-11" aria-hidden="true" tabindex="-1"></a> <span class="st">"{} ({} years): {}({} ZEC) {}({} ZEC)"</span><span class="op">,</span></span> | ||
<span id="cb2-12"><a href="#cb2-12" aria-hidden="true" tabindex="-1"></a> block<span class="op">,</span> <span class="co">// current block</span></span> | ||
<span id="cb2-13"><a href="#cb2-13" aria-hidden="true" tabindex="-1"></a> block <span class="op">/</span> <span class="dv">420_768</span><span class="op">,</span> <span class="co">// ~ current year</span></span> | ||
<span id="cb2-14"><a href="#cb2-14" aria-hidden="true" tabindex="-1"></a> block_subsidy<span class="op">,</span> <span class="co">// block subsidy in zatoshis</span></span> | ||
<span id="cb2-15"><a href="#cb2-15" aria-hidden="true" tabindex="-1"></a> block_subsidy <span class="op">/</span> <span class="dv">100_000_000</span><span class="op">,</span> <span class="co">// block subsidy in ZEC</span></span> | ||
<span id="cb2-16"><a href="#cb2-16" aria-hidden="true" tabindex="-1"></a> available_subsidies<span class="op">,</span> <span class="co">// available subsidies in zatoshis</span></span> | ||
<span id="cb2-17"><a href="#cb2-17" aria-hidden="true" tabindex="-1"></a> available_subsidies <span class="op">/</span> <span class="dv">100_000_000</span> <span class="co">// available subsidies in ZEC</span></span> | ||
<span id="cb2-18"><a href="#cb2-18" aria-hidden="true" tabindex="-1"></a> )<span class="op">;</span></span> | ||
<span id="cb2-19"><a href="#cb2-19" aria-hidden="true" tabindex="-1"></a></span> | ||
<span id="cb2-20"><a href="#cb2-20" aria-hidden="true" tabindex="-1"></a> block <span class="op">+=</span> <span class="dv">1</span><span class="op">;</span></span> | ||
<span id="cb2-21"><a href="#cb2-21" aria-hidden="true" tabindex="-1"></a> <span class="op">}</span> </span> | ||
<span id="cb2-22"><a href="#cb2-22" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div> | ||
<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> | ||
</body> | ||
</html> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,166 @@ | ||
``` | ||
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: Nathan Wilcox | ||
Mark Henderson | ||
Jason McGee | ||
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” - 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. | ||
|
||
“Issuance” - The method by which unmined or unissued ZEC is converted to ZEC available | ||
to users of the network | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
“We” - the ZIP authors, owners listed in the above front matter | ||
|
||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
“`ZsfBalanceAfter(h)`” is the total ZEC available in the Zcash Sustainability Fund (ZSF) after the transactions | ||
in block `h`, described in ZIP #TODO reference#. The Sustainability Fund is used to pay out Block Subsidies | ||
from unmined ZEC, and other fund deposits. | ||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
“`BLOCK_SUBSIDY_FRACTION`” = 41 / 100,000,000 or `0.00000041` | ||
|
||
# Abstract | ||
|
||
This ZIP proposes a change to how nodes calculate the block subsidy. | ||
|
||
Instead of following a step function around the four-year halving cycle inherited | ||
from Bitcoin, we propose a slow exponential “smoothing” of the curve. The new issuance | ||
scheme would approximate the current 4 year cycle, and results in the last | ||
zatoshi being issued in around 114 years. | ||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
# Motivation | ||
|
||
Zcash’s economic model is inherited from Bitcoin and includes the concept of a halving | ||
mechanism to regulate the issuance of new coins. This approach, though foundational, invites | ||
a reevaluation amid Zcash’s ongoing evolution. As the network matures, the need to address | ||
potential future challenges and ensure a sustained and stable economic ecosystem becomes | ||
apparent. The transition to a smoothed emissions curve offers an opportunity to adjust the network's | ||
issuance dynamics while maintaining the supply cap of 21,000,000 coins. By doing so, Zcash | ||
endeavors to optimize its economic framework, accommodating changing circumstances while | ||
maintaining predictability and stability in rewards distribution. | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
This proposal outlines a solution to address challenges associated with the existing block | ||
subsidy issuance mechanism in the Zcash network. The primary goal of this proposal is to | ||
introduce a more predictable and stable issuance of ZEC by smoothing out the issuance | ||
curve while preserving the supply cap. It's important to note that this proposal does | ||
not seek to alter the fundamental aspects of Zcash's issuance policy. The average block | ||
subsidy amount over time will remain the same and the funds for block subsidies will last | ||
a similar amount of time. Instead, it focuses solely on enhancing the predictability | ||
and consistency of the block subsidy issuance process. | ||
|
||
Smoothing the emissions curve helps ensure that the network remains economically | ||
viable and stable as it transitions from a traditional issuance mechanism to one | ||
that maintains a sustainable and predictable issuance of rewards over time. It | ||
prevents abrupt changes in the rate of newly issued coins, which could lead to | ||
disruptions in the network's economic model and potentially impact its security | ||
and sustainability. A smoother emissions curve allows for a more gradual and controlled | ||
transition, providing ZEC stakeholders and participants with a clear understanding of | ||
how rewards will be distributed over time. | ||
|
||
|
||
|
||
# Specification | ||
|
||
Smoothing the issuance curve is possible using an exponential decay formula that | ||
satisfies the following requirements: | ||
|
||
## Issuance Goals | ||
|
||
1. Block subsidies are monotonically decreasing, as long as `ZsfBalanceAfter(h)` is monotonically decreasing | ||
2. Block subsidies approximate a continuous function | ||
3. When `ZSF_BALANCE(h) > 0` then block subsidies for block `h` | ||
MUST always be `> 0`, preventing a final “unmined” zatoshi | ||
4. For any 4 year period, all paid out block subsidies MUST equal approximately | ||
half of `ZSF_BALANCE` at the beginning of that 4 year period | ||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
5. This functionality MUST be introduced as part of a network upgrade | ||
tomekpiotrowski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The above requirements assume no deflationary action, i.e. that no ZEC is added | ||
to `ZSF_BALANCE`. They are referenced below as **Rn**. | ||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Issuance Calculation | ||
aphelionz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Given the block height `h` define a function **S**, such that: | ||
|
||
**S(h)** = Block subsidy for a given `h`, that satisfies above requirements. | ||
|
||
Using an exponential decay function for **BlockSubsidy** satisfies **G1** and **G2** above: | ||
|
||
`BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)` | ||
|
||
Finally, to satisfy **G3** above we need to always round up to at least 1 Zatoshi | ||
if `ZsfBalanceAfter(h - 1) > 0`: | ||
|
||
`BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))` | ||
conradoplg marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After the There will be some block height (that should be a constant in this specification section with either a known value or undefined for now) at which this issuance mechanism will first be applied, but that does not necessarily need to coincide with the network upgrade activation height (so e.g. if this were deployed in a NU that activated at height There should also be a section in the Rationale explaining why the (to-be-specified) choice was made. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nathan-at-least This is what we spoke about on our recent call - can you weigh in here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @str4d I believe I've now addressed this in my latest commit(s) based on the discussion on the Oct 5 Arborist call - can you confirm? |
||
|
||
# Rationale | ||
|
||
## `BLOCK_SUBSIDY_FRACTION` | ||
|
||
The value `41 / 100_000_000` satisfies the approximation: | ||
|
||
`(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ≈ 0.5` | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out | ||
as block subsidies, thus satisfying **G4**. | ||
|
||
|
||
## 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. | ||
tomekpiotrowski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
# 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: | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Rust Code | ||
|
||
```rust | ||
fn main() { | ||
// approximate available subsidies in August of 2023 | ||
tomekpiotrowski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
let mut available_subsidies: i64 = 4671731 * 100_000_000; | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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. | ||
tomekpiotrowski marked this conversation as resolved.
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assigned ZIP 234.