[Dead] Dev fund proposal: Full Node/Transactions Directed Dev Fund (was: opt-out mechanism for sharing block rewards by miners for dev fund)

Community Collaborations protocol
1

1 - Header

ZIP: unassigned.
Title: Full Node/Transactions Directed Dev Fund
Advocate: dontbeevil (dontbeevil on zcash forums)
ZIP Status: Draft
Community Status: Request for comments : @ Dev fund proposal: Full Node/Transactions Directed Dev Fund (was: opt-out mechanism for sharing block rewards by miners for dev fund)
Category: Process
Created: 2019-08-28
License: public domain
Credits to Andrew Miller(@amiller), this proposal is a fork of his dev fund proposal [7]

2 - Terminology

To understand this ZIP it is critical that people understand the right terminology so their requirements can be quickly checked.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”

Have special meaning and people should get familiar with it. - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

For clarity in this zip I define these terms:

  • 2nd Halving 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 dev fund
    MR% - Miner Reward Percentage, the portion of newly minted ZEC in each block given to miners
    (so that DF% + MR% = 100%).

3 - Out of Scope for this proposal

  • This proposal only provides a guideline for the 2nd halving period.

4 - Abstract

During the 2nd halving period, a variable portion (DF% <= 20%) of the newly minted coins in each block are reserved for a Full Node/Transactions Directed Dev Fund (NTDDF). Currently, ECC and Zcash Foundation have shown interest to receive funding from NTDDF.

DF% will be split between ECC and Zcash Foundation in a fixed 3:1 ratio respectively. The fund is “Full Node/Transaction directed” in the sense that the full nodes and/or transactions in each block chooses DF% (0 - 20).

5 - Motivation

Zcash is still in early stages of development, its goal to empower and provide best privacy-preserving digital currency is not fulfilled yet. Hence, the proposal for dev fund to enforce active/non-voluntary development for Zcash.

This dev fund is user activated unlike other proposals [7]. This is simpler than community-involved governance which adds more complexity and unnecessary process to keep a check on Zcash Foundation and ECC [8].

What does 3:1 dev fund split mean:
The maximum amount that the Zcash Foundation would receive under this proposal is 5% of block rewards, and the maximum amount that ECC would receive is 15% of block rewards. 3:1 ratio is based on following factors:

  • ECC, Zcash Foundation estimated yearly spend [1][2][3] from 2020/2021.
  • Size of efforts/goals to help Zcash.

6 - Requirements:

7 - Specification

Accountability for dev fund receiving entities: Zcash Foundation and ECC
(Extracted from Zcash Foundation’s accountability requirements [1])

  • Monthly public developer calls, detailing current technical roadmap and updates
  • Quarterly tech roadmap reports and updates
  • Quarterly financial reports, detailing spending levels/burn rate and cash/ZEC on hand
  • A yearly, audited financial report akin to the Form 990 for US-based nonprofits
  • Yearly reviews of organization performance, along the lines of our “State of the Zcash Foundation” report

Core Features that one of dev fund receiving entities: Zcash Foundation/ECC needs to make available for Zcash users.

  • Work towards 100% t2z + z2z transactions => ~0% deshielding and transparent transactions.
  • Deploy Multi-sig for z-address.
  • Support z-address for at-least one hardware wallet (ex: Ledger, Trezor).
  • Tech support for Layer-2 scalability BOLT and help private channels become a reality [5].
  • Research and Deploy Bonsai (aka Succinct Blockchain) on Mainnet [6].

Social contract
ECC and Zcash Foundation need to help each other with development, regulatory, business efforts and also with funds when they run out during second halving period (when necessary).

(optional) ECC to explore turning it into non-profit or setting up new non-profit (if necessary)

Implementation Details

  • Enable full nodes signaling via software flag
    AND/OR
  • Enable wallet-based signaling via shielding/private transactions with the help of new transparent Memo field.
  • This proposal is explicitly limited in scope to the 2nd halving period which means NTDDF would end in 2024.
  • DF% will be split between ECC and Zcash Foundation in a fixed 3:1 ratio respectively.
  • Setting maximum that DF% can be as 20% of block rewards.

Issues & Further Discussion

Raised objections and issues so far:

  • This proposal is modifying original social contract: total of 90% of all minted coins would have originally been awarded to miners. Under this proposal, less reward could be available to miners, than would be according to the original minting schedule as implemented in Zcashd prior to NU5.

Additional Information and References

[1] Zcash Foundation Guidance on Dev Fund Proposals - zcash foundation
[2] The State of the Zcash Foundation in 2019 - zcash foundation (Read finances)
[3] Electric Coin Company Statement on Sustainability - Electric Coin Company
[4] How to hire ECC - #43 by dontbeevil
[5] BOLT Support feature requirements · Issue #2353 · zcash/zcash · GitHub
[6] Bonsai: private payments on a succinct (or partially succinct) blockchain · Issue #3818 · zcash/zcash · GitHub
[7] [ZIP 1004] Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or "burn")
[8] Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance

Selected snippets from Zcash foundation and ECC blog posts linked above:

ZFND: Here are the acceptable options, in order of the Foundation’s preference:

  1. Transition from the current Founder’s Reward to a compulsory Zcash dev fund. For-profit entities would not be eligible recipients of the dev fund. Funds would be disbursed equally across recipient nonprofits, all required to adhere to transparency and accountability requirements.
  2. Transition from the Founder’s Reward to an opt-in Zcash dev fund, where miners choose to distribute the funds to recipient organizations, or burn the funds forever.
  3. Allow the Founder’s Reward to sunset at its current expiry period, without extension or creation of any new model.

ZFND: At a price of $50 USD per ZEC, we have roughly $16 million in assets, which translates to a five-year runway if we meet the 2019 expected budget. Obviously swings in ZEC price could materially change this calculation.

ZFND: We expect to spend roughly $3.7mm a year, with the largest cost being $2mm for wages. With our current spending for 2019, and our assets as they are today, the Zcash Foundation could operate at this level until 2023.

ZFND: If a dev fund granted 10% of the next block reward period to the Foundation, we’d receive 625,000 ZEC over four years, or 156,250 ZEC per year. At $50 per ZEC, that would be equivalent to $7.8mm per year (the price of ZEC is volatile, but we think $50 is a reasonable baseline).

ZFND: If our budget was $6.7mm a year, we would likely spend more resources on events beyond Zcon, engage in broader education work, hoping to build a long-tail of protocol contributors outside the Electric Coin Company/Foundation, and do even more advocacy work for Zcash and privacy in general (where not limited by our nonprofit status).

ECC: Based on our current reserves and 8% allocation, the company has approximately 24 months of runway, or about 8 months beyond the end of funding

ECC: As we’re “All in on ZEC,” the company is not pursuing other funding mechanisms at this time. If the company’s reserves — including USD, ZEC and anticipated receipt of ZEC — dip below what is needed to sustain the company for 12 months at a $1.1M per month run rate

Zcash Foundation Financial Summary:
By the time of next upgrade (Oct 2020), Zcash Foundation would have approximately $9M after it spends $3.7M this year and 3.4M next year until Oct. It can still support Zcash until 2023 March (assuming ZEC price is 50) without devfund. If Zcash Foundation wants to use $9M for future operations beyond 2024, then it would need at least $3.7M * 4 years ~ $15M for dev fund. That is equivalent to ~ 5% of block rewards (300k ZEC).

ECC Financial Summary:
By the time of next upgrade (Oct 2020), ECC would have approximately $9M ($1.1M * 8 months of runway left). For ECC to accept community’s bid - it would need $44M ($1.1M * 40 months) to operate for next 4 years. That is equivalent to 880,000 ZEC over 4 years at $50 ZEC which translates to 14% of block rewards (6.25M).

GRAVEYARD AKA ORIGINAL DEV FUND PROPOSAL: opt-out mechanism for sharing block rewards by miners for dev fund
You may find this proposal interesting: [ZIP 1004] Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or "burn")

(Obvious) Problem: Block reward distribution to ECC, Zcash Foundation and others ends sometime in 2020.

Solution: Instead of simply extending the current mechanism of block reward distribution (only 80% going to miners)- this time enabling miners to (partial or full) opt-out of sharing their block rewards for dev fund. So, protocol can be changed to allow miners to signal sharing of their block rewards from MIN to MAX percentage.

MIN could be as low as 0%
MAX could be as high as 20%

Edit #1: Why introduce MIN and MAX: As price of zcash fluctuates, it helps miners adjust amount of block rewards towards dev fund for continued development and improvement of zcash protocol.
Example:
If zcash price goes down 2x (during bear cycle), then miners have the power to increase block reward share to MAX, for continued development.
Similarly, if price of zcash goes up 2x (bull market), they can reduce the reward percentage without affecting USD value.

Both MAX and MIN can be configured to decrease every 4 years at block reward halving event.
Reasoning: In the long run, Zcash protocol development becomes more decentralized and will not just rely on contributions from Zcash Foundation and ECC.
Assumption: Avg. value of Zcash protocol increases with continued development, in the long run.

6 Likes
2

Hi, thanks for making the effort to follow my requests in Proposal authors, please read: Help making ZIPs. I’ll check back to you in the next week or so to help you with any formatting or editorial needs.

Thanks for your contribution!

2 Likes
3

I’m going to be updating this proposal based on Zcash Foundation’s stance. Look for an update.

2 Likes
4

Thank you, interested to see what you change!

6

One possible mechanism here would be to do something similar to how Ethereum does miner steering of parameters like gas limit. Basically there is a “current average” X, which is an average of the value chosen in the last 1024 blocks. And in each block, the miner chooses the value Y which is within 0.999X and 1.001X, something like that. The result is that a) miners can make a choice within some range for each block, and b) the range itself can drift over time according to those choices.
A decent description is here: Accounts, Transactions, Gas, and Block Gas Limits in Ethereum

1 Like
7

20% at the current exchange rate will not be enough for the salary of the fund and ECC after halving in 2020.

10

7100 a day now, there will be 3550, right?
20 * 3550/100 = 710 per day at 20% tax.
710 * 61 * 30 = $ 1,300,000 per month.
The fund is about 800 thousand and ECC is now 1,100,000 until the state is replenished, so you can round up to 2 million per month, you will need to spend only on salaries, without additional activities, right? And this at the current rate of about 33 percent.
Where am I mistaken?

11

I think you missed something, the part that it is stated that the funds should be 50% to ECC and 50% to Foundation. It’s not an add up.

Means if the dev fund results in $1,000,000, the ECC gets 500,000 and the Foundation gets 500,000.

Talking only about the Foundations Dev Fund guidance here and at least that is my understanding for “equal distribution”.

14

I said something else, I say that 20% may not be enough to continue, the fund does not need a price for a coin as they say, therefore there is no market effort, and they try to achieve adoption and adoption through high-quality technology, and users themselves must to do everything in order to join this system, China is apparently able to develop a client themselves who wants to use zcash.

3 Likes
15

Miners on their own, investors on their own and the community are also left to their own devices, the miners will leave further due to low liquidity and volumes, investors have already left, the community has split up, the fund is sharing money, the strategy is for development.

2 Likes
16

This is only required for mandatory dev fund proposal, not for opt-in based proposal.

17

Everyone needs to read this before they finalize their dev fund proposal:
https://docs.google.com/document/d/1eHpO_L7yncGy_K4BslzTzDG1uAE7PSzz2eeM6dqhHEI/edit?usp=sharing

2 Likes
18

I was under the assumption that Aug 31st is deadline for submitting draft ZIP. Just read:

@nathan-at-least @zooko @joshs looking forward to hear your answers to my questions in “How to hire ECC” thread.

I’m taking time to come up with a proposal based on new information being surfaced everyday.

1 Like
19

I responded in the thread. I hope it helps.

2 Likes
20

I have updated my proposal. Please take a look, Zcash community!

21

@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.

Add a credit to Andrew Miller (as it appears this proposal incorporates writing by him).

This content should be in the Specification. The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

This is unclear as to what the intended consensus rules are. In particular, this could be interpreted as the miner having full control of DF%, as they are given control of the number of coins minted for the NTDDF, which is effectively DF%. It could also be interpreted as the miner’s and transactions’ signals being added together, effectively giving each “entity” partial control over the full DF%. The intent needs to be clarified for the ZIP draft; the full algorithm is not necessary now, but would need to be specified for the final ZIP.

If the intent is that transaction creators should have control over DF% (or some fraction of it), then this is also gameable, because miners could create a block containing some fraction of legitimate transactions (to collect fees) and fill enough of the rest of the block with fake transactions to bias the result to their desired DF% rather than what would result from the legitimate transactions. This is indistinguishable in the consensus rules from a block containing only legitimate transactions.

Replace this with “The maximum amount that the Zcash Foundation would receive under this proposal is 5% of block rewards, and the maximum amount that ECC would receive is 15% of block rewards.”

The content in this section should be part of the Specification. Quoting the ZIP guide:

Requirements

Describe design constraints on, or goals for the solution – typically one paragraph for each constraint or goal. Again, don’t actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.

There is significant difference in analysis and implementation work required between these two options. For example, there is more complexity in a transaction format change, and it requires more work from the ecosystem. (If there were other NU4 proposals that required a transaction format change, then this could be paired with them - but that analysis comes later.) If the ZIP is proposing a particular signaling mechanism, it should be clear whether it intends for only one of these (and if so, which), or both.

Additionally:

  • “Signalling via full node software flags” is under-specified; it does not indicate how the consensus rules could enforce this.
    • Are full nodes somehow influencing the miners’ blocks? This seems hard to achieve, and the strategy would need to be specified as part of the draft.
    • Are full nodes rejecting blocks that don’t satisfy their required DF% bounds?
      • If the flag specifies a minimum DF%, then miners will trend towards all blocks having max-DF%, otherwise they risk losing blocks entirely.
      • Similarly, if the flag instead specifies a maximum DF%, then miners will trend towards all blocks having zero-DF%.
      • If the full nodes specify a range, then you have both issues at once; the miners would have to guess the most likely range, and this would increase the orphan rate and the chance of chain forks.
  • Signalling via a transaction is gameable per above.

This reads like a specification. It should either be reformatted as an open issue, or moved into the Specification.

2 Likes
22

Consensus rules could make full nodes reject blocks where miner doesn’t set DF% based on signals in the transactions. You’re right, Miners could gamify this with fake transactions if the transaction fees are low and also not mine legitimate transactions if they can get around algorithm to select DF%. This could make network unusable and mining non-economical because of increased ZEC volatility.

Fair point. I’ve not mentioned the algorithm that I was thinking to mitigate this. Will update the proposal once I get it right.

Can you expand more on why that is hard to achieve. This could help me understand the complexity and also how consensus rules can be forced.
One option could be full nodes validate the blocks based on signal-ing provided by transactions => Reject the block if the median of DF% < actual DF% set by winning miner in the block.

1 Like
23

Meta question:

@sonya @joshs does this proposal if accepted by community make Zcash a security?

1 Like
24

Disclaimer: I am not a lawyer.

There were concerns about the regulatory implications of a dev fund with no opt out being granted to a for-profit company. I can’t elaborate on the details of those concerns, since I don’t have the necessary expertise.

Don’t worry about that for now :slight_smile: As I’ve told others, we’re consult our lawyers as needed before the feature selection deadline.

1 Like
25

No one can say with certainty about any of these proposals. Even if the community believes something is not, the SEC could chose to pursue it, which could be very expensive and cause damage regardless.

I don’t believe Sonya is correct based upon our consultations. Nonprofit and for-profit have no bearing. Direct funding (regardless of who receives it), if I understand your proposal correctly, would likely result in this type of model being presented to SEC.gov | Strategic Hub for Innovation and Financial Technology (FinHub) for feedback.

2 Likes