Run an AERE Validator

Module 1, What Validators Do in QBFT

AERE Network uses QBFT (Quorum Byzantine Fault Tolerant) consensus. Unlike Proof-of-Work where anyone who solves a hash puzzle proposes a block, QBFT relies on a known, permissioned set of validators. Understanding what validators actually do helps you run one responsibly.

Proposing blocks

Validators take turns proposing new blocks in a round-robin rotation. When it is your turn, your node collects pending transactions from the mempool, orders them, and broadcasts a proposed block to all other validators. The proposer is deterministic, every node in the network can independently calculate whose turn it is.

Voting on blocks

When a validator receives a proposed block, it verifies that the block is structurally valid (correct parent hash, valid signatures on transactions, gas limits respected). If valid, it broadcasts a prepare message. Once a validator sees enough prepare messages from its peers (a quorum), it broadcasts a commit message. Once a block accumulates enough commit messages, it is finalized and cannot be changed.

Liveness and safety

QBFT guarantees safety as long as no more than one-third of validators are Byzantine (dishonest or faulty). It guarantees liveness (the chain keeps making progress) as long as more than two-thirds of validators are online and responsive. If your validator goes offline, you reduce the safety margin and slow the network, validator operators have a responsibility to maintain high uptime.

Validator identity

Each validator is identified by its node key, a secp256k1 key pair where the public key (and its derived address) is the validator's identity on-chain. The active validator set is maintained by Besu's QBFT protocol itself and can be read at any time with the qbft_getValidatorsByBlockNumber RPC method. There is no stake, no bond, and no deposit that makes an address a validator: the set changes only when the existing validators vote a candidate in or out. There are 10 Foundation validators today (f=3, quorum 7-of-10), with a public path to 21.

Module 2, Hardware Requirements

AERE produces a block about every 0.62 seconds (0.5 s target) with deterministic finality. This is less compute-intensive than Proof-of-Work, but more demanding in terms of network latency and storage I/O than a light client.

Storage grows over time as the chain accumulates history. The NVMe recommendation is important: Hyperledger Besu performs many random small reads and writes per block. SATA SSDs work but will bottleneck at sustained load. Spinning disks will not keep up.

Module 3, Running the AERE node

AERE Network runs a fork of Hyperledger Besu, an enterprise-grade Java Ethereum client maintained by the Hyperledger Foundation. Stock Besu stops following chain 2800 at block 9,189,161, where the post-quantum precompiles activated, so the node is built from upstream Besu plus the patches published in the public aere-node package. The steps assume Ubuntu 22.04.

Install Java 21 and git

sudo apt update && sudo apt install -y openjdk-21-jdk-headless git
java -version  # should print openjdk 21...

Get the node package

git clone https://git.aere.network/aere-network/aere-node.git
cd aere-node

The package carries the chain-2800 genesis file, byte for byte as it sits on the Foundation nodes (its sha256 is printed in RUN-A-NODE.md and checked by the script), the patches and the bootnode list. The benchmark genesis in the public research repository is a different chain (chainId 28777) and will not sync you to 2800, so do not substitute it.

Build and start the node

# verifies the genesis and the registries by sha256, fetches upstream Besu at the named commit,
# applies the mainnet patches in order, builds, and starts a full node syncing from block 0
./run-node.sh --bootnode <enode://...@host:port>   # a bootnode published in RUN-A-NODE.md
./run-node.sh --help   # --data-path, --p2p-port, --rpc-port, --sync-min-peers, --no-start, --rebuild

The script holds no key and signs nothing. It configures a node that validates chain 2800, including the post-quantum certificate anchor, but does not produce seals: a validator also needs its validator keys, which are set up during admission (Module 4). Every step the script performs is written out by hand in RUN-A-NODE.md for anyone who wants to audit it rather than run it.

Your node key

# Besu creates the node key on first start, in the data directory (<data-path>/key).
# BACK IT UP. For a validator, losing it means losing the validator identity.

Run it as a service

For automatic restarts on failure or reboot, run the same run-node.sh command, with your options, as the ExecStart of a systemd unit owned by a dedicated user, then:

sudo systemctl daemon-reload
sudo systemctl enable aere-node
sudo systemctl start aere-node
sudo journalctl -fu aere-node  # follow logs

Once your node is synced, check peering:

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","id":1}'
# {"jsonrpc":"2.0","id":1,"result":"0x5"}  ← 5 peers, good

Module 4, Becoming a Validator, and Accountability

AERE does not use proof-of-stake. There is no stake-to-validate, no minimum bond, no 32-AERE deposit, and no delegation. Validators are admitted by governance: the existing validator set votes a candidate in, and later can vote a misbehaving one out. This is standard Hyperledger Besu QBFT behavior.

How a candidate is admitted

1. You stand up a fully synced Besu node (Modules 1 to 3) and share your validator address with the Foundation through the onboarding process.
2. Each existing validator calls qbft_proposeValidatorVote with your address and true. This is coordinated by the Foundation, not a token vote.
3. Once a majority of the current validators have proposed your address, QBFT adds you to the active set at the next epoch block. Your node begins proposing and voting on blocks immediately.
4. No AERE changes hands. Admission is a permissioning decision, not a purchase.

The full, up-to-date onboarding guide (candidate requirements, how to submit your address, the live set of 10 validators (as read from the chain at 2026-11-01 17:00 UTC; 7 until 2026-08-09, 9 until 2026-09-11) and the public path to 21) lives at aere.network/run-a-validator.

What validators earn

Validators are not paid a staking APY. They earn the per-block fee remainder: after each block's coinbase split is routed by the AereCoinbaseSplitter (0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec) and AereCoinbaseSplitterV2 (0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4), the remaining fees accrue to the block's proposer. Reward is therefore tied to actually proposing blocks and staying online, not to any locked balance. On 2026-10-15 that remainder is close to zero: the base fee is destroyed by EIP-1559 and priority fees are zero, so the splitter has handled 0.366 AERE in its whole life.

Accountability, no on-chain slashing

AERE has no slashing contract. Nothing is burned, and there is no equivocation penalty or unbonding period, because no stake is ever posted. A validator that misbehaves or stays offline is instead removed by governance: the remaining validators call qbft_proposeValidatorVote with the offender's address and false, and once a majority agrees the address is dropped from the active set. Accountability is social and operational, backed by the ability to remove, not financial.

Module 5, Monitoring Your Validator

A validator running without monitoring is a liability. At a minimum, you need to know immediately if your node stops producing blocks, falls behind in sync, or loses peers.

Besu metrics (Prometheus)

Besu exposes a Prometheus metrics endpoint at port 9545 when --metrics-enabled is set. Key metrics to watch:

• besu_blockchain_height, should increase about 1.6 per second (one block every ~0.62 s, measured).
• besu_peers_connected_total, if this drops to 0, your node is isolated.
• besu_synchronizer_in_sync, 1 means fully synced, 0 means catching up.
• besu_transaction_pool_transactions, size of pending transaction pool.

Grafana + Prometheus setup (quick start)

# prometheus.yml, add a scrape job for Besu
scrape_configs:
  - job_name: aere_validator
    static_configs:
      - targets: ['127.0.0.1:9545']
    scrape_interval: 10s

Run Prometheus and Grafana via Docker Compose alongside your Besu node. The Besu community maintains a pre-built Grafana dashboard (import dashboard ID 10273 from grafana.com) that works with QBFT nodes and shows block production, peer count, and JVM health in one view.

On-chain check

You can verify your validator is actively signing blocks by querying the explorer. Search your validator address at explorer.aere.network, the block production history shows whether your node is participating in consensus.

Alerting

Set up an alert rule in Grafana (or Prometheus Alertmanager) that fires if besu_blockchain_height does not increase for more than 30 seconds. Route alerts to a Telegram bot, PagerDuty, or your team's preferred channel. Slow response to a node outage reduces your fee earnings, weakens network liveness, and, if sustained, is grounds for the validator set to vote your node out.