Skip to main content

Documentation Index

Fetch the complete documentation index at: https://berachain-422fce37-feat-nodes-section-reno.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Berachain’s network relies on validator nodes and RPC nodes. Each can be configured as a full node or archive node. Berachain follows a decoupled node architecture standard in modern Ethereum-equivalent networks. Every node consists of two separate software clients running in tandem: an execution client and a consensus client. Berachain supports any EVM execution client paired with BeaconKit, a consensus framework built by Berachain.
Berachain node architecture showing execution and consensus client pairs

​
RPC vs Validator Nodes

Architecturally, RPC nodes and validator nodes are nearly identical. Both maintain a complete copy of the blockchain state and participate in peer-to-peer gossip. The only difference is that a validator node has been funded with a deposit and holds a private validator key. This key allows the consensus client to sign blocks and attestations, participate in consensus, and receive block rewards. To learn about the economics of becoming a validator, see the Validator Lifecycle and the Be A Validator guides.

​
Client Separation

The separation of concerns between the two clients is strictly defined:
  • Execution Client (e.g., Bera-Reth, Bera-Geth): Responsible for transaction execution, managing the Ethereum Virtual Machine (EVM) state, maintaining the state trie, and serving user-facing JSON-RPC requests (like eth_call or eth_sendRawTransaction).
  • Consensus Client (BeaconKit): Responsible for the Proof-of-Stake consensus mechanism, determining the chain’s head, managing the validator set, and proposing new blocks. It does not execute transactions or hold EVM state.
Because these are separate databases, “archival” status usually refers to the execution client retaining historical EVM state, whereas the consensus client manages its own independent pruning settings.

​
The Engine API and JWT

The execution and consensus clients must communicate continuously to keep the node synced. They do this over a local HTTP interface called the Engine API. Because the Engine API allows the consensus client to command the execution client to build and execute blocks, this API must be highly secured. Communication is authenticated using a JSON Web Token (JWT) secret. Both clients must be configured to read the exact same jwt.hex file on disk to authorize communication.

​
Dual P2P Networks

Because the node is split into two clients, it participates in two entirely separate Peer-to-Peer (P2P) networks simultaneously:
  1. Execution P2P (devp2p): The execution client connects to other execution clients to gossip pending user transactions (the mempool).
  2. Consensus P2P (CometBFT): The consensus client connects to other consensus clients to gossip proposed blocks, validator attestations, and consensus votes.
For firewall and networking configurations, operators must ensure both P2P ports are open and publicly dialable. For more details on securing and optimizing these networks, see the Production Checklist.