Skip to content
BaseHub by Will Binns Updated

consensus

base-consensus runs the Base consensus layer, implementing the OP Stack consensus protocol on top of the Kona derivation framework.

The consensus binary:

  1. L1 derivation — Connects to L1 Ethereum to read rollup data and derives L2 blocks from L1 batches using the derivation pipeline
  2. P2P networking — Manages peer-to-peer networking for block gossip and state sync
  3. Engine API — Communicates with the execution layer (base-reth-node) via the Engine API to deliver derived payloads
  4. Kona integration — Uses kona-node-service for the core consensus loop and kona-genesis for chain configuration
  • base-cli-utils — CLI utilities (logging, metrics)
  • base-client-cli — Client CLI extensions
  • kona-genesis — Genesis configuration
  • kona-cli — Consensus CLI framework
  • kona-node-service — Node service orchestration
Terminal window
cargo build --bin base-consensus --release
Terminal window
./target/release/base-consensus [OPTIONS]

The consensus node must be configured with:

  • An L1 Ethereum RPC endpoint for reading rollup data
  • An Engine API endpoint for communicating with the execution layer
  • A P2P configuration for block gossip

Serving execution methods from the consensus port

Section titled “Serving execution methods from the consensus port”

By default the consensus RPC answers only its own methods. A call such as eth_getBlockByNumber fails with method not found, so a client that needs both layers has to hold two URLs. #5506 adds an opt-in fix: --rpc.execution-forwarding-endpoint <url> (env BASE_NODE_RPC_EXECUTION_FORWARDING_ENDPOINT). Point it at the execution client’s plain, unauthenticated HTTP RPC. There is no default. It works on base-consensus node, base-consensus follow, base rpc, base follow, and base sequencer.

With the flag set, any method the consensus server does not serve goes to that endpoint unchanged, and its result or error comes back as is. The match is on the exact method name. A method the consensus server serves itself is never forwarded, even if the execution client has one of the same name. Each entry in a batch is routed on its own. Notifications are not forwarded. Forwarded calls share --rpc.max-concurrent and --rpc.timeout with the server’s own requests. If the execution client returns no valid response, or a response over 10 MB, the caller gets a bare -32603 internal error, and the real cause goes only to the log.