Dash Devnets

Dash developer networks explained

What are devnets?

With the release of Dash Core 12.3, Dash added support for a great new feature — named devnets. Devnets are developer networks that combine some aspects of testnet (the global and public testing network) and some aspects of regtest (the local-only regression testing mode that provides controlled block generation). Unlike testnet, multiple independent devnets can be created and coexist without interference. Each one is identified by a name which is hardened into a “devnet genesis” block that is automatically positioned at height 1. Validation rules ensure that a node from devnet=test1 cannot accept blocks from devnet=test2. This is done by checking the expected devnet genesis block. Additionally, the devnet name is put into the sub-version of the version message so a node connecting to the wrong network will immediately be disconnected.

Eventually, there will be many public and/or private devnets that all vary in size and function. Providing the correct devnet name and the seed node of the network will be all that is required to join. An old devnet can be easily dropped and a new one started just by destroying all nodes and recreating them with a new devnet name.

Why are devnets useful?

As you can guess from the description, devnets are primarily useful as a development tool. They provide significantly more flexibility than testnet since they can be created for specific purposes and operated in controlled settings. We expect that devnets will be used in situations that require the ability to do things like test code base / protocol changes that are incompatible with mainnet/testnet, fully control block generation on a live network, and restrict network access to specific parties.

Examples for this include:

• Development — Develop/test new features on real networks without impacting the existing testnet
• Research — Complete realistic analysis of blockchain/network performance in a controlled environment
• Education — Provide practical, hands-on training with minimal overhead
• Integrations — Development/testing on private networks

Devnets have already been utilized by Dash developers to test possible future enhancements on devnet networks containing 3000+ nodes.

How can I create a devnet?

Fortunately, devnets are easy to configure. The steps below will describe the process of setting up a devnet. The devnet name in the instructions (“dashblog”) is a currently active devnet that should remain accessible for the next few weeks.

Start Dash Core with devnet parameters

Configuring a new devnet consists of starting Dash Core with several configuration (config file or command line) options enabled. The primary parameters are:

• devnet — Defines the name of the network
• port — Port to listen for P2P connections (default: 19999)
• rpcport — Port to listen for RPC connections (default: 19998)

An example Dash Core configuration file for a devnet named “dashblog” is shown below (it also defines the RPC user and password):

devnet=dashblog
port=19999
rpcport=19998rpcuser=myuser
rpcpassword=mypasswordsporkaddr=yXDzZ3eu3GCAHcTCZvgFVkL16qguZJmtww# FYI, this is not the correct spork key for the dashblog devnet, this just serves as an example
sporkkey=cTwYCkbKw4EneV6aNG4XAJ6qNGr7zrQEp1NRFSRKf8Ay5BhRBbSX

To start the devnet defined in the configuration file, run dashd with the -conf option set to the full path of your configuration file:

dashd -conf=/home/user/.dashcore/mydevnet.conf

Dash will also create a dedicated subfolder inside the default Dash data directory. This subfolder is specific to the devnet and won’t conflict with other Dash networks. It contains all the usual data needed by Dash, for example the blockchain data and the wallet data.

The sporkaddr and sporkkey options define the keys required to issue sporks in the devnet. These are represented in the same form as normal Dash addresses and exported private keys. Just use the getnewaddress and dumpprivkey RPC APIs with a devnet or regtest node to generate keys for your own devnet.

Establish an initial connection

A devnet consisting of a single node is not very interesting, so multiple nodes are started using the same parameters. These nodes can be run on the same network or distributed across the internet.

After starting multiple nodes with the same devnet parameters, an initial addnode command must be run to establish connections between the nodes for the first time. This is because the DNS seed discovery mechanism used for mainnet/testnet does not apply to the ad hoc nature of devnets.

The command for connecting to another devnet peer is:

dash-cli -conf=/home/user/.dashcore/mydevnet.conf addnode “devnet.thephez.com:19999” “add”

Alternatively, a known peer can be defined in the Dash Core configuration file as shown below:

# Also include the general devnet options from above here
...# Hard-coded first node
addnode=devnet.thephez.com:19999

Once a peer has been successfully connected to, it should reconnect automatically in the future. As additional nodes are added to a devnet, the getaddr/ addr P2P messages will enable nodes to discover other peers on the network in the same way that mainnet and testnet do.

Use the devnet

Once the devnet is successfully bootstrapped and multiple nodes are able to communicate with each other, it is ready to be used. Blocks are generated using the generate RPC (the same controlled way as a regtest network). This can be done by manually calling the RPC or in an automated way (e.g. cron, etc.) depending on the development environment requirements.

This example cron would create 1 new block every 5 minutes:

*/5 * * * * dash-cli -conf=/home/user/.dashcore/mydevnet.conf generate 1

Otherwise, running the generate command manually will accomplish the same thing:

dash-cli -conf=/home/user/.dashcore/mydevnet.conf generate 1

At this point, you’re ready to begin using the devnet for its intended purposes. You can send transactions, set up masternodes, do PrivateSend mixing, etc. Use of masternode-dependent features like InstantSend and Privatesend will require setting up masternodes on your devnet. The process is identical to mainnet/testnet masternode setup; however, you will need to generate coins via the generate RPC (described above) to get the masternode collateral. The network size is only limited by the resources you have available. If you run into unexpected issues, you can reset the devnet by shutting down all nodes, deleting their data directories (~/.dashcore/devnet-<devnetname> by default), and restarting them.

Now go have some fun and let us know what interesting use cases you discover!

References

A repository containing a couple basic Linux shell scripts for setting up a devnet can be found here — https://github.com/thephez/dash-devnet-setup. The repository also contains an example configuration file that can be used to connect to the “dashblog” devnet used as the example.