Accelerate NU7: Let’s Deliver A Smaller Network Upgrade Sooner

I believe it is entirely accurate and I stand by the detailed, well-supported argument I gave in my previous post.

Economic systems are shaped not only by current transactions but also by expectations and the confidence of participants.

What you’re talking about it is “market sentiment”, not economics. It’s notoriously fickle. Investors clearly are not working with accurate information and do not understand the risks. If they did, you’d expect the price history to reflect the fact that upgrades are risky (some more than others) and that the risk is resolved once the upgrade activates successfully — which is not the case.

The community can listen to my advice or not. My advice is that expending effort in Zcash development on anything other than directly making shielded Zcash more useful to more people with fewer security risks is mostly a waste of that effort. Address the long-term things in the long term (or, better, the medium term). I could have pushed back much more on the NSM because of the opportunity costs of doing it instead of almost anything else. I didn’t, because it was being bundled with other things and in that form, it was mostly harmless. Now Shielded Labs is proposing something that magnifies those opportunity costs enormously, by putting it in its own upgrade that is almost pure overhead. I’m opposed to this and I will say so clearly.

3 Likes

This is because Ethereum fees are much higher. The actual numbers matter.

The relevant part of what I said was:

What causes downward price pressure is simply the availability of ZEC to be bought in exchange for fiat or goods and services. […] Someone who wants to remove funds from circulation can already just send them to a verifiably unspendable transparent address, or make a legally binding promise to not spend the funds and use ZIP 233 to remove them from circulation once it activates.

I stand by what I said: essentially, that supply is only determined by the availability of coins; and that effects on supply, demand, and market sentiment are not significantly different between removing your coins from circulation in a (possibly) earlier NU, vs doing what I suggested. I will grant two very minor caveats: that sending to a verifiably unspendable transparent address does not result in eventual re-issuance, and that it may be harder for investors to tell that you’ve made the binding promise (but I believe they mostly do not care and it will have very little if any influence on their buy/sell behaviour either way).

Remember that on the other side of the trade-off, I believe NU6.2 would cause significant disruption to the deployment of the NU7 features that are not in NU6.2 (that is: ZSAs and memo-bundles; ZIP 2003 is not a feature per se).

The more I hear about this issue, the more I think that this is an argument in favor of more smaller network upgrades.

To me it seems like @aquietinvestor and @nuttycom are essentially in agreement that what’s needed is immediate attention to the how transaction formats are upgraded. @nuttycom immediately points out the obvious way to deprecate old formats, and everyone seems to be in violent agreement that previous format upgrades have been too difficult, and formats need to be upgraded repeatedly and efficiently.

So does all this smoke and gusto really just boil down to investing resources in making formats more upgradeable and deprecateable?!

As I believe @arya2 has already suggested, or at least hinted at, multiple times?

Or are (upgradeable formats), at least, a necessary improvement to the protocol that we’ll all benefit from, and that will begin amortizing as soon as it’s complete?

1 Like

Arguments for or against the proposal aside, any non-contentious network upgrade must have broad consensus.

NSM appears to have it. But this proposal currently does not.

Of course a contentious NU is possible. It becomes a fork. I don’t think anyone is advocating for that.

In this case, no one seems to be moved by each other’s perspectives and I suggest we keep the current path unless something changes that would sway opinion. The dialogue back and forth is also consuming a lot of time from the people focused on zcashd deprecation and getting NU7 across the line.

6 Likes

I strongly agree with this sentiment.

I think we should try to tag a release that deploys NU8 on Testnet almost immediately after we’ve:

  • Specified either Asset Swaps or CrossLink, and
  • Tagged the release that deploys NU7 on Mainnet.

and to tag another release deploying NU9 on Testnet immediately after the one deploying NU8 on Mainnet.

Then we could tag a release to deploy NU8 on Mainnet ~16 weeks after tagging one for NU7, and tag a release for NU9 ~16 weeks after tagging one for NU8 if CrossLink and Asset Swaps are ready in time.

Or if both are implemented by the time we’ve tagged a release to deploy NU7 on Mainnet, both could be included in NU8.

I suspect it was largely due to:

  • Technical debt and investing effort into clearing technical debt, including zcashd deprecation
  • Maintaining two nodes
  • Ensuring that several mobile wallet implementations would work with the new upgrades
  • Bottlenecks in specifying network upgrades and the ZIPs being deployed,
  • Most of those upgrades deployed new transaction formats, and
  • A couple of those upgrades deployed new shielded protocols.

What’s changed/changing:

  • Lots of technical debt has been cleared or will be cleared alongside NU7 deployment,
  • Only one node implementation will be maintained,
  • Zashi should support new network upgrades promptly,
  • More people are helping to update the spec using more established processes, and
  • It seems likely that CrossLink and Asset Swaps will be implemented by or fairly soon after NU7 deployment, and neither of them require transaction format changes

There’s some work to be done to enable a faster network upgrade cycle for NUs that deploy transaction format changes.

It’s the option I had in mind for enabling a faster NU cycle for NUs that deploy transaction format changes, @nuttycom’s suggestion to ensure that we’re publishing a set of libraries to handle (de)serialization so that other projects need only update their dependencies to support the latest transaction format would work too, and may be a better idea.

This all boils down to clearing tech debt imo, specifically, porting code from C++ to Rust, zcashd deprecation, and de-duplicating code across the ecosystem.

I think librustzcash has been leaping forward since Zcon4 without much celebration or recognition, but that was/is a crucial step.

5 Likes

I don’t know that I’m non-swayable. To me there seems to be an important technical consideration which is:

How easy is it to upgrade transaction formats?

What’s the downside of e.g. SL investing development time into making it easier to upgrade and deprecate transactions formats?

There’s opportunity cost, of course, but beyond that?

If that’s the first step, or an early step on a path, then it seems that we haven’t really reached a divergence yet?

It seems to me that a significant improvement to upgrading transaction formats might more than pay for itself in just a few upgrades… maybe more than offset the cost of maintaining zcashd through one more upgrade…

Why not wait until we have more information before making any “final” decisions?

Fairly difficult:

  • I’m not sure if zcashd handles (de)serialization with librustzcash, but Zebra doesn’t, and they use completely different transaction types (one is a struct and the other is an enum),
  • Other stakeholders may be maintaining their own code to handle encoding/decoding the format,
  • Transaction version specifications are complicated, sensitive, and rely on deep, obscure knowledge regarding the Zcash and Bitcoin encodings

That’s not was proposed by Shielded Labs, it was what @nuttycom suggested as an alternative to this proposal, and it doesn’t make sense as a priority right now imo, but it would be reasonable.

What was proposed by Shielded Labs was to front load the implementation effort for transaction version 6 under the misunderstanding that it would work without using the new Orchard ZSA changes, but that won’t work, so one of the following approaches would be required:

  • Use the new Orchard ZSA circuit, not really an option because it’s the other critical constraint on ZSA deployment alongside zcashd deprecation and may rely on zcashd deprecation, can’t accelerate NSM deployment if we still have to block on that,
  • Change v6 to support either the old format or the new format and disallow the new format with a consensus rule until ZSAs are deployed, involving dangerous, sensitive, and complicated changes to introduce tech debt that Shielded Labs is probably not well-suited to make and which would likely go through a long review process, still won’t accelerate NSM deployment, may delay it while also delaying everything else, particularly CrossLink which Shielded Labs is the best suited to develop and which should be a priority for Zcash imo
  • Add a new transaction format for just the NSM, introducing tech debt, requiring an unknown number of stake holders to update their (de)serialization implementations, and requiring at least two or three of our (de)serialization implementations to be updated and reviewed, probably still won’t accelerate NSM deployment.

Any of those approaches would require as much if not more work from other organizations to review the changes, two of them would introduce long-term tech debt, and none of them seem ikely to accelerate NSM deployment.

It’s not the first step imo, see my comment above regarding potential steps in line with what Shielded Labs said was their key motivation behind this proposal.

In four upgrades, see my comment above, it seems unlikely to offer much benefit until NU10.

1 Like

You mention that there’s more than one (de)ser process currently being used by at least zcashd and zebrad, and note that @nuttycom (If I Understand Correctly) advocates for a single common library that consumers across the ecosystem can use to handle transactions.

Isn’t the creation (and/or extraction) and adoption of such a library something that would deduplicate effort and probably by virtue of reducing sources of truth eliminate bugs?

Isn’t such a library something that simply needs adequate investment to create?

Is there a reason such a library couldn’t be written now?

Wouldn’t such a library as a community resource make future transaction format modification simpler?

Wouldn’t this work be valuable for any future regime of Network Upgrades?

In this case, there already is a library for (de)serializing transactions in a Rust environment, librustzcash. Zebra just isn’t using it yet because we’re prioritizing zcashd deprecation above all else, replacing Zebra’s transaction type with the librustzcash transaction type is a large change, and because it’s not necessary for zcashd deprecation.

We do want to deduplicate logic between librustzcash and Zebra where it can be done with relatively minor changes, and are doing that, see #9828, #9737 and #9308 which have all been authored or merged in the past couple weeks.

We’re eager to specifically use the librustzcash transaction type as well, see this comment, but in the interest of getting NU7 deployed as soon as possible, are deferring significant unrelated tech debt cleanups.

Is there a reason such a library couldn’t be written now?

There is no reason that libraries in commonly-used languages that handle (de)serialization of the transaction format can’t be written now, it was suggested as an alternative to this proposal because it can be written now, and it would be valuable to have now.

As noted in my previous comment, that’s not what was proposed by Shielded Labs, it was suggested by others as a way that Shielded Labs could help enable a faster NU cycle in the future for NUs that deploy transaction format changes.

4 Likes

Honestly this seems like a recipe for burn-out of the core developers. NUs are currently stressful and exhausting for us (and always have been; every single one of them so far including the “minor” ones). If we want to facilitate shipping protocol upgrades faster, we need to address the effect on core developer workload with as much emphasis as the strictly technical issues.

I just want to point out here that the protocol hasn’t changed and won’t change in any way that precludes there being more than one node implementation, and the community hasn’t made any irreversible decision to focus on only one implementation. There are obviously some advantages to having only one active on Mainnet (modulo differences between versions of that implementation), and some down-sides. In any case there are likely to be several forks of Zebra (not all intended to be deployed on Mainnet).

2 Likes

Yes, it does, in addition to the C++ deserialization code, the librustzcash serialization code is used when crossing the FFI boundary. All this can go away with a pure-rust implementation, particularly if we eventually unify on a transaction type.

I support this decision! Now is not the right time to throw that wrench into the works, given everything else that is in flight. It might make sense in a few months, or it might be something that a motivated third party could work on - I made a small attempt at this about a year ago, replacing the Zebra transaction type with a wrapper around the zcash_primitives type, and it’s not too invasive if you do it that way but it is still a bunch of work.

2 Likes

As @nuttycom noted (I started replying before finishing the thread), it both depends on librustzcash’s transaction parser in consensus (for v5 txid digesting), and has its own transaction parser (the original / first Zcash transaction parser) for basically everything else zcashd needs. The latter is a third kind of parser: it only parses into either simple integers or byte arrays / vectors, not into typed fields like we do on the Rust side for shielded logic[1]. This is actually something I’ve wanted to retrofit into librustzcash as an option because it has some useful benefits (specifically in being able to disable support for older shielded pools), and this would in theory be something that zcashd could then use. But that would require engineering time and resources, taking time away from zcashd deprecation.

[1] The moment I posted this I remembered that it’s even more complex: for Orchard we do actually parse on the Rust side and store a pointer to the Rust orchard::Bundle on the C++ side (because we wanted to do more on the Rust side).

1 Like

Update: After reviewing the feedback from the community and discussing it internally, we’ve decided not to move forward with our proposal for a smaller NU7. Introducing another upgrade at this stage would create too much disruption for the ecosystem, especially given how much work is already underway across multiple fronts. In addition, questions raised about the release schedule highlighted that our proposed timeline for implementation was likely unrealistic once all the necessary steps were taken into account. We want to be constructive and collaborative in this process, which is why we think the best path forward is to step back.

While we will not be pursuing this specific proposal, we still believe there are opportunities for Shielded Labs to help improve the network upgrade process so that upgrades can ship faster and on a more regular cadence. That will be our focus going forward.

Our proposal for a smaller NU7 was meant to explore whether we could help Zcash regain momentum, reduce pressure on core engineering teams by taking greater ownership of the upgrade lifecycle, and streamline coordination with ecosystem partners. Ultimately, our motivation was driven by our desire to accelerate Crosslink. Since Crosslink will eventually require going through the full upgrade process, conducting a smaller upgrade now would give us an opportunity to build relationships, improve coordination, and address challenges in advance, which would ultimately make that larger effort more efficient. Although we are not pursuing that path, we still see opportunities to apply the same thinking to the upgrade process more broadly.

One way Shielded Labs can help is by contributing to process changes that make upgrades more predictable and less prone to the kind of delays we have seen in the past. This means putting greater emphasis on scope control and speed, accepting that some level of disruption is unavoidable, and prioritizing smaller, incremental steps over large, all-encompassing upgrades. Instead of tying releases to when every feature is ready, upgrades should follow a schedule, with features included as they mature. Running a dedicated testnet focused on faster upgrade cycles could also help us practice this approach in a controlled environment, allowing us to refine coordination, timing, and delivery before mainnet activation.

Another area where Shielded Labs can add value is by focusing on the needs of exchanges, mining pools, and other key partners. By speaking directly with them, understanding their requirements, and helping them adapt, we can lighten the workload on the core engineering teams and improve the overall upgrade experience. In practice, this could mean acting as software maintainers and providing responsive support, supplying libraries where needed, or even splitting partners into categories and tailoring solutions based on their setup. Taking on this role allows for greater specialization and customer focus, while also enabling work to be parallelized and decoupled across the ecosystem. The result would be a more efficient and resilient upgrade process that reduces bottlenecks and builds confidence that Zcash can deliver on a regular schedule.

We want to lead by challenging assumptions about what users and partners actually need during upgrades. For example, a common belief is that consecutive transaction format changes are highly disruptive for exchanges and create major obstacles that slow down the entire ecosystem. However, @pacu’s recent outreach to exchanges indicates that this impact may not be as severe as often assumed. In a conversation on Telegram, Binance described a straightforward workflow of reviewing the changelog, testing in QA, and promoting to production; they also build and parse transactions in house from node RPC data and said the most helpful support would be clear change documentation and example mainnet transactions. This points to communication and preparation as the primary constraints, not the transaction format changes.

Insights like this highlight the importance of direct engagement with exchanges and mining pools to understand their workflows, tailor support to their requirements, and ensure that scope decisions reflect real needs. Shielded Labs is well positioned to provide that kind of customer focus, which supports scope control and makes a schedule-based release cadence more achievable.

Our next step is to bring on someone at Shielded Labs who can take responsibility for this work. The role will require a solid understanding of consensus so they can advise and support engineering teams, as well as the ability to manage relationships with relevant stakeholders. It is similar to a developer-relations position in that it combines technical knowledge with communication and coordination skills. Having a dedicated person in this role will allow Shielded Labs to help accelerate Zcash and ship network upgrades faster and on a predictable schedule.

We want to thank @nuttycom, @arya2, @daira, and @str4d for their thoughtful comments and feedback. Their input helped highlight important considerations around timelines, scope, and implementation that informed our decision not to move forward. We also appreciate the broader discussion that this proposal generated within the community, and the net impact will help move the upgrade process in the right direction. Shielded Labs values open dialogue and constructive engagement, and we are committed to being receptive to feedback and making adjustments when needed. We look forward to continuing to collaborate to help Zcash advance.

18 Likes