Мости між екосистемами

(Розділ: Екосистема та Мережа)

1) Навіщо потрібні мости

Мости забезпечують передачу цінності і даних між різними доменами: блокчейнами, платіжними рейками, партнерськими платформами, дата-озерами та API-мережами. Це розширює ліквідність, об'єднує аудиторію і прискорює інтеграції без централізації. Ключові ефекти: зростання GTV, зниження тертя онбордингу партнерів, нові продукти (крос-ігрові активи, мультичейн-платежі, єдина ідентичність).

2) Таксономія мостів

1. Custodial - централізований зберігач випускає «обгорнуті» активи/повідомлення. Просто, але ризик контрагента.
2. Federated/MPC - набір валідаторів/оракулів спільно підписує події; краще децентралізація, але є довіра до федерації.
3. Light-client-based - цільова мережа перевіряє криптодокази вихідної мережі (заголовки/меркл-гілки); висока криптографічна надійність.
4. Optimistic - події приймаються із затримкою для можливих суперечок (challenge period).
5. ZK-proof-based - короткі докази коректності стану/переходів; швидко і безпечно, дорожче в обчисленні.
6. Liquidity-network - переклад цінності через маркет-мейкерів/канали (HTLC/канали, «моментальна» ліквідність, але є ризик надання ліквідності).
7. Messaging-only - перенесення даних/викликів без токенів (команди, статуси, квитанції).

3) Модель довіри і вибір архітектури

Необхідна гарантія: економічна фіналізація (невідкатність), криптографічна верифікація або довіра до операторів.
Затримка: light-client/ZK - швидше/дорожче; optimistic - затримка на вікно спору; custodial - швидко, але «людська» довіра.
Вартість: плата за газ/докази/підписи, опортуністична вартість ліквідності.
Операційка: хто ротуує ключі, моніторить алерти, проводить аварійні паузи.
Рекомендація: для критичних грошових потоків - light-client/ZK; для даних і команд - messaging-only поверх підписів і квітування; для роздрібних платежів - liquidity-network з лімітами та страховкою.

4) Об'єкти та типи повідомлень

Токен-трансфери: lock/mint, burn/release, escrows, rebalancing.
Платежі та виплати: мультичейн, конверсія, розклад.
Дані/події: KYC-статуси, ліміти, ігрові події, результати верифікації.
Виклики (cross-chain calls): виконання функції/транзакції в цільовому домені.
Квитанції та підтвердження: proof-of-delivery, proof-of-execution, компенсуючі операції.

5) Маршрутизація та фіналізація

Source→Relay→Target: подія фіксується у вихідній мережі, доставляється релеєром, верифікується в цільовій.

• Економічна: після K підтверджень/епох.
• Криптографічна: light-client/ZK-докази.
• Вікно спору: optimistic-модель.
• Порядок та ідемпотентність: детерміновані idempotency-key і nonce, дедуплікація на цільовій стороні.

6) Ризики та загрози

Підміна/повтор (replay) повідомлень.
Компрометація ключів федерації/операторів.
Помилки меппінгу активів (невідповідність decimals, chainId).
Брак ліквідності, сліппедж/фронт-ран.
Атаки на релеєрів/оракули (лаги, цензурування).
Неузгодженість форків/реоргів.
Неправильні ліміти і відсутність «стоп-кранів».

7) Політики безпеки

mTLS + підписи подій (ed25519/secp256k1), пінінг ключів.
Nonce/sequence на кожну пару (chainA→chainB).
ACL за типами повідомлень/активів/лімітами.
Rate-limits/velocity-checks на трансфери та повідомлення.
Circuit-breaker: глобальна/по-парам пауза при аномаліях.
Двофакторне виконання: технічний підпис + операційний мультисиг при великих сумах.
Список довірених конфігов: зіставлення chainId, decimals, адрес мостових контрактів/сервісів.

8) Економіка і ліквідність

Модель комісій: базова комісія + надбавка за пріоритет + плата за доказ.
Ліквідність: пули по мережах, моніторинг незакритих експозицій; ребаланс через зворотні потоки/маркет-ордери.
Сліппедж і котирування: котирування маркету, пред-авторизація лімітів, справедливий розподіл.
Страхування: фонд ризиків/страхування операторів мосту з публічною звітністю.
SLA виплат: цілі по швидкості підтвердження/доставки, компенсації при порушенні.

9) SLI/SLO і моніторинг

• Time-to-Finality p50/p95 (хв/сек).
• Success-Rate повідомлень/трансферів (%).
• Reorg/Challenge events (шт./добу).
• Liquidity Utilization (%), Pending Backlog (шт./сума).
• Cost-per-Transfer (ед.).
• Relay/Oracle Availability (%), Data Freshness (лаг).

• Success-Rate ≥ 99. 5%, p95 Finality ≤ 5 хв (або регламент мережі).
• Liquidity buffer ≥ 150% від 95-го перцентиля денного нетто-потоку.
• MTTA аномалій ≤ 5 хв, MTTR SEV-1 ≤ 30 хв.
• Звіти про стан мосту - щодня, інцидент-репорти ≤ 72 год.

10) Операційні регламенти

Версіонування протоколу: capability-negotiation, backward-сумісність, депрекейт-вікно ≥ 90 днів.
Ротація ключів: планові та аварійні процедури, «подвійні ключі» (old/new) з почерговим перемиканням.
Ліміти: добові/годинні, за активами та за контрагентами; «екстрені» жорсткі ліміти.
Пауза/розморожування: хто активує, як оголошується, як знімається; Публічні статуси.
Журнали: незмінні логи подій/рішень з прив'язкою до proposal-ID (governance).
Перевірки відповідності: регулярні аудити конфігів, симуляції форків/реоргів.

11) UX і розробник-досвід

Єдині квитанції та статуси (pending, finalized, challenged, failed).
Track & Trace: посилання/ID, прогрес-бар фіналізації, ETA.
Ідемпотентні SDK з автоматичними ретраями/дедупом.
Довідник активів та мереж: єдиний реєстр з версіями та локалями.
Сповіщення: вебхуки/вебсокети про зміну статусу, ліміти, паузи.

12) Комплаєнс і ризик-контроль

KYC/KYB для впливаючих ролей (оператори, провайдери, релеєри).
AML/санкційні фільтри до і після перекладу; блок-листи.
Data residency: маршрутизація та шифрування за локальними вимогами; псевдонімізація.
Аудит: зовнішні перевірки коду/конфігів, звітність по фонду ризиків.
Політика спірних ситуацій: терміни, докази, оборотність (reversal policies для messaging-only).

13) Тестування та валідація

Симуляції форків/реоргів: перевірка повторної доставки і відмін.
Fuzzing вхідних подій: великі payload-и, рідкісні edge-кейси.
Chaos-тести релеєрів/оракулів: затримки, відключення, втрата зв'язності.
Backfill/Replay: безпечна пере-реплікація історії із захистом від дублів.
Навантажувальні тести ліквідності: шторм заявок, ребаланс під тиском.

14) Playbook інцидентів (шпаргалка)

• Заморозити відповідні пари chainA→chainB, включити сувору перевірку nonce/ACL, ревізія журналів, публікація статусу.

• Включити пріоритетне ребалансування, підняти ліміти на маркет-мейкерів, тимчасово збільшити комісії, повідомити ETA, по SLO - компенсація.

• Негайний відгук ключа, перехід на аварійний мультисиг, перестворення довірених списків, ротація SDK-конфігів, публічний звіт.

• Збільшити K-підтверджень/delay, тимчасово переключитися на «підтверджені» чекпойнти, відкласти великі трансфери.

• Переключення на резервні канали, зниження частоти батчів, включення фільтрів і квот, незалежна перехресна верифікація.

15) Приклади конфігурацій (псевдо-YAML)

Маршрутизація та фіналізація

yaml bridge:
pairs:
- from: chainA to: chainB confirmations: 20 finality_mode: light_client  # or optimistic    zk nonce_window: 1000 rate_limits:
per_minute: 500 per_hour: 20000 circuit_breaker:
enabled: true error_rate_threshold: 0.5  # %
open_window_sec: 900

Ліквідність і комісії

yaml liquidity:
pools:
chainA: { base: 2_000_000, buffer_pct: 50 }
chainB: { base: 1_500_000, buffer_pct: 60 }
fees:
base_bps: 8 priority_bps: 5 insurance_fund:
size: 1_000_000 policy: "cover shortfall up to 30%"

Безпека та ключі

yaml security:
signing:
mode: mpc threshold: "t-of-n: 5/8"
acl:
assets_allowlist: [USDC, GAME, POINTS]
methods_allowlist: [transfer, call, message]
alerts:
pager_on:
- "success_rate<99.2%"
- "p95_finality>10m"
- "liquidity_utilization>85%"

16) Схеми даних та ідемпотентність (псевдо-SQL)

sql
-- Регистр заявок на перенос
CREATE TABLE bridge_transfers(
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
src_tx TEXT, status TEXT, created_at TIMESTAMPTZ,
nonce BIGINT, sender TEXT, recipient TEXT,
meta JSONB
);

-- Квитанции/доказательства
CREATE TABLE bridge_receipts(
transfer_id TEXT REFERENCES bridge_transfers(id),
proof_type TEXT, proof JSONB, received_at TIMESTAMPTZ,
UNIQUE(transfer_id, proof_type)
);

-- Идемпотентность целевой цепи/домена
CREATE TABLE bridge_idempotency(
dst_chain TEXT, nonce BIGINT, hash TEXT,
PRIMARY KEY (dst_chain, nonce)
);

17) Дашборди

Real-time Ops: Success-Rate, p95/p99 Finality, backlog, relay/oracle availability, burn-rate SLO.
Liquidity & Cost: завантаження пулів, utilization, cost-per-transfer, страховий фонд.
Security & Risk: challenge/reorg події, rate-limit спрацьовування, паузи/розморожування.
Governance & Compliance: зміни лімітів/ключів, звіти аудиту, метрики SLA.

18) Чек-лист впровадження

1. Виберіть модель довіри (light-client/ZK для грошей; messaging-only для команд).
2. Зафіксуйте схему повідомлень, nonce/ідемпотентність, ACL і ліміти.
3. Налаштуйте фіналізацію (K підтверджень/вікно спору), circuit-breaker і ротацію ключів.
4. Підніміть дашборди SLI/SLO і оповіщення; оформіть публічні статуси.
5. Розгорніть пул ліквідності і страховий фонд, включіть ребаланс.
6. Проведіть аудит/пентест і регулярні симуляції форків/відмов релеєрів.
7. Регламентуйте комунікації та політику спірних ситуацій.

19) Глосарій

Finality - незворотність транзакцій/подій.
Challenge period - вікно оспорювання (optimistic-модель).
Light client - верифікація заголовків і доказів іншої мережі.
ZK-proof - короткий доказ коректності обчислення/стану.
HTLC - атомарний обмін на умовних платежах/секретах.
MPC - спільний підпис без розкриття приватних ключів.
Idempotency - стійкість до повторної доставки.

Підсумок: надійний міст - це не тільки «з'єднання мереж», а керована система з криптографії, лімітів, ліквідності, спостережуваності та операційних регламентів. Дотримуючись цих принципів, екосистема отримує безпечну і передбачувану інтероперабельність без сюрпризів для користувачів і партнерів.