Міжцепна аналітика

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

1) Що таке міжцепна аналітика і навіщо вона потрібна

• Єдиний облік цінності та активності: обсяги, ліквідність, комісії, ретеншн.
• Спостережуваність мостів і P2P-зв'язків: фіналізація, лаги, reorg/challenge події.
• Атрибуція трафіку та конверсій: cheyn→cheyn, kanal→produkt.
• Ризик і комплаєнс: AML, санкції, поведінковий фрод, ідентифікація сутностей.
• Прийняття рішень: OKR/бюджети, ліміти, регламенти оновлень і ліквідності.

2) Джерела даних і події (канонічний список)

1. Ланцюги/реєстри: блоки, транзакції, логи подій, стани смарт-контрактів.
2. Мости: заявки, квитанції, докази (light/optimistic/ZK), статуси фіналізації.
3. Провайдери платежів/КУС: проходження перевірок, ліміти, статуси виплат.
4. Продуктові події: онбординг, депозити/ставки/висновки, ігрові та поведінкові метрики.
5. P2P-транспорт: Pub/Sub квитанції, RPC-успішність, latency.
6. Довідники: мережі, активи, decimals, chainId, адреси контрактів, версії SDK.

3) Архітектура даних (потоки і сховища)

Ingest (стрімінг): конектори до нодів/індексерів, webhooks мостів, CDC з операційних БД.
Сирі шари (Bronze/Raw): незмінні партії з міткою'observed _ at'і метаданими джерела.
Очищення/нормалізація (Silver): дедуп, семантичне збагачення, вирівнювання таймзон, маппінг активів.
Моделі ядра (Gold/Core): уніфіковані факти «transfers», «bridges», «onchain _ events», «kyc _ status», «payouts».
Вітрини (Marts): фінанси (GTV/TVL/Take Rate), продукт (ретеншн/воронки), ризик (скоринги), операційка (SLO).
Кеш/Serve: OLAP/HTAP для дашбордів і API, і окремий пошук за адресами/tx.

Транспорт: Kafka/Pulsar (exactly-once semantics поверх ідемпотентності), об'єктне сховище для сировини, паркет/колонічні формати для аналітики.

4) Фіналізація, реорги та ідемпотентність

Стан подій: `observed` → `confirmed(k)` → `finalized` → `invalidated(reorg)`.
Правило підтверджень (K-confirmations): налаштовується за мережею/типом активу.
Optimistic/Challenge вікна: підтримка «оспорюваного» статусу для мостів.
Ідемпотентність: 'idempotency _ key = chainId'block'tx'logIndex'topic'( або хеш корисного навантаження).
Пере-програвання (replay): плановий backfill і відновлення при зміні індексера.

5) Модель ідентичностей і сутностей (entity resolution)

Адреса → Актор: адреси, ключі, гаманці ↔ аккаунт/організація/провайдер.
Крос-ланцюговий граф: зв'язку адрес одним власником (евристики, підпису, онбординг-дані).
Рівні впевненості: hard-link (KYC, on-chain підпис), soft-link (поведінкові кореляції).
Псевдонімізація: зберігайте стабільні ідентифікатори (PID) замість PII в аналітиці.

6) Уніфікована схема подій (спрощено)

yaml event:
id: string # global UUID observed_at: timestamp # when they saw chain_id: string # 'eth-mainnet', 'solana-mainnet',...
block_height: long tx_hash: string log_index: int event_type: string    # transfer    bridge. lock    bridge. mint    kyc. pass    payout. done...
status: string      # observed    confirmed    finalized    invalid actor_src: string # address/peer-id/source organization actor_dst: string # address/peer-id/destination organization asset: string # canonical symbol (e. g., USDC), + decimals amount: decimal usd_value: decimal # rate normalization at the observed_at bridge_ref: string # link with the application/receipt of the metadata bridge: object # network/contract/version/gac/fee, etc.
idempotency_key: string

7) Нормалізація активів і цін

Канонічний довідник активів: символ, decimals, chain mapping, контрактні адреси.
FX нормалізація: історичні курси та ціни активів за таймстемпом'observed _ at'.
Мульти-активні бандли: групуйте «обернені» і нативні активи.

8) Ключові метрики та вітрини

8. 1 Фінанси та ліквідність

GTV (Gross Transaction Volume) по мережах/активах/мостах.
TVL і Net Flow по мостах і пулах.
Take Rate/комісія на обсяг; Cost-to-Serve на трансфер.
Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.

8. 2 Продукт і користувач

Cross-chain MAU/DAU (dedup по PID),

Retention D1/D7/D30 з урахуванням мультичейн активності,

Funnel: вхідна мережа → міст → цільовий продукт → дію.
QoT (якість трафіку): валіда трафіку після анти-фрода.

8. 3 Ризик і комплаєнс

Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.
Anomaly rate за патернами перекладів, velocity-чек, clustering.
KYB/KYC Pass% і таймінги.

8. 4 Операційка і SLO

Bridge Success-Rate, p95 Finality, Relay Availability,

Reorg/Challenge events, Error budget burn.

9) Приклади SQL/псевдо-запитів

GTV по парам ланцюгів

sql
SELECT src. chain_id AS src_chain,
dst. chain_id AS dst_chain,
date_trunc('day', e. observed_at) AS d,
SUM(e. usd_value) AS gtv_usd
FROM events e
JOIN bridges b ON e. bridge_ref = b. id
JOIN networks src ON b. src_chain_id = src. id
JOIN networks dst ON b. dst_chain_id = dst. id
WHERE e. status = 'finalized' AND e. event_type IN ('bridge. lock','bridge. mint','transfer')
GROUP BY 1,2,3;

Cross-chain retention D7

sql
WITH first_touch AS (
SELECT pid, MIN(observed_at) AS t0
FROM product_events
WHERE event IN ('signup','first_deposit')
GROUP BY pid
),
week_activity AS (
SELECT DISTINCT pid
FROM product_events pe
JOIN first_touch ft USING(pid)
WHERE pe. observed_at BETWEEN ft.t0 + INTERVAL '1 day'
AND ft.t0 + INTERVAL '7 day'
)
SELECT 100. 0 COUNT() / (SELECT COUNT() FROM first_touch) AS d7_retention_pct
FROM week_activity;

Вітрина для SLO моста

sql
SELECT date_trunc('hour', observed_at) AS h,
100. 0 SUM(CASE WHEN status='finalized' THEN 1 END)/COUNT() AS success_rate,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY (finalized_at - observed_at)) AS p95_finality_min,
SUM(CASE WHEN challenge_event THEN 1 END) AS challenges
FROM bridge_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY 1;

10) Атрибуція і мульти-канальний шлях

Модель last-touch/position-based з вагами для джерела мережі, моста і продукту.
UTM→On-chain: зв'язуйте кліки/реферали з ончейн-адресою при онбордингу (за згодою).
Асоціативні моделі: Shapley/Markov для складних шляхів «set→most→produkt».

11) Анти-фрод і поведінкові сигнали

Графові ознаки: загальні контрагенти, кругові переклади, швидка оборотність.
Velocity-ліміти та аномалії: сплески, «дроблення» сум, нічні кластери.
Схеми шахрайства на мостах: повторна подача, спроби обходу KYC, сендвіч-патерни з ліквідністю.
Моделі: градієнтний бустинг/graph-embeddings; навчайте на розмітці інцидентів.

12) Приватність і комплаєнс (privacy-by-design)

PII мінімізація: PID замість прямих ідентифікаторів, токенізація.
Data residency: партіонування по регіонах, шифрування «в спокої/в дорозі».
Право на видалення: tombstone/redaction-події з доказовістю.
Доступ та аудит: рольові ACL, журнали читання, підписані звіти для перевірок.

13) SLI/SLO для аналітичних пайплайнів

• Freshness (медіана лага від'observed _ at'до появи в Gold),
• Completeness (% подій без дірок за очікуваннями K-confirmations),
• Correctness (% подій, що пройшли валідації схем/правил),
• Reorg handling success (% коректно інвалідацій/перегравань),
• Serve latency (p95 запитів до вітрин/дашбордів).

• Freshness p95 ≤ 3 хв (стримінг), ≤ 15 хв (батч).
• Completeness ≥ 99. 7%, Correctness ≥ 99. 9%.
• Reorg handling success ≥ 99. 9%.
• Serve p95 ≤ 500 мс (основні вітрини).

14) Спостережуваність даних і lineage

Data Lineage: від дашборду до сирої події (column-level).
Сигнали якості: completeness, uniqueness, referential integrity, schema drift.
Алерти: «тихі збої» (немає нових даних), стрибки розподілів, зростання'unknown'полів.

15) Дашборди (шаблони)

• Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.

• TVL, Net Flow per chain, cost-per-transfer, utilization, страховий фонд.

• MAU/DAU (dedup), cross-chain retention, канальні воронки, QoT.

• Fraud/Dispute Rate, sanctions hits, high-risk share, швидкість розглядів.

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

Інцидент: лаг свіжості> SLO

Перевірити конектори/індексери, переключитися на резерв, включити деградаційний режим (вітрини показують «останнє фіналізоване»), eskalate власнику джерела.

Інцидент: сплеск reorg/challenge

Збільшити K-confirmations/вікно спору, включити «delayed finalization» для великих сум, сповістити міст/операторів.

Інцидент: розбіжність валют/активів

Заморозити порушені пари, відкотити довідник, перерахувати USD-нормалізацію, опублікувати звіт.

Інцидент: стрибок Fraud/Dispute

Посилити ліміти/скоринг, включити ручною рев'ю high-risk, довчити модель на свіжому патерні.

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

Вікна фіналізації по мережах

yaml finality:
eth-mainnet: 12  # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }

Правила ідемпотентності та дедупу

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${event_type}"
ttl_hours: 48

SLO пайплайнів

yaml pipelines:
ingest_stream:
freshness_p95_min: 3 completeness_min_pct: 99. 7 gold_build:
correctness_min_pct: 99. 9 reorg_success_min_pct: 99. 9

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

1. Зафіксуйте джерела, схеми, вікна фіналізації та власників.
2. Увімкніть ідемпотентність і reorg-handling (states + replay).
3. Побудуйте ядро моделей (transfers/bridges/onchain_events/kyc/payouts).
4. Налаштуйте довідники активів і FX нормалізацію.
5. Визначте SLI/SLO пайплайнів і дашборди.
6. Реалізуйте entity resolution і privacy-by-design.
7. Увімкніть анти-фрод скоринги і регламент інцидентів.
8. Проведіть backfill і тести на історичних reorg/challenge кейсах.
9. Регулярно ревізуйте схеми, вага метрик і джерела.

19) Глосарій

Finality - незворотність стану/події.
Reorg - перезбірка ланцюга, що призводить до анулювання частини блоків.
Challenge period - вікно оскарження в optimistic-моделях.
Entity resolution - зіставлення адрес/акаунтів єдиної сутності.
GTV/TVL - обсяг транзакцій/заблокована вартість.
Completeness/Freshness/Correctness - базові метрики якості даних.

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