Қатысушылар арасындағы P2P байланыстары

(Бөлім: Экожүйе және Желі)

1) P2P экожүйеде не үшін

• Тұрақтылық және істен шығуға төзімділік: бірыңғай SPOF жоқ, желілік/өңірлік іркілістерді бастан кешу оңай.
• Өсуіне қарай масштабталуы: әрбір жаңа қатысушы ресурстарды (арналар, есептеу, сақтау) енгізеді.
• Жеткізу құнының төмендеуі: трафик ең қысқа жолмен жүреді, орталықтандырылған шлюздерде үнемдеу.
• Деректердің құпиялылығы мен егемендігі: не және кімге берілетінін түйіршіктелген бақылау.

2) P2P топологиялары

1. Толық байланыс (mesh) - жоғары орнықтылық, бірақ арналар саны бойынша қымбат (O (n ²)). Алмасу жиілігі жоғары шағын топтарға арналған.
2. Супер-тораптар/гибрид (super-peers) - пирлердің бір бөлігі mesh пен жұлдыз арасындағы бағдарды/ретрансляцияны, ымыраны өзіне алады.
3. Кластерлiк оверлейлер - көпiрлермен (gateways) байланысқан тақырыптық кiшi желiлер (мысалы, «провайдер-оператор», «аффилиат-оператор»).
4. DHT-оверлей - сервистер мен контентті бағыттау/іздеудің бөлінген кестесі, іздеудің логарифмдік күрделілігі.

Ұсыным: көптеген рөлдері бар экожүйе үшін - гибрид: «келісімшарт» топтарының ішіндегі жергілікті mesh (провайдер операторы), маршруттау үшін super-peers, жаһандық іздеу үшін DHT және оқиғалар үшін Pub/Sub.

3) Желілік стек және хаттамалар

Көлік: QUIC/UDP (резюме 0-RTT, жоғалтуға төзімділік, мультиплексиялау), TCP (fallback), WebRTC (браузерлер, P2P-медиа/датаграммалар).
Шифрлау: TLS 1. 3 QUIC/TCP кезінде; оверлей үшін - Noise/Libp2p-SECIO/ECDH + AEAD. End-to-End жеке арналар үшін көліктің үстінен шифрлау.
Сәйкестіктер: өзінен-өзі қол қойған peer-ID тораптардың ұзақ мерзімді кілттері (ed25519/secp256k1) комплаенс талаптарына сәйкес келуі үшін опциондық түрде X.509/PKI.
Анықтау және адрестеу: mDNS (LAN), DHT/Kademlia (WAN), статикалық бута-страптар (bootstrap-пирлар), каталогтар/сервистер тізілімдері.
NAT traversal: STUN, UDP hole-punching, TURN/relay fallback, TCP hole-punching, супер-түйіндер арқылы порт-проксирлеу.

• Нүктелік сұраулар үшін Req/Resp (RPC) (баға белгіленімдері, лимиттер, төлем мәртебелері).
• Оқиғалар үшін Pub/Sub (мемсип) (транзакциялар, ойындар мәртебелері, комплаенс алаңдары).
• Параллель логикалық арналар үшін stream-muxing (yamux/mplex/QUIC).
• Кэштер мен метадеректерді «шеберсіз» келісуге арналған CRDT/операциялық журналдар.

4) NAT traversal және реле

1. Тікелей P2P: hole-punch әрекеті (UDP артықшылықты, содан кейін TCP).

2. Super-тораптар арқылы TURN/Relay: көлемді шектеу, end-to-end шифрлау, релелерді биллингтеу.

3. HTTPS/HTTP3 Fallback: қажет болса рұқсат етілген корпоративтік прокси арқылы туннельдеу.

Тікелей қосылыстардың үлесін vs relay арқылы бақылаңыз, өйткені relay қымбаттайды және жасырындылықты арттырады.

5) Маршруттау, іздеу және табу

DHT (Kademlia-класс): тек «көрсеткіштерді» (provider records) сақтаңыз, оларды қолтаңбалармен қорғаңыз, TTL және оқу кворумын енгізіңіз.
Content-based routing: 'service: limits/operator: XYZ/region: TR' түрінің кілттерін жариялау.
Жеке namespace: жеке префикстер/жабық қауымдастықтар үшін кілттер (серіктес оверлейлер).
Anti-poisoning: жазбаларды иелерінің қолтаңбаларымен валидациялау, жарияланым түйіндерінің беделі, rate-limit жарияланымдары.

6) Деректер модельдері және келісу

Event-sourcing + Pub/Sub: барлық маңызды өзгерістер өзгермейтін кілттері бар оқиғалар ретінде (idempotency-key).
CRDT (GCounter, OR-Set, LWW-register): көптеген қатысушылар өңдейтін конфигурациялар, рұқсаттар, кэшталатын лимиттер/котировкалар үшін.
Консенсус барлық жерде міндетті емес: анықтамалықтар мен метадеректер үшін «eventual consistency» жеткілікті; қаржылық операциялар үшін - қатаң қаржыландыру (сыртқы тізілім/блокчейн/нотариус).

7) QoS, SLO және метриктер

• p99 latency P2P-RPC ≤ 250-400 мс (өңіраралық ≤ 600 мс), success-rate ≥ 99. 5%.
• Pub/Sub end-to-end delay p95 ≤ 2 с.
• Relay-үлесі ≤ 30% (мақсаты - тікелей байланыстылығы ≥ 70%).
• Churn-тұрақтылығы: SLA деградациясы жоқ 20% -ға дейін пирлерді жоғалту.

• Connectivity: қол жеткізілетін пирлердің пайызы, тікелей қосылыстардың үлесі, көршілердің орташа саны.
• Path quality: RTT, Jitter, Packet loss; p95/p99 сервистік сыныптар бойынша.
• Throughput: ағындар бойынша орташа/ең жоғары өткізу қабілеті.
• Reliability: reconnect rate, RPC error rate, Pub/Sub reordering/drop.
• Discovery health: DHT hit/miss, кілтті толтыру уақыты, ескірген жазбалардың үлесі.
• Security: E2E шифрлау үлесі, жалған емес қолтаңбалар, rate аномалиялары.
• Cost: реле арқылы трафик (ГБ/тәулік), CTS per GB, CTS per RPC.

8) P2P қауіпсіздігі

Сәйкестігі және сенім: ұзақ мерзімді peer-ID, заңды мәніне байланыстыру (оператор/провайдер), сенімді кілттердің тіркелімі; қысқа өмір сүретін сессиялық кілттер.
Шифрлау: көліктік TLS 1. Жеке арналар үшін үстінен 3/Noise + E2E (Double-Ratchet, HPKE).
Авторизациялау: capability-токендер/макарондар (операцияларға және көлемге байланыстырылған), Pub/Sub топиктері бойынша ACL.
Анти-Sybil және спам: «тіркеу» тораптары үшін proof-of-authority, reputations/credit-limits, ашық қоғамдастықтар үшін кіріс капчалары/төлем кепілдіктері.
Арналарды теріс пайдалану: трафик бойынша circuit-breaker, RPC және publish-те leaky-bucket rate-limit, шулы пирлердің «greylisting».
Деректерді тексеру: оқиғаның қолтаңбалары, үлкен батчаларға арналған меркл-дәлелдер, idempotency-key бойынша дедуп.

9) Инженерлік паттерндер

RPC ұқсастығы: 'x-idempotency-key' + «at-least-once» жеткізу + қабылдағышта дедуп.
Backpressure: window-size ағындар бойынша, басымдықтар (ақшамен операциялар> телеметрия).
Partial failure tolerance: жылдам таймаут + жартылай жұмыс режимі (read-only, кэш-only, фич деградациясы).
Observability: p2p-хоп трассировкалары, корреляциялық ID, 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 және мемсип

Хабар тарату оқиғаларына арналған Gossip-желілер: анти-дупликация, диаметрін шектеу (random walk), жазылымдардың «жылжымалы терезелері».
Топика және саясат: «жария» және «жеке» тақырыптарды бөлу; жеке - тек ACL жазылушылары үшін.
Жеткізу: «at-least-once» кепілдігі + жазылушыларда дедупликация.

11) Сақтау және кэштеу

Снэпшоттар + журналдар: соңғы снапшоттан пирді жылдам суықтай бастау және оқиғалар журналын тарту.
Кэш саясаты: TTL/ETag/схемаларды нұсқалау; қолтаңбамен валидациялау.
Edge-кэш: super-peers «кэштеуші прокси» ретінде қол қоя отырып, күй кілттерін/бөліктерін сақтай алады.

12) Пайдалану, мониторинг және дашбордтар

• Connectivity %, relay %, DHT hit/miss, RPC success/latency p95/p99, Pub/Sub delay, error rate, churn.
• Супер-тораптар картасы (жүктеме, saturation, өңірлер бойынша кідірістер).

• Relay-үлес трендтері, трафик құны, «ыстық» топиктер, E2E-арналар үлесі, шабуылдар/аномалиялар.

• NAT traversal тиімділігі (түзулердің үлесі), CTS per GB/RPC, супер-тораптарды кеңейту жоспары, KPI комплаенс (логизация, сақтау).

13) Тестілеу және сапа

Chaos сценарийлері: супер түйіндерді% өшіру, жасанды шығындар/джиттер, Pub/Sub жүктемелері.
Interop-матрица: SDK/хаттаманың нұсқалары × NAT түрі × өңірлер.
Fuzzing протоколдары: кездейсоқ өрістер/өлшемдер, зиянды payload-лар (құмсалғышта).
Security-drills: пир кілтінің жылыстауы, суперторапты сындыру (сенім тізімін қайта басып шығару, кілттерді қайтарып алу).

14) Комплаенс және құқықтық аспектілер

Логикалау және өзгермейтіндігі: журналдардың хэш-тізбектері, timestamping, өңірлер бойынша сақтау (data residency).
Деректерге қол жеткізуді бақылау: минимизация, «тыныштықта» шифрлау, топиктегі DLP саясаты, пайдаланушы атрибуттарын псевдонимизациялау.
Жою/шектеу құқығы: редакциялаудың криптографиялық дәлелдемелері бар «tombstone-events» және «redaction-events» саясаты.
Аудит: сыртқы тексерулер үшін қол қойылған журналдардың экспорты.

15) Экономика және биллинг желісі

Шығындар моделі: × ГБ релелі-трафик, snapshot сақтау, супер-тораптар «жеткізуші тораптар» ретінде (compensation per GB/RPC).
Fair-usage: жарияланымдар мен RPC квоталары; ақылы «жеделдетілген» арналар/басымдықтар.
Тікелей арналарға ынталандыру: P2P-direct кезіндегі жеңілдіктер, желінің «жақсы азаматтары» үшін лимиттерді арттыру.

16) SLO/OKR үлгісі (тоқсан)

KR1 (байланыстылығы): 75% тікелей қосылыстарды ≥, DHT resolve p95 ≤ 300 мс.
KR2 (өнімділігі): p99 RPC ≤ 400 мс жаһандық; Pub/Sub p95 ≤ 2 с.
KR3 (сенімділік): RPC success ≥ 99. 7%; churn-түсуге төзімділігі 20%.
KR4 (Қауіпсіздік): ≥ бар каналдардың 95% E2E; 0 күрделі қолтаңба/ауыстыру инциденттері.
KR5 (Құны): 1 RPC-ге relay-трафик − 20% QoQ; CTS per GB −15% QoQ.

17) Playbook инциденттер (шпаргалка)

• Агрессивті hole-punch қосыңыз, STUN пулдарын ауыстырыңыз, супер-түйіндердің географиясын кеңейтіңіз, сыни топиктерді басымдылыққа енгізіңіз.

• Жарияланушылардың сенімді кілттерін қайта шығару, тексерулердің кворумын қосу, ескірген жазбаларды тазалау, жарияланымдарды күдікті пирлерден уақытша шектеу.

• Rate-limit + proof-of-work/fee-gate, сұр тізім, қолтаңбаның жаңа шектерімен overlay қайта жинау.

• Дереу шолу, «revoke-event» жариялау, тәуелдi iрiктер кiлттерiн ротациялау, ACL қайта есептеу.

18) Конфигурация үлгісі (псевдо-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) Енгізу чек-парағы

1. Құрамдастырылған топологияны таңдаңыз (келісім-шарттық топтар ішіндегі mesh + super-peers + DHT).
2. Негізгі өңірлерде бута-страпаларды және супер-тораптарды көтеріңіз, STUN/TURN қосыңыз.
3. Оқиға пішімдерін, қолтаңбаларды, ACL және e2e саясатын анықтаңыз.
4. Трассалар мен өлшемдерді қосыңыз (RTT, relay-%, DHT-latency, RPC success).
5. SLO/OKR тіркеп, burn-rate алертингін қосыңыз.
6. Chaos күнін өткізіңіз: өшіру, жоғалту, Pub/Sub жүктемесі.
7. Кілттерді ротациялауды, логтардың аудитін, ден қою рәсімін регламенттеңіз.

Қорытынды: экожүйедегі сауатты жобаланған P2P-желісі орталық шлюздерге тәуелділікті төмендетеді, алмасуды жеделдетеді және тұрақтылықты арттырады. QUIC, DHT, Pub/Sub, E2E-шифрлау, қатаң ACL және өлшенетін пайдалану (SLO/метрика) біріктіре отырып, сіз кеңейтілетін және қауіпсіз желілік матаны аласыз, онда әрбір қатысушы - пассивті клиент емес, толық құнды торап.