Network Sustainability Mechanism (NSM)

Technology
104

Speaking as a ZIP Editor, I wanted to raise a concern about the security of the incentives in this split:

In Nate’s original post about the fee split, he talks about balancing the incentive for mining the current block, and the incentive for increasing the payouts of future blocks.

So I’m not sure if 50/50 is the best split as we move into the future. When issuance drops to zero, a 50/50 split is only balanced if there is a single mining pool on the entire network. Because to get the full 50% in future block payouts, they would need to be the only miner, and plan to be there for the long term. So there is still an significant incentive to roll back blocks for a larger fee.

So whenever the fee difference between blocks exceeded mining costs plus issuance, miners would have an incentive to roll back.

Ideally we’d want a strong incentive to mine even for miners that are significantly less than 50% of the network. And we’d want the current fee share to be low enough to avoid significant fee differences between blocks creating incentives for a rollback.

But we’re not in the far future now, so maybe it’s all ok. But maybe it’s not. So let’s check first, before we deploy the ZIP and find out.

So as part of the ZIP, I’d like to see an incentive model that justifies the proposed fee split for the current blockchain:

  • maximum fee differences between recent adjacent blocks
  • typical mining costs
  • issuance rate before the halving, after the halving, and if the smoothing ZIP is accepted
  • a mining pool that is 50%, 10%, and 1% of the hash rate

A model like this would help us work out a reasonable range of splits, and when we’d next need to review the split.

As an engineer I also have a slight objection to equal fractions, because it will be harder to discover some kinds of bugs. For example, swapping the miner and ZSF fractions, or swapping the checks for the miner and ZSF amounts. (A swap like this happened in Zebra before, but we caught it in code review.)

Any other split than 50/50 would fix this concern. (51/49 would be fine, because the difference between these fractions of the median transaction fee is larger than zero.)

9 Likes
105

I’d like to raise the idea of perpetually randomizing the split to fit within an 80/20 range (or even 90/10), such that per 100 blocks (arbitrary, ~2 hours… perhaps we’d like this to also be randomized, or if it is a fixed parameter… a larger application range could be used? closer to 12 hours: 600 blocks(?), or per 2,100 blocks even to rhyme with the 21,000,000 hard cap(?)), a new distribution is applied at random…

Where at the maximum 80% goes to one cohort or the other, but over a very long timeline the outcome would mediate itself toward 50/50.

Randomizing the distribution over a relatively small window of time, both incentivizes individual participants to play their odds while also incentivizing larger parties to stick out the clock in order to reap the benefits of the math/ time (which favors their disposition).

Also considering that online gambling remains very popular, and is a directly addressable market via decentralized blockchains, it is possible that if the miner/ ZSF % randomizer was done with UI in mind, it could also operate as the core for a Zcash casino-like application layer.

1 Like
106

Hi @teor. Thank you for the feedback; it’s very helpful. We are working on updating the ZIP now and will follow up once the revisions have been made.

2 Likes
107

In my detailed comments on the draft ZIP PR, I mistakenly said this was a 3.1% increase in average issuance over 4 years. It is actually a 0.31% decrease in average issuance (so the issuance is 49.84% rather than 50% of the remaining coins over 4 years). Since that’s much less than exchange rate variance, I don’t think it is a significant difference.

I caught the mistake early, but I wanted to post the correction here anyway, for anyone who read my incorrect comment, but isn’t following the PR.

I’ve made some suggestions to reduce the variance in the PR comments. We can get it as small as -0.005% or +0.011% (49.9971% or 50.0055% over 4 years) within the technical limitations of the protocol:

I’d be interested in feedback about whether 0.31% lower average issuance is significant. Would community members rather us have the smallest possible variance? Or do you want a rate increase or decrease, even if it isn’t the smallest possible?

3 Likes
108

I find that lower average issuance is preferred, afterall what is the rush to emit all of the supply to the earliest adopters; If this is a privacy blockchain asset for the next few hundred years of humanity?

The slower that coins are emitted over time, the more likely the supply is to be equitably and broadly distributed. This calls back to the hazard of many blockchains which have been created with enormous supply vestments to a tiny cohort of early adopters and technical insiders.

109

Just to be clear: I was asking about a 0.31% or smaller change in the issuance, which does not significantly impact the total issuance over time. It’s more of a question of principle: should the change be as small as possible, or should it be heading in a particular direction?

If you’d like to significantly lower issuance, that will need a new ZIP with different goals.

110

In today’s ZIP Editors meeting:

The ZIP editors did a content review on the ZSF fee split ZIP: https://github.com/zcash/zips/pull/718
We reviewed changes in the ZSF issuance smoothing ZIP: https://github.com/zcash/zips/pull/706

Action items:

6 Likes
111

this looks like just another org unless is structured to decentralize development. the below is just an idea to get the conversation started re transaction fees.

Minimum fee 1.5 or 1% of transaction value as a base case scenario

  1. 25 cents to miners
  2. 25 cents to core blockchain improvements. POS etc.
  3. 50 cents to wallet developer or the creator of the edge use case should be able to directly get paid and not go through a centralized org. they set their own prices. it can be less.
  4. 50 cents to additional coin creators on top of zcash block chain. this is optional charge. eg stablecoins. they set their own fees.

the goal is to remove middle men and enable creators to more directly fund their own projects, connect with customers and pay the direct blockchain fees.

fees can be dynamically set based on cost and scale.

1 Like
112

It’s not like a org because no one manages it. The posterity fund is basically a mechanism to “un-issue” ZEC so that it can be saved for issuance later.

I suggest creating a separate topic for your suggestion. Having a percentage fee would leak the transaction value.

3 Likes
113

This is the concise retort that JGX has been in need of!

I suppose that what the middle-ground would be is for market (value) based fee %s applied to transparent transactions, where their value is already revealed anyhow.

Shielded transactions can remain at the absoluted flat and cheap rate.

I like the idea of distinguished fee % for transparent vs shielded transactions because it would act as an incentive mechanism for Zcash users to seek shielded rather than transparent.

1 Like
114

how does money get into the posterity fund? is it voluntary, flat fee or something else?

so when zec is un- issued later, who gets control of the money? my suggestion is to have a mechanism to automatically redistribute the money in real time to

  1. miners
  2. zcash blockchain - dev fund
  3. direct payments to edge use case transactions - we need to have a framework for third parties to access the fees. all the major development platforms that i’m aware of work this way. they create the platform and open development where 3rd parties fund their own use cases. so for example if i like Ywallet, every time i send money out of ywallet, a fee is charged and sent to the list of recipients, including Y wallet developers for creating and maintaining the wallet.
  4. zec yield

so the posterity fund would be more like a protocol that can help transition away from block rewards and towards a self sustaining ecosystem. The goal should be to remove risk associated with centralized control over the money. the more decentralized the lower the risk in my opinion.

seems like a little bit of a problem if we can’t figure out how to charge fees because even a burn mechanism will have the same issues won’t it? why can’t we hide the fees just like we hide the transaction value using ZK ?

1 Like
115

In the current proposal there are two mechanisms: you can deposit voluntarily into the ZSF every time you make a transaction (wallets would need to expose this functionality), and a % of the fees (40% or 60%, can’t remember exactly now) would be deposited into the ZSF.

Where the money would go to is up to whatever is accepted for the next dev fund. But if nothing changes, it would be just miners.

I see your suggestion, you have posted different variations of it dozens of times, it would be better to create its own topic.

6 Likes
116

Just an update from the ZIP Editors meeting last week:
We reviewed some small changes to the 3 ZSF ZIPs, made some suggestions, and asked some questions.

We also assigned some action items to individual ZIP Editors, or to the ZIP Editors as a group. Please let us know if any of these become blockers.

There are some open comments on those PRs where we’re looking for direction from the ZIP Owners. There are also some technical amendments which you can accept or reject. Please let us know if there is anything you’d like us to clarify.

6 Likes
117

Is this the proposal you are referring to @Jgx7 ?

I don’t believe it proposed changing the 21M cap, just changing how halvings work. I haven’t read up on it in awhile.

1 Like
118

My comment wasn’t just about the 21m cap, my comment was also about the halving schedule. I believe I always refer to both 21m and halving schedule. I will see if I can find the chart the shows it effectively “pulls forward” coin issuance. Its the slippery slope I fear. The only reason to change the issuance is to get more money faster. There is no other reason. Then when that doesnt work. Its only logicial they will try to change the 21m cap. Lets just keep the 21m cap, keep the halving schedule. Put it to bed. And then everyone can focus on creating value instead of the gimmicky (and slightly sneaky) changes to coin issuance (Apologies if I am wrong; but that is how I read it; i dont recall much discussion it just came and went. But its probably out there still)

4 Likes
119

ZPF-Issuance-per-10m-Interval-as-of-nu5-Protocol-2048x939
ZPF-Issuance-per-10m-Interval-as-of-nu5-Protocol-2048x9392048×939 16 KB

Here it is. Now if you look at the green line (proposed), it pulls forward coin issuance. So if its done around the same time as the halving, then the green line would extend up to be much higher and closer to the existing coin issuance. In any case, I’m in the camp, we need to reduce coin issuance not increase it. So im a little more sensitive to more coins being sold into the market than under the existing plan. Everyone wins if the price of ZEC increases.

3 Likes
120

Interesting.

IIRC this proposal also puts part of that coin issuance into a fund, so it wouldn’t necessarily all be onto the market by miners immediately if that is your primary concern. I would need to read up on it further to have a opinion one way or the other.

This would also have to change later when/if we move to PoS.

5 Likes
121

My concern is twofold A) We need to reduce issuance if we are going to modify anything, which I am against and B) I dont like the posterity fund. It looks more like end run around the other orgs. Its a land grab. They argue its about smoothing out issuance. Its not. It about pulling foward issuance. But, if they honesly only care about the smoothing out of issuance. Lets reduce issuance today and make it higher further out in the future. Start at the bottom of the next halving and start smoothing from there. See red line

ck6ud12m
ck6ud12m2048×939 45.6 KB

If they are issued, they are in the market. And we already know some % would be sold for Eth/BTC or something else. Thats an aside. We just should not increase coin issuance under any circumstance.

2 Likes
122

While smoothing may increase or decrease issuance in the short term (depending on when it’s activated), in the long run the issuance rate is the same. You are proposing something totally different which is totally changing the issuance curve which would go against most people’s expectations

3 Likes
123

Sorry, but this has been explained multiple times. It’s not an org. No one manages it. No one receives it. It’s a way to “unissue” ZEC so that it can be issued later by the protocol itself.

5 Likes