zip-0234.md

ZIP: 234
Title: Network Sustainability Mechanism: Issuance Smoothing
Owners: Jason McGee <[email protected]>
        Zooko Wilcox <[email protected]>
        Tomek Piotrowski <[email protected]>
        Mariusz Pilarek <[email protected]>
        Paul Dann <[email protected]>
Original-Authors: Nathan Wilcox
Credits:
Status: Draft
Category: Consensus
Created: 2023-08-23
License: BSD-2-Clause
Discussions-To: <https://github.com/zcash/zips/issues/923>

Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 ¹ when, and only when, it appears in all capitals.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. ²

The character § is used when referring to sections of the Zcash Protocol Specification. ³

The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. ⁴

The symbol "$,\cdot,$" means multiplication, as described in § 2 ‘Notation’. ⁵

"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e. ZEC on Mainnet and TAZ on Testnet.

The terms "Block Subsidy", "Issuance", and "Burning" are to be interpreted as described in ZIP 233. ⁶

Let $\mathsf{PostBlossomHalvingInterval}$ be as defined in ⁷.

$\mathsf{MAX_MONEY}$, as defined in § 5.3 ‘Constants’ ⁸, is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to 21,000,000 ZEC. This is slightly larger than the supply cap for the current issuance mechanism, but is the value used in existing critical consensus checks.

"Issued Supply" - The Issued Supply at a given height of a block chain is the total ZEC/TAZ value in all chain value pool balances at that height, as calculated by $\mathsf{IssuedSupply}(\mathsf{height})$ defined in § 4.17 ‘Chain Value Pool Balances’. ⁹

"Money Reserve" - The Money Reserve at a given height of a block chain is the total ZEC/TAZ value remaining to be issued, as calculated by $\mathsf{MAX_MONEY} - \mathsf{IssuedSupply}(\mathsf{height})$.

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 smooth logarithmic curve, defined as a fixed portion of the current value of the Money Reserve at a given block height.

The new issuance scheme would approximate the current issuance over 4-year intervals, assuming no ZEC/TAZ is burned during that time, and retains the overall supply cap of MAX_MONEY.

Motivation

Key Objectives:

1. We want to introduce an automated mechanism that allows users of the network to contribute to the long-term sustainability of the network.
2. We want to enable ZEC that has been burned to be recreated in the future to benefit network sustainability.
3. We want to retain the existing ZEC supply cap of 21 million.
4. We want the issuance rate to remain similar to the historical rate for Zcash (and before that, Bitcoin).
5. We want issuance to be easy for all network users to understand and predict.
6. We want the new issuance to activate at a block with as minimal a delta from the current issuance as possible.

The current Zcash economic model, inherited from Bitcoin, includes a halving mechanism that 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.

This new NSM-based issuance scheme solves these problems by ensuring a more consistent and predictable rate of coin issuance, while preserving the core aspects of Zcash's issuance policy and the 21-million-coin cap. At the same time, it introduces the first mechanism to recreate and distribute ZEC that has been removed from circulation, as well as unclaimed transaction fees, across future block subsidies.

Requirements

Smoothing the issuance curve is possible using an exponential decay formula that satisfies the following requirements:

1. The issuance can be summarized into a reasonably simple explanation.
2. Block subsidies approximate a continuous function.
3. If the Money Reserve is greater than 0, then the block subsidy must be non-zero, preventing any final "unmined" zatoshis.
4. For any 4-year period, all paid out block subsidies are approximately equal to half of the Money Reserve at the beginning of that 4-year period, if no ZEC is burned during those 4 years.
5. Decrease the short-term impact of the deployment of this ZIP on block subsidy recipients, and minimize the potential reputation risk to Zcash of changing the block subsidy amount.
6. The immediate change in issuance when this mechanism activates should be minimal.

Specification

Parameters

$\mathsf{BLOCK_SUBSIDY_FRACTION} = 4126 / 10_000_000_000 = 0.0000004126$

$\mathsf{DEPLOYMENT_BLOCK_HEIGHT} = \mathsf{TBD}$

The block height will be chosen by the following criteria:

• It is after NU7 activation height.
• It is calculated to be the lowest height after the second halving at which the NSM issuance would be less than the current BTC-style issuance neglecting any burnt ZEC (i.e. assuming the amount of ZEC burnt is exactly 0).

This selection is intended to achieve Key Objective 6 while still being at a constant, predictable height. An alternative would be to have a dynamic "latch"-style activation, which would calculate the activation height by testing the "less than" conditional with every block after the second halving. We prefer the pre-defined constant height parameter, to give everyone more time certainty at the cost of issuance level certainty.

The difference in up-front calculation versus dynamic calculation is in whether or not burns are accounted for (since future burns cannot be calculated up-front). This means with the pre-defined constant parameter approach, issuance will jump up some amount at activation. This amount should be equivalent to all ZEC burnt prior to that height times $\mathsf{BLOCK_SUBSIDY_FRACTION}$. For example, if a total of 100,000 ZEC were burnt prior to the pre-defined constant activation height, then at activation the issuance would be larger than BTC-style issuance by $100_000\textsf{ ZEC} \cdot \mathsf{BLOCK_SUBSIDY_FRACTION}$, which we calculate equals $0.04126$ ZEC. This example is chosen to demonstrate that a very large burn amount (much larger than expected) would elevate issuance by a relatively small amount. For this reason, we believe a pre-defined constant is a better approach to achieving Key Objective 6 than a "dynamic latch" logic because it is so much simpler to implement and reason about.

$\mathsf{MoneyReserveAfter}(\mathsf{height}) =$ The value of the Money Reserve after the specified block height.

Issuance Calculation

At the $\mathsf{DEPLOYMENT_BLOCK_HEIGHT}$, nodes should switch from the current issuance calculation, to the following:

$\mathsf{BlockSubsidy}(\mathsf{height}) = \mathsf{ceiling}(\mathsf{BLOCK_SUBSIDY_FRACTION} \cdot \mathsf{MoneyReserveAfter}(\mathsf{height} - 1))$

Applicability

All of these changes apply identically to Mainnet and Testnet.

Rationale

• Using an exponential decay function satisfies Requirements 1 and 2 above.
• We round up to the next zatoshi to satisfy Requirement 3 above.

BLOCK_SUBSIDY_FRACTION

Let $\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} = 0.5$.

The value $4126 / 10_000_000_000$ satisfies the approximation within $\pm 0.002%$:

$(1 - \mathsf{BLOCK_SUBSIDY_FRACTION})^\mathsf{PostBlossomHalvingInterval} \approx \mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears}$

This implies that after a period of 4 years around half of Money Reserve will have been issued as block subsidies, thus satisfying Requirement 4.

The largest possible value in the Money Reserve is $\mathsf{MAX_MONEY}$, in the theoretically possible case that all issued funds are burned. If this happened, the largest interim sum in the block subsidy calculation would be $\mathsf{MAX_MONEY} \cdot 4126 / 10_000_000_000$.

This uses 62.91 bits, which is just under the 63-bit limit for signed two's complement 64-bit 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?

Visualization of the Smoothed Curve

The following graph compares issuance for the current halving-based step function vs the smoothed curve.

The graph below shows the balance of the Money Reserve assuming smooth issuance is implemented.

Appendix: Simulation

The NSM Simulator allows us to simulate the effects of this ZIP on the Money Reserve 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 that no ZEC is ever burned, the Money Reserve 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:
  NSM 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),         NSM/legacy: 1.0001

shows that the difference between the smoothed out and the current issuance schemes is 238 ZEC after 1680000 blocks (around 4 years).

Appendix: Considerations for the Future

Future protocol changes may not increase the payout rate to a reasonable approximation beyond the four year half-life constraint.

Deployment

This ZIP is proposed to activate with Network Upgrade 7. ¹⁰ It MUST be deployed at the same time or after ZIP 233 ("NSM: Burning" ⁶).

References

Footnotes

1. Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" ↩

2. ZIP 200: Network Upgrade Mechanism ↩

3. Zcash Protocol Specification, Version 2024.5.1 [NU6] or later ↩

4. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet ↩

5. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation ↩

6. ZIP 233: Network Sustainability Mechanism: Burning ↩ ↩²

7. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.7.3 Difficulty Adjustment ↩

8. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants ↩

9. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.17 Chain Value Pool Balances ↩

10. ZIP 254: Deployment of the NU7 Network Upgrade ↩