Komunikacja P2P między uczestnikami

(Sekcja: Ekosystem i sieć)

1) Dlaczego P2P w ekosystemie

• Odporność i tolerancja błędów: nie ma jednego SPOF, łatwiej jest przetrwać awarie sieciowe/regionalne.
• Skalowalność w miarę rozwoju: Każdy nowy członek wnosi wkład w zasoby (kanały, obliczenia, przechowywanie).
• Zmniejszenie kosztów dostawy: ruch idzie najkrótszymi ścieżkami, oszczędności na scentralizowanych bramach.
• Prywatność i suwerenność danych: granulowana kontrola nad tym, co i komu dać.

2) Topologie P2P

1. W pełni podłączony (siatka) - wysoka stabilność, ale drogie w liczbie kanałów (O (n ²)). Nadaje się do małych grup o wysokich kursach wymiany.
2. Super-rówieśnicy - niektórzy rówieśnicy przejmują routing/relaying, kompromis między siatką a gwiazdą.
3. Nakładki na klaster - podgrupy tematyczne (na przykład „provayder”, „affiliat”) połączone mostami (bramy).
4. Nakładka DHT - rozproszona tabela routingu/wyszukiwania usług i treści, logarytmiczna złożoność wyszukiwania.

Zalecenie: dla ekosystemu z wieloma rolami - hybryda: lokalna siatka w grupach „kontraktowych” (operatora „provayder”), super-rówieśników dla routingu, DHT dla globalnego wyszukiwania i Pub/Sub dla wydarzeń.

3) Stosy sieciowe i protokoły

Transport: QUIC/UDP (0-RTT podsumowania, tolerancja strat, multipleksowanie), TCP (fallback), WebRTC (przeglądarki, media/datagramy P2P).
Szyfrowanie: TLS 1. 3 dla QUIC/TCP; nakładka - Noise/Libp2p-SECIO/ECDH + AEAD. Szyfrowanie End-to-End nad transportem dla prywatnych kanałów.
Tożsamość: długoterminowe klucze węzłowe (ed25519/secp256k1), samodzielnie podpisane, opcjonalnie X.509/PKI do spełnienia wymagań zgodności.
Odkrycie i adresowanie: mDNS (LAN), DHT/Kademlia (WAN), statyczne buty (bootstrap peers), katalogi usług/rejestry.
NAT traversal: STUN, UDP dziurkowanie, TURN/przekaźnik fallback, TCP dziurkowanie, port proxing przez super-węzły.

• Req/( RPC) dla żądań na miejscu (notowania cen, limity, statusy płatności).
• Pub/Sub dla zdarzeń (transakcje, statusy gry, alerty zgodności).
• Stream-muxing (yamux/mplex/QUIC) dla równoległych kanałów logicznych.
• CRDT/dzienniki operacyjne do uzgadniania buforów i metadanych bez „kreatora”.

4) Przekaźnik i przekaźnik NAT

1. Direct P2P: próba dziurkowania (UDP preferowane, a następnie TCP).

2. TURN/Przekaźnik poprzez super-węzły: ograniczyć głośność, szyfrować end-to-end, przekaźnik rozliczeniowy.

3. Awaria na HTTPS/HTTP3: tunelowanie poprzez dozwolone korporacyjne pełnomocnictwa, jeśli jest to wymagane.

Monitoruj proporcje bezpośrednich połączeń przekaźnikowych, ponieważ przekaźnik zwiększa koszty i opóźnienia.

5) Routing, wyszukiwanie i odkrywanie

DHT (klasa Kademlia): przechowywać tylko „wskazówki” (rekordy dostawcy), chronić je podpisami, wpisać TTL i czytać kworum.
Routing oparty na treści: klucze do publikacji formularza „service: limits/operator: XYZ/region: TR”.
Prywatny obszar nazw: oddzielne przedrostki/klucze dla zamkniętych społeczności (nakładki partnerskie).
Przeciwdziałanie zatruciom: zatwierdzanie zapisów przez podpisy właścicieli, reputacja węzłów wydawniczych, publikacje limitowane stawkami.

6) Modele danych i pojednanie

Event-sourcing + Pub/Sub: wszystkie istotne zmiany jako imprezy o kluczowym znaczeniu.
CRDT (GCounter, OR-Set, LWW-register): dla konfiguracji, dostępu, buforowanych limitów/cytatów, które są edytowane przez wielu uczestników.
Konsensus nie zawsze jest wymagany: dla ksiąg referencyjnych i metadanych wystarczy „ewentualna spójność”; dla transakcji finansowych - solidne zakończenie (rejestr zewnętrzny/blockchain/notariusz).

7) QoS, SLO i mierniki

• p99 P2P-RPC opóźnienia ≤ 250-400 ms (międzyregionalne ≤ 600 ms), współczynnik sukcesu ≥ 99. 5%.
• Pub/Sub end-to-end delay p95 ≤ 2 ".
• Udział przekaźnika ≤ 30% (celem jest bezpośrednia łączność ≥ 70%).
• Opór kościoła: utrata do 20% uczt bez degradacji SLA.

• Łączność: procent osiągalnych rówieśników, odsetek połączeń bezpośrednich, średnia liczba sąsiadów.
• Jakość ścieżki: RTT, Jitter, utrata pakietów; p95/p99 według klasy serwisowej.
• Przepustowość: przeciętna/szczytowa szerokość pasma w poprzek strumieni.
• Niezawodność: szybkość ponownego połączenia, wskaźnik błędów RPC, Pub/Sub reordering/drop.
• Zdrowie odkrycia: DHT hit/miss, czas rozdzielczości klucza, odsetek przestarzałych rekordów.
• Bezpieczeństwo: udostępnianie szyfrowania E2E, nieprawidłowe podpisy, anomalie.
• Koszt: ruch przez przekaźnik (GB/dzień), CTS na GB, CTS na RPC.

8) Bezpieczeństwo P2P

Tożsamość i zaufanie: długoterminowy dowód tożsamości, wiążący dla podmiotu prawnego (operatora/dostawcy), rejestr zaufanych kluczy; krótkotrwałe klucze sesyjne.
Szyfrowanie: Transport TLS 1. 3/Noise + E2E over (Double-Ratchet, HPKE) dla kanałów prywatnych.
Autoryzacja: tokeny/makaron (związane z operacjami i woluminem), ACL według tematów Pub/Sub.
Anty-Sybil i spam: dowód autorytetu dla węzłów „rejestracyjnych”, reputacji/limitów kredytowych, captchas wejściowych/zastawów płatniczych dla otwartych społeczności.
Nadużycie kanału: wyłącznik na ruchu, wyciek-wiadro-limit na RPC i publikować, „greylisting” hałaśliwe uczty.
Weryfikacja danych: podpisy pod wydarzeniami, dowody merkle dla dużych partii, dziadek-klucz idempotencji.

9) Wzory inżynierskie

RPC idempotencja: 'x-idempotency-key' + 'co najmniej raz' dostawa + deadpan w odbiorniku.
Backpressure: rozmiar okna według strumienia, priorytety (operacje pieniężne> telemetria).
Częściowa tolerancja awarii: szybki czas + połowy trybów pracy (tylko do odczytu, tylko do pamięci podręcznej, funkcja degradacji).
Obserwowalność: ślady p2p-hop, identyfikatory korelacji, eksport metryk przez OpenTelemetry.

json
{
"id": "evt_01J...",
"ts": "2025-10-31T18:25:43Z",
"topic": "limits. update/operator:ACME/region:TR",
"payload_hash": "sha256:...",
"payload": { "limit": 10000, "currency": "TRY", "valid_until": "2025-11-01T00:00:00Z" },
"sig": "ed25519:base64..."
}

10) Pub/Sub i plotki

Sieci plotkarskie do transmisji wydarzeń: anty-powielanie, losowy spacer, okna przesuwne subskrypcji.
Tematy i politycy: rozdzielenie tematów „publicznych” i „prywatnych”; private - tylko dla abonentów z ACL.
Wysyłka: co najmniej raz gwarancja + deterministyczne deduplikacje u abonentów.

11) Przechowywanie i buforowanie

Migawki + dzienniki: szybki zimny start do uczty z ostatniego migawki i dziennik zdarzeń.
Polityka pamięci podręcznej: TTL/ETag/schema versioning; zatwierdzenie przez podpis.
Pamięć podręczna krawędzi: super-rówieśnicy mogą przechowywać gorące klucze/kawałki stanu, podpisując jako „buforowanie proxy”.

12) Obsługa, monitorowanie i deski rozdzielcze

• Łączność%, przekaźnik%, hit/miss DHT, sukces RPC/opóźnienie p95/p99, opóźnienie Pub/Sub, wskaźnik błędu, churn.
• Mapa super-węzłów (obciążenie, nasycenie, opóźnienia według regionu).

• Przekaźnik trendy akcji, koszt ruchu, gorące tematy, E2E udział kanału, ataki/anomalie.

• Wydajność trakcyjna NAT (bezpośredni udział), CTS na GB/RPC, plan rozszerzenia węzła super, zgodność KPI (rejestrowanie, przechowywanie).

13) Badania i jakość

Scenariusze chaosu: zamknięcie% superwęzłów, sztuczne straty/jitter, ładunki na Pub/Sub.
Interop-matrix: SDK/protocol versions × NAT type × regions.
Protokoły zamrażania: losowe pola/rozmiary, złośliwe ładunki (w piaskownicy).
Wiertła zabezpieczające: wyciek klucza rówieśnika, kompromis super-węzła (ponowne wyświetlanie list zaufania, cofanie kluczy).

14) Zgodność i aspekty prawne

Rejestrowanie i niezmienność: łańcuchy hash dziennika, oznaczanie czasu, przechowywanie według regionu (rezydencja danych).
Kontrola dostępu do danych: minimalizacja, szyfrowanie „w spoczynku”, zasady DLP dotyczące tematów, pseudonimizacja atrybutów użytkownika.
Prawo do usunięcia/ograniczenia: polityka „nagrobków-zdarzeń” i „redaction-events” z dowodami edycji kryptograficznej.
Audyt - eksport podpisane dzienniki do kontroli zewnętrznych.

15) Ekonomia sieci i rozliczenia

Model kosztów: ruch przekaźnikowy × GB, przechowywanie migawek, super-węzłów jako „węzły dostawcy” (kompensacja na GB/RPC).
Fair-use: kwoty publikacji i RPC; płatne kanały/priorytety „przyspieszone”.
Motywacja dla kanałów bezpośrednich: zniżki na P2P-direct, podnoszenie limitów dla „dobrych obywateli” sieci.

16) Szablon SLO/OKR (kwartał)

KR1: ≥ 75% połączeń bezpośrednich, rozdzielczość DHT p95 ≤ 300 ms.
KR2 (wydajność): p99 RPC ≤ 400 ms globalnie; Pub/Sub p95 ≤ 2 ".
KR3: sukces RPC ≥ 99. 7%; odporność kościoła na 20% kropli.
KR4 (Bezpieczeństwo): ≥ 95% kanałów z E2E; 0 krytycznych incydentów związanych z podpisem/substytucją.
KR5: ruch przekaźnikowy na 1 RPC − 20% QoQ; CTS na GB − 15% QoQ.

17) Incydenty Playbook (oszustwo arkusza)

• Włącz agresywne dziurkowanie, zmień baseny STUN, rozszerzyć geografię super-węzłów, umożliwić priorytetyzację krytycznych tematów.

• Przywrócić zaufane klucze wydawców, umożliwić kworum kontroli, wyczyścić przestarzałe zapisy, tymczasowo ograniczyć publikacje od podejrzanych rówieśników.

• Limit stawki + dowód pracy/brama opłat, szara lista, przebudowa nakładki z nowymi progami podpisu.

• Natychmiastowe wycofanie, publikacja „cofnąć-event”, rotacja kluczy zależnych rówieśników, ponowne obliczenie ACL.

18) Przykład konfiguracji (Pseudo-YAML)

yaml p2p:
transport: [quic, tcp]
encryption: [tls13, noise]
discovery:
bootstrap_peers:
- /dns4/bootstrap-1. ecosys/p2p/12D3KooW...
- /dns4/bootstrap-2. ecosys/p2p/12D3KooX...
dht: kademlia mdns: true nat_traversal:
stun_servers: [stun1. ecosys. net, stun2. ecosys. net]
turn_relays:
- turn1. ecosys. net
- turn2. ecosys. net hole_punching: {udp: true, tcp: true}
relay_threshold_pct: 30 pubsub:
engine: gossip topics:
- name: limits. update acl: allow: [operators, providers]
- name: payouts. status acl: allow: [operators]
security:
e2e_required_topics: [payouts. status, limits. update]
acls:
operators: [12D3KooA..., 12D3KooB...]
providers: [12D3KooC..., 12D3KooD...]
rate_limits:
rpc_per_minute: 600 publish_per_minute: 1200

19) Lista kontrolna wdrażania

1. Wybierz łączoną topologię (oczko w obrębie + super-rówieśników + grupy kontraktowe DHT).
2. Podnieś buty i super węzły w kluczowych regionach, dodaj STUN/TURN.
3. Zdefiniuj formaty zdarzeń, podpisy, ACL i zasady e2e.
4. Włączyć ślady i mierniki (RTT, relay-%, DHT-latency, sukces RPC).
5. Naprawić SLO/OKR, włączyć alarm spalania.
6. Spędzić dzień chaosu: przerwy, straty, obciążenie na Pub/Sub.
7. Reguluj rotację klucza, audyt dziennika, procedurę odpowiedzi.

Linia dolna: dobrze zaprojektowana sieć P2P w ekosystemie zmniejsza zależność od bram centralnych, przyspiesza wymianę i zwiększa stabilność. Łącząc szyfrowanie QUIC, DHT, Pub/Sub, E2E, ścisłe ACL i wymierne wykorzystanie (SLO/metryki), otrzymujesz skalowalną i bezpieczną tkaninę sieciową, w której każdy uczestnik jest kompletnym węzłem wartości, a nie pasywnym klientem.