Just one zero-configuration command will launch an internal
geth with reasonable settings for the genesis block and other parameters.
The testnet is a one-node proof-of-authority chain with a one second block time, so you never have to waste any CPU cycles on proof-of-work, and you get a snappy experience when deploying contracts and testing frontends.
Starting couldn’t be simpler — just run
dapp testnet. It doesn’t matter from which directory you run it. You should run the testnet in a separate terminal or
tmux tab or however you like.
When you quit the testnet with a Control-C in the terminal, all traces of the blockchain are nuked automatically, so you won’t have dead blockchains lying around.
In fact, you can run any number of independent testnets simultaneously by just starting them in different terminals. The RPC ports will increment starting at 2000.
Using the RPC node with Dapp and Seth
seth tools won’t automatically use your testnet, but just a couple of environment variables make it work. Note that the
~/.dapp/ folder has data about the testnet, like the whale account’s address.
export ETH_FROM=$(cat ~/.dapp/testnet/2000/config/account)
After this you can use
dapp create as usual to deploy contracts, or
seth balance to look up an ether balance, and so on.
An experimental feature runs your Solidity tests against the real testnet. If you want to beta test it, run
dapp test-geth-experimental. It takes a while and chews at your CPU. If it doesn’t work for you, file an issue or join our chat.
Installation and some notes on Nix
dapp testnet command is our first feature to integrate more deeply with Nix, the cross-platform hash-based package manager that we use to distribute our tools.
Thanks to Nix, you as a user don’t need to have Geth installed. It will be transparently and unobtrusively downloaded into the Nix store.
nix-channel --update && nix-env --upgrade
If you already have Geth installed, you don’t need to worry — there’s no effect on your
PATH or any of your system folders; the testnet’s node software is like a black box that you don’t have to worry about.
In fact, we use a very slightly patched version of the Go codebase. In order to support deploying very large integration testing contracts, we alter the constants that define the maximum sizes of bytecode and transaction data.
Patching is very easy with Nix, so we don’t have to maintain a fork. If you’re curious about how this works, look at the Nix package definition for the patched client. Our build server provides binaries of the patched client for both Linux and Mac.