Hyperledger Besu Architecture and Deployment
This domain tests whether you understand how Besu is packaged, how a node process is configured, and where its state lives on disk. Besu is an Apache-2.0 Ethereum client written in Java that runs public Ethereum and private consortium networks from the same binary, so most deployment questions reduce to which flags, which genesis, and which data directory.
Core rules
- Current releases require a modern JDK (Java 17 or later); confirm the minimum in the release notes before upgrading a host.
- Configuration comes from CLI flags, a TOML file passed with
--config-file, or a mix. Command-line flags take precedence over the file, so a stale TOML can be silently overridden by an operator's ad-hoc flag. --data-pathholds the node key (key,key.pub), the database, caches andDATABASE_METADATA.json. Never point two nodes at one data path.- Trie storage is Bonsai (default in current releases) or Forest via
--data-storage-format; the choice changes disk use and pruning behaviour, and a database is not portable between formats without a resync. - Extend behaviour with plugins (
--plugins) rather than forking; plugins also supply alternate security modules and storage backends.
Worked example
You need a reproducible private node. Write a TOML file holding data-path, genesis-file, p2p-port, rpc-http-enabled=true and the RPC API list, then start with besu --config-file=config.toml. While debugging you add --logging=DEBUG on the command line only. The flag applies to that process and the TOML is untouched, so the next restart returns to INFO without editing files.
Traps
- Reusing a data path after changing the genesis or chain ID: the node either refuses to start or follows a different chain.
- Assuming the config file overrides command-line flags.
- Deploying with default RPC exposure and no host or firewall review.
- Treating a copied data directory as portable across Besu versions, storage formats or clients.