Does regtest have a future?

The question has been raised whether regtest is important and whether it has a future. An application developer currently does not have that many services they rely on. But it is very likely that as the ecosystem develops and there are more and more useful third party services they opt to use, these may not be available in the developer’s regtest environment.

If you don’t know what regtest is, it is the ability to run a node with a test blockchain that you are in control of. You start the node in regtest mode and generate blocks whenever you want. You can get coins on demand, and test confirmation logic and more.

This article is not intended to advocate for keeping regtest alive, if it cannot survive future complexity. It is however hoping to raise the subject and get feedback from people who may or may not have thought about the subject. Can we keep regtest alive? Will it have limited utility? Will it even be practical? Let’s explore this a little.

My current regtest environment

The following is representative of how I use regtest daily.

  1. I start a local node.
  2. I start a local merchant api service.
  3. I start a local block headers client service.
  4. I start other services that run alongside these, from the DPP proxy server for modern invoiced payments to a blockchain indexer that enables legacy payments.
  5. I broadcast a test blockchain with a range of different transaction types, from P2SH multi-signature, P2PKH to P2PK.
  6. I start ElectrumSV and connect to the services and then restore a wallet, and check that the full wallet history is available and it is full of confirmed coins.
  7. Now I run the manual testing scenarios that are related to a change I have made to ElectrumSV, usually involving two ElectrumSV wallets running independently against the services.

All of the first six steps can be done in seconds, providing me with a consistent testing environment. If I reproduce something, but lose the state that can be examined, I can tear it all down and build it all up step by step.

Perhaps I have modified the MAPI server selection logic. I can see that when I use the GUI to send a legacy payment from the funded wallet via MAPI broadcast, it is received by the recipient wallet. I can see that when I send a payment using the new JSON-RPC node wallet approximate API, it also sends without error.

It is one thing to run unit tests, it is another to be able to contrive a realistic test stack and to see that the representative set of services and the wallet all interoperate together as expected. It is another yet to be able to do this on my laptop on a plane without a network connection.

The future regtest environment

I’ve already alluded to the unknown practicalities of continuing to use regtest, especially if developers rely on third party services. Let’s look at a few examples of the possible problems.

The future of the node

What is the future of the node? I do not know. Where does it stand in relation to the coming of teranode? I do not know. What if the node is going to be deprecated and it is not practical to use teranode in a lightweight on-demand regtest type scenario?

There’s a large value in using the same code that is used in production. You are testing the edge cases of all the consensus rules implemented with the code that the miners are enforcing. You know that if you can do it locally or cannot do it using the regtest node, it is a high certainty that this is representative of how your code will work on mainnet.

Regtest users do not want to be in the business of developing a locally runable replacement node, in the event both the node and teranode go away. There is just too much work ensuring it is compatible and opportunity for unforeseen failures to arise.

External service dependencies

Developers who have applications that run against mainnet cannot run their own node. It is not practical any more. More practical is running an SPV client, that listens to the P2P network for headers and to broadcast. This should be the same for both hosted services and client-side applications, although the client-side application may find itself in a limited network environment.

Next there’s a level of direct blockchain state that is best obtained from third party services, that are most likely to be run by miners.

  • This might be the appearance of data in the future, like the payment to an output script, which can be used to detect legacy payments.
  • It might be a stream of transactions related to an identifier that relate to an on-chain protocol, where the current state of that protocol requires processing all matching transactions since the genesis of that custom protocol.
  • It might be the ability to poll the state of UTXOs in order to verify an SPV payment.
  • It might be the ability to get notified about the changes in your UTXO state, so you know when they are ready to use for payments.

If there’s a community of developers who keep regtest viable, it is possible they maintain regtest facades that emulate the different blockchain state-related third party service APIs.

Another possibility is that a developer relies on a non-mining business’ custom APIs, and would need these on regtest. Is it worth their time to make representative versions of these for regtest? Is it even possible, given the service that the business provides? More than likely not. Maybe, just maybe, depending on what the service does and how popular they are developers might be inclined to build emulation tools on regtest.

Your needs and thoughts

So do you use regtest? How do you use it? What benefit do you gain from using it, rather than just testing against mainnet or testnet? If you had a viable and reliable source of test coins for testnet, that provided you with all the coins you needed on demand, would that be good enough?

What would you need to be in place to ensure regtest was usable in the future? Do you think it is worth preserving?

Very interested in hearing your thoughts.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store