REGTEST Support for Mobile SDKs

[pacu]

In order to get REGTEST support on the mobile SDKs, certain changes must be accommodated. I don't have a 100% certainty of what they are but I'll start pouring some of them here.

Changes to Librustzcash

zcash_primitives

Add an enum that represents Regtest distinctively

pub enum Network {
    MainNetwork,
    TestNetwork,
    RegTestNetwork,
}

Provide Regtest variants to Parameters

pub trait Parameters: Clone

Make NetworkUpgrade Parameters variable.

REGTEST can be set up with different activation heights.

A RegTestNetwork struct should be able to provide these values according to the
environment that the caller is expecting.

pub const MAIN_NETWORK: MainNetwork = MainNetwork;

impl Parameters for MainNetwork {
    fn activation_height(&self, nu: NetworkUpgrade) -> Option<BlockHeight> {
        match nu {
            NetworkUpgrade::Overwinter => Some(BlockHeight(347_500)),
            NetworkUpgrade::Sapling => Some(BlockHeight(419_200)),
            NetworkUpgrade::Blossom => Some(BlockHeight(653_600)),
            NetworkUpgrade::Heartwood => Some(BlockHeight(903_000)),
            NetworkUpgrade::Canopy => Some(BlockHeight(1_046_400)),
            NetworkUpgrade::Nu5 => Some(BlockHeight(1_687_104)),
            #[cfg(feature = "zfuture")]
            NetworkUpgrade::ZFuture => None,
        }
    }

Provide Regtest-specificParameters trait values

the following values are constant and part of the Parameters trait

 fn coin_type(&self) -> u32 {
        constants::mainnet::COIN_TYPE
    }

    fn address_network(&self) -> Option<zcash_address::Network> {
        Some(zcash_address::Network::Regtest)
    }

    fn hrp_sapling_extended_spending_key(&self) -> &str {
        constants::regtest::HRP_SAPLING_EXTENDED_SPENDING_KEY
    }

    fn hrp_sapling_extended_full_viewing_key(&self) -> &str {
        constants::regtest::HRP_SAPLING_EXTENDED_FULL_VIEWING_KEY
    }

    fn hrp_sapling_payment_address(&self) -> &str {
        constants::maregtestinnet::HRP_SAPLING_PAYMENT_ADDRESS
    }

    fn b58_pubkey_address_prefix(&self) -> [u8; 2] {
        constants::regtest::B58_PUBKEY_ADDRESS_PREFIX
    }

    fn b58_script_address_prefix(&self) -> [u8; 2] {
        constants::regtest::B58_SCRIPT_ADDRESS_PREFIX
    }

zcash_client_backend

Add regtest encoding tests to encoding.rs
add regtest examples to zip321.rs

zcash_client_sqlite

no changes

zcash_extensions

no changes

zcash_history

no changes

Changes to Components

zcash_address

I don't think changes are needed but this assertion on zcash_address::Network::Regtest
might not hold after the changes in zcash_primitives

    /// For some address types there is no distinction between test and regtest encodings;
    /// those will always be parsed as `Network::Test`.
    Regtest,

zcash_encoding

No changes

Related GitHub Issues:

Electric-Coin-Company/zcash-swift-wallet-sdk#1233
Electric-Coin-Company/zcash-swift-wallet-sdk#1314

[str4d]

The main issue is that regtest mode is customizable. Just adding an enum case is not sufficient; you need a struct that can be configured with the regtest settings matching the full node you are using it with. And the available customization is not guaranteed to be the same across full nodes, so a one-size-fits-all type in these crates is not necessarily sufficient (but with the cooperation of relevant full node maintainers it might work).

zcashd already has a type that it uses to support (its implementation of) regtest mode (source). I implemented it as an enum that wraps the one in zcash_primitives, so we use the common global definition of mainnet and testnet, and then enhance it with the zcashd regtest configuration (which zcashd knows by construction):

enum Network {
    Consensus(zcash_primitives::consensus::Network),
    RegTest {
        overwinter: Option<BlockHeight>,
        sapling: Option<BlockHeight>,
        blossom: Option<BlockHeight>,
        heartwood: Option<BlockHeight>,
        canopy: Option<BlockHeight>,
        nu5: Option<BlockHeight>,
    },
}

[pacu]

Thanks @str4d for this insight.

If I were to change the Network enum to match this consensus and regtest I believe it can be much of a change in the whole code base, but it could also make Zcashd slimmer by just referencing this type instead.

I had another idea in mind but I'm not sure if it's possible in rust.

pub enum Network {
    MainNetwork,
    TestNetwork,
    RegTestNetwork(NetworkUpgradeValues),
}

pub struct NetworkUpgradeValues {
        overwinter: Option<BlockHeight>,
        sapling: Option<BlockHeight>,
        blossom: Option<BlockHeight>,
        heartwood: Option<BlockHeight>,
        canopy: Option<BlockHeight>,
        nu5: Option<BlockHeight>,
}

I think that if this construct is possible in Rust, this change can be implemented with less impact in the whole codebase.