mirror of https://github.com/zcash/zips.git
370 lines
10 KiB
ReStructuredText
370 lines
10 KiB
ReStructuredText
::
|
|
|
|
ZIP: 214
|
|
Title: Consensus rules for a Zcash Development Fund
|
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
|
Status: Proposed
|
|
Category: Consensus
|
|
Created: 2020-02-28
|
|
License: MIT
|
|
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>
|
|
|
|
|
|
Terminology
|
|
===========
|
|
|
|
The key words "MUST", "SHALL", and "SHOULD" in this document are to be
|
|
interpreted as described in RFC 2119. [#RFC2119]_
|
|
|
|
The term "Zcash" in this document is to be interpreted as described in the
|
|
Zcash Trademark Donation and License Agreement ([#trademark]_ or successor
|
|
agreement).
|
|
|
|
The term "network upgrade" in this document is to be interpreted as
|
|
described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
|
|
Agreement ([#trademark]_ or successor agreement).
|
|
|
|
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.
|
|
[#protocol]_
|
|
|
|
The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"),
|
|
"Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to
|
|
be interpreted as described in ZIP 1014 [#zip-1014]_.
|
|
|
|
The terms below are to be interpreted as follows:
|
|
|
|
Canopy
|
|
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
|
Testnet
|
|
The Zcash test network, as defined in [#protocol]_.
|
|
Mainnet
|
|
The Zcash production network, as defined in [#protocol]_.
|
|
|
|
|
|
Abstract
|
|
========
|
|
|
|
This ZIP describes consensus rule changes interpreting the proposed structure of
|
|
the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last
|
|
for 4 years.
|
|
|
|
|
|
Applicability
|
|
=============
|
|
|
|
This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be
|
|
applicable to other block chains using Zcash technology.
|
|
|
|
|
|
Motivation
|
|
==========
|
|
|
|
Motivation for the Zcash Development Fund itself is considered in ZIP 1014
|
|
[#zip-1014]_, which gives a high-level description of the intended structure of
|
|
the fund.
|
|
|
|
An important motivation for describing the consensus rules in a separate ZIP is
|
|
to avoid making unintended changes to ZIP 1014, which has already been agreed
|
|
between ECC, ZF, and the Zcash community. This facilitates critically assessing
|
|
whether the consensus rule changes accurately reflect the intent of ZIP 1014.
|
|
|
|
|
|
Requirements
|
|
============
|
|
|
|
The primary requirement of this ZIP is to make changes to consensus rules necessary
|
|
and sufficient to implement the intent of ZIP 1014.
|
|
|
|
The Zcash Development Fund distributes funding in ZEC obtained from block subsidies
|
|
on Mainnet. This ZIP should also specify corresponding rules, addresses, and
|
|
activation height for Testnet, in order to allow testing and auditing of the design
|
|
and implementation within sufficient lead time before activation on Mainnet.
|
|
|
|
|
|
Non-requirements
|
|
================
|
|
|
|
This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what
|
|
is implementable by Zcash consensus rules.
|
|
|
|
|
|
Specification
|
|
=============
|
|
|
|
The Blossom network upgrade changed the height of the first halving to block height
|
|
1046400 [#zip-0208]_, as a consequence of reducing the block target spacing from
|
|
150 seconds to 75 seconds.
|
|
|
|
Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving,
|
|
the activation height of Canopy on Mainnet therefore SHALL be 1046400.
|
|
|
|
ZIP 207 [#zip-0207]_ SHALL be activated in Canopy.
|
|
|
|
The following funding streams are defined for Mainnet:
|
|
|
|
========== =========== ============= ============== ============
|
|
Stream Numerator Denominator Start height End height
|
|
========== =========== ============= ============== ============
|
|
``FS_ECC`` 7 100 1046400 2726400
|
|
``FS_ZF`` 5 100 1046400 2726400
|
|
``FS_MG`` 8 100 1046400 2726400
|
|
========== =========== ============= ============== ============
|
|
|
|
As specified in [#zip-0207]_, 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 are defined for Testnet are identical except that the
|
|
start height of each stream is the activation height of Canopy on Testnet, i.e.
|
|
xxxxxxx.
|
|
|
|
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).
|
|
|
|
|
|
Dev Fund Recipient Addresses
|
|
----------------------------
|
|
|
|
For each of Testnet and Mainnet, before deploying this ZIP in a node implementation
|
|
with the activation height set for that network, each of the parties (ECC and ZF)
|
|
SHALL generate sequences of recipient addresses to be used for each stream in each
|
|
funding period:
|
|
|
|
* ECC SHALL generate the addresses for the ``FS_ECC`` funding stream, which on
|
|
Mainnet corresponds to the **ECC slice**;
|
|
* ZF SHALL generate the addresses for the ``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 [#zip-1014]_.
|
|
|
|
No requirements are imposed on the use of funds sent to Testnet funding streams.
|
|
|
|
|
|
Direct-grant option
|
|
'''''''''''''''''''
|
|
|
|
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. [#zip-1014]_
|
|
|
|
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 amount of funding streams assigned to direct grantees MUST be subtracted
|
|
from 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 would be published specifying those modifications.
|
|
|
|
|
|
Mainnet Recipient Addresses
|
|
---------------------------
|
|
|
|
FS_ECC_Addresses[0..47] = [
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO" ]
|
|
|
|
FS_ZF_Addresses[0..47] = [
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO" ]
|
|
|
|
FS_MG_Addresses[0..47] = [
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO",
|
|
"TODO" ]
|
|
|
|
Testnet Recipient Addresses
|
|
---------------------------
|
|
|
|
TODO
|
|
|
|
|
|
Rationale
|
|
=========
|
|
|
|
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. [#zip-1014]_
|
|
|
|
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.
|
|
|
|
|
|
Deployment
|
|
==========
|
|
|
|
This proposal is intended to be deployed with Canopy. [#zip-0251]_
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
|
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later <protocol/protocol.pdf>`_
|
|
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
|
|
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
|
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_
|
|
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
|
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
|
|
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|