Network Configuration and Genesis Files
Genesis defines the chain. Every node must load a byte-identical file; a single differing field breaks peering or block acceptance. The exam probes field semantics, consensus configuration and how genesis is generated for a new network.
Core rules
- Top-level fields include
config,nonce,timestamp,gasLimit,difficulty,mixHash,coinbase,allocandextraData.allocmaps addresses to abalancein hex wei and can also carrycodeandstoragefor predeployed contracts. config.chainIdmust be unique per network. It drives EIP-155 replay protection and is compared by wallets, libraries and other clients.- Consensus sits under
configasethash,clique,ibft2orqbft, with lowercase keys such asblockperiodseconds,epochlengthandrequesttimeoutseconds. Fork activation blocks and times (londonBlock,shanghaiTime) also live here. extraDatais consensus-specific. Clique concatenates 32 vanity bytes, the signer addresses and a 65-byte signature (zeros in genesis). IBFT 2.0 and QBFT encode a vanity value plus the validator address list in an RLP structure.- Generate the file with
besu operator generate-blockchain-config --config-file=config.json --to=networkFilesrather than hand-building hex.
Worked example
A four-validator QBFT network: the operator config lists four validator keys and a qbft block with blockperiodseconds: 5, epochlength: 30000 and requesttimeoutseconds: 4. The command emits genesis.json and per-node key files. You verify that extraData decodes to exactly four addresses matching the generated validator addresses, set a unique chainId, and distribute the same file to all nodes. A wrong count or order leaves the chain unable to reach quorum.
Traps
- Writing balances as decimal or omitting the
0xprefix. - Forgetting
difficulty: 0x1and a zeromixHashon PoA networks. - Hand-editing
extraDatato add a validator instead of using a proposal vote. - A future
timestampor a gas limit below what contracts need.