Create draft-jackgavigan-defer-and-extend.rst #996
Conversation
A draft ZIP to prohibit any disbursement of funds from the Lockbox until after ZSAs is active on Mainnet, and extend the Current Dev Fund for one year.
There was a problem hiding this comment.
Hello @jackgavigan! I left some comments with formalities and possible clarifications that could potentially make the ZIP less open to interpretation in some sections.
| anything that distracts the engineers who are working on the new stack is likely | ||
| to delay ZSA activation further. | ||
|
|
||
| In addition, any changes to the core Zcash cryptographic libraries or Zebra -- |
There was a problem hiding this comment.
Any kind of changes will imply that QEDIT will have to rebase their work regardless of what they are. Although, how code changes impact a fork depends a lot on where those changes are made in the codebase and how the fork changed are coded. It could be possible that a lot of changes are actually "fast-fowardable".
Could @vivek-arte or someone else from QEDIT comment on this paragraph?
There was a problem hiding this comment.
It is simply not true that Qedit's work would have any significant code conflicts with a lockbox distribution mechanism. They are completely independent in terms of the affected code, beyond absolutely trivial issues (conflicts in changelogs, dependency lockfiles, etc) that would be easily resolved. It's quite possible that Qedit's work will land (behind a feature flag) before any lockbox changes, anyway.
There was a problem hiding this comment.
The concern here isn't that the changes required to enable ZSAs might conflict with changes required to enable Lockbox funds distribution.
The concern is that implementing, reviewing and merging the changes required to enable Lockbox funds distribution is likely to distract core engineers from reviewing and merging QEDIT's pull requests, and any other work that enabling ZSAs is dependent on (including implemention of the new stack -- a prerequisite for zcashd deprecation, and therefore for enabling ZSAs -- and subsequent implementing of any changes to that stack to enable support for ZSAs).
To put it another way - the issue isn't code conflicts; it's resource, time, and prioritisation conflict.
|
|
||
| Non-requirements | ||
| ================ | ||
|
|
There was a problem hiding this comment.
A non-requirement of this ZIP could be not defining or supporting any disbursement mechanism after ZSA deployment
| and delay. | ||
|
|
||
| This ZIP therefore proposes expressly prohibiting any disbursement of funds from | ||
| the Lockbox until after Zcash Shielded Assets is active on Mainnet. |
There was a problem hiding this comment.
It would be good that the ZIP explicitly specifies ZIPs, PRs, GitHub issues and other documented pieces of code that have to be implemented to it is possible to determine when the requirement "Zcash Shielded Assets is active on Mainnet" is completed without any ambiguity.
| Mainnet. Zcashd deprecation was expected to be complete by April 2025. However, | ||
| the necessary work was not prioritized. [#nu7-timeline]_ As a result, as of March |
There was a problem hiding this comment.
@jackgavigan please do not spread outright falsehoods.
The timeline that was originally given was the most optimistic possible timeline, and not a commitment by any organization. Furthermore, due to the complexity of reimplementing the zcashd wallet, even if no other efforts had been undertaken this work would not have been complete by April 2025. Your expectation of this completion date was your own, not a realistic schedule based on an accurate assessment of the task.
There was a problem hiding this comment.
@jackgavigan I agree with @nuttycom that this needs to be rephrased, I think the sentiment is there - we (in the ecosystem as a whole, including ZF and myself personally) have blundered repeatedly since zcon4 leading to delays, and I think we (the ecosystem devs) have failed to fulfill some of our promises - but at the time that the timeline you're referring to was released, it was clear that April was the best possible timeline if the stars aligned, not a worst-case hard deadline.
There was a problem hiding this comment.
@nuttycom For the record, I do not appreciate being falsely accused of spreading falsehoods.
Your expectation of this completion date was your own...
No, it was created by Josh Swihart stating, during the Arborist Call dedicated to discussing ZSAs, NU6 and NU7 on 18th April 2023, that zcashd deprecation would be complete "well before" April 2025.
Others interpreted Josh's words in exactly the same way.
@arya2 When you say "at the time that the timeline you're referring to was released", what timeline do you think I'm referring to?
| and delay. | ||
|
|
||
| This ZIP therefore proposes expressly prohibiting any disbursement of funds from | ||
| the Lockbox until after Zcash Shielded Assets is active on Mainnet. |
There was a problem hiding this comment.
Subjective opinions:
- ZSA deployment and zcashd deprecation are both very large and complicated projects, I would suggest tying this to just zcashd deprecation rather than the completion of both.
- It could be nice to condition this on sufficient grants being provided to core teams from ZCG for zcashd deprecation to ensure that they remain solvent.
There was a problem hiding this comment.
- ZSA deployment and zcashd deprecation are both very large and complicated projects...
Undeniable. However, I would argue that they are both now more complicated than they would have been had they been prioritised, and received the sort of focus and attention that this ZIP is intended to incentivise.
..I would suggest tying this to just zcashd deprecation rather than the completion of both.
My personal opinion is that the time for half measures is long past.
However, my primary motivation in writing these ZIPs is to ensure that the community has a voice, by putting forward choices and options, so I wouldn't be opposed to there being two variants of this ZIP or it being accompanied by a separate question asking the community whether, in the event that this ZIP is adopted, the trigger for permitting the distribution of Lockbox funds should be (a) the activation of ZSAs on Mainnet, or (b) the deprecation of zcashd (defined by a requirement that any protocol changes to unlock the Lockbox MUST NOT be made available in zcashd).
- It could be nice to condition this on sufficient grants being provided to core teams from ZCG for zcashd deprecation to ensure that they remain solvent.
That would raise the problem of defining "sufficient funds", and also risk introducing an incentive to spend existing funds as quickly as possible on other project in order to put pressure on ZCG to approve grant applications for funding earmarked for zcashd deprecation and/or ZSA activation.
My sense is that, having funded QEDIT to research and develop ZSAs, ZCG are highly motivated to see that functionality deployed and activated.
There was a problem hiding this comment.
In my personal opinion, this draft ZIP "manifestly violates common expectations of a significant portion of the Zcash community" and should not be accepted. ZIP 1015 says that "the Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development funds". There was no expectation that "allocation of development funds" would be blocked behind any specific protocol feature, other than possibly mechanisms that directly help to allocate development funds — which ZSAs do not.
ZSAs in particular are a complicated feature that very well might encounter delays in deployment for entirely legitimate reasons. What if a security vulnerability is found, for example? It is completely inappropriate to hold the lockbox funds hostage to ZSA deployment.
I disagree.
The absence of an explicitly-articulated expectation in a ZIP does not imply that the ZIP in question can be interpreted as expressing an opposite or counter-expectation. Furthermore, one could argue that, at the time the community decided to adopt ZIP 1015, there was an expectation that zcashd would be deprecated well before April 2025, thus clearing the path for ZSA activation.
Extenuating circumstances (such as a fundamental security vulnerability) would, in my opinion, be grounds for re-consulting the community. There is plenty of precedent for amending ZIPs (c.f. ZIP 1014). |
A draft ZIP to prohibit any disbursement of funds from the Lockbox until after ZSAs is active on Mainnet, and extend the Current Dev Fund for one year.