Skip to content
ZIPs.tools

ZIP 236

Blocks should balance exactly

  • Final
Proposal metadata
ID
236
Status
Final
Category
Consensus
Owners
  • Daira-Emma Hopwood
Created
2024-07-02
License
MIT
Contents
  1. Terminology
  2. Abstract
  3. Motivation
  4. Requirements
  5. Non-requirements
  6. Specification
  7. Changes to the Zcash Protocol Specification
  8. Deployment
  9. Reference implementation
  10. Acknowledgements
  11. References
Preamble
ZIP
236
Title
Blocks should balance exactly
Credits
  • Jack Grigg
  • Kris Nuttycombe
Status
Final
Category
Consensus
Created
2024-07-02
License
MIT

Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 1 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.2

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification.3

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

Abstract

In the current Zcash protocol, the miner of a coinbase transaction is permitted to claim up to and including the total amount of miner subsidy plus fees from other transactions in the block, but is not required to claim the full amount.

This proposal would require the full amount of miner subsidy and fees to be collected in coinbase transactions.

Motivation

The current semantics of coinbase transactions creates a potential for miners to miscalculate the total amount of miner subsidy plus fees in a block. If they claim a higher amount than the actual miner subsidy plus total fees, the block will be invalid, but if they claim a lower amount, the excess is effectively burnt. As a consequence, the effective ZEC issuance can fall short of the amount calculated from the intended issuance curve.

This unnecessarily complicates the question of how much ZEC has been issued: if it is defined as not including the amounts that were left unclaimed by miners, then it is difficult to calculate, and cannot be predicted exactly in advance for any given block height. Alternatively if it is defined to include those amounts, then that introduces potentially confusing discrepancies between different definitions of issuance or total supply.

Requirements

The consensus rule change specified in this ZIP must:

  • allow issuance to be predicted exactly in advance, starting from the point at which it activates;
  • preclude errors by miners in computing the total miner subsidy plus fees for transactions in the mined block;
  • be deployable in the NU6 network upgrade, which is not expected to define a new transaction version.

Non-requirements

Since this ZIP is intended to activate in a network upgrade that is not expected to support a new transaction version, it cannot resolve the issue that the amounts of fees are implicit in non-coinbase transactions. That issue results in various potential security difficulties and the potential for users' wallets to inadvertently overpay the fee, but solving that would require an explicit "fee" field.

(It would technically be possible to encode the fee as a transparent output, but that would be a more disruptive change than is desirable, since other consensus rules would have to change in order to prevent this output from being spent, and since existing consumers of the transaction format could misinterpret such outputs.)

This consensus change is not intended to prevent other methods of provably removing ZEC from the circulating supply, such as sending it to an address for which it would be demonstrably infeasible to find the spending key.

Specification

From the activation block of this ZIP onward, coinbase transactions MUST claim all of the available miner subsidy plus fees in their block.

Changes to the Zcash Protocol Specification

The following sentence in § 3.4 ‘Transactions and Treestates’5:

The remaining value in the transparent transaction value pool of a coinbase transaction is destroyed.

is clarified as follows:

The remaining value in the transparent transaction value pool of coinbase transactions in blocks prior to NU6 is destroyed. From activation of NU6, this remaining value is required to be zero; that is, all of the available balance MUST be consumed by outputs of the coinbase transaction.

In § 7.1.2 ‘Transaction Consensus Rules’6 as modified by 7, replace:

The total output value of a coinbase transaction MUST NOT be greater than its total input value.

with

[Pre-NU6] The total output value of a coinbase transaction MUST NOT be greater than its total input value.

[NU6 onward] The total output value of a coinbase transaction MUST be equal to its total input value.

These changes apply identically to Mainnet and Testnet.

Deployment

This ZIP was deployed with NU6.8

The wording change to § 7.1.2 depends on9 which was also deployed with NU6.10

Reference implementation

Acknowledgements

The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.

References


  1. Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"↩︎

  2. ZIP 200: Network Upgrade Mechanism↩︎

  3. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet↩︎

  4. Zcash Protocol Specification, Version 2024.5.1 or later↩︎

  5. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.4: Transactions and Treestates↩︎

  6. Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1.2: Transaction Consensus Rules↩︎

  7. ZIP 2001: Lockbox Funding Streams↩︎

  8. ZIP 253: Deployment of the NU6 Network Upgrade↩︎

  9. ZIP 2001: Lockbox Funding Streams↩︎

  10. ZIP 253: Deployment of the NU6 Network Upgrade↩︎

Citation graph

Hover or tap a node to see its title and citations.
Loading citation graph…
ZIP 236: Blocks should balance exactly · ZIPs.tools