Node Configuration

Defines the operational role of the node on the network.

• Full Node: Validates and relays blocks and transactions, maintaining a full copy of the blockchain.
• Validator Node: A full node that participates in consensus by proposing and voting on blocks, requiring a staked bond.
• Archive Node: A full node that retains the entire history of all states, not just recent blocks.
• Light Client: Connects to full nodes to query blockchain data without storing the entire chain.

Settings governing how the node connects to the peer-to-peer network.

• Persistent Peers: A static list of node addresses (node-id@ip:port) to maintain constant connections with.
• Seeds: Bootstrap nodes that provide initial peer addresses; the node disconnects after obtaining peers.
• Addr Book Strict: If enabled, prevents connections to peers not in the addrbook.json file.
• External Address: The public address other nodes use to connect to yours, crucial for validator nodes.

Core parameters that control the node's participation in the blockchain's consensus mechanism.

• Pruning Settings: Determines how much historical block data is retained (default, everything, nothing, custom).
• Block Time: Target time between blocks, often set by the chain protocol.
• Validator Key: Path to the private key used for signing prevotes and precommits (stored separately for security).
• Double-Sign Check Height: The block height up to which the node checks for evidence of double-signing.

Controls access to the node's Remote Procedure Call (RPC) and Application Programming Interface (API) servers.

• RPC Listen Address: The address and port (e.g., tcp://127.0.0.1:26657) where the RPC server binds.
• CORS Allowed Origins: Specifies which web domains can access the RPC endpoint (critical for security).
• API Server Enable: Turns on the REST API server (e.g., on port 1317) for querying application state.
• gRPC Enable: Activates the gRPC server, used by wallets and indexers for efficient data streaming.

Parameters for rapidly bootstrapping a node by syncing from a recent network snapshot instead of from genesis.

• Enable State Sync: Boolean flag to turn the feature on.
• RPC Servers: Trusted RPC endpoints (usually from other validators) to fetch snapshot data and headers.
• Trust Height & Hash: The specific block height and its block hash from which to trust the snapshot providers.
• Snapshot Interval: How often the node creates local snapshots for other nodes to sync from.

Hardware and system resource limits to ensure stable node operation.

• Database Backend: Choice of underlying storage (e.g., goleveldb, rocksdb, boltdb).
• Max Open Connections: Limits the number of simultaneous P2P connections to prevent resource exhaustion.
• Gas Prices: The minimum gas prices the node accepts for transactions, set to filter out spam.
• Log Level: Output detail for debugging (debug, info, warn, error).

Node configuration varies drastically based on resource constraints and use case. A full node validates all rules and stores the entire blockchain state, requiring significant storage (hundreds of GB to TBs) and bandwidth. A light client (or light node) only downloads block headers and requests specific data on-demand, sacrificing sovereignty for minimal resource use. Protocols like Ethereum (via light sync) and Bitcoin (Simplified Payment Verification) support this mode.

Incorrect chain parameters can cause a node to fork off the canonical chain. Configuration ensures the node follows the correct network rules.

• Genesis Block & Chain ID: The genesis configuration (genesis.json) defines the initial state and must match the network exactly.
• Hard Fork Activation Blocks: The client must be configured with the correct block numbers or timestamps for network upgrades (hard forks).
• Network Selection: Use the correct flag (e.g., --mainnet, --sepolia) or custom configuration file for testnets or private networks.
• Bootstrap Integrity: Verify the integrity of bootnodes and trusted checkpoints to prevent syncing to a malicious chain.

The genesis file is the foundational configuration document that initializes a blockchain. It defines the network's initial state, including:

• The initial allocation of tokens or coins.
• Network parameters like block time and gas limits.
• The cryptographic hash that identifies the specific chain. Every node must load the correct genesis file to join the intended network.

A Remote Procedure Call (RPC) endpoint is an interface that allows external applications to query a node's data and submit transactions. Key configuration includes:

• RPC Port: The network port (e.g., 8545 for Ethereum) the node listens on.
• CORS Settings: Defines which external domains can access the endpoint.
• API Modules: Enables specific namespaces like eth, net, or web3. Misconfiguration can expose the node to security risks or unintended access.

Peer discovery is the mechanism a node uses to find and connect to other nodes in the P2P network. Configuration involves specifying:

• Bootnodes: Hardcoded node addresses used to initially bootstrap into the network.
• Discovery Protocols: Such as Ethereum's Discv4 or Libp2p, which handle node lookup.
• Maximum Peers: The cap on simultaneous connections to manage bandwidth and resources.

State pruning is a configuration that reduces a node's storage requirements by deleting historical state data that is no longer necessary for validation. Options typically include:

• Archive Node: Retains all historical state (no pruning).
• Full Node: Prunes state older than a certain number of blocks.
• Light Client: Stores minimal state, relying on full nodes for data. This is a critical trade-off between storage space and historical data availability.

For nodes that produce blocks (validators/miners), configuration includes parameters for transaction inclusion and fee management:

• Gas Price Minimum: The lowest gas price the node will accept for a transaction.
• Block Gas Limit: The maximum total gas allowed in a block the node proposes.
• Priority Fee (Tip): In EIP-1559 networks, the miner's share of the transaction fee. These settings directly influence network throughput and validator revenue.

In post-Merge Ethereum and similar architectures, node operation is split between two software clients:

• Execution Client (e.g., Geth, Erigon): Manages transaction pool, state, and execution. Configured with RPC and sync mode.
• Consensus Client (e.g., Prysm, Lighthouse): Manages the Proof-of-Stake consensus, block proposal, and attestation. Configured with validator keys and beacon node settings. Both must be correctly configured and connected via an authenticated API.