Mosty między ekosystemami

(Sekcja: Ekosystem i sieć)

1) Dlaczego mosty są potrzebne

Mosty zapewniają transfer wartości i danych między różnymi domenami: łańcuchami blokującymi, szynami płatniczymi, platformami partnerskimi, jeziorami danych i sieciami API. Zwiększa to płynność, łączy odbiorców i przyspiesza integrację bez centralizacji. Kluczowe efekty: wzrost GTV, zmniejszenie tarcia na pokładzie partnera, nowe produkty (aktywa gry krzyżowej, płatności wielokołowe, pojedyncza tożsamość).

2) Taksonomia mostów

1. Powiernicze - scentralizowane kwestie powiernicze „owinięte” aktywa/wiadomości. Proste, ale ryzyko kontrahenta.
2. Sfederowane/MPC - zestaw walidatorów/wyroczni wspólnie podpisuje wydarzenia; Decentralizacja jest lepsza, ale jest zaufanie do federacji.
3. Light-client-based - sieć docelowa sprawdza kryptografię dowodu sieci źródłowej (nagłówki/gałęzie Merkle); wysoka niezawodność kryptograficzna.
4. Optymistyczne - wydarzenia są odbierane z opóźnieniem w przypadku ewentualnych sporów (okres wyzwań).
5. ZK-proof-based - krótki dowód poprawności stanu/przejścia; szybkie i bezpieczne, droższe do obliczenia.
6. Sieć płynnościowa - transfer wartości za pośrednictwem producentów/kanałów rynkowych (HTLC/kanały, „natychmiastowa” płynność, ale istnieje ryzyko płynności).
7. Tylko komunikatory - transmisja danych/połączenia bez żetonów (polecenia, statusy, rachunki).

3) Wybór modelu zaufania i architektury

Wymagana gwarancja: finalizacja ekonomiczna (niepowodzenie), weryfikacja kryptograficzna lub zaufanie do operatorów.
Opóźnienie: lekki klient/ZK - szybszy/droższy; optymistyczne - opóźnienie dla okna sporu; pozbawienie wolności - szybkie, ale „ludzkie” zaufanie.
Koszt: Opłaty za gaz/dowody/podpisy, oportunistyczne koszty płynności.
System operacyjny: kto obraca klucze, monitoruje alerty, prowadzi awaryjne przerwy.
Zalecenie: dla krytycznych przepływów pieniężnych - lekki klient/ZK; w przypadku danych i poleceń - tylko sygnatury i potwierdzenie; w przypadku płatności detalicznych - sieć płynnościowa z limitami i ubezpieczeniem.

4) Obiekty i typy wiadomości

Transfery tokenów: zamek/mięta, oparzenie/zwolnienie, powiernictwo, przywracanie równowagi.
Płatności i wypłaty: multi-chain, konwersja, harmonogram.
Dane/wydarzenia: statusy KYC, limity, wydarzenia w grze, wyniki weryfikacji.
Połączenia międzysieciowe-Wykonaj funkcję/transakcję w domenie docelowej.
Paragony i potwierdzenia: dowód dostarczenia, dowód wykonania, operacje kompensacyjne.

5) Routing i finalizacja

Źródło → Przekaźnik → Cel: zdarzenie jest rejestrowane w sieci źródłowej, dostarczane przez przekaźnik, zweryfikowane w celu.

• Ekonomiczne: po K potwierdzenia/eras.
• Kryptografia: światło-klient/ZK-dowody.
• Okno sporu: model optymistyczny.
• Porządek i idempotencja: deterministyczny idempotencja-klucz i nonce, cel-side deduplication.

6) Ryzyko i zagrożenia

Spoofing/powtórka wiadomości.
Kompromis federacji/kluczy operatora.
Błędy w odwzorowaniu aktywów (niedopasowanie dziesiętne, identyfikator).
Brak płynności, poślizg/przedni bieg.
Ataki na zwiotczacze/wyrocznie (opóźnienia, cenzura).
Niespójność wideł/reorg.
Nieprawidłowe granice i brak „zaworów stopu”.

7) Polityka bezpieczeństwa

mTLS + podpisy zdarzeń (ed25519/secp256k1), spinanie kluczy.
Nonce/sekwencja na parę („A” → „B”).
ACL według rodzaju wiadomości/aktywów/limitu.
Limity/prędkość kontroli transferów i wiadomości.
Wyłącznik-wyłącznik: para globalna/para dla anomalii.
Wykonanie dwuskładnikowe: podpis techniczny + multisig operacyjny dla dużych kwot.
Lista zaufanych konfiguracji: mapowanie Id, przecinki, adresy umów/usług mostowych.

8) Ekonomia i płynność

Model opłaty: opłata podstawowa + dopłata priorytetowa + opłata za dowód.
Płynność: pula sieci, monitorowanie otwartych ekspozycji; przywrócenie równowagi poprzez odwrotne przepływy/zlecenia rynkowe.
Poślizg i notowania: notowania rynkowe, preautoryzacja limitów, sprawiedliwa dystrybucja.
Ubezpieczenie: fundusz ryzyka/ubezpieczenie operatorów mostów z publiczną sprawozdawczością.
Wypłata SLAs: cele dotyczące szybkości potwierdzenia/dostawy, rekompensaty za naruszenie.

9) SLI/SLO i monitorowanie

• Czas do finału p50/p95 (min/sek).
• Success-Rate of messages/transfers (%).
• Reorg/Challenge events (szt ./dzień).
• Wykorzystanie płynności (%), zaległości oczekujące (kawałki/kwota).
• Cost-per-Transfer (eko.) .
• Przekaźnik/Wyrocznia Dostępność (%), Świeżość Danych (dwupoziomowy).

• Wskaźnik sukcesu ≥ 99. 5%, p95 Końcowość ≤ 5 min (lub regulacja sieci).
• Bufor płynności ≥ 150% 95. percentyla dziennego przepływu netto.
• Zaburzenia MTTA ≤ 5 min, MTTR SEV-1 ≤ 30 min.
• Raporty dotyczące stanu mostu - dzienne, raporty o zdarzeniach ≤ 72 godziny.

10) Przepisy eksploatacyjne

Wersioning protokołu: zdolność-negocjacja, kompatybilność wsteczna, odchylenie okna ≥ 90 dni.
Rotacja klucza: planowane i awaryjne procedury, „podwójne klucze” (stare/nowe) z alternatywnym przełącznikiem.
Limity: dziennie/godzinowo, według aktywów i kontrahentów; „awaryjne” granice.
Pauza/odszranianie: kto aktywuje, jak jest ogłaszany, jak jest usuwany; statusy publiczne.
Kłody: niezmienne dzienniki zdarzeń/decyzji związane z identyfikatorem wniosku (zarządzanie).
Kontrole zgodności: regularne audyty konfiguracyjne, widelce/symulacje reorg.

11) UX i doświadczenie deweloperskie

Pojedyncze paragony i statusy (oczekujące, sfinalizowane, zakwestionowane, nieudane).
Śledzenie i śledzenie: link/ID, pasek postępu finalizacji, ETA.
Idempotentne SDK z automatycznym przekładaniem/deduplikacją.
Katalog aktywów i sieci: pojedynczy rejestr z wersjami i lokalizacjami.
Wpisy: haki/witryny internetowe o zmianach stanu, limitach, przerwach.

12) Zgodność i kontrola ryzyka

KYC/KYB za wpływ na role (operatorów, dostawców, relayers).
AML/filtry sankcji przed i po przeniesieniu; listy bloków.
rezydencja danych: routing i szyfrowanie zgodnie z lokalnymi wymaganiami; pseudonimizacja.
Audyt: zewnętrzny kod/kontrola konfig, sprawozdawczość z funduszy ryzyka.
Polityka rozstrzygania sporów: czas, dowody, odwracalność (polityka odwracania tylko dla wiadomości).

13) Badanie i walidacja

Symulacje Forks/Reorg: weryfikacja ponownej dostawy i anulowania.
Zamrażanie zdarzeń wejściowych: duże ładunki użytkowe, rzadkie przypadki krawędzi.
Testy chaosu zwiotczaczy/wyroczni: opóźnienia, odłączenia, utrata łączności.
Backfill/Replay: Bezpieczne powtórzenie historii z podwójną ochroną.
Badania obciążenia płynności: burza zastosowań, równowaga pod ciśnieniem.

14) Incydenty Playbook (oszustwo arkusza)

• Zamrożenie odpowiednich par „A” → „B”, umożliwienie ścisłego sprawdzania nonce/ACL, rejestrów audytu, publikowania statusu.

• Umożliwienie przywrócenia równowagi priorytetowej, podniesienie limitów dla twórców rynku, tymczasowe zwiększenie prowizji, poinformowanie ETA, dla SLO - rekompensata.

• Natychmiastowe odwołanie klucza, przejście na multisig awaryjny, odtworzenie zaufanych list, rotacja konfiguracji SDK, raport publiczny.

• Zwiększenie potwierdzeń/opóźnień K, tymczasowe przełączenie na „potwierdzone” punkty kontrolne, odroczenie dużych transferów.

• Przełączanie na kanały kopii zapasowych, obniżanie częstotliwości partii, włączanie filtrów i kwot, niezależna weryfikacja krzyżowa.

15) Przykłady konfiguracji (Pseudo-YAML)

Routing i finalizacja

yaml bridge:
pairs:
- from: chainA to: chainB confirmations: 20 finality_mode: light_client  # or optimistic    zk nonce_window: 1000 rate_limits:
per_minute: 500 per_hour: 20000 circuit_breaker:
enabled: true error_rate_threshold: 0.5  # %
open_window_sec: 900

Płynność i opłaty

yaml liquidity:
pools:
chainA: { base: 2_000_000, buffer_pct: 50 }
chainB: { base: 1_500_000, buffer_pct: 60 }
fees:
base_bps: 8 priority_bps: 5 insurance_fund:
size: 1_000_000 policy: "cover shortfall up to 30%"

Bezpieczeństwo i klucze

yaml security:
signing:
mode: mpc threshold: "t-of-n: 5/8"
acl:
assets_allowlist: [USDC, GAME, POINTS]
methods_allowlist: [transfer, call, message]
alerts:
pager_on:
- "success_rate<99.2%"
- "p95_finality>10m"
- "liquidity_utilization>85%"

16) Schematy danych i idempotencja (pseudo-SQL)

sql
-- Регистр заявок на перенос
CREATE TABLE bridge_transfers(
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
src_tx TEXT, status TEXT, created_at TIMESTAMPTZ,
nonce BIGINT, sender TEXT, recipient TEXT,
meta JSONB
);

-- Квитанции/доказательства
CREATE TABLE bridge_receipts(
transfer_id TEXT REFERENCES bridge_transfers(id),
proof_type TEXT, proof JSONB, received_at TIMESTAMPTZ,
UNIQUE(transfer_id, proof_type)
);

-- Идемпотентность целевой цепи/домена
CREATE TABLE bridge_idempotency(
dst_chain TEXT, nonce BIGINT, hash TEXT,
PRIMARY KEY (dst_chain, nonce)
);

17) Deski rozdzielcze

Operacje w czasie rzeczywistym: Success-Rate, p95/p99 Finalność, zaległości, dostępność przekaźnika/wyroczni, szybkość spalania SLO.
Płynność i koszt: baseny załadunkowe, wykorzystanie, cost-per-transfer, fundusz ubezpieczeniowy.
Bezpieczeństwo i ryzyko: wyzwanie/reorg events, rate-limit triggering, pause/defrost.
Zarządzanie i zgodność: ograniczenia/kluczowe zmiany, sprawozdania z audytu, wskaźniki SLA.

18) Lista kontrolna wdrażania

1. Wybierz model zaufania (lekki klient/ZK za pieniądze; wiadomości tylko dla poleceń).
2. Przechwytywanie schematu wiadomości, nonce/idempotence, ACL i limitów.
3. Skonfiguruj zakończenie (potwierdzenie K/okno sporu), wyłącznik i rotację klucza.
4. Podnieść deski rozdzielcze SLI/SLO i wpisy; sporządzanie statusów publicznych.
5. Rozszerzyć pulę płynności i fundusz ubezpieczeniowy i umożliwić przywrócenie równowagi.
6. Wykonywać badanie audytu/penetracji i regularną symulację wideł przekaźnikowych/awarii.
7. Reguluj politykę komunikacji i sporów.

19) Słownik

Finalność - nieodwracalność transakcji/zdarzeń.
Okres wyzwań - okno wyzwań (model optymistyczny).
Lekki klient - weryfikacja nagłówków i dowodów innej sieci.
ZK-proof - krótki dowód poprawności obliczeń/stanu.
HTLC - wymiana atomowa w zakresie płatności warunkowych/tajemnic.
MPC - wspólny podpis bez ujawniania klucza prywatnego.
Idempotencja - odporność na redelivery.

Linia końcowa: niezawodny most jest nie tylko „połączeniem sieciowym”, ale zarządzanym systemem kryptografii, limitów, płynności, obserwowalności i regulacji operacyjnych. Stosując się do tych zasad, ekosystem zyskuje bezpieczną i przewidywalną interoperacyjność bez niespodzianek dla użytkowników i partnerów.