Inter-Chain Analytics
(Abschnitt: Ökosystem und Netzwerk)
1) Was ist Inter-Chain Analytics und warum wird es benötigt?
Cross-Chain Analytics ist eine Methodik und ein Stack, der Telemetrie und Ereignisse aus einer Vielzahl von Schaltkreisen, Brücken, Anbietern und Anwendungen in einem einzigen Datenmodell vereint. Die Ziele sind:- Einheitliche Erfassung von Wert und Aktivität: Volumen, Liquidität, Provisionen, Retention.
- Beobachtbarkeit von Brücken und P2P-Verbindungen: Finalisierung, Lags, Reorg/Challenge-Events.
- Attribution von Traffic und Conversions: cheyn→cheyn, kanal→produkt.
- Risiko und Compliance: AML, Sanktionen, Verhaltensmissbrauch, Identifizierung von Entitäten.
- Entscheidungsfindung: OKR/Budgets, Limits, Aktualisierungs- und Liquiditätsvorschriften.
2) Datenquellen und Ereignisse (kanonische Liste)
1. Ketten/Register: Blöcke, Transaktionen, Ereignisprotokolle, Smart Contract Status.
2. Brücken: Anträge, Belege, Nachweise (light/optimistic/ZK), Abschlussstände.
3. Zahlungsanbieter/KUS: bestandene Prüfungen, Limits, Auszahlungsstatus.
4. Produktevents: Onboarding, Einzahlungen/Wetten/Schlussfolgerungen, Spiel- und Verhaltensmetriken.
5. P2P-Transport: Pub/Sub-Quittungen, RPC-Erfolg, Latenz.
6. Verzeichnisse: Netzwerke, Assets, Decimals, chainId, Vertragsadressen, SDK-Versionen.
3) Datenarchitektur (Streams und Speicher)
Ingest (Streaming): Konnektoren zu Knoten/Indexern, Brücken-Webhooks, CDC aus operativen DBs.
Rohschichten (Bronze/Raw): Unveränderliche Partitionen mit dem Label 'observed _ at' und den Metadaten der Quelle.
Bereinigung/Normalisierung (Silber): Dedup, semantische Anreicherung, Timezon-Ausrichtung, Asset-Mapping.
Kernel-Modelle (Gold/Core): einheitliche Fakten 'transfers', 'bridges', 'onchain _ events', 'kyc _ status', 'payouts'.
Schaufenster (Marts): Finanzen (GTV/TVL/Take Rate), Produkt (Retention/Trichter), Risiko (Scoring), Operational (SLO).
Cache/Serve: OLAP/HTAP für Dashboards und APIs und separate Suche nach Adressen/tx.
Transport: Kafka/Pulsar (exactly-once semantics over idempotence), Objektspeicher für Rohstoffe, Parkett-/Säulenformate für Analysen.
4) Finalisierung, Rengs und Idempotenz
Status der Ereignisse: 'observed' → 'confirmed (k)' → 'finalized' → 'invalidated (reorg)'.
Bestätigungsregel (K-Bestätigungen): Konfiguriert nach Netzwerk/Asset-Typ.
Optimistic/Challenge-Fenster: Unterstützung des „umkämpften“ Status für Brücken.
Idempotenz: 'idempotency _ key = chainId' block 'tx' logIndex' topic'(oder Nutzlast-Hash).
Re-Playing (replay): Geplanter Backfill und Recovery bei Indexwechsel.
5) Modell der Identitäten und Entitäten (Entitätsauflösung)
Adresse → Akteur: Adressen, Schlüssel, Wallets ↔ Konto/Organisation/Anbieter.
Cross-Chain-Graph: Adressverknüpfungen durch einen Eigentümer (Heuristiken, Signaturen, Onboarding-Daten).
Vertrauensstufen: Hard-Link (KYC, On-Chain-Signatur), Soft-Link (Verhaltenskorrelationen).
Pseudonymisierung: Speichern Sie stabile IDs (PIDs) anstelle von PIIs in der Analytik.
6) Einheitliches Ereignisschema (vereinfacht)
yaml event:
id: string # global UUID observed_at: timestamp # when they saw chain_id: string # 'eth-mainnet', 'solana-mainnet',...
block_height: long tx_hash: string log_index: int event_type: string # transfer bridge. lock bridge. mint kyc. pass payout. done...
status: string # observed confirmed finalized invalid actor_src: string # address/peer-id/source organization actor_dst: string # address/peer-id/destination organization asset: string # canonical symbol (e. g., USDC), + decimals amount: decimal usd_value: decimal # rate normalization at the observed_at bridge_ref: string # link with the application/receipt of the metadata bridge: object # network/contract/version/gac/fee, etc.
idempotency_key: string
7) Normalisierung von Vermögenswerten und Preisen
Canonical Asset Directory: Symbol, Decimals, Chain Mapping, Vertragsadressen.
FX-Normalisierung: historische Kurse und Vermögenspreise nach Zeitstempel 'observed _ at'.
Multi-aktive Bundles: Gruppieren Sie „Wrapped“ und native Assets.
8) Schlüsselmetriken und Schaufenster
8. 1 Finanzen und Liquidität
GTV (Gross Transaction Volume) über Netzwerke/Assets/Brücken.
TVL und Net Flow über Brücken und Pools.
Take Rate/Provision pro Volumen; Cost-to-Serve zum Transfer.
Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.
8. 2 Produkt und Benutzer
Cross-chain MAU/DAU (dedup по PID),
Retention D1/D7/D30 unter Berücksichtigung der Multi-Chain-Aktivität,
Funnel: Eingangsnetzwerk → Brücke → Zielprodukt → Aktion.
QoT (Traffic Quality): Traffic Valide nach Anti-Betrug.
8. 3 Risiko und Compliance
Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.
Anomalierate nach Übersetzungsmustern, Velocity-Check, Clustering.
KYB/KYC Pass% und Timings.
8. 4 Betrieb und SLO
Bridge Success-Rate, p95 Finality, Relay Availability,
Reorg/Challenge events, Error budget burn.
9) Beispiele für SQL/Pseudo-Abfragen
GTV nach Kettenpaaren
sql
SELECT src. chain_id AS src_chain,
dst. chain_id AS dst_chain,
date_trunc('day', e. observed_at) AS d,
SUM(e. usd_value) AS gtv_usd
FROM events e
JOIN bridges b ON e. bridge_ref = b. id
JOIN networks src ON b. src_chain_id = src. id
JOIN networks dst ON b. dst_chain_id = dst. id
WHERE e. status = 'finalized' AND e. event_type IN ('bridge. lock','bridge. mint','transfer')
GROUP BY 1,2,3;
Cross-chain retention D7
sql
WITH first_touch AS (
SELECT pid, MIN(observed_at) AS t0
FROM product_events
WHERE event IN ('signup','first_deposit')
GROUP BY pid
),
week_activity AS (
SELECT DISTINCT pid
FROM product_events pe
JOIN first_touch ft USING(pid)
WHERE pe. observed_at BETWEEN ft.t0 + INTERVAL '1 day'
AND ft.t0 + INTERVAL '7 day'
)
SELECT 100. 0 COUNT() / (SELECT COUNT() FROM first_touch) AS d7_retention_pct
FROM week_activity;
Schaufenster für SLO-Brücke
sql
SELECT date_trunc('hour', observed_at) AS h,
100. 0 SUM(CASE WHEN status='finalized' THEN 1 END)/COUNT() AS success_rate,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY (finalized_at - observed_at)) AS p95_finality_min,
SUM(CASE WHEN challenge_event THEN 1 END) AS challenges
FROM bridge_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY 1;
10) Attribution und Multi-Channel-Pfad
Last-Touch/Position-basiertes Modell mit Gewichten für Netzwerkquelle, Brücke und Produkt.
UTM→On -chain: Verknüpfen Sie Klicks/Empfehlungen mit der Onchain-Adresse beim Onboarding (mit Zustimmung).
Assoziative Modelle: Shapley/Markov für komplexe „set→most→produkt“ -Pfade.
11) Anti-Betrug und Verhaltenssignale
Graphische Merkmale: gemeinsame Kontrahenten, zirkuläre Transfers, schneller Umsatz.
Velocity-Grenzen und Anomalien: Ausbrüche, „Fragmentierung“ von Summen, nächtliche Cluster.
Betrugsmuster auf Brücken: Wiedervorlage, KYC-Umgehungsversuche, Sandwich-Muster mit Liquidität.
Modelle: Gradient Boosting/Graph-Embeddings; Lernen Sie, Vorfälle zu markieren.
12) Datenschutz und Compliance (Privacy-by-Design)
PII-Minimierung: PID statt direkter IDs, Tokenisierung.
Datenresidenz: Partitionierung nach Regionen, Verschlüsselung „in Ruhe/unterwegs“.
Recht auf Löschung: tombstone/redaction-events mit Nachweisbarkeit.
Zugriff und Prüfung: rollenbasierte ACLs, Leseprotokolle, signierte Berichte für Prüfungen.
13) SLI/SLO für analytische Payplines
SLI (Beispiel):- Freshness (die mediane Verzögerung von 'observed _ at' bis zum Erscheinen in Gold),
- Completeness (% der Ereignisse ohne Löcher nach Erwartungen der K-Bestätigungen),
- Correctness (% der Ereignisse, die die Validierung der Schemata/Regeln bestanden haben),
- Reorg-Handling-Erfolg (% korrekt Behinderte/Wiederholungen),
- Serve latency (p95 Anfragen an Vitrinen/Dashboards).
- Freshness p95 ≤ 3 min (Streaming), ≤ 15 min (Batch).
- Completeness ≥ 99. 7%, Correctness ≥ 99. 9%.
- Reorg handling success ≥ 99. 9%.
- Serve p95 ≤ 500 ms (Hauptvitrinen).
14) Datenbeobachtbarkeit und Lineage
Data Lineage: vom Dashboard zum rohen Event (column-level).
Qualitätssignale: completeness, uniqueness, referential integrity, schema drift.
Alertas: „stille Abstürze“ (keine neuen Daten), Verteilungssprünge, Wachstum der „unbekannten“ Felder.
15) Dashboards (Vorlagen)
A. Cross-Chain Ops (Realtime/Stunde):- Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.
- TVL, Net Flow per chain, Cost-per-Transfer, Utilization, Versicherungsfonds.
- MAU/DAU (dedup), Kettenretention, Kanaltrichter, QoT.
- Betrugs-/Disputationsrate, Sanktionshits, hochriskante Aktie, Verfahrensgeschwindigkeit.
16) Betriebsvorschriften und Playbook
Vorfall: Frische lag> SLO
Überprüfen Sie die Konnektoren/Indexer, wechseln Sie auf Reserve, aktivieren Sie den Degradationsmodus (Vitrinen zeigen „zuletzt finalisiert“), eskalate an den Besitzer der Quelle.
Vorfall: reorg/challenge surge
Erhöhen Sie K-Bestätigungen/Streitfenster, aktivieren Sie „verzögerte Finalisierung“ für große Beträge, benachrichtigen Sie die Brücke/Betreiber.
Vorfall: Divergenz der Währungen/Vermögenswerte
Betroffene Paare einfrieren, Referenz zurückrollen, USD-Normalisierung neu berechnen, Bericht veröffentlichen.
Vorfall: Fraud/Dispute Jump
Grenzen/Scoring verschärfen, manuelle High-Risk-Revue einschalten, Modell auf frischem Muster ausstatten.
17) Beispielkonfigurationen (Pseudo-YAML)
Finalisierungsfenster über Netzwerke
yaml finality:
eth-mainnet: 12 # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }
Idempotenz- und Deduplizierungsregeln
yaml dedup:
key_template: "${chain_id} ${block_height} ${tx_hash} ${log_index} ${event_type}"
ttl_hours: 48
Pipeline-SLOs
yaml pipelines:
ingest_stream:
freshness_p95_min: 3 completeness_min_pct: 99. 7 gold_build:
correctness_min_pct: 99. 9 reorg_success_min_pct: 99. 9
18) Checkliste Umsetzung
1. Erfassen Sie Quellen, Schemata, Finalisierungsfenster und Eigentümer.
2. Aktivieren Sie Idempotenz und Reorg-Handling (Staaten + Wiederholung).
3. Erstellen Sie einen Modellkern (transfers/bridges/onchain_events/kyc/payouts).
4. Richten Sie Asset-Verzeichnisse und FX-Normalisierung ein.
5. Definieren Sie SLI/SLO von Pipelines und Dashboards.
6. Implementieren Sie Entity Resolution und Privacy-by-Design.
7. Schließen Sie Anti-Betrug-Scoring und Incident Regulation ein.
8. Führen Sie Backfill und Tests an historischen Reorg-/Challenge-Fällen durch.
9. Überprüfen Sie regelmäßig die Diagramme, die Gewichtung der Metriken und die Quellen.
19) Glossar
Finalität - Irreversibilität des Zustands/Ereignisses.
Reorg - Neumontage der Kette, was zur Annullierung eines Teils der Blöcke führt.
Challenge period ist ein Herausforderungsfenster in optimistischen Modellen.
Entity resolution - Zuordnung von Adressen/Konten einer einzelnen Entität.
GTV/TVL - Transaktionsvolumen/blockierter Wert.
Completeness/Freshness/Correctness sind grundlegende Metriken für die Datenqualität.
Fazit: Inter-Chain Analytics ist nicht nur eine Zusammenfassung von Metriken, sondern eine überschaubare Disziplin: ein einheitliches Veranstaltungsschema, korrekte Finalisierung, nachhaltige Piplines, Privatsphäre, Anti-Betrug und verständliche Schaufenster. Diesem Rahmen folgend erhält das Ökosystem einen wirklich „End-to-End“ -Blick auf Wert, Risiken und Wachstum - vom rohen Block bis zur Geschäftslösung.