Слияние данных из разных цепей

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

1) Зачем нужно слияние

• Единый источник правды (canonical facts) при наличии разношерстных логов.
• Устойчивость к реоргам и задержкам: корректная финализация и перевычисления.
• Сопоставимость метрик между сетями и активами.
• Прозрачный lineage и контроль качества для аудита и регуляторов.

2) Источники и классы данных

1. Ончейн: блоки, транзакции, логи контрактов, заголовки, состояния.
2. Мосты/релееры: заявки, квитанции, доказательства, статусы финализации.
3. L2/DA слои: батчи, публикации, пруфы, окна оспаривания.
4. PSP/KYC/KYB/AML: платежные статусы, проверки, санкционные хиты.
5. Продуктовые события: онбординг, депозиты/выплаты, игровые и поведенческие события.
6. Справочники: сети, активы, decimals, chainId, адреса, версии SDK.

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

3) Архитектура пайплайна слияния

Ingest (агенты/индексеры/webhook) → Raw/Bronze (неизменяемое сырье) → Clean/Silver (нормализация и дедуп) → Merge/Core/Gold (канонические факты и связи) → Marts (финансы/продукт/риск/операционка) → Serve (OLAP/API/поиск).
Ключевые свойства: идемпотентность, версионирование схем, replay/backfill, late data handling.

4) Канонические схемы (упрощенно)

4.1 События (YAML)

yaml event:
id: uuid observed_at: timestamp # when saw event_at: timestamp # when happened (by source)
chain_id: string       # 'eth-mainnet'    'polygon'...
block_height: long tx_hash: string log_index: int type: string         # transfer    bridge. lock    bridge. mint...
status: string        # observed    confirmed    finalized    invalid src: string # address/peer-id/org _ id dst: string asset: string # canonical character (USDC)
amount: decimal usd_value: decimal # normalization at the rate on the meta observed_at: object # gas, fee, contract, sdk_version...
idempotency_key: string    # chainId    block    tx    logIndex    type proof_ref: string # proof/anchor reference

4.2 Переводы и мосты (SQL)

sql
CREATE TABLE bridge_transfers (
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
created_at TIMESTAMPTZ,
finalized_at TIMESTAMPTZ,
status TEXT,          -- requested    inflight    finalized    failed    reversed src_tx TEXT, dst_tx TEXT,
proof_ref TEXT, meta JSONB
);

4.3 Справочник активов/сетей (YAML)

yaml catalog:
assets:
- symbol: USDC decimals: { eth-mainnet: 6, polygon: 6 }
contracts: { eth-mainnet: "0xA0b8...", polygon: "0x2791..." }
networks:
- id: eth-mainnet k_confirmations: 12
- id: polygon k_confirmations: 256

5) Финализация, реорги и статусы

Состояния: `observed → confirmed(K) → finalized → invalidated(reorg)` (+ `challenged` для optimistic).

• K-подтверждений по сети/активу/риску.
• Delayed Finalization для крупных сумм.
• Reorg handling: автоматическая инвалидация и replay.
• Proof coverage: доля записей с пруфами/анкерами ≥ целевого SLO.

6) Нормализация времени и валют

Время: все timestampts в UTC, хранить `observed_at` и `event_at`.
FX/цены активов: пересчет `usd_value` по курсу на `observed_at` (или `event_at` — для отчетности, определено политикой).
Decimals/scale: строгая канонизация количеств для сопоставимости.
Часовые пояса в отчетах: резолвятся при отборе (витрина), не в core.

7) Идемпотентность и дедупликация

• `idempotency_key = chainId|block_height|tx_hash|log_index|type`

• Повторы из нескольких индексеров — upsert по idempotency_key.
• При конфликте payload — срабатывает policy of truth (приоритет источника/версия/время).
• Окно дедупа хранится ≥ 48–72 ч для «блуждающих» повторов.

8) Entity Resolution (сопоставление сущностей)

Адреса → акторы: кошелек/контракт → пользователь/организация/роль.
Связи кросс-цепи: hard-link (подпись/kyc), soft-link (поведение/граф).
Псевдонимизация: стабильный PID/ORG_ID; PII хранится у контроллера данных.

9) Правила слияния и приоритеты (Policy)

1. Источник истины по факту перевода — ончейн событие `finalized` + пруф.
2. Источник истины по агрегатам — core таблицы `transfers|bridge_transfers`, а не «сырье».
3. Конфликт времени (event_at vs observed_at) — по политике отчета (финансы — event_at; операционка — observed_at).
4. Конфликт сумм/активов — остановка мерджа и карантин до сверки каталога активов.
5. Мостовые связки — требуются квитанции обеих сторон (src/dst) + receipt pairing.

10) Псевдо-запросы и алгоритмы

10.1 Сведение событий в каноническую «операцию»

sql
WITH base AS (
SELECT e.,
CONCAT(e. chain_id,'    ',e. block_height,'    ',e. tx_hash,'    ',e. log_index,'    ',e. type) AS idem
FROM raw_events e
)
INSERT INTO core_events AS c (id, observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idempotency_key, proof_ref)
SELECT gen_random_uuid(), observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idem, proof_ref
FROM base
ON CONFLICT (idempotency_key) DO UPDATE
SET status = EXCLUDED. status,
usd_value = COALESCE(EXCLUDED. usd_value, core_events. usd_value),
proof_ref = COALESCE(EXCLUDED. proof_ref, core_events. proof_ref),
meta   = core_events. meta          EXCLUDED. meta;

10.2 Матчинг мостовых пар (источник↔цель)

sql
INSERT INTO bridge_transfers (id, src_chain, dst_chain, asset, amount, created_at, status, src_tx, proof_ref)
SELECT
CONCAT('br:', e. tx_hash) AS id,
e. chain_id, b. dst_chain, e. asset, e. amount, e. event_at, 'inflight', e. tx_hash, e. proof_ref
FROM core_events e
JOIN bridge_book b ON e. type='bridge. lock' AND e. asset=b. asset AND e. chain_id=b. src_chain
ON CONFLICT (id) DO NOTHING;

UPDATE bridge_transfers bt
SET finalized_at = e. event_at,
dst_tx    = e. tx_hash,
status    = 'finalized'
FROM core_events e
WHERE e. type='bridge. mint'
AND bt. status='inflight'
AND bt. asset=e. asset
AND bt. src_chain=bridge_book. src_chain
AND bt. dst_chain=bridge_book. dst_chain
AND abs(e. amount - bt. amount) < 1e-9;

10.3 Обработка реоргов

sql
UPDATE core_events
SET status='invalidated'
WHERE chain_id=$1 AND block_height BETWEEN $2 AND $3
AND status IN ('observed','confirmed','finalized');

-- Reassembly of aggregates (example)
CALL recompute_materialized_views($1, $2, $3);

11) Управление схемами и эволюцией

Версионирование: `schema_version` в шапке набора данных, миграции записываются в журнал.
Политика совместимости: `BACKWARD` для событий (только добавление полей).
Data Contracts с источниками: тесты контрактов в CI, линтеры схем.

12) Качество данных: SLI/SLO

• Freshness p95: лаг ingest→Gold (мин).
• Completeness %: доля записей, достигших `finalized` в пределах окна.
• Correctness %: валидные схемы/подписи/пруфы.
• Proof Coverage %: доля канонических записей с пруфами/анкерами.
• Dedup Efficiency: доля дублей, поглощенных идемпотентно.
• Reorg Handling Success %: корректно инвалидаций и replays.

SLO (ориентиры): Freshness ≤ 3 мин (стрим) / 15 мин (батч); Completeness ≥ 99.7%; Correctness ≥ 99.9%; Proof Coverage ≥ 99.0%; Reorg Success ≥ 99.9%; Merge MTTR (инцидент) ≤ 30 мин.

13) Дашборды (макеты)

Merge Ops (реал-тайм/час): Freshness, Queue lag, Dedup rate, Finalized %, Reorg spikes, Error-budget burn.
Proof & Finality: proof coverage, p95 finality per chain, challenge/reorg события.
Catalog Health: расхождения мэппингов активов, decimals, версий SDK.
Quality & Drift: completeness/correctness, schema drift, late data.
Finance Lens: GTV, Net Flow, TVL по цепям/мостам (только `finalized`).

14) Конфигурации (YAML)

Окна финализации

yaml finality:
eth-mainnet: { k: 12, delayed_for_usd_gt: 100000 }
polygon:   { k: 256 }
optimistic-L2:
k: 0 challenge_minutes: 20 delayed_for_usd_gt: 50000

Политика мерджа и приоритетов

yaml merge_policy:
source_priority: [onchain, bridge, psp, product]
conflict:
time: { prefer: "event_at" }
amount: { action: "quarantine" }
proof_required_for: ["bridge_transfers", "payouts"]
quarantine_topics: ["asset_mismatch", "decimals_mismatch", "time_skew_gt_5m"]

Идемпотентность/дедуп

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${type}"
ttl_hours: 72

15) Приватность и комплаенс

PII-минимизация: PID/ORG_ID, запрет PII в метриках/лейблах.
Data residency: сегрегация регионов (EU/ROW), шифрование «в покое/в пути».
Право на удаление: tombstone/redaction события с доказуемым применением.
Аудит: неизменяемые журналы, анкеринг хэшей, проверка доступа по ролям.

16) Операционные регламенты

Ежедневно: сверка proof coverage, финализация по цепям, реестр мостов и конфиг-дрейф.
Еженедельно: ревизия каталога активов/decimals, корректность FX-нормализации.
Ежемесячно: тесты reorg/replay, проверка SLO и стресс-тест производительности.
Change Management: timelock на изменения merge-политики, журнал решений.

17) Playbook инцидентов

A. Рассинхрон активов/decimals

Стоп на соответствующие активы, откат каталога, перерасчет витрин, отчет ≤ 24 ч.

B. Падение Proof Coverage

Перезапуск мерклизации/анкеринга, повышение уровня логирования, ручная выборка 100 кейсов, отчет.

C. Пики Reorg/Challenge

Увеличить `k`/окно спора, включить delayed finalization для крупных сумм, уведомить заинтересованных.

D. Взрыв дублей/повторов

Ужесточить дедуп TTL/ключ, ограничить «шумные» источники, включить карантин-контур.

E. Дрейф времени (time skew)

Синхронизация NTP/PTP, пересчет окон, временный сдвиг политики `prefer: observed_at`.

18) Чек-лист внедрения

1. Зафиксируйте источники, окна финализации и доказательства.
2. Внедрите каноническую схему событий и ключ идемпотентности.
3. Настройте дедуп и merge-политику с quarantine-контуром.
4. Поднимите реестр активов/сетей и FX-нормализацию.
5. Реализуйте replay/backfill и обработку late data.
6. Определите SLI/SLO и дашборды качества.
7. Запустите регулярный анкеринг и аудит-журналы.
8. Проведите пилот с симуляциями реоргов/мостовых задержек и зафиксируйте MTTR.

19) Глоссарий

Finality — необратимость состояния/события.
Reorg — пересборка цепи с аннуляцией части блоков.
Idempotency — устойчивость к повторной доставке.
Proof Coverage — доля записей с валидными доказательствами.
Entity Resolution — сопоставление адресов/аккаунтов единой сущности.
Delayed Finalization — отложенное принятие в агрегаты для высокорисковых сумм.
Quarantine — изолированный поток для конфликтных/подозрительных записей.

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