Развёртывание блокчейна на Hyperledger Besu
Hyperledger Besu — единственный enterprise Ethereum клиент под лицензией Apache 2.0, написанный на Java. Его ключевое отличие от Geth и Erigon: Besu поддерживает permissioned сети через smart contract-based permissioning, несколько enterprise consensus алгоритмов (QBFT, IBFT 2.0, Clique), и нативно интегрируется в Hyperledger экосистему.
Выбирают Besu когда нужна EVM-совместимость (смарт-контракты на Solidity, инструменты Hardhat/Foundry, MetaMask из коробки) плюс контроль над участниками сети — в отличие от Fabric где нужен свой chaincode для каждой операции.
Архитектура permissioned сети
┌──────────────────────────────────────────────────────┐
│ Besu Network │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Bootnode │ │Validator1│ │Validator2│ ... │
│ │(no vote) │ │(QBFT) │ │(QBFT) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └─────────────┴─────────────┘ │
│ P2P Network │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Permissioning Contracts │ │
│ │ NodePermissioning AccountPermissioning │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
QBFT vs IBFT 2.0: выбор консенсуса
QBFT (Quorum Byzantine Fault Tolerance) — рекомендуемый алгоритм для новых сетей. Финальность сразу после включения в блок, нет форков. Tolerate до (n-1)/3 Byzantine нод — при 4 валидаторах переживаем 1 злонамеренный.
IBFT 2.0 — предшественник QBFT, схожие свойства, но менее производительный при больших validator sets. Оставлен для обратной совместимости.
Clique — PoA алгоритм, аналог Ethereum Goerli. Менее строгие гарантии финальности, но проще в операции. Для dev/staging окружений.
Минимальное число валидаторов для QBFT: 4 (терпит 1 отказ). Для production: 4–7 валидаторов от разных организаций.
Genesis файл
{
"config": {
"chainId": 1337,
"berlinBlock": 0,
"londonBlock": 0,
"qbft": {
"blockperiodseconds": 2,
"epochlength": 30000,
"requesttimeoutseconds": 4,
"blockreward": "0",
"validatorcontractaddress": "0x0000000000000000000000000000000000008888"
}
},
"nonce": "0x0",
"timestamp": "0x5b3d92d7",
"gasLimit": "0x1fffffffffffff",
"difficulty": "0x1",
"mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
"coinbase": "0x0000000000000000000000000000000000000000",
"alloc": {
"0xfe3b557e8fb62b89f4916b721be55ceb828dbd73": {
"privateKey": "...",
"comment": "validator 1",
"balance": "0xad78ebc5ac6200000"
}
},
"extraData": "0x..."
}
extraData для QBFT должен содержать RLP-кодированный список адресов начальных валидаторов. Используем besu operator generate-blockchain-config для генерации genesis с ключами:
besu operator generate-blockchain-config \
--config-file=qbftConfigFile.json \
--to=networkFiles \
--private-key-file-name=key
Это генерирует genesis.json + директории для каждого ноды с ключами и enode URL.
Docker Compose для локальной сети
version: '3.8'
services:
bootnode:
image: hyperledger/besu:latest
command: |
--node-private-key-file=/opt/besu/keys/bootnode/key
--data-path=/opt/besu/data
--genesis-file=/opt/besu/config/genesis.json
--rpc-http-enabled=true
--rpc-http-host=0.0.0.0
--rpc-http-port=8545
--rpc-http-api=ETH,NET,QBFT,ADMIN,WEB3
--host-allowlist=*
--rpc-http-cors-origins=all
--p2p-port=30303
--logging=INFO
volumes:
- ./config:/opt/besu/config:ro
- ./keys:/opt/besu/keys:ro
- bootnode-data:/opt/besu/data
ports:
- "8545:8545"
- "30303:30303"
validator1:
image: hyperledger/besu:latest
depends_on: [bootnode]
command: |
--node-private-key-file=/opt/besu/keys/validator1/key
--data-path=/opt/besu/data
--genesis-file=/opt/besu/config/genesis.json
--bootnodes=enode://${BOOTNODE_PUBKEY}@bootnode:30303
--rpc-http-enabled=true
--rpc-http-host=0.0.0.0
--rpc-http-port=8546
--rpc-http-api=ETH,NET,QBFT
--p2p-port=30304
volumes:
- ./config:/opt/besu/config:ro
- ./keys:/opt/besu/keys:ro
- validator1-data:/opt/besu/data
volumes:
bootnode-data:
validator1-data:
Permissioning: контроль участников
Besu поддерживает два уровня permissioning:
Node permissioning — какие ноды могут подключаться к P2P сети. Smart contract-based: список разрешённых enode URL хранится в контракте, динамически обновляется без рестарта нод.
Account permissioning — какие accounts могут отправлять транзакции и деплоить контракты. Также через контракт.
# Включение permissioning в конфиге ноды
--permissions-nodes-contract-enabled=true
--permissions-nodes-contract-address=0x0000000000000000000000000000000000009999
--permissions-accounts-contract-enabled=true
--permissions-accounts-contract-address=0x0000000000000000000000000000000000008888
Контракты permissioning деплоятся при genesis (добавляем в alloc с bytecode) или после запуска сети. Besu предоставляет reference implementation:
git clone https://github.com/ConsenSys/permissioning-smart-contracts
cd permissioning-smart-contracts
npm install
# Деплой через Hardhat с указанием начальных валидаторов и нод
Мониторинг и управление
# Список текущих валидаторов через QBFT API
curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}' \
http://localhost:8545
# Добавление нового валидатора (требует BFT majority голосования)
curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["0xNewValidatorAddress",true],"id":1}' \
http://localhost:8545
Grafana + Prometheus: Besu экспортирует метрики в Prometheus формате на порту 9545 (--metrics-enabled=true --metrics-host=0.0.0.0 --metrics-port=9545). Официальный Grafana dashboard: github.com/ConsenSys/quorum-monitoring.
Интеграция с существующими инструментами
Besu — EVM-совместимый, поэтому работают без изменений:
- Hardhat/Foundry — деплой контрактов, тесты
- MetaMask — добавить кастомную сеть через Custom RPC
- ethers.js / web3.js / viem — без изменений кода
- OpenZeppelin контракты — полностью совместимы
- The Graph — можно деплоить локальный graph-node для индексации
Разница только в том, что private/permissioned нода — это ваш собственный RPC endpoint, а не общедоступный.
Типичные этапы деплоя
| Этап | Задачи | Срок |
|---|---|---|
| Дизайн сети | Количество организаций, валидаторов, consensus параметры | 1–2 дня |
| Genesis | Генерация ключей, genesis.json, alloc | 1 день |
| Infrastructure | Сервера, Docker/K8s, networking | 2–3 дня |
| Deployment | Запуск нод, синхронизация, проверка | 1–2 дня |
| Permissioning | Деплой контрактов, настройка ролей | 1–2 дня |
| Smart contracts | Деплой бизнес-логики | зависит от объёма |
| Monitoring | Prometheus, Grafana, алерты | 1 день |
| Documentation | Runbook, onboarding для операторов | 1–2 дня |







