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

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

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, частка трафіку за версіями.
Ключі та ролі: 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. Збільшити К/вікно спору, 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, екосистема отримує перевіряються звіти і керовані ризики - від сирої події до управлінського рішення.