ZIP: 233
Title: Network Sustainability Mechanism: Removing Funds From Circulation
Owners: Jason McGee <jason@shieldedlabs.net>
        Zooko Wilcox <zooko@shieldedlabs.net>
        Mark Henderson <mark@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.]

\(\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 remove funds entirely from circulation on the network. The explicit intent of this removal is that the funds will be returned to circulation through future block subsidies, rather than being permanently destroyed or held in reserve for discretionary use. 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:

Long Term Consensus Sustainability: By enabling the removal of funds from circulation, 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. The intent is that removed funds will be automatically and algorithmically reissued through future block subsidies, sustaining the network’s long-term security budget, whether or not all three ZIPs comprising the Network Sustainability Mechanism are deployed in the same network upgrade.
Benefits to ZEC Holders: Removing funds from circulation reduces the circulating supply of ZEC. To the extent that this potentially contributes to an increase in the value of remaining ZEC, it can be argued to benefit network users in proportion to their holdings — without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.

Privacy Implications

ZIP 233 adds a new type of transparent transaction event that is fully visible to chain observers, and linked to other events performed in the transaction. The removal of funds from circulation does represent a potential distinguisher; transactions that intentionally remove funds from circulation are likely to represent a small fraction of Zcash transactions, and so this will provide another tool that adversaries may use to be able to segment users of the network.

Requirements

The mechanism enables users to remove funds from the circulating supply, and each removal event is explicitly specified in the corresponding transaction.
The process is publicly auditable, allowing network participants to verify the amount and occurrence of funds removed from circulation.

Specification

Changes to ZIP 248

This ZIP proposes to register bundle type 5 variant 0 (“ZIP 233 NSM field”) in the V6 transaction bundle type registry defined in ZIP 248 ⁷.

BundleType	BundleVariant	`mValuePoolDeltas`	`mEffectBundles`	`mAuthBundles`
5	0	✅	❌	❌

\(\mathsf{zip233\_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{zip233\_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 mechanism by which the funds removed from circulation may be reissued through future block subsidies.

The NSM bundle has no effecting data and no authorizing data. The amount to be removed from circulation is represented solely as an entry in mValuePoolDeltas with bundleType = 5 and assetClass = 0 (ZEC).

NSM Amount

When the mValuePoolDeltas map contains an entry with bundleType = 5, the transaction removes funds from circulation. The entry’s value field MUST BE nonpositive; its negation is denoted \(\mathsf{zip233\_amount}\) and represents the value in zatoshis removed from circulation when the transaction is mined. If no such entry is present, \(\mathsf{zip233\_amount}\) is defined to be 0.

The NSM bundle’s effect on the transparent transaction value pool does not reflect an output being produced in any chain value pool. At the point at which the transaction is applied to the global chain state, \(\mathsf{zip233\_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 funds removed from circulation would become available for reintroduction into the issued supply in subsequent blocks.

Changes to the Zcash Protocol Specification

Let \(\mathsf{NSMBundleId} = 5.\)

Let \(\mathsf{Zec}\) be the asset UUID for ZEC as defined in ZIP 248 ⁷.

Make a change to § 3.4 ‘Transactions and Treestates’ ⁹ adding the following consensus rules:

[NU7 onward] The assetClass for any entry in mValuePoolDeltas having bundleType \(= \mathsf{NSMBundleId}\) MUST be 0. That is, amounts to remove from circulation MUST be denominated in ZEC.

[NU7 onward] The value of \(\mathsf{mValuePoolDeltas}[(\mathsf{NSMBundleId}, \mathsf{Zec})]\), if present, MUST be nonpositive. Its absolute value is \(\mathsf{zip233\_amount}\).

[NU7 onward] \(\mathsf{zip233\_amount}\) does not result in an output being produced in any chain value pool.

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

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

Modifications to Digest Algorithms

The \(\mathsf{zip233\_amount}\) is committed to the transaction identifier and signature digest via the value_pool_deltas_digest defined in ZIP 248 ⁷. Since the NSM bundle (bundle type 5) has no effecting data and no authorizing data, its only contribution to the transaction digest is through its entry in mValuePoolDeltas.

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 amount to remove from circulation

An explicit value distinguishes the funds to remove from circulation 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. ¹¹