The Zcash Posterity Fund

Technology
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. ↩︎

5 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…”

63

Awesome!! Having more entities capable of making consensus rule changes to Zcash, especially ones not based in the U.S. will go a long way towards making Zcash more resilient.

Without any plans to deprecate zcashd on the horizon, the new consensus rules would also have to be implemented in zcashd prior to activation. Is this part of the work you’re planning, or is that expected to fall on other ecosystem participants (like ECC)?

4 Likes
64

Hi @earthrise. Implementation into zcashd is part of the work we’re planning. I will make that more explicit in the proposal. Thank you!

5 Likes
65

Sooo… to make Zcash sustainable, the plan is to conjure up the entire coin supply like 100 years early?

1 Like
66

Having the rest of ZEC in a pool controlled by the consensus, is the same as to having the rest of ZEC getting “mined” by the consensus.

12 Likes
67

Not exactly imo. The constantly changing consensus of ~today is potentially very different than the consensus of the future (think years into the future).

One quick example of consensus differences would be to presume the consensus today who are Proof of Work technicians, vs the consensus of the future (if Proof of Stake is completed) who are greater in number and who are ZEC holders/ wallet users but not necessarily PoW Hardware technicians.

Decision making today by the current consensus (PoW) could be viewed critically by the consensus of the future (PoS).

My guess is that the PoW consensus of today are probably not in support of pre-mining the remaining 7 million ZEC into a large transparent pool… whereas future PoS validators may be comfortable with that concept. Pre-mining all of the ZEC would likely be irrevocable as a technical matter.

Personally speaking, I support the pre-mine solution that would place the remainder of all ZEC into a large and transparent pool, where they are then distributed from; to either PoW miners now, or PoS validators in the future.

1 Like
68

Hey folks, we believe this is worth clarifying:

  1. Upon the network upgrade, we will not premine any ZEC in the traditional sense, but rather account for “unmined” (or maybe “reserved”) ZEC in a field in every block.
  2. This balance of “unmined” ZEC will be used to pay mining rewards at a similar pace to now, but will allow the addition of ZEC to this balance.
  3. For now, this will be the only function of the ZSF, with other activities to be determined later
10 Likes
69

Just a note: one possibility that could be considered is that the value of “reserved” ZEC that @aphelionz mentions could take into account the small existing value of ZEC block rewards and fees that was not properly claimed by miners when the relevant blocks were mined. The total value of these unclaimed rewards is the difference between the theoretical supply and the actual supply as of the current block; these values have been computed from the chain history on a per-block/per-address basis and can be found in zcash/contrib/metrics/supply_check/deltas_mainnet.py at master · zcash/zcash · GitHub

6 Likes
70

During last week’s Arborist call, Shielded Labs announced it has started development of the Zcash Sustainability Fund in collaboration with engineers from the Equilibrium Group. The first milestone is to draft two ZIPs: (1) to establish the ZSF at the protocol level and (2) to modify the issuance schedule. We also plan to meet with members of the Zcash Foundation’s engineering team in August to discuss building a proof of concept in Zebra.

We’ll continue to use this thread to provide periodic updates on the status of the project and to solicit community feedback. You can follow along with the project at the Discord Zcash R&D’s dedicated #sustainability-fund channel or via the bi-weekly Arborist calls.

12 Likes
71

What does not properly claimed mean? How many total coins is this today?

My reaction is that valid but unclaimed rewards should remain unclaimed, perhaps the miner intended to unclaim those rewards. It feels like a slippery slope to presume the rightful reward owners intent/ grabbing coins that were not earned as reward via consensus protocol rules

72

Hi all,

I just responded to a CT post about the blocksize growth, and my thread kept growing longer and ended up tying together multiple pieces:

  • block size growth
  • fees in the (current / deploying) ZIP-317 design
  • fees with a potential future upgrade similar to EIP-1559 (I personally advocate this)
  • how that hypothetical EIP-1559-like change could also deposit into the ZSF.

Since my thread mentioned ZSF, I thought I’d share it here as a brainstorm of how future protocol changes might tie into ZSF.

And to be clear, the third and fourth bullets are speculative on my part, but to me they seem like good steps that relate to ZSF. (For example, I’m not aware of anyone actively working on an EIP-1559-like change currently, and it’s not on ECC’s current roadmap.)

Also, just to repeat a position I shared elsewhere, I don’t advocate trying to bundle a change like EIP-1559 into a ZSF design up front, but instead to approach them as separate options, because I think this simplifies each step both technically and in terms of governance.

5 Likes
73

I don’t think “pre-mining” is an accurate concept for ZSF, and to illustrate here’s a thought experiment:

I hearby declare that Zcash has a “Zcash Nakamoto Fund”:

  • Starting immediately with this post, this new fund balance is set to the number of ZEC that will be issued by the current BTC-like issuance schedule.
  • No new ZEC may be created, so all 21M ZEC are either already active in the network or stored in this new fund.
  • This new fund follows a strict rule that withdrawals are only allowed once per block, 80% to miners and 20% to current DF recipients.
  • About every ~4 years, the size of the allowed withdrawals gets cut in half.

Ok. So did we just “premine” 7M ZEC?

No, I just used an accounting terminology to describe the current consensus rules. This isn’t how the current rules are typically described, but it is equivalent to the existing consensus rules.

It doesn’t “premine” anything or change anything about how the ZEC supply, even though it is “a fund” and “withdrawals” are made from it. These are just alternative terms to describe what already exists.

The ZSF is similar, except it changes how funds get distributed into two ways: it “smooths” issuance instead of the 4 year halvings, and it allows “deposits”.

Just like the “Zcash Nakamoto Fund” is an alternative way to describe the current rules, there’s a different way to describe the ZSF that doesn’t use the concept of “a fund” or “withdrawals” or “deposits”.

We could talk only about current block issuance and how that changes when ZEC is contributed to “future block rewards” in such a way that the rate of issuance follows a smooth halving curve and the total supply is still capped at 21M ZEC. I think that alternative description would be a lot harder to understand versus describing a “fund” that the protocol manages because deposits and withdrawals are a convenient way to think of how to describe it.

Does this description about how the “fund” is a way to track accounting and not a “pre-mine” make sense or not?

3 Likes
75

Makes a lot of sense, and I suppose that I understood the suggestion originally also. Although pre-mine seems like what would happen it really is not. The fund acts as a permanent gatekeeper to assure the floating or non floating supply of ZEC is controlled, auditable, and being held up to the rules of the protocol.

My comment at first regards my general conceptualization of specifics of Proof of Work and how it instantiates new coins over time. The long term supply cap for PoW (or PoS) coins depends on consensus. For Bitcoin, people feel extremely assured that its 21m cap will remain unmodified forever, but for much smaller PoW coins there may be occasional feelings that an eternal hard-cap doesnt make sense… lets take Monero for example and their tail emissions supply implementation. I don’t think Bitcoiners, Zcashers, or Litecoiners to make 3 examples would be in favor of an in-flight change to include some tail emissions like supply change.

With the Zcash Posterity Fund, the wording and communication about what it is may be challenging, particularly so because we’re also having active discussions about changing to Proof of Stake, and there are active discussions about the Dev Fund decision for the next halving cycle.

If the ZPF messaging creates confusion, that likely will create fear, uncertainty, and doubts. So however the ecosystem approaches this topic, my opinion is that we should be deliberate in our choice of terms, branding, narrative, short-hand, et al… in order to hopefully mitigate against communications and marketing challenges. We all love the upgrade beyond trusted setups known as Halo but we can also probably all agree that the marketing and messaging around the upgrade was possibly convoluted, delayed, and too technical to pique the interest of common crypto adjacent users and journos.

I’ve never heard Bitcoin described as having its supply in a Nakamoto Fund (?) was that your choice of words for the sake of the thought exercise? I feel that the use of the word fund conjures up the idea of a room with a safe and some security guards… it feels like all of the ZEC today or ever would be stashed in the safe, and that the fund managers then exercise their power to distribute new floating coins or call-back-in existing floating coins.

After thinking about this more, I’m in favor of avoiding the word Fund altogether in the messaging and discussions around this potential protocol upgrade, because Fund is such a well known term, that will carry a ton of (possibly incorrect) assumptions when used to describe the ZPF.

From here on I’ll try my best to use emissions smoothening & fee allocation upgrade ;0

The Zcash ESFA upgrade …ohhh wait, I see a better ordering.

The Zcash SAFE upgrade… Smoothening the Allocation of Fees, & Emissions

5 Likes