Create a Genesis file, i. e. your first block of the private chain, in your home directory e. g.
Point geth to the Genesis file and start your private net
geth init /home/ether_testuser/.ethereum/CustomGenesis.json
geth --identity MyPrivateNet --port 50303 --nodiscover --maxpeers 1 --networkid 925345
Now you can connect with
geth attach on a different console, create a new account and start mining to get some ether
More details regarding the geth parameters
|nodiscover||Use this to make sure that your node is not discoverable by people who do not manually add you. Otherwise, there is a chance that your node may be inadvertently added to a stranger’s node if they have the same genesis file and network id.|
|maxpeers||Use maxpeers 0 if you do not want anyone else connecting to your test chain. Alternatively, you can adjust this number if you know exactly how many peers you want connecting to your private chain.|
|A custom name and number to identify your test network.|
|port||Use a different port than the geth standard port in order to run a test and production net in parallel.|
Connect to the testnet with the following command (insert key, ip address and port of the testnet):
geth --bootnodes enode://pubkey1@ip1:port1
geth --help for all options.
More details regarding the Genesis block
|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 miningcalculation. 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 access to correct DAG data files to create an illegal Block.
|nonce||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 Proof-of-Work (PoF).
The combination of nonce and mixhash must satisfy a mathematical condition and allows to verify that the Block has really been cryptographically mined and thus, from this aspect, is valid.
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.
The final nonce value is the result of 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 Difficulty. 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 reward 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.
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 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. 🙂|
|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.|