mirror of https://github.com/zcash/zips.git
370 lines
16 KiB
ReStructuredText
370 lines
16 KiB
ReStructuredText
::
|
|
|
|
ZIP: Unassigned
|
|
Title: Decentralize the Dev Fee
|
|
Owners: Matt Luongo <matt@thesis.co>
|
|
Status: Draft
|
|
Category: Process
|
|
Created: 2019-09-27
|
|
License: MIT
|
|
|
|
Motivation
|
|
==========
|
|
|
|
Who am I?
|
|
---------
|
|
|
|
My name is Matt Luongo. I'm an entrepreneur who's been full-time in the crypto
|
|
space since 2014, co-founding Fold, a Bitcoin payments company, and more
|
|
recently Keep, a private computation startup built on Ethereum. At Keep, we've
|
|
done some `work around Zcash <https://github.com/ethereum/EIPs/pull/2129>`_,
|
|
and our parent company, `Thesis <https://thesis.co>`_, is considering investing
|
|
more heavily in Zcash development for our latest project.
|
|
|
|
I'm deeply interested in privacy tech. For me, privacy is about consent --
|
|
consent to share my habits, beliefs, and preferences -- and I see privacy as
|
|
the inevitable next frontier in our pursuit of an economy that respects
|
|
individual choice.
|
|
|
|
My perspective is as the founder of a for-profit company focused on building
|
|
self-sovereign technology who wants to develop on Zcash. We work in this space
|
|
ideologically, but our work isn't free; attracting and growing talent requires
|
|
funding.
|
|
|
|
If you're interested in more on my background, I've introduced myself more
|
|
`properly on the forum
|
|
<https://forum.zcashcommunity.com/t/introducing-matt-luongo-from-keep/34947>`_.
|
|
|
|
What's this about?
|
|
------------------
|
|
|
|
Since Zcon1, I've been looking to fund work to build an Ethereum / Zcash bridge.
|
|
I've spoken to the ECC, the Zcash Foundation, and a number of early Zcash
|
|
community members on how best to move forward with this project, and in the
|
|
process I've learned a lot about how the community works and dev governance has
|
|
been structured thus far.
|
|
|
|
Inevitably, I've become interested in the community's proposals for a new dev
|
|
fee, and thought about how the right structure might support work like ours.
|
|
|
|
I believe the Zcash community has an opportunity to deploy a new incentive
|
|
structure that will attract companies like ours to build and improve Zcash,
|
|
leading to a more resilient network, stronger technology, and wider usage.
|
|
|
|
The Zcash narrative
|
|
-------------------
|
|
|
|
We're all here to build a robust, private, decentralized currency. But in the
|
|
dev fee proposals I've seen so far, the idea of a Zcash narrative that
|
|
distinguishes it from the competition is absent.
|
|
|
|
Of the slew of ZIPs addressing Zcash's future, there's only been one strong
|
|
narrative case -- the idea that Zcash exists purely as a hedge against Bitcoin's
|
|
long-term privacy failure. Put simply, Zcash is "Bitcoin, but private".
|
|
|
|
Zcash should aim higher. Bitcoin is the only coin that has successfully made a
|
|
store of value argument, which I like to call "worse is better". Don't upgrade
|
|
the network -- the argument goes -- stability is more important than solving
|
|
today's problems. Bitcoin is chasing the `Lindy
|
|
effect<https://en.wikipedia.org/wiki/Lindy_effect>`, where worse is better, and
|
|
the network becomes stronger every day it survives. That's great for Bitcoin.
|
|
For the rest of us, though, better is better. Zcash *should be better*.
|
|
|
|
Zcash is known for having the best tech in the space, built by one of the best
|
|
team's in the space. We should lean in to that reputation, nurturing the best
|
|
research and engineering talent to take Zcash to the next level, and leveraging
|
|
a Zcash dev fee as a differentiator to build the world's best private medium of
|
|
exchange.
|
|
|
|
Principles of cryptocurrency governance
|
|
---------------------------------------
|
|
|
|
To understand Zcash governance, it's worth reviewing "default" cryptocurrency
|
|
governance. Most proof-of-work chains today have three major governing roles:
|
|
|
|
1. Miners validate and secure the chain. They do some work to earn a reward.
|
|
Miners are the first owners of newly minted coins, and are an integral part
|
|
of network upgrades.
|
|
2. Users buy, hold, and spend the currency. In networks like Bitcoin, they also
|
|
run full nodes, strengthening network resilience by decentralizing
|
|
validation.
|
|
3. Developers maintain clients to power and interact with the network. They
|
|
typically propose network upgrades.
|
|
|
|
On a chain like Bitcoin, any of these roles can veto a network upgrade.
|
|
|
|
1. Miners can veto activating a new fork by refusing to build off blocks using
|
|
new network rules, orphaning a minority effort. They can also attack any fork
|
|
attempt that doesn't change
|
|
2. Users can veto a fork by refusing to update their full nodes, rejecting
|
|
blocks as invalid -- as demonstrated in the UASF fiasco resulting from the
|
|
SegWit2x attempt to force a Bitcoin hardfork. Users can also vote with their
|
|
dollars, acting as a fork resolution of last resort via market pressure.
|
|
3. Developers can refuse to update client codebases to follow a fork. While this
|
|
might not seem like a strong veto, in practice that means any fork will need
|
|
at least one additional development team, or the agreement of existing client
|
|
software developers.
|
|
|
|
These roles together form a balance of power that makes contentious forks
|
|
difficult -- any change that a large swath of users disapproves of could split
|
|
the chain.
|
|
|
|
The state of play
|
|
-----------------
|
|
|
|
In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash
|
|
Foundation skew this balance.
|
|
|
|
Both organizations are comprised of Zcash founders, developers, researchers, and
|
|
privacy proponents who have driven this ecosystem forward and represent its
|
|
values. Nevertheless, their mode of operation today skews a healthy balance of
|
|
power in Zcash governance.
|
|
|
|
The mechanisms of that skew are the Zcash trademark, held by the ECC, and
|
|
primary client software development, now split between the ECC and the
|
|
Foundation.
|
|
|
|
In a disagreement between miners, users, and developers, the ECC has the
|
|
unilateral option of enforcing the Zcash trademark, effectively allowing them
|
|
to choose a winning fork against the will of users, miners, and other
|
|
developers.
|
|
|
|
While the Foundation's maintenance of the `zebrad` client would normally allow
|
|
them to "soft veto" a network upgrade, they don't have a similar veto on the
|
|
Zcash trademark enforcement.
|
|
|
|
Compounding these issues, the Foundation and the ECC aren't arms-length entities
|
|
as they're organized today.
|
|
|
|
This situation poses a number of problems for new and existing Zcash users, as
|
|
well as both entities.
|
|
|
|
* The threat of a central entity overriding (or being forced to override) the
|
|
will of users undermines self-sovereignty.
|
|
* The ECC and Foundation are both put at legal risk. As entangled entities,
|
|
they're remarkably similar to a single entity when trying to minimize
|
|
regulatory risk.
|
|
* Power between the two entites *hasn't* been decentralized. The ECC remains
|
|
a unilateral power, as well as a single point of failure.
|
|
|
|
The "crowding out" problem
|
|
--------------------------
|
|
|
|
The Zcash ecosystem, as it exists today, leaves little incentive for outside
|
|
developers to participate.
|
|
|
|
Zcash development has a high learning curve.
|
|
|
|
* The reference client is a fork of the Bitcoin reference implementation,
|
|
building on a decade of poorly written legacy code.
|
|
* What Zcash brings to the table involves a greater understanding of applied
|
|
cryptography than most projects. SNARKs are often still referred to as "moon
|
|
math", after all.
|
|
* As the recent network-level attack demonstrates, full-stack privacy is hard.
|
|
|
|
Most outside developers need to see a clear path to longer-term funding before
|
|
they can commit to the cost of that curve.
|
|
|
|
Even those developers who already have the expertise to work on this system are
|
|
frustrated by the lack of longer-term funding. For evidence, look at Parity's
|
|
exit from Zcash after `zebrad` development, or Summa's struggles to work on
|
|
Zcash.
|
|
|
|
Sustainably attracting talent to Zcash is critical to maintain innovation and
|
|
build resilience.
|
|
|
|
Requirements
|
|
============
|
|
|
|
The first requirement is a balanced governance structure. Developers should be
|
|
rewarded, without rewarding governance capture. What's best for the chain and
|
|
ZEC holders should always come before commercial interests.
|
|
|
|
The second, and secondary, requirement is funding Zcash development. While the
|
|
chain shouldn't be run by a commercial entity, it will need to be supported by
|
|
them.
|
|
|
|
The third requirement is the support of a more resilient ecosystem by:
|
|
|
|
1. Ending the "crowding out" problem by paying development teams to work on and
|
|
for Zcash.
|
|
2. Building a dev fee management structure that's resilient to the loss,
|
|
capture, or compromise of the Zcash Foundation.
|
|
3. Ensuring the ecosystem can survive the loss, capture, or compromise of the
|
|
ECC by encouraging developer diversity and strategic input.
|
|
|
|
Finally, avoid introducing unnecessary additional entities into the governance
|
|
process.
|
|
|
|
Non-requirements
|
|
================
|
|
|
|
General on-chain governance is outside the scope of this proposal. On-chain
|
|
governance is an exciting idea -- what if we had an impartial arbiter funding
|
|
development? My experience with on-chain governance to date, however, leads me
|
|
to believe it's still a risky direction. Zcash should focus on what it's good at
|
|
-- privacy -- and leave proving on-chain governance models to other projects.
|
|
|
|
While this proposal attempts to outline a long-term structure for Zcash funding
|
|
and governance, specifying the structure beyond the next 4 years is out of
|
|
scope. Much will have changed in 4 years. Perhaps this structure will be
|
|
sufficient; perhaps we'll be battling the Third Crypto War, and need to go back
|
|
to the drawing table.
|
|
|
|
Specification
|
|
=============
|
|
|
|
The below proposal is an effort to cleanly resolve the problems with Zcash's
|
|
current governance, while
|
|
|
|
* maintaining a balance of power between stakeholders
|
|
* removing single points of failure / control
|
|
* growing development and usage of Zcash
|
|
* and supporting the best interests of miners, users, and developers *today*.
|
|
|
|
Decentralizing development
|
|
--------------------------
|
|
|
|
A few proposals have suggested the introduction of a mysterious "third entity"
|
|
to resolve disagreements between the Foundation and the ECC.
|
|
|
|
I prefer a different approach, refocusing the role of the Foundation and making
|
|
room for the ECC to work with a robust developer ecosystem.
|
|
|
|
In this proposal, the Foundation shall support community development through
|
|
running the forum and events, gathering community sentiment, managing short-term
|
|
development grants, and conducting the diligence behind the assignment and
|
|
disbursement of a development fee. This development fee shall be funded by 20%
|
|
of the block reward, with as much as half of the fee burned in case of
|
|
extraordinary growth in the price of ZEC.
|
|
|
|
The Foundation shall receive 25% of the dev fee. If the volume-weighted average
|
|
price of ZEC over the month means the foundation would receive greater than
|
|
$500k that month, the Foundation shall burn enough ZEC such that their max
|
|
benefit is
|
|
|
|
.. math::
|
|
|
|
MaxBenefit(RewardDollarAmount) = Max(500000, \sqrt{\frac{RewardDollarAmount/500000}})
|
|
|
|
Capping the monthly upside of the Foundation will limit growth, while
|
|
encouraging fiscal discipline.
|
|
|
|
The remaining 75% of the dev fee shall be distributed between development teams
|
|
working to maintain clients.
|
|
|
|
* One third of the remaining fee (25% of the total) shall be reserved for the
|
|
role of the "principal developer", a developer with additional voice in Zcash
|
|
governance. The principal developer allocation shall be capped similarly to
|
|
the Foundation's, based on the monthly volume-weighted average price.
|
|
* The remaining two thirds of the fee (50% of the total), called the "outside
|
|
development fee", shall be distributed between at least two development teams,
|
|
chosen semi-annually by the Foundation, coinciding with network upgrades.
|
|
Unlike those of the Foundation and principal developer, these allocations
|
|
aren't affected by market conditions, and don't carry a burn requirement.
|
|
|
|
Prior to each network upgrade, the Foundation shall recommend a list of
|
|
addresses and a total number of ZEC per block each address is meant to receive
|
|
from the dev fee. The recommendation will be "ratified" by the miners as the
|
|
network upgrade activates.
|
|
|
|
The role of dev fee recipients
|
|
------------------------------
|
|
|
|
Dev fee recipients are distinguished from grant recipients in the scope and
|
|
timelines of their work, as well as the specificity of direction. The intent
|
|
is to allow teams to focus on a core competency, while encouraging research and
|
|
adjacent work.
|
|
|
|
Dev fee recipients are chosen semi-annually by the Foundation based on their
|
|
ability to move Zcash forward. Recipients will typically be development teams,
|
|
though "full stack" teams that can communicate well with the community, expand
|
|
Zcash usage, and widely share their work should be advantaged.
|
|
|
|
Recipients shall submit quarterly plans to the community for their efforts, as
|
|
well as monthly progress updates.
|
|
|
|
All work funded by the dev fee will be open source, under licenses compatible
|
|
with the existing Zcash clients.
|
|
|
|
Though the Foundation shall periodically judge the efficacy of dev fee
|
|
recipients, deciding on and driving roadmaps for Zcash is the role of dev fee
|
|
recipients, in partnership with the community. This role is neatly balanced by
|
|
users running full nodes and miners, either of which can veto a network upgrade.
|
|
|
|
While dev fee recipients are not required to work exclusively on Zcash,
|
|
considering the nature of their work, recipients must guarantee they aren't
|
|
obliged to the interests of competing projects.
|
|
|
|
The role of the principal developer
|
|
-----------------------------------
|
|
|
|
The role of the principal developer is as a "first among equals" amongst the dev
|
|
fee recipients.
|
|
|
|
The principal developer shall make a number of guarantees.
|
|
|
|
1. Zcash shall be their exclusive focus, submitting financials periodically to
|
|
the Foundation as assurance.
|
|
2. They shall maintain a well-run board and employ a qualified CFO.
|
|
3. In addition to the existing open-source requirements, they shall agree to
|
|
assign any trademarks or patents relevant to Zcash to the Foundation.
|
|
|
|
In exchange, the principal developer is granted an indefinite dev fee allocation
|
|
and a wide remit to pursue longer-term research relevant to Zcash, as well as
|
|
a voice on the board of the Foundation. The principal developer will not be
|
|
subject to semi-annual review, though it will submit the same plans required of
|
|
other recipients. The principal developer will only be recommended for removal
|
|
by the Foundation in extraordinary circumstances, including reneging on the
|
|
above guarantees or extreme negligence.
|
|
|
|
Minimum viable Foundation
|
|
-------------------------
|
|
|
|
To manage the dev fee and fulfill its community and diligence duties, the
|
|
Foundation shall maintain a board of 5 independent members. Rather than the
|
|
structure in the current bylaws, the board will consist of
|
|
|
|
* 1 seat voted on by ZEC holders directly.
|
|
* 1 seat representing a newly created research advisory board, whose primary
|
|
role will be technical diligence of potential recipients of the dev fee.
|
|
* 1 seat for the "principal developer", a privileged recipient of the Zcash
|
|
dev fee acting as "first among equals" amongst a variety of dev fee recipients
|
|
building on Zcash.
|
|
* 2 seats elected by the board, as the board is currently selected according to
|
|
the bylaws. The board's discretion here means these could be selected via a
|
|
community election, or via the remaining 3 seats' direct vote.
|
|
|
|
The Foundation requires a professional board. Board member selection should
|
|
heavily favor candidates with existing formal public or private sector board
|
|
experience. Each board member shall be paid reasonably by the Foundation.
|
|
|
|
Each board member should bring a unique network and set of skills to bear to
|
|
increase the impact of the Foundation.
|
|
|
|
Outside the seat for the principal developer, no board members shall have an
|
|
ongoing commercial interest in any recipients of the dev fee.
|
|
|
|
The ECC as the principal developer
|
|
----------------------------------
|
|
|
|
I propose that the ECC be considered as the initial principal developer,
|
|
receiving an indefinite dev fee allocation in exchange for their exclusive
|
|
focus on Zcash research and development, and assigning all patents and marks
|
|
relevant to Zcash to the Foundation.
|
|
|
|
I believe this arrangement is best for the Zcash ecosystem, and with proper
|
|
management of funds, should satisfy the ongoing needs of the ECC.
|
|
|
|
The dev call
|
|
------------
|
|
|
|
The Foundation shall organize a bi-weekly call for all dev fee recipients and
|
|
other third party developers. The call will be live-streamed for community
|
|
participation, though the speaking participants will be invite only. At a
|
|
minimum, a single representative from each dev fee recipient should attend.
|
|
|
|
The Foundation shall also maintain a simple chat solution for development of
|
|
the protocol. While the chat logs should be publicly viewable, it need not be
|
|
open to public participation.
|