Kettenübergreifendes Audit

(Abschnitt: Ökosystem und Netzwerk)

1) Ziele und Bereich

• Bestätigen Sie die Richtigkeit und Vollständigkeit der Einträge unter Berücksichtigung von Finalisierungen und Wiederholungen.
• Sicherstellung der Nachweisbarkeit von Entscheidungen und Transaktionen (Krypto-Signaturen, Merkle-Proofs, ZK/Optimistic-Modelle).
• Geben Sie einen Pass-Through-Trail (Lineage) vom Bericht bis zum rohen Ereignis.
• Reduzieren Sie das Betriebs- und Regulierungsrisiko durch standardisierte Protokolle und Verfahren.

2) Wahrheitsquellen und Vertrauensmodell

On-Chain-Status und -Protokolle: Blöcke, Vertragsereignisse, Hashes von Nachrichtenpaketen.
Brücken und Relaiser: Anträge, Belege, Nachweise (light-client/optimistic/ZK).
PSP/KYC/AML: Prüfstatus, Zahlungsbelege, Sanktionshits.
Betriebssysteme: Configs, Ficheflags, SDK-Versionen, Limits, Schlüssel.
Governance/Lösungen: proposals, timelock, performances.

Vertrauensstufen: Kryptographisch verifizierbar → wirtschaftlich finalisierbar → operativ zertifiziert (durch Unterschrift und unveränderliches Protokoll).

3) Finalisierung, Rengs und Nachweisbarkeitsstatus

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

• K-Bestätigungen pro Kette/Asset/Risikoklasse.
• Challenge-Fenster für optimistische Brücken.
• Verzögerte Finalisierung für große Beträge/kritische Aktionen.
• Reorg-Handhabung: automatische Behinderung/Re-Replikation mit Verweis auf einen alten Hash.

4) Unveränderliche Protokolle und Hashketten

Audit-Log (nur Append): Eintrag = (Zeit, Quelle, Payload-Hash, Signaturen).

5) Ende-zu-Ende-Datenlineage

• Column-Level-Lineage: von der Vitrine/Reportage über Transformationen bis hin zum rohen Event.

6) Überwachung von Brücken- und Domänenkonfigurationen

Kettenbrücken/Dampfregister: chainId, Beweisart, K-Bestätigungen/Streitfenster, Vertragsadressen, Decimals/Asset-Map.
SDK/Agentversionen: minimal unterstützt, LTS, Anteil des Datenverkehrs nach Version.
Die Schlüssel und die Rollen: org_id → peer_id → capability, die Fristen und die Rotation.
ACL/Limits: Rate-Limits, Tagesvolumen, Whitelist von Assets/Methoden.

7) Beweismodell (Proof Stack)

Log-Proofs: Quellensignaturen + Hash-Ketten/Anker.
State-proofs: light-client/header check + merkle branches.
Execution-proofs: ZK-Nachweis der Korrektheit der Berechnung (bei Verfügbarkeit).
Optimistische-Proofs: richtig, noch nicht bestritten (Challenge-Periode, Steak, Schiedsrichter).
Empfang-Paarung: Bündel von Senden und Ausführen (Proof-of-Delivery/-Ausführung).

8) SLI/SLO des Zwischenkettenaudits

• Frische p95 (min) von 'observed _ at' bis zum Treffer in Gold.
• Completeness (%) vs. erwartete K-Fenster.
• Korrektheit (%) (Validierung von Schemata, Signaturen, Proofs).
• Proof-Coverage (%) - Anteil der Einträge mit Kryptobeweis.
• Reorg Handling Success (%).
• Config Drift Detection MTTA (мин).

SLO: Freshness ≤ 15 min (Batch )/ ≤ 3 min (Stream), Completeness ≥ 99. 7%, Correctness ≥ 99. 9%, Proof-Coverage ≥ 99. 0%, Reorg Success ≥ 99. 9%, MTTA drift ≤ 5 min.

9) Datenschemata (Pseudo-SQL)

Ereignis-/Übersetzungsregister

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

Beweise

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

Unveränderliches Audit-Protokoll

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

Brücken-/Konfigenregister

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) Kontrolle der Berichtsintegrität (Pseudo-Anfragen)

So ordnen Sie einen Bericht Proofs zu

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;

Erkennung von Konfigurationsdrift

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

reorg-Analyse

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) Konfigurationen (Pseudo-YAML)

Finalisierungsfenster und Proof-Modi

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 }

Audit-Qualitätsparameter

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

Ankerpolitik

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

12) Beobachtbarkeit und Dashboards

Audit Ops (реал-тайм/час): Freshness, Completeness, Proof-Coverage, Reorg/Challenge, Drift-alerts, Error-budget burn.
Bridges Compliance: Übereinstimmung der tatsächlichen Config mit dem Register, SLA Finalisierung, Anteil der Anomalien.
Data Lineage: interaktiver Wegbericht → Schaufenster → Transformation → Rohstoff → Proof/Anker.
Key & Access Hygiene: abgelaufene Schlüssel, verdächtige Signaturen, Rotationsfrequenz.

13) Prozesse und Rollen

Dateneigentümer (Data Owner) - Korrektheit von Diagrammen und Schaufenstern.
Auditor (Internal/External) - Überprüfung von Prüfungen, Stichproben, Einhaltung der Richtlinien.
Bridge/Relay Operator - Aufrechterhaltung der Beweise und Finalisierung.
Security/Compliance - Sanktionen, Vorfälle, Reviews von Schlüsseln und Zugriffen.
Governance - Genehmigung von Änderungen an Config/Limits, Veröffentlichung von Berichten.

14) Playbook der Vorfälle

A. Config-Drift (Nichtübereinstimmung von Register und Tatsache)

1. Betroffene Paare einfrieren, 2) config auf die zuletzt signierte Version zurücksetzen, 3) Berichte neu berechnen, 4) öffentliche Notiz.

B. Reorg/Challenge Splash

1. Vergrößern K/Streitfenster, 2) delayed finalization für große Summen aktivieren, 3) Teilnehmer warnen, 4) Retro-Analyse.

C. Unzureichende Proof-Coverage

1. Neustart der Verankerung/Merkalisierung, 2) Anhebung des Logging-Levels, 3) Sampling von 100 manuellen Inspektionsfällen, 4) Bericht in 24 Stunden.

D. Kompromittierung des Quellschlüssels

1. Sofortige Revoke, 2) Überzeichnung kritischer Schlachten, 3) Aktualisierung der vertrauenswürdigen Listen, 4) Einflussanalyse und Post-Mortem.

E. Uneinheitlichkeit des Vermögensverzeichnisses

1. Stoppen Sie Berichte mit affektierten Assets, 2) Katalog-Rollback, 3) Neuberechnung der USD-Normalisierung, 4) Veröffentlichung des korrigierten Berichts.

15) Inspektionen und Stichproben für externe Audits

Sampling-Plan: geschichtete Stichprobe nach Ketten/Brücken/Summenklassen.
Reperformance-Tests: unabhängige Rekonstruktion von Metriken aus Rohstoffen.
Walk-through: Vom Bericht zum Rohstoff (und zurück) mit Proof-Verifizierung.
Key-Control-Tests: Rotationen, widerrufene Schlüssel, Einschränkungen der Rechte.
Change-Management: Übereinstimmung der Releases mit der Timelock-/Deprecate-Richtlinie.

16) Checkliste Umsetzung

1. Identifizieren Sie die Quellen der Wahrheit und das Finalisierungsfenster nach Domäne.
2. Fügen Sie unveränderliche Protokolle, Hash-Ketten und regelmäßiges Ankern hinzu.
3. Standardisieren Sie Schemata, Idempotency-Schlüssel und Lineage auf Spalten.
4. Heben Sie das Bridge/Config-Register mit Signaturen und Audit-Log an.
5. Konfigurieren Sie SLI/SLO und Audit Dashboards; Aktivieren Sie drift-alerts.
6. Automatisieren Sie reorg/challenge-processing und delayed finalization.
7. Führen Sie einen externen Auditpiloten durch: Sampling, Walk-Through, Reperformance.
8. Setzen Sie ein regelmäßiges Post-Mortem über Vorfälle und aktualisieren Sie die Richtlinie.

17) Glossar

Finalität - Irreversibilität des Zustands/Ereignisses.
Reorg ist eine Kettenreparatur, die einen Teil der Blöcke aufhebt.
Anchoring - Protokollierung von Hashes in einem öffentlichen Netzwerk.
Merkle tree ist ein Framework zur nachweisbaren Aggregation vieler Datensätze.
Light-client proof - Überprüfen Sie den Status eines anderen Netzwerks durch Header/Merkle-Zweige.
Der ZK-Nachweis ist ein kurzer Beweis für die Richtigkeit der Berechnung/des Zustands.
Optimistischer Nachweis - Annahme mit Anfechtungsmöglichkeit im Fenster 'Herausforderung'.
Lineage - Lückenlose Rückverfolgbarkeit der Datenherkunft.
Proof-Coverage - Anteil der Datensätze mit validen Nachweisen.

Fazit: Das Inter-Chain-Audit ist die Disziplin der Nachweisbarkeit. Durch die Kombination von Finalisierung und Reorg-Verarbeitung, unveränderlichen Protokollen mit Anker, einheitlichen Schemata und Config-Registern sowie klaren SLOs und Playbooks erhält das Ökosystem überprüfbare Berichte und überschaubare Risiken - von der Rohveranstaltung bis zur Managemententscheidung.