Network Sustainability Mechanism (NSM)

Technology
42

Thank you for this proposal which I fully support.
I love the the idea of smoothening the emission as well as the possibility of depositing Zec into ZPF.
It would be interesting to fund future protocol developments by depositing Zec into Fund.
I think also that the part of tx fees(if not all of them) should be definitely redirected to the Fund. Maybe I don’t follow completely the importance of miners(or future validators) getting tx fees directly…

If there will be still some funds inside Sprout and Sapling pool on the day go their deprecation, will it go to ZPF ?

3 Likes
43

Before we try to mess with the devfund mechanism, I would like to propose we narrow down how the funds can be used by mean of a ZIP.
I’ve noticed a growing trend where devfunds is used to fund something and in return Zcashers get nothing out of it.

2 very recent examples :

If Zcash devfund funds something, there must be a “what’s in it for Zcash community” otherwise it should not be funded. Also, funding political speech / propaganda should be explicity forbidden in the ZIP.

1 Like
44

Hi @joris

As to the ECC call outs:

  1. Gary’s Forbes work is predicated (by Forbes) on not being biased toward any particular coin. Meanwhile, he is building credibility and reach with key messages that impact narratives for Zcash, which may be in common with other projects.

  2. The podcast is a platform (as is the PGP breakfast series) that allows us to build alliances, introduce or reshape narratives, and influence influencers in DC policy circles. In some cases, the guest may be ambivalent or even antagonistic toward Zcash or privacy-preserving tools coming into the conversation. It’s a long play.

These activities are highly strategic, with very little cost. We’re open about what we’re doing and why. Just ask.

6 Likes
45

Wax on, wax off.

1 Like
46

(Speaking for myself, not ECC.)

This is not the example you are looking for:

  • The funding came from the Major Grants slice of the dev fund, approved by ZCG (not ZF).
  • The funding was for developing Arti (a Rust implementation of tor to replace the C implementation). This can benefit Zcashers in that the resulting implementation will be feasible to integrate as a library into Zcash nodes and wallets (the C implementation is not - I attempted to do so multiple times), as well as making Tor overall more reliable.
  • Mullvad Browser is a version of Tor Browser that replaces tor with Mullvad VPN. That means it does not include the one part of Tor Browser that the Zcash grant is funding development on.
  • The “payment methods” screenshot comes from Mullvad’s pricing page. Monero was added to the list of accepted cryptocurrencies around May 2022, almost a full year before Mullvad Browser was announced.

I would be very interested in knowing what is preventing Mullvad from accepting Zcash; it would be a great match! Maybe the answer is “we need X technical thing”, which is something that could be addressed (perhaps with a grant!) Or maybe the answer is “no users have requested it”, which is something that Zcash community members can fix :slightly_smiling_face:

8 Likes
47

Hey @str4d I knew all of that, but there’s a lack of “return the favor” attitude from a grantee that got $1M. It is unacceptable to bleed the community from $1M and not even care that the partner you work with doesn’t support Zcash.

I didn’t mean to hijack this thread, but my point is if rework is done in funding mechanism, then I request we also rework ethics in funding.

1 Like
48

A grant is a job, not a favor. Hire the best people who can get it done. Loyalty in the workplace is unproductive anyway.

2 Likes
49

Thanks to everyone who has provided feedback. I want to bring the conversation back to the Zcash Sustainability Fund and focus on one specific issue. As Dodger mentioned above, one important question the community needs to answer is “Should the Zcash emissions schedule change”? As previously stated, the ZSF preserves the 21 million supply cap, but smooths out the emissions curve and maintains an approximate issuance rate that replaces the four-year halving cycle.

So far, I have seen no one raise an objection to changing the emissions curve. There are two potential objections that I’ve considered. First, individuals may want to maintain the halving cycle because they believe (based on Bitcoin’s performance) that periodic supply shocks lead to price appreciation. Second, Proof of Work maximalists may object to the ZSF because they believe such a change could potentially bring Zcash closer to implementing a Proof of Stake consensus protocol. I personally don’t believe either of these objections are particularly strong or valid.

What are other objections we should consider? If you have a strong opinion against changing the emissions curve, please respond to this thread or, if you prefer to respond privately, reach out to me via DM.

Thanks!

9 Likes
50

I’d love to see these activities covered in a new thread. I’ll only follow up here this last time before opting to create a new thread for the topic of regulatory risk.

My original concern(s) are not that carte blanche Zcash might be a security according to the contemporary opinions of the SEC or CFTC in US. I’m of the belief that ZEC, no moreso than BTC, LTC, or any other Proof of Work crypto currency is at risk of being wholly labeled as a security and then put to the responsibilities of being treated as such.

My concern is about regulatory risk to the Electric Coin Company and the Zcash Foundation and their specific actions involved with claiming the ZEC block rewards and then brokering them to some unknown to the public third party. (Can you share any insight into the mechanics of how ECC received ZEC are transacted into USD?)

With that in mind, have you got some feedback about how the ECC have perhaps squared the circle to feel assured that their modus operandi isn’t carrying more regulatory risk than is responsible or necessary? Let’s suppose that ECC chartered itself outside of the jurisdiction of the assorted US federal bureaucracies (in a jurisdiction that doesn’t hold as strict of a vision for regulation of securities), in a situation like that I wouldn’t have any concern about that hypothetical ECC’s carried regulatory risk.

1 Like
51

Quick thoughts.

I don’t really see a major objection to smoothing the emission curve. If there is a continuously variable amount of ZEC emitted, it may make bookkeeping a bit more of a pain for block reward recipients like ECC or ZF, but maybe not. (Just a small thought.) On the other hand, eliminating (relatively) drastic changes in token inflation rate may make the properties of the currency seem less idiosyncratic and perhaps help with volatility.

The argument against smoothing the curve in favor of being able to game the halving volatility seems weak to me. An ideal currency is less volatile, not more.

The idea of the ZSF and emission curve smoothing being a gateway drug to POS also seems tenuous.

One thing getting rid of the halvings will do is get rid of the hard-coded 4 year intervals that have been useful to demarcate decisions about the dev fund. It may be worth encoding those 4 year (or some other interval) markers some other way if the halvings no longer provide them by default.

I’ve only had time to scan this thread briefly, although I’ll say I am generally in favor separating the input and output discussions. I think a lot of points will come up in the future about the output part of the equation, but it seems to make sense to me to start saving early. It reminds me of when I sat down with a financial planner to set up a retirement account and they ask all sorts of questions about the future. How much are you gonna want each year for retirement? Will you have any boats? Etc. I had literally no idea how to answer that, so we just fudged some numbers for their software. But of course, it is obvious that the sooner one starts saving, the more you’ll have later. Now, many years later, I have a much better idea of how to handle myself with long-term financial planning because I’ve learned a lot between then and now. I could imagine a similar situation for Zcash; it is intuitive that starting to save earlier is better and also it is likely we will learn more and more over time how what to do with any funds accrued to the ZSF. This is not to say we shouldn’t be thinking hard about the best ways to allocate resources in the future, only that we will probably be wiser in the future and not having it all mapped out now shouldn’t be a blocker.

10 Likes
52

Well, like ECC, ZF retains outside counsel to advise us on regulatory matters, and I led ECC’s regulatory engagement efforts before joining ZF.

We’re also fortunate in having three attorneys on the board of the Zcash Foundation:

  • Peter Van Valkenburgh is the director of research for Coin Center,
  • J.W. Verrett is a law professor who teaches securities law, and served on the SEC’s Investor Advisory Committee, and finally,
  • in addition to leading the Filecoin Foundation, Marta Belcher is general counsel at Protocol Labs, and special counsel to the EFF.

J.W. talked about the regulatory environment during our community call last week (starts at 7:16), and I’d encourage you to watch that:

6 Likes
53

I just wanted to add some support for this example.

We got Arti working in Zebra at the start of 2022. But we recently had to disable it until we have time to upgrade to the latest Arti API, and until we work out how to integrate it in a way that best balances privacy, Tor network load, and Zcash syncing speed.

7 Likes
54

This extra little wrinkle seems unnecessary at first glance, but I believe it is actually pretty important for the security and sustainability of the ZSF system, so I’m going to dig into it in depth:

No ZSF, or 0% txn fee deposits

In both the current protocol, or if there is a ZSF but 0% of txn fees get deposited into the ZSF, there is an important security flaw when transaction fees are large enough compared to the issuance (or ZSF payout).

When issuance becomes too low, there is a risk to the entire protocol in making “progress” towards finalizing transactions. If the new issuance reward is 0 and the only income is transaction fees, then when a miner sees a new block with large fees in it, they have an incentive to roll it back in order to take the high-fee transactions out of it for their own new block! But then, if they do that and produce a new block which rolled back the one they saw, then the next miner has the same incentive! So there is a serious risk that miners will actually stop extending the chain![1]

BTW- this flaw exists in Bitcoin, too, so if you see folks suggesting that future BTC fees will be enough to pay for mining, that would require some protocol change to avoid this flaw.

100% ZSF deposits

Meanwhile, let’s support we have ZSF and 100% of txn fees go into ZSF deposits. Now the problem is that miners get paid only from ZSF for their block and none from txns they put into their block. It’s easier and cheaper not to include txns. But, if they don’t include txns, then the fees from those transactions won’t get deposited into ZSF! So there’s a “bootstrapping problem”.

Splitting fees to miners and ZSF deposits

So, the “90% / 10%” split is an attempt to balance between these.

BTW- the actual proportion, 90% / 10% are total guesswork on my part. It would be prudent to analyze how different proportions may impact security as well as the whole ZSF economic flow.

Anyway, the idea is by splitting fees this way, we get two mutually-reinforcing behaviors:

  • Because a miner will receive 10% of txn fees, they have a financial incentive to include that transaction into their block.[2]
  • Since they do include the transaction, the other 90% will be deposited into ZSF.

This combination would seem to provide a virtuous cycle: since they are incentivized to do something that leads to ZSF deposits, the ZSF balance should grow (as long as there is txn activity), and when it grows, it provides a consistent stream for future miners, making mining more appealing, thus sustaining network security.

Now this argument really needs better modeling with concrete numbers to answer a few questions:

  • If the ZSF balance is Xⓩ, and the latest block has some high-fee transactions worth Yⓩ, and the proportion of txn fees that pay directly to a block miner is M%, and a miner has C% of the total network capacity, when would a miner be incentivized to rollback the block to “poach” the large-fee transactions?
  • If we expect a users to pay a total of Tⓩ in transaction fees per block (on average over a large enough time window), then what proportion between ZSF deposits and direct-to-miner fees will cause the ZSF balance to increase (thus support network sustainability) vs decrease (thus deplete network sustainability)? (Or we could flip this around and ask "given these parameters, how many txn fees would we need to see for sustainability?)
  • If we have some target rate of fees, and some proportion of direct-to-miner fees, are those fees large enough to incentivize miners to include the txns?

Whew!

And finally:

If there other sources of ZSF deposits (maybe different kind of ZSA fees, Namada deposits, etc…) those all change the modeling above! It seems like any more deposits will generally be good for sustainability, and sustainability could work with fewer txn fees, which might be better for adoption. So with all of this there’s a complex balancing act to build something that everyone can be confident can keep running indefinitely.

  1. I’m simplifying a bit here about mining capacity: a tiny miner may not do this, because the chance that their 1 block rollback will win is maybe too small to make it worth it. It’s more worth it for larger miners. But even for small miners, if the fee is large enough, it may be worth it. ↩︎

  2. Part of the analysis we should do is figure out how large fees have to be to make it worthwhile to include in a block. If it takes a miner some amount of bandwidth, memory, and CPU resources to validate transactions, that adds up to some cost, so the fees would need to be larger than that to make it worthwhile. ↩︎

6 Likes
55

An excellent tokenomics/ consensus/ security incentives nuance to investigate, but because it does not practically manifest as a Zcash ecosystem risk for another 60-100 years… we can probably shelf these implementation debates until after the Proof of Stake upgrade?

(Or will the ZSF work to mainnet happen prior to the Proof of Stake upgrade?)

Bitcoin is a couple of halving cycles ahead of Zcash, and for all that I can tell it is still decades away from really having to feel haste about a protocol upgrade to better balance for the long term viability of coin issuance vs fee compensation as its means to adequately incentivize miners to stick around. The current crisis about spiking fees is nothing but a flash in the pan, once the ordinals-NFT craze cools off the BTC fees will normalize again.

Good suggestions about picking a magic pair of numbers to define the allocation of fee compensation to ZSF vs miners (or validators). I’d recommend two dynamic variables whose sum always = 100% and their values are derived from ~20 week look-back market data (is one magic number better than two? :sweat_smile: ) that considers the trended daily ZEC issuance value, vs transaction fees collected. If those two values ever converged/inverted (by either-or a fall in ZEC value, or a spike in fees) then dynamically the protocol could adapt to mitigate against block fee poaching or any other undesirable behaviors that would become lucrative when ZEC issuance value is inferior to fee poaching value potential for miners/ validators.

1 Like
57

Well, first of all it has an immediate impact: if 0% of txn fees go to the immediate block miner, then miners who exclude all transactions have lower costs and thus a financial edge. (This is ignoring second-order effects like the community putting social pressure on “misbehaving miners”.)

Meanwhile, if the earlier the Sustainability Fund is introduced, the earlier it begins accruing deposits. There’s another economic angle that is subtle: a deposit into the ZSF acts very similarly to reducing the issuance/inflation rate, so the sooner and larger deposits start happening, the more this is like reducing the emission rate (ie: lower available supply).

You can see realtime metrics for a very similar dynamic for ETH supply at ultrasound.money (but keep in mind Ethereum txn fees are massive compared to Zcash currently):

image
image892×453 56.6 KB

Next, aside from the immediate impacts, I tend to assume that the longer time goes on, the more difficult it is to introduce any protocol changes due to politics. This is a double-edged sword: if the protocol is self-sustaining, then being change-resistant can be good, because more people can depend on it to “just work” without worrying about disruption. BTC is the poster-child for change-resistance.

OTOH, if there are flaws that get “locked in” due to political change resistance, that can be bad because there’s a “boiling the frog” dynamic: exactly when should Bitcoin change their protocol wrt fees? There will always be self-interested parties who’d rather kick the can down the road, so will the problem ever be addressed? When will it be too late?

So for changes like ZSF, ZSAs, switching to PoS, etc… which I personally consider can all be improvements that will benefit all current and future users in the long term, I’m a fan of getting them in place sooner rather than waiting. (This assumes each change is widely believed to be a net benefit to all current & future users.)

And finally: I anticipate the changes for ZSF might be deployed well ahead of PoS, simply because it’s much simpler technically. OTOH, changing the emission curve is a Big Deal, so even though it’s simpler technically, it may take longer or not ever happen due to governance process.

As for your suggestion of a dynamic mechanism to adjust how much of the fees go directly to miners vs through the ZSF, I haven’t quite understood it yet. It might be a good candidate for “ZSF v2”. :wink:

6 Likes
58

RFC: Zcash Sustainability Fund - Project Proposal

I am excited to announce that Shielded Labs is partnering with the Equilibrium Group to collaborate on the development of the Zcash Sustainability Fund (ZSF). By working together, we aim to create a strong partnership that leverages our respective strengths.

Shielded Labs will fund the development of the ZSF and utilize its understanding of the Zcash ecosystem to manage and shape the direction of the project and ensure that it aligns with the values of the Zcash community. With a strong background in blockchain engineering, the Equilibrium Group is well-equipped to lead the technical development of the ZSF. Their team of experienced engineers will bring extensive knowledge and expertise to design and implement the necessary mechanisms for the fund. This partnership marks an exciting milestone for Zcash as it strives to become more decentralized and sustainable.

Below is our proposal to develop the ZSF. We invite you to review it and provide your thoughts, feedback, and suggestions. We will allow a comment period for at least one month. If there is general community support and no significant objections, we plan on starting development shortly thereafter.

Background

Recently, there has been increased attention around Bitcoin’s future security budget due to the possibility that miner revenue from transaction fees may not be sufficient to provide adequate network security after the block subsidy ends. Zcash faces a similar problem as its network is sustained by block rewards and operates with a supply cap of 21 million coins.

The ZSF addresses this issue by modifying Zcash’s issuance schedule and introducing a mechanism to direct funds towards sustaining the network. It preserves the 21 million supply cap and smooths out the emissions curve while maintaining an approximate issuance rate that replaces the four-year halving cycle. Fees deposited into the reserve are distributed over time in block rewards to help sustain the network.

In simple terms, the ZSF works like an algorithmic savings account or endowment. Funds are set aside for a specific purpose, to provide a sustainable source of block rewards for the Zcash network. Deposits can come from various sources, including transaction fees, which can be used to fund the network. Disbursements are governed by specific rules and policies that allow ecosystem participants to better plan for the long-term. In this sense, the ZSF is a reserve of funds that is managed separately from the circulating supply of ZEC to help ensure the long-term sustainability of the network.

The ZSF is not dependent on any specific consensus protocol, such as Proof of Stake, and can be implemented within the current Proof of Work consensus protocol. However, since it creates a mechanism for deposits that new applications or protocol designs can use to strengthen the long-term sustainability of the network, it may be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.

Project Summary

We propose the creation of a modest version of the ZSF wherein our primary goal is to modify the issuance schedule, develop the mechanism for depositing into the Fund, and leave the conversation about future changes to disbursements for the community to decide at a later point in time after the fund is up and running. We will develop the ZSF into a proof of concept and implement it into Zebra. At the start, the ZSF will be funded by transaction fees. We are exploring the 90% / 10% split proposed by Nate Wilcox; however, we plan to research the optimal percentage of transaction fees further.

As noted above, the ZSF modifies the existing issuance schedule and replaces it with a mechanism that approximates the four-year halving cycle. Upon implementation, all remaining unissued ZEC will be immediately deposited into the ZSF, and recipients of the block reward will receive a payout directly from the ZSF. This proposal is intentionally neutral towards block reward recipients so that the implementation of the ZSF is not intertwined with decisions related to disbursement reallocations. The distribution of newly issued ZEC in block rewards will follow the proportional split outlined in ZIP 1014, with 80% allocated to the block miner and 20% distributed to existing Dev Fund recipients.

Technical Overview

The technical process of this work is driven by two Zcash Improvement Proposals (ZIPs) that we plan on submitting. The first ZIP would implement the ZSF disbursement at the protocol level as described in the previous section. The second ZIP will propose “smoothing” the issuance curve as described in the background section.

Please note that the following technical details are based on our current understanding of the technology and code, and we remain flexible and open to questions, comments, and suggestions. Also note that additional lower-level / fine-grained ZIPs may be necessary as we move through the process.

ZIP 1: Establish the ZSF on the Protocol Level

If this ZIP is approved, the technical activities involved in implementing it will include, but not be limited to the following:

  • Add the SUSTAINABILITY_DEPOSIT in transactions

    • Potentially update/amend Transaction Malleability (ZIP-244)
    • Update any RPC endpoints that display transaction fields, such as listtransactions

  • Support ZSF_BALANCE in blocks

    • Update block versioning (or use a hard-coded block height as zcashd’s NetworkUpgradeState does)
    • Update block validation to check new fields
    • Update any RPC endpoints

Additionally, during this process we will provide a proof of concept in code (using the Zebra code base) to help facilitate further technical discussions.

ZIP 2: Modify the Issuance Schedule

If this ZIP is approved, the technical activities involved in implementing it will include, but not be limited to the following:

  • Immediately upon network upgrade activation mine the remaining, unmined ZEC into the ZSF
  • Modify the formula in the issuance function to disburse funds more frequently based on block height
  • Update block validation to check issuance amount
  • Potentially modify / expand RPC endpoints

Additional Activity: Plan, Schedule, and Execute Network Upgrade

Once the code is in place and tested, and all the ZIPs are approved, there will need to be an upgrade to the Zcash network. We will work closely with the Zcash community and ecosystem engineers to plan and implement this upgrade into both zcashd and zebrad. Since the ZSF is independent from a transition to Proof of Stake, implementing it earlier allows the ZSF to accrue value sooner. To that end, it would be reasonable to set the activation block height to coincide with the next halving in Q4 2024.

Governance

In terms of governance, there is currently no clearly defined pathway to support independent protocol development. Network upgrades, like the one required for the ZSF, involve inherent complexities and uncertainties due to the decentralized nature of the Zcash protocol. The successful implementation of a network upgrade requires careful coordination and consensus among diverse stakeholders within the Zcash community.

The Zcash Community Advisory Panel (ZCAP) exists as a means of gauging community consensus; however, its primary function is to serve as an advisor for the Zcash Foundation. While we appreciate the governance framework the Foundation has put in place and their commitment to community engagement, we firmly believe protocol development should be permissionless. Seeking approval from ZCAP to develop the ZSF would be at odds with the fundamental ethos of Zcash that allows anyone to actively participate or contribute to the network. The Foundation may choose to poll ZCAP at some point to inform their view on the ZSF, and we would welcome their input.

Shielded Labs and the Equilibrium Group are committed to working closely with community members, ecosystem engineers, and other stakeholders throughout the development process to navigate these uncertainties effectively. We will participate in the bi-weekly Arborist calls and utilize the R&D Discord channel to promote transparency, open dialogue, and a collaborative decision-making process. We started collecting feedback in March and will continue to encourage ongoing community engagement to ensure that the ZSF project aligns with the long-term goals and values of the Zcash community.

Zcash was designed as a consensual currency that allows users the freedom to choose whether to adopt and utilize it. We believe a consensus-driven process is essential for the successful development and implementation of the ZSF. By seeking input from the broader Zcash community and incorporating diverse viewpoints, we aim to ensure that the ZSF project is not dictated by a single entity or group. We believe this allows for a more inclusive and democratic approach to decision-making that aligns well with the spirit and values of Zcash.

Shielded Labs

Shielded Labs is an independent, non-profit organization dedicated to supporting Zcash. Its mission is to increase user adoption, develop new use cases for Zcash, and contribute to protocol development. Shielded Labs was established with two goals in mind: to increase decentralization by independently contributing to the ongoing development of Zcash, and to make Zcash more resilient by building a geographically diverse and robust ecosystem. Shielded Labs is domiciled in Switzerland, a country that is crypto-friendly and has a long-standing tradition of safeguarding privacy rights.

The Equilibrium Group

The Equilibrium Group (EQG) is a constellation of organizations with a combined vision and mission to steward Web3 into the future. The organizations consist of Eiger, a blockchain engineering company focused on scalable, production-ready implementations and Equilibrium Labs, a research-focused engineering organization. The organizations are mainly separated by process and focus and consistently lean on each other’s specific expertise. An example of a joint effort between Equilibrium and Eiger is the Ziggurat project.

Additional Resources

ECC’s blog post announcing the Fund

Draft ZIP written by Nate Wilcox

Nate’s twitter thread summarizing the Fund

Zcash Community Forum thread about the Fund

23 Likes
59

[quote=“aquietinvestor, post:58, topic:42703”]
ZIP 2: Modify the Issuance Schedule

If this ZIP is approved, the technical activities involved in implementing it will include, but not be limited to the following:

  • Immediately upon network upgrade activation mine the remaining, unmined ZEC into the ZSF

Does this mean what I think it means?

1 Like
60

Do you have a link to the official status of this swiss non-profit association?

61

:100:. I hope Zcashers continue to embrace this :clap:. It’s probably one of the most powerful governance mechanisms we have and I believe we should all lean into this more :rocket:.

4 Likes
62

Yes, they will be stored in a specific pool, I guess.
“upon implementation, all remaining unissued ZEC will be immediately deposited into the ZSF, and recipients of the block reward will receive a payout directly from the ZSF…”