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.
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.
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.
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.
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 7 Foundation validators today, with a public path to 7 and then 21.
AERE produces one block per second with instant 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.
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 4 cores / 2.5 GHz | 8 cores / 3.0 GHz+ |
| RAM | 16 GB | 32 GB |
| Storage | 500 GB SSD | 1 TB NVMe SSD |
| Network | 25 Mbps symmetric | 100 Mbps symmetric, low latency |
| OS | Ubuntu 22.04 LTS | Ubuntu 22.04 LTS (server, no GUI) |
| Java | OpenJDK 21 | OpenJDK 21 |
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.
AERE Network runs on Hyperledger Besu, an enterprise-grade Java Ethereum client maintained by the Hyperledger Foundation. The following steps assume Ubuntu 22.04.
sudo apt update && sudo apt install -y openjdk-21-jre-headless
java -version # should print openjdk 21...
# Check the latest release at https://github.com/hyperledger/besu/releases
VERSION=24.12.0
wget https://github.com/hyperledger/besu/releases/download/${VERSION}/besu-${VERSION}.tar.gz
tar -xzf besu-${VERSION}.tar.gz
sudo mv besu-${VERSION} /opt/besu
sudo ln -s /opt/besu/bin/besu /usr/local/bin/besu
besu --version
# Create a dedicated data directory mkdir -p /opt/aere-node/data # Besu generates a node key automatically on first start, # but you can generate one explicitly and back it up: besu --data-path=/opt/aere-node/data operator generate-blockchain-config \ --config-file=genesis.json \ --to=output/ \ --private-key-file-name=key # Your node key will be at /opt/aere-node/data/key # BACK THIS UP. Losing it means losing your validator identity.
cd /opt/aere-node wget https://git.aere.network/aere-network/aere-node/raw/branch/main/genesis.json wget https://git.aere.network/aere-network/aere-node/raw/branch/main/static-nodes.json cp static-nodes.json data/
besu \ --data-path=/opt/aere-node/data \ --genesis-file=/opt/aere-node/genesis.json \ --network-id=2800 \ --p2p-port=30303 \ --rpc-http-enabled \ --rpc-http-host=127.0.0.1 \ --rpc-http-port=8545 \ --rpc-ws-enabled \ --rpc-ws-host=127.0.0.1 \ --rpc-ws-port=8546 \ --host-allowlist="localhost,127.0.0.1" \ --metrics-enabled \ --metrics-host=127.0.0.1 \ --metrics-port=9545 \ --logging=INFO
Running Besu as a systemd service ensures it restarts automatically on failure or reboot:
# /etc/systemd/system/aere-node.service
[Unit]
Description=AERE Network Validator Node
After=network-online.target
Wants=network-online.target
[Service]
User=aere
ExecStart=/usr/local/bin/besu \
--data-path=/opt/aere-node/data \
--genesis-file=/opt/aere-node/genesis.json \
--network-id=2800 \
--p2p-port=30303 \
--rpc-http-enabled --rpc-http-host=127.0.0.1 \
--rpc-ws-enabled --rpc-ws-host=127.0.0.1 \
--metrics-enabled --metrics-host=127.0.0.1 \
--logging=INFO
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
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
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.
qbft_proposeValidatorVote with your address and true. This is coordinated by the Foundation, not a token vote.The full, up-to-date onboarding guide (candidate requirements, how to submit your address, the current queue from 6 toward 7 and then 21 validators) lives at aere.network/run-a-validator.
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.
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.
0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0) earns a variable staker-yield from the AereSink split, and AereLockedStaking (0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad) offers fixed-term locks (30d/10%, 90d/15%, 180d/22%, 365d/30% APY). Both are open to any holder for yield. Neither grants validation rights or block-proposal duties.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 exposes a Prometheus metrics endpoint at port 9545 when --metrics-enabled is set. Key metrics to watch:
besu_blockchain_height, should increase ~1 per second.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.# 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.
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.
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.
/opt/aere-node/data/key), it is your validator's permanent identity.qbft_proposeValidatorVote true), not by staking. There is no stake-to-validate and no slashing; accountability is removal by the same vote (false).