Tracking: Add regtest network
Motivation
This has been requested, and could be useful for testing.
Depends-On: #7845
Possible Design
- [x] #7839
- [x] #8327
- [x] Disable peer connections (or only connect to nodes with the same network magic)
- Skip loading checkpoints and update
NetworkUpgrade::activation_heightto use zcashd defaults or user-defined heights- [x] #7846
- [x] #8479
- [x] remove the implementation constraint that
PoWLimitmust be less than or equal to(2^256 - 1) / PoWAveragingWindow(approximately2^251) to avoid overflow - [x] calculate difficulty adjustment for heights less than 17
- [x] remove the implementation constraint that
- [x] Skip
SLOW_START_INTERVALchecks (nSubsidySlowStartIntervalis 0 for regtest in zcashd) - [x] #8478
- [x] #8361
- [x] https://github.com/ZcashFoundation/zebra/issues/9182
- [ ] https://github.com/ZcashFoundation/zebra/issues/8367
- [ ] Update prefixes (optional)
- Match other differences between zcashd testnet vs regtest in chainparams
These are just some notes for if we eventually do this ticket. No action is needed at this time.
We might also want to take a look at:
- #1135
It seems like some of these changes would benefit from the Regtest variant containing a consensus rule configuration. (Like zcashd has for all its network variants.)
It would also be a lot easier to make this change if we refactored all our network conditions into methods on the Network enum. For example, a has_slow_start() method, rather than a match statement buried in the zebra-consensus code.
- update
From<Network> for &'static strfordb_path()
We either need to work out how to make sure the consensus rules match the cached state, or make regtest ephemeral by default.
This isn't an issue for mainnet or testnet because their rules are fixed and can't be configured.
- Set
peerset_initial_target_sizeto 0 (Zebra should not make any peer connections)
This change isn't enough to stop Zebra making outbound connections, because Zebra will try to connect to new peers every minute or so. Instead, the initial seed peers list needs to be empty for regtest.
- Update prefixes
Which prefixes?
- Match other differences between zcashd testnet vs regtest in chainparams
If we're not going to connect to other nodes by default, then compatibility with zcashd seems like a lower priority. So we might want to categorise this ticket into:
- changes needed to have a regtest mode
- changes requested by the people who requested regtest mode (please link to the request in the ticket)
- other changes that are useful for full compatibility with zcashd
That way, when we schedule this work, we can split the ticket, give the categories different priorities, then do the estimates.
Here's one request for regtest in Zebra: https://twitter.com/thecodebuffet/status/1674606998908727297
Screenshot in case twitter goes down:
This is currently blocked by some kind of network refactor. (It doesn't have to be #1135 specifically.)
Hey team! Please add your planning poker estimate with Zenhub @arya2 @oxarbitrage @teor2345 @upbqdn
@mpguerra this ticket is outdated. @arya2 and I have had some private conversations about it, and I think we should update it before we estimate it. (Or replace it with another ticket.)
For example:
I'd like to split the tasks in this ticket based on what the ZSA team needs for their testing, then do the rest of regtest later.
- Add a
Regtestvariant toNetwork, updateFrom<Network> for &'static strfordb_path(), default port, and genesis hash
It will be much easier to gradually add network settings inside the existing Testnet variant. Adding new variants requires changing a lot of code.
- Add config field or CLI option for accepting network upgrade heights
This should be split into a different ticket, it's not required to match the default zcashd regtest.
I added these issues to the ticket description, we might need to fix them depending on the required scope:
- difficulty adjustment for heights less than 17
- contextual validation of the genesis block (it has to be a checkpoint)
https://github.com/ZcashFoundation/zebra/pull/7770#discussion_r1364969449
Personally, the lack of regtest support blocks me from moving to zebrad because it is too hard to write integration tests.
Personally, the lack of regtest support blocks me from moving to zebrad because it is too hard to write integration tests.
@hhanh00 Is it enough for Zebra to support NU5 on its Regtest, or is it important that Zebra support Canopy and prior network upgrades on Regtest as well?
Just nu5 is enough but I would also need the ability to generate, invalidate and reconsider blocks. This is how the project I work on tests forks and reorganizations.