LinuxCommandLibrary

bootnode

SYNOPSIS

bootnode [options]

PARAMETERS

-nodekey
    Specifies the file containing the node's private key. If not provided, a temporary key will be generated and stored in the data directory.

-nodekeyhex
    Specifies the node's private key directly in hexadecimal format. This option overrides -nodekey.

-addr
    Defines the listening address (IP and UDP port) for the discovery service. Default is :[30301].

-nat |
    Enables NAT traversal. ext_ip:port specifies the external IP and port, or any for automatic detection of the external address.

-verbosity
    Sets the logging verbosity level (0=silent, 1=error, 2=warn, 3=info, 4=debug, 5=trace). Default is 3 (info).

-maxpeers
    Sets the maximum number of peers the discovery node will attempt to track or communicate with.

-writeaddress
    Writes the node's enode URL to a file named enode within the data directory.

-datadir
    Specifies the data directory for the node. Used to store the node key if -nodekey is not specified.

-timeout
    Sets a timeout for various discovery protocol operations, e.g., 30s.

-version
    Prints the bootnode version and exits.

-help
    Displays the help message and exits.

DESCRIPTION

The bootnode command provides a standalone implementation of the Ethereum P2P network discovery protocol. Its primary purpose is to act as a bootstrap node, helping other Ethereum clients (like Geth) find initial peers on the network.

Unlike a full Ethereum client, bootnode does not process transactions, mine blocks, or store blockchain data. Instead, it listens on a UDP port for discovery requests and responds with information about other known peers. This mechanism is crucial for the initial peer discovery phase, allowing new or restarting nodes to quickly connect to the network without needing a hardcoded list of all possible peers.

It is an essential component, especially when setting up private Ethereum networks, where a dedicated discovery service ensures that all participating nodes can easily find and connect to each other. bootnode is part of the go-ethereum client suite.

CAVEATS

No Blockchain State: bootnode does not maintain any blockchain data, validate transactions, or mine blocks. It is purely for peer discovery.

Security of Node Key: The node's private key (specified via -nodekey or -nodekeyhex) is sensitive and should be protected. If lost or compromised, the node's identity on the network may be affected.

Network Configuration: For successful operation, the specified UDP port (via -addr) must be open and accessible from other nodes, often requiring proper firewall configuration and correct NAT setup.

ENODE URL

An enode URL is the unique identifier for an Ethereum node on the network. It follows the format enode://@:. The is derived from the node's public key (part of the nodekey). Other Ethereum clients use this URL to connect to the bootnode as an initial peer. When bootnode starts, it prints its enode URL to the console, and it can also be written to a file using the -writeaddress option.

USAGE IN PRIVATE NETWORKS

For private or consortium Ethereum networks, one or more bootnode instances are typically set up to serve as the exclusive peer discovery service for that specific network. This ensures that only nodes configured to use these bootnodes can join the private network, providing a controlled environment for blockchain operations. The enode URLs of these bootnodes are then provided to all participating Geth clients via the --bootnodes command-line option.

HISTORY

The bootnode command has been an integral part of the go-ethereum (Geth) project since its early days. It was developed to address the fundamental need for robust peer discovery within the Ethereum network. As the network grew and the complexity of peer-to-peer communication increased, a dedicated and reliable discovery service became essential. bootnode's role has remained consistent: to provide a stable initial point of contact for new nodes joining the network, thereby facilitating seamless connectivity and network resilience. Its development closely tracks the evolution of the Ethereum P2P protocol.

SEE ALSO

geth(1), clef(1), abigen(1), evm(1)

Copied to clipboard