Hyperledger Besu

Для реализации реестра ЦФА выбрана платформа Hyperledger Besu — высокопроизводительный Ethereum-клиент с открытым исходным кодом, поддерживающий приватные сети и корпоративные стандарты безопасности.

Почему Hyperledger Besu?

1. EVM-совместимость: Позволяет использовать зрелую экосистему смарт-контрактов Solidity для реализации логики ЦФА.
2. QBFT Консенсус: Обеспечивает мгновенную финальность транзакций (Instant Finality) и устойчивость к сбоям до 1/3 нод, что критично для финансовых операций.
3. Permissioning: Встроенные механизмы контроля доступа на уровне нод и аккаунтов.
4. Плагинная архитектура: Возможность расширения функционала (например, добавление поддержки российских криптографических стандартов).

Конфигурация сети

Сеть развернута в приватном контуре и состоит из валидаторов и архивных нод.

Параметры QBFT (Genesis)

{
  "config": {
    "chainId": 1337,
    "berlinBlock": 0,
    "qbft": {
      "blockperiodseconds": 2,
      "epochlength": 30000,
      "requesttimeoutseconds": 4
    }
  },
  "gasLimit": "0x1fffffffffffff",
  "difficulty": "0x1"
}

Besu Connector Service

Для интеграции с DLT используется отдельный микросервис apps/besu-connector. Он общается с другими сервисами только через Kafka и инкапсулирует JSON‑RPC вызовы в Besu.

Kafka темы

• Команды:
  • besu.command.sendRawTransaction
  • besu.command.getBlockNumber
  • besu.command.getTransactionReceipt
• События:
  • besu.event.transactionSubmitted
  • besu.event.transactionFailed
  • besu.event.transactionReceiptReady
  • besu.event.blockNumberRead

Локальный запуск через Docker Compose

Для локальной разработки сеть Besu поднимается через docker/docker-compose.besu-*.yml. Генерация genesis.json и ключей валидаторов выполняется автоматически при старте besu-init.

Генерация genesis и ключей валидаторов

Besu предоставляет операторский под‑командный инструмент для создания genesis.json и ключей:

besu operator generate-blockchain-config \
  --config-file=qbft-config.json \
  --to=network \
  --private-key-file-name=key

Файл qbft-config.json содержит параметры QBFT и количество валидаторов. Результатом является genesis.json и набор директорий в network/keys.

Структура файлов

infra/besu/
  qbft-config.json
  network/
    genesis.json
    keys/

Команды запуска

# DLT сеть создается базовым compose (или вручную: docker network create maniton_dlt)

# Генерация genesis.json и ключей валидаторов
docker compose -f docker/docker-compose.besu-init.yml up -d

# Запуск валидаторов
docker compose -f docker/docker-compose.besu-node1.yml up -d
docker compose -f docker/docker-compose.besu-node2.yml up -d
docker compose -f docker/docker-compose.besu-node3.yml up -d

RPC и P2P порты

• besu-node1: RPC 8545, P2P 30303
• besu-node2: RPC 8546, P2P 30304
• besu-node3: RPC 8547, P2P 30305

Порты можно переопределить в .env (пример — .env.example).

Проверка валидаторов

curl -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}' \
  http://localhost:8545

Permissioning

Доступ к нодам и аккаунтам ограничивается механизмами permissioning Besu. В прод‑контуре включается:

• Node Permissioning: белый список enode‑адресов валидаторов и архивных нод.
• Account Permissioning: разрешенные аккаунты для отправки транзакций.

Конфигурация хранится в управляемых файлах сети и синхронизируется с реестром валидаторов/операторов.

Важные примечания

• Ключи валидаторов генерируются в infra/besu/network/keys автоматически.
• Если требуется пересоздать сеть, удалите infra/besu/network и volume узлов Besu.

Интеграция с ГОСТ 34.11 / 34.10

Для соответствия требованиям регулятора (ЦБ РФ) используется гибридная модель:

1. На уровне DLT: Besu обрабатывает стандартные транзакции (ECDSA secp256k1).
2. Слой CFA-Core: На уровне Rust-модуля CFA-Core вычисляется дополнительный хэш блока по стандарту ГОСТ 34.11-2012.

Безопасность и ключи

• Web3Signer: Для подписания транзакций ноды не хранят приватные ключи. Вместо этого используется Web3Signer, подключенный к HSM (Hardware Security Module).
• RBAC: Доступ к RPC-интерфейсу Besu ограничен для внешних сервисов. Только авторизованные модули (CFA-Core) имеют право на отправку транзакций.

Мониторинг реестра

Для клиента в мобильном приложении данные из Besu агрегируются в Ledger-DB. При просмотре деталей актива клиент может видеть:

• Идентификатор транзакции в DLT.
• Хэш блока (SHA-256 + ГОСТ).
• Подтверждение от валидаторов сети.