Технічна підтримка блокчейн-проекту

Технічна підтримка блокчейн-проекту

Блокчейн-інфраструктура ломається по-іншому, ніж звичайні веб-сервіси. Нода може зависнути на конкретному блоці через edge case в consensus клієнті. Смарт-контракт може вести себе коректно при тестуванні, але непередбачливо при взаємодії з іншим протоколом через flash loan. RPC-провайдер може почати повертати застарілі дані без явних помилок. Підтримка таких систем вимагає специфічних знань, яких немає у звичайної DevOps команди.

Що входить в постійну підтримку

Моніторинг інфраструктури:

• On-chain моніторинг смарт-контрактів (незвичайні виклики, зміни state)
• Стан нод (sync lag, peer count, версія клієнта)
• Стан валідаторів / sequencer
• Працездатність bridge контрактів
• Баланс service акаунтів (relayer, deployer, keeper)

Реагування на інциденти:

• Дежурство по розкладу з SLA на перший ответ
• Діагностика і виправлення проблем з нодами
• Emergency pause контрактів при обнаруженні експлойту
• Координація з аудиторами при security-інцидентах

Обслуговування:

• Оновлення клієнтів (Geth, Lighthouse тощо) при виході нових версій
• Застосування hotfix в смарт-контрактах через upgrade механізм
• Ротація ключів сервісних акаунтів
• Оновлення RPC endpoints при деградації провайдерів

Мониторинговий стек

# docker-compose monitoring stack
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml

Prometheus правила алертів для типичного EVM проекту:

groups:
  - name: blockchain
    rules:
      - alert: NodeSyncLag
        expr: eth_syncing_current_block - eth_syncing_highest_block > 50
        for: 5m
        labels: { severity: warning }
        annotations:
          summary: "Node is {{ $value }} blocks behind head"

      - alert: ServiceWalletLowBalance
        expr: eth_balance{account="relayer"} < 0.1
        for: 1m
        labels: { severity: critical }
        annotations:
          summary: "Relayer wallet balance critical: {{ $value }} ETH"

      - alert: ContractPaused
        expr: contract_is_paused == 1
        for: 0m
        labels: { severity: critical }
        annotations:
          summary: "Contract {{ $labels.contract }} is paused"

On-chain моніторинг через OpenZeppelin Defender

Defender Sentinel — моніторинг конкретних подій та вызовов на контракте:

// Sentinel конфігурація (через Defender UI або API)
{
  "type": "BLOCK",
  "network": "mainnet",
  "addresses": ["0xYOUR_CONTRACT"],
  "abi": [...],
  "eventConditions": [
    { "eventSignature": "RoleGranted(bytes32,address,address)" },
    { "eventSignature": "Upgraded(address)" }  // proxy upgrade event
  ],
  "functionConditions": [
    { "functionSignature": "pause()" }
  ]
}

При срабатыванні — webhook в ваш сервіс або прямо уведомлення в Telegram/PagerDuty.

Реагування на security інцидент

У кожного протоколу з TVL повинен бути runbook для security-інцидентів. Типичний сценарій:

1. Обнаружение (автоматичний алерт або зовнішній репорт)
2. Оцінка (5–15 хвилин): розмір ущерби, активний ли exploit, можна ли pauseити
3. Пауза (якщо контракт pausable): негайно, не чекати повного аналізу
4. Уведомлення (15–30 хвилин): команда, держателі токенів, аудиторы
5. Розслідування: аналіз трансакцій в Tenderly, trace exploit
6. Виправлення: hotfix контракту, аудит виправлення
7. Post-mortem: публічний звіт про сталося

Для кроку "пауза" — pauser role повинна бути настроєна на Gnosis Safe з 1/N threshold (швидке реагування), а upgrade role — на Safe з N/M threshold (повільне, безпечне змінення).

Підтримка нод: часті проблеми

Geth зависнув на блоці:

# Діагностика
curl -s -X POST localhost:8545 \
  -d '{"jsonrpc":"2.0","method":"debug_traceBlockByNumber","params":["latest",{}],"id":1}'

# Якщо нода завила — restart з --gcmode archive і --syncmode full
# Якщо проблема з state corruption — resync від checkpoint
geth snapshot prune-state  # звільняє місце, іноді допомагає

Consensus клієнт не бачить peers:

lighthouse bn --libp2p-addresses /ip4/0.0.0.0/tcp/9000  # перевірити що порт відкритий
# Перевірити firewall:
iptables -L INPUT | grep 9000

op-batcher не публікує батчи:

• Перевірити баланс batcher wallet (потрібен ETH для L1 трансакцій)
• Перевірити L1 RPC доступність
• op-batcher logs на channel_full або tx_failed

SLA та моделі підтримки

Для проектів з TVL > $1M і живими користувачами мінімальний розумний рівень — Production.