- ZIP: XXX
-Title: Blocks should balance exactly
-Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
-Credits: Jack Grigg
- Kris Nuttycombe
-Status: Draft
-Category: Consensus
-Created: 2024-07-02
-License: MIT
-Discussions-To: <https://github.com/zcash/zips/issues/864>
- 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 terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification.
- The character § is used when referring to sections of the Zcash Protocol Specification .
-
- 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. More specifically, the following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of the Zcash Protocol Specification :
-
- Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. The remaining value in the transparent transaction value pool of a coinbase transaction is destroyed.
- Consensus rule: The remaining value in the transparent transaction value pool MUST be nonnegative.
-
- is modified to become:
-
- Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions on the transaction value pool are specified in § 4.13 and § 4.14 respectively.
- As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. That is, the sum of those values for non-coinbase transactions in each block is treated as an implicit input to the transaction value balance of the block's coinbase transaction (in addition to the implicit input created by issuance).
- The remaining value in the transparent transaction value pool of coinbase transactions in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value is required to be zero; that is, all of the available balance MUST be consumed by outputs of the coinbase transaction.
- Consensus rules:
-
- - The remaining value in the transparent transaction value pool of a non-coinbase transaction MUST be nonnegative.
- - [Pre-NU-X] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be nonnegative.
- - [NU-X onward] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be zero.
-
-
- where "NU-X" is to be replaced by the designation of the network upgrade in which this ZIP will be activated.
- Note that the differences in the first two paragraphs of the above replacement text are clarifications of the protocol, rather than consensus changes. Those could be made independently of this ZIP.
- This change applies identically to Mainnet and Testnet.
-
- Deployment
- Subject to community agreement, this ZIP is proposed to be deployed with NU6.
-
- Reference implementation
- TODO
-
- Acknowledgements
- The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.
-
- References
-
-
-
-
-
-
-
-
+