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 word “MUST” in this document is to be interpreted as described in BCP 14 ¹ when, and only when, it appears in all capitals.

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

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

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

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

“Block Subsidy” - The algorithmic issuance of ZEC/TAZ on block creation, as defined by consensus. This is split between the miner and Funding Streams.

“Issuance” - The method by which ZEC/TAZ becomes available for circulation on the network. [TODO: there is a potential terminology conflict between this and issuance as defined in ZIP 227.]

“Burning” - The method by which ZEC/TAZ becomes unavailable for circulation on the network.

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

Abstract

This ZIP proposes the introduction of a mechanism to voluntarily burn funds, removing those funds entirely from circulation on the network. This mechanism, in combination with ZIP 234 ⁶ and ZIP 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 \(\mathsf{MAX\_MONEY}\). This lays necessary groundwork for extending the block subsidy 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

Burn amount

Each transaction gains a \(\mathsf{burn\_amount}\) property, specifying the value in zatoshis that is burned when the transaction is mined. The burned value subtracts from the remaining value in the “transparent transaction value pool” as described in § 3.4 ‘Transactions and Treestates’ ⁸.

\(\mathsf{burn\_amount}\) does not result in an output being produced in any chain value pool, and therefore from the point at which the transaction is applied to the global chain state, \(\mathsf{burn\_amount}\) is subtracted from the issued supply. It is unavailable for circulation on the network at least through to the end of the block in which the transaction is mined. ZIP 234 ⁶ specifies a potential mechanism by which the burned funds would again become available.

Changes to ZIP 230 ⁹

The following field is appended to the Common Transaction Fields of the v6 transaction format after nExpiryHeight ¹⁰:

The \(\mathsf{burn\_amount}\) of a transaction is defined to be the value of the burnAmount field if present, and otherwise 0.

Notes:

• If both this ZIP and ZIP 2002 are selected for inclusion in the same Network Upgrade, then the ambiguity in ordering of the fields added by these ZIPs would need to be resolved.
• 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.

Changes to the Zcash Protocol Specification

Make a change to § 3.4 ‘Transactions and Treestates’ ⁸ implementing the specification in Burn amount.

In § 7.1 ‘Transaction Encoding and Consensus’ ¹¹, add:

[NU7 onward] \(\mathsf{burn\_amount}\) MUST be in the range \(\{ 0 .. \mathsf{MAX\_MONEY} \}\).

Modifications relative to ZIP 244 ¹²

Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm that applies to v6 transactions differs by appending the encoding of \(\mathsf{burn\_amount}\) to the Common Transaction Fields that are the input to the digest in T.1: header_digest ¹³:

 T.1f: burn_amount (8-byte little-endian burn amount)

Note: If both this ZIP and ZIP 2002 are selected for inclusion in the same Network Upgrade, then the ambiguity in ordering of the fields added by these ZIPs would need to be resolved.

Applicability

All of these changes apply identically to Mainnet and Testnet.

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