ZIP: 233
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:
Status: Draft
Category: Consensus / Ecosystem
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]

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 block subsidy 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 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:
  • 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

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:

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. Recovery of “Soft-Burned” Funds: In some instances, such as miners not claiming 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

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[height] : u64 [zatoshi]

The state is a single 64 bit integer (representing units of zatoshi) at any given block height, height, representing the Sustainability Fund balance at that height. The ZSF_BALANCE can be calculated using the following formula:

$\mathsf{ZsfBalanceAfter}(\mathsf{height}) = \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} (\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - \mathsf{BlockSubsidy}(h))$

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 height commits to ZsfBalanceAfter(height) 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]:

• 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.

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

• 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 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.

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).

References

[1]: Key words for use in RFCs to Indicate Requirement Levels

[2]: ZIP 200: Network Upgrade Mechanism

[3]: ZIP 230: v6 transactions, including ZSAs

[4]: ZIP 244: Transaction Identifier Non-Malleability