Connecting to Public Test Networks

After you have written your contracts, and tried them out locally and tested them thoroughly, it’s time to move to a persistent public testing environment, where you and your beta users can start interacting with your application.

We will use public testing networks (aka testnets) for this, which are networks that operate similar to the main Ethereum network, but where Ether has no value and is free to acquire - making them ideal for testing your contracts at no cost.

In this guide, we will pick up our beloved Box contract, and deploy it to a testnet, while learning:

Remember that deploying to a public test network is a necessary step when developing an Ethereum project. They provide a safe environment for testing that closely mimics the main network - you don’t want to take out your project for a test drive in a network where mistakes will cost you money!

Available Testnets

There are four test networks available for you to choose, each with their own characteristics:

Ropsten

The only proof-of-work testnet. It has unpredictable block times and frequent chain reorganizations. At the same time, it is the chain that most closely resembles mainnet. (id=3)

Rinkeby

A proof-of-authority network. This means that new blocks are added by a set of pre-defined trusted nodes, instead of by whichever miner provides a proof-of-work. It only works with Geth clients, and has 15-second block times. (id=4)

Kovan

Another proof-of-authority network, but this one runs only with Parity clients, and has 4-second block times. (id=42)

Goerli

Also a proof-of-authority network, but compatible with both Geth and Parity clients, with 15-second block times. (id=6)

Each network is identified by a numeric ID. Local networks usually have a large random value, while id=1 is reserved for the main Ethereum network.

It is up to you whether you want to test in Ropsten’s unpredictable environment to assess how robust your application is, or a more reliable one to simplify the testing experience.

Connecting a Project to a Public Network

To connect our OpenZeppelin project to a public testnet, we will need to:

Accessing a Testnet Node

While you can spin up your own Geth or Parity node connected to a testnet, the easiest way to access a testnet is via a public node service such as Infura. Infura provides access to public nodes for all testnets and the main network, via both free and paid plans.

We say a node is public when it can be accessed by the general public, and manages no accounts. This means that it can reply to queries and relay signed transactions, but cannot sign transactions on its own.

Head over to Infura or a public node provider of your choice, sign up, and jot down your assigned project ID - we will use it later to connect to the network.

Creating a New Account

To send transactions in a testnet, you will need a new Ethereum account. There are many ways to do this: here we will use the mnemonics package, which will output a fresh mnemonic (a set of 12 words) we will use to derive our accounts:

$ npx mnemonics
pioneer tent curve wild ...
Make sure to keep your mnemonic secure. Even if it is just for testing purposes, there are still malicious users out there who will wreak havoc on your testnet deployment for fun!

Configuring the Network

Since we are using public nodes, we will need to sign all our transactions locally. We will use @truffle/hdwallet-provider to do this, setting it up with our mnemonic. We will also tell the provider how to connect to the test network by using the Infura endpoint.

This part assumes you have already set up a new OpenZeppelin project. If you haven’t, run oz init or head over to the guide on getting started with the CLI.

Let’s start by installing the provider:

$ npm install --save-dev @truffle/hdwallet-provider

Then, we will update our networks.js file with a new connection to the testnet. Here we will use Rinkeby, but you can use whichever you want:

+const { projectId, mnemonic } = require('./secrets.json');
+const HDWalletProvider = require('@truffle/hdwallet-provider');

 module.exports = {
   networks: {
     development: {
      ...
     },
+    rinkeby: {
+      provider: () => new HDWalletProvider(
+        mnemonic, `https://rinkeby.infura.io/v3/${projectId}`
+      ),
+      networkId: 4,
+      gasPrice: 10e9
+    }
   },
 };
See the HDWalletProvider documentation for information on configuration options.

Note in the first line that we are loading the project id and mnemonic from a secrets.json file, which should look like the following, but using your own values. Make sure to .gitignore it!

{
  "mnemonic": "pioneer tent curve wild ...",
  "projectId": "305c13705054a8d918ad77549e402c72"
}
Instead of a secrets.json file, you can use whatever secret-management solution you like for your project. A popular and simple option is to use dotenv for injecting secrets as environment variables.

We can now test out that this configuration is working by listing the accounts we have available for the Rinkeby network. Remember that yours will be different, as they depend on the mnemonic you used.

$ npx oz accounts
? Pick a network rinkeby
Accounts for rinkeby:
Default: 0xc38C62Af27e329aD58e889E7AE3070B1db571eB0
All:
- 0: 0xc38C62Af27e329aD58e889E7AE3070B1db571eB0
- 1: 0xE8595815B50088fd4371f2E52fb2F5eeAfd654ac
- 2: 0x1Ad3B46f8d23d84380c618F4aD33Bf49E2Df7f25
- 3: 0xebfb88b31bdDead46a909276D3A69e2b712A2Aa3
...

We can also test the connection to the Infura node, by querying our account balance.

$ npx oz balance
? Enter an address to query its balance 0xc38C62Af27e329aD58e889E7AE3070B1db571eB0
? Pick a network rinkeby
Balance: 0 ETH
0

Empty! This points to our next task: getting testnet funds so that we can send transactions.

Funding the Testnet Account

Most public testnets have a faucet: a site that will provide you with a small amount of test Ether for free. If you are on Rinkeby, head on to the Rinkeby Authenticated Faucet to get funds by authenticating with your Twitter or Facebook account. Alternatively, you can also use MetaMask’s faucet to ask for funds directly to your MetaMask accounts.

Armed with a funded account, let’s deploy our contracts to the testnet!

Working on a Testnet

With a project configured to work on a public testnet, we can now finally deploy our Box contract. The command here is exactly the same as if you were on your local development network, though it will take a few seconds to run as new blocks are mined.

$ npx oz deploy
✓ Compiled contracts with solc 0.6.7 (commit.b8d736ae)
? Choose the kind of deployment regular
? Pick a network rinkeby
? Pick a contract to deploy Box
✓ Deployed instance of Box
0xA1a05372ECD1353105543ee46C8AA447547C6680

That’s it! Your Box contract instance will be forever stored in the testnet, and publicly accessible to anyone. The OpenZeppelin CLI will keep track of this and all your deployed contracts in .openzeppelin/rinkeby.json, so you can easily refer to them later, such as when upgrading or interacting with them.

You can see your contract on a block explorer such as Etherscan. Remember to access the explorer on the testnet where you deployed your contract, such as rinkeby.etherscan.io for Rinkeby.

You can check out the contract we deployed in the example above, along with all transactions sent to it, here.

You can also interact with your instance as you regularly would, either using the call and send-tx CLI commands, or programmatically using web3. You can also upgrade your contracts via oz upgrade as you add new features to your staging project!

$ npx oz send-tx
? Pick a network rinkeby
? Pick an instance Box at 0xA1a05372ECD1353105543ee46C8AA447547C6680
? Select which function store(newValue: uint256)
? newValue: uint256: 42
✓ Transaction successful. Transaction hash: 0xd6ef798b1c85f5dca1cf4b27f8544d6333dd1ab1f83e61a19f2cb3df203e638c
Events emitted:
 - ValueChanged(42)

Keep in mind that every transaction will cost some gas, so you will eventually need to top up your account with more funds.

Next Steps

After thoroughly testing your application on a public testnet, you are ready for the last step on the development journey: deploying your application in production.