The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 5
-The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8
+The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 4 7
+The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 10
The terms below are to be interpreted as follows:
This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.
-This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 12. It should be read in conjunction with ZIP 1014 14, which describes the high-level requirements for that fund.
+This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 14. It should be read in conjunction with ZIP 1014 16, which describes the high-level requirements for that fund.
Motivation for the Zcash Development Fund is considered in ZIP 1014 14.
+Motivation for the Zcash Development Fund is considered in ZIP 1014 16.
This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.
The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 12 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 14, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.
+The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 14 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 16, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.
As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.
We use the following constants and functions defined in 4, 5, and 6:
+We use the following constants and functions defined in 5, 6, 7, and 8:
A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).
-By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. 9
+By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. 11
The value of a funding stream at a given block height is defined as:
On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.
Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6
+Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 8
Once the Canopy network upgrade activates:
OP_HASH160 RedeemScriptHash(height) OP_EQUAL
as the scriptPubKey
.For the funding stream definitions to be activated at Canopy, see ZIP 214. 12 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7
+For the funding stream definitions to be activated at Canopy, see ZIP 214. 14 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 9
struct FundingPeriod { @@ -371,7 +371,7 @@ License: MIT
This proposal is intended to be deployed with Canopy. 13
+This proposal is intended to be deployed with Canopy. 15
This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.
@@ -392,46 +392,62 @@ License: MIT3 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet |
---|
4 | -Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.1 or later | +5 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.3: Constants | +
---|
6 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.6.3: Difficulty adjustment |
---|
7 | +9 | ZIP 0: ZIP Process |
---|
8 | +10 | ZIP 200: Network Upgrade Mechanism |
---|
9 | +11 | ZIP 208: Shorter Block Target Spacing |
---|
10 | +12 | ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext |
---|
11 | +13 | ZIP 213: Shielded Coinbase |
---|
12 | +14 | ZIP 214: Consensus rules for a Zcash Development Fund |
---|
13 | +15 | ZIP 251: Deployment of the Canopy Network Upgrade |
---|
14 | +16 | ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants |
---|
As specified in 8, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.
+As specified in 9, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.
The funding streams defined for Testnet are identical except that the start height of each stream is the activation height of Canopy on Testnet, i.e. TODO.
Note: on Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).
FS_ZF
and FS_MG
funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.
-Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 11.
+Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 12.
No requirements are imposed on the use of funds sent to Testnet funding streams.
ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 11
+ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 12
The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total value of funding streams assigned to direct grantees MUST be subtracted from the value of the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).
For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP SHOULD be published specifying those modifications.
The rationale for ZF generating the addresses for the ZF_MG
funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 11
The rationale for ZF generating the addresses for the ZF_MG
funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 12
Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.
Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks at the time of writing, which is the equivalent of ~67 days at the post-Blossom block target spacing), the activation height and the start heights of the funding streams could have also been set to 1046400 on Testnet. However, 67 days is arguably too short a testing period, and the block rate on Testnet is less predictable than on Mainnet.
It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.
This proposal is intended to be deployed with Canopy. 10
+This proposal is intended to be deployed with Canopy. 11
2 | -Zcash Protocol Specification, Version 2020.1.1 or later | +Zcash Protocol Specification, Version 2020.1.9 or later [Canopy] |
---|
3 | -Zcash Protocol Specification, Version 2020.1.4. Section 3.9: Block Subsidy and Founders' Reward | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet |
---|
5 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.7: Calculation of Block Subsidy and Founders' Reward |
---|
5 | +6 | Zcash Trademark Donation and License Agreement |
---|
6 | +7 | The Open Source Definition |
---|
7 | +8 | ZIP 200: Network Upgrade Mechanism |
---|
8 | +9 | ZIP 207: Funding Streams |
---|
9 | +10 | ZIP 208: Shorter Block Target Spacing |
---|
10 | +11 | ZIP 251: Deployment of the Canopy Network Upgrade |
---|
11 | +12 | ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants |
---|
3 | -Zcash Protocol Specification, Version 2020.1.5 or later [Overwinter+Sapling+Blossom+Heartwood] | +Zcash Protocol Specification, Version 2020.1.1 | +
---|
4 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet | +
---|
5 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 5.4.5: Ed25519 | +
---|
6 | +ZIP 251: Deployment of the Canopy Network Upgrade |
---|
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 3
-The terms below are to be interpreted as follows:
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 5
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 3.
+"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
This proposal defines the deployment of the Canopy network upgrade.
@@ -33,17 +26,17 @@ License: MITThe primary sources of information about Canopy consensus protocol changes are:
The network handshake and peer management mechanisms defined in ZIP 201 4 also apply to this upgrade.
-The following network upgrade constants 3 are defined for the Canopy upgrade:
+The network handshake and peer management mechanisms defined in ZIP 201 6 also apply to this upgrade.
+The following network upgrade constants 5 are defined for the Canopy upgrade:
0xE9FF75A6
The implementation is similar to that for Overwinter which was described in 4.
+The implementation is similar to that for Overwinter which was described in 6.
Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:
Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.
-Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1; and use the same transaction digest algorithm as defined in 10. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. 10
+Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 4; and use the same transaction digest algorithm as defined in 12. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. 12
Support for Canopy on testnet will be implemented in zcashd
version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in zcashd
version 4.0.0, which will advertise protocol version 170013.
3 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 3.11: Mainnet and Testnet | +
---|
4 | +Zcash Protocol Specification, Version 2020.1.9 [Canopy]. Section 7.1: Encoding of Transactions |
---|
3 | +5 | ZIP 200: Network Upgrade Activation Mechanism |
---|
4 | +6 | ZIP 201: Network Peer Management for Overwinter |
---|
5 | +7 | ZIP 207: Funding Streams |
---|
6 | +8 | ZIP 211: Disabling Addition of New Value to the Sprout Value Pool |
---|
7 | +9 | ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext |
---|
8 | +10 | ZIP 214: Consensus rules for a Zcash Development Fund |
---|
9 | +11 | ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules |
---|
10 | +12 | ZIP 243: Transaction Signature Validation for Sapling |
---|
11 | +13 | ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants |
---|