The Zcash Posterity Fund

[januszgrze]

Hi everyone!

As you may have seen, we recently posted a blog about the Zcash Posterity Fund. We want to use this forum post as a place where community members can discuss the proposal, voice support, and ask the ECC team questions.

The Zcash Posterity Fund modifies ZEC issuance in order to improve long term financial sustainability of the network, while maintaining the 21M ZEC supply cap and approximate issuance rate. This proposal is independent from PoS or any consensus protocol, and could be adopted with the current PoW consensus protocol with the same benefits and drawbacks.

The full blog post outlining the Zcash Posterity Fund can be found here. @nathan-at-least also did a thread giving everybody the tl;dr on the proposal.

We’ll be hosting discussions around the proposal in the coming weeks. In the meantime, we’d love to gather community feedback in this forum thread, on Twitter and at Zcon3.

We’re interested in everyone’s feedback and questions. Thank you!

[teor]

Thanks for this proposal!

I’m generally in favour of smooth transitions rather than abrupt changes. They are more predictable for users, and easier for developers to code and test correctly.

But I think there might be a vulnerability in one of the issuance rules in the proposal:

The parameter X% is calculated from the block target time so that without any incoming Fund deposits, the balance of the Fund reduces to half over a four year period.

I’m concerned that we’re using a miner-specified value in this issuance rule.

I’m not sure exactly what the block target time is, but I’m assuming it’s based on the median-time-past of the block, which depends on the block timestamps provided by miners in recent blocks:
https://zips.z.cash/protocol/protocol.pdf#blockheader

Here is an attack that gives some miners more fees than others:

1. if the mining pool controls a large proportion of the total hash rate, set the block timestamp as low as possible, to increase X% for future blocks mined by the pool
2. if a mining pool controls a small proportion of the total hash rate, set the block timestamp as high as possible, to reduce X% for future blocks mined by other pools (therefore preserving more balance for the blocks occasionally mined by this pool)

This attack is compatible with the current consensus rules, as long as the block times are:

• within [1, 90 * 60] seconds after the median-time-past for the block
• less than 2 hours in the future, according to the node’s local clock

For example, it is valid for each block time to be 1 more than the previous block time, even if the block took 75 seconds to mine.

Because some of these consensus rules depend on the node’s local clock, this rule also provides incentives to attack node clocks. For example, these attacks could happen via the Network Time Protocol (NTP).

There are also incentives for miners to prefer forks depending on their block times, or rollback blocks with high or low block times.

The difference in X% caused by these strategies might not actually yield a large number of Zats. But the cumulative effect on the protocol could be significant. And attacks can also impact the reputation of the protocol.

Fortunately, there’s an easy fix here - use the block height instead. It’s strictly constrained by the consensus rules to a single value: one more than the previous block.

We could calculate X% for each block height using some combination of:

• the target block spacing, and
• the actual block spacing over the past N years.

It’s not quite as neat as using the block time, but it’s a lot more robust.

[teor]

I also have a suggestion about implementing and testing this proposal:

The final piece of the ZPF proposal is that it now becomes possible to transfer Funds from the circulating supply back into the Fund via Deposits . Future protocol-enforced fee mechanisms may require fees to do this. This base proposal is not specific to any particular deposit mechanisms.

If we implement and release this proposal by itself, nodes, wallets, and miners won’t have fully tested scenarios where:

• deposits happen
• the deposit balance is non-zero
• the issuance rate departs from the smooth curve
• the issuance rate becomes effectively negative
• other amounts in blocks or transactions become negative

That seems like a big testing gap.

So we have two alternatives here:

1. a two-phase release, where we deploy the smooth curve first, then deploy deposits later
2. a single phase release, where we deploy both changes at the same time

If we do a two-phase release, we’ll have more time to code, review, test, and audit the changes. But we might also miss fundamental design issues caused by variable fund balances.

So I don’t have a strong preference here, I’d like us to consider both options.

[mitchellpkt]

These are intriguing proposals!

A smoother disbursement curve seems like a safe and prudent move (whether by this mechanism or a different one).

The ZPF is a really interesting idea, and the tokenomics motivations seem sound to me. Given its novelty, I’ll have to sit with it for a few days to grok the implications. But my initial impressions are very positive, and the tricky parts seem tractable.

The comments by @teor made me curious to examine the Zcash block discovery times, based on the [spoofable!] block header timestamps self-reported by the miners. See figure below showing blocks between Blossom activation and 2022-05-15 when my data set ran out [edit: updated figure axis label to specify units of seconds]. There are definitely some anomalies, most notably blocks whose timestamps precede the timestamp in the previous block (“Merlin blocks” since they defy the usual direction of time and appear to have a negative discovery time). Can’t really do anything about it since timestamp tolerances are necessary for stability, but I think that’s okay from a practical perspective as long as any calculations pertaining to empirically calculated block time are designed with outlier-resistant approaches (e.g. median instead of mean).

Anyways, I’m looking forward to the conversation and developments around these proposals. Thanks @ all the contributors to the design and write-up

(See this notebook for code to generate the plot, and related analyses)

[mitchellpkt]

(Oops i meant to include links in the last post. See block 1467595 with miner-reported discovery at 2021-11-21 05:02:10 UTC, followed by block 1467596 with with timestamp corresponding to 2021-11-21 05:01:32 UTC)

[nathan-at-least]

I want to clarify that the kind of rule I’m imagining does not depend on either block heights or times. It would look like this:

• Calculate a fixed protocol constant ZPF_DISBURSEMENT_PROPORTION based off of POST_BLOSSOM_POW_TARGET_SPACING using the “4 year half life rule”, ie that (1 - ZPF_DISBURSEMENT_PROPORTION) ^ POST_BLOSSOM_HALVING_INTERVAL ≈ 0.5 or in English: “after 4 years of max disbursements with no deposits, half the balance remains”.¹
• Fully validating nodes track a ZPF balance for each block (same data type & constraints as all Zatoshi amounts): ZPF_BALANCE.
• For each block, the disbursement maximum² is ZPF_BALANCE * ZPF_DISBURSEMENT_PROPORTION (or equivalent integer arithmetic, see (1)).
• In the same block, the ZPF_BALANCE is updated by subtracting the disbursement amount, then adding any deposits.

Disbursements are only that single product of one variable ZPF_BALANCE and the protocol constant ZPF_DISBURSEMENT_PROPORTION for any block. There is no dependence on block heights or timestamps. This is similar to the current halving-based reward: as long as it’s not a halving boundary, the reward does not depend on height, and the reward also does not depend on timestamps.

On a short time scale, because block arrival times are stochastic, the actual “wall-clock” rate of issuance jumps around, but on longer time scales (say more than a dozen or a hundred blocks), this relies on the Difficulty Adjustment Algorithm to provide a consistent real-time rate.

If any future protocol changes alter POST_BLOSSOM_POW_TARGET_SPACING or change the way finality timing works, that change should follow the “4 year half life rule” to the best approximation.

Does this address any concerns about mining shenanigans with timestamps or block withholding? AFAICT, the proposal’s behavior around timestamps, block withholding, rollbacks, etc… behaves almost identically to the current block reward system.

Footnotes:

¹ For the toy model from the blog post I used an f64. For a real consensus rule, I suspect we might want to use only integer math for consensus safety / cross-platform precision.

² A subtlety: I always say disbursement “maximum” because I wanted to leave the door open to withdrawing less than this amount. For PoS, this may be useful. I assume this subtlety would upset fans of the supply cap / issuance rate.

[nathan-at-least]

Thanks for this analysis!

What are y axis units?

Are you aware of any data sets that associate the local clock when a node receives a header to compare that against block header timestamps?

[teor]

@nathan-at-least

Does this address any concerns about mining shenanigans with timestamps or block withholding?

Thanks for the clarification!
Using a constant rate makes the security implications much clearer.

And yes, we’d want integer arithmetic. It’s tricky to specify exact calculations using floating point numbers, and many processors have known floating point calculation bugs.

[mitchellpkt]

Good catch, the units on the y-axis are seconds; I’ve updated the image in the previous post to include this.

I was collecting the relevant data back in 2020, but my node has been offline for quite some time now. If anybody has more recent node logs that can be shared (semi-structured is fine), just shoot me a DM, I’d love to carry out fresh analyses of the node-receipt timestamps versus miner-reported timestamps. If anything interesting comes out of it, I’ll make a fresh forum thread with results to review and discuss separately from the ZPF conversation.

[noamchom]

I strongly support this ECC solution to the future risks of:

1. remaining on the exact PoW conceived BTC emission schedule
2. risk of a breakdown in tokenomics under Proof of Stake, due to tail emissions drought (after the assumed transition occurs)
3. transaction fee risk to tokenomics and network consensus security

Have any existing blockchain protocol base layers implemented a supply mechanics solution like what is proposed here?

[dontbeevil]

This is innovation like Dev Fund. I wouldn’t be surprised if other blockchains adopt this.

The sooner we do it the better. Get that ZIP going

[Sean1]

I got questions.

Is this lowering issuance like a halving would?
Therefore lowering inflation?

Thanks

[AJK]

Hello Zcash community,

I love this community, so active and productive.

However, Zcash in its current form is perfect with PoW. The transformation to PoS is too early. I believe once all the Zcash cap mined it would make more sense because the owners of the Zcash currency already there, the cap is all circulating, no need for competition among miners. Also, the transformation in that time will reduce the fees since we all know the fees are the only reward a miner will get when the network is running at that time.

For the Posterity Fund, I would say is a great idea if the fund is coming from outside network and be used to prospectively automate the mining process in order to reduce the cost as well ( it can be done using smart contracts). In addition, miners should receive guides to reduce their costs by using the advancement in renewable energy instead of keeping part of the reward for the generation which is clear will end up with the same results. By those two steps mining will never stops becuase the price as well will compensate the lower reward they are receiving.

Since ZPF is about taking a portion of the miner’s reward and add it the ZPF, the process for the miners of rethinking being a miner in the network wiil start and that not realy desirable since it is an important part of being “decentralized.”

Zcash is one of the best Decentralized Electronic Cash System in the crypo market. PoW is providing choices for miners to reduce their costs by using alternatives to produce electricity whereas PoS is relying mainly on the amount of stake which will centralize the network eventually if it used in early stages. Unless the network is moving toward having EVM compatibility in the soon future and looking to speed up the network to host dapplications.

Important point: what motivate miners to operate when all the cap of Zcash is mined?

I wish the Zcash community the best, and happy to share my thoughts with all of you,

Ahmad

[tokidoki]

@AJK

For the Posterity Fund, I would say is a great idea if the fund is coming from outside network

I would love to know what “outside network”-source of fund that you’re talking about

@AJK

which will centralize the network eventually if it used in early stages

Does PoW decentralize the network more than PoS? Is a system where only a few actors with lots of money can profit from mining more decentralized than a system where everyone with small amount of ZEC can help secure the network and profit from their actions?

Also, Zcash is not at an “early stage” anymore. Moreover, miners have received more than 50% of all ZEC that will ever be minted (assuming the community sticks to 21m cap).

[AJK]

Thanks for your reply,

Yes PoS will minimize decentralization, after this point of upgrade, the network will notice that and will start to let users delegate to create more chances for lower stake validators (less money), but users will look for the highest stake because they have more chances to mint a block and make more rewards. Money here will give more authority over the network.

Unless Zcash will propose a customized PoS that will force the network to choose a validators based on other factors beside MONEY.

*Few people with high stake is PoS, ( Few: lowering the number of people with authority) toward centralization.

More people ( more accepted, more adopted), competing with the same equipment but using various resources to run that equipment is Fairness (PoW). Resources distributed over the whole world. "Most the money with 1% of the whole world. The case now in Zcash.

I know Zcash isn’t in early stages, the more the upgrade postponed the more decentralized the network will be. However, once the network mined all Zcash, PoS makes more sense because the reward of the mining is the service fees not new minted Zcash.

The proposal of ZPF points out to outside support, I just wanted to say this outside fund much better for the future than taking portion on miners, who might not be able to act maliciously but can stop working becuase his cost of operation is high.

[Sean1]

Motivations of Proof of Stake: Zooko Wilcox at Zcon3

This talk by Zooko at zcon3 answers a lot of your concerns.

[AJK]

I like what Zooko presented. I see his point of view, Zooko is looking for stable minting process from the transaformation from PoW to PoS since PoS is much easier to engage people in the minting operation. Despite the fact that in PoW, you have to set up your own equipment to start mining. This is a valid point but will not increase decentralization, it will minimize it. And usually all networks started with this process they are trying to avoid the decrease in miners by having known validators, which any user can elect and delegate their crypto to increase their chances in minting and making sure the operation is on even with lowest number of validators.

To conclude, once you apply ZPF and get some of miners rewards to ZPF, PoS makes more sense, because it will keep the network running becuase it will use the crowd stake in addition to the validator which will support the operations.

Both PoW and PoS, are best versions of consensus algorithms. Both secured and imuutable, but the difference here is the level of decentralization.

Anyway, in crypto decentralization is acquired by embedded rules applied over the network through the code not by the technology used.

Good luck Zcash community

[cwgoes]

I have a few questions about the ZPF proposal as it might pertain to ZSAs, bridges (e.g. this proposal), and interoperation with other assets and ecosystems:

1. Could the ZPF accept deposits in other assets? For example, if fee payment is supported with ZSAs directly (instead of requiring all fees to be paid in ZEC) - perhaps with some multi-token EIP1559 variant - could the ZPF take part or all of those fees in deposits, and pay them out following the same “four-year halving” schedule? It seems to me like in principle this should be possible, but it depends of course on the details of the implementation.
2. Could the ZPF accept deposits of assets sent across a bridge? For example, if another ecosystem wished to donate another asset - perhaps ETH, USDC, some other native token - to support Zcash development, and if the Zcash network (PoW or PoS) via a bridge were able to receive other assets, could these assets be deposited into the ZPF (and paid out in the same way)? Would this be a good way for other ecosystems - which do not in general have a lot of ZEC - to fund Zcash development (and also perhaps to diversify ZPF / Zcash network revenue)?

Note: In general, I don’t think that the security models of proof-of-work or proof-of-stake are dependent on security payments (to miners or validators) being made in a single/native asset, but I haven’t done extensive research here and would like to hear if anyone has.

3. Could the ZPF, if it accepted deposits in other assets, implement other issuance curves, but pay the same participants?
4. Relatedly, could the ZPF, if it accepted deposits in other assets, allow depositors to choose the recipients and issuance curves of their deposits?

These questions may seem odd or pointed - the general thrust of my inquiry is this: could the ZPF be turned into a more general public-goods funding mechanism for the Zcash ecosystem? Network security, development, research, and outreach are all public goods - which I expect myself and many others would be interested in funding - but perhaps not all in the exact same way or with the exact same assets.

For example, the Namada network under development by Heliax builds on the technology originally developed by the Electric Coin Company and Zcash, implements a public-goods funding mechanism capable of both proactive and retroactive disbursement, including over bridges, and we would like to find a good way to contribute back to the Zcash ecosystem & community to support both the past research and continued development without which our work wouldn’t be possible. One way I can imagine doing that is by directing a small part of the inflation from our network over a Zcash bridge to the ZPF, where it can be disbursed to the ZPF recipients, who can use it as they would prefer. As compared to an airdrop or once-off funding of individual people/organisations, I like this approach because I think it better captures our desire to fund collective public goods, in a fashion sustainable over time, and to fund public goods in a way approved by the Zcash ecosystem - but there may be downsides (for example, I expect this would increase ZPF implementation complexity somewhat) and I’d like to hear what folks think.

[dontbeevil]

@cwgoes

Namada network under development by Heliax builds on the technology originally developed by the Electric Coin Company and Zcash, implements a public-goods funding mechanism capable of both proactive and retroactive disbursement, including over bridges, and we would like to find a good way to contribute back to the Zcash ecosystem & community to support both the past research and continued development without which our work wouldn’t be possible

[dontbeevil]

I think this is beginning of something. I don’t even have a term for it.