New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add regtest support to Parameter
for Mobile SDKs
#1054
Conversation
Parameter
Parameter
to support Mobile SDKs
Parameter
to support Mobile SDKsParameter
for Mobile SDKs
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1054 +/- ##
==========================================
+ Coverage 66.17% 66.24% +0.07%
==========================================
Files 114 115 +1
Lines 11063 11089 +26
==========================================
+ Hits 7321 7346 +25
- Misses 3742 3743 +1 ☔ View full report in Codecov by Sentry. |
3b0af31
to
e497fb6
Compare
zcash_primitives/src/consensus.rs
Outdated
RegtestNetwork { | ||
overwinter: Option<BlockHeight>, | ||
sapling: Option<BlockHeight>, | ||
blossom: Option<BlockHeight>, | ||
heartwood: Option<BlockHeight>, | ||
canopy: Option<BlockHeight>, | ||
nu5: Option<BlockHeight>, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a transparent enum variant (which is harder to make changes to later, as its internals are in the public API), move this to a pub struct RegtestNetwork {..}
. Then the enum variant can be Regtest(RegtestNetwork)
.
I'm also not convinced that we should add a Regtest
variant to the main Network
enum. zcash_primitives::consensus::Network
is a consensus network type, and only the main and test networks are consensus networks. Regtest mode is solely for local testing purposes, and in particular depends on the full node; zcashd
supports its definition of regtest, while zebrad
has no support for any kind of regtest mode (though I recall hearing vague whispers of some kind of local test network support that might be coming soon - cc @teor2345 et al).
I think regtest support (or more generally, user-configurable test networks) should be provided with a separate type that downstreams can opt into, similar to what we do in zcashd
, and that lives somewhere other than zcash_primitives::consensus
(maybe zcash_primitives::testing
):
pub enum ZcashdNetwork {
Consensus(consensus::Network),
RegTest(RegTestNetwork),
}
We could even retire the "regtest" name if we want to instead define this as a fully locally-defined test network capability (where zcashd
's regtest
mode configures only a subset of the available options):
pub enum FullNodeParameters {
Consensus(consensus::Network),
Local(LocalNetwork),
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're working on basic support for other networks, but I'm not sure when that will be scheduled or complete. We're focused on the shielded scanner right now.
@arya2 might also have something to add here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @str4d for your review. I agree with this quote below.
I think regtest support (or more generally, user-configurable test networks) should be provided with a separate type that downstreams can opt into, similar to what we do in zcashd, and that lives somewhere other than zcash_primitives::consensus (maybe zcash_primitives::testing)
The only thing I would differ is that we need to be able to use regtest from clients to have the integration tests like the advanced ReOrg tests. So we would need to access this RegtestNetwork types from the FFI.
I chose consensus::Network mostly for two reasons:
- other crates were referring to it
- The FFI uses that
And no others, so I'm definitely ok with refactoring this so that it's more convenient for today's reality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FFI uses it
To clarify, the FFI itself uses numeric constants for the kinds of networks it knows about, and then converts those into a consensus::Network
. So the way for the iOS SDK to opt in to testing with a configurable local network is to change that helper function to use the new type that supports local testing. That change makes sense because the iOS SDK won't be able to do local testing without a bunch of other changes on its Swift side.
other crates were referring to it
If we change consensus::Network
then some other crates using it may be forced to do that same bunch of work (depending on how they use the enum) that they don't want to do (perhaps because they are only concerned with the consensus networks).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the Consensus
and LocalNetwork
approach I'll give it a go and we can take it from there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@str4d I think the changes I pushed might be heading into the right direction
@pacu sorry that we didn't get this in earlier; it's now conflicted, so can you please rebase and I'll re-review? |
No worries. I'll rebase it! Thanks |
5561dd0
to
39e1123
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I missed this before, but the additions need rustdoc & CHANGELOG entries, and the feature flag needs to be added to Cargo.toml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK modulo a few additional documentation suggestions.
@pacu builds are currently failing? |
They don't fail for me locally but I'm not running an ubuntu target. It seemed intermittent to me. do we have some script to build all the different targets or is that something you folks delegate to CI? |
closes zcash#1051 Also: Adds encoding tests + cargo fmt Adds tests on ZIP-321 Adds coverage on new code Supports nu6 activation `local-consensus` feature is disabled by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 09bbc79
@@ -132,6 +132,8 @@ unstable-nu6 = [] | |||
## Exposes early in-development features that are not yet planned for any network upgrade. | |||
zfuture = [] | |||
|
|||
## Exposes support for working with a local consensus (e.g. regtest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Exposes support for working with a local consensus (e.g. regtest | |
## Exposes support for working with a local consensus (e.g. regtest). |
Non-blocking.
/// a `LocalNetwork` setup should define the activation heights | ||
/// of network upgrades. `None` is considered as "not activated" | ||
/// These heights are not validated. Callers shall initialized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// a `LocalNetwork` setup should define the activation heights | |
/// of network upgrades. `None` is considered as "not activated" | |
/// These heights are not validated. Callers shall initialized | |
/// A `LocalNetwork` setup should define the activation heights | |
/// of network upgrades. `None` is considered as "not activated" | |
/// These heights are not validated. Callers should initialize |
Non-blocking.
/// nu6: Some(BlockHeight::from_u32(1)), | ||
/// #[cfg(feature = "zfuture")] | ||
/// z_future: Some(BlockHeight::from_u32(1)), | ||
/// }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// }; | |
/// }; |
Non-blocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK, non-blocking doc-only suggestions.
closes #1051