BCP Exam Prep: Build One Private Besu Network That Covers All Seven Domains

You can read about Besu for weeks and still freeze on a BCP question that asks why a new node can't join the network. The fastest way to prepare for the Besu Certified Professional (BCP) exam is to build the thing the exam is about: a small private Besu network. One four-node lab, extended a step at a time, touches every one of the exam's seven domains.

This guide gives you that lab, maps each step to the official domains, and covers the exam facts you need before booking. Exam figures come from the Linux Foundation's official BCP certification page, and the commands come from the Besu documentation.

What does the BCP exam test?

BCP is a 90-minute, online proctored, multiple-choice exam from the Linux Foundation that tests whether you can build and run networks on Besu, an open source Ethereum client.

LF Decentralized Trust and Linux Foundation Education announced the certification in November 2024 for full-stack engineers, DevOps engineers and developers. At launch, LF Decentralized Trust Executive Director Daniela Barbosa said that "for the enterprise adoption of Ethereum to scale, there must be a strong base of well qualified engineers and developers."

The official page lists seven weighted domains:

Domain	Weight
Networking	26%
Besu Core Concepts	24%
Transactions and Storage	14%
Cryptography	10%
Permissioning and Privacy	10%
Execution Engine and Consensus	8%
Monitoring	8%

Networking is the biggest single domain. Add permissioning, the execution engine and monitoring, and more than half the exam is about operating nodes. That's why a lab works so well.

What are the BCP exam details?

US$250, 90 minutes, two attempts, valid for two years, with no prerequisites and a free official course.

• Format: online, proctored, multiple-choice
• Duration: 90 minutes
• Fee: $250, or $495 with a THRIVE-ONE annual subscription
• Attempts: two (one retake)
• Validity: two years
• Eligibility window: 12 months from purchase
• Prerequisites: none
• Free course: Besu Essentials: Creating a Private Blockchain Network (LFS176x)

The Linux Foundation doesn't publish a question count or passing score. Prep guides list 60 questions and a 75% pass mark, so aim well above 75% on timed practice before you book.

What do you need for the lab?

One machine with Java and Besu installed, four terminal windows and about an hour for the first network.

Install Besu by following the Besu documentation for your operating system, then check it runs with besu --version. Everything below runs locally. The nodes talk to each other on different ports of the same machine, so you don't need cloud servers or real Ether.

The lab follows the Besu documentation's QBFT private network tutorial. Keep that page open, because flags can change between Besu releases.

Lab 1: How do you create the network? (Core Concepts and Execution Engine)

Write a QBFT configuration file, let Besu generate the genesis file and node keys, and read every field it produces.

Create a QBFT-Network folder and a qbftConfigFile.json like this:

{
  "genesis": {
    "config": {
      "chainId": 1337,
      "berlinBlock": 0,
      "qbft": {
        "blockperiodseconds": 2,
        "epochlength": 30000,
        "requesttimeoutseconds": 4
      }
    },
    "nonce": "0x0",
    "timestamp": "0x58ee40ba",
    "gasLimit": "0x1fffffffffffff",
    "difficulty": "0x1",
    "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
    "coinbase": "0x0000000000000000000000000000000000000000",
    "alloc": {}
  },
  "blockchain": {
    "nodes": { "generate": true, "count": 4 }
  }
}

Then generate the network files:

besu operator generate-blockchain-config \
  --config-file=qbftConfigFile.json \
  --to=networkFiles \
  --private-key-file-name=key

Besu writes a genesis.json and one key folder per node. It also fills in extraData for you, which encodes the initial validators.

What this teaches for the exam: the genesis file (Core Concepts) sets the chain ID, the consensus protocol, the block period and the gas limit. The chainId is what keeps your transactions from being replayed on another network. QBFT is the proof-of-authority protocol Besu's tutorial uses, and it needs four validators to be Byzantine fault tolerant. That's why the lab has four nodes.

Lab 2: How do nodes find each other? (Networking)

Start Node-1 as the bootnode, then start Nodes 2 to 4 pointing at its enode URL, each on its own ports.

Copy each node's key into its own NodeN/data folder, then start Node-1:

besu --data-path=data --genesis-file=../genesis.json \
  --rpc-http-enabled --rpc-http-api=ETH,NET,QBFT \
  --host-allowlist="*" --rpc-http-cors-origins="all" \
  --profile=ENTERPRISE

Node-1 prints its enode URL at startup. Start Node-2 with the same flags plus a bootnode and different ports:

  --bootnodes=<Node-1 enode URL> --p2p-port=30304 --rpc-http-port=8546

Nodes 3 and 4 use ports 30305/8547 and 30306/8548. Then confirm the network has four validators:

curl -X POST --data \
  '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}' \
  localhost:8545

What this teaches for the exam: node discovery, bootnodes and enode URLs; the difference between the P2P port nodes use to talk to each other and the RPC port applications use; and what a validator node is. Stop Node-4, watch blocks keep coming, then stop a second node and watch them stop. Seeing that happen will stick with you longer than any definition of fault tolerance.

Lab 3: How do you run a gas-free network? (Networking and Transactions)

Set the minimum gas price to zero on every node, and set the matching genesis options.

Many enterprise networks don't charge gas. According to the Besu documentation, every node needs --min-gas-price=0, because a node with a higher minimum "silently drops" zero-price transactions. You'll typically also set --tx-pool-enable-balance-check=false so senders with no balance aren't blocked. Networks on the London fork or later also need "zeroBaseFee": true in the genesis config.

Send a few transactions and inspect the results with eth_getTransactionReceipt. Look at the gas used, the status and the logs.

What this teaches for the exam: gas, gas-free mode, transaction receipts, and logs and events. It also shows you how the transaction pool treats transactions that don't meet a node's rules. Besu's default layered transaction pool is part of the Execution Engine domain.

Lab 4: How do you control who joins and transacts? (Permissioning and Privacy)

Turn on local node and account allowlists, then manage them through the PERM API.

Restart your nodes with these options:

  --permissions-nodes-config-file-enabled \
  --permissions-accounts-config-file-enabled \
  --rpc-http-api=ETH,NET,QBFT,PERM

Then list the allowed nodes and accounts in permissions_config.toml, which Besu reads from each node's data directory by default:

nodes-allowlist=["enode://<node-1>@127.0.0.1:30303", "enode://<node-2>@127.0.0.1:30304"]
accounts-allowlist=["0x<your-test-account>"]

Try to connect a node that isn't on the list, and send a transaction from an account that isn't allowed. Then use perm_addNodesToAllowlist and perm_addAccountsToAllowlist to fix both. The PERM methods aren't enabled by default, which is why the --rpc-http-api list above includes PERM.

What this teaches for the exam: the difference between node permissioning (who can connect) and account permissioning (who can transact). It also teaches when to move from local allowlists to onchain permissioning, where smart contracts enforce the rules for the whole network.

Lab 5: How do you watch the network? (Monitoring)

Enable metrics on each node, point Prometheus at them, and load a Besu dashboard in Grafana.

Add --metrics-enabled to each node. By default, Besu serves metrics on 127.0.0.1:9545, so give each node a different --metrics-port. Configure Prometheus to scrape all four, then import the sample Besu dashboard into Grafana. Stop a node and watch the peer count and block height react.

What this teaches for the exam: node monitoring, Grafana dashboards and the signals that matter for high availability. Read about Besu plugins too: they extend the client without forking it, and plugins are a listed Monitoring topic.

What can go wrong in the lab, and what does it teach?

Most lab failures map directly to exam scenarios, so treat each one as a free practice question.

• A node won't peer. Usually the --bootnodes value has the wrong enode URL, or two nodes are trying to use the same P2P port. This is the node discovery and networking material, in practice.
• Blocks stop being produced. With four QBFT validators, the network keeps going with one node down but stalls with two down. This is consensus and fault tolerance, and it's why validator counts matter.
• Transactions sit pending. On a gas-free network, check whether every node has --min-gas-price=0. One node with a higher minimum will drop zero-price transactions, so they may never reach a validator.
• An RPC call is rejected. The API group isn't in --rpc-http-api, or the caller isn't covered by --host-allowlist. Expect questions on which APIs a node exposes and why you'd restrict them.
• You lock yourself out. If you enable node allowlisting without listing your own nodes, they can't connect to each other. It's an easy mistake to make, and a common scenario question on permissioning.

Write down each problem you hit and how you fixed it. By exam day, that list is one of your best revision notes.

What does the lab not cover?

Cryptography and the storage internals need focused reading alongside the lab.

Hands-on work won't teach you everything. Plan dedicated study time for:

• Cryptography (10%): ECDSA signing on the secp256k1 curve, private key management, symmetric versus asymmetric encryption, and structured data signing (EIP-712).
• Transactions and Storage (14%): account state (nonce, balance, storage root and code hash), Merkle trees, account storage and the world state, plus token standards such as ERC-20 and ERC-721.
• Core theory: the blockchain trilemma, block propagation, and how addresses are derived from public keys.

David Boswell, Community Architect at LF Decentralized Trust, recommends the recorded Besu workshops, the public and private network tutorials, and the Besu channels on the LF Decentralized Trust Discord. A study partner or learning group helps too.

https://www.youtube.com/watch?v=n1pCMJRLvZk

How should you schedule your BCP prep?

Five weeks: one lab per week, with theory alongside, then a final week of timed practice.

1. Week 1: LFS176x, plus Lab 1. Explain every genesis field out loud.
2. Week 2: Lab 2, plus Networking theory: discovery, synchronization, and comparing QBFT, IBFT 2.0 and Clique.
3. Week 3: Labs 3 and 4, plus Transactions and Storage and Permissioning theory.
4. Week 4: Lab 5, plus Cryptography and the execution engine.
5. Week 5: timed sets of 60 questions in 90 minutes. Rebuild the network from scratch once without notes.

Linux Foundation SVP Clyde Seepersad said at launch that "the demand for IT professionals with solid decentralized trust skills is strong and growing rapidly." That demand favors people who can actually run a network. The lab gets you ready for both the exam and the job.

Quick answers: BCP FAQ

How long is the BCP exam? 90 minutes, online and proctored.

How much does BCP cost? $250, or $495 with a THRIVE-ONE annual subscription.

Which domain carries the most weight? Networking, at 26%.

What is the BCP passing score? The Linux Foundation doesn't publish one. Prep guides list 75%.

How many validators does a QBFT network need? Four, to be Byzantine fault tolerant, according to the Besu documentation.

Do I need cloud servers for the lab? No. Four nodes can run on one machine using different ports.

Is there a free BCP course? Yes: Besu Essentials: Creating a Private Blockchain Network (LFS176x).

How long is BCP valid? Two years.

Ready to test yourself?

Once your network runs and you can explain why each flag is there, check your knowledge against exam-style questions. These free Besu Certified Professional sample questions are a good way to find the domains that still need work.

Exam details are from the Linux Foundation's official BCP page as of October 2026. Commands follow the Besu documentation; check the docs for your Besu version before running them.