Interoperabilität der Teilnehmer

(Abschnitt: Ökosystem und Netzwerk)

1) Was ist die Interoperabilität der Teilnehmer

Interoperabilität - die Fähigkeit verschiedener Organisationen (Betreiber, Studios, PSP, KYC/AML-Anbieter, Bridges, Affiliates, Analytics und Governance), über vereinbarte Protokolle und Verträge zuverlässig miteinander zu interagieren und dabei die Sicherheit, Privatsphäre und Reproduzierbarkeit der Geschäftsergebnisse zu wahren.

• Integrationsgeschwindigkeit und Skalierung (Time-to-Integration ↓)
• Vorhersagbarkeit (stabile SLOs/SLAs über kritische Flüsse).
• Sicherheit und Compliance (Mindestrechte, Audit).
• Evolution ohne Bruch (Versionierung, Backward-Kompatibilität).

2) Interoperabilitätsstufen (Schichtenmodell)

1. Transport und Netzwerk: HTTP/2/3, gRPC/QUIC, WebSockets, P2P, mTLS.
2. Identitäten und Vertrauen: org_id, peer_id, X.509/mTLS, Unterschriften, Schlüsselrotation.
3. Ereignisse und Daten: einheitliche Ereignisschemata, Asset/Netzwerk-Verzeichnisse, Idempotency.
4. Prozesse und Geschäftsverträge: Payout/Settlement, Attribution, Risikosignale, Limitreplikation.
5. Management/Rechtsschicht: SLA/SLO, DPA, Lizenzen, Governanceregelungen.
6. Beobachtbarkeit und Qualität: SLI/SLO, Logging, Traces, Audit.

Jede Schicht hat ihre eigenen Verträge, Tests und Kompatibilitätsrichtlinien.

3) Gestaltungsprinzipien

Contract-first: APIs/Schemas/Events werden vor der Implementierung formalisiert.
Backward-kompatible Änderungen: Strategie „nur Felder hinzufügen“ und Deprecate-Fenster ≥ 90 Tage.
Capability negotiation: Die Teilnehmer tauschen unterstützte Fähigkeiten aus und wählen eine gemeinsame Teilmenge aus.
Isolation und PoLP: Zugriffe und Limits werden „minimal notwendig“ ausgegeben.
Idempotenz und Determinismus: wiederholungssichere Operationen, vorhersehbare Konfliktregeln.
Standard-Beobachtbarkeit: Abfrage-/Ereigniskorrelation (trace-id), überprüfbare Belege.
Datenminimierung: keine PII in Telemetrie/Labels, Pseudonymisierung.

4) Capability negotiation (Verhandlung von Möglichkeiten)

Beim Händeschütteln veröffentlichen die Teilnehmer ein Manifest der Möglichkeiten und Versionen.

yaml participant:
org_id: "ORG:ACME"
versions:
api: "2. 6. 1"
events: "1. 9. 0"
capabilities:
payouts: { create: true, cancel: true, currencies: [USD, EUR, USDC] }
kyc: { level: ["basic","enhanced"], sla_minutes_p95: 15 }
bridge: { proof: ["light","zk"], challenge_supported: true }
telemetry: { qos: ["P0","P1"], traces: true }
limits:
payouts_daily_usd: 1_000_000 rate_limits: { create_per_minute: 500 }

Die Kompatibilitäts-Engine passt die Manifeste der Parteien an und wählt ein Jobprofil aus (z.B. 'payouts: v2', 'events: v1. 9`).

5) API/Event Verträge und Schemata

API-Verträge: OpenAPI/gRPC IDL, eindeutige Fehlercodes, idempotente Schlüssel („Idempotency-Key“), Einschränkungen von Körpern.
Ereignismodell: 'deposit.', 'payout.', 'bridge.', 'kyc.', 'risk.', 'product.' - mit stabilen Feldern.
Verzeichnisse/Verzeichnisse: Netzwerke, Vermögenswerte, Zahlungsmethoden, SDK-Versionen, Regionen/Gerichtsbarkeiten.
Datenverträge (Data Contracts): in CI getestet, Änderungen durch Governance mit Timelock.

yaml event:
id: uuid ts: timestamp_utc type: payout. created    payout. finalized    bridge. lock...
src_org: string dst_org: string payload: object trace_id: string idempotency_key: string signature: string # source signature

6) Versionierung und Kompatibilität

Semantische Versionen: 'MAJOR. MINOR. PATCH`.
Regeln: MINOR/PATCH - rückwärtskompatibel; MAJOR - Parallelexistenz mit „Überrollbügeln“ (Adaptern), Deprecate ≥ 90 Tage.
Migration Playbooks: Migrationsvorlagen für APIs/Events/Verzeichnisse; Emulatoren alter Formate.

7) Integrationsmuster (Muster)

Request-Reply + Idempotency: sichere Auszahlungen/Limits/Reserven.
Event-Driven: „Quellen der Wahrheit“ senden Änderungen; Abonnenten materialisieren Schaufenster.
Outbox/Inbox: atomare Veröffentlichung von Ereignissen aus der DB; idempotent Empfang beim Abonnenten.
SAGA (Orchestrierung/Choreographie): konzertierte Multi-Domain-Operationen (z.B. „popolneniye→igrovoye sobytiye→vyplata“).
Dual-write guard: Verbot direkter Doppeleinträge ohne Outbox.
Replay/Backfill: Wiederherstellung nach Abstürzen mit Aufrechterhaltung der Ordnung und Finalisierung.

8) Sicherheit und Vertrauen

mTLS und Bindung der Schlüssel an 'org _ id/peer _ id'.
Ereignissignaturen, Vertrauensprotokoll (wer und was unterzeichnet/empfangen hat).
RBAC/ABAC und Quoten: Rechte nach Rollen, Grenzen nach Operationen/Volumen.
Secret-Management: Rotation, Verbot von „langlebigen“ Token, kurze Scopes.
PII/Datenschutz: Tokenisierung, regionale Datensegregation (EU/ROW), DSR-Prozesse (Löschung/Export).
Schutz vor Missbrauch: Velocity-Limits, Anti-Fraud-Signale, Sanktionsprüfungen.

9) SLI/SLO und die Beobachtbarkeit der Interoperabilität

• 'p95 Time-to-Acknowledge' (Ereignis-Handshake).
• „p95 End-to-End“ (Erstellen → Finalisieren/Ausführen)
• 'Erfolgsrate' nach Ereignis-/Aktivitätstypen.
• „Schema/Contract Compliance%“ (valide Meldungen).
• „Proof Coverage%“ (Anteil der unterzeichneten/beigefügten Nachweise).
• `Error Budget Burn` по P0/P1.

• P0 (Auszahlungen/Brücke): p95 E2E ≤ 5 min, Erfolg ≥ 99. 5%, Ack ≤ 2 s.
• P1 (Lebensmittel): Freshness p95 ≤ 3 min, Compliance ≥ 99. 9%.
• Datenverträge: Drift MTTA ≤ 5 min, Breaking changes = 0 ohne MAJOR.

Дашборды: Interop Ops, Contract Health, Latency & Success, Schema Drift, Security & Keys.

10) Kompatibilitätsmatrix (Testdesign)

• Szenarien: payouts, deposits, bridge, risk, product, telemetry.
• Versionen: API v2. 6/v2. 5, events v1. 9/v1. 8.
• Netzwerkmodi: Normal, Degradation, Rengs, DA-Latenzen.
• Gerichtsbarkeiten: EU/UK/TR/LA - verschiedene Kataloge und Vorschriften.

Autotests: Vertragstests (Producer/Consumer), Idempotency, Retry/Compensation, Schema-Linter, Lastprofile.

11) Referenzschemata und Kataloge

Leistungskatalog (SQL)

sql
CREATE TABLE capabilities (
org_id TEXT,
cap_name TEXT,
version TEXT,
params JSONB,
PRIMARY KEY (org_id, cap_name)
);

Vertrags-/Versionsregister

sql
CREATE TABLE contracts (
name TEXT, kind TEXT,     -- api    events    catalog version TEXT, status TEXT,  -- active    deprecated    retired breaking BOOLEAN DEFAULT FALSE,
effective_from TIMESTAMPTZ,
deprecates_at TIMESTAMPTZ,
PRIMARY KEY (name, version)
);

Überwachung der Kompatibilität

sql
SELECT name, version, 100. 0SUM(CASE WHEN compliant THEN 1 END)/COUNT() AS compliance_pct
FROM contract_checks
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY name, version;

12) Konfigurationen (YAML)

Versionsrichtlinie

yaml versioning:
events: { compatibility: "BACKWARD", deprecate_days: 90 }
api:  { parallel_majors: true, support_minors: 2 }

Idempotency und Wiederholungen

yaml idempotency:
header: "Idempotency-Key"
ttl_hours: 72 conflict_policy: "prefer-latest-payload-with-signature"

QoS-Klassen

yaml qos:
P0: { ack_timeout_ms: 2000, retries: 3, backoff_ms: [100,400,800] }
P1: { ack_timeout_ms: 5000, retries: 2 }
P2: { best_effort: true }

13) Betriebsvorschriften

Täglich: Compliance-Bericht zu Verträgen/Schemata, abgelaufene Schlüssel, SLO-Burn.
Wöchentlich: Ausschuss für Interoperabilität (neue Möglichkeiten, Migrationen, Deprecates).
Vor der Veröffentlichung: Vertragstests, kanarische mit „Glas“ -Metriken, Rollback-Pläne.

Vorfälle: einheitlicher Status-Kanal, Meldungsvorlagen für Partner, Post-Mortem ≤ 72 Stunden

14) Playbook der Vorfälle

A. Schema/Contract Drift

1. Aktivieren Sie den „strikten Modus“ (schneiden Sie nicht konforme Nachrichten ab),

2. den Vorfall zu öffnen und die Quellen zu benachrichtigen,

3. diff generieren,

4. Adapter/Fix freigeben,

5. Post-Mortem und Aktualisierung der Linters.

B. Massenwiederholungen/Doppelmeldungen

1. Idempotenz/Schlüssel prüfen,

2. Dedup-Filter aktivieren,

3. den lärmenden Produzenten zu beschränken,

4. Neuberechnung der Schaufenster.

C. Zunahme der Latenz/ack-Drawdowns

1. Priorisieren Sie P0, erhöhen Sie die Verbraucher,

2. vorübergehend P2-Proben reduzieren,

3. Analyse von Routen und Netzengpässen.

D. Kompromittierung des Teilnehmerschlüssels

1. Revoke, Rotation, Aktualisierung der vertrauenswürdigen Registrierung,

2. Überzeichnung kritischer Battles/Zertifikate,

3. Maßnahmenaudit, Bericht an Partner.

E. Nichtübereinstimmung der Verzeichnisse (Assets/Netzwerke)

1. Quarantäne von Konfliktnachrichten,

2. Katalog zurücksetzen,

3. Neuberechnung der Aggregate,

4. Veröffentlichen von Korrekturen.

15) Checkliste Umsetzung

1. Definieren Sie Ebenen und Verträge (APIs, Ereignisse, Verzeichnisse, Schlüssel).
2. Starten Sie capability negotiation und die Versions-/Fähigkeitsregistrierung.
3. Aktivieren Sie Idempotenz, Quoten, QoS, Signaturen und mTLS.
4. Konfigurieren Sie SLI/SLO, Dashboards und Alerts (Ack, E2E, Compliance).
5. Automatisieren Sie Vertragstests und Kompatibilitätstestmatrix.
6. Geben Sie die Regeln für Deprecates und Migrationen ein (MAJOR parallel).
7. Überprüfen Sie regelmäßig Kataloge/Datenschutz- und Zugangsregeln.

16) Glossar

Capability negotiation - Vereinbaren Sie die unterstützten Fähigkeiten und Job-Profil.
Contract-first - Gestaltung von Schnittstellen über formale Verträge bis hin zur Umsetzung.
Idempotency - Wiederholungssicherheit Operationen.
Schema/Contract Drift - Diskrepanz der tatsächlichen Nachrichten mit den angekündigten Verträgen.
PoLP ist das Prinzip der minimal notwendigen Rechte.
Compliance% - Anteil der Nachrichten/Anfragen, die dem Vertrag entsprechen.

Fazit: Die Interoperabilität der Teilnehmer ist ein verwaltetes System aus Verträgen, Versionen, Fähigkeiten und Beobachtbarkeit. In Anlehnung an dieses Framework ermöglicht das Ökosystem schnelle Integrationen, nachhaltige Geschäftsflüsse und eine sichere Entwicklung ohne Pannen - von der Netzwerkebene und Identitäten bis hin zu Prozessen und Abläufen.