-
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 12 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,125 @@ | ||
<p><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></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 ZIP TBD [3]</p> | ||
<p>“Issuance” - to be interpreted as described in ZIP TBD [3]</p> | ||
<p>“We” - the ZIP authors, owners listed in the above front matter</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 #TODO reference#. The Sustainability Fund is used to pay out Block Subsidies | ||
from unmined ZEC, and other fund deposits.</p> | ||
<p>“<code>BLOCK_SUBSIDY_FRACTION</code>” = 41 / 100,000,000 or <code>0.00000041</code></p> | ||
<p>"<code>NUMBER_OF_BLOCKS_IN_4_YEARS</code>" = <code>(365.25 * 24 * 60 * 60/75 * 4)</code>, or <code>1_683_072</code></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 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.</p> | ||
<h1>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 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.</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>Specification</h1> | ||
<p>Smoothing the issuance curve is possible using an exponential decay formula that | ||
satisfies the following requirements:</p> | ||
<h2>Issuance Goals</h2> | ||
<ol> | ||
<li>Block subsidies are monotonically decreasing, as long as <code>ZsfBalanceAfter(h)</code> is monotonically decreasing</li> | ||
<li>Block subsidies approximate a continuous function</li> | ||
<li>When <code>ZSF_BALANCE(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>ZSF_BALANCE</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>ZSF_BALANCE</code>. They are referenced below as <strong>Rn</strong>.</p> | ||
<h2>Issuance Calculation</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>Using an exponential decay function for <strong>BlockSubsidy</strong> satisfies <strong>G1</strong> and <strong>G2</strong> above:</p> | ||
<p><code>BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)</code></p> | ||
<p>Finally, to satisfy <strong>G3</strong> above we need to always round up to at least 1 Zatoshi | ||
if <code>ZsfBalanceAfter(h - 1) > 0</code>:</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>The value <code>41 / 100_000_000</code> satisfies the approximation:</p> | ||
<p><code>(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ≈ 0.5</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>G4</strong>.</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 > 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> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,175 @@ | ||
``` | ||
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” - to be interpreted as described in ZIP TBD [3] | ||
|
||
“Issuance” - to be interpreted as described in ZIP TBD [3] | ||
aphelionz 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` | ||
|
||
"`NUMBER_OF_BLOCKS_IN_4_YEARS`" = `(365.25 * 24 * 60 * 60/75 * 4)`, or `1_683_072` | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
# 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. | ||
|
||
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. | ||
teor2345 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
||
|
||
# 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
|
||
|
||
|
||
# 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 | ||
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. This also needs 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. @daira is that a note for the ZIP owners? If so, could you clarify? Do I just need to add the anchor to the URL? |
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.