Dev Fund Proposal: Dev Focused , let the Nodes Decide

Community Collaborations protocol
1

Up until this point I have not been taking a side on the Founders Reward debate, acting as a Mod I try to remain neutral in most conversations while spurring debate with threads like this one. However with a topic as important as this I realize that expressing no opinion is basically the same as a vote to let the code remain as-is: letting the founders reward expire.

[:exclamation: UPDATE: I have decided not to submit this as a full ZIP proposal due to the likely hood it could be gamed based on feedback I received below]

obligatory disclaimer: my opinions are my own and don’t reflect those of ECC or the Zcash Foundation

—How did we get here?

As you may have heard me saying before, the Zcash launch was not an easy one with no such thing as ICOs and a total of $3M had to be raised to effectively get Zcash Company started. Back then nobody had ever heard of zkSNARKs and didn’t know if Zcash would be successful. According to stories I have heard from Matthew Green and Eran Tromer, they got rejected by many potential VC investors and had to pledge a good portion of the rewards/company (16.4%) just to raise the $3M.

—So in the almost 3 years since Zcash launched what has the Founders Reward been used for?

  • From barely working proof-of-concept academic Zerocash code to production ready Zcash code (if you’re not sure of the difference listen to Sean Bowe explain)
  • Establishment of the Zcash Foundation
  • Listing on just about every major exchange, including the most strict ones like Coinbase, Gemini and even OTC NYSE markets through Grayscale and Galaxy Digital trusts.
  • Acceptance by the strictest state crypto regulator in the US
  • Tons of Code improvements including squashing inflation bugs and denial of service
  • Hiring top level developer/engineer talent for the ECC team
  • Hiring top level developer/engineer for the Foundation team
  • Ongoing work with regulators about the need for acceptance of privacy preserving technology like Zcash
  • Sapling , the huge performance improvement Zcash badly needed
  • Giving away over $380,000 in Grants by the Foundation (more coming this year)
  • Building a community funding platform for Zcash Projects
  • ZecWallet and Zepio wallets built with Foundation financial support
  • New Zcash Node software ZEBRA from the Foundation independent of ECCs Zcashd
  • Eli Ben-Sasson started Starkware , STARK research which can benefit Zcash
  • Zooko supported Bolt Labs which is building a Lightning Network on Zcash
  • The mobile reference wallet code was released, and ongoing work with wallet providers which will hopefully lead to many mobile wallets available soon.

Before you skip to the next heading, I want you to stop for a second and re-read the list above . That is a huge amount of work that has been done by a Company and Foundation which didn’t even exist 3 years ago

—Why isn’t Zcash done yet, they have had lots of money and time?

The old saying goes “Good software takes 10 years” and Blockchain software is no exception.

Overall the ECC has been very methodical about how it rolls out software, marketing, and hype. This has led some users to say that ECC doesn’t put enough effort into marketing. In the cryptocurrency space where its common to see “announcements that there is going to be a big announcement!” and Twitter “Giving away a TESLA” memes the ECCs approach can seem drastically different. This is not only because the Founders of Zcash were comprised of academics and OG cypherpunks (as opposed to marketing pros) but because they have been around long enough to have learned important lessons from other projects like eCash and core software lessons like: Get Big Fast syndrome, Overhype syndrome, Too frequent upgrades, etc… . The ECC spends lots of time “getting it right” rather than pushing out often. It’s important not to forget: “ Yes, software takes 10 years to write, and no, there is no possible way a business can survive if you don’t ship anything for 10 years. ” good software still takes 10 years get used to it

—So what’s this about the Founders Reward ending?

The Zcash Founders Reward will end in 2020 if nothing changes. As it sits right now I don’t think the software is in a finished enough state to pull all funding from the projects core teams: the ECC and the Foundation, but that doesn’t mean I think the “Founders Reward” should continue.

In a perfect Bitcoin-esqe world we could simply let direct funding for development lapse and the community would step in to make up the difference, but with Zcash I don’t think that suddenly asking the community to abruptly start pledging huge amounts of ZEC every-month for developers is realistic. The core tech is complex, and the stake of users privacy too high to just hope that everything will be OK. Having core team members in the ECC and Zcash Foundation allows us to fix bugs, adopt, and adapt faster to keep up with the competing protocols.

—How much is needed?

The ECC has released a transparency report that outlines what a “sustainable” burn rate is in USD for both the ECC and Foundation. This chart is a result of what was negotiated between the Founders, Foundation, and ECC behind closed doors, so we don’t have a super detailed breakdown of exactly who gets what but we do have enough to do the math on what could be sustainable going forward.

In that report we have:

ECC_Transparency

If the community decides that a continuing “development focused” fund is worth having then the two most obvious line items Founders, and Additional should be removed which leaves us with:

  • Zcash Foundation $288,750 per month
  • ECC $754,688 per month

Thereby giving us a rough estimate of what the ECC and Foundation need to maintain their current development capacity is approx $1M per month. I purposely left off the “Miners” line item because it’s not important to figure out funding needs. It seems that this $1M a good rough number to plan on for the future for ECC and probably the Foundation because when asked in the ECC 2019 Q2 livestream if these numbers would be good going forward the ECC CEO and CFO concurred . I’m just assuming the same amount for the Foundation would be adequate.

—9% over 7 years

That brings us to my proposal of a development fund of 9% of block rewards capped at 7 years. The 7 year limit is based roughly the statements that I made above about good software requiring 10 years to accomplish. Setting the end date in 2027 will give about 11 years total since Zcash launched and if it’s not “good” by then then it likely won’t ever be. This also forces a cost efficient (50% less funding) re-structuring after year 8 because of the next halving will occur in 2024.

—Monetary Supply

So lets run the numbers as to what 9% over 7 years would mean for the Zcash total monetary supply. As we know the original plan was 10% of the total supply of Zcash would allocated for the founders reward, which is 2.1M coins. If were to allocate 9% of the new halved block rewards (25 ZEC ~ 10mins = 2.25ZEC ~ 10mins) for the next four years we get 9,720 ZEC per month = 466,560 4yrs. Then the last 3 years (12.5 ZEC ~ 10mins = 1.125 ZEC ~ 10 mins) 4,860 ZEC per month = 174,960 3years. Giving us:

  • Founder Reward of 10% of total supply = 2.1M ZEC
  • Development only plan of 9% over 7 years = 641,650 ZEC
  • Total ZEC allocated 13.05%
  • Total monetary supply unchanged

—Funds available for Development

If we factor todays rates (which are hard to calculate because we are in the middle of a bull run) at about $100 ZEC then:

Approx. USD value at today’s rates $972K/mo after 2020 ~ $486K/mo after 2024

Which you can already see is pretty close to the $1M per month which should be enough to keep the ECC/Foundation going. I personally feel that allocating an additional 3% of the total monetary supply of ZEC to support development for the next 7 years is reasonable and may even be supported by those on the fence if they want the FR to end.

—All Development Fund addresses are hard coded 50% ECC / 50% Foundation

I know that the current balance of funding requirements is not near the 50/50 mark for the ECC and the Foundation and I’m not sure it ever will be. But I do know that they ECC and Foundation were able to reach an agreement on adjusting the balance of funds before and I don’t think it would be an insurmountable task for the ECC and Foundation to coordinate in the future to be sure the funds are distributed as needed. If all else fails and some sort of agreement can’t be made then the default 50/50 will remain in place.

—Consensus

So the next question that has been discussed in other proposals is how to gauge Community consensus on whether this (or any other) development proposal is supported by a majority of the community. As much as I like the idea of some sort of on-chain voting/staking system I personally don’t think there is time or a good enough system in place for such a new process to be implemented before time runs out. So my proposal is to do it the old fashioned way – network consensus. Whichever node software is supported by the majority of the network becomes the rule.

The Zcash network is the miners and node operators in the community and they now have the choice of running the Zcashd node software which is supported by the ECC or Zebrad which is supported by the Zcash Foundation. Up until version 1.1.2 Zcashd had a flag -disabledepreciation to allow the node to continue running beyond the 16 week deprecation schedule. By removing this flag the ECC sought to keep the majority of the network running the most recent software which is good for network stability, but bad for any choice of software other than the latest version, thus accepting any changes that came with it. I don’t know if the current version of Zebrad allows disabledeprecation.

So my idea is to re-instate the -disabledeprecation flag to let the community decide if they want to support a new development fund (like the one I propose here or otherwise) with the nodes themselves.

I’m not sure exactly how this would work in practice, but in my head it goes something like:

  • A Node software version released by ECC and Foundation prior to , but not the last , before the Founders reward ending blockheight has the option to disable its deprecation, thus letting nodes continue to run beyond the FR ending blockheight if they choose.
  • The Node software release from ECC and Foundation directly prior to the FR ending blockheight has a new % development fund included in it and is consensus incompatible with the prior version.
  • If more than 50% of the network miners/nodes vote with the disabledepreciation flag then the FR ends.
  • If more than 50% of the network miners/nodes vote by running the latest version with a development fund then that becomes the new rule.

So I honestly have no idea if this would work since I’m not a developers/cryptographer and don’t know the network security implications of this kind of fork, or any gameable aspects. But I thought I would just put it out there.

—Conclusion

Feel free to tell me what a bad idea this is, or what I could do to tune/fix it. I have no idea how to submit a ZIP for it either.

Again, this is just my personal idea and does not represent the views of ECC of the Foundation. I sincerely hope that we can continue to see Zcash grow into a private global payment solution if for no other reason than to counteract the impending hegemony of private corporations over the cryptocurrency space. Privacy is a fundamental human right and it should be up to individual to choose what they want to share without having to give their data to whatever entity has spent the most money to monetize it for themselves.

ALL IN ZEC

9 Likes
2

I It was made clear in the Zcon1 event that the development of ZEC requires at least 1m USD per month to be sustainable in the “All in on ZEC” concept. Which I am all for. As an additional suggestion, might be a good idea that the funding for the development be a fixed ammount in USD (the 1m per month USD) and flexible in ZEC.

1 Like
3

That’s an excellent way of measuring community sentiment.

Maybe the nodes could provide more than just a ‘yes/no’ so owners could choose from a range of choices, something like ‘-voteflag A13’ (meaning option A, vote 13)

1 Like
4

Not sure if i understood the nodes voting correctly, but if yes i means ONLY people who use a full node vote. That would mean right now there are 402 nodes online and these vote and have an equal vote, no matter if someone has 100,000 ZEC or just 1 ZEC.

Another concern when it comes to voting with technically advanced voting systems is that you leave the non-technical advanced people out of the elections. Not even talking that a lot of ZEC users don’t even run full node wallets for whatever reasons.
The ideal voting system should be a one that allows as many as possible potential voters to be involved in such voting process and at the same time to ensure that votes are fair. I personally consider that a vote from a 10,000 ZEC holder that gives 1 vote and a 1 ZEC holder that gets as well 1 vote is quite unfair. But it could be as well reverse. I mean why should an exchange wallet for example that holds 200,000 ZEC have mor weight than an active ZEC contributer that holds for example only 50 ZEC? Just some thoughts regarding the nodes vote issue…

5

Actually i personally got aware due the Britich conversvatives leader election of an really interesting election proecess that seems quiete fair.

From all members, in our case, proposals, in each round the proposal with least support gets eliminated until only 2 members (2 proposals) are left for voting. If i remember right until the final voting or ballots as it’s named there a limited panel votes (could be in our case again some kind of governance panel) and in the final round the wide party members vote (could be in our case the whole community).

I think this design of voting has several advantages compared to a direct voting on several proposals at once.
Easy example would be there is 1 proposal of NO-Funding but there are 10 different about continued fundings but with different percentages for example, different recepients and so on. In a single round the “continue-funding” supports would split all their votes on 10 proposals which could lead to making the no-funding proposal the winning one.
Example 2: IF in each round the proposal with least support gets eliminated somone can truely say that the best 2 and 2 most supported made it to the final.

I think these are very important points to have in mind when choosing a voting system, be it for several candidates or propols if the answer is not limited to YES/NO…

6

Shawn, are you proposing here to increase the monetary base to greater than 21 million or to allocate future block rewards to dev funding instead of to mining rewards?

7

My calculations above are based on 9% of Block Reward and subsequent halvings.

The 21M total monetary base would not change.

8

Thanks Shawn for making this proposal.

Instead of sharing 9% of block rewards for dev fund for over 7 years.

How about this:

  • 10% block rewards over next 4 years. So, that’s 518400 ZEC (~ 2.46% of 21M supply) for dev fund (based on numbers provided in the original post).

For this:

  • Quarterly/Monthly transparency report.
  • Roadmap/Vision - what’s in line for next four years for Zcash, without this it would hard for community to just allocate dev fund.
  • As community is funding ECC (like a VC), would it make sense to get ECC board seat(s)? who would represent those seats? etc., still need to be figured out.

Critical Question for ECC/Zcash Foundation: would they be supporting Zcash development after 2024 even if they have plenty ZEC available (scenario: ZEC price skyrocketed by 5-10X).

9

Since Zcash is a POW coin, why don’t we learn the methods Bitcoin making a decision? Vote by individuals or stakings make Zcash like a POS coin.
I persist the emission should be unchanged, which is the guarantee for the decentralization, otherwise Zcash would become a really company coin.

10

I’m more in favor of a longer time period so that the developers can plan for the future.

One of the thoughts behind this was that after the next halving the company /foundation would know that a 50% reduction in ZEC is coming and would give more of a ramp accordingly. But this is also highly dependant on the ZEC value at the time, 50% less ZEC may still be enough to cover costs depending on the market value.

11

That’s an interesting idea, feel free to to start a proposal outlining exactly how that would work so you can submit a ZIP for consideration.

12

The node operators and miners are the network.

This isn’t a “vote” in the traditional sense where the outcome is later ratified by someone. This is Nakamoto style 51% majority of the network software sets the consensus rules, and anyone else forks to a separate chain.

This doesn’t leave room for multiple “questions” on a ballot, for it to work it would need to be 51% of the total network. If 51% no-votes is not breached then the default consensus rules would remain.

Keep in mind, I have no idea if this would work, or the possible security ramifications. I’m fully open to an expert like @daira or @str4d to say it would be impossible, in which case this would just be a proposal for a Development Fund after the FR ends.

If you would like to propose a separate ZEC-stake based voting system then feel free to make a separate thread with how your proposal would work.

1 Like
13

That’s the first problem than, which 2 proposals to choose from, not? Which again, if ideally done, would need a voting system that requires votes for multiple options in first place until you are in a stage of a “final vote” with 2 options.

I don’t have, i struggle as well to think about a good proposal on how voting could be fair & transparent. The best option would have been some voting option integrated into the wallet, but as we lack such i seriously have no idea. Actually i even hoped the foundation itself will come up with something as it should be somehow they could/should manage, not?

14

The cost of running a node is negligible so how do you prevent Sybil attacks? What is stopping ECC (or anyone else) from spinning up 10,000 nodes considering there are 10s of million dollars of funding on the line? You could let the hashpower decide it but that puts the decision solely in the hands of the miners.

4 Likes
15

Not trying to derail your thread, just giving my feedback on the voting aspect in general. I hope this helps you think about you ideas and helps you flesh them out. I offer this as constructive criticism, not some kind of diatribe. I apologise in advance if that is how it reads.

Personally, I feel voting in any sense is the wrong way to go. It gives people a false sense of power. then a false sense of powerlessness when they either missed or didn’t understand the vote - Because we have it drummed into us voting matters - and on a people governance level it is the best we have.

I really am not sure that it is a good idea/model for financial governance though. - The only exception to this would be the community voting/signalling to the foundation of what they want. The foundation then puts these ideas to the ECC, along with their own ideas. [they are already moving towards this]

This has to be made so absolutely clear that you are voting to signal to and maybe influence the foundation, not the ECC.

This time around the ECC has said they would implement whatever the community decides. This is admirable and I think this is a special case, regarding funding extension, not the rule. They should take a stance against implementing things that go against the core values. no matter what the voting decides. Friendly fork if you have enough support.

The ECC has a legal duty to its shareholders above and beyond that of its ‘customers’ - This is for all companies that have share options. (It is even worse with publicly traded companies). Which is why we need laws like anti trust to keep capitalism under control. - These laws are hard to apply to projects where their is no one legal entity behind it (like bitcoin).

I am working on 2 zips to try to solidify what we currently have and why I think it should stay that way. and another as to where alternate financial incentive can be provided to the ECC from the community to help keep them working on this project. I still haven’t seen the Q&A part of zookos talk. but the first half was pretty enlightening. Daira’s was still my favourite tho. I wonder if there is any videos/audio of the workshops. I’d love to hear more.

Another key aspect of voting is that it was never intending as part of the original design. So their could be a large number of holders that do not know that the rules can be changed. they thought they signed up to something where the rules could not be changed by community consensus.

I actually like the benevolent dictatorship model, when that dictatorship is a company bound by legal rules (not as a form of governance of people). I think the ECC is a great experiment in this regard, and on top we now have some real tech with real use outside of transaction processing.

They just need to shore up some potential legal cracks that might appear in the future, which they are doing. for example the two of two sign off model by the foundation/ecc is a great step towards this. I would like the ECC to exist as a company and to support zcash, I would like the foundation to be the voice of the people and help formalise their thoughts into a format the ECC can work with.

I agree, but there are other methods that do this.

might be off topic but wanted to mention it anyway

I will go into more details in my own thread on this topic - please do not respond to this in this thread unless it is relevant to the OP and conversation at hand.

To use bad environmental analogy,

  • all in zec would be “lets just burn through whatever resources we have left on this planet so we can get off it before it dies”
  • Slow down would be “lets use the bare minimum of fuel to keep society functioning for as long as possible”
  • Piviot would be “lets put our resources into working on renewable/green energy sources”

So points 2 and 3 are also doing 1 but with the possibility of less risk exposure, I know of one major fortune 500 that is interested in licencing some parts of zcash, and some modifications - not for a currency but for cryptography.

I was just writing a script to do just that and have half the network nodes. turned out to be a not quite as simple as I first thought but still, it is not an expensive or particularly technical to achive. The problem is all systems can be gamed Satoshi got this wrong with his 1 miner 1 vote idea. great idea, but that one didn’t work out quite so well. For profits dont need customers deciding their internals and work schedule, community projects are decided by their customers so satoshis plan made a little more sense. Customers of for profits have the choice by voting with their wallet. (metaphorical wallet, not crypto wallet)

16

I don’t agree with any proposal that involves extending developer tax.

Yes, development is important, but please let the free market decide where to distribute funds. This will promote an open source technology that other encourage more participants. Otherwise you’re centralizing the knowledge of the technology and now dependent on their support.

Suggest we move forward with the original plan and let the free market decide. And while we’re discussing the possibility of extending the tax, can we have a complete itemized list of all the expenses for funding?

1 Like
17

This should be a must while talking about community funding and a possible dev fee/tax but i doubt there will be such list …
Strange enough the majority of the community seems fine on agreeing to something they have no idea what it’s exactly used for…

1 Like
18

@garethtdavies @mistfpga You guys make a excellent point. I was still thinking along the lines of hashpower, but running nodes is obviously much cheaper to do and would be subject to gaming.

Well that kinda blows away half of my proposal, and my suggestion of 9% over 7 years is very similar to other users proposals.

I will leave this thread up if anyone wants to discuss it further, but I won’t be submitting it as a ZIP proposal.

1 Like
19

I wouldn’t abandon the idea completely - how about if node signalling was influenced by the funds they hold?

Upside, expensive to spread funds across a legion of nodes
Downside, paints a target on nodes used for voting

1 Like
20

That would be an interesting idea, similar to a POS system. I don’t know how Nodes would do something like that though.