ZIP: 233
Title: Network Sustainability Mechanism: Burning
Owners: Jason McGee <jason@shieldedlabs.net>
        Zooko Wilcox <zooko@shieldedlabs.net>
        Tomek Piotrowski <tomek@eiger.co>
        Mariusz Pilarek <mariusz@eiger.co>
        Paul Dann <paul@eiger.co>
Original-Authors: Nathan Wilcox
Credits:
Status: Draft
Category: Consensus / Ecosystem
Created: 2023-08-16
License: BSD-2-Clause
Discussions-To: <https://github.com/zcash/zips/issues/922>

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 ZEC becomes available for circulation on the network.

“We” - the ZIP Owners and Authors, listed in the above front matter.

“MAX_MONEY” is the total ZEC supply cap, defined as 21,000,000 ZEC. This is slightly larger than the supply cap for the current issuance mechanism, but is the value used in existing critical consensus checks.

Abstract

We propose the introduction of a mechanism to voluntarily burn funds, removing those funds entirely from circulation on the network. This mechanism, in combination with ZIPs 234 and 235, comprises a long-term strategy for the sustainability of the network. We will refer to the combined effects of these three ZIPs as the “Network Sustainability Mechanism”.

Motivation

This mechanism seeks to address concerns about the sustainability of the network design shared by Bitcoin-like systems:

1. Long Term Consensus Sustainability: By enabling the burning of funds, the network gains the ability to create “headroom” between the chain value and MAX_MONEY. This lays necessary groundwork for extending the miner reward system, which currently has a clear final end date.
2. Benefits to ZEC Holders: Burning funds reduces the supply of ZEC, benefiting network users in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.

Specification

The modifications required are:

1. The addition of a transaction field representing an amount to burn for a given transaction.
2. The inclusion of the burn amount in the calculated total output value for a given transaction.
3. Consensus rules to ensure the burned amount is no longer available for circulation on the network.

Transaction Format

The following field is added to the v6 transaction format [3]:

Note: Older transaction versions can continue to be supported after a network upgrade, but burning is not possible for these transactions. For example, NU5 supports both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.

Consensus Rules

The burned value must now be considered when calculating the total output value of a transaction. It should be treated similarly to a transparent output, except that there is no way for this value to be used as an input in a future transaction.

Digests

The transaction digest algorithm defined in ZIP 244 [4] is to be modified for v6 transactions as follows:

Section T.1: header_digest [5] is specified in draft-txv6-sighash [6] to read:

A BLAKE2b-256 hash of the following values:

T.1a: version             (4-byte little-endian version identifier including ``fOverwintered`` flag)
T.1b: version_group_id    (4-byte little-endian version group identifier)
T.1c: consensus_branch_id (4-byte little-endian consensus branch id)
T.1d: lock_time           (4-byte little-endian ``nLockTime`` value)
T.1e: expiry_height       (4-byte little-endian block height)
T.1f: burn_amount         (8-byte little-endian burn amount value)

The personalization field of this hash is set to:

ZTxIdHeadersHash

Rationale

All technical decisions in this ZIP are balanced between the necessary robustness of the NSM mechanics, and simplicity of implementation.

New transaction field for burn amount

An explicit value distinguishes the burned ZEC from the 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 7.

References

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

[2]: ZIP 200: Network Upgrade Mechanism

[3]: ZIP 230: Version 6 Transaction Format

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

[5]: ZIP 244: Transaction Identifier Non-Malleability. Section T.1: Header Digest

[6]: Draft Tx v6 Sighash