How to set up an Ethereum development environment [Tutorial]

There are various ways to develop Ethereum blockchain. We will look at the mainstream options in this article which are:

  • Test networks
  • How to setup Ethereum private net

There are multiple ways to develop smart contracts on Ethereum. The usual and sensible approach is to develop and test Ethereum smart contracts either on a local private net or a simulated environment, and then it can be deployed on a public testnet. After all the relevant tests are successful on public testnet, the contracts can then be deployed to the public mainnet.

There are however variations in this process, and many developers opt to only develop and test contracts on locally simulated environments. Then deploy on public mainnet or their private production blockchain networks. Developing on a simulated environment and then deploying directly to a public network can lead to faster time to production. As setting up private networks may take longer compared to setting a local development environment with a blockchain simulator.

Let’s start with connecting to a test network.

Ethereum connection on test networks

The Ethereum Go client (https://geth.ethereum.org) Geth, can be connected to the test network using the following command:

$ geth –testnet

A sample output is shown in the following screenshot. The screenshot shows the type of the network chosen and various other pieces of information regarding the blockchain download:

The output of the geth command connecting to Ethereum test net

A blockchain explorer for testnet is located at https://ropsten.etherscan.io can be used to trace transactions and blocks on the Ethereum test network.

There are other test networks available too, such as Frontier, Morden, Ropsten, and Rinkeby. Geth can be issued with a command-line flag to connect to the desired network:

--testnet: Ropsten network: pre-configured proof-of-work test network

--rinkeby: Rinkeby network: pre-configured proof-of-authority test network

--networkid value: Network identifier (integer, 1=Frontier, 2=Morden (disused), 3=Ropsten, 4=Rinkeby) (default: 1)

Now let us do some experiments with building a private network and then we will see how a contract can be deployed on this network using the Mist and command-line tools.

Setting up a private net

Private net allows the creation of an entirely new blockchain. This is different from testnet or mainnet in the sense that it uses its on-genesis block and network ID. In order to create private net, three components are needed:

  • Network ID
  • The Genesis File
  • Data directory to store blockchain data. Even though the data directory is not strictly required to be mentioned, if there is more than one blockchain already active on the system, then the data directory should be specified so that a separate directory is used for the new blockchain.

On the mainnet, the Geth Ethereum client is capable of discovering boot nodes by default as they are hardcoded in the Geth client, and connects automatically. But on a private net, Geth needs to be configured by specifying appropriate flags and configuration in order for it to be discoverable by other peers or to be able to discover other peers. We will see how this is achieved shortly.

In addition to the previously mentioned three components, it is desirable that you disable node discovery so that other nodes on the internet cannot discover your private network and it is secure. If other networks happen to have the same genesis file and network ID, they may connect to your private net. The chance of having the same network ID and genesis block is very low, but, nevertheless, disabling node discovery is good practice, and is recommended.

In the following section, all these parameters are discussed in detail with a practical example.

Network ID

Network ID can be any positive number except 1 and 3, which are already in use by Ethereum mainnet and testnet (Ropsten), respectively. Network ID 786 has been chosen for the example private network discussed later in this section.

The genesis file

The genesis file contains the necessary fields required for a custom genesis block. This is the first block in the network and does not point to any previous block. The Ethereum protocol performs checking in order to ensure that no other node on the internet can participate in the consensus mechanism unless they have the same genesis block. Chain ID is usually used as an identification of the network.

A custom genesis file that will be used later in the example is shown here:

{

"nonce": "0x0000000000000042",

"timestamp": "0x00", "parentHash":

"0x0000000000000000000000000000000000000000000000000000000000000000",

"extraData": "0x00",

"gasLimit": "0x8000000", "difficulty": "0x0400", "mixhash":

"0x0000000000000000000000000000000000000000000000000000000000000000", "coinbase": "0x3333333333333333333333333333333333333333",

"alloc": {
},

"config": {

"chainId": 786,

"homesteadBlock": 0,

"eip155Block": 0,

"eip158Block": 0

}

}

This file is saved as a text file with the JSON extension; for example, privategenesis.jsonOptionally, Ether can be pre-allocated by specifying the beneficiary’s addresses and the amount of Wei, but it is usually not necessary as being on the private network, Ether can be mined very quickly.

In order to pre-allocate a section can be added to the genesis file, as shown here:

"alloc": {

"0xcf61d213faa9acadbf0d110e1397caf20445c58f ": { "balance": "100000" },

}

Now let’s see what each of these parameters mean.

  • nonce: This is a 64-bit hash used to prove that PoW has been sufficiently completed. This works in combination with the mixhash parameter.
  • timestamp: This is the Unix timestamp of the block. This is used to verify the sequence of the blocks and for difficulty adjustment. For example, if blocks are being generated too quickly that difficulty goes higher.
  • parentHash: This is always zero being the genesis (first) block as there is no parent of the first block.
  • extraData: This parameter allows a 32-bit arbitrary value to be saved with the block.
  • gasLimit: This is the limit on the expenditure of gas per block.
  • difficulty: This parameter is used to determine the mining target. It represents the difficulty level of the hash required to prove the PoW.
  • mixhash: This is a 256-bit hash which works in combination with nonce to prove that sufficient amount of computational resources has been spent in order to complete the PoW requirements.
  • coinbase: This is the 160-bit address where the mining reward is sent to as a result of successful mining.
  • alloc: This parameter contains the list of pre-allocated wallets. The long hex digit is the account to which the balance is allocated.
  • config: This section contains various configuration information defining chain ID, and blockchain hard fork block numbers. This parameter is not required to be used in private networks.

Data directory

This is the directory where the blockchain data for the private Ethereum network will be saved. For example, in the following example, it is ~/etherprivate/.

In the Geth client, a nu mber of parameters are specified in order to launch, further fine-tune the configuration, and launch the private network. These flags are listed here.

Flags and their meaning

The following are the flags used with the Geth client:

  • –nodiscover: This flag ensures that the node is not automatically discoverable if it happens to have the same genesis file and network ID.
  • –maxpeers: This flag is used to specify the number of peers allowed to be connected to the private net. If it is set to 0, then no one will be able to connect, which might be desirable in a few scenarios, such as private testing.
  • –rpc: This is used to enable the RPC interface in Geth.
  • –rpcapi: This flag takes a list of APIs to be allowed as a parameter. For example, eth, web3 will enable the Eth and Web3 interface over RPC.
  • –rpcport: This sets up the TCP RPC port; for example: 9999.
  • –rpccorsdomain: This flag specifies the URL that is allowed to connect to the private Geth node and perform RPC operations. cors in –rpccorsdomain means cross-origin resource sharing.
  • –port: This specifies the TCP port that will be used to listen to the incoming connections from other peers.
  • –identity: This flag is a string that specifies the name of a private node.

Static nodes

If there is a need to connect to a specific set of peers, then these nodes can be added to a file where the chaindata and keystore files are saved.

For example, in the ~/etherprivate/ directory. The filename should be static- nodes.json. This is valuable in a private network because this way the nodes can be discovered on a private network. An example of the JSON file is shown as follows:

[

"enode:// 44352ede5b9e792e437c1c0431c1578ce3676a87e1f588434aff1299d30325c233c8d426fc5 7a25380481c8a36fb3be2787375e932fb4885885f6452f6efa77f@xxx.xxx.xxx.xxx:TCP_P ORT"

]

Here, xxx is the public IP address and TCP_PORT can be any valid and available TCP port on the system. The long hex string is the node ID.

This article has been published from the source link without modifications to the text. Only the headline has been changed.

Source link