Quick readiness summary: you are ready to practice under exam conditions when you can (1) identify the public versus permissioned context of any deployment description, (2) read a genesis file and predict consensus behavior, including what happens when validators stop, (3) choose between standard and flexible privacy groups for a membership change, and (4) trace a new node through every permissioning gate. For administrative details such as scheduling and exam format, rely on the Linux Foundation certification page rather than third-party summaries, and use the free practice questions to rehearse these decisions under time pressure.
Why one Besu client behaves differently in public and permissioned contexts
Besu is a single codebase serving two roles: an Ethereum execution client for public networks and a fully configurable node for permissioned chains. Consensus, privacy, and governance topics split cleanly along that line.
On public networks, Besu follows the Ethereum execution specification: it executes the chain, serves standard JSON-RPC, and depends on a separate consensus-layer client for validator duties. The operator does not choose validators, set block parameters, or decide who connects; the protocol and the wider client ecosystem define those behaviors. When you study validator-related content in this context, the correct frame is how an execution client hands over and receives validator-driven work after the proof-of-stake transition.
On permissioned networks, the operator owns these decisions through the genesis file and configuration: the consensus protocol, who may run a validator, who may connect, and whether private transactions are enabled. Features such as QBFT, Tessera privacy, and permissioning contracts only exist in this context, so make a habit with every deployment scenario you read: write down the context as your first decision, then choose tools second. Practicing that two-step on networks you build yourself trains the habit before you need it.
Matching each Besu component to the behavior it owns
A running Besu node combines the execution engine, transaction pool, JSON-RPC and WebSocket APIs, a pluggable consensus engine, optional privacy-manager integration, and observability hooks. Troubleshooting questions become tractable once you assign each symptom to the right component.
The execution core runs the EVM, maintains state, and syncs blocks; the transaction pool holds pending public transactions until they are included. The JSON-RPC and WebSocket interfaces are the operator-facing surface, grouped by function, and are meant to be explicitly restricted. Metrics and logging expose peer counts, block import rates, and consensus messages — the evidence you would cite when diagnosing a stalled network.
The consensus engine is selected per network in the genesis file (for example dev, qbft, ibft2, or clique) rather than installed separately. Privacy works differently: Besu coordinates with an external privacy manager, Tessera, over configured endpoints, and private payloads travel through that companion process rather than through the public transaction pool. Plugin interfaces allow enterprises to hook in custom identity or storage behavior at defined extension points.
Telling QBFT, IBFT 2.0, and Clique apart when operating a network
Enterprise networks usually choose between QBFT, its predecessor IBFT 2.0, and Clique proof of authority. They differ in Byzantine fault tolerance, when blocks become final, and how validator changes are proposed and accepted.
Read any Besu network from its genesis file first: the consensus protocol and its parameters are declared there, including validator lists or a validator contract. QBFT and IBFT 2.0 provide immediate finality with Byzantine tolerance — a network of N validators keeps finalizing while fewer than a third are faulty, which is why a four-validator network survives one failure but halts when a second stops. Clique is simpler to run but offers no Byzantine tolerance and finalizes only at checkpoint blocks.
Validator management also differs. In QBFT you can propose adding or removing validators through vote-based RPC calls, or manage the set via a validator smart contract; changes take effect only once enough validators agree, so a mid-life validator replacement should be planned as a sequence of coordinated proposals rather than a simultaneous restart of several validators. When comparing IBFT 2.0 and QBFT, treat IBFT 2.0 as the established predecessor that legacy networks still run in production.
| Protocol | Trust model | Finality behavior | Typical fit |
|---|---|---|---|
| QBFT | BFT; tolerates up to one third faulty validators | Immediate finality once enough validators vote | Recommended for enterprise permissioned networks |
| IBFT 2.0 | BFT; predecessor of QBFT | Immediate finality, similar thresholds | Legacy permissioned networks still running it |
| Clique | Proof of authority among configured signers | Finality at checkpoint blocks, no BFT tolerance | Simple test or signer networks |
| Public PoS transition | Validator set managed at the consensus layer | Finality determined by the consensus client | Public Ethereum operation as an execution client |
Choosing a privacy group type when members may change later
Private transactions reach only the members of a privacy group, coordinated through Tessera. Standard privacy groups have fixed membership once created; flexible privacy groups allow members to be added afterwards.
A standard privacy group forms implicitly from the participants of the first private transaction, and its membership is fixed: no later transaction extends it. A flexible (bespoke) privacy group is created deliberately with a privacy group identifier and an initial member list, and new members can be added while the group lives. Distinguishing the two matters wherever network membership is expected to grow, which describes most consortium designs, and it changes how you plan contract state sharing.
Scenario: three banks have traded privately for months, and a supplier must now join the same working group. The tempting mistake is to hand the supplier's Tessera details to the existing participants, assuming the group grows automatically. The better decision is to recognize the group is a standard one with locked membership, then either create a flexible privacy group for the expanded membership or plan a deliberate state-sharing and migration path. The choice determines whether the supplier can read prior private state at all, which is the whole point of the integration.
Debugging a healthy new node that still has no permitted peers
Permissioning separates network admission from validation and transacting. A new node can be technically healthy yet isolated if it is missing from the node allowlist — whether that lives in onchain permissioning contracts or local configuration.
Besu supports layered admission control: onchain permissioning stores node and account allowlists in smart contracts managed through governance RPC calls, while file-based permissioning enforces allowlists locally in configuration. Discovery is not admission — finding a bootnode does not mean peers will accept connections from an unallowlisted node. Account permissioning then governs who may send transactions, which is a distinct question from which nodes may join the peer-to-peer network.
Scenario: an operator launches a new node with the correct genesis file and bootnode list, sees zero peers in a permissioned network, and repeatedly restarts the node while suspecting networking. The better decision is to walk the admission chain in order: confirm the node's enode identity is recorded in the permissioning contracts or local allowlist, confirm bootnode connectivity, and only then investigate TLS or firewall settings. The distinction matters because each gate fails differently, and restarting a node that is permitted by nothing cannot fix it.
A lab drill that makes consensus, privacy, and observability concrete
Build a small QBFT network with privacy enabled in an isolated lab, watch its metrics, and deliberately stop validators. Observing where finality and privacy boundaries move teaches what configuration reading alone cannot.
Exercise: on an isolated machine, deploy a four-validator QBFT network in containers plus two Tessera nodes, send a private transaction between two members and a public transaction from a third, then stop one validator and later a second. Expected observations: with one validator stopped, blocks keep finalizing; stopping a second halts finality because the required threshold can no longer be reached. In the logs, find the privacy group creation, the privacy group identifier in transaction receipts, and confirm the third member cannot read the private payload.
Extend the drill into performance: enable Prometheus-format metrics, watch block import and peer counts while a validator is down, and experiment with data-retention settings such as pruning on a separate throwaway node, noting what historical access you lose. Sizing storage and watching sync behavior on a disposable copy of the network builds deployment judgment far better than rereading configuration references, and the same lab can be reused for every scenario in this guide.
- Rubric item: explain why one stopped validator is tolerated but two are not, in terms of the fault-tolerance threshold.
- Rubric item: locate the privacy group ID in a receipt and state which Tessera nodes hold the private payload.
- Rubric item: name the metrics you watched — peer count, block import, validator status — to diagnose the halt.
- Self-check: score each item 0-2; treat a total below 4 as a signal to redo the drill, not as a pass or fail prediction.
Securing enterprise interfaces and sequencing your final weeks
Security topics concentrate on signing-key handling, restricting JSON-RPC exposure, TLS between Besu, Tessera, and clients, and plugin-based enterprise identity. Finish preparation by rehearsing decisions rather than rereading notes.
In an enterprise node, the JSON-RPC interface is a privileged surface: enable only the API groups a client needs, bind it away from public interfaces, and use host allowlists to block rebinding attacks. Traffic between Besu and Tessera, and between clients and RPC endpoints, can be protected with TLS using trusted certificates. Signing keys for validators and transaction senders need explicit custody decisions — a file-based keystore is the default arrangement, not a complete security strategy.
Identity integration closes the loop: Besu's plugin API lets enterprises replace default behaviors, for example by plugging in an enterprise key-management or authentication flow, which is why integration questions hinge on identifying which extension point a described change would use. When studying, name the extension point explicitly for each enterprise integration you read about, then check how it interacts with permissioning and privacy components instead of treating the three as isolated features.
- Weeks 1-2: draw one permissioned network end to end, label which component owns each behavior, and rebuild it from a genesis file.
- Week 3: run the privacy and permissioning scenarios from this guide as written decisions, not as reading.
- Week 4: take the free practice set timed, redo any missed decision in the lab, and repeat the readiness checks below.
- Check 1: given a deployment description, name the context (public vs permissioned) and consensus protocol without notes.
- Check 2: given a membership change, choose standard versus flexible privacy groups and justify the state consequences.
- Check 3: trace a new node from launch to permitted peers, naming each admission gate in order.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.