Interoperacyjność uczestników

(Sekcja: Ekosystem i sieć)

1) Jaka jest interoperacyjność uczestników

Interoperacyjność - zdolność różnych organizacji (operatorów, studiów, PSP, dostawców KYC/AML, mostów, podmiotów stowarzyszonych, analityków i rządów) do niezawodnej interakcji ze sobą poprzez uzgodnione protokoły i umowy, przy zachowaniu bezpieczeństwa, prywatności i powtarzalności wyników biznesowych.

• Czas do integracji
• Przewidywalność (stabilny SLO/SLA według przepływów krytycznych).
• Bezpieczeństwo i zgodność (minimalne wystarczające prawa, audyt).
• Ewolucja bez podziałów (wersioning, kompatybilność wsteczna).

2) Poziomy interoperacyjności (model warstwy)

1. Transport i sieć: HTTP/2/3, gRPC/QUIC, WebSockets, P2P, mTLS.
2. Tożsamość i zaufanie: org_id, peer_id, X.509/mTLS, podpisy, rotacja klucza.
3. Zdarzenia i dane: ujednolicone schematy zdarzeń, katalogi aktywów/sieci, idempotencja.
4. Procesy i umowy biznesowe: wypłata/rozliczenie, przypisanie, sygnały ryzyka, ograniczenie replikacji.
5. Zarządzanie/warstwa prawna: SLA/SLO, DPA, licencje, regulamin rządowy.
6. Obserwowalność i jakość: SLI/SLO, logowanie, śledzenie, audyt.

Każda warstwa ma własne umowy, testy i politykę zgodności.

3) Zasady projektowania

Umowa pierwsza: API/schematy/wydarzenia są formalizowane przed wdrożeniem.
Zmiany kompatybilne z wstecznym: strategia „tylko dodawanie pól” i okno deprecate ≥ 90 dni.
Negocjacje dotyczące zdolności: Uczestnicy wymieniają wspierane możliwości i wybierają wspólny podzbiór.
Izolacja i PoLP: dostęp i limity są wydawane „minimum konieczne”.
Idempotencja i determinizm: powtarzające się bezpieczne operacje, przewidywalne zasady konfliktu.
Domyślna obserwowalność: śladowa korelacja żądań/zdarzeń, możliwe do zweryfikowania rachunki.
Minimalizacja danych: brak PII w telemetrii/etykietach, pseudonimizacja.

4) Negocjacje dotyczące zdolności

Podczas potrząsania rękami uczestnicy publikują manifest cech i wersji.

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 }

Silnik kompatybilności pasuje do manifestów stron i wybiera profil pracy (np. "wypłaty: v2", "wydarzenia: v1. 9`).

5) Umowy i schematy API/Event

Kontrakty API: OpenAPI/gRPC IDL, jasne kody błędów, idempotent keys ('Idempotency-Key'), ograniczenia ciała.
Model zdarzenia: "depozyt. „,” wypłata. „,” most. „,” kyc. „,” ryzyko. „,” produkt. "- o stabilnych polach.
Katalogi/katalogi: sieci, aktywa, metody płatności, wersje SDK, regiony/jurysdykcje.
Kontrakty na dane - testowane w CI, zmiany poprzez zarządzanie z terminem.

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) Wersioning i kompatybilność

Wersje semantyczne: 'MAJOR. DROBNE. PATCH '.
Zasady: MINOR/PATCH - kompatybilne wstecz; MAJOR - równoległe istnienie z „adapterami”, deprecate ≥ 90 dni.
Playbooks migracji: szablony migracji dla API/zdarzeń/katalogów; emulatory starych formatów.

7) Wzorce integracji (wzory)

Zapytanie-odpowiedź + Idempotencja: bezpieczne płatności/limity/rezerwy.
Event-Driven: „źródła prawdy” wysyłają zmiany; abonenci materializują sklepy.
Outbox/Inbox: atomowe publikowanie wydarzeń z bazy danych; odbiór idempotentny u abonenta.
SAGA (orkiestra/choreografia): skoordynowane operacje wielopoziomowe (na przykład, „popolneniye → igrovoye sobytiye → vyplata”).
Podwójna osłona zapisu: brak bezpośrednich podwójnych wpisów bez skrzynki zewnętrznej.
Powtórka/Backfill: awaria z zamówieniem i finalizacją.

8) Bezpieczeństwo i zaufanie

mTLS i powiązanie klucza z 'org _ id/peer _ id'.
Podpisy pod wydarzeniami, dziennik zaufania (kto i co podpisał/otrzymał).
RBAC/ABAC i kwoty: prawa według roli, limity według operacji/wolumenu.
Tajne zarządzanie: rotacja, zakaz „długotrwałych” żetonów, krótkie zakresy.
PII/prywatność: tokenizacja, regionalna segregacja danych (EU/ROW), procesy DSR (delete/export).
Ochrona przed nadużyciami: ograniczenia prędkości, sygnały o zwalczaniu nadużyć finansowych, kontrole sankcji.

9) SLI/SLO i obserwowalność interoperacyjności

• „p95 Czas do potwierdzenia”.
• 'p95 End-to-End' (utwórz → zakończyć/wykonać).
• „Wskaźnik sukcesu” według typu zdarzenia/operacji.
• „Schemat/Zgodność umowy%” (ważne wiadomości).
• „Zakres dowodu%” (odsetek podpisanych/załączonych dowodów).
• „Error Budget Burn” ма P0/P1.

• P0 (wypłata/most): p95 E2E ≤ 5 min, sukces ≥ 99. 5%, Ack ≤ 2 sek.
• P1 (produkt): świeżość p95 ≤ 3 min, zgodność ≥ 99. 9%.
• Kontrakty na dane: Drift MTTA ≤ 5 min, Zmiany łamania = 0 bez MAJOR.

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

10) Matryca kompatybilności (projekt testu)

• Scenariusze: wypłaty, depozyty, most, ryzyko, produkt, telemetria.
• Wersje: API v2. 6/v2. 5, wydarzenia v1. 9/v1. 8.
• Tryby sieciowe: normalne, degradacja, regurgitacja, opóźnienia DA.
• Jurysdykcja: EU/UK/TR/LA - różne katalogi i zasady.

Autotests: testy kontraktowe (producent/konsument), iempotencja, retry/kompensacja, schema-linters, profile obciążeń.

11) Systemy referencyjne i katalogi

Katalog funkcji (SQL)

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

Rejestr kontraktów/wersji

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

Monitorowanie zgodności

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

Polityka weryfikacyjna

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

Idempotencja i powtarza

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

Klasy QoS

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) Procedury operacyjne

Codziennie: raport zgodności z umowami/programami, klucze wygasłe, spalanie SLO.
Co tydzień: komitet ds. interoperacyjności (nowe możliwości, migracja, deprecacja).
Przed zwolnieniem: testy kontraktowe, kanaryjskie z „szklanymi” metrykami, plany rollback.
Incydenty: pojedynczy kanał statusu, szablony wiadomości dla partnerów, pośmiertnie ≤ 72 h.

14) Incydenty Playbook

A. Schemat/Drift kontraktowy

1. Włącz „tryb ścisły” (odciąć nieodpowiednie wiadomości),

2. otworzyć incydent i powiadomić źródła,

3. generować różnicę

4. zwolnić adapter/naprawić,

5. aktualizacja pośmiertna i liniowa.

B. Masowe powtórki/podwójne wiadomości

1. Sprawdź idempotencję/klucze,

2. włączyć filtry dedup,

3. ograniczyć hałaśliwego producenta,

4. ponowne obliczenie okien sklepowych.

C. Wzrost opóźnienia/wypłaty

1. Priorytet P0, zwiększenie konsumentów,

2. tymczasowo zmniejszyć pobieranie próbek P2,

3. analiza wąskich gardeł trasy i sieci.

D. Kompromis klucza członka

1. Cofnij, obrót, zaufana aktualizacja rejestru,

2. ponowne podpisanie partii/certyfikatów krytycznych,

3. audyt działań, sprawozdanie dla partnerów.

E. Niedopasowanie katalogów (aktywa/sieci)

1. Wiadomości o konflikcie kwarantanny,

2. katalog rollback

3. ponowne obliczenie kruszyw,

4. publikowanie łatek.

15) Lista kontrolna wdrażania

1. Zdefiniuj poziomy i kontrakty (interfejsy API, wydarzenia, katalogi, klucze).
2. Uruchom negocjację zdolności i rejestr wersji/możliwości.
3. Obejmuje idempotencję, kwoty, QoS, podpisy i mTLS.
4. Konfiguruj SLI/SLO, deski rozdzielcze i alerty (Ack, E2E, Zgodność).
5. Automatyczne testy kontraktowe i matryca testowa kompatybilności.
6. Wprowadź procedury deprecate i migracji (MAJOR równolegle).
7. Regularnie przeglądaj katalogi/zasady prywatności i dostępu.

16) Słownik

Negocjacje w sprawie zdolności - pogodzenie wspieranych możliwości i profilu pracy.
Kontrakt pierwszy - Interfejsy projektowe poprzez formalne umowy przed wdrożeniem.
Idempotencja - operacje powtarzania zabezpieczeń.
Schemat/Drift kontraktowy - rozbieżność między rzeczywistymi komunikatami a deklarowanymi umowami.
PoLP jest zasadą minimalnych niezbędnych praw.
Zgodność% to odsetek wiadomości/żądań, które odpowiadają umowie.

Podsumowanie: Interoperacyjność uczestników jest zarządzanym systemem umów, wersji, możliwości i obserwowalności. Stosując się do tych ram, ekosystem zapewnia szybkie integracje, zrównoważone przepływy przedsiębiorstw i bezpieczną ewolucję bez podziałów - od poziomu sieci i tożsamości po procesy i zarządzanie.