mirror of https://github.com/zcash/zips.git
195 lines
7.8 KiB
ReStructuredText
195 lines
7.8 KiB
ReStructuredText
|
::
|
|||
|
|
|||
|
ZIP: 1004
|
|||
|
Title: Miner-Directed Dev Fund
|
|||
|
Owner: Andrew Miller (@amiller on zcash forums)
|
|||
|
Status: Draft
|
|||
|
Category: Consensus
|
|||
|
Created: 2019-06-19
|
|||
|
License: public domain
|
|||
|
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864>
|
|||
|
|
|||
|
|
|||
|
Terminology
|
|||
|
===========
|
|||
|
|
|||
|
The key words "MUST", "SHOULD", and "MAY" in this document are to be
|
|||
|
interpreted as described in RFC 2119. [#RFC2119]_
|
|||
|
|
|||
|
For clarity, this ZIP defines these terms:
|
|||
|
|
|||
|
2nd Halvening Period
|
|||
|
the 4-year period of time, roughly from October 2020 - October 2024,
|
|||
|
during which at most 5,250,000 ZEC will be minted.
|
|||
|
DF%
|
|||
|
Dev Fund Percentage, the portion of newly minted ZEC in each block
|
|||
|
reserved for a development fund.
|
|||
|
MR%
|
|||
|
Miner Reward Percentage, the portion of newly minted ZEC in each block
|
|||
|
given to miners (so that DF% + MR% = 100%).
|
|||
|
|
|||
|
|
|||
|
Abstract
|
|||
|
========
|
|||
|
|
|||
|
This proposal reserves a portion (20%) of the newly minted coins in each
|
|||
|
block for the development fund. A fixed set of developer entities would be
|
|||
|
eligible to receive these funds. The fund would be miner-directed in the
|
|||
|
sense that the miner of each block can determine how to allocate these funds
|
|||
|
to eligible developers.
|
|||
|
|
|||
|
|
|||
|
Out of Scope for this proposal
|
|||
|
==============================
|
|||
|
|
|||
|
* This proposal does not (currently) specify any process for reaching
|
|||
|
agreement on or modifying the fixed set of development entities.
|
|||
|
* This proposal does not specify how miners should reach a decision on how
|
|||
|
to direct the development fund, or how developers should appeal to miners
|
|||
|
to do so. Other development fund proposals include specific processes for
|
|||
|
accountability and to support community decision making, such as monthly
|
|||
|
developer calls, lists of planned features and goals, etc. Any of these
|
|||
|
can be compatible with this proposal as well, by providing non-binding
|
|||
|
advice to miners, by reaching agreement on implementation defaults, by
|
|||
|
guiding the choice of the fixed set of developers, etc.
|
|||
|
* This proposal only provides a guideline for the 2nd Halvening Period.
|
|||
|
|
|||
|
|
|||
|
Motivation
|
|||
|
==========
|
|||
|
|
|||
|
Like most development fund proposals, this is motivated by the potential
|
|||
|
value to the Zcash community of using newly minted coins to hire developers
|
|||
|
to continue improving Zcash. [#amiller-notes]_
|
|||
|
|
|||
|
Unlike most other development fund proposals, this proposal is distinct in
|
|||
|
providing a fine-grained “opt-in” [#acityinohio-comment]_ feature, since
|
|||
|
miners have the choice to provide a small amount of development funding or
|
|||
|
none at all.
|
|||
|
|
|||
|
|
|||
|
Requirements
|
|||
|
============
|
|||
|
|
|||
|
* Simplicity: A design goal of this proposal is to be simple to define and
|
|||
|
implement, without specifying much process for on-chain or off-chain
|
|||
|
governance.
|
|||
|
* Opt-in: The proposed development fund is not mandatory, since miners can
|
|||
|
decide not to allocate any funds at all to the developer entities.
|
|||
|
* Incentive-compatible: Miners cannot directly pay the development fund to
|
|||
|
themselves.
|
|||
|
|
|||
|
|
|||
|
Specification
|
|||
|
=============
|
|||
|
|
|||
|
During the 2nd Halvening Period, a fixed portion (DF% = 20%) of the newly
|
|||
|
minted coins in each block are reserved for a Miner-Directed Dev Fund (MDDF).
|
|||
|
A hardcoded set of developer entities (e.g., Electric Coin Company, Zcash
|
|||
|
Foundation, Parity, or others), represented in the code by their t-address
|
|||
|
or z-address public keys, are eligible to receive funding from the MDDF.
|
|||
|
The fund is “miner-directed” in the sense that the miner in each block
|
|||
|
chooses how to allocate the MDDF coins among the developer entities, simply
|
|||
|
by creating outputs in the coinbase transaction. The DF% is a maximum —
|
|||
|
miners can also “opt out” by minting a lower number of coins for the MDDF,
|
|||
|
or none at all.
|
|||
|
|
|||
|
This proposal is explicitly limited in scope to the 2nd Halvening Period.
|
|||
|
After the end of this period, the entire block reward in each block is
|
|||
|
awarded to the miner. The upper bound on the rate of newly minted coins MUST
|
|||
|
remain the same as before this proposal (i.e., at most 25 ZEC minted per
|
|||
|
10 minutes during the 2nd Halvening Period).
|
|||
|
|
|||
|
Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the
|
|||
|
Electric Coin Company and DF%/2 to the Zcash Foundation).
|
|||
|
|
|||
|
Implementations SHOULD support changing the allocation (overriding any such
|
|||
|
default) through a configuration option.
|
|||
|
|
|||
|
|
|||
|
Examples
|
|||
|
--------
|
|||
|
|
|||
|
The following examples illustrate how miners can build the outputs of the
|
|||
|
coinbase transactions to allocate the MDDF to eligible developers. Assume
|
|||
|
``Dev1``, ``Dev2`` are the hardcoded addresses of eligible developers, and
|
|||
|
``Miner`` is the address of the mining pool mining this block. Assume that
|
|||
|
the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening
|
|||
|
Period (this takes into account the change to a 75-second block target
|
|||
|
spacing after the Blossom Network Upgrade [#zip-0208]_), and that DF% = 20%,
|
|||
|
MR% = 80%.
|
|||
|
|
|||
|
**Example 1: Split equally between two developers**
|
|||
|
|
|||
|
The transaction outputs of the coinbase transaction are as follows:
|
|||
|
|
|||
|
* 2.5 ZEC to ``Miner``
|
|||
|
* 0.3125 ZEC to ``Dev1``
|
|||
|
* 0.3125 ZEC to ``Dev2``.
|
|||
|
|
|||
|
**Example 2: Opt-out of the development fund**
|
|||
|
|
|||
|
The transaction outputs of the coinbase transaction are as follows:
|
|||
|
|
|||
|
* 2.5 ZEC to ``Miner``.
|
|||
|
|
|||
|
|
|||
|
Issues and Further Discussion
|
|||
|
=============================
|
|||
|
|
|||
|
Raised objections and issues so far:
|
|||
|
|
|||
|
* Miners may have adverse incentives, such as:
|
|||
|
|
|||
|
- Stonewalling any development of Proof-of-Work alternatives, such as
|
|||
|
GPU-friendly variants or Proof-of-Stake.
|
|||
|
- Extortion for more funds. To illustrate: "We’ll direct all 20% of the
|
|||
|
development fund to DeveloperX, but only if they promise to keep just
|
|||
|
5% and pass 15% back to the mining pool.”
|
|||
|
- Blocking the development fund out of greed.
|
|||
|
|
|||
|
* This proposal modifies the terms of what some may consider a social
|
|||
|
contract: given the original code in Zcash implementations, by the end
|
|||
|
of the issuance schedule when all 21 million ZEC have been minted, a
|
|||
|
total of 90% of all minted coins would have originally been awarded to
|
|||
|
miners. Under this proposal, less reward would be available to miners,
|
|||
|
than would be available to them according to the original minting schedule.
|
|||
|
|
|||
|
* Several others, notably the Blocktown Capital proposal [#blocktown-summary]_,
|
|||
|
have suggested that a 20% development fund would set a precedent for a
|
|||
|
perpetual 20% development fund. This proposal is explicitly limited in
|
|||
|
scope to the 2nd Halvening Period. Thus adopting this proposal on its
|
|||
|
own, if there are no further updates, would result in the the development
|
|||
|
fund ending in 2024.
|
|||
|
|
|||
|
|
|||
|
References
|
|||
|
==========
|
|||
|
|
|||
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
|||
|
.. [#amiller-notes] `Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019. <https://medium.com/@socrates1024/here-are-a-couple-of-points-on-framing-the-discussion-of-a-potential-new-dev-fund-in-zcash-c13bcbf4ed5b>`_
|
|||
|
.. [#acityinohio-comment] `Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019. <https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/267>`_
|
|||
|
.. [#blocktown-summary] `Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. <https://medium.com/blocktown/executive-summary-blocktown-proposal-for-zcash-2020-network-upgrade-84ff20997502>`_
|
|||
|
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
|||
|
|
|||
|
.. raw:: html
|
|||
|
|
|||
|
<br>
|
|||
|
|
|||
|
Change Log
|
|||
|
==========
|
|||
|
|
|||
|
* 2019-06-19 Initial post
|
|||
|
* 2019-08-28
|
|||
|
|
|||
|
- Update to be more like a ZIP draft
|
|||
|
- Renamed to Miner-Directed Dev Fund
|
|||
|
- Removed references to “Burn”, instead opt-out is in terms of coins never being minted in the first place
|
|||
|
|
|||
|
* 2019-08-29
|
|||
|
|
|||
|
- Address informal pre-ZIP feedback
|
|||
|
- Add example, requirements, fix incomplete sentence about default allocations
|
|||
|
|
|||
|
* 2019-09-15 Move to GitHub
|