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

[arya2]

@aquietinvestor

This proposal is less about the NSM itself and more about improving how we ship network upgrades by making them faster, more predictable, and on a regular schedule. As I mentioned on the Arborist call

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.

@shielded-nate

I didn’t take up @str4d’s well-put challenge that we’ve tried a faster upgrade cycle previously, so what will be new about any new proposals of process improvements. I hope we can all ponder that more, and I’m all ears!

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.

@zancas

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?

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.