From 43a7ca825729118673c0f007dd0b8247cfcb6953 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Wed, 16 Aug 2023 13:06:47 +0200
Subject: [PATCH 001/119] Add Zcash Sustainability Fund ZIP draft
---
draft-zsf.md | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 154 insertions(+)
create mode 100644 draft-zsf.md
diff --git a/draft-zsf.md b/draft-zsf.md
new file mode 100644
index 000000000..c5ccbd028
--- /dev/null
+++ b/draft-zsf.md
@@ -0,0 +1,154 @@
+```
+ZIP:
+Title: Establish the Zcash Sustainability Fund on the Protocol Level
+Owners: Jason McGee
+ Mark Henderson
+ Tomek Piotrowski
+ Mariusz Pilarek
+Original-Authors: Nathan Wilcox
+Credits: Nathan Wilcox
+ Mark Henderson
+ Jason McGee
+ Tomek Piotrowski
+ Mariusz Pilarek
+Status: Draft
+Category: Ecosystem
+Created: 2023-08-
+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]
+
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [2]
+
+The term "Block Rewards" refers to the algorithmic
+issuance of ZEC to every block's creator -- part of the consensus rules.
+
+"Issuance" - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network
+
+"We" - the ZIP authors, owners listed in the above front matter
+
+"`MAX_MONEY`" is the ZEC supply cap. For simplicity, this ZIP defines it to be `21,000,000 ZEC`, although this is slightly larger than the actual supply cap of the original ZEC issuance mechanism.
+
+# Abstract
+
+This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
+
+The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
+
+# Motivation
+
+The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this:
+
+- At Every New Block:
+ - Miner rewarded via unissued ZEC
+ - Transaction fees `(inputs - outputs)`
+
+The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below:
+
+- **Unmined ZEC is now accounted for as `ZSF_BALANCE`**
+- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
+- Thus, at Every New Block:
+ - Miner still rewarded **from `ZSF_BALANCE`**
+ - Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount**
+
+This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
+
+For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
+
+This ZIP is explicitly agnostic as to the recipients of block rewards so that acceptance or adoption of the Sustainability Fund does not introduce or bundle reallocation decisions with the primary proposal.
+
+This quite simple alternation has -- in our opinion -- a multitude of benefits:
+
+1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment and eventually replace block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
+2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
+3. **Network Sustainability:** This mechanism involves temporarily reducing the supply of ZEC similar to asset burning in Ethereum's EIP-1559, but with potential long-term sustainability benefits as the redistribution of deposits contributes to issuance rewards and network development, making it an attractive option for current and future Zcash users.
+4. **Reduce "Governance Attack Surface":** The proposal's policies aim to enhance predictability, financial sustainability, and minimize governance capture risks, ensuring Zcash's successful evolution as a global currency with a growing userbase and stakeholdership.
+5. **Ecosystem Benefits of Longer Time Horizons:** A reliable and long-term functioning Zcash blockchain allows users to make secure long-term plans, leading to a sustainable and virtuous adoption cycle, rather than being influenced by short-term trends.
+6. **Consensus Continuity During Lulls:** Rate-limited payouts from the Sustainability Fund help maintain blockchain security during periods of low activity by utilizing savings from high activity periods, whereas direct miner rewards tied to short-term activity may favor miners with significant savings reserves or access to credit, reducing mining competitiveness and overall ecosystem certainty about mining capacity.
+7. **Mitigate Payment-to-Self Vulnerabilities:** The risk of miners benefiting from "spoofing" transactions and the desire for a fixed eventual supply goal lead to considering alternatives like the Sustainability Fund, which pays out fees over a long enough time horizon to prevent recouping costs, allowing Zcash to remain closer to its supply goal and offering an alternative to other protocol designs that destroy or burn funds.
+8. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
+
+_Disclaimer 1: Long term success depends on the specific mechanisms of deposits, the quantities involved, and broader economic considerations. For such as if the payout rate is both sufficient and not excessive enough to threaten sustainability._
+
+# Specification
+
+In practice, The Zcash Sustainability Fund is a single global balance maintained by the node state and contributed to via a single transaction field. This provides the economic and security support described in the motivation section, while also importantly keeping the fund payouts extremely simple to describe and implement.
+
+The two modifications are:
+1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE`
+2. The addition of a transaction field called `ZSF_DEPOSIT`
+
+Please note that a **network upgrade is required** for this work to be fully implemented.
+
+## `ZSF_BALANCE`
+
+Upon activation at height `H`, the ZEC issuance mechanism is permanently suspended, the value of `ZSF_BALANCE[H]` is set to the remainder of unissued ZEC. This must be done before the `Block Rewards Payout Rule` is enforced for the block at height `H`. **This is not a pre-mine.** This is simply a re-accounting of unissued ZEC that comes with the benefit of other possible sources of funding.
+
+Consensus nodes are then required to track new per-block state:
+
+- `ZSF_BALANCE[H] : u64 [zatoshi]`
+
+The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
+
+`TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS`
+
+This formula holds for all future blocks. It is safe and semantically consistent to consider all blocks prior to the activation height to have a value of `0` in this field. This is not required by this proposal but may be convenient in designs or implementations.
+
+### `ZSF_BALANCE` Requirements
+
+- The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`.
+- The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks.
+- Future protocol changes MUST NOT reduce or redistribute the funds in the ZSF, and they may not increase the payout rate to a reasonable approximation beyond the four year half-life constraint.
+
+## `ZSF_DEPOSIT`
+
+Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
+
+This is achieved by adding a new field to all transactions:
+
+- `ZSF_DEPOSIT : u64 [zatoshi]`
+
+The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance.
+
+It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
+
+Note: this field is not generally considered an "output" because it differs from other outputs in several significant ways:
+
+- All `ZSF_DEPOSIT` fields contribute to a single global balance rather than a user-specific output state,
+- Consensus validation can account for this field by updating `ZSF_BALANCE[H]` and do not need to track any transaction field specific state after this accounting in contrast to e.g. UTXOs which must be tracked until spent.
+- This field does not contribute to the transaction graph of senders or recipients whether transparent or protected by cryptography.
+
+### `ZSF_DEPOSIT` Requirements
+
+- There MUST be only one `ZSF_DEPOSIT` field per transaction
+- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
+- Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent
+
+# Rationale
+
+All technical decisions in this ZIP are balanced between the necessary robustness of the ZSF mechanics, and simplicity of implementation.
+
+## `ZSF_BALANCE` as node state
+
+Tracking the `ZSF_BALANCE` value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
+
+### Alternative: `ZSF_BALANCE` as block header commitment
+
+An alternative to node state could be to include the `ZSF_BALANCE` field as a block header and require a block header commitment.
+
+Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
+
+## `ZSF_DEPOSIT` as explicit transaction field
+
+An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
+
+# References
+
+**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**
+
+**[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)**
+
+**[3]: [ZIP 225: Version 5 Transaction Format](https://zips.z.cash/zip-0225)**
From 22b954c90062e4a2231945e618d83218a1fc0b59 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Wed, 16 Aug 2023 23:21:17 +0200
Subject: [PATCH 002/119] Add the ZSF draft HTML
---
draft-zsf.html | 273 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 273 insertions(+)
create mode 100644 draft-zsf.html
diff --git a/draft-zsf.html b/draft-zsf.html
new file mode 100644
index 000000000..8c9545b25
--- /dev/null
+++ b/draft-zsf.html
@@ -0,0 +1,273 @@
+
+
+
+ Draft zsf: Establish the Zcash Sustainability Fund on the Protocol Level
+
+
+
+
+
+
ZIP:
+Title: Establish the Zcash Sustainability Fund on the Protocol Level
+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
+ Tomek Piotrowski
+ Mariusz Pilarek
+Status: Draft
+Category: Ecosystem
+Created: 2023-08-
+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]
+
The term “network upgrade” in this document is to be interpreted as
+described in ZIP 200. [2]
+
The term “Block Rewards” refers to the algorithmic issuance of ZEC to
+every block’s creator – part of the consensus rules.
+
“Issuance” - The method by which unmined or unissued ZEC is converted
+to ZEC available to users of the network
+
“We” - the ZIP authors, owners listed in the above front matter
+
“MAX_MONEY” is the ZEC supply cap. For simplicity, this
+ZIP defines it to be 21,000,000 ZEC, although this is
+slightly larger than the actual supply cap of the original ZEC issuance
+mechanism.
+
Abstract
+
This ZIP describes the motivation, the necessary changes for, and the
+implementation specifications for the Zcash Sustainability Fund (ZSF).
+The ZSF is a proposed alteration to the block rewards system and
+accounting of unmined ZEC that allows for other sources of funding
+besides unissued ZEC. This new mechanism for deposits – that new
+applications or protocol designs can use to strengthen the long-term
+sustainability of the network – will likely be an important step for
+future economic upgrades, such as a transition to Proof of Stake or
+Zcash Shielded Assets, and other potential protocol fees and user
+applications.
+
The changes in this ZIP are ultimately minimal, only requiring for
+the node to track state in the form of a ZSF_BALANCE, and
+for a new transaction field to be added, called
+ZSF_DEPOSIT. While wallet developer would be encouraged to
+add the ZSF_DEPOSIT field to their UIs, no changes or new
+behavior are absolutely required for developers or ZEC holders.
+
Motivation
+
The Zcash network’s operation and development relies fundamentally on
+the block reward system inherited from Bitcoin. This system currently
+looks sometihng like this:
+
+
At Every New Block:
+
+
Miner rewarded via unissued ZEC
+
Transaction fees (inputs - outputs)
+
+
+
The Zcash Sustainability Fund is a proposed replacement to that
+payout mechanism, with the relevant parts in bold below:
+
+
Unmined ZEC is now accounted for as
+ZSF_BALANCE
+
Transaction includes optional contributions to ZSF via a
+ZSF_DEPOSIT field
+
Thus, at Every New Block:
+
+
Miner still rewarded from
+ZSF_BALANCE
+
Transaction fees (inputs - outputs), including
+the ZF_DEPOSIT amount
+
+
+
This design gives similar clarity and algorithmic control benefits,
+while also allowing other sources of funds for Block Rewards in addition
+to newly issued ZEC, via ZSF Deposits.
+
For example, an end-user wallet application could have an option to
+contribute a portion of a transaction to the ZSF, which would be
+included in a ZSF_DEPOSIT field in the transaction, to be
+taken into account by the Zcash nodes.
+
This ZIP is explicitly agnostic as to the recipients of block rewards
+so that acceptance or adoption of the Sustainability Fund does not
+introduce or bundle reallocation decisions with the primary
+proposal.
+
This quite simple alternation has – in our opinion – a multitude of
+benefits:
+
+
Long Term Consensus Sustainability: This mechanism
+supports long-term consensus sustainability by addressing concerns about
+the sustainability of the network design shared by Bitcoin-like systems
+through the establishment of deposits into the Sustainability Fund to
+augment and eventually replace block rewards, ensuring long-term
+sustainability as the issuance rate of Zcash drops and newly issued ZEC
+decreases over time.
+
Benefits to ZEC Holders: Deposits to the ZSF slow
+down the payout of ZEC, temporarily reducing its available supply,
+benefiting current holders of unencumbered active ZEC in proportion to
+their holdings without requiring them to opt into any scheme,
+introducing extra risk, active oversight, or accounting complexity.
+
Network Sustainability: This mechanism involves
+temporarily reducing the supply of ZEC similar to asset burning in
+Ethereum’s EIP-1559, but with potential long-term sustainability
+benefits as the redistribution of deposits contributes to issuance
+rewards and network development, making it an attractive option for
+current and future Zcash users.
+
Reduce “Governance Attack Surface”: The proposal’s
+policies aim to enhance predictability, financial sustainability, and
+minimize governance capture risks, ensuring Zcash’s successful evolution
+as a global currency with a growing userbase and stakeholdership.
+
Ecosystem Benefits of Longer Time Horizons: A
+reliable and long-term functioning Zcash blockchain allows users to make
+secure long-term plans, leading to a sustainable and virtuous adoption
+cycle, rather than being influenced by short-term trends.
+
Consensus Continuity During Lulls: Rate-limited
+payouts from the Sustainability Fund help maintain blockchain security
+during periods of low activity by utilizing savings from high activity
+periods, whereas direct miner rewards tied to short-term activity may
+favor miners with significant savings reserves or access to credit,
+reducing mining competitiveness and overall ecosystem certainty about
+mining capacity.
+
Mitigate Payment-to-Self Vulnerabilities: The risk
+of miners benefiting from “spoofing” transactions and the desire for a
+fixed eventual supply goal lead to considering alternatives like the
+Sustainability Fund, which pays out fees over a long enough time horizon
+to prevent recouping costs, allowing Zcash to remain closer to its
+supply goal and offering an alternative to other protocol designs that
+destroy or burn funds.
+
Recovery of “Soft-Burned” Funds: In some instances,
+such as miners not claim all available rewards, some ZEC goes
+unaccounted for though not formally burned. This proposal would recover
+it through the ZSF_BALANCE mechanism described below.
+
+
Disclaimer 1: Long term success depends on the specific
+mechanisms of deposits, the quantities involved, and broader economic
+considerations. For such as if the payout rate is both sufficient and
+not excessive enough to threaten sustainability.
+
Specification
+
In practice, The Zcash Sustainability Fund is a single global balance
+maintained by the node state and contributed to via a single transaction
+field. This provides the economic and security support described in the
+motivation section, while also importantly keeping the fund payouts
+extremely simple to describe and implement.
+
The two modifications are: 1. The re-accounting of unmined ZEC as a
+node state field called ZSF_BALANCE 2. The addition of a
+transaction field called ZSF_DEPOSIT
+
Please note that a network upgrade is required for
+this work to be fully implemented.
+
ZSF_BALANCE
+
Upon activation at height H, the ZEC issuance mechanism
+is permanently suspended, the value of ZSF_BALANCE[H] is
+set to the remainder of unissued ZEC. This must be done before the
+Block Rewards Payout Rule is enforced for the block at
+height H. This is not a pre-mine. This is
+simply a re-accounting of unissued ZEC that comes with the benefit of
+other possible sources of funding.
+
Consensus nodes are then required to track new per-block state:
+
+
ZSF_BALANCE[H] : u64 [zatoshi]
+
+
The state is a single 64 bit integer (representing units of
+zatoshi) at any given block height, H,
+representing the Sustainability Fund balance at that height,
+H. The ZSF_BALANCE can be calculated using the
+following formula:
+
TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
+
This formula holds for all future blocks. It is safe and semantically
+consistent to consider all blocks prior to the activation height to have
+a value of 0 in this field. This is not required by this
+proposal but may be convenient in designs or implementations.
+
ZSF_BALANCE
+Requirements
+
+
The value of ZSF_BALANCE SHOULD equal 0
+for all blocks prior to the activation height H.
+
The above described formula
+TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
+MUST hold for all future blocks.
+
Future protocol changes MUST NOT reduce or redistribute the funds in
+the ZSF, and they may not increase the payout rate to a reasonable
+approximation beyond the four year half-life constraint.
+
+
ZSF_DEPOSIT
+
Each transaction can dedicate some of its excess funds to the ZSF,
+and the remainder becomes the miner fee, with any excess miner
+fee/reward going to the ZSF
+
This is achieved by adding a new field to all transactions:
+
+
ZSF_DEPOSIT : u64 [zatoshi]
+
+
The ZSF_BALANCE[H] for a block at height H
+can be calculated given a value of ZSF_BALANCE[H-1] and the
+set of transactions contained in that block. First, the
+ZSF_DEPOSIT[H] is calculated based solely on
+ZSF_BALANCE[H-1]. This is subtracted from the previous
+block’s balance to be distributed as part of the block reward. Second,
+the sum of all the ZSF_DEPOSIT fields of all transactions
+in the block is added to the balance.
+
It is safe and consistent to treat older transactions using
+pre-Sustainability Fund formats as if they have this field implicitly
+present with a value of 0 where that simplifies designs or
+implementations.
+
Note: this field is not generally considered an “output” because it
+differs from other outputs in several significant ways:
+
+
All ZSF_DEPOSIT fields contribute to a single global
+balance rather than a user-specific output state,
+
Consensus validation can account for this field by updating
+ZSF_BALANCE[H] and do not need to track any transaction
+field specific state after this accounting in contrast to e.g. UTXOs
+which must be tracked until spent.
+
This field does not contribute to the transaction graph of senders
+or recipients whether transparent or protected by cryptography.
+
+
ZSF_DEPOSIT
+Requirements
+
+
There MUST be only one ZSF_DEPOSIT field per
+transaction
+
ZIP 225 [3] MUST be updated to include ZSF_DEPOSIT. ZIP
+244 MAY be updated as well.
+
Separate programming language implementations (C++, Rust, etc) MUST
+guarantee that the calculations described above are consistent
+
+
Rationale
+
All technical decisions in this ZIP are balanced between the
+necessary robustness of the ZSF mechanics, and simplicity of
+implementation.
+
ZSF_BALANCE as node
+state
+
Tracking the ZSF_BALANCE value as a node state using the
+above formula is very simple in terms of implementation, and should work
+correctly given that the node implementations calculate the value
+according to the specifications.
+
Alternative:
+ZSF_BALANCE as block header commitment
+
An alternative to node state could be to include the
+ZSF_BALANCE field as a block header and require a block
+header commitment.
+
Requiring block-header-rooted commitments of global fund balances
+such as the Sustainability Fund ensures that any consensus deviating
+bugs in accounting of this balance are immediately detected in the
+earliest impacted block. It also removes some of the need for explorer
+sites and other analytics services from tracking this value
+independently, assuming the committed value is made available by common
+APIs. This helps ensure that all explorers track and report the correct
+value.
+
ZSF_DEPOSIT
+as explicit transaction field
+
An explicit value distinguishes the ZEC destined to Sustainability
+Fund deposits from the implicit transaction fee. Explicitness also
+ensures any arithmetic flaws in any implementations are more likely to
+be observed and caught immediately.
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
+
“We” - the ZIP authors, owners listed in the above front matter
+
“AVAILABLE_SUBSIDIES(h)” is the total ZEC available to
+pay out Block Subsidies from at block height h, ie. “not
+yet mined ZEC at h”.
+
“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 spent in around 113
+years.
+
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 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.
+
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:
+
Requirements
+
+
Block subsidies MUST be weakly decreasing
+
Block subsidies SHOULD approximate a continuous function
+
When AVAILABLE_SUBSIDIES(h) > 0 then block subsidies
+for block h MUST always be > 0, preventing
+a final “unmined” zatoshi
+
For any 4 year period, all paid out block subsidies MUST equal
+approximately half of AVAILABLE_SUBSIDIES at the beginning
+of that 4 year period
+
This functionality MUST be introduced as part of a network
+upgrade
+
+
The above requirements assume no deflationary action, i.e. that no
+ZEC is added to AVAILABLE_SUBSIDIES. They are referenced
+below as Rn.
+
Solution
+
Given the block height h define a function
+S, such that:
+
S(h) = Block subsidy for a given h,
+that satisfies above requirements.
+
Please note that
+
AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h)
+assuming no deflationary action.
+
An exponential decay function S satisfies
+R1 and R2 above:
That value of 41 / 100_000_000 was selected so that it
+satisfies the equation:
+
(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ~ ½
+
Meaning after a period of 4 years around half of
+AVAILABLE_SUBSIDIES will be paid out as block subsidies,
+thus satisfying R4.
+
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.
+
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:
+
Rust Code
+
fn main() {
+// approximate available subsidies in August of 2023
+letmut available_subsidies:i64=4671731*100_000_000;
+letmut 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.
+
+
diff --git a/draft-issuance.md b/draft-issuance.md
new file mode 100644
index 000000000..bd47dade7
--- /dev/null
+++ b/draft-issuance.md
@@ -0,0 +1,169 @@
+```
+ZIP:
+Title: Smooth Out The Block Subsidy Issuance
+Owners: Jason McGee
+ Mark Henderson
+ Tomek Piotrowski
+ Mariusz Pilarek
+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
+
+“We” - the ZIP authors, owners listed in the above front matter
+
+“`AVAILABLE_SUBSIDIES(h)`” is the total ZEC available to pay out Block Subsidies from at
+block height `h`, ie. “not yet mined ZEC at h”.
+
+“`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 spent in around 113 years.
+
+# 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 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.
+
+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:
+
+## Requirements
+
+1. Block subsidies MUST be weakly decreasing
+2. Block subsidies SHOULD approximate a continuous function
+3. When `AVAILABLE_SUBSIDIES(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 `AVAILABLE_SUBSIDIES` at the beginning of that 4 year period
+5. This functionality MUST be introduced as part of a network upgrade
+
+The above requirements assume no deflationary action, i.e. that no ZEC is added
+to `AVAILABLE_SUBSIDIES`. They are referenced below as **Rn**.
+
+## Solution
+
+Given the block height `h` define a function **S**, such that:
+
+**S(h)** = Block subsidy for a given `h`, that satisfies above requirements.
+
+Please note that
+
+`AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h)` assuming no deflationary action.
+
+An exponential decay function **S** satisfies **R1** and **R2** above:
+
+`S(h) = BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h)`
+
+Finally, to satisfy **R3** above we need to always round up to at least 1 Zatoshi
+if `AVAILABLE_SUBSIDIES(h) > 0`:
+
+`S(h) = ROUND_UP(BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h))`
+
+# Rationale
+
+## `BLOCK_SUBSIDY_FRACTION`
+
+That value of `41 / 100_000_000` was selected so that it satisfies the equation:
+
+`(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ~ ½`
+
+Meaning after a period of 4 years around half of `AVAILABLE_SUBSIDIES` will be paid out
+as block subsidies, thus satisfying **R4**.
+
+
+## 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.
+
+# 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:
+
+## Rust Code
+
+```rust
+fn main() {
+ // approximate available subsidies in August of 2023
+ let mut available_subsidies: i64 = 4671731 * 100_000_000;
+ 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.
From 7d2929f21cb21c31715f60da281b1f9178cec455 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 13:29:31 +0200
Subject: [PATCH 004/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index c5ccbd028..68fe526f8 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -85,7 +85,7 @@ Please note that a **network upgrade is required** for this work to be fully imp
## `ZSF_BALANCE`
-Upon activation at height `H`, the ZEC issuance mechanism is permanently suspended, the value of `ZSF_BALANCE[H]` is set to the remainder of unissued ZEC. This must be done before the `Block Rewards Payout Rule` is enforced for the block at height `H`. **This is not a pre-mine.** This is simply a re-accounting of unissued ZEC that comes with the benefit of other possible sources of funding.
+The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, which is initially set to `MAX_MONEY` at the genesis block.
Consensus nodes are then required to track new per-block state:
From 9488fce1c67c145dc83d0b4e7d1e33e88320bb15 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 13:31:13 +0200
Subject: [PATCH 005/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 68fe526f8..87fff7a3a 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -38,12 +38,14 @@ This ZIP describes the motivation, the necessary changes for, and the implementa
The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
+This ZIP does not change the current ZEC issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
+
# Motivation
The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this:
- At Every New Block:
- - Miner rewarded via unissued ZEC
+ - Miner and funding streams rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
- Transaction fees `(inputs - outputs)`
The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below:
@@ -51,7 +53,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
- **Unmined ZEC is now accounted for as `ZSF_BALANCE`**
- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
- Thus, at Every New Block:
- - Miner still rewarded **from `ZSF_BALANCE`**
+ - Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
- Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount**
This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
From c7cad3edb364eb32aecdc29d3914bc0f79eacf06 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 13:35:28 +0200
Subject: [PATCH 006/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 87fff7a3a..a51c4f5bb 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -117,11 +117,9 @@ The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value o
It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
-Note: this field is not generally considered an "output" because it differs from other outputs in several significant ways:
+#### Consensus Rule Changes
-- All `ZSF_DEPOSIT` fields contribute to a single global balance rather than a user-specific output state,
-- Consensus validation can account for this field by updating `ZSF_BALANCE[H]` and do not need to track any transaction field specific state after this accounting in contrast to e.g. UTXOs which must be tracked until spent.
-- This field does not contribute to the transaction graph of senders or recipients whether transparent or protected by cryptography.
+- Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs **and sustainability fund deposits** remove value from this pool.
### `ZSF_DEPOSIT` Requirements
From 884001107e4d2fad5252392f13085b83d29cb885 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 13:39:58 +0200
Subject: [PATCH 007/119] Update draft-zsf.md
Co-authored-by: Daira Emma Hopwood
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index a51c4f5bb..a346d8a2a 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -97,7 +97,7 @@ The state is a single 64 bit integer (representing units of `zatoshi`) at any gi
`TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS`
-This formula holds for all future blocks. It is safe and semantically consistent to consider all blocks prior to the activation height to have a value of `0` in this field. This is not required by this proposal but may be convenient in designs or implementations.
+This formula holds for all blocks.
### `ZSF_BALANCE` Requirements
From e085c88a6dd02b13ac6069a3a46a3780082dadcc Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 13:57:29 +0200
Subject: [PATCH 008/119] Remove restriction on future protocol changes
---
draft-zsf.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index a346d8a2a..af70cd4af 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -103,7 +103,6 @@ This formula holds for all blocks.
- The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`.
- The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks.
-- Future protocol changes MUST NOT reduce or redistribute the funds in the ZSF, and they may not increase the payout rate to a reasonable approximation beyond the four year half-life constraint.
## `ZSF_DEPOSIT`
From c48f5b1d025c8053fe093efb1d9cd888f63208cc Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 14:26:11 +0200
Subject: [PATCH 009/119] Slim down the motivation section
---
draft-zsf.md | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index af70cd4af..4b028fa25 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -64,16 +64,9 @@ This ZIP is explicitly agnostic as to the recipients of block rewards so that ac
This quite simple alternation has -- in our opinion -- a multitude of benefits:
-1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment and eventually replace block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
+1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
-3. **Network Sustainability:** This mechanism involves temporarily reducing the supply of ZEC similar to asset burning in Ethereum's EIP-1559, but with potential long-term sustainability benefits as the redistribution of deposits contributes to issuance rewards and network development, making it an attractive option for current and future Zcash users.
-4. **Reduce "Governance Attack Surface":** The proposal's policies aim to enhance predictability, financial sustainability, and minimize governance capture risks, ensuring Zcash's successful evolution as a global currency with a growing userbase and stakeholdership.
-5. **Ecosystem Benefits of Longer Time Horizons:** A reliable and long-term functioning Zcash blockchain allows users to make secure long-term plans, leading to a sustainable and virtuous adoption cycle, rather than being influenced by short-term trends.
-6. **Consensus Continuity During Lulls:** Rate-limited payouts from the Sustainability Fund help maintain blockchain security during periods of low activity by utilizing savings from high activity periods, whereas direct miner rewards tied to short-term activity may favor miners with significant savings reserves or access to credit, reducing mining competitiveness and overall ecosystem certainty about mining capacity.
-7. **Mitigate Payment-to-Self Vulnerabilities:** The risk of miners benefiting from "spoofing" transactions and the desire for a fixed eventual supply goal lead to considering alternatives like the Sustainability Fund, which pays out fees over a long enough time horizon to prevent recouping costs, allowing Zcash to remain closer to its supply goal and offering an alternative to other protocol designs that destroy or burn funds.
-8. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
-
-_Disclaimer 1: Long term success depends on the specific mechanisms of deposits, the quantities involved, and broader economic considerations. For such as if the payout rate is both sufficient and not excessive enough to threaten sustainability._
+3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
# Specification
From af56e30d5137b97889c9fe15d1bf37c9f70fd853 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 15:13:28 +0200
Subject: [PATCH 010/119] Update the ZSF balance formula
---
draft-zsf.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 4b028fa25..7967803b3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -88,9 +88,9 @@ Consensus nodes are then required to track new per-block state:
The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
-`TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS`
+`ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
-This formula holds for all blocks.
+where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height.
### `ZSF_BALANCE` Requirements
From dbab6a63c7060ff2fa9f36bf806b4ebe5a2ce2c0 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 15:13:56 +0200
Subject: [PATCH 011/119] Remove redundant requirements
---
draft-zsf.md | 5 -----
1 file changed, 5 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 7967803b3..b7c9a9fcb 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -92,11 +92,6 @@ The state is a single 64 bit integer (representing units of `zatoshi`) at any gi
where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height.
-### `ZSF_BALANCE` Requirements
-
-- The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`.
-- The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks.
-
## `ZSF_DEPOSIT`
Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
From 15542d7737550e1e3bbcf11f831ed07df9049e42 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 15:51:43 +0200
Subject: [PATCH 012/119] ZSF_DEPOSIT in older non-coinbase transactions
Co-authored-by: teor
---
draft-zsf.md | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index b7c9a9fcb..7bc4b2aa7 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -102,7 +102,10 @@ This is achieved by adding a new field to all transactions:
The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance.
-It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
+
+### Non-Coinbase Transactions
+
+If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is defined to be zero for non-coinbase transactions.
#### Consensus Rule Changes
From f5462c7ed77226b3549eee02ef482075ab68a328 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 16:38:51 +0200
Subject: [PATCH 013/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 7bc4b2aa7..8f3e442c4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -96,7 +96,7 @@ where Unclaimed(height) is the portion of the block subsidy that is unclaimed fo
Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
-This is achieved by adding a new field to all transactions:
+This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
- `ZSF_DEPOSIT : u64 [zatoshi]`
From 3437abe31ae21737f2717153eed0bcc7deb01531 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 16:39:00 +0200
Subject: [PATCH 014/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 8f3e442c4..af6d86b0c 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -113,7 +113,6 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
### `ZSF_DEPOSIT` Requirements
-- There MUST be only one `ZSF_DEPOSIT` field per transaction
- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
- Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent
From 0374cb489c7c88ef8a323bdad96ed658d46f926d Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 16:39:48 +0200
Subject: [PATCH 015/119] Update draft-zsf.md
Co-authored-by: Daira Emma Hopwood
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index af6d86b0c..a83974dd3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -98,7 +98,7 @@ Each transaction can dedicate some of its excess funds to the ZSF, and the remai
This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
-- `ZSF_DEPOSIT : u64 [zatoshi]`
+- `zsfDeposit : u64 [zatoshi]`
The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance.
From 8c7dd069f085ca9c16d861f2f745a1eb4b813bea Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Thu, 31 Aug 2023 16:45:12 +0200
Subject: [PATCH 016/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index a83974dd3..566b835d9 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -60,7 +60,6 @@ This design gives similar clarity and algorithmic control benefits, while also a
For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
-This ZIP is explicitly agnostic as to the recipients of block rewards so that acceptance or adoption of the Sustainability Fund does not introduce or bundle reallocation decisions with the primary proposal.
This quite simple alternation has -- in our opinion -- a multitude of benefits:
From dd179887c4c22b2fa212a4bc33aca116c5e94c82 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 09:02:28 +0200
Subject: [PATCH 017/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 566b835d9..879b6e4c3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -113,7 +113,6 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
### `ZSF_DEPOSIT` Requirements
- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
-- Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent
# Rationale
From 73f879a930a00efeaf62fc2cbefc97f1d1acc58e Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 09:05:09 +0200
Subject: [PATCH 018/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/draft-zsf.md b/draft-zsf.md
index 879b6e4c3..93ad4eb1f 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -110,6 +110,17 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
- Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs **and sustainability fund deposits** remove value from this pool.
+### Coinbase Transactions
+
+Any excess miner fee/reward is sent to the ZSF.
+
+In new blocks, this deposit is tracked via the `ZSF_DEPOSIT` field in coinbase transactions.
+
+If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an older transaction version, it is defined as the value of any unspent miner fee and miner reward. This re-defines these previously unspendable funds as ZSF deposits.
+
+#### Consensus Rule Changes
+
+- The remaining value in the transparent transaction value pool of a coinbase transaction is **deposited in the sustainability fund**.
### `ZSF_DEPOSIT` Requirements
- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
From 903c7d54f1cd364f588078b18a558e1b1ce7ebc0 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 09:06:52 +0200
Subject: [PATCH 019/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 93ad4eb1f..09fbb4c81 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -133,9 +133,9 @@ All technical decisions in this ZIP are balanced between the necessary robustnes
Tracking the `ZSF_BALANCE` value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
-### Alternative: `ZSF_BALANCE` as block header commitment
+### Committing to `ZsfBalanceAfter` in the block header
-An alternative to node state could be to include the `ZSF_BALANCE` field as a block header and require a block header commitment.
+The `ZsfBalanceAfter` node state has a block header commitment as specified above.
Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
From d7e5b28c251b1623183c844bab940a93205fa3b9 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 10:33:55 +0200
Subject: [PATCH 020/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/draft-zsf.md b/draft-zsf.md
index 09fbb4c81..a630785dc 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -88,7 +88,9 @@ Consensus nodes are then required to track new per-block state:
The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
`ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
+The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
+TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height.
## `ZSF_DEPOSIT`
From 06b77c8154cf49af7e27b7362277039c99bc84f4 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 10:43:54 +0200
Subject: [PATCH 021/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/draft-zsf.md b/draft-zsf.md
index a630785dc..d8fb581de 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -145,6 +145,11 @@ Requiring block-header-rooted commitments of global fund balances such as the Su
An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
+# Deployment
+
+This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
+
+The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCommitments` chain starting with the network upgrade activation block.
# References
**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**
From 1e2cec00c5caa841d7adf557dfc42941d4b55ded Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 10:51:42 +0200
Subject: [PATCH 022/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index d8fb581de..75a3ad388 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -93,7 +93,19 @@ The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block c
TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height.
-## `ZSF_DEPOSIT`
+## Deposits into the Sustainability Fund
+
+Sustainability fund deposits can be made via a new `zsfDeposit` field. This can be done by:
+- ZEC fund holders, in non-coinbase transactions;
+- Zcash miners, in coinbase transactions.
+
+In transaction versions without this new field:
+- unclaimed miner fees and rewards in **coinbase transactions** are re-defined as deposits into the sustainability fund, and
+- there are no sustainability fund deposits from non-coinbase transactions.
+
+Note: older transaction versions can continue to be supported after a network upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.
+
+### `zsfDeposit` fields in transactions
Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
From eb91d2b3f3fed32109730a95d8b84fedaca80153 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski
Date: Fri, 1 Sep 2023 14:21:49 +0200
Subject: [PATCH 023/119] draft-zsf.md updates
---
draft-zsf.md | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 75a3ad388..03b6934bd 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -42,11 +42,11 @@ This ZIP does not change the current ZEC issuance schedule. Any additional amoun
# Motivation
-The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this:
+The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks like this:
- At Every New Block:
- - Miner and funding streams rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
- - Transaction fees `(inputs - outputs)`
+ - Miner and funding streams are rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
+ - Miner is rewarded via Transaction fees `(inputs - outputs)`
The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below:
@@ -54,7 +54,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
- Thus, at Every New Block:
- Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
- - Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount**
+ - Miner is rewarded via Transaction fees `(inputs - outputs)`, **including the `ZSF_DEPOSIT` amount**
This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
@@ -88,14 +88,15 @@ Consensus nodes are then required to track new per-block state:
The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
`ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
+where `Unclaimed(height)` is the portion of the block subsidy that is unclaimed for the block at the given height.
+
The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
-where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height.
## Deposits into the Sustainability Fund
-Sustainability fund deposits can be made via a new `zsfDeposit` field. This can be done by:
+Sustainability fund deposits can be made via the new `zsfDeposit` field. This can be done by:
- ZEC fund holders, in non-coinbase transactions;
- Zcash miners, in coinbase transactions.
@@ -135,9 +136,11 @@ If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an olde
#### Consensus Rule Changes
- The remaining value in the transparent transaction value pool of a coinbase transaction is **deposited in the sustainability fund**.
+
### `ZSF_DEPOSIT` Requirements
-- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
+- ZIP 230 [3] must be updated to include `ZSF_DEPOSIT`.
+- ZIP 244 [4] must be updated as well to include `ZSF_DEPOSIT`.
# Rationale
@@ -168,4 +171,6 @@ The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCo
**[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)**
-**[3]: [ZIP 225: Version 5 Transaction Format](https://zips.z.cash/zip-0225)**
+**[3]: [ZIP 230: v6 transactions, including ZSAs](https://github.com/zcash/zips/pull/687)**
+
+**[4]: [ZIP 244: Transaction Identifier Non-Malleability](https://zips.z.cash/zip-0244)**
From e5d2cca34b2e227ef088ea1fcaa1b323e06a7757 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:39:33 -0400
Subject: [PATCH 024/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 03b6934bd..d1a4092b6 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -60,8 +60,7 @@ This design gives similar clarity and algorithmic control benefits, while also a
For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
-
-This quite simple alternation has -- in our opinion -- a multitude of benefits:
+This quite simple alteration has -- in our opinion -- a multitude of benefits:
1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
From 85df0478b4fde633abd897b8594e2835bff96b31 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:39:52 -0400
Subject: [PATCH 025/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index d1a4092b6..8f4d69361 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -54,7 +54,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
- Thus, at Every New Block:
- Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
- - Miner is rewarded via Transaction fees `(inputs - outputs)`, **including the `ZSF_DEPOSIT` amount**
+ - Miner is rewarded via Transaction fees `(inputs - outputs)`, **where `outputs` includes the `ZSF_DEPOSIT` amount**
This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
From bb4835b98928e848d902a9e7dd8abb7446e2831a Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:40:16 -0400
Subject: [PATCH 026/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 8f4d69361..83e2beba4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -74,8 +74,6 @@ The two modifications are:
1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE`
2. The addition of a transaction field called `ZSF_DEPOSIT`
-Please note that a **network upgrade is required** for this work to be fully implemented.
-
## `ZSF_BALANCE`
The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, which is initially set to `MAX_MONEY` at the genesis block.
From 450d47ba63fcc99a32a755973d53aa2202d6cf67 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:40:36 -0400
Subject: [PATCH 027/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 83e2beba4..37af1ea75 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -56,8 +56,6 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
- Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
- Miner is rewarded via Transaction fees `(inputs - outputs)`, **where `outputs` includes the `ZSF_DEPOSIT` amount**
-This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
-
For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
This quite simple alteration has -- in our opinion -- a multitude of benefits:
From ccd9eba4328521cac66f2dfa57a5af98c259fa98 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:40:49 -0400
Subject: [PATCH 028/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/draft-zsf.md b/draft-zsf.md
index 37af1ea75..62336c795 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -160,6 +160,7 @@ An explicit value distinguishes the ZEC destined to Sustainability Fund deposits
This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCommitments` chain starting with the network upgrade activation block.
+
# References
**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**
From eac8efabf3b8c15d6660bd11b8cc73245fa44647 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:41:04 -0400
Subject: [PATCH 029/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 62336c795..953a3b252 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -34,7 +34,7 @@ issuance of ZEC to every block's creator -- part of the consensus rules.
# Abstract
-This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
+This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
From d6cd39f665a9573fdfa6ec2da729e4bcd0724598 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 09:41:29 -0400
Subject: [PATCH 030/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index 953a3b252..cc505ce70 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -6,11 +6,7 @@ Owners: Jason McGee
Tomek Piotrowski
Mariusz Pilarek
Original-Authors: Nathan Wilcox
-Credits: Nathan Wilcox
- Mark Henderson
- Jason McGee
- Tomek Piotrowski
- Mariusz Pilarek
+Credits:
Status: Draft
Category: Ecosystem
Created: 2023-08-
From 753d1801f877da87a4939e63e8b2c08a97f091a5 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 10:01:05 -0400
Subject: [PATCH 031/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index bd47dade7..a88125800 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -42,7 +42,7 @@ 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 spent in around 113 years.
+zatoshi being issued in around 114 years.
# Motivation
From b0c142f6e9148340e269bb4fe00f57cad9d3b101 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 10:01:21 -0400
Subject: [PATCH 032/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index a88125800..e0bdb3cf9 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -60,7 +60,7 @@ subsidy issuance mechanism in the Zcash network. The primary goal of this propos
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
+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.
From 54317ed4faa818c37c5c5c95323c0bc9ce2fa168 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 10:01:31 -0400
Subject: [PATCH 033/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index e0bdb3cf9..4e72176bf 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -93,7 +93,7 @@ half of `AVAILABLE_SUBSIDIES` at the beginning of that 4 year period
The above requirements assume no deflationary action, i.e. that no ZEC is added
to `AVAILABLE_SUBSIDIES`. They are referenced below as **Rn**.
-## Solution
+## Issuance Calculation
Given the block height `h` define a function **S**, such that:
From 2d691eb5fa946d84cd6bf64bdf43a6dd07d0d274 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 10:01:44 -0400
Subject: [PATCH 034/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 4e72176bf..7649d1b22 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -99,18 +99,14 @@ Given the block height `h` define a function **S**, such that:
**S(h)** = Block subsidy for a given `h`, that satisfies above requirements.
-Please note that
+Using an exponential decay function for **BlockSubsidy** satisfies **G1** and **G2** above:
-`AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h)` assuming no deflationary action.
+`BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)`
-An exponential decay function **S** satisfies **R1** and **R2** above:
+Finally, to satisfy **G3** above we need to always round up to at least 1 Zatoshi
+if `ZsfBalanceAfter(h - 1) > 0`:
-`S(h) = BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h)`
-
-Finally, to satisfy **R3** above we need to always round up to at least 1 Zatoshi
-if `AVAILABLE_SUBSIDIES(h) > 0`:
-
-`S(h) = ROUND_UP(BLOCK_SUBSIDY_FRACTION * AVAILABLE_SUBSIDIES(h))`
+`BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))`
# Rationale
From 66dab1e63da09586cdea457d0d33afbc1f343bf9 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 10:01:57 -0400
Subject: [PATCH 035/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 7649d1b22..800342bf7 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -112,12 +112,12 @@ if `ZsfBalanceAfter(h - 1) > 0`:
## `BLOCK_SUBSIDY_FRACTION`
-That value of `41 / 100_000_000` was selected so that it satisfies the equation:
+The value `41 / 100_000_000` satisfies the approximation:
-`(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ~ ½`
+`(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ≈ 0.5`
-Meaning after a period of 4 years around half of `AVAILABLE_SUBSIDIES` will be paid out
-as block subsidies, thus satisfying **R4**.
+Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out
+as block subsidies, thus satisfying **G4**.
## Other Notes
From 907fe1cf7b28ae7b7ce4bdb50bf4fe85aecb6611 Mon Sep 17 00:00:00 2001
From: Mark Henderson
Date: Tue, 19 Sep 2023 10:36:30 -0400
Subject: [PATCH 036/119] update: add ZSF_BALANCE and ZsfBalanceAfter(h)
---
draft-issuance.md | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 800342bf7..99b906dad 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -30,11 +30,15 @@ to users of the network
“We” - the ZIP authors, owners listed in the above front matter
-“`AVAILABLE_SUBSIDIES(h)`” is the total ZEC available to pay out Block Subsidies from at
-block height `h`, ie. “not yet mined ZEC at h”.
+“`ZSF_BALANCE(h)`” is the total ZEC available in the Zcash Sustainability Fund (ZSF),
+described in ZIP #TODO#. This is used to pay out Block Subsidies from at block height
+`h`, ie. “not yet mined ZEC at h”.
“`BLOCK_SUBSIDY_FRACTION`” = 41 / 100,000,000 or `0.00000041`
+"`ZsfBalanceAfter(h)`" is the total ZEC available in the ZSF _after_ the calculation
+involving the `BLOCK_SUBSIDY_FRACTION` is applied.
+
# Abstract
This ZIP proposes a change to how nodes calculate the block subsidy.
@@ -84,14 +88,14 @@ satisfies the following requirements:
1. Block subsidies MUST be weakly decreasing
2. Block subsidies SHOULD approximate a continuous function
-3. When `AVAILABLE_SUBSIDIES(h) > 0` then block subsidies for block `h`
+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 `AVAILABLE_SUBSIDIES` at the beginning of that 4 year period
+half of `ZSF_BALANCE` at the beginning of that 4 year period
5. This functionality MUST be introduced as part of a network upgrade
The above requirements assume no deflationary action, i.e. that no ZEC is added
-to `AVAILABLE_SUBSIDIES`. They are referenced below as **Rn**.
+to `ZSF_BALANCE`. They are referenced below as **Rn**.
## Issuance Calculation
From 8b725d868d2e4de2b8a852475543134d6c51002f Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 16:17:41 -0400
Subject: [PATCH 037/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 99b906dad..ccaa30150 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -84,7 +84,7 @@ how rewards will be distributed over time.
Smoothing the issuance curve is possible using an exponential decay formula that
satisfies the following requirements:
-## Requirements
+## Issuance Goals
1. Block subsidies MUST be weakly decreasing
2. Block subsidies SHOULD approximate a continuous function
From 087f7b9a5dbb1ed808499b5a1a3abd4141d1b8f8 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 16:17:51 -0400
Subject: [PATCH 038/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index ccaa30150..667795f9f 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -87,7 +87,7 @@ satisfies the following requirements:
## Issuance Goals
1. Block subsidies MUST be weakly decreasing
-2. Block subsidies SHOULD approximate a continuous function
+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
From e3a28eb4ffb41dd0a24a9346d2bc3b4486c48c12 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 16:18:19 -0400
Subject: [PATCH 039/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 667795f9f..add02f63a 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -86,7 +86,7 @@ satisfies the following requirements:
## Issuance Goals
-1. Block subsidies MUST be weakly decreasing
+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
From 609a3c66ec4a5def1bef679f20e8f9f7a17082f1 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Tue, 19 Sep 2023 16:18:46 -0400
Subject: [PATCH 040/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index add02f63a..56e8b96ec 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -30,15 +30,12 @@ to users of the network
“We” - the ZIP authors, owners listed in the above front matter
-“`ZSF_BALANCE(h)`” is the total ZEC available in the Zcash Sustainability Fund (ZSF),
-described in ZIP #TODO#. This is used to pay out Block Subsidies from at block height
-`h`, ie. “not yet mined ZEC at h”.
+“`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.
“`BLOCK_SUBSIDY_FRACTION`” = 41 / 100,000,000 or `0.00000041`
-"`ZsfBalanceAfter(h)`" is the total ZEC available in the ZSF _after_ the calculation
-involving the `BLOCK_SUBSIDY_FRACTION` is applied.
-
# Abstract
This ZIP proposes a change to how nodes calculate the block subsidy.
From 2e5f3902ef33002b646d64ed564648743ea9fb3b Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 12:03:48 -0400
Subject: [PATCH 041/119] Update draft-zsf.md
Co-authored-by: teor
---
draft-zsf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zsf.md b/draft-zsf.md
index cc505ce70..1e8d60676 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -79,7 +79,7 @@ Consensus nodes are then required to track new per-block state:
The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
`ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
-where `Unclaimed(height)` is the portion of the block subsidy that is unclaimed for the block at the given height.
+where `Unclaimed(height)` is the portion of the block subsidy and miner fees that are unclaimed for the block at the given height.
The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
From 904c7afb9cd15d2619058427dde3fc22031b9bf3 Mon Sep 17 00:00:00 2001
From: Mark Henderson
Date: Wed, 27 Sep 2023 12:10:18 -0400
Subject: [PATCH 042/119] chore: ZIP html
---
draft-zsf.html | 337 +++++++++++++------------------------------------
draft-zsf.md | 3 +-
2 files changed, 91 insertions(+), 249 deletions(-)
diff --git a/draft-zsf.html b/draft-zsf.html
index 8c9545b25..7c7ee08d6 100644
--- a/draft-zsf.html
+++ b/draft-zsf.html
@@ -1,273 +1,116 @@
-
-
-
- Draft zsf: Establish the Zcash Sustainability Fund on the Protocol Level
-
-
-
-
-
-
ZIP:
+
ZIP:
Title: Establish the Zcash Sustainability Fund on the Protocol Level
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
- Tomek Piotrowski
- Mariusz Pilarek
+Credits:
Status: Draft
Category: Ecosystem
Created: 2023-08-
-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]
-
The term “network upgrade” in this document is to be interpreted as
-described in ZIP 200. [2]
-
The term “Block Rewards” refers to the algorithmic issuance of ZEC to
-every block’s creator – part of the consensus rules.
-
“Issuance” - The method by which unmined or unissued ZEC is converted
-to ZEC available to users of the network
-
“We” - the ZIP authors, owners listed in the above front matter
-
“MAX_MONEY” is the ZEC supply cap. For simplicity, this
-ZIP defines it to be 21,000,000 ZEC, although this is
-slightly larger than the actual supply cap of the original ZEC issuance
-mechanism.
-
Abstract
-
This ZIP describes the motivation, the necessary changes for, and the
-implementation specifications for the Zcash Sustainability Fund (ZSF).
-The ZSF is a proposed alteration to the block rewards system and
-accounting of unmined ZEC that allows for other sources of funding
-besides unissued ZEC. This new mechanism for deposits – that new
-applications or protocol designs can use to strengthen the long-term
-sustainability of the network – will likely be an important step for
-future economic upgrades, such as a transition to Proof of Stake or
-Zcash Shielded Assets, and other potential protocol fees and user
-applications.
-
The changes in this ZIP are ultimately minimal, only requiring for
-the node to track state in the form of a ZSF_BALANCE, and
-for a new transaction field to be added, called
-ZSF_DEPOSIT. While wallet developer would be encouraged to
-add the ZSF_DEPOSIT field to their UIs, no changes or new
-behavior are absolutely required for developers or ZEC holders.
-
Motivation
-
The Zcash network’s operation and development relies fundamentally on
-the block reward system inherited from Bitcoin. This system currently
-looks sometihng like this:
+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]
+
The term "network upgrade" in this document is 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
+
"We" - the ZIP authors, owners listed in the above front matter
+
"MAX_MONEY" is the ZEC supply cap. For simplicity, this ZIP defines it to be 21,000,000 ZEC, although this is slightly larger than the actual supply cap of the original ZEC issuance mechanism.
+
Abstract
+
This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
+
The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a ZSF_BALANCE, and for a new transaction field to be added, called ZSF_DEPOSIT. While wallet developer would be encouraged to add the ZSF_DEPOSIT field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
+
This ZIP does not change the current ZEC issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
+
Motivation
+
The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks like this:
-
At Every New Block:
-
-
Miner rewarded via unissued ZEC
-
Transaction fees (inputs - outputs)
-
+
At Every New Block:
+
Miner and funding streams are rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
+
Miner is rewarded via Transaction fees (inputs - outputs)
-
The Zcash Sustainability Fund is a proposed replacement to that
-payout mechanism, with the relevant parts in bold below:
-
-
Unmined ZEC is now accounted for as
-ZSF_BALANCE
-
Transaction includes optional contributions to ZSF via a
-ZSF_DEPOSIT field
-
Thus, at Every New Block:
+
+
+
The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in bold below:
-
Miner still rewarded from
-ZSF_BALANCE
-
Transaction fees (inputs - outputs), including
-the ZF_DEPOSIT amount
-
+
Unmined ZEC is now accounted for as ZSF_BALANCE
+
Transaction includes optional contributions to ZSF via a ZSF_DEPOSIT field
+
Thus, at Every New Block:
+
Miner and funding streams rewarded the same constant amount, but from ZSF_BALANCE (this constant amount still halves at specified heights)
+
Miner is rewarded via Transaction fees (inputs - outputs), where outputs includes the ZSF_DEPOSIT amount
+
+
-
This design gives similar clarity and algorithmic control benefits,
-while also allowing other sources of funds for Block Rewards in addition
-to newly issued ZEC, via ZSF Deposits.
-
For example, an end-user wallet application could have an option to
-contribute a portion of a transaction to the ZSF, which would be
-included in a ZSF_DEPOSIT field in the transaction, to be
-taken into account by the Zcash nodes.
-
This ZIP is explicitly agnostic as to the recipients of block rewards
-so that acceptance or adoption of the Sustainability Fund does not
-introduce or bundle reallocation decisions with the primary
-proposal.
-
This quite simple alternation has – in our opinion – a multitude of
-benefits:
-
-
Long Term Consensus Sustainability: This mechanism
-supports long-term consensus sustainability by addressing concerns about
-the sustainability of the network design shared by Bitcoin-like systems
-through the establishment of deposits into the Sustainability Fund to
-augment and eventually replace block rewards, ensuring long-term
-sustainability as the issuance rate of Zcash drops and newly issued ZEC
-decreases over time.
-
Benefits to ZEC Holders: Deposits to the ZSF slow
-down the payout of ZEC, temporarily reducing its available supply,
-benefiting current holders of unencumbered active ZEC in proportion to
-their holdings without requiring them to opt into any scheme,
-introducing extra risk, active oversight, or accounting complexity.
-
Network Sustainability: This mechanism involves
-temporarily reducing the supply of ZEC similar to asset burning in
-Ethereum’s EIP-1559, but with potential long-term sustainability
-benefits as the redistribution of deposits contributes to issuance
-rewards and network development, making it an attractive option for
-current and future Zcash users.
-
Reduce “Governance Attack Surface”: The proposal’s
-policies aim to enhance predictability, financial sustainability, and
-minimize governance capture risks, ensuring Zcash’s successful evolution
-as a global currency with a growing userbase and stakeholdership.
-
Ecosystem Benefits of Longer Time Horizons: A
-reliable and long-term functioning Zcash blockchain allows users to make
-secure long-term plans, leading to a sustainable and virtuous adoption
-cycle, rather than being influenced by short-term trends.
-
Consensus Continuity During Lulls: Rate-limited
-payouts from the Sustainability Fund help maintain blockchain security
-during periods of low activity by utilizing savings from high activity
-periods, whereas direct miner rewards tied to short-term activity may
-favor miners with significant savings reserves or access to credit,
-reducing mining competitiveness and overall ecosystem certainty about
-mining capacity.
-
Mitigate Payment-to-Self Vulnerabilities: The risk
-of miners benefiting from “spoofing” transactions and the desire for a
-fixed eventual supply goal lead to considering alternatives like the
-Sustainability Fund, which pays out fees over a long enough time horizon
-to prevent recouping costs, allowing Zcash to remain closer to its
-supply goal and offering an alternative to other protocol designs that
-destroy or burn funds.
-
Recovery of “Soft-Burned” Funds: In some instances,
-such as miners not claim all available rewards, some ZEC goes
-unaccounted for though not formally burned. This proposal would recover
-it through the ZSF_BALANCE mechanism described below.
+
For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a ZSF_DEPOSIT field in the transaction, to be taken into account by the Zcash nodes.
+
This quite simple alteration has -- in our opinion -- a multitude of benefits:
+
+
Long Term Consensus Sustainability: This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
+
Benefits to ZEC Holders: Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
+
Recovery of "Soft-Burned" Funds: In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the ZSF_BALANCE mechanism described below.
-
Disclaimer 1: Long term success depends on the specific
-mechanisms of deposits, the quantities involved, and broader economic
-considerations. For such as if the payout rate is both sufficient and
-not excessive enough to threaten sustainability.
-
Specification
-
In practice, The Zcash Sustainability Fund is a single global balance
-maintained by the node state and contributed to via a single transaction
-field. This provides the economic and security support described in the
-motivation section, while also importantly keeping the fund payouts
-extremely simple to describe and implement.
-
The two modifications are: 1. The re-accounting of unmined ZEC as a
-node state field called ZSF_BALANCE 2. The addition of a
-transaction field called ZSF_DEPOSIT
-
Please note that a network upgrade is required for
-this work to be fully implemented.
-
ZSF_BALANCE
-
Upon activation at height H, the ZEC issuance mechanism
-is permanently suspended, the value of ZSF_BALANCE[H] is
-set to the remainder of unissued ZEC. This must be done before the
-Block Rewards Payout Rule is enforced for the block at
-height H. This is not a pre-mine. This is
-simply a re-accounting of unissued ZEC that comes with the benefit of
-other possible sources of funding.
+
Specification
+
In practice, The Zcash Sustainability Fund is a single global balance maintained by the node state and contributed to via a single transaction field. This provides the economic and security support described in the motivation section, while also importantly keeping the fund payouts extremely simple to describe and implement.
+
The two modifications are:
+1. The re-accounting of unmined ZEC as a node state field called ZSF_BALANCE
+2. The addition of a transaction field called ZSF_DEPOSIT
+
ZSF_BALANCE
+
The ZEC issuance mechanism is re-defined to remove funds from ZSF_BALANCE, which is initially set to MAX_MONEY at the genesis block.
Consensus nodes are then required to track new per-block state:
ZSF_BALANCE[H] : u64 [zatoshi]
-
The state is a single 64 bit integer (representing units of
-zatoshi) at any given block height, H,
-representing the Sustainability Fund balance at that height,
-H. The ZSF_BALANCE can be calculated using the
-following formula:
-
TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
-
This formula holds for all future blocks. It is safe and semantically
-consistent to consider all blocks prior to the activation height to have
-a value of 0 in this field. This is not required by this
-proposal but may be convenient in designs or implementations.
-
ZSF_BALANCE
-Requirements
+
The state is a single 64 bit integer (representing units of zatoshi) at any given block height, H, representing the Sustainability Fund balance at that height, H. The ZSF_BALANCE can be calculated using the following formula:
+
ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))
+where Unclaimed(height) is the portion of the block subsidy and miner fees that are unclaimed for the block at the given height.
+
The block at height H commits to ZsfBalanceAfter(H) as part of a new block commitment in the block header, at the end of the hashBlockCommitments chain in ZIP-244.
+
TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
+
Deposits into the Sustainability Fund
+
Sustainability fund deposits can be made via the new zsfDeposit field. This can be done by:
+- ZEC fund holders, in non-coinbase transactions;
+- Zcash miners, in coinbase transactions.
+
In transaction versions without this new field:
+- unclaimed miner fees and rewards in coinbase transactions are re-defined as deposits into the sustainability fund, and
+- there are no sustainability fund deposits from non-coinbase transactions.
+
Note: older transaction versions can continue to be supported after a network upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.
+
zsfDeposit fields in transactions
+
Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
+
This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
-
The value of ZSF_BALANCE SHOULD equal 0
-for all blocks prior to the activation height H.
-
The above described formula
-TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
-MUST hold for all future blocks.
-
Future protocol changes MUST NOT reduce or redistribute the funds in
-the ZSF, and they may not increase the payout rate to a reasonable
-approximation beyond the four year half-life constraint.
+
zsfDeposit : u64 [zatoshi]
-
ZSF_DEPOSIT
-
Each transaction can dedicate some of its excess funds to the ZSF,
-and the remainder becomes the miner fee, with any excess miner
-fee/reward going to the ZSF
-
This is achieved by adding a new field to all transactions:
+
The ZSF_BALANCE[H] for a block at height H can be calculated given a value of ZSF_BALANCE[H-1] and the set of transactions contained in that block. First, the ZSF_DEPOSIT[H] is calculated based solely on ZSF_BALANCE[H-1]. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the ZSF_DEPOSIT fields of all transactions in the block is added to the balance.
+
Non-Coinbase Transactions
+
If the ZSF_DEPOSIT field is not present in an older transaction version, it is defined to be zero for non-coinbase transactions.
+
Consensus Rule Changes
-
ZSF_DEPOSIT : u64 [zatoshi]
+
Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs and sustainability fund deposits remove value from this pool.
-
The ZSF_BALANCE[H] for a block at height H
-can be calculated given a value of ZSF_BALANCE[H-1] and the
-set of transactions contained in that block. First, the
-ZSF_DEPOSIT[H] is calculated based solely on
-ZSF_BALANCE[H-1]. This is subtracted from the previous
-block’s balance to be distributed as part of the block reward. Second,
-the sum of all the ZSF_DEPOSIT fields of all transactions
-in the block is added to the balance.
-
It is safe and consistent to treat older transactions using
-pre-Sustainability Fund formats as if they have this field implicitly
-present with a value of 0 where that simplifies designs or
-implementations.
-
Note: this field is not generally considered an “output” because it
-differs from other outputs in several significant ways:
+
Coinbase Transactions
+
Any excess miner fee/reward is sent to the ZSF.
+
In new blocks, this deposit is tracked via the ZSF_DEPOSIT field in coinbase transactions.
+
If the ZSF_DEPOSIT field is not present in a coinbase transaction with an older transaction version, it is defined as the value of any unspent miner fee and miner reward. This re-defines these previously unspendable funds as ZSF deposits.
+
Consensus Rule Changes
-
All ZSF_DEPOSIT fields contribute to a single global
-balance rather than a user-specific output state,
-
Consensus validation can account for this field by updating
-ZSF_BALANCE[H] and do not need to track any transaction
-field specific state after this accounting in contrast to e.g. UTXOs
-which must be tracked until spent.
-
This field does not contribute to the transaction graph of senders
-or recipients whether transparent or protected by cryptography.
+
The remaining value in the transparent transaction value pool of a coinbase transaction is deposited in the sustainability fund.
-
ZSF_DEPOSIT
-Requirements
+
ZSF_DEPOSIT Requirements
-
There MUST be only one ZSF_DEPOSIT field per
-transaction
-
ZIP 225 [3] MUST be updated to include ZSF_DEPOSIT. ZIP
-244 MAY be updated as well.
-
Separate programming language implementations (C++, Rust, etc) MUST
-guarantee that the calculations described above are consistent
+
ZIP 230 [3] must be updated to include ZSF_DEPOSIT.
+
ZIP 244 [4] must be updated as well to include ZSF_DEPOSIT.
-
Rationale
-
All technical decisions in this ZIP are balanced between the
-necessary robustness of the ZSF mechanics, and simplicity of
-implementation.
-
ZSF_BALANCE as node
-state
-
Tracking the ZSF_BALANCE value as a node state using the
-above formula is very simple in terms of implementation, and should work
-correctly given that the node implementations calculate the value
-according to the specifications.
-
Alternative:
-ZSF_BALANCE as block header commitment
-
An alternative to node state could be to include the
-ZSF_BALANCE field as a block header and require a block
-header commitment.
-
Requiring block-header-rooted commitments of global fund balances
-such as the Sustainability Fund ensures that any consensus deviating
-bugs in accounting of this balance are immediately detected in the
-earliest impacted block. It also removes some of the need for explorer
-sites and other analytics services from tracking this value
-independently, assuming the committed value is made available by common
-APIs. This helps ensure that all explorers track and report the correct
-value.
-
ZSF_DEPOSIT
-as explicit transaction field
-
An explicit value distinguishes the ZEC destined to Sustainability
-Fund deposits from the implicit transaction fee. Explicitness also
-ensures any arithmetic flaws in any implementations are more likely to
-be observed and caught immediately.
All technical decisions in this ZIP are balanced between the necessary robustness of the ZSF mechanics, and simplicity of implementation.
+
ZSF_BALANCE as node state
+
Tracking the ZSF_BALANCE value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
+
Committing to ZsfBalanceAfter in the block header
+
The ZsfBalanceAfter node state has a block header commitment as specified above.
+
Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
+
ZSF_DEPOSIT as explicit transaction field
+
An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
+
Deployment
+
This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
+
The ZsfBalanceAfter node state commitment will be included in the hashBlockCommitments chain starting with the network upgrade activation block.
\ No newline at end of file
diff --git a/draft-zsf.md b/draft-zsf.md
index 1e8d60676..b8188ac1d 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -19,8 +19,7 @@ The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL",
The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [2]
-The term "Block Rewards" refers to the algorithmic
-issuance of ZEC to every block's creator -- part of the consensus rules.
+"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
From 5e6c367720fc2d6707948bdaaded7f7a82a17bcc Mon Sep 17 00:00:00 2001
From: Mark Henderson
Date: Wed, 27 Sep 2023 12:26:23 -0400
Subject: [PATCH 043/119] update: references and definitions
---
draft-issuance.html | 252 +++++++++++++++++++-------------------------
draft-issuance.md | 19 +++-
2 files changed, 123 insertions(+), 148 deletions(-)
diff --git a/draft-issuance.html b/draft-issuance.html
index 93f69ae02..05812d483 100644
--- a/draft-issuance.html
+++ b/draft-issuance.html
@@ -1,13 +1,4 @@
-
-
-
- Draft issuance: Smooth Out The Block Subsidy Issuance
-
-
-
-
-
-
ZIP:
+
ZIP:
Title: Smooth Out The Block Subsidy Issuance
Owners: Jason McGee <jason@shieldedlabs.com>
Mark Henderson <mark@equilibrium.co>
@@ -20,140 +11,115 @@
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
+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]
“We” - the ZIP authors, owners listed in the above front matter
-
“AVAILABLE_SUBSIDIES(h)” is the total ZEC available to
-pay out Block Subsidies from at block height h, ie. “not
-yet mined ZEC at h”.
-
“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 spent in around 113
-years.
-
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 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.
-
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:
-
Requirements
-
-
Block subsidies MUST be weakly decreasing
-
Block subsidies SHOULD approximate a continuous function
-
When AVAILABLE_SUBSIDIES(h) > 0 then block subsidies
-for block h MUST always be > 0, preventing
-a final “unmined” zatoshi
-
For any 4 year period, all paid out block subsidies MUST equal
-approximately half of AVAILABLE_SUBSIDIES at the beginning
-of that 4 year period
-
This functionality MUST be introduced as part of a network
-upgrade
+
“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.
+
“BLOCK_SUBSIDY_FRACTION” = 41 / 100,000,000 or 0.00000041
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.
+
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.
+
Specification
+
Smoothing the issuance curve is possible using an exponential decay formula that
+satisfies the following requirements:
+
Issuance Goals
+
+
Block subsidies are monotonically decreasing, as long as ZsfBalanceAfter(h) is monotonically decreasing
+
Block subsidies approximate a continuous function
+
When ZSF_BALANCE(h) > 0 then block subsidies for block h
+MUST always be > 0, preventing a final “unmined” zatoshi
+
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
+
This functionality MUST be introduced as part of a network upgrade
-
The above requirements assume no deflationary action, i.e. that no
-ZEC is added to AVAILABLE_SUBSIDIES. They are referenced
-below as Rn.
-
Solution
-
Given the block height h define a function
-S, such that:
-
S(h) = Block subsidy for a given h,
-that satisfies above requirements.
-
Please note that
-
AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h)
-assuming no deflationary action.
-
An exponential decay function S satisfies
-R1 and R2 above:
That value of 41 / 100_000_000 was selected so that it
-satisfies the equation:
-
(1 - BLOCK_SUBSIDY_FRACTION)^NUMBER_OF_BLOCKS_IN_4_YEARS ~ ½
-
Meaning after a period of 4 years around half of
-AVAILABLE_SUBSIDIES will be paid out as block subsidies,
-thus satisfying R4.
-
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.
-
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:
-
Rust Code
-
fn main() {
-// approximate available subsidies in August of 2023
-letmut available_subsidies:i64=4671731*100_000_000;
-letmut 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;
-}
-}
+
The above requirements assume no deflationary action, i.e. that no ZEC is added
+to ZSF_BALANCE. They are referenced below as Rn.
+
Issuance Calculation
+
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:
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.
+
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:
+
Rust Code
+
```rust
+fn main() {
+ // approximate available subsidies in August of 2023
+ let mut available_subsidies: i64 = 4671731 * 100_000_000;
+ 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.
-
-
+
Note the addition of 99,999,999 before division to force rounding up of non-zero values.
\ No newline at end of file
diff --git a/draft-issuance.md b/draft-issuance.md
index 56e8b96ec..8e1d3c1d5 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -22,11 +22,9 @@ and “REQUIRED” in this document are to be interpreted as described in RFC 21
"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.
+“Block Subsidy” - to be interpreted as described in ZIP TBD [3]
-“Issuance” - The method by which unmined or unissued ZEC is converted to ZEC available
-to users of the network
+“Issuance” - to be interpreted as described in ZIP TBD [3]
“We” - the ZIP authors, owners listed in the above front matter
@@ -36,6 +34,8 @@ from unmined ZEC, and other fund deposits.
“`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`
+
# Abstract
This ZIP proposes a change to how nodes calculate the block subsidy.
@@ -49,7 +49,7 @@ zatoshi being issued in around 114 years.
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
+ 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
@@ -164,3 +164,12 @@ 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.
+
+
+# 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
From 013dcc1812c8ba5a218d54a0636387fa976a7593 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 17:56:59 -0400
Subject: [PATCH 044/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 8e1d3c1d5..2ac01242c 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -22,9 +22,9 @@ and “REQUIRED” in this document are to be interpreted as described in RFC 21
"Network upgrade" - to be interpreted as described in ZIP 200. [2]
-“Block Subsidy” - to be interpreted as described in ZIP TBD [3]
+“Block Subsidy” - to be interpreted as described in the Zcash Protocol Specification (TODO ZIP Editors: link from comment).
-“Issuance” - to be interpreted as described in ZIP TBD [3]
+“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out if this definition is correct or can be removed).
“We” - the ZIP authors, owners listed in the above front matter
From bf090f46e6cbc751941c2f759fde3b4b5a972d8d Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 17:57:07 -0400
Subject: [PATCH 045/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 2ac01242c..44ffe49c6 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -26,8 +26,6 @@ and “REQUIRED” in this document are to be interpreted as described in RFC 21
“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out if this definition is correct or can be removed).
-“We” - the ZIP authors, owners listed in the above front matter
-
“`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.
From dca11748be4850baf19221d79041356201fabf2f Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 17:58:33 -0400
Subject: [PATCH 046/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 44ffe49c6..ef6c03d59 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -27,7 +27,7 @@ and “REQUIRED” in this document are to be interpreted as described in RFC 21
“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 #TODO reference#. The Sustainability Fund is used to pay out Block Subsidies
+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.
“`BLOCK_SUBSIDY_FRACTION`” = 41 / 100,000,000 or `0.00000041`
From de30feac97ad991ef89239e951ffdac6979bd7ed Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 17:58:47 -0400
Subject: [PATCH 047/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index ef6c03d59..c18bdb346 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -38,9 +38,9 @@ from unmined ZEC, and other fund deposits.
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
+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 4 year cycle, and results in the last
+scheme would approximate the current issuance over 4-year intervals, and results in the last
zatoshi being issued in around 114 years.
# Motivation
From 45ff587b6f4b030e810918ab2cb5835d9a47d10a Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 18:31:54 -0400
Subject: [PATCH 048/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index c18bdb346..7e7e441e6 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -74,19 +74,18 @@ how rewards will be distributed over time.
-# Specification
+# Requirements
Smoothing the issuance curve is possible using an exponential decay formula that
satisfies the following requirements:
-## Issuance Goals
+## Issuance Requirements
-1. Block subsidies are monotonically decreasing, as long as `ZsfBalanceAfter(h)` is monotonically decreasing
+1. The issuance can be summarised into a reasonably simple explanation
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
+3. If there are funds in the ZSF, 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 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
5. This functionality MUST be introduced as part of a network upgrade
The above requirements assume no deflationary action, i.e. that no ZEC is added
From 8cc6f92b39b399b929b1e32e35d0cf2ab43c1811 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 18:32:13 -0400
Subject: [PATCH 049/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/draft-issuance.md b/draft-issuance.md
index 7e7e441e6..77946fe6a 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -88,8 +88,6 @@ satisfies the following requirements:
TODO daira: add a requirement that makes the initial total issuance match the previous total issuance
5. This functionality MUST be introduced as part of a network upgrade
-The above requirements assume no deflationary action, i.e. that no ZEC is added
-to `ZSF_BALANCE`. They are referenced below as **Rn**.
## Issuance Calculation
From 9f4e7fd4771c6bd0980fd5aaa929b5d06c645270 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson
Date: Wed, 27 Sep 2023 18:32:24 -0400
Subject: [PATCH 050/119] Update draft-issuance.md
Co-authored-by: teor
---
draft-issuance.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/draft-issuance.md b/draft-issuance.md
index 77946fe6a..7e0985ee7 100644
--- a/draft-issuance.md
+++ b/draft-issuance.md
@@ -89,6 +89,8 @@ TODO daira: add a requirement that makes the initial total issuance match the pr
5. This functionality MUST be introduced as part of a network upgrade
+# Specification
+
## Issuance Calculation
Given the block height `h` define a function **S**, such that:
From 78b6c5200da514a2a1096cd1c1b67633751c0b43 Mon Sep 17 00:00:00 2001
From: Mark Henderson
Date: Fri, 29 Sep 2023 10:35:39 -0400
Subject: [PATCH 051/119] fix: date
---
draft-zsf.html | 2 +-
draft-zsf.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/draft-zsf.html b/draft-zsf.html
index 7c7ee08d6..4feb5732d 100644
--- a/draft-zsf.html
+++ b/draft-zsf.html
@@ -8,7 +8,7 @@
Credits:
Status: Draft
Category: Ecosystem
-Created: 2023-08-
+Created: 2023-08-16
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]
diff --git a/draft-zsf.md b/draft-zsf.md
index b8188ac1d..08931eba4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -9,7 +9,7 @@ Original-Authors: Nathan Wilcox
Credits:
Status: Draft
Category: Ecosystem
-Created: 2023-08-
+Created: 2023-08-16
License: BSD-2-Clause
```
From 09e70fefc1d3a0eb45a95f808d7bbfc053a30e05 Mon Sep 17 00:00:00 2001
From: Mark Henderson
Date: Fri, 29 Sep 2023 10:41:45 -0400
Subject: [PATCH 052/119] fix: revert accidental changes to other files
---
.github/workflows/render.yml | 2 +-
protocol/protocol.tex | 4 ++--
zip-0032.html | 4 ++--
zip-0032.rst | 2 +-
zip-0316.html | 4 ++--
zip-0316.rst | 2 +-
zip-0321.html | 4 ++--
zip-0321.rst | 2 +-
8 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml
index 8ff554395..0cd8240a0 100644
--- a/.github/workflows/render.yml
+++ b/.github/workflows/render.yml
@@ -8,7 +8,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Set up Git repository
- uses: actions/checkout@v3.6.0
+ uses: actions/checkout@v3.5.3
- name: Compile Zcash Protocol Specification
uses: ./.github/actions/render-protocol-pdf
diff --git a/protocol/protocol.tex b/protocol/protocol.tex
index 5b1c15610..532d0c933 100644
--- a/protocol/protocol.tex
+++ b/protocol/protocol.tex
@@ -11929,8 +11929,8 @@
for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$,
or if $\NullifierKey \notin \SubgroupJ$.
-For \fullViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}.
-For \fullViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}.
+For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}.
+For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}.
} %sapling
diff --git a/zip-0032.html b/zip-0032.html
index 333d780e2..c7d7ad4b3 100644
--- a/zip-0032.html
+++ b/zip-0032.html
@@ -232,7 +232,7 @@