Межцепной аудит

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

1) Цели и область

• Подтвердить корректность и полноту записей с учетом финализации и реоргов.
• Обеспечить доказуемость решений и транзакций (криптоподписи, меркль-доказательства, ZK/optimistic-модели).
• Дать сквозной след (lineage) от отчета до сырого события.
• Снизить операционный и регуляторный риск через стандартизованные журналы и процедуры.

2) Источники истины и модель доверия

On-chain состояния и логи: блоки, события контрактов, хэши пакетов сообщений.
Мосты и релееры: заявки, квитанции, доказательства (light-client/optimistic/ZK).
PSP/KYC/AML: статусы проверок, платежные квитанции, санкционные хиты.
Операционные системы: конфиги, фичефлаги, версии SDK, лимиты, ключи.
Говернанс/решения: proposals, timelock, исполнения.

Уровни доверия: криптографически проверяемые → экономически финализируемые → операционно заверенные (подписью и неизменяемым логом).

3) Финализация, реорги и статусы доказуемости

• `observed → confirmed(K) → finalized → challenged (optimistic) → invalidated(reorg)`

• K-confirmations на цепь/актив/класс риска.
• Challenge-окно для optimistic-мостов.
• Delayed Finalization для крупных сумм/критичных действий.
• Reorg handling: автоматическое инвалидация/пере-реплей с ссылкой на старый хэш.

4) Неизменяемые журналы и цепочки хэшей

Аудит-журнал (append-only): запись = (время, источник, payload-хэш, подписи).

5) Сквозной lineage данных

• Column-level lineage: от витрины/отчета до трансформаций и сырого события.

6) Контроль конфигураций мостов и доменов

Реестр мостов/паров цепей: chainId, тип доказательства, K-confirmations/окно спора, адреса контрактов, decimals/asset-map.
Версии SDK/агентов: минимально поддерживаемые, LTS, доля трафика по версиям.
Ключи и роли: org_id → peer_id → capability, сроки и ротация.
ACL/лимиты: rate-limits, дневные объемы, whitelist активов/методов.

7) Модель доказательств (Proof Stack)

Log-proofs: подписи источников + хэш-цепи/анкеры.
State-proofs: light-client/проверка заголовков + меркль-ветви.
Execution-proofs: ZK-доказательства корректности вычисления (при доступноси).
Optimistic-proofs: верно, пока не оспорено (challenge-период, стейк, арбитры).
Receipt-pairing: связка отправки и исполнения (proof-of-delivery/-execution).

8) SLI/SLO межцепного аудита

• Freshness p95 (мин) от `observed_at` до попадания в Gold.
• Completeness (%) vs ожидаемые по K-окнам.
• Correctness (%) (валидации схем, подписи, пруфы).
• Proof-Coverage (%) — доля записей с криптодоказательствами.
• Reorg Handling Success (%).
• Config Drift Detection MTTA (мин).

SLO (ориентиры): Freshness ≤ 15 мин (батч)/≤ 3 мин (стрим), Completeness ≥ 99.7%, Correctness ≥ 99.9%, Proof-Coverage ≥ 99.0%, Reorg Success ≥ 99.9%, MTTA drift ≤ 5 мин.

9) Схемы данных (псевдо-SQL)

Регистр событий/переводов

sql
CREATE TABLE xchain_events (
id TEXT PRIMARY KEY,
observed_at TIMESTAMPTZ,
status TEXT,         -- observed    confirmed    finalized    challenged    invalidated chain_id TEXT, block_height BIGINT, tx_hash TEXT, log_index INT,
type TEXT,          -- bridge.lock    bridge.mint    transfer    kyc.pass...
actor_src TEXT, actor_dst TEXT,
asset TEXT, amount NUMERIC, usd_value NUMERIC,
bridge_ref TEXT, idempotency_key TEXT,
proof_ref TEXT
);

Доказательства

sql
CREATE TABLE proofs (
id TEXT PRIMARY KEY,
kind TEXT,          -- log    state    zk    optimistic root_hash TEXT, leaf_hash TEXT, proof JSONB,
anchored_chain TEXT, anchor_tx TEXT,
created_at TIMESTAMPTZ
);

Неизменяемый аудит-журнал

sql
CREATE TABLE audit_log (
seq BIGSERIAL PRIMARY KEY,
ts TIMESTAMPTZ,
source TEXT, record_hash TEXT, prev_hash TEXT,
sig_org TEXT, sig_payload TEXT
);

Реестр мостов/конфигов

sql
CREATE TABLE bridge_registry (
pair_id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
proof_mode TEXT, confirmations INT, challenge_minutes INT,
contracts JSONB, assets_map JSONB, sdk_min TEXT, lts TEXT,
updated_at TIMESTAMPTZ, updated_by TEXT
);

10) Контроль целостности отчетов (псевдо-запросы)

Сопоставление отчета с пруфами

sql
SELECT r.report_id, COUNT() AS rows,
100.0 SUM(CASE WHEN e.proof_ref IS NOT NULL THEN 1 ELSE 0 END) / COUNT() AS proof_coverage_pct
FROM report_rows r
JOIN xchain_events e ON r.event_id = e.id
GROUP BY r.report_id;

Выявление дрейфа конфигураций

sql
SELECT pair_id, COUNT() AS changes_24h
FROM config_audit
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY pair_id
HAVING COUNT() > 0;

Реорг-анализ

sql
SELECT chain_id, date_trunc('hour', observed_at) AS h,
SUM(CASE WHEN status='invalidated' THEN 1 ELSE 0 END) AS reorg_cnt
FROM xchain_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY chain_id, h;

11) Конфигурации (псевдо-YAML)

Окна финализации и пруф-режимы

yaml finality:
eth-mainnet: { k: 12, proof: light_client }
polygon:   { k: 256, proof: light_client }
solana:   { k: "optimistic:32 slots", proof: optimistic, challenge_minutes: 20 }
zk-bridge:  { proof: zk, sla_proof_sec: 180 }

Аудит-параметры качества

yaml audit:
freshness_p95_min: 3 completeness_min_pct: 99.7 correctness_min_pct: 99.9 proof_coverage_min_pct: 99.0 drift_mtta_min: 5

Политика анкеринга

yaml anchoring:
cadence: "15m"
chains: ["eth-mainnet"]
anchor_contract: "0xANCh..."

12) Наблюдаемость и дашборды

Audit Ops (реал-тайм/час): Freshness, Completeness, Proof-Coverage, Reorg/Challenge, Drift-alerts, Error-budget burn.
Bridges Compliance: соответствие фактических конфигов реестру, SLA финализации, доля аномалий.
Data Lineage: интерактивный путь отчет → витрина → трансформация → сырье → пруф/якорь.
Key & Access Hygiene: просроченные ключи, подозрительные подписи, частота ротаций.

13) Процессы и роли

Владелец данных (Data Owner) — корректность схем и витрин.
Аудитор (Internal/External) — проверка пруфов, выборки, соответствия политике.
Оператор мостов/релеев — поддержание доказательств и финализации.
Секьюрити/Комплаенс — санкции, инциденты, ревью ключей и доступов.
Governance — утверждение изменений конфигов/лимитов, публикация отчетов.

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

A. Конфиг-дрейф (несовпадение реестра и факта)

1. Заморозить затронутые пары, 2) откатить конфиг к последней подписанной версии, 3) пересчитать отчеты, 4) публичная заметка.

B. Reorg/Challenge всплеск

1. Увеличить K/окно спора, 2) включить delayed finalization для крупных сумм, 3) предупредить участников, 4) ретро-анализ.

C. Недостаточная Proof-Coverage

1. Перезапуск анкеринга/мерклизации, 2) поднять уровень логирования, 3) выборка 100 кейсов ручной проверки, 4) отчет за 24 ч.

D. Компрометация ключа источника

1. Немедленный revoke, 2) переподписание критичных батчей, 3) обновление доверенных списков, 4) анализ влияния и пост-мортем.

E. Несогласованность справочника активов

1. Стоп на отчеты с аффектированными активами, 2) откат каталога, 3) перерасчет USD-нормализации, 4) публикация исправленного отчета.

15) Проверки и выборки для внешнего аудита

Sampling-план: стратифицированная выборка по цепям/мостам/классам суммы.
Reperformance-тесты: независимая реконструкция метрик из сырья.
Walk-through: от отчета к сырью (и обратно) с пруф-верификацией.
Key-control тесты: ротации, отозванные ключи, ограничения прав.
Change-management: соответствие релизов политике timelock/депрекейта.

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

1. Определите источники истины и окно финализации по доменам.
2. Включите неизменяемые журналы, хэш-цепи и регулярный анкеринг.
3. Стандартизируйте схемы, idempotency-ключи и lineage до колонок.
4. Поднимите реестр мостов/конфигов с подписями и аудит-логом.
5. Настройте SLI/SLO и дашборды аудита; включите drift-алерты.
6. Автоматизируйте reorg/challenge-обработку и delayed finalization.
7. Проведите пилот внешнего аудита: sampling, walk-through, reperformance.
8. Поставьте регулярный пост-мортем по инцидентам и обновляйте политику.

17) Глоссарий

Finality — необратимость состояния/события.
Reorg — пересборка цепи, отменяющая часть блоков.
Anchoring — фиксация хэшей журналов в публичной сети.
Merkle tree — структура для доказуемой агрегирования множества записей.
Light-client proof — проверка состояния другой сети по заголовкам/меркль-ветвям.
ZK-proof — краткое доказательство корректности вычисления/состояния.
Optimistic proof — принятие с возможностью оспаривания в окне `challenge`.
Lineage — сквозная прослеживаемость происхождения данных.
Proof-Coverage — доля записей с валидными доказательствами.

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