Skip to content

Commit

Permalink
Merge pull request #970 from ShieldedLabs/nsm-rephrase-burning
Browse files Browse the repository at this point in the history 
ZIP 233-235: Rephrase all references to "burning"
  • Loading branch information
@nuttycom
nuttycom authored Feb 12, 2025
2 parents 2155475 + 8d224d1 commit c11530f
Show file tree
Hide file tree
Showing 3 changed files with 136 additions and 127 deletions.
92 changes: 47 additions & 45 deletions zips/zip-0233.md
View file
Original file line number Diff line number Diff line change
@@ -1,8 +1,9 @@
```
ZIP: 233
Title: Network Sustainability Mechanism: Burning
Title: Network Sustainability Mechanism: Removing Funds From Circulation
Owners: Jason McGee <[email protected]>
Zooko Wilcox <[email protected]>
Mark Henderson <[email protected]>
Tomek Piotrowski <[email protected]>
Mariusz Pilarek <[email protected]>
Paul Dann <[email protected]>
Expand Down Expand Up @@ -40,9 +41,6 @@ defined by consensus. This is split between the miner and Funding Streams.
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’ [^protocol-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
Expand All @@ -52,83 +50,87 @@ 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 [^zip-0234] and ZIP 235 [^zip-0235], 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”.
This ZIP proposes the introduction of a mechanism to voluntarily remove funds
entirely from circulation on the network. This mechanism, in combination with
ZIP 234 [^zip-0234] and ZIP 235 [^zip-0235], 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.
1. **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.
2. **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.


# Specification

## Burn amount
## Transaction Field

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’ [^protocol-transactions].
Each transaction gains a $\mathsf{zip233\_amount}$ property, specifying the
value in zatoshis that is removed from circulation when the transaction is
mined. The value removed from circulation subtracts from the remaining value in
the "transparent transaction value pool" as described in § 3.4 ‘Transactions and
Treestates’ [^protocol-transactions].

$\mathsf{burn\_amount}$ does not result in an output being produced in any
$\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{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 [^zip-0234]
specifies a potential mechanism by which the burned funds would again become
available.
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
[^zip-0234] specifies a potential mechanism by which the funds removed from
circulation would again become available.

## Changes to ZIP 230 [^zip-0230]

The following field is appended to the Common Transaction Fields of the v6
transaction format after `nExpiryHeight` [^zip-0230-transaction-format]:

| Bytes | Name | Data Type | Description |
|-------|--------------|-----------|----------------------------------------------------------|
| 8 | `burnAmount` | `uint64` | The value to be burned in this transaction, in zatoshis. |
| Bytes | Name | Data Type | Description |
|-------|----------------|-----------|----------------------------------------------------------------------------|
| 8 | `zip233Amount` | `uint64` | The value to be removed from circulation in this transaction, in zatoshis. |

The $\mathsf{burn\_amount}$ of a transaction is defined to be the value of the
`burnAmount` field if present, and otherwise 0.
The $\mathsf{zip233\_amount}$ of a transaction is defined to be the value of the
`zip233Amount` 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.
* Older transaction versions can continue to be supported after a network
upgrade, but removing funds from circulation 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’ [^protocol-transactions]
implementing the specification in [Burn amount].
implementing the specification in [ZIP-233 Amount].

In § 7.1 ‘Transaction Encoding and Consensus’ [^protocol-txnconsensus], add:

> [NU7 onward] $\mathsf{burn\_amount}$ MUST be in the range $\{ 0 .. \mathsf{MAX\_MONEY} \}$.
> [NU7 onward] $\mathsf{zip233\_amount}$ MUST be in the range $\{ 0 .. \mathsf{MAX\_MONEY} \}$.
## Modifications relative to ZIP 244 [^zip-0244]

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
$\mathsf{zip233\_amount}$ to the Common Transaction Fields that are the input
to the digest in T.1: `header_digest` [^zip-0244-t-1-header-digest]:

> T.1f: burn_amount (8-byte little-endian burn amount)
> T.1f: zip233_amount (8-byte little-endian amount to remove from circulation)
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
Expand All @@ -144,11 +146,11 @@ All of these changes apply identically to Mainnet and Testnet.
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
## New transaction field for amount to remove from circulation

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.
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
Expand Down Expand Up @@ -178,7 +180,7 @@ This ZIP is proposed to activate with Network Upgrade 7. [^zip-0254]

[^zip-0234]: [ZIP 234: Network Sustainability Mechanism: Issuance Smoothing](zip-0234.rst)

[^zip-0235]: [ZIP 235: Burn 60% of Transaction Fees](zip-0235.rst)
[^zip-0235]: [ZIP 235: Remove 60% of Transaction Fees From Circulation](zip-0235.rst)

[^zip-0244]: [ZIP 244: Transaction Identifier Non-Malleability](zip-0244.rst)

Expand Down
92 changes: 48 additions & 44 deletions zips/zip-0234.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ ZIP: 234
Title: Network Sustainability Mechanism: Issuance Smoothing
Owners: Jason McGee <[email protected]>
Zooko Wilcox <[email protected]>
Mark Henderson <[email protected]>
Tomek Piotrowski <[email protected]>
Mariusz Pilarek <[email protected]>
Paul Dann <[email protected]>
Expand Down Expand Up @@ -36,8 +37,8 @@ The symbol "$\,\cdot\,$" means multiplication, as described in § 2 ‘Notation
"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e.
ZEC on Mainnet and TAZ on Testnet.

The terms "Block Subsidy", "Issuance", and "Burning" are to be interpreted
as described in ZIP 233. [^zip-0233]
The terms "Block Subsidy" and "Issuance" are to be interpreted as described in
ZIP 233. [^zip-0233]

Let $\mathsf{PostBlossomHalvingInterval}$ be as defined in [^protocol-diffadjustment].

Expand Down Expand Up @@ -66,8 +67,8 @@ inherited from Bitcoin, we propose a smooth logarithmic curve, defined as a
fixed portion of the current value of the Money Reserve at a given block height.

The new issuance scheme would approximate the current issuance over 4-year
intervals, assuming no ZEC/TAZ is burned during that time, and retains the
overall supply cap of `MAX_MONEY`.
intervals, assuming no ZEC/TAZ is removed from circulation during that time, and
retains the overall supply cap of `MAX_MONEY`.


# Motivation
Expand All @@ -76,8 +77,8 @@ Key Objectives:

1. We want to introduce an automated mechanism that allows users of the network
to contribute to the long-term sustainability of the network.
2. We want to enable ZEC that has been burned to be recreated in the future to
benefit network sustainability.
2. We want to enable ZEC that has been removed from circulation to be reissued
in the future to benefit network sustainability.
3. We want to retain the existing ZEC supply cap of 21 million.
4. We want the issuance rate to remain similar to the historical rate for Zcash
(and before that, Bitcoin).
Expand Down Expand Up @@ -111,7 +112,7 @@ that satisfies the following requirements:
non-zero, preventing any final "unmined" zatoshis.
4. For any 4-year period, all paid out block subsidies are approximately equal
to half of the Money Reserve at the beginning of that 4-year period, if no
ZEC is burned during those 4 years.
ZEC is removed from circulation during those 4 years.
5. Decrease the short-term impact of the deployment of this ZIP on block subsidy
recipients, and minimize the potential reputation risk to Zcash of changing
the block subsidy amount.
Expand All @@ -126,39 +127,16 @@ $\mathsf{BLOCK\_SUBSIDY\_FRACTION} = 4126 / 10\_000\_000\_000 = 0.0000004126$

$\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT} = \mathsf{TBD}$

$\mathsf{MoneyReserveAfter}(\mathsf{height}) =$ The value of the Money Reserve
after the specified block height.

The block height will be chosen by the following criteria:

- It is after NU7 activation height.
- It is calculated to be the lowest height after the second halving at
which the NSM issuance would be less than the current BTC-style issuance
_neglecting_ any burnt ZEC (i.e. assuming the amount of ZEC burnt is
exactly 0).

This selection is intended to achieve Key Objective 6 while still being at
a constant, predictable height. An alternative would be to have a dynamic
"latch"-style activation, which would calculate the activation height by
testing the "less than" conditional with every block after the second halving.
We prefer the pre-defined constant height parameter, to give everyone more
_time_ certainty at the cost of _issuance level_ certainty.

The difference in up-front calculation versus dynamic calculation is in
whether or not burns are accounted for (since future burns cannot be
calculated up-front). This means with the pre-defined constant parameter
approach, issuance will jump _up_ some amount at activation. This amount
should be equivalent to all ZEC burnt prior to that height times
$\mathsf{BLOCK\_SUBSIDY\_FRACTION}$. For example, if a total of 100,000 ZEC
were burnt prior to the pre-defined constant activation height, then at
activation the issuance would be larger than BTC-style issuance by
$100\_000\textsf{ ZEC} \cdot \mathsf{BLOCK\_SUBSIDY\_FRACTION}$,
which we calculate equals $0.04126$ ZEC. This example is chosen to
demonstrate that a very large burn amount (much larger than expected) would
elevate issuance by a relatively small amount. For this reason, we believe
a pre-defined constant is a better approach to achieving Key Objective 6
than a "dynamic latch" logic because it is so much simpler to implement
and reason about.

$\mathsf{MoneyReserveAfter}(\mathsf{height}) =$ The value of the Money Reserve
after the specified block height.
- It is calculated to be the lowest height after the second halving at which
the NSM issuance would be less than the current BTC-style issuance _neglecting_
any ZEC removed from circulation (i.e. assuming the amount of ZEC removed from
circulation is exactly 0).

## Issuance Calculation

Expand All @@ -177,6 +155,31 @@ All of these changes apply identically to Mainnet and Testnet.
* Using an exponential decay function satisfies **Requirements 1** and **2** above.
* We round up to the next zatoshi to satisfy **Requirement 3** above.

## Parameters

The selection is intended to achieve Key Objective 6 while still being at
a constant, predictable height. An alternative would be to have a dynamic
"latch"-style activation, which would calculate the activation height by
testing the "less than" conditional with every block after the second halving.
We prefer the pre-defined constant height parameter, to give everyone more
_time_ certainty at the cost of _issuance level_ certainty.

The difference in up-front calculation versus dynamic calculation is
in whether or not funds removed from circulation are accounted for
(since funds removed from circulation in the future cannot be calculated
up-front). This means with the pre-defined constant parameter approach,
issuance will jump _up_ some amount at activation. This amount should be
equivalent to all ZEC removed from circulation prior to that height times
$\mathsf{BLOCK\_SUBSIDY\_FRACTION}$. For example, if a total of 100,000 ZEC were
burnt prior to the pre-defined constant activation height, then at activation
the issuance would be larger than BTC-style issuance by $100\_000\textsf{ ZEC}
\cdot \mathsf{BLOCK\_SUBSIDY\_FRACTION}$, which we calculate equals $0.04126$
ZEC. This example is chosen to demonstrate that a very large amount removed from
circulation (much larger than expected) would elevate issuance by a relatively
small amount. For this reason, we believe a pre-defined constant is a better
approach to achieving Key Objective 6 than a "dynamic latch" logic because it is
so much simpler to implement and reason about.

## BLOCK_SUBSIDY_FRACTION

Let $\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} = 0.5$.
Expand All @@ -189,9 +192,9 @@ This implies that after a period of 4 years around half of Money Reserve will
have been issued as block subsidies, thus satisfying **Requirement 4**.

The largest possible value in the Money Reserve is $\mathsf{MAX\_MONEY}$, in the
theoretically possible case that all issued funds are burned. If this happened,
the largest interim sum in the block subsidy calculation would be
$\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000$.
theoretically possible case that all issued funds are removed from circulation.
If this happened, the largest interim sum in the block subsidy calculation would
be $\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000$.

This uses 62.91 bits, which is just under the 63-bit limit for signed
two's complement 64-bit integer amount types.
Expand Down Expand Up @@ -225,9 +228,9 @@ well as generate plots like the ones above. Its output:
Last block is 47917869 in ~113.88 years
```

indicates that, assuming that no ZEC is ever burned, the Money Reserve will be
depleted after 113.88 years, and the block subsidy will be 0 ZEC after that
point.
indicates that, assuming that no ZEC is ever removed from circulation, the Money
Reserve will be depleted after 113.88 years, and the block subsidy will be 0 ZEC
after that point.

This fragment of the output:

Expand All @@ -251,7 +254,8 @@ approximation beyond the four year half-life constraint.
# Deployment

This ZIP is proposed to activate with Network Upgrade 7. [^zip-0254]
It MUST be deployed at the same time or after ZIP 233 ("NSM: Burning" [^zip-0233]).
It MUST be deployed at the same time or after ZIP 233 ("NSM: Removing Funds From
Circulation" [^zip-0233]).


# References
Expand Down
Loading

0 comments on commit c11530f

Please sign in to comment.