Развертывание блокчейна на Hyperledger Besu

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1306 услуг
Развертывание блокчейна на Hyperledger Besu
Сложный
~1-2 недели
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1308
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1221
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    921
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1149
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    611
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    886

Развёртывание блокчейна на 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 дня