Skip to content

Архитектура Blockchain Integrity Appliance

Общая схема

graph TB subgraph INFRA["Инфраструктура OZON"] subgraph SOT["Source of Truth: любой сервис Ozon"] S1["Order Service"] S2["Contract Service"] S3["Logger"] S4["CRM"] end subgraph IA["Integrity Appliance"] API["Go REST API"] --> HE["Hash Engine
(SHA-256)"] HE --> POA_NODE["PoA Node
(Ethereum Client)"] JDB[("Journal DB
(PostgreSQL)")] JDB -.->|хранит proof-ы и метаданные| API end S1 -.-> API S2 -.-> API S3 -.-> API S4 -.-> API end subgraph NET["PoA CONSENSUS NETWORK
6 Валидаторов"] N1["Node 1
(ДЦ А)"] --- N2["Node 2
(ДЦ B)"] --- N3["Node 3
(ДЦ C)"] N4["Node 4
(ДЦ D)"] --- N5["Node 5
(ДЦ E)"] --- N6["Node 6
(OZON)"] N1 --- N4 N3 --- N6 NOTES["Consensus: IBFT 2.0
Block time: 3-12 сек
Gas: 0 (бесплатные транзакции)"] end POA_NODE -->|публикует хеши| N6

Компоненты Appliance

1. REST API (Go)

  • Фреймворк: chi или стандартный net/http
  • Эндпоинты:
Метод Путь Описание
POST /api/v1/proof Отправить данные на proof
GET /api/v1/proof/:id Получить proof по ID
GET /api/v1/proof/tx/:txhash Получить proof по tx hash
GET /api/v1/verify Проверить документ (hash → proof)
GET /api/v1/status Health check + метрики ноды
GET /metrics Prometheus metrics

  • Формат запроса POST /proof: 

    {
  "document_id": "contract-2025-001",
  "hash": "sha256hex...",
  "metadata": {
    "type": "contract",
    "timestamp": 1715692800,
    "source": "contract-service.ozon.internal"
  }
}

  • Формат ответа: 

    {
  "status": "confirmed",
  "proof": {
    "tx_hash": "0x7a1e...f3c9",
    "block_number": 1047297,
    "block_hash": "0x...",
    "timestamp": 1715692802,
    "validator": "ozon-node"
  },
  "verification_url": "https://explorer.integrity.network/tx/0x7a1e...f3c9"
}

2. Hash Engine

  • SHA-256 (стандартный, может быть BLAKE2b для производительности)
  • Возможность пакетной обработки: несколько документов → Merkle tree → один root hash → одна транзакция
  • Bulk API до 1000 документов в одной транзакции

3. PoA Node (Ethereum Client)

  • Клиент: Go-Ethereum (geth) в режиме PoA
  • Consensus: IBFT 2.0 (Istanbul Byzantine Fault Tolerance)
  • Block time: 3-12 секунд
  • Finality: мгновенная (no fork possibility in PoA)

4. Journal DB (PostgreSQL)

  • Хранит полную историю: какие документы, когда, какой hash, какой tx hash
  • Служит для быстрой проверки без обращения к блокчейну
  • Реплицируется на внешний storage для disaster recovery

5. Мониторинг

  • Prometheus metrics: количество proof-ов, время подтверждения, статус консенсуса, загрузка CPU/RAM
  • Health check: /api/v1/status — состояние ноды, синхронизация, peers
  • Alerts: падение ноды, потеря синхронизации, деградация производительности

Процесс proof-ing (пошагово)

sequenceDiagram participant Client as Клиент participant Appliance as Appliance participant PoA as PoA Network Note over Client,PoA: Создание proof Client->>Appliance: POST /api/v1/proof activate Appliance Appliance->>Appliance: 1. Валидация входных данных Appliance->>Appliance: 2. Вычисление SHA-256 Appliance->>Appliance: 3. Формирование tx Appliance->>PoA: 4. IBFT consensus (3-12 сек) activate PoA PoA-->>Appliance: Подтверждение deactivate PoA Appliance->>Appliance: 5. Сохранение в Journal DB Appliance-->>Client: { tx_hash, block, ts } deactivate Appliance Note over Client,PoA: Верификация Client->>Appliance: GET /api/v1/verify activate Appliance Appliance->>PoA: 6. Запрос hash из блокчейна activate PoA PoA-->>Appliance: hash из блокчейна deactivate PoA Appliance->>Appliance: Сравнение hash: запрос vs блокчейн Appliance-->>Client: { valid: true/false } deactivate Appliance

Hardware спецификация (начальная оценка)

Компонент Минимальная Рекомендуемая (Ozon)
CPU 4 cores, 2.0 GHz 16 cores, 3.0 GHz (AMD EPYC 7313)
RAM 16 GB 64 GB
SSD 500 GB 1 TB NVMe + 4TB SAS
Сеть 1 GbE 10 GbE
Питание 1x 2N hot-swap
Форм-фактор 1U 1U

Оценка нагрузки: - 100 TPS хэшей → ~8.6M proof-ов в день - Размер 1 proof в блокчейне: ~100 байт - Рост блокчейна: ~1 GB в месяц при 100 TPS - Journal DB: ~30 GB в месяц (с метаданными)

Безопасность

Data leakage

  • Zero data leakage: только 32-байтовые хэши покидают периметр Ozon
  • Hash необратим — невозможно восстановить исходные данные
  • Метаданные (document_id, source) остаются только в Journal DB на appliance

Network security

  • Нода Ozon подключается к PoA сети через TLS
  • Белый список пиров (static-nodes.json)
  • API доступен только внутри сети Ozon
  • Option: дополнительная аутентификация запросов (API key / JWT)

Физическая безопасность

  • TPM 2.0 для защиты ключа валидатора
  • Secure boot
  • Encrypted storage (LUKS)

Аудит

  • Все изменения конфигурации логируются
  • Journal DB immutable (append-only)
  • Регулярная сверка Journal DB с блокчейном