Several things didn’t need consensus changes: for example shielded n-of-n multisig; rollback attack mitigation; BOLT; and deprecating sending to Sprout addresses. Also there is a bunch of work needed to capitalise on Sapling. But I’m not going to pretend that Blossom isn’t sparser on features than we originally thought it would be. Part of the reason for that is that it isn’t a circuit change, so any idea that required a circuit change needed to be postponed to NU3.
2 Likes
Sounds pretty parsimoniously in my opinion having in mind a whole year for these improvements/changes.
Out of curiousity, how much funding/resources are used for these NU2 targets?
1 Like
It’s not a whole year until specification freeze for Blossom. That’s at the end of February. If there’s a criticism to be made here, it’s that we weren’t overlapping more R&D for the next upgrade while also doing Sapling. But Sapling was so ambitious that that would have been extremely difficult.
What you can do in an upgrade is constrained mainly by technical feasibility within the timescale. It’s indirectly influenced by funding in that developer salaries are a substantial part of the outlay, and you need enough developers on board for the whole period of research, design, implementation, analysis, deployment, and consolidation of ecosystem support, which is at least 2 years (and which we’re still in for Sapling, btw), to make changes in a given upgrade feasible. Given the “crypto winter”, it’s not feasible to hire more developers at the moment.
4 Likes
In my opinion it’s a whole year work involved. As the upgrades/updated/changes are based yearly the whole worked involved for each upgrade is just a whole year the team is working on a given NU upgrade as it includes after and bevor announcing/finishing the upgrade/update work, not?
It still doesn’t answer my question how much funding are going into a given upgrade/update NU, or are planned to go in. I think it’s just normal to measure a given done work compared with the expense for it. Of course time is the next factor to this and it’s a know factor allready, about 1 year. Leaves only the expense factor open. I guess and hope this is not a secret on how much funds for NU1 have been used and how much is planned for NU2, or?
We haven’t published what we spend funding on, but developer salaries, for example, can’t be attributed to particular upgrades – any such attribution would be completely arbitrary and wouldn’t tell you anything useful. The developer is either hired or they aren’t.
2 Likes
The entire pipeline might look about a year long, but that’s due to overlapping work on the current upgrade, the next upgrade, and future upgrades:
- Blossom needs to be specified, implemented, audited, and tested within four months (so that it doesn’t delay specification and implementation of NU3).
- In that same time window, we need to write draft ZIPs for NU3 (hopefully the community will contribute some as well!), and then do NU3-oriented R&D and feature selection.
- Alongside this, we need to be spending some time on forward-looking R&D for things that might be considered for NU4 or beyond, but need more research before we can be sure they are feasible.
So it simply isn’t the case that the Blossom upgrade (or any upgrade, for that matter) corresponds to one year’s worth of Zcash Company engineering time, with us doing nothing else.
5 Likes
I see that Zcash team has great plans for 2019, keep it going!