You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In NU6 we will very likely be adding a new transaction version, v6. This is likely to mean that three transaction versions will be allowed simultaneously: v4, v5, and v6. That is complicated but not really so bad.
In NU7, it is proposed to reorganise transaction fields to support "action groups". This may or may not require another transaction version, v7, but it will increase the number of options for the transaction format regardless. In addition there will be a new revision of the Orchard shielded protocol to support ZSAs, with an associated circuit change. I think it is not yet decided whether the old Orchard Action circuit will still be used in v5/v6 transactions after NU7 activation, but in any case proofs of that circuit must still be verifiable.
Having effectively four transaction versions (v4 to v6 and the action groups change), and five zk circuits (Sprout JoinSplit, Sapling Spend, Sapling Output, Orchard Action, OrchardZSA Action) in the field at once is too much. I'm good at remembering protocol details and I don't think I'll be able to effectively keep track of the whole protocol at this point, even with the help of my ADHD meds 😛
So, assuming that NU6 and NU7 remain roughly as planned, I propose that in NU7, we:
disallow v4 transactions, i.e. only v5, v6 and possibly v7 will be supported;
at the NU7 activation height, burn all remaining Sprout funds and add their total amount (i.e. the Sprout chain value pool balance at that point) to the Zcash Sustainability Fund.
Note that the Sprout chain value pool balance will necessarily be nonnegative because ZIP 209 requires that as a consensus rule.
(As with all network upgrades, a rollback is possible undoing the activation, at which point it is technically possible for additional Sprout funds to be spent before any reactivation. Therefore, a validating node must keep the last Sprout treestate until it is no longer possible to roll back that far, i.e. 100 blocks after activation for Zebra. It is expected that all zcashd nodes will have halted.)
The text was updated successfully, but these errors were encountered:
daira
changed the title
Proposal to deprecate v4 transactions and move all Sprout funds to the ZSF in NU7
Proposal to disallow v4 transactions and move all Sprout funds to the ZSF in NU7
May 2, 2024
In NU6 we will very likely be adding a new transaction version, v6. This is likely to mean that three transaction versions will be allowed simultaneously: v4, v5, and v6. That is complicated but not really so bad.
In NU7, it is proposed to reorganise transaction fields to support "action groups". This may or may not require another transaction version, v7, but it will increase the number of options for the transaction format regardless. In addition there will be a new revision of the Orchard shielded protocol to support ZSAs, with an associated circuit change. I think it is not yet decided whether the old Orchard Action circuit will still be used in v5/v6 transactions after NU7 activation, but in any case proofs of that circuit must still be verifiable.
Having effectively four transaction versions (v4 to v6 and the action groups change), and five zk circuits (Sprout JoinSplit, Sapling Spend, Sapling Output, Orchard Action, OrchardZSA Action) in the field at once is too much. I'm good at remembering protocol details and I don't think I'll be able to effectively keep track of the whole protocol at this point, even with the help of my ADHD meds 😛
So, assuming that NU6 and NU7 remain roughly as planned, I propose that in NU7, we:
This assumes that, out of the ZSF-related specification changes, at least ZIP 233 will have activated in NU6.
Note that the Sprout chain value pool balance will necessarily be nonnegative because ZIP 209 requires that as a consensus rule.
(As with all network upgrades, a rollback is possible undoing the activation, at which point it is technically possible for additional Sprout funds to be spent before any reactivation. Therefore, a validating node must keep the last Sprout treestate until it is no longer possible to roll back that far, i.e. 100 blocks after activation for Zebra. It is expected that all zcashd nodes will have halted.)
The text was updated successfully, but these errors were encountered: