Zcash: Regtest mode & tests for Sapling

[solardiz]

I admit this is in part a question/wish and might not be treated as a potentially actionable issue worth tracking by the Zcash project. If so, please feel free to close this issue.

Right now, regtest mode never activates Overwinter & Sapling. Wouldn't it be a good idea to be able to (re-)test those upgrades without a network, and to have automated regression tests for them? Or are there existing regression tests for Overwinter & Sapling that somehow do not rely on regtest mode?

Subtly related: there are several Zcash fork projects, and there will be more. For new ones, they'll want to activate Sapling early on, and having such regression tests would be especially helpful. It would also be helpful to know whether (and to be re-testing that) Sapling can be activated right away. I've just tried the below on testnet in a Zcash fork tree, and it appears to work fine, but I wish upstream had any comments on whether this is supported or not (do Sapling and Overwinter possibly rely on previous protocol revisions having been active before? it seems not, but I'm not sure), and have automated tests for it:

        consensus.vUpgrades[Consensus::BASE_SPROUT].nProtocolVersion = 170002;
        consensus.vUpgrades[Consensus::BASE_SPROUT].nActivationHeight =
            Consensus::NetworkUpgrade::ALWAYS_ACTIVE;
        consensus.vUpgrades[Consensus::UPGRADE_TESTDUMMY].nProtocolVersion = 170002;
        consensus.vUpgrades[Consensus::UPGRADE_TESTDUMMY].nActivationHeight =
            Consensus::NetworkUpgrade::NO_ACTIVATION_HEIGHT;
        consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion = 170003;
        consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nActivationHeight =
            Consensus::NetworkUpgrade::ALWAYS_ACTIVE;
        consensus.vUpgrades[Consensus::UPGRADE_SAPLING].nProtocolVersion = 170007;
        consensus.vUpgrades[Consensus::UPGRADE_SAPLING].nActivationHeight =
            Consensus::NetworkUpgrade::ALWAYS_ACTIVE;

(Even more subtly related, and off-topic here: can Sprout-specific parameter files be omitted in a Sapling-right-away fork of Zcash? This question will keep coming up every time a fork is created.)

[ioptio]

Regtest is intended for unit testing. It is possible to change these parameters within test and many do already. Looks like it isn't properly documented, though you can find examples where this is used in the RPC tests under qa/rpc-tests. This uses the -nuparams option.

If you search for UpdateNetworkUpgradeParameters there are tests that upgrade to Overwinter and Sapling.

[solardiz]

Thanks! Now that I grep the tree for -nuparams, I see this is documented in release-notes-1.0.15.md (for Overwinter) and release-notes-1.1.1.md (for Sapling). I'm not sure where to document it better for everyone, but for me a comment in the regtest section of chainparams.cpp would have helped - so it might also work for informing someone else with a similar question.

Meanwhile, I found out that activating Sapling with ALWAYS_ACTIVE _did_ have ill effects on testnet in a Zcash fork: trying to restart the node (that already has a chain) fails with an assertion failure. The lowest that actually works without triggering this issue is Overwinter with ALWAYS_ACTIVE and Sapling at block height 1.

[ioptio]

It should be possible to activate Sapling at the genesis block so this is likely a bug. Thank you!

[Eirik0]

Closing this ticket. Please add any further notes to #3730.