GH GambleHub

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

(Раздел: Экосистема и Сеть)

1) Что такое межцепная аналитика и зачем она нужна

Межцепная аналитика (cross-chain analytics) — это методология и стэк, объединяющие телеметрию и события из множества цепей, мостов, провайдеров и приложений в единую модель данных. Цели:
  • Единый учет ценности и активности: объемы, ликвидность, комиссии, ретеншн.
  • Наблюдаемость мостов и P2P-связей: финализация, лаги, reorg/challenge события.
  • Атрибуция трафика и конверсий: чейн→чейн, канал→продукт.
  • Риск и комплаенс: AML, санкции, поведенческий фрод, идентификация сущностей.
  • Принятие решений: OKR/бюджеты, лимиты, регламенты обновлений и ликвидности.

2) Источники данных и события (канонический список)

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

💡 Для каждого источника фиксируйте: схему, лаг обновления, «окно финализации», владельца, SLO.

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 для сложных путей «сеть→мост→продукт».

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

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

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

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

13) SLI/SLO для аналитических пайплайнов

SLI (пример):
  • Freshness (медиана лага от `observed_at` до появления в Gold),
  • Completeness (% событий без дыр по ожиданиям K-confirmations),
  • Correctness (% событий, прошедших валидации схем/правил),
  • Reorg handling success (% корректно инвалидаций/переигрываний),
  • Serve latency (p95 запросов к витринам/дашбордам).
SLO (ориентиры):
  • 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) Дашборды (шаблоны)

A. Cross-Chain Ops (реал-тайм/час):
  • Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.
B. Liquidity & Cost (день/неделя):
  • TVL, Net Flow per chain, cost-per-transfer, utilization, страховой фонд.
C. Product & Growth (неделя/месяц):
  • MAU/DAU (dedup), cross-chain retention, канальные воронки, QoT.
D. Risk & Compliance (неделя):
  • 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 — базовые метрики качества данных.

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

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.