Audyt międzysystemowy

(Sekcja: Ekosystem i sieć)

1) Cele i zakres

• Potwierdź poprawność i kompletność zapisów, biorąc pod uwagę finalizację i reorgie.
• Zapewnienie sprawdzalności decyzji i transakcji (podpisy kryptograficzne, dowody handlowe, modele ZK/optymistyczne).
• Daj rodowód od raportu do surowego wydarzenia.
• Ograniczenie ryzyka operacyjnego i regulacyjnego dzięki znormalizowanym dziennikom i procedurom.

2) Źródła prawdy i model zaufania

Stany i dzienniki łańcuchowe: bloki, zdarzenia umowne, hashes pakietów wiadomości.
Mosty i przyczepy: aplikacje, paragony, dowody (światło-klient/optymistyczny/ZK).
PSP/KYC/AML: statusy kontroli, wpływy z płatności, trafienia sankcji.
Systemy operacyjne: konfiguracje, flagi funkcji, wersje SDK, limity, klawisze.
Rządy/rozwiązania: propozycje, harmonogram, wykonanie.

Poziomy zaufania: kryptograficznie zweryfikowane → ekonomicznie sfinalizowane → certyfikowane operacyjnie (według podpisu i niezmiennego dziennika).

3) Finalizacja, reorgia i statusy sprawdzalności

• „observed → potwierdzone (K) → sfinalizowane → challenged (optymistic) → unieważnione (reorg)”

• K-potwierdzenia na łańcuch/aktywa/klasa ryzyka.
• Wyzwanie okno dla optymistycznych mostów.
• Opóźnione zakończenie dla dużych kwot/działań krytycznych.
• Obsługa Reorg: automatyczna niepełnosprawność/ponowne powtórzenie w odniesieniu do starego hasha.

4) Niezmienne dzienniki i łańcuchy hash

Dziennik audytu (tylko dodatek): record = (czas, źródło, ładunek-hash, podpisy).

5) Dane rodowe typu end-to-end

• Rodowód na poziomie kolumn: od prezentacji/raportu po transformacje i surowe zdarzenie.

6) Kontrola konfiguracji mostu i domeny

Rejestr mostów/łańcuchów pary: Id, rodzaj dowodu, K-potwierdzenia/okno sporu, adresy umów, przecinki/asset-map.
Wersje SDK/agenta: minimalnie obsługiwane, LTS, udział ruchu według wersji.
Klucze i role: org_id → peer_id → możliwości, terminy i obrót.
ACL/limity: limity stawek, dzienne wolumeny, aktywa/metody białej listy.

7) Stos dowodowy

Dowody dziennika: podpisy źródłowe + łańcuchy/kotwice hash.
State-proofs: light-client/checking headers + merkle-branches.
Dowody wykonania: Dowody poprawności obliczeń ZK (jeśli są dostępne).
Optymistyczne dowody: prawdziwe aż do zakwestionowania (okres wyzwania, stek, umpires).
Parowanie odbioru: dowód dostawy/-ekspekcja.

8) SLI/SLO audytu międzysieciowego

• Świeżość p95 (min) od 'observed _ at' do 'Gold'.
• Kompletność (%) vs oczekiwane przez okna K.
• Poprawność (%) (zatwierdzanie systemu, podpisy, dowody).
• Proof-Coverage (%) - udział rekordów z dowodami kryptograficznymi.
• Reorg Handling Success (%).
• Config Drift Detection MTTA (мий).

SLO: świeżość ≤ 15 min (partia )/≤ 3 min (strumień), kompletność ≥ 99. 7%, prawidłowość ≥ 99. 9%, zasięg dowodu ≥ 99. 0%, Reorg Success ≥ 99. 9%, dryf MTTA ≤ 5 min.

9) Schematy danych (pseudo-SQL)

Rejestr wydarzeń/tłumaczeń

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
);

Dowody

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
);

Niezmodyfikowalny dziennik audytu

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
);

Rejestr mostu/Konfig

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) Kontrola integralności raportów (wnioski o pseudo)

Porównaj raport do Profs

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;

Wykrywanie dryfu konfiguracyjnego

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

Analiza Reorg

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) Konfiguracje (pseudo-YAML)

Wykończenie okien i tryby odporności

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 }

Parametry audytu jakości

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

Polityka kotwiczenia

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

12) Obserwowalność i deski rozdzielcze

Audyt Ops (реаα-таса/сАВ): Świeżość, Kompletność, Dowód-Coverage, Reorg/Challenge, Drift-alerts, Error-budget burn.
Zgodność mostów: zgodność rzeczywistych konfiguracji z rejestrem, finalizacja SLA, odsetek anomalii.
Dane Lineage: interaktywny raport ścieżki → prezentacja → transformacja → surowiec → dowód/kotwica.
Klucz i dostęp Higiena: wygasły klucze, podejrzane podpisy, częstotliwość rotacji.

13) Procesy i role

Właściciel danych-schematy i sklepy są poprawne.
Audytor (wewnętrzny/zewnętrzny) - dowody kontroli, pobieranie próbek, zgodność z polityką.
Operator mostu/przekaźnika - Konserwacja i finalizacja dowodów.
Bezpieczeństwo/zgodność - sankcje, incydenty, przeglądy kluczowych i dostępu.
Zarządzanie - zatwierdzenie zmian konfiguracji/limitów, publikacja raportów.

14) Incydenty Playbook

A. Drift Config (niedopasowanie rejestrów i faktów)

1. Zamrozić dotknięte pary, 2) wycofać konfigurację do ostatniej podpisanej wersji, 3) przeliczyć raporty, 4) notatkę publiczną.

B. Reorg/Wyzwanie

1. Powiększyć okno K/sporu, 2) włączyć opóźnione zakończenie dla dużych kwot, 3) ostrzec uczestników, 4) analiza retro.

C. Niewystarczający zakres dowodowy

1. Ponowne uruchomienie kotwiczenia/rtęci, 2) podniesienie poziomu pozyskiwania drewna, 3) próbka 100 przypadków ręcznych, 4) zgłoszenie przez 24 godziny.

D. Kompromis dotyczący klucza źródłowego

1. Natychmiastowe odwołanie, 2) ponowne oznakowanie partii krytycznych, 3) aktualizacja zaufanych list, 4) analiza skutków i pośmiertna.

E. Niespójność przewodnika dotyczącego aktywów

1. Zatrzymaj się na raportach z aktywami dotkniętymi, 2) rollback katalogu, 3) ponowne obliczenie normalizacji USD, 4) publikacja skorygowanego raportu.

15) Kontrole i wybory do audytu zewnętrznego

Plan pobierania próbek: stratyfikowane pobieranie próbek według obwodów/mostów/klas sumy.
Testy reperformancji: niezależna rekonstrukcja metryk z surowców.
Przejście przez: od raportu do surowca (i z powrotem) z weryfikacją dowodów.
Testy kontroli kluczy: obroty, odwołane klucze, ograniczenia praw.
Zarządzanie zmianą: zgodność zwolnień z polityką timelock/deprecate.

16) Lista kontrolna wdrażania

1. Identyfikacja źródeł prawdy i okna finalizacji według domeny.
2. Włącz niezmienne dzienniki, łańcuchy hash i regularne kotwiczenie.
3. Standaryzuj schematy, klucze idempotencji i lineage do kolumn.
4. Podnieś rejestr mostów/konfiguracji z podpisami i dziennikiem audytu.
5. Konfigurowanie desek rozdzielczych SLI/SLO i audytu; zawierać wpisy dryfujące.
6. Automatyczne przetwarzanie reorg/challenge i opóźnione zakończenie.
7. Przeprowadzenie pilota audytu zewnętrznego: pobieranie próbek, przechodzenie, powtarzalność.
8. Postawić regularne pośmiertne zdarzenia i zaktualizować politykę.

17) Słownik

Finalność - nieodwracalność stanu/zdarzenia.
Reorg - ponowna instalacja łańcucha, anulowanie części bloków.
Kotwiczenie - mocowanie haseł dziennika w sieci publicznej.
Drzewo Merkle - struktura do sprawdzalnej agregacji wielu rekordów.
Dowód klienta światła - sprawdza stan innej sieci za pomocą nagłówków/gałęzi merkle.
ZK-proof - krótki dowód poprawności obliczeń/stanu.
Optymistyczny dowód - akceptacja z możliwością wyzwania w oknie „wyzwanie”.
Rodowód - identyfikowalność pochodzenia danych od końca do końca.
Proof-Coverage - odsetek zapisów z ważnymi dowodami.

Podsumowanie: Audyt łańcuchowy jest dyscypliną provability. Łącząc proces finalizacji i przerobu, niezmienne dzienniki z kotwiczeniem, ujednoliconymi systemami i rejestrami konfiguracyjnymi, jak również wyraźne SLO i playbooks, ekosystem otrzymuje weryfikowalne raporty i możliwe do zarządzania ryzyko - od zdarzenia surowego do decyzji zarządczej.