# How to Configure Besu Client as a Bootnode on Ephemery network? A bootnode is a regular node that provides information about itself and other regular nodes to assist in network connectivity. A bootnode helps other nodes that have newly joined the network to discover new peers. Clients usually have a list of bootnodes hardcoded into them. Therefore, we need the address of the bootnodes to be constant and not changing, which is the main topic of this write-up. We want Besu to be able to be a bootnode on Ephemery and not change its address even with every restart. This way we provide more decentralization around node discovery since it enables regular nodes to become a boot node, not just rely on centralized ones and those that are maintained by centralized data centers, such as AWS, Azure, and Hetzner. The more diverse bootnodes we have, the more decentralized and more secure the network will be. You can read more about the issue [here](https://ethresear.ch/t/execution-consensus-client-bootnodes/14588/11). ### Run an Ephemery Bootnode on Besu A node address on the network follows this format: `enode://<node ID>@<IP address>:<port>` For a node to function as a robust bootnode, it must maintain three consistent parameters: - Node ID - IP Address - Port One and the most important is the key. The key should be preserved and not change over time; this will help the address of the node become constant. Other than that, the node should be run on a machine with a static IP. `--max-peers` can be set to a reasonable number tailored to your bandwidth. The default is 25, so it can be higher than 25 on a bootnode, as its solo job task is to prepare peer info. #### Manually (every 28 days) Besu client will generate a new key when starting with no key file. So to keep the key the same on every start and stop, it should copy the key file beforehand into the next folder that Ephemery is going to sync data into or via the command `--node-private-key-file`, for which you should provide the key file as the value, and you have to have the private key in the file. Not a good option for a bootnode, as the key is more exposed to getting compromised, and also during downtime the bootnode is not available, which loses the purpose of a bootnode in the first place. #### Automatically (once and for all) [These PRs](https://github.com/hyperledger/besu/pull/9210), if merged, will enable automatic Ephemery restarts with fresh databases while preserving the node's identity across cycles and refreshing peer connections at each cycle. Start the Ephemery node with a known private key: You can provide a private key (especially useful when migrating from another client or machine). The Ephemery automation will then handle restarts, key preservation, and other maintenance tasks, providing a more secure and robust bootnode. ```bash --network= ephemry --p2p-port= 30303 --data-path= ./besu-ephemery-data --node-private-key-file=./besu-ephemery-data/key --max-peers = 30 ``` For deploying a new node on Besu from scratch: In this case, you shouldn't give it any key file for node ID. Besu generates a new ID and will be seen in the key file in the path you've given as `--data-path` or in the default path. You can also export the file to any path using the`--to` parameter. ```bash --network= ephemry --p2p-port= 30303 --data-path= ./besu-ephemery-data --max-peers = 30 ``` ### Do we mean static node by bootnode? What about bootstrap nodes? "Bootnode" is short for "bootstrap node." But there is a difference between static nodes and bootnodes. The static node can be used as a syncing partner on the network as well as a discovery peer. But these two words are used interchangeably in the network (much like terminology in software architecture and development). Thus, when deploying, it's best to clarify the intended use case. Static nodes can serve as both syncing partners and peer discovery nodes on the network, while bootnodes primarily focus on peer discovery: - For peer discovery only: Enable UDP and set `--max-peers` to a high number. - For both discovery and syncing: Enable both UDP and TCP with `--max-peers` set to a moderate number, as bandwidth will be shared between syncing data and providing peer information.