There are two significant reasons to include the NSM (at least ZIP 233) now:
I think we need to be careful about saying anything is trivial. Even with âtrivialâ code changes (which are not all iiuc), everything must be tested, audited, remediated if necessary and rolled out.
And the rollout and ecosystem impact is not trivial. Miners need to be engaged and their models refactored. Content must be updated, and until third parties need to update their information and reporting, it will cause confusion and distraction.
Every change we make to the L1 is significant. Changing the issuance curve is a big deal. Why add this complexity right now when the near term benefit is unclear. Cutting unnecessary scope to ensure the delivery of high impact capabilities is generally a good idea.
I think its important we believe what the subject experts express! Iâm simply reading their opinions.
Iâm more optimistic, and I think your fears might be unfounded.
Who decided on burning issuance fees? I donât recall seeing a proposal from Qedit.
To my knowledge, changing the issuance doesnât have clear community consensus. It may get there, but it doesnât seem wise to couple the requirements of these two less than two weeks before the ZIP editors are calling for a decision.
For the record, my account has not been hacked. 
I agree.
I agree (c.f. NU5).
I agree.
Core engineers have expressed concerns (both in public and privately) about the complexity budget for NU7.
The more complexity we jam into a network upgrade, the greater the risk of delays and/or that something will go wrong when it activates.
This isnât about whether NSM is a good idea or not (and, for the record, I have no strong feelings either way). Itâs about respecting the communityâs priorities, and whether the people who will be responsible for fixing the Zcash blockchain if it breaks (or, God forbid, halts) are comfortable with the level of complexity and the risk it entails.
As much as I want to believe you, Iâd prefer for folks to speak for themselves. This isnât some taboo topic, lets hear it directly and verify.
We have learned. Have more confidence in our teams.
This was a recommendation from the ZIP Editors. The rationale is that burning fees for issuance is a desirable mechanism that compensates the entire network for the costs imposed, as opposed to compensating a single miner. The primary thing Iâm personally worried about here is miners using âselfish miningâ techniques in order to attempt to claim larger-than-normal issuance fees.
One thing that I think is new and important in this network upgrade is that there are four separate organizations producing new and meaningful changes to the consensus layer. The NSM integration is primarily the responsibility of Shielded Labs, and while ECC and ZF engineers will be involved in reviewing and integrating that code, this is a major step in terms of the distribution of responsibility and in terms of improving our processes for the inclusion of new consensus features.
Eliminating NSM components would mean that Shielded Labs has less to do this upgrade; my personal preference would be for them to be fully engaged in this upgrade, including with making the necessary changes to the librustzcash wallet support code. I think that as there will be a burden imposed on ZF and ECC engineers for review, that parties like Shielded Labs should also take on some review burden for the other new consensus features; by distributing the load, we can actually make the entire network upgrade process work better.
Couldnât agree more. Accelerate. Having leaders who are confident in our teams is critical at a time like this.
id like to see hybrid PoS being more important right now than NSM.
so if they could delay NSM ot NU8 maybe and focus instead on working on PoS instead now?
not sure if that would make sense for Shielded Labs
There is no chance of implementing any part of the PoS transition in NU7.
Shielded Labs contracted Eiger to develop and implement the NSM. Eiger is not involved in the Crosslink project, so the resources and budgets for these two initiatives are separate.
In my opinion the game-changing potential of ZSAs is bottlenecked by the lack of a bridge to Zcash, and delays are thus not that important. I think most people who look forward to ZSAs are looking forward the most to a shielded stablecoin. I donât think we will get an issuer to issue directly on Zcash, so we will probably need to bridge it. The bridge closest to completion is the Red Bridge to Avalanche, but it isnât designed with ZSAs in mind. Maybe @mrkit2u can comment on whether it is feasible to have a bridge that supports bridging stablecoins to Zcash in time for NU7.
Itâs no coincidence that these ZSAs and NSM are complementary: it was during the era when ECC was encouraging more economic analysis of ZSAs when I first had the idea for (whatâs now called) NSM, and so ZSAs have always been on my mind as a likely major contributor to the âNSM flywheelâ.
IMO, ZSA + NSM has a fee model that clearly benefits ZEC holders and network sustainability to some degree, and the main question is how much. For potential ZSA users (issuers and âconsumersâ) I think this is a compelling story: ânot only does the network have the features you need, but the economic incentive system is directly tied to your use case, so you can be more confident in long term support.â
By contrast, IMO (again quite biased), without ZSA without NSM is a less clear story: âhereâs a network that has the features you want; thereâs not a clear economic linkage between your use and the networkâs operation, but thereâs a new fee model that might come out in the next update.â More cautious, judicious, or financially constrained ventures may want to wait for a âsettledâ fee model before committing.
So this is an argument that the bundle increases likelihood of new use case adoption and provides a compelling narrative for Zcashâs future potential in the multi-asset shielded space.
Now to jump into @nuttycom 's specifics:
IIUC this means modifying ZIP-227 Issuance of Zcash Shielded Assets to burn a portion of fees, correct?
I personally think this is big. If ZSAs are to be a major adoption driver, then this quoted change also makes that adoption directly drive Zcashâs sustainability. To be clear there are two different adoption drivers in this combination: 1. direct economic incentives, and 2. a compelling story about how those direct economic incentives mean Zcash continues to improve its long term fitness.
I also want to compare the potential of burning ZSA issuance fees with the claim in Zip Editors' NU7 ZIP Viability Assessment that low fees today mean that ZIP-235 Burn 60% of Transaction Fees is less compelling: that ZIP is more compelling precisely because the community is making a bet on ZSAs. If ZSAs increase usage, then ZIP-235 is more compelling. Is this something that should be spelled out more clearly in the ZIP rationale?
So in my biased opinion ZSA + NSM with both ZIP-227 modified to burn and ZIP-235 are a complementary reinforcing combination and the more we believe ZSAs bring a compelling rationale, the stronger the rationale for these two.
IMO, this is a âtactical but importantâ rationale for combining ZSAs + NSM. For me, the strategic reasons above are the more compelling, but reducing disruption to the ecosystem to âone waveâ also seems quite compelling.
(Thought experiment: how many of the multi-asset privacy systems are directly integrated into the economic flywheel of their underlying platform? IMO, this is a big picture / long term challenge with those systems. For example, some of the Ethereum smart contract or L2 privacy systems do not necessarily benefit ETH holders, and therefore we shouldnât expect the L1 to protect, improve, or extend those use cases for purely direct economic-incentive reasons, although secondary incentive impacts such as general usage/adoption still come into play, and importantly non-incentive reasons such as community values matter. Still, I believe direct economic sustainability of multi-asset privacy is a killer feature.)
What Iâm actually referring to here is the change proposed in ZIP 230: Version 6 Transaction Format (which is not the greatest place for it; we should probably add a 2000-series ZIP for the modification to ZIP 317). Itâs my opinion that essentially all of the issuance fee should be burned; 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 also posted about this topic here: ZSA - Update on Release - #6 by nuttycom
Related to this specifically, note that ZIP 234 doesnât activate for likely more than a year after NU7 activation. This gives ample time for updates to be rolled out to miners after the NU7 release before the smoothing actually becomes an active feature.
To me it seems logical:
NU7 - NSM
NU8 - LockBox
NU9 - TFL (Hybrid PoS/PoW)
All this planning, all this work, all this evolution gives me more and more confidence in Zcash. In addition to having amazing technology, they are always evolving.
I have a question: will these updates NU7, NU8, NU9⌠cause any changes to the Unified addresses? Will it not be necessary to move the coins to another address to stay updated?
At present none of the changes through to Hybrid PoS would require an address change. In general, an address change is only required when shifting to a different curve, and none of the changes weâre foreseeing at the moment would require that. Maybe something related to the scalability improvements that @ebfull is working on might do so, but it doesnât seem likely.
The RedBridge team has intentions to include ZSAs on subsequent iterations of the bridge. The team is focused on delivering v1 which is the foundation of it all and take it from there.