Genesis File

Genesis File

This document explains how the genesis file of the Zenith Chain is structured.

What is a Genesis File?

A genesis file is a JSON file that defines the initial state of your blockchain. It can be seen as height 0 of your blockchain. The first block, at height 1, will reference the genesis file as its parent.

The state defined in the genesis file contains all the necessary information, like initial token allocation, genesis time, default parameters, and more. Let us break down this information.

Explanation

• chianID66 for main-net and 96 for test-net. To compatible with third part service that already supports Ethereum, we’d better not use network id that Ethereum ecology that already used. The network id of test-net should be distinct from main-net.

• periodMinimum difference between two consecutive block’s timestamps. Suggested 3s for the testnet .

• epochNumber of blocks after which to checkpoint and reset the pending votes. Suggested 100 for testnet

• 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. In Zenith Chain, this value is always set to 0x0.

• timestampMust be at least the parent timestamp + BLOCK_PERIOD.

• extraData

  • EXTRA_VANITY: Fixed number of extra-data prefix bytes reserved for signer vanity. Suggested 32 bytes

  • Signer Info: validator address

  • EXTRA_SEAL bytes (fixed) is the signer’s signature sealing the header.

• difficulty A scalar value corresponding to the difficulty level applied during the nonce discovering of this block. Suggested 0x1 for testnet

• mixHashReserved for fork protection logic, similar to the extra-data during the DAO. Must be filled with zeroes during normal operation.

• coinbaseSystem controled address for collecting block rewards

• numberBlock height in the chain, where the height of the genesis is block 0.

• parentHashThe 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.

Zenith Chain Initialization

There are two requirements we need to meet: 2. All the initial validators of Zenith Chain should be recorded in the ZC.

The first one is a must, because if we want to transfer some Zenith Coin to ZC, we will consume some gas in ZC. So we must ensure there are already some Zenith Coins in ZC. That means the first interchain transfer should be done in the genesis block of side chain.

For the second one, we should have that to ensure all the validators info and changes are tracked in the main chain.

People can apply to be a validator or delegate to these candidates. We can have a time limit. After that, we collect all the elected validators and write them to the genesis of ZC.

Account and Address

For normal users, all the keys and addresses can be generated via Zenith Extension Wallet.

This default wallet would use a similar way to generate keys as Ethereum, i.e. use 256 bits entropy to generate a 24-word mnemonic based on BIP39, and then use the mnemonic and an empty passphrase to generate a seed; finally use the seed to generate a master key, and derive the private key using BIP32/BIP44 with HD prefix as "44'/60'/", which is the same as Ethereum's derivation path.