[ZIP-233] Network Sustainability Mechanism: Burning

[giddie]

This mostly consists of the addition of a burn_amount transaction field, introduced in the ZFuture network upgrade. Enabling cfg(zcash_unstable = "zfuture") meant that a lot of TZE code was unnecessarily enabled, so we switched some of those sections to zcash_unstable = "tze" as well as introducing zcash_unstable = "nsm" to keep things separate. The zfuture cfg is now used just to enable the ZFuture network upgrade.

The code for the generated test vectors is available in this PR.

[codecov]

Codecov Report

Attention: Patch coverage is 41.66667% with 35 lines in your changes missing coverage. Please review.

Project coverage is 61.56%. Comparing base (81d8ad4) to head (0ac99f7).
Report is 64 commits behind head on main.

Files with missing lines	Patch %	Lines
zcash_primitives/src/transaction/mod.rs	42.85%	16 Missing ⚠️
zcash_primitives/src/transaction/builder.rs	20.00%	8 Missing ⚠️
zcash_primitives/src/transaction/txid.rs	57.14%	6 Missing ⚠️
zcash_client_sqlite/src/wallet.rs	0.00%	4 Missing ⚠️
devtools/src/bin/inspect/transaction.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1567      +/-   ##
==========================================
- Coverage   61.62%   61.56%   -0.07%     
==========================================
  Files         148      148              
  Lines       18825    18873      +48     
==========================================
+ Hits        11601    11619      +18     
- Misses       7224     7254      +30     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[daira]

This change is incorrect I believe. ZFuture by definition has no activation height.

[shielded-nate]

What's the recommended development pattern for naming and activating "provisional" protocol changes within dev branches prior to those changes being accepted or planned for any network upgrade?

In other words, what's the best way to do steps 2 and 3 below (wrt librustzcash crates):

1. Implement some consensus protocol change,
2. Name the new protocol version (with a provisional dev-branch-specific identifier),
3. Modify update/activation logic and tests for activating that new protocol change,
4. Later, if things go well, after ZIPs are specified and the changes are slated for a real life upgrade, submit another code change to rename the provisional protocol version with the real target version,
5. Merge the protocol changes with other protocol changes for the slated upgrade, etc...

Also, I believe this process/convention needs to be shared somewhat with zebra, correct?

[shielded-nate]

I realized my question isn't directly relevant to this diff hunk, and I understand why ::Future should not be added to that list.

[nuttycom]

As discussed in the last Arborist call, the proposed mechanism is to guard those changes with:

#[cfg(all(zcash_unstable = "nu7", feature = "zip-233"))]

This requires the zcash_unstable feature flag to be set, and also for an ordinary additive Rust feature flag. This will make it so that the code cannot be part of any ordinary build, but those who need to experiment with and ensure build consistency can proceed.

As part of this, we should add a NetworkUpgrade::Nu7 constant that is guarded by #[cfg(zcash_unstable = "nu7")]

[nuttycom]

I'll make a PR to zcash_protocol that adds these constants.

[nuttycom]

#1718

[daira]

Blocking on review by @str4d and @nuttycom, since this requires a design decision about the future of ZFuture (and the interaction of zcash_unstable flags).