Deploy Nodes

A Devnet will generally have two or more nodes. For our use case we will deploy four nodes, one for each participant. Each node will required an execution client and a consensus client. To set up each node you need to follow a series of steps and create reasonably complex configuration files.

There are two steps required to deploy a node:

1. Create a node

This step creates the directories required to store the node data and the configuration files for the node. It also creates the account that will be used to operate the node along with its address and private key, which are important when maintaining and ether balance and executing trasnactions.

2. Run the node

This step will start execution of the node. It will first sync up with all other nodes in the network through a process of discovery based on the configuration data, and then start mining blocks, which is an indication that it is ready to execute transactions in the network.

Deployment Script

To simplify this process we have created a script (deploy_nodes.sh) that guides you through the steps required, allows you to make some configuration choice, but largely pre-configures and automates the tasks required to get a Devnet up and running.

The script will have to be run for each of the steps above and for each node with the appropriate choices and configuration data (currently the scripts only allows the creation of upto 4 nodes for which it will have to be run 8 times). One node uses the Prysm consensus client while the other three nodes use the Lighthouse consensus client.

There is a second script (reset_devnet.sh) that shuts down the devnet if required. There are two options when resetting:

• You can stop the running nodes and keep all the data. In which case you do not need to recreate the nodes, only run them again. Any Smart Contracts you had deployed (and any data in the contracts) on the Blockchain will continue to be available.

• You can stop the running nodes and delete all node (and the entire blockchain) data. In which case you need to recreate all nodes and run them all over again. Any Smart Contracts you had deployed (and any data in the contracts) on the Blockchain will be deleted and will have to be redeployed with none of the data from before.

Running the scripts

Download the scripts and templates in the working directory (we have named it devnet) and run the following command to make the two script files executable:

chmod +x ./deploy_nodes.sh
chmod +x ./reset_devnet.sh

The scripts should be run from inside the working directory and the templates should be stored in the same directory as the scripts. Every time the script is executed it will create a directory for the node to save all its configuration and data. The node directories will have fixed names (node1, node2, and so on).

Refer to the file structure below (assuming devnet is your working directory):

/devnet
/node1
/node2
/node3
/node4
- deploy_nodes.sh
- reset_devnet.sh
- genesis_template.json
- config_template.yaml

Under the Hood

While it is not necessary to understand each of the steps since the script does it all for you, it is always good to know what is happening under the hood. Also, some of the data created during the deployment process is required to use the node later. A simplified explanation of the steps is provided below.

Creating Nodes

This script is customized for this solution so upto 4 nodes can be created and the nodes must be created in a predefined sequence, starting with node 1, followed by node 2, and so on, until node 4.

There are two combinations of execution and consensus clients used in this solution:

• Nodes 1, 3, and 4 use geth + Lighthouse
• Node 2 uses geth + Prysm

The steps for creating Node 1 are listed below:

• The folder structure for the node is created with the execution and consensus directories for the execution and consensus client respectively.
• An account is generated and the ether to be allocated (as input by the user) is updated in the genesis file (using the jq library and the genesis.json as a reference) which is used by the geth command to initialize the node.
• Mnemonics and validator keys for the node are generated. These mnemonics are stored in a mnemonic.yaml file.
• All the mnemonics under this file are activated at genesis when genesis.ssz is created, so there is no need to do manual staking of 32 ETH to the network.
• These validator keys will be imported into the validator client when running the node
• Finally, a JWT token is generated that will be used to authenticate the connection between the execution and the consensus client within a node.

Node 1 is created. The same steps are followed to create nodes 2,3 and 4 with the difference that new genesis.json and mnemonic.yaml files are not created, rather those created for node 1 are updated to pre-allocate balance to accounts and add mnemonics to activate validators. The genesis.json and mnemonic.yaml files are later copied from node 1 directories after node 1 is started.

Running Nodes

Node 1 must be the first node to run in the devnet. The following steps are executed:

• In genesis.json, the timestamp and config.shanghaiTime fields are updated to the current Unix time and current Unix time + 384 seconds respectively.
• The geth node is initialised using the updated genesis.json file
• The geth execution client is started. The geth javascript console is also immediately started and the genesis block's hash is returned.
• config.yaml file is created using the yq library and the config_template.yaml as a reference.
• The genesis block's hash retrieved in the previous step is stored against the key TERMINAL_BLOCK_HASH and the MIN_GENESIS_TIME is set to the current Unix time generated in step 1.
• The genesis.ssz file is generated using the eth2-testnet-genesis library using the updated genesis.json, config.yaml and the mnemonic.yaml files.
• Finally, the Beacon client is started.
• After a short delay, the validator keys are imported into the validator client, and the validator client is started to begin block production.

To run nodes 2, 3, and 4 (node 1 must already be running) the following pre-requisite steps are completed:

• genesis.json, config.yaml, and the genesis.ssz files are copied from the node 1 directory.
• The geth node is initialised.
• Validator keys are imported into the validator client

The node is now redy to run. Start the geth execution client, then the beacon client, and finally the validator client sequentially.