Ethereum private network configuration guide.

Ethereum_private_network.md

Create your own Ethereum private network

Introduction

Used nodes:

Linux raspberrypi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux

Linux localhost.localdomain 4.14.5-200.fc26.x86_64 #1 SMP Mon Dec 11 16:29:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Darwin 0mkars-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

3 physical machines were used as 3 Ethereum nodes for this experiment. Ethereum node on Raspberrypi was setup to act as bootnode. Other two Ethereum nodes were connected to the bootnode by setting --bootnode parameter.

Installation

Please follow standart setup process or use prebuilt binaries from https://geth.ethereum.org/downloads/

Create custom Ethereum network

Following the bellow steps we will create our private Ethereum testnet.

Create a genesis.json file:

vi genesis.json

Insert following lines:

{
  "config": {
        "chainId": 0,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip158Block": 0
    },
  "alloc"      : {},
  "coinbase"   : "0x0000000000000000000000000000000000000000",
  "difficulty" : "0x20000",
  "extraData"  : "",
  "gasLimit"   : "0x2fefd8",
  "nonce"      : "0x0000000000000042",
  "mixhash"    : "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash" : "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp"  : "0x00"
}

A genesis block is the first block of a blockchain. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1. The genesis block is almost always hardcoded into the software. It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.

For detailed explanation of genesis file component see here.

Create our bootnode on Raspberrypi

Setup geth on your Raspberrypi and run following commands to start bootnode

bootnode --genkey=boot.key
bootnode --nodekey=boot.key

This will start bootnode and we will have our bootnode address INFO [12-27|15:22:12] UDP listener up self=enode://865655f2a55c792aa4749d00bf24431fc4b3f686948a047c1f1f3b2569b368900a462cb1658e288f513ab42a3aef74d14d1ee1bac445678aab954ed4b8a90fd8@[::]:30301

Initialize network and start geth console:

Iniatialize a geth node with custom genesis

geth --datadir="~/test/" init genesis.json

NOTE: Perform above process on both nodes. genesis.json needs to be identical on both nodes.

Then we can start our nodes with --bootnode option as

geth --bootnodes="enode://865655f2a55c792aa4749d00bf24431fc4b3f686948a047c1f1f3b2569b368900a462cb1658e288f513ab42a3aef74d14d1ee1bac445678aab954ed4b8a90fd8@192.168.0.6:30301" --verbosity=6 console

Genesis.md

Explanation of genesis file

• mixhash

A 256-bit hash which proves, combined with the nonce, that a sufficient amount of computation has been carried out on this block: the Proof-of-Work (PoF).

The combination of nonce and mixhash must satisfy a mathematical condition described in the Yellowpaper, 4.3.4. Block Header Validity, (44). It allows to verify that the Block has really been cryptographically mined, thus, from this aspect, is valid.

The value is a reduced representation (using a simple Fowler–Noll–Vo hash function) of the set of values selected from the DAG data file during mining calculation. This selection pick follows the implemented Estah' Hashimoto algorithm, which depends on the given Block header. The applied mixhash is re-determined for each hash operation that a Miner performs while searching for the correct Block nonce (cf. ASIC resistance, high IO). The final Block mixhash is the value leading to the valid Block. The reason why this value is part of the Block descriptor is that it becomes part of the //parentHash// of the next Block. By this, a potential attacker would need correct DAG data files to create illegal Blocks.

• nonce

A scalar value equal to the number of transactions sent by the sender.

A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block.

The nonce is the cryptographically secure mining proof-of-work that proves beyond reasonable doubt that a particular amount of computation has been expended in the determination of this token value. (Yellowpager, 11.5. Mining Proof-of-Work).

The final nonce value is the result of the the mining process iteration, in which the algorithm was able to discover a nonce value that satisfies the Mining Target. The Mining Target is a cryptographically described condition that strongly depends on the applied . Just by using the nonce Proof-of-Work, the validity of a Block can verified very quickly.

• difficulty

A scalar value corresponding to the difficulty level applied during the nonce discovering of this block. It defines the Mining Target, which can be calculated from the previous block’s difficulty level and the timestamp. The higher the difficulty, the statistically more calculations a Miner must perform to discover a valid block. This value is used to control the Block generation time of a Blockchain, keeping the Block generation frequency within a target range. On the test network, we keep this value low to avoid waiting during tests since the discovery of a valid Block is required to execute a transaction on the Blockchain.

• alloc

Allows to define a list of pre-filled wallets. That's a Ethereum specific functionality to handle the "Ether pre-sale" period. Since we can mine local Ether quickly, we don't use this option.

• coinbase

The 160-bit address to which all rewards (in Ether) collected from the successful mining of this block have been transferred. They are a sum of the mining eward itself and the Contract transaction execution refunds. Often named "beneficiary" in the specifications, sometimes "etherbase" in the online documentation. This can be anything in the Genesis Block since the value is set by the setting of the Miner when a new Block is created.

• timestamp

A scalar value equal to the reasonable output of Unix’ time() function at this block inception.

This mechanism enforces a homeostasis in terms of the time between blocks. A smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required to find the next valid block. If the period is too large, the difficulty, and expected time to the next block, is reduced.

The timestamp also allows to verify the order of block within the chain (Yellowpaper, 4.3.4. (43)).

Note: Homeostasis is the property of a system in which variables are regulated so that internal conditions remain stable and relatively constant.

• parentHash

The Keccak 256-bit hash of the entire parent block’s header (including its nonce and mixhash). Pointer to the parent block, thus effectively building the chain of blocks. In the case of the Genesis block, and only in this case, it's 0.

• extraData

An optional free, but max. 32 byte long space to conserve smart things for ethernity on the Blockchain.

• gasLimit

A scalar value equal to the current chain-wide limit of Gas expenditure per block. High in our case to avoid being limited by this threshold during tests. Note: this does not indicate that we should not pay attention to the Gas consumption of our Contracts.