NUP: the New NUPenning

[dconnolly]

What do we want the NUP to be, vs what it currently is and has been?

Goals:

• encode the formulation of new NU's via the ZIP process¹
• making sure that our partners and users have a predictable, reliable schedule of NU's to plan around
• proposed consensus changes for a new NU via the ZIP process should be 'ready to go' in software, modulo some integration work with other proposed ZIPs perhaps, before being accepted for the next NU
• making sure our users have a well-greased process for software updates and changes, but which is not 1:1 with the NUP/network update changes

Up for discussion:

• If we don't have anything ready to go into a NU, we don't have to do one.
• Requiring audits of implementation / specification as part of the NUP, vs baking in enough time in the NUP for parties that audit to do so

---

1: "A suggested replacement --- let's mirror and sync the ZIP/trademark process

That's not to say the NUP is all bad. It's not! There's some great guidance in
there, particularly after features have been selected for a hard fork upgrade.
It's a thoughtfully designed process by the ECC.

But to date, the actual ZIP selection process — and choosing when/which ZIPs to
be a part of a hard-fork upgrade — has happened mostly opaquely. We'd like to
change that, and then set a process that doesn't set an regular-cadence deadline
to the upgrade, but instead relies on the ZIP editors to "bundle" suggested
consensus-changing ZIPs into a given upgrade.

• Create a new ZIP category called "network upgrade", a meta category of sorts,
  that would include a list of ZIPs approved by editors. While this meta-ZIP is
  in the "draft" state ZIPs can still be added/modified by Editors.
• ZIP Editors decide which ZIPs (which have to be previously vetted/discussed by
  editors) wind up in these "network upgrade" ZIPs.
• Any ZIP Editor can propose that a "network upgrade" moves to "proposed" state,
  at which point all ZIP Editors must unanimously agree to a
  implementation/audit timeline and hard-fork schedule, which will be enshrined
  based on block time. Some pieces of the NUP could be an inspiration here.
• Once all sub-ZIPs within a "network upgrade" have been implemented, the status
  changes to network-upgrade ZIP changes to "implemented".
• Once activated the "network upgrade" ZIP becomes "final/active."
• If a ZIP within a "network upgrade" proposal is judged by any ZIP Editor has
  having potentially political/economic implications (e.g. like the dev fund), a
  ZIP Editor can short-circuit to the process to call for community input in the
  decision, upon which it would follow a similar debate/polling process to the
  dev fund. If this is viewed as something that may delay a given hard fork, it
  can/should be tabled to the "next" network upgrade.

Modifying ZIP 0 to prescribe this process is a good idea, and would scale as we
get more teams building independent implementations (or contributing to zcashd
and zebra!). Doing it this way would more closely match the trademark agreement,
and since both the trademark agreement and the ZIP Editor selection can be
expanded to include other parties (e.g., perhaps an MGRC rep?) in the future,
it makes sense for the network-upgrade schedule to be in sync with these
processes."

2: https://forum.zcashcommunity.com/t/zf-protocol-hangout-about-improving-the-nup-september-16-at-1-pm-et/37340/7?u=steven-ecc

3: The NUP as it exists

[daira]

Hmm, this proposal would be putting a lot of power in the hands of the ZIP Editors.

(Disclosure of interest: @dconnolly and I are the current ZIP Editors.)

[dconnolly]

Hmm, this proposal would be putting a lot of power in the hands of the ZIP Editors.

(Disclosure of interest: @dconnolly and I are the current ZIP Editors.)

This is a good point

[jackgavigan]

NB: I'm speaking for myself here, not on behalf of ECC.

👍 to making the network upgrade process more transparent and accessible to anyone who wants to:

• observe the sausage-making process (🙃),
• voice opinions or provide feedback regarding what changes should be included in a network upgrade, or
• suggest or propose a change to be included.

👎 to the ZIP Editors having the authority to decide what changes are included in a network upgrade. The Zcash Trademark Agreement sets forth the criteria for determining whether a network upgrade "should become the new Reference Implementation of Zcash". Without going into too much detail, It's effectively up to ECC and ZFnd, which means that those organisations already have the implicit authority to decide which changes should be included in a network upgrade.