Proposed NSM update ("Long term security")

Long Term Security mechanism

Writing this as a response for how I’d interpret NU7 polling results for (2) and (3). This is what I consider the natural interpretation, with one non-natural addendum, delay the disbursement date. I’ve also had confusion in discussions using the word “NSM” due to different interpretations of the word “burn”, and changing the block subsidy being key to NSM. Hence LTS.

The halvening schedule of block subsidy to miners is not adjusted, per coin holder vote. That remains under the existing halvening schedule. We make a new tracker in state, called “long term security funds”, AKA LTS_funds, that is funded via:

  • Voluntary donation
  • 60% of all tx fees

This tracker is set to pay out along the smooth issuance function. (I don’t personally care if its smooth or discrete, thats a minor detail. Proposing smooth to be in line with past discussions)

As per the logic in ZIP-234, the payout per block is \mathsf{LTS_funds} * \frac{4126}{10\_000\_000\_000}, and the remaining LTS funds decrease by the payout amount.

The payout to the miner is done as a single output for both block subsidy, and LTS payout. So the output amount is: \mathsf{block_subsidy} + \mathsf{LTS_funds} * \frac{4126}{10\_000\_000\_000}

Addendum

Lets only begin disbursement of LTS_funds two halvenings from now. Funding from tx fees is currently negligible as compared to block subsidy.

My shielded payments are at .0001 zec fee. If we sustain 1 TPS, the tx-fee payout into the LTS fund is .0045 zec/block. Compared to the current block reward of 1.6 ZEC/block. This is negligible, so we should let the fund accumulate, and be disbursed once block rewards are far lower.

Prioritization

To be clear, I don’t consider any of the NSM/LTS work short term important. We have yet to remotely hit fee demand outside of spam, and it’s far more useful to do everything on the critical path to improve chain UX, kill shielded sync, and get post-quantum.

But I have had a number of conversations wrt confusion on how to interpret the poll results. This is my impression of the vote, consistent with how I voted in: NU 7 discussions: NSM

3 Likes

I like this idea! We shouldn’t waste the budget meant to fund long term security while we don’t yet need it. Starting in two halvings feels a little arbitrary, but I cannot think of anything better on the spot. I do wonder about even longer term security. There’s just no way around the fact that in the limit our entire security budget needs to be covered by fees. That’s one of the reasons why Project Tachyon is so important. If we want fees to be somewhat affordable per transaction we need a ton of them.

2 Likes

The NSM was previously referred to as the Zcash Posterity Fund and the Zcash Sustainability Fund. It doesn’t need another name change. If the word “burn” is creating confusion, we can instead describe the mechanism as “removing ZEC from circulation” and “recycling it into future block rewards.”

It sounds like we’re interpreting the results very similarly:

We’re open to discussing the appropriate activation height for the disbursement mechanism. As I mentioned on Signal, Zooko is building a simulator to model issuance smoothing as well as alternative approaches that don’t require smoothing, which we plan to review with you in the coming days. Let’s start there and then decide how to proceed.

We believe there’s an opportunity right now to attract long-term investors. In conversations we’ve had over the past year, investors respond positively to the fact that we’re thinking about and actively addressing long-term sustainability. Broad consensus from the community and coinholders for implementing the NSM in the next network upgrade would send a clear signal that we have a credible path forward.

Tachyon could increase aggregate fees in the near term by allowing a much higher rate of transactions, which makes the timing especially important. NEAR Intents integrations and additional Maya DEX activity could also increase fee demand. If several of these developments gain traction at the same time, aggregate network usage could rise meaningfully. In that scenario, it would be better to already have the NSM in place rather than trying to introduce it later.

Implementing the NSM now clearly signals that we are planning for the network’s long-term future. That clarity helps shape expectations and market behavior, because confidence in long-term sustainability is itself economically meaningful. Given the ongoing debate around Bitcoin’s future security budget, having a mechanism explicitly defined at the protocol level could be an important differentiator for users and investors evaluating network security.

8 Likes

It sounds like we’re interpreting the results very similarly

Awesome, super exciting! Lets retain the name as NSM!

We believe there’s an opportunity right now to attract long-term investors

Great! I’m personally really aligned then on trying to get a final proposal voted on ASAP, and into next upgrade. Let me know, happy to help on implementation.

We’re open to discussing the appropriate activation height for the disbursement mechanism

Sweet, please post when its updated, or if you want help on it.

4 Likes

The way I think about the security budget can be divided into three related problems.

How much we spend

I think there is a real question about the cost-effectiveness of Proof of Work. When the Ethereum Merge happened, we saw how inflation fell. There are discussions in that ecosystem to further limit inflation with a staking soft cap. What allows this to be done safely is the supply inelasticity of cryptocurrencies; i.e., if you try to buy 51% of staked ETH, you’ll increase the price so much that you cannot succeed. The same is not true for an attack on a PoW network, because when the attacker buys more and more mining ASICs, the price per unit may even decrease thanks to economies of scale.

How much we collect

Here, economies of scale play a role as well, because for fees per transaction to remain low and fee revenue to increase, we need many more transactions than we currently support. We not only need the technical foundation to support many more users, but we also need those users to actually show up, use the network, and pay the fees. This is a very hard challenge. Even Ethereum, which has tried the hardest at becoming deflationary, has not yet succeeded, and that is in spite of all the fees generated by DeFi, L2s, ENS, and dapps.

Source

How much time we have to break even

This is where the NSM comes in. It can buy us some time to break even. Breaking even requires more than a few technical breakthroughs and an explosion of real-world adoption. None of this will happen overnight, but we have to plan for success. In the startup world, people sometimes talk about increasing the runway when they raise funds with the goal of becoming profitable; the same applies to the NSM. I think schemes where we save money now while issuance is still high and spend it when new issuance gets much lower will naturally increase that runway furthest due to the issuance exponentially decreasing.

3 Likes

The important thing about deferring the activation of reintroduction of funds “un-issued” by ZIP 233 is to recognize that it imposes a constraint on future action. Someone who is using the mechanism today to remove funds from circulation must consent to the eventual disposition of those funds. I agree with the arguments that I’ve seen that the re-issuance mechanism, if it activates at the same time as the un-issuance mechanism, may make suboptimal use of those funds in terms of the long-term security of the chain since they are almost certain to be dwarfed by current block rewards. However, deferring the activation of reissuance also presents potential problems, in that it fixes in place a new component of the issuance algorithm, that will probably be as hard to change as the original halvening-based issuance algorithm is proving to be!

As such, I think that it’s very important to think carefully about the “contract with future users” that this mechanism is introducing. It’s the same problem as pool deprecation; despite the fact that it was made clear early on to users that the Sprout protocol would eventually be deprecated, there is now opposition to that deprecation despite the very real security costs that the existence of Sprout imposes. The implicit “the decisions set forth by this ZIP may be altered by a future ZIP” is clearly not sufficient to avoid ossification.

1 Like

I think you’re right to point out that it’s important to think carefully about any “contract with future users”. However, we already have an implicit contract with those users, because they will need to continue to pay the security budget while new issuance asymptotically approaches zero.
I would argue that saving some funds for those future users to spend on security isn’t really constraining future users, but rather current users. That said, reasonable people can naturally disagree on where limited resources are best allocated.

  • Should we spend more money on increasing the runway or building the plane?
  • What parts of the plane need to be built for takeoff?

We already took the most important step in the early days of the project, which was to spend 1/5 of new issuance on development. I am thankful we did, because I’m not sure such a change would have support today. But I understand why coinholders are wary about changing the issuance curve. That is why I am glad that coinholders signaled support for funding the runway extension with 3/5 of current fee collection.