Polling ZCAP on NU7 priorities

[ZcashFoundation]

A number of consensus and protocol changes have been been proposed for NU7, and there are concerns that trying to introduce too many changes in a single network upgrade may be risky (in terms of complexity) and/or delay NU7.

Therefore, we plan to include several questions in the upcoming ZCAP poll intended to solicit ZCAP members’ input on which features should be prioritized for NU7.

The purpose of these questions is to inform any decisions regarding which features should be prioritized if the core engineers judge that some features should be postponed to a future NU, in order to streamline, simplify or de-risk NU7.

The poll description can be found here. Please note that the length of this description is limited, and the current draft is at that limit (i.e. no further information can be added without removing some information).

The draft questions can be found here.

We plan to open the poll by the end of this week, so please provide any feedback ASAP.

[nuttycom]

Minor suggestion: instead of

3. Zcash Shielded Assets will allow anyone to issue and transact digital assets on the Zcash blockchain. Please indicate how you believe this feature should be prioritized. (approval, select between 0 and 1 answers, result type absolute.)

clarify as:

3. Zcash Shielded Assets will allow anyone to issue and transact with digital assets other than ZEC on the Zcash blockchain. Please indicate how you believe this feature should be prioritized. (approval, select between 0 and 1 answers, result type absolute.)

Also, a nit about the following:

9. ZIP 2003 (Disallow version 4 transactions) will mean that it would no longer be possible to spend ZEC held in the Sprout shielded pool. (approval, select between 0 and 1 answers, result type absolute.)

With the deprecation of the zcashd wallet, it will no longer be possible to spend ZEC held in the Sprout shielded pool irrespective of ZIP 2003; there will simply be no code that enables it that is usable with NU7 unless someone decides to go write some.

[daira]

My comments:

• The poll should link to the ZIP Editors’ assessment of the proposed ZIPs.
• Question 4 should say “burn part of the ZSA issuance fees”.
• It should be made clear that the change described in question 4 depends on including ZIP 233, as do ZIPs 234 and 235.
• It should be made clear that ZIP 234 is not the only possible way to reintroduce funds burnt by ZIP 233, and that it would be coherent to activate ZIPs 233 and 234 (or an alternative to 234) without ever activating ZIP 235. (The current description incorrectly implies that accepting some of the NSM ZIPs will inevitably lead to accepting the others eventually.)
• Question 9 should mention the motivation of ZIP 2003: reducing the attack surface and complexity of the protocol and simplifying transaction validation.

I also agree with @nuttycom’s comments.

[Dodger]

@nuttycom

clarify as:

3. Zcash Shielded Assets will allow anyone to issue and transact with digital assets other than ZEC on the Zcash blockchain. Please indicate how you believe this feature should be prioritized. (approval, select between 0 and 1 answers, result type absolute.)

Question amended.

@nuttycom

With the deprecation of the zcashd wallet, it will no longer be possible to spend ZEC held in the Sprout shielded pool irrespective of ZIP 2003; there will simply be no code that enables it that is usable with NU7 unless someone decides to go write some.

But (absent ZIP 2003) it will still be possible for someone to write some code that enables the creation of V4 transactions, correct?

@daira

The poll should link to the ZIP Editors’ assessment of the proposed ZIPs.

There is a link in the sentence “A number of consensus and protocol changes have been been proposed for NU7…”

@daira

Question 4 should say “burn part of the ZSA issuance fees”.

I’m strictly distinguishing between the issuance fee versus (to quote @nuttycom), the fee for the Orchard actions in the transaction that provide the funds to pay for the issuance fees will still pay normal transfer fees.

@daira

It should be made clear that the change described in question 4 depends on including ZIP 233, as do ZIPs 234 and 235.

Questions amended.

@daira

It should be made clear that ZIP 234 is not the only possible way to reintroduce funds burnt by ZIP 233, and that it would be coherent to activate ZIPs 233 and 234 (or an alternative to 234) without ever activating ZIP 235. (The current description incorrectly implies that accepting some of the NSM ZIPs will inevitably lead to accepting the others eventually.)

Can you suggest a relevant text change(s) for this, bearing in mind that the character “budget” for the poll description is 4,000 (including HTML tags), and the current character count is 3,902?

@daira

Question 9 should mention the motivation of ZIP 2003: reducing the attack surface and complexity of the protocol and simplifying transaction validation.

Question amended.

[aquietinvestor]

@ZcashFoundation

The poll description can be found here.

In the poll description, the link to Shielded Labs where it says, “more information can be found here” is incorrect. It links to:

https://vote.heliosvoting.org/helios/elections/70bf34cc-bc94-11ef-89b1-82d7c612bc21/”https://shieldedlabs.net/nsm/

But it should link to:

NSM - Shielded Labs

The same link error is present in the ZCG candidate profiles.

@ZcashFoundation

The draft questions can be found here.

I will follow up on the draft questions later today.

[Dodger]

The links have been fixed.

[daira]

@Dodger

There is a link in the sentence “A number of consensus and protocol changes have been been proposed for NU7…”

To me, that anchor text isn’t sufficient to motivate why you might want to read it. I suggest being more explicit: something like "The ZIP Editors, with input from node implementors, have published their viability assessment of the consensus changes proposed for NU7.”

[daira]

@Dodger

@daira

Question 4 should say “burn part of the ZSA issuance fees”.

I’m strictly distinguishing between the issuance fee versus (to quote @nuttycom), the fee for the Orchard actions in the transaction that provide the funds to pay for the issuance fees will still pay normal transfer fees.

I meant what I wrote!

I think that every component of the transaction should have a fee to the miner (block producer), in order to incentivize the (small) amount of effort on the part of the block producer to include it. The issuance bundle is a component of the transaction, so ZIP 317 will need to be modified to include it. This is not covered by the fees on OrchardZSA actions (and if it were then the poll question would still be overspecifying a technical detail, IMHO).

“… burn most of the ZSA issuance fees …” would also be fine.

[daira]

@Dodger

@daira

It should be made clear that ZIP 234 is not the only possible way to reintroduce funds burnt by ZIP 233, and that it would be coherent to activate ZIPs 233 and 234 (or an alternative to 234) without ever activating ZIP 235. (The current description incorrectly implies that accepting some of the NSM ZIPs will inevitably lead to accepting the others eventually.)

Can you suggest a relevant text change(s) for this […]

Replace that section of the poll description with:

Network Sustainability Mechanism (NSM)

Shielded Labs has proposed three ZIPs for NU7 to specify parts of the NSM, which could be deployed selectively or in stages:

• ZIP 233 would enable voluntary burning of ZEC to remove it from circulation.
• ZIP 234 would smooth the issuance curve, and reintroduce burnt coins into circulation in a predictable manner as part of future block rewards.
• ZIP 235 would require burning at least 60% of transaction fees.

ZIPs 234 and 235 depend on ZIP 233. ZIP 233 assumes that a way to reintroduce burnt funds will be deployed at some point; ZIP 234 is not the only possible way to do so. The ZIP Editors’ viability assessment raised questions over inclusion of ZIP 235. The NSM has also been discussed on the forum.

[aquietinvestor]

Comments on Question 5 (ZIP 233)

ZIP 233 (Network Security Mechanism: Burning) will enable the voluntary burning of ZEC to remove it from circulation, and be reissued as part of future block rewards.

• The second part of the question should be deleted as ZIP 233 does not include ZEC being reissued into future block rewards. You might be able to rephrase it as “…with the intention for ZEC to be reissued as part of future block rewards.”

• The congruity between ZIP 2002 and ZIP 233 is missing from the poll. In fact, none of the questions address ZIP 2002, and this question doesn’t address tradeoffs between making multiple transaction format changes.

• ZIP 233 is consistent with other transaction format changes being made as part of ZIP 2002 that are not mentioned in this poll, so not including ZIP 233 is potentially disruptive.

• It’s best to bundle ZIP 233 with the other transaction format changes, which is efficient from a development perspective.

• Our understanding is an engineering design strategy of ZIP 2002 is to make as many things as possible explicit (instead of implicit) in the transaction format. Doing ZIP 2002 without ZIP 233 means the attempt to make transactions more explicit is less complete.

• The factors mentioned above are important for the community to consider when determining the priority of ZIP 233.

I will follow up later this afternoon with comments on Question 6 (ZIP 234) and Question 7 (ZIP 235).

[Dodger]

@daira

I think that every component of the transaction should have a fee to the miner (block producer), in order to incentivize the (small) amount of effort on the part of the block producer to include it. The issuance bundle is a component of the transaction, so ZIP 317 will need to be modified to include it. This is not covered by the fees on OrchardZSA actions (and if it were then the poll question would still be overspecifying a technical detail, IMHO).

Is this proposal different to what @nuttycom proposed?

Is this proposal written up or specified anywhere?

[Dodger]

@daira

Replace that section of the poll description with:

Network Sustainability Mechanism (NSM)

Shielded Labs has proposed three ZIPs for NU7 to specify parts of the NSM, which could be deployed selectively or in stages:

• ZIP 233 would enable voluntary burning of ZEC to remove it from circulation.
• ZIP 234 would smooth the issuance curve, and reintroduce burnt coins into circulation in a predictable manner as part of future block rewards.
• ZIP 235 would require burning at least 60% of transaction fees.

ZIPs 234 and 235 depend on ZIP 233. ZIP 233 assumes that a way to reintroduce burnt funds will be deployed at some point; ZIP 234 is not the only possible way to do so. The ZIP Editors’ viability assessment raised questions over inclusion of ZIP 235. The NSM has also been discussed on the forum.

Done (with minor changes to fit within the character budget).

[zooko]

I’m trying to think about what we developers–including Shielded Labs, Qedit and the Zebra maintainers–would do in response to different answers to these questions. The questions in the current draft poll are about prioritisation – do the ZCAP voters value X more highly or Y more highly. The actionable implication from answers such questions would be: If we can only do some things, do the things that got the highest prioritisation by ZCAP voters.

However, I don’t think that’s actually the situation with the Network Sustainability Mechanism ZIPs. The NSM ZIPs are already implemented and submitted as Pull Requests to Zebra.

At a high level, I think ZIP 233 (explicit burning) and ZIP 235 (burn part of transaction fees) are not alternative to ZSAs, such that we can only do one or the other, and they may actually be complementary to ZSAs.

Here are a couple of technical details about why I’m thinking this:

There are six ZIPs that interact here: ZIP 226, 227, 230 (ZSAs), 2002 (explicit fees), and 233 and 235 (NSM).

• ZIP 230 is there to accomplish two things: incentivise miners to include ZSA issuance transactions, and deter “spam” ZSA issuance. Without ZIP 235, non-miners are deterred from creating “spam” ZSA issuance, but miners are not deterred. With ZIP 235, both non-miners and miners are deterred.
• ZIP 2002 is there to make transaction contents explicit instead of implicit. Without ZIP 233, the current implicit mechanism miners can use to burn ZEC is eliminated but no explicit mechanism replaces it. (This leaves miners and spenders with the option of burning ZEC in a different implicit mechanism, such as by sending ZEC to an address made up of all zero bits, or something.) With ZIP 235, the eliminated implicit mechanism is replaced with an explicit mechanism for miners or spenders to burn ZEC.

So both ZIP 230 and 2002 are somewhat incomplete implementations of their goals, and ZIP 230 and 235 make them more complete.

In the bigger strategic picture–at a higher level than ZIPs–I think merging the Network Sustainability Mechanism now may encourage potential ZSA issuers and users to go ahead and start using ZSAs for long-term projects.

It’s like, you want to move your business into our nice new commercial district now, and we’ll decide in a year or two how we’re going to charge you rent – or even if we’re going to charge you rent? Or you want to see the rent structure (fees) now, before you move your business here, and you get a nice guarantee that we can’t change the rent structure out from under you without a coordinated and lengthy governance process that you will also be a part of?

Also, if your business is a long-term investment for you, then you might be more willing to move into a structure in which you pay rent (fees) versus a structure that is free to you, because then you know there is funding and incentive for the neighborhood to be maintained in a way that includes your business’s needs. If it’s free to you then maybe the neighborhood won’t be maintained, or whoever is paying for its maintenance will prioritize maintenance and upgrades that serve their needs more than yours.

To complete the analogy: Without the Network Sustainability Mechanism, the person who takes your rent is the miner, who may or may not have at heart your interests or the interests of the whole Zcash ecosystem. With the Network Sustainability Mechanism, it is 40% to the miner and 60% to the whole Zcash ecosystem.

So both at the low level of software engineering, and at the high level of attracting long-term users, I think NSM is largely complementary to ZSAs, and it would be a mistake to suggest to ZCAP voters that they ought to pick one or the other.

So what to do with this ZCAP poll?

To make this draft poll more consistent, we could add a question about ZIP 2002 (Explicit Fees) – should ZIP 2002 be prioritised high, medium, low, or not? And we could make it more consistent by adding this text from the current “Memo Bundles” question to the questions about ZIPs 2002 and 233, which I think it is equally true of: “If this change is not included in NU7, it will likely not be possible to implement it until 2026 at the earliest (to minimize disruption caused by transaction format changes).”

But at a high level this would just make it even more confusing for ZCAP voters, and mislead them into thinking that the relevant question is how to prioritise among these ZIPs, which I don’t think is really the actionable question. Picking and choosing some of these ZIPs to merge now and others to put off merging until a future Network Upgrade is probably not going to substantially accelerate NU7. In fact, poring over poll results from ZCAP and from other polls about whether each ZIP is prioritise high, medium, low, or none would probably delay NU7.

[Dodger]

@aquietinvestor

The second part of the question should be deleted as ZIP 233 does not include ZEC being reissued into future block rewards. You might be able to rephrase it as “…with the intention for ZEC to be reissued as part of future block rewards.”

Question amended.

@aquietinvestor

• The congruity between ZIP 230 and ZIP 233 is missing from the poll. In fact, none of the questions address ZIP 230, and this question doesn’t address tradeoffs between making multiple transaction format changes.
• ZIP 233 is consistent with other transaction format changes being made as part of ZIP 230 that are not mentioned in this poll, so not including ZIP 233 is potentially disruptive.
• It’s best to bundle ZIP 233 with the other transaction format changes, which is efficient from a development perspective.
• Our understanding is an engineering design strategy of ZIP 230 is to make as many things as possible explicit (instead of implicit) in the transaction format. Doing ZIP 230 without ZIP 233 means the attempt to make transactions more explicit is less complete.
• The factors mentioned above are important for the community to consider when determining the priority of ZIP 233.

As is likely clear from the conversation above, there is a limit of 4,000 characters on the poll description (and we have now used up all 4,000 characters). Therefore, I suggest including this information in the shieldedlabs.net/nsm/ page.

It’s also important to note that the purpose of this poll is to solicit input from the Zcash community on which changes they think should be prioritized if the core engineers advise that some features should be postponed to a future NU, in order to streamline or simplify NU7.

Assuming the community is in favour of implementing ZIP 233 (and by “in favour”, I mean that a majority of respondents don’t vote for the “I do not support enabling ZIP 233.” option), if the core engineers were to decide (having taken the community’s feedback into account when making that decision) that it would be best to postpone ZIP 233 until a future NU, I would expect that they would still recommend including the burnAmount field in the v6 transaction format so that ZIP 233 could be fully implemented in a future NU without requiring another transaction format change. (And I’d invite @arya2, @conradoplg, @daira, @Marek, @nuttycom, @oxarbitrage, and @str4d to chime in here).

In other words, while this poll can inform the engineers what the community wants to see prioritized, such input shouldn’t override the engineers’ judgement when it comes to implementation details.

[aquietinvestor]

@Dodger

As is likely clear from the conversation above, there is a limit of 4,000 characters on the poll description (and we have now used up all 4,000 characters). Therefore, I suggest including this information in the shieldedlabs.net/nsm/ page.

Understood. Yes, you’ve mentioned the 4,000-character limit a few times, and I ran into the same issue when conducting Helios polls for the NSM last month. This is an important poll, so I’d prefer to focus on crafting clear and thorough descriptions and questions rather than trying to condense everything into a limited space. Additionally, ZCAP participants are being asked to consider several topics in this poll: seven ZCG candidates, ZCG compensation, and the prioritization of key network upgrade candidates. Would it make sense to focus this poll specifically on ZCG and address NU7 with a separate ZCAP poll in early January? It seemed from the Arborist Call that you were open to that idea:

[01:53:45.57] - Jason McGee

Is this going to be part of the ZCG poll or do we have time to work these details out?

[01:53:53.51] - Dodger

I think we should try to get it into the ZCG poll.

[01:53:57.58] - Daira Emma

What’s the timeline for the ZCG poll?

[01:54:01.27] - Dodger

Mid next week. So basically, approximately a week from now.

[01:54:05.16] - Daira Emma

Okay. I mean, I can make some suggestions before that.

[01:54:11.07] - Dodger

We can always push it to next year.

[Dodger]

@aquietinvestor

Would it make sense to focus this poll specifically on ZCG and address NU7 with a separate ZCAP poll in early January? It seemed from the Arborist Call that you were open to that idea:

That’s right. It’s clear from past polls that running polls too frequently can result in “poll fatigue” but, in this case, I think it’s reasonable to run another poll in mid- to late-January.

[daira]

Neither @nuttycom’s suggestion or mine are written up, but that is within the scope of the ZIP Editors’ capacity to make changes to ZIP 227 (in consultation with Qedit) and ZIP 317. The only choices to be made here are the amount of the fee per issuance action, and the amount of that fee that must be burnt. @nuttycom’s suggestion was the special case where these are equal.

[arya2]

I would expect that they would still recommend including the burnAmount field in the v6 transaction format so that ZIP 233 could be fully implemented in a future NU without requiring another transaction format change.

I would certainly recommend that if there’s support for ZIP 233 and there are technical difficulties with deploying it as part of NU7, though I feel it’s unlikely that there will be any technical difficulties with deploying it as part of NU7.

[daira]

@zooko

ZIP 2002 is there to make transaction contents explicit instead of implicit. Without ZIP 233, the current implicit mechanism miners can use to burn ZEC is eliminated but no explicit mechanism replaces it.

That’s not correct. ZIP 236 removed the implicit mechanism that miners could use to burn ZEC, and that activated in NU6.