Besu Certified Professional key terms

A JSON document that defines a chain's initial state: chain ID, consensus settings, pre-funded accounts, block gas limit, and hard fork activation blocks. Every node on the network must use an identical copy to reach the same genesis hash.

A numeric identifier placed in the genesis file and embedded in every signed transaction. It prevents replay of transactions across chains, so nodes reject transactions signed for a different network.

A genesis field whose meaning depends on consensus. Under IBFT 2.0 and QBFT it carries the initial validator set plus the RLP-encoded vote and round number; under Clique it holds signer addresses and a vanity prefix.

A node whose enode URL is hard-coded so new peers can discover the network. It does not need to be a validator, but it must be reachable and running the same chain ID and genesis hash as joining nodes.

A peer entry in the node's configuration that Besu always attempts to connect to and never drops for inactivity. Static nodes are used to build a stable mesh, for example connecting every validator to every other validator.

A peer address in the form enode://<128-hex-node-public-key>@:. It contains no IP-based identity, so the same key can be advertised from different addresses; the port defaults to 30303 for dev networks.

The private key that determines a node's P2P identity and therefore its enode URL. It is separate from account keys used to sign transactions and must be preserved if peers rely on a fixed enode address.

The private key whose address identifies a validator in IBFT 2.0 or QBFT. It signs consensus messages such as proposals, prepares, and commits, and must be available whenever the validator is running.

The list of addresses authorised to produce and attest blocks under a proof-of-authority protocol. Membership changes through on-chain votes, and the current set is derivable from block headers rather than from the genesis file alone.

A Byzantine fault tolerant proof-of-authority protocol in Besu where validators take turns proposing blocks and finalise them after a two-phase prepare and commit exchange. Finalised blocks are never reorganised, which suits consortium networks needing immediate settlement.

The successor to IBFT 2.0 in Besu, offering a formally specified Byzantine fault tolerant consensus with improved liveness and clearer message handling. It uses the same validator-voting model but is generally preferred for new permissioned networks.

The minimum number of validator signatures required to make progress or finalise a block. In IBFT 2.0 and QBFT it is two-thirds of the validator set rounded up, so a network of four validators tolerates one faulty node.

The property that a consensus network keeps producing a single consistent chain even when some participants fail or send contradictory messages. It requires more than two-thirds of voting power to be honest.

The phase in IBFT 2.0 or QBFT where the designated proposer for a round broadcasts a candidate block. Other validators validate it and respond with prepare then commit messages before it is written and finalised.

The mechanism that lets validators abandon a stalled round when the proposer is offline or slow. Validators broadcast round-change messages, and once a quorum agrees a new proposer is selected for the next round.

A simpler proof-of-authority protocol where authorised signers take turns producing blocks in a rotating schedule. It offers no immediate finality, so short reorganisations are possible, and Besu supports it mainly for compatibility.

The proof-of-work mining algorithm used by Ethereum mainnet before the Merge. Besu can run Ethash networks for testing, but production Besu deployments overwhelmingly use proof-of-authority or post-Merge proof-of-stake chains.

The account that receives block rewards under proof-of-work. On proof-of-authority networks rewards are normally zero, so the beneficiary field is set but does not transfer value to the block producer.

A divergence in chain history, either temporary when two validators propose competing blocks or permanent when nodes disagree on protocol rules. Besu avoids permanent forks by requiring identical genesis and fork-block configuration across peers.

The HTTP or WebSocket interface Besu exposes for reading chain state and submitting transactions. Methods are grouped into namespaces such as eth, net, admin, debug, and priv, and each namespace must be enabled explicitly.

A prefix grouping JSON-RPC methods by function and risk level, for example eth, net, web3, admin, debug, miner, and priv. Enabling admin or debug on a public interface exposes powerful operations and should be restricted.

The JSON-RPC method that submits a signed, RLP-encoded transaction to the node. The node validates nonce, gas, signature, and chain ID before propagating it to peers; the returned value is the transaction hash, not a receipt.

The result record available after a transaction is included in a block, containing status, cumulative gas used, logs, and contract address. Polling for a receipt is the standard way to confirm execution outcome.

A structured record emitted by a contract during execution and stored in the transaction receipt. Logs are not readable by contracts themselves but are the primary way off-chain systems observe on-chain activity.

A persistent JSON-RPC connection over which the node pushes notifications for new blocks, pending transactions, or logs matching a filter. It avoids polling but requires the WebSocket service and relevant namespaces to be enabled.

A configuration list controlling which Host header values the JSON-RPC HTTP service accepts. Requests with unlisted hosts are rejected, which mitigates DNS-rebinding attacks against a locally exposed API.

Transport encryption for Besu's JSON-RPC endpoints and P2P links, configured with a keystore and certificate chain. Enabling it prevents credential and payload exposure on the network but adds certificate lifecycle management.

A directory of encrypted JSON files, each holding one private key protected by a password. Besu uses key stores for node keys, validator keys, and account keys referenced by the --node-private-key-file and related options.

The process of supplying a password so Besu can sign transactions for a locally stored account via eth_sendTransaction. Unlocking is disabled by default and is riskier than signing transactions client-side.

The set of controls deciding which nodes may peer and which accounts may submit transactions. Besu implements node and account allowlists, either locally in files or on-chain through permissioning contracts that update without restarts.

A permissioning model where allowlists live in smart contracts, so changes are made by sending transactions rather than editing files and restarting nodes. Nodes poll the contracts and enforce the resulting lists automatically.

An identifier for a set of nodes that share private transactions under Besu's private transaction feature. Members receive the payload and state; non-members see only a marker transaction with no readable data.

A transaction whose payload is distributed only to members of a privacy group, with the public chain recording a hash-based marker instead of the data. State resulting from it is stored in a separate private state trie.

The public on-chain transaction that references a private transaction's hash and privacy group, proving it occurred without revealing contents. It carries a special recipient address that the privacy precompile recognises.

Publishing contract code by sending a transaction with no recipient and the compiled bytecode as data. The resulting contract address derives from the sender address and nonce, and the receipt confirms success or revert.

The process of simulating a transaction to predict the gas it will consume, exposed through eth_estimateGas. Accurate estimates prevent out-of-gas failures, and Besu applies the block gas limit as a ceiling.

A JSON-RPC method that executes a contract function against current or specified state without creating a transaction. It returns the decoded result immediately and is used for read-only queries and pre-flight checks.

The guarantee that a signed transaction valid on one chain cannot be resubmitted on another. It relies on the chain ID in the signature, so mismatched chain IDs cause nodes to reject the transaction outright.

The ability of a network to keep finalising blocks despite failed or partitioned validators. It depends on having more than two-thirds of validators online, so validator count and placement directly affect resilience.