NU7 Timeline and the Dev Fund Expiration

General
1

In my Z|ECC summary post, I mentioned that the ECC team reviewed the NU7 timeline (including vanilla ZSAs, the NSM, and memo bundles) and does not believe the network upgrade is likely to activate in August. According to our estimates, an “optimistic” date for the NU7 activation is sometime in October. Keep in mind that these optimistic dates are not commitments, they are only stated to give people an idea of possible timing.

This delay is because we are running behind on implementing the replacement zcashd cli wallet, which is called Zallet (pronounced like “ballet” or “sallet”). Other factors, of course, include sufficient time for testing and rollout. Some of this testing requires a complete rollout of the new stack, including zebrad.

We need to consider the implications of this delay. The current development fund is scheduled to end in November. At that time, miners will receive the full allocation of mining rewards, and additions to the lockbox will cease.

Even if this two-month change to the optimistic timeline had not occurred, any schedule deviation would have resulted in the same outcome: the development fund would have ended, and a hundred percent of the mining rewards would have reverted to the miners.

Network upgrades should be spaced at least three months apart to ensure smooth and safe transitions. Under current assumptions, the best case for a network upgrade that includes a distribution mechanism for the lockbox would, at best, be scheduled for January 2026.

Allocating the full amount to the miners only to return and reinstall some development funding at a later date is not ideal.

Therefore, assuming the community desires an ongoing development fund as signaled in surveys this last year, we recommend extending the 20% allocation of mining rewards to the lockbox for another year with a network upgrade that will activate no later than November 2025.

We believe this extension should allocate all of the 20% development funds to the lockbox. Unlike the current allocation to ZCG, its funding allocation would cease until the community decides what to do with the funds in the lockbox. Like others, including ZF and ECC, it would be limited to its existing treasury until a distribution mechanism is cooperatively defined.

We see two potential paths for activating an extension. One path is to insert a new network upgrade that simply extends the timeline and removes the ZCG allocation for a period of one year. This Network Upgrade (NU 6.5 or a new NU 7) would activate no later than November and three months before what is currently defined as NU7 (ZSAs, NSM, and memo bundles).

The second option is to include the change in NU7 unless the remaining NU7 work is delayed beyond the November expiration date, in which case, only the extension is activated, and the remaining capabilities would be activated at a later date when ready.

We would like to get feedback from the ZIP editors and the community at large on these ideas.

Adjacently, @daira and I are working on a proposal to implement a new distribution mechanism. We will soon publish it.

Thanks to Daira-Emma and @nuttycom for reviewing and providing feedback on this post.

We look forward to your thoughts and feedback.

6 Likes
2

Why are you behind?

1 Like
3

We prioritized PCZTs in support of Keystone in Dec.

According to the ECC core team, Aug was not likely even without that.

2 Likes
4

@Dodger - is there something specific that you are giving the thumbs down to?

The delay? The idea?
If the idea, what specifically and what is a better option?

3 Likes
5

General thoughts that may not even be related:

  • It’s really not healthy for ECC, or any other party receiving on-going funds to always be on this tight-schedule. It’s like a start-up that spends months raising for just a few months of runaway.
  • I’m increasingly feeling like ZCF needs to be extensively reviewed. I think great work is being done there (Zebra/Frost), but I think the leadership team has served its time. I see low engagement, and I’m unable to even understand the impact of the three executives. Probably some G&A behind the scenes but do we want to keep funding this?
  • More to come…
6

only ZCG is receiving funding from new blocks since november. everything else is already going into lockbox. ZF and ECC are running on their past received funds atm.

the runaway could be improved with just 1 variable that is decided by outside world. not gonna say what it is. we all know it.

5 Likes
7

I agree and this should be included in NU7, which in turn, I believe should be activated before end of dev fund.

On the topic of the foundation, what is ZF doing for NU7? Frost is great, but it’s unrelated to NU7 right? I wonder if ZF should postpone further work on Frost and focus on helping NU7 delivery works.

1 Like
8

Are you prioritizing the CLI Wallet work now?

10

My personal opinion:

I’m extremely against NU 6.5 for the simple reason that everything breaks on each network upgrade and we should avoid another breakage round if possible.

I’m against rushing NU7 to meet the end-of-lockbox deadline (though I do believe it’s possible to meet the deadline). It’s not the end of the world if the lockbox gets unfunded for a couple of months. (Assuming the community actually wants to renew the lockbox.)

1 Like
11

At a high level, there are two things that need to happen before NU7 can activate:

  1. zcashd must be deprecated (because ECC will not support adding more features - like ZSAs - to zcashd), and
  2. QEDIT must complete the work to enable ZSAs, and those changes must be merged into both Zebra (maintained by ZF) and librustzcash (maintained by ECC).

Of the two, Zcashd Deprecation is the biggest challenge. This isn’t to suggest that the work that QEDIT is doing is simple (it’s definitely not!) but it’s well in hand, and on track.

To deprecate zcashd, we need to replicate all the functionality that people and organisations currently rely on zcashd for, in other pieces of software. The plan (agreed last September) looks roughly like this, annotated with which organisations are responsible for which pieces (credit to Zingo for the original diagram):

Post-zcashd_Stack_v2
Post-zcashd_Stack_v21920×2594 200 KB

ZF is working on adding whatever functionality is necessary to support the Zaino usecase, and any other use cases that will rely on Zebra (e.g. mining). You can track the progress of that work in this GitHub milestone or by reading our Engineering Updates.

We’re also supporting QEDIT with the changes they’re making/refining to their fork of Zebra, and we’ll be helping them merge those changes into the main branch of Zebra.

FROST is not a strict prerequisite for NU7 but it addresses various important use cases (e.g. the Avalanche bridge, multisig-style ZSA issuance, potential mechanisms for distribution of lockbox funds).

We would absolutely do that if it would bring NU7 forward. As things stand, we don’t think it would because ZF is not the bottleneck.

In any case, the current phase of FROST work (providing a FROST and frostd implementation that can be used to add FROST support to Zcash wallets) is nearly complete, and after that, all our engineers will be fully focused on Zebra, Zcashd Deprecation and getting ZSAs merged and activated.

8 Likes
12

There isn’t much value in dredging up all of the previously shared concerns.

Nothing really ever seems to happen in a year with Zcash, which is why I communicated concerns about the original 1-year extension, and why I’m here to share deeper concerns about another 1-year extension.

We look silly to be doing this again so soon. I don’t support any extensions because clearly they’re not effective to incentivize an ecosystem like this. I’m in support of ending the lockbox/ NDFM block subsidies (and ZCG direct subsidies along with it), as was originally communicated by the ZIP proposers whose path we’re on today.

It is unfair, possibly disrespectful, to the many community members who supported the previous Dev Fund NU, with its specific deadlines and outcomes defined - 1-year extension, ZCG/ Lockbox/ et al

Zcash will become a big mess if our disparate teams are made to debate and redeploy new Dev Fund implementations every year.

Can we finally just get subsidization behind us? The results speak for themselves, the results are thus far very poor in a crypto-industry relative sense.

As I mentioned months ago, this ecosystem cannot take on the burden of perpetual 1-year Dev Fund renewal debates/ tinkerings with % address multi-sig implementations of where the subsidy ZEC ought to be distributed.

We’ve got yet another chance to clean the slate, and completely eliminate the hazards created by ZEC ecosystem subsidization.

The funds that the NDFM will have accumulated after 1-year should be adequate to achieve its theoretical objectives. Also keep in mind that Zcash true-believer investors have the freedom to contribute ZEC into the NDFM lockbox, suppose that its liquidity begins to try up years into the future.

13

There are some things that ZF can be doing to help.

7 Likes
14

This has been on my plate for a while, I did some preliminary reviews and there were some issues with the code in the PR not being up to date. But these were resolved and I’m planing to do a full review very soon. We didn’t give this high priority because while it is required for zcashd deprecation, it’s fairly standalone and it’s not blocking any intermediate work AFAIK.

This is very specialized code and I don’t think ZF has the know-how to do a good effective review. I agree that is not the best state of things (and I personally have been wanting to study the ZK stuff for a long while) but unfortunately that’s not going to change now before zcashd deprecation. I’d be happy to help reviewing other stuff though.

3 Likes
15

To be honest I’m somewhat in the same boat with these PRs; however, there’s a lot of code involved that doesn’t actually involve the highly specialized ZK proving knowledge, and reviewing that (and picking around the edges of the ZK stuff) is both useful and a good way to learn. Some of the circuit code is difficult for those lacking the necessary background to follow internally, but fortunately the code that uses those APIs is not too hard to understand at a high level.

2 Likes
16

@joshs Would there any reason for other existing development works (e.g.; Zashi) to be prioritised over anything NU7 and launch of ZSA or as of right now all ships are sailing to that goal?

17

The core team’s priority is NU7 work including the Zallet (cli wallet), PR reviews, and memo bundles.

Our Zashi team’s work is currently focused on areas that minimize requirements on the core team’s time.

I should have an updated roadmap out next week.

3 Likes
18

Interestingly, at present this isn’t true: there’s no mechanism in the protocol by which anyone can independently donate to the lockbox. The fact that we didn’t introduce such a mechanism when implementing the lockbox is an unfortunate oversight; ideally there would be such a mechanism but at present that would be yet another thing to add to the transaction V6 format changes and would require another consensus rule change. The specification window for making such a change has closed, but… well, maybe the ZIP Editors should consider it anyway.

On the other hand, it probably makes more sense to introduce that change when a disbursement mechanism is implemented. We really don’t need to be cramming anything more into NU7.

6 Likes
19

The one thing that I think gives this some urgency is that it would be good for the code here that runs both the existing script interpreter and the new Rust interpreter in parallel to be integrated into a Zebra release in the near term, so that we can verify that the new interpreter is acting correctly in production well before we get to the NU7 activation height and need to switch over to the new interpreter, since the zcashd transaction type will not be updated to support V6 transactions (and as a result the C++ implementation will entirely cease to work).

2 Likes
20

You mean transaction v6, not NU6. And yes I agree on both points: that it would be useful, and that it is late in the NU7 schedule to add it now. It could reasonably go into NU8, along with the mechanism(s) for lockbox disbursement that @joshs and I intend to write a ZIP for.

(The NU numbering here assumes no NU inserted before what is currently NU7.)

Incidentally — although the main reason we didn’t add this is that we didn’t think of it — I think there would have been an argument not to add a mechanism for voluntary donation to the lockbox without having nailed down any disbursement mechanism, on the basis that potential donors would have insufficient information to make an informed decision to donate. (It is somewhat analogous to ZIP 233 without 234.)

3 Likes
21

Oops, yes, fixed.

2 Likes