NU7 Coinholder Vote

A few comments to document here what I said in yesterday’s ZIP sync (11 August), but in more detail.

This is a poll, not a vote

There is no ZIP that approves making Zcash protocol decisions by vote or that specifies how to do so (and also no Zcash Governance Proposal or whatever would replace ZIPs for that purpose). The only ZIP that mentions coinholder polling, ZIP 1016, has this in its Non-requirements section:

Any changes to Zcash protocol governance, specifically what changes are made to consensus node software, are outside this proposal’s scope.

Anyone is free to carry out a poll. Calling it a “vote” misleads about its force.

Sprout

Q3 includes a new option relative to the previous poll: “Do not set a v4 transaction deprecation date.”

First, this has a wording error. ZIP 2003 does not propose to deprecate v4 transactions, it proposes to disallow them:

This proposal disallows v4 transactions. The v5 transaction format introduced in the NU5 network upgrade [ZIP 225] does not support Sprout, and so this will have the effect of disabling the ability to spend Sprout funds.

“Disable” (as in the question “When should v4 transactions be disabled?”) is a synonym; “deprecate” is not. This creates confusion about the meaning of the question and should be fixed (e.g. “Do not set a date to disable v4 transactions.”) if the option is retained at all.

However, I want to emphasize the absolute necessity of removing Sprout from the protocol. The reasons to do so have only become more urgent since ZIP 2003 was proposed and also since the last NU7 sentiment poll. For example, zcashd 6.12.0 fixed a critical consensus bug in which Sprout JoinSplit proofs were not being validated in blocks sent directly to a zcashd peer, due to a misimplemented caching optimization. This proves incontrovertibly that I was right about Sprout’s attack surface being an unacceptable risk.

zcashd is no more (and gone with it is the last wallet that supported Sprout), but zebrad also depends on Sprout code that frankly does not come up to our present standards. The risk of (potentially AI-assisted) bug-hunters finding flaws in it is real and significant. The Sprout turnstile is essential, but if there were a turnstile violation or other visible exploit of the Sprout protocol, that could have a severe effect on confidence — probably affecting ZEC’s fiat value by far more than the nominal amount in the Sprout pool (22,621 ZEC, or USD 11.3m @ USD 500/ZEC).

That interacts with the characterization of this polling as a “vote” rather than an advisory poll. I strongly believe that it would be neither fair nor right to expose all ZEC holders to unnecessary risk on the say-so of a few obstinate large holders.

Issues affecting the NSM questions

“Donated funds”

Funds are removed from circulation by the mechanism of ZIP 233. That wording was carefully chosen and is what should be used in all governance discussions. The wording of Q1 should be changed accordingly. Also, “fee reissuance” is simply incorrect. What is eventually reissued is only and exactly the amount removed from circulation. That must include at least 60% of fees in each block.

Potential NSM Reissuance Start Dates

Q2 currently has the following options:

  1. As soon as possible after NSM activation.
  2. After the fourth halving (around 2032).
  3. Abstain.

But it had already been agreed that the first oppportunity for the smoothing to activate would be the point at which the smoothed issuance curve, excluding reissuance, intersects the stepped one — roughly 2.23 years after the second halving, which coincided with NU6 on November 24, 2024. That is 188 days from now, roughly February 17, 2027 (the estimate has drifted by only ~2 days due to block time variation). Here is the proposed issuance graph, as specified in ZIP 234 and calculated by daira/nsm-simulator:

This is needed to satisfy at least three of the Requirements of ZIP 234, namely:

  1. […]
  2. Block subsidies approximate a continuous function.
  3. […]
  4. Decrease the short-term impact of the deployment of this ZIP on block subsidy recipients, and minimize the potential reputation risk to Zcash of changing the block subsidy amount.
  5. The immediate change in issuance when this mechanism activates should be minimal.

There would be significant negative ZEC monetary policy implications if the issuance were to abruptly increase at activation, which is why it was designed this way.

The next date after that at which the smoothed issuance curve intersects the stepped one is in February 2031 (not at the fourth halving which is expected in November 2032).

Taking into account the last item as well, Q2 should read:

Q2 (NSM Reissuance Start Date)

NSM has prior coinholder approval. This question concerns the start of reissuance of funds removed from circulation (which includes at least 60% of total fees).

When should NSM reissuance of funds removed from circulation begin?

  1. The next point at which the smoothed issuance curve intersects the stepped one (February 2027).
  2. The point at which those curves intersect one halving later (February 2031).
  3. Abstain.

Transaction format change caveat and consequences for NSM

The note about transaction format changes above needs to be visible above the question list. People usually read things sequentially, and a comment tucked away in this thread is not enough.

In particular, this note contradicts what the poll says in Q5, and the conflict must be fixed one way or another. Q5 currently says:

NU7 will include NSM fee recycling, […]

That can’t happen if NU7 doesn’t include a transaction format change. Also, no funds removed from circulation will be recycled anyway until February 2027 at the earliest, as I pointed out above. So, delete “NU7 will include NSM fee recycling” from Q5, because it won’t.

15 Likes

the winkles holding 5% of supply shape what happens i guess if 1 coin is one vote, but will be good to see on the app

It’s a goal to hold that, right? It’ll take years tbf.

1 Like

Hi @daira. Thank you for the feedback on the NSM questions.

You’re correct. We agreed to use the terms “remove from circulation” and “recycling into future block rewards”. Therefore, Q1 should be updated to read:

The component of the Network Sustainability Mechanism that removes ZEC from circulation is already approved. How that ZEC is recycled into future block rewards remains unresolved. In no case will the total supply of ZEC be affected.

Which approach do you support?

  1. Smooth issuance curve. Replace halvings with a gradual issuance curve. ZEC removed from circulation by the NSM is recycled into future block rewards along the same curve.

  2. Preserve halvings. Keep the existing halving schedule for new ZEC. ZEC removed from circulation by the NSM is eventually recycled into future block rewards.

  3. Do not include issuance smoothing in NU7. How ZEC removed from circulation by the NSM is recycled into future block rewards is left to future governance.

  4. Abstain.

This framing assumes the smoothing version of ZIP 234 is adopted, but Q1 is considering two different ZIP 234 implementations: one that smooths the issuance curve and one that preserves the existing halving schedule. Q2 therefore needs to account for both possibilities. If halvings are preserved, the curve-intersection dates aren’t relevant. So I think the choices should be framed around the earliest applicable recycling date under whichever implementation is selected in Q1: the next intersection point in February 2027 if issuance smoothing is adopted, or as soon as possible after activation if halvings are preserved.

I think Q2 should be updated to read:

Q2 (NSM Reissuance Start Date)

NSM has prior coinholder approval. This question concerns when ZEC removed from circulation by the NSM should begin to be recycled into future block rewards. The applicable dates depend on the issuance approach selected in Q1.

When should NSM recycling into future block rewards begin?

  1. At the earliest applicable date under the approach selected in Q1: at the next point where the smoothed issuance curve intersects the existing stepped issuance curve (approximately February 2027) if issuance smoothing is adopted, or as soon as possible after NSM activation if halvings are preserved.

  2. At the later applicable date: at the following intersection of the smoothed and stepped issuance curves (approximately February 2031) if issuance smoothing is adopted, or after the next halving if halvings are preserved.

  3. Abstain.

Agreed on the transaction format change point. If NU7 does not include the ZIP 233 transaction format changes needed to remove ZEC from circulation, then Q5 obviously shouldn’t say that NU7 will include NSM fee recycling.

There’s a separate question around ZIP 234, though. Depending on the outcome of Q1, it may still make sense for NU7 to include implementation of the mechanism for recycling ZEC removed from circulation into future block rewards, even if the actual recycling does not begin until later. So I think either Q5 should mention ZIP 234 inclusion depending on the result of Q1, or we should remove any mention of the NSM from the question and refer to the poll results more generally. I think the latter is the better option.

So Q5 should be updated to say:

Q5 (NU7 Scope and Readiness)

NU7 will be consistent with the results of this poll, assuming each applicable feature is implemented by September 30th.

How should features that are not ready by the deadline be handled?

  1. Ship NU7 as soon as possible, removing any feature that is not implemented by the September 30th deadline.

  2. Delay NU7 until every applicable feature approved in this poll is deemed complete.

  3. I do not support this NU7 plan.

  4. Abstain.

7 Likes

It is frustrating to me to see polling questions about protocol options that haven’t been specified. This option could easily have been specified. To my knowledge no-one asked any of the core protocol engineers for help with that.

In any case, how is someone supposed to answer Q2 if its meaning depends on the answer to Q1, and they don’t know how polling on Q1 will come out? This is frankly just replicating the kind of mistakes that were made in setting the questions for the last sentiment poll, which gave uninterpretable answers.

I suggest something like this instead, so that at least people have the option to give a concrete date as their answer without it being reinterpreted unpredictably:

Q2 (NSM Reissuance Start Date)

NSM has prior coinholder approval. This question concerns the start of reissuance of funds removed from circulation (which includes at least 60% of total fees).

When should NSM reissuance of funds removed from circulation begin?

  1. As soon as possible. If the outcome of Q1 is smoothed issuance, this will be February 2027; otherwise it may be sooner.
  2. February 2027, regardless of the outcome of Q1.
  3. February 2031, regardless of the outcome of Q1.
  4. Abstain.

To explain the motivation for the February 2027 and February 2031 dates, these are the first and second points at which the smoothed issuance curve intersects the stepped curve, if smoothed issuance were to be adopted. The former date is what is currently specified in ZIP 234.

Note that there’s no particular reason why the introduction of reissuance needs to be at a halving if stepped issuance is retained. Choosing the same date as would have been chosen for smoothed issuance is entirely harmless.

1 Like

Why? Under the generally accepted as-if rule for any kind of protocol, implementors have no obligation to implement a thing that won’t result in any observable difference in behaviour. And it’s a poll, so it’s not binding them anyway.

In any case, the proposed wording is vague and misleading because it doesn’t say that the NSM is not an applicable feature. It should say precisely what the applicable features are, and that NSM is not one.

Sprout to Sapling txids still happening post zcashd, to me this is a no brainer reason to seal sprout in the protocol before damage is done. Orchard proves it can happen quickly, the hard part is getting all the anon sprout user(s) onboard. I can’t think of a good reason to keep funds there unless they found an exploit and the goal is to never come forward.

Is the community willing to risk that? Food for thought as coinholders vote.

I’ve updated the original post based on the feedback from @daira and @aquietinvestor above. Summary of the changes:

Q1 now uses the correct NSM terminology: ZEC is “removed from circulation” and later “recycled into future block rewards,” rather than “fee-burning” and “reissuance.” The options are otherwise unchanged.

Q2 was rewritten using @daira’s suggested framing, so that each option means the same thing regardless of how Q1 turns out:

  1. As soon as possible. If the outcome of Q1 is smoothed issuance, this will be February 2027; otherwise it may be sooner.
  2. February 2027, regardless of the outcome of Q1.
  3. February 2031, regardless of the outcome of Q1.
  4. Abstain.

Q3 now says “disable” instead of “deprecate,” since ZIP 2003 disallows v4 transactions rather than deprecating them.

Q5 no longer states that NU7 will include NSM fee recycling, and now refers to “applicable” features.

A new Transaction Format Changes section below the questions specifies what those are:

NU7 will not include transaction format changes, and proposals that would involve them have been removed from this poll. In particular, the NSM component that removes ZEC from circulation (ZIP 233) will not be part of NU7 and is not an applicable feature in Q5. The applicable features are the issuance approach selected in Q1 and Q2, disabling v4 transactions (Q3), and faster block times (Q4).

Any additional feedback welcome as we’re about 10 days out now.

8 Likes

Hi Sean, Daira-Emma, Jason, and everyone. Thank you so much for organizing this!

What I most want is to attract the largest number and variety of people to come to trust Zcash over the coming years.

In my opinion these answers will achieve that goal the most:

Q1: Smooth issuance (ZIP-234) or halvings-plus-smoothed-re-issuance?

A1: Smooth issuance (ZIP-234), because it is easier to explain verbally, visually, and mathematically. Something being easy to understand increases trust.

Verbally:

Verbally, you can explain ZIP-234 issuance like this:

“The amount issued is a fixed percentage of the gap between the current circulating supply and the 21 million maximum. It issues 16% of the current gap every year, which works out to shrinking the gap by 50% every four years. (If you’re familiar with the previous ‘halving’ schedule, this is the same as that, but smoothed out.)”

To verbally explain the halvings-plus-smooth-reissuance…well, how to explain it depends on how much your listeners already understand about halvings and ZIP-233 Zcash-burning. If you’re trying to draw in the widest audience of outsiders to trust Zcash, maybe you should not assume they already understand either of those two things. :slight_smile:

Visually:

Here is what Zcash’s issuance looks like under the “halvings-plus-smoothed-re-issuance” mechanism in a certain possible future scenario:

(source: Zcash Supply & Issuance)

I’m not saying this particular scenario is necessarily going to happen. It might, or it might not. But in order for people to have confidence in Zcash issuance, they should feel like they understand what would happen to issuance in different possible future scenarios. You can play with the settings on that web page to explore what it looks like under other possible futures.

Here is the graph for smooth issuance (ZIP-234) in the same scenario:

(source: Zcash Supply & Issuance)

I encourage you to play with the interactive settings on that page and tell me what you think.

Mathematically:

Smoothed issuance is easier to understand for mathematicians and computer programmers (and AIs). The entire consensus rule is one line of math:

ZEC issued in each block = (21,000,000 − current supply) / 2,423,728

“2,423,728” is the number that you divide the gap by in each block, in order to issue half of the gap every four years.

Here’s the Javascript source code that implements ZIP-234 on the web page (you can edit the Javascript code on the web page yourself too if you want):

return (MAX_SUPPLY - s) / 2_423_728n;

That’s it. You now have a complete and correct mathematical understanding of the smoothed-issuance consensus rules.

Here’s the Javascript source code that implements halvings-plus-smoothed-re-issuance:

let deficit = 15_750_000n*ZEC; let i = 0n; let e = (h - HALVING_2_HEIGHT) / BLOCKS_PER_HALVING; for(; i < e; i++) deficit += (156_250_000n >> i) * BLOCKS_PER_HALVING; deficit += (156_250_000n >> e) * ((h - HALVING_2_HEIGHT) % BLOCKS_PER_HALVING + 1n); deficit -= s; return (156_250_000n >> e) + (deficit > 0n ? deficit / 2_423_728n : 0n);

Frankly, I had an AI write that and a different AI double-check it, and cross-check it against the informal verbal description of the proposal on this forum at the time, but I couldn’t really explain exactly why the code is like that or if there is a way to make it simpler and do the same thing.

I do know there’s another way to write the code, which is to add another consensus rule that tracks the total amount of burned ZEC separately, in addition to the current consensus rules that track the circulating supply. That would make this function simpler, but at the cost of making other parts of the consensus rules more complicated, and raising questions like “How do we know those two numbers the consensus rules are tracking are consistent with each other?”. It’s totally doable, either with the stateless way (one big function, like the function above), or the stateful way (another variable in the consensus rules and a simpler function), but either way it is going to be more complex than the ZIP-234 version, and harder to explain to non-programmers.

In my opinion what earns trust from the most people is something being easy to understand, so that they can be confident when they talk about it with their friends.

Q2 (NSM Reissuance Start Date)

A2: As soon as is safely possible. A change to issuance that happened in the past and has proven itself increases trust, and the longer in the past it happened, the greater the trust. This is the Lindy Effect. A change to issuance that is planned for the future has the opposite effect: it invites skepticism.

In my humble opinion, doing the simple thing as soon as possible in order to earn more trust is more important than the other considerations that people have raised, like 1. The short-term effect on the issuance rate right after activation, 2. How much it resembles Bitcoin, and 3. Whether we save up more issuance for future use by delaying activation. Those are all valid ideas, but IMHO less valuable than the goal of gaining trust from the largest number of people over the next few years.

So that’s how I would like to vote on these questions, inasmuch as the questions allow me to.

That said, I think any of the possible outcomes here are good for Zcash, and better than the status quo–the status quo of Zcash and also the status quo over in Bitcoin land. I’m just glad we’re getting back to our tradition of responsible innovation!

[EDITED] I edited this to remove a whole topic that I advocated for in the initial post (re-issuance of burned ZEC before February 2027). I’m pretty sure just leaving that whole topic out makes this post more readable and hopefully more acceptable to more people.

11 Likes

刚听到平滑发行这个提案的时候,我是很惊喜的。感觉终于干了一件漂亮,清晰,整洁的优化方案。 但是看了大家的评论之后,我也意识到了反对意见确实有不错的理由。 显然,一条平滑的曲线对于工程师,研究人员来说是非常漂亮的事情。 但这只是原理,绝大部分人不是很在于原理,而是在乎实际使用价值。 是原理的结果。 显然,频繁变动的单次金额,无论是对于沟通、交流,还是统计,分析,都是非常不友好的。 当我们讨论一次的奖励时, 哪怕他是1.5625这样的非整数,但是我们四年都围绕这个数字,这个数字就不是陌生的,难以理解和接受的数字。 沟通和交流,统计和分析都没有障碍。 但如果他随时变化,这个沟通,交流始终是困难的,统计和分析也是有很多的不利之处的。 另外,我们需要认识到一点,与技术无关,很现实的一点,就是对于持有人来说,定期的减半是一个难得的利好。这是最大的利益相关,没有这个利好,价值很难维持或提升。某种程度是也是加密货币生存的根基。 所以,我觉得投票选项应该增加一个选项:即保留定期减少,但时间可以不用4年那么长。 如对应4年减半的规模, 改成每年减 15.91%。 这样子我们不仅能保留利好,还能更频繁的触发利好, 同时避免的4年时间过长,减半的冲击过大的困扰。

1 Like

你好,欢迎来到论坛!这是我在模拟器中对你的提案所做的实现:

请注意,ZEC 的总供应量会随着时间推移而下降。这是由销毁事件造成的,也就是图中的红色胶囊形控件。点击它们即可展开查看详情。

1 Like

非常清晰的模拟图。

我们能看到 default, BYOI 最终走向了0。 不过这是由于只有 burn 而没有 reissuance 导致。 由图可以看出, burn 必然需要伴随着 reissuance, 这俩天然需要绑定在一起。 而BYOI 实际上比default更平滑,最终效果一致。 但是 BYOI 方案 显然能在 coinholder 关心的兴趣点上,提供价值。 同时BYOI也确实达到了比default更平滑的程度, 这对于加强预期,减少市场冲击来说更佳。

Zooko and others:

[Edit: I wrote this while also irritated by other unrelated things. I apologize to Zooko; it was unnecessarily tendentious, In particular, I didn’t make it clear what the actual —not entirely obvious— problem was that made his (now withdrawn) proposal conflict with the current specification of ZIP 234. It’s because the ZIP has no free parameters; the value 4126 for BLOCK_SUBSIDY_FRACTION is forced in order to match (within \pm 0.002\%) 4-year issuance, and then the per-block issuance necessarily jumps up if it activates before the specified block height. Moving the activation height while retaining the intersection would move the whole curve forward or backward in time.

Less importantly, I hadn’t checked the Owners of ZIP 234, which include Zooko. So obviously, acting in concert with the Owners of a ZIP wouldn’t be an issue here, although it would be in general.]


Can I ask that when people have a suggested change to a proposed Zcash specification —especially a consensus specification— they concretely ask for that change, either by filing a ZIPs PR or by making a specific concrete request of someone who can help. Ideally that should be done in concert with the Owners of the ZIP, and as soon as possible, not on the eve of a governance vote when the wording of a question about that change has already been set based on its current proposal.

— A frustrated and deeply overworked protocol engineer.

5 Likes

我fork了模拟器的分支并做一点点的改动,即将模拟器采样数据的一个字段:上次发行的数量 (lastIssZat),暴露给发行函数(default, zip234, nsmalt, byoi)。

这样子公式中可以出了h和s外,还可以用 lastIssZat。

这个字段最典型的用法就是在一个周期内(一年或四年)固定发行量。 机制就是在减半(减小)时,重新计算发行量。 在任何非减半(减小)的位置,直接返回上一个区块的发行量就行。(return lastIssZat).

借助这个字段,我将BYOI改成在NSMalt的基础上,每次发行量固定的公式。

在线查看在这里: Zcash Supply & Issuance

1 Like

RE: our conversation in the Arborist call. I’ve submitted a PR for the halving-preserving version of ZIP 234 here: [draft] halving-preserving issuance by judah-caruso · Pull Request #1354 · zcash/zips · GitHub

I wrote the alternative as a separate draft ZIP (per ZIP 0’s process for competing proposals) so the two can be reviewed side-by-side, without mixing terminology or concepts between them.

1 Like

We’ve chosen a snapshot height for the vote, 3459350, which should occur (approximately) on August 24 at 19:00 UTC, as planned. If you have spendable funds in Ironwood at that height, your ZEC is eligible even if you move your funds after the snapshot.

8 Likes