ZIP: 234
+Title: Smooth Out The Block Subsidy Issuance
+Owners: Jason McGee <jason@shieldedlabs.com>
+ Mark Henderson <mark@equilibrium.co>
+ Tomek Piotrowski <tomek@eiger.co>
+ Mariusz Pilarek <mariusz@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits:
+Status: Draft
+Category: Consensus
+Created: 2023-08-23
+License: BSD-2-ClauseTerminology
+The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, +“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as +described in RFC 2119. [1]
+“Network upgrade” - to be interpreted as described in ZIP 200. +[2]
+“Block Subsidy” - to be interpreted as described in the Zcash +Protocol Specification (TODO ZIP Editors: link from comment).
+“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: +work out if this definition is correct or can be removed).
+“ZsfBalanceAfter(h)” is the total ZEC available in the
+Zcash Sustainability Fund (ZSF) after the transactions in block
+h, described in ZIP draft-zsf.md. In this ZIP, the
+Sustainability Fund is used to pay out Block Subsidies from unmined ZEC,
+and other fund deposits.
Let PostBlossomHalvingInterval be as defined in
+[#protocol-diffadjustment]_.
Abstract
+This ZIP proposes a change to how nodes calculate the block +subsidy.
+Instead of following a step function around the 4-year halving +intervals inherited from Bitcoin, we propose a slow exponential +“smoothing” of the curve. The new issuance scheme would approximate the +current issuance over 4-year intervals.
+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.
+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.
+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 satisfies the following requirements:
+Issuance Requirements
+-
+
- The issuance can be summarised into a reasonably simple +explanation +
- Block subsidies approximate a continuous function +
- If there are funds in the ZSF, then the block subsidy must be +non-zero, preventing any final “unmined” zatoshis +
- 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.
+Constants
+Define constants:
+“BLOCK_SUBSIDY_FRACTION” = 4126 / 10,000,000,000 or
+0.0000004126
“DEPLOYMENT_BLOCK_HEIGHT” = 2726400
Issuance Calculation
+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.
Using an exponential decay function for BlockSubsidy +satisfies requirements R1 and R2 +above:
+BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)
Finally, to satisfy R3 above we always round up to +the next zatoshi.
+BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))
Rationale
+BLOCK_SUBSIDY_FRACTION
+Let IntendedZSFFractionRemainingAfterFourYears =
+0.5.
The value 4126 / 10_000_000_000 satisfies the
+approximation within +0.002%:
(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears
Meaning after a period of 4 years around half of
+ZSF_BALANCE will be paid out as block subsidies, thus
+satisfying R4.
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.
+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?
+DEPLOYMENT_BLOCK_HEIGHT
+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.
Visualization of the +Smoothed Curve
+The following graph illustrates compares issuance for the current +halving-based step function vs the smoothed curve.
+
+
+The graph below shows the balance of the ZSF assuming smooth issuance +is implemented.
+
+
+Deployment
+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 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 yearsindicates 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
+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.0001shows that the difference between the smoothed out and the current +issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).
+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
+ + diff --git a/zips/zip-0234-balance.png b/zips/zip-0234-balance.png new file mode 100644 index 00000000..9f0e8e5a Binary files /dev/null and b/zips/zip-0234-balance.png differ diff --git a/zips/zip-0234-block_subsidy.png b/zips/zip-0234-block_subsidy.png new file mode 100644 index 00000000..435d8fcd Binary files /dev/null and b/zips/zip-0234-block_subsidy.png differ diff --git a/zips/zip-0234.md b/zips/zip-0234.md new file mode 100644 index 00000000..332baac6 --- /dev/null +++ b/zips/zip-0234.md @@ -0,0 +1,221 @@ +``` +ZIP: 234 +Title: Smooth Out The Block Subsidy Issuance +Owners: Jason McGee