WEBOVÝ SOCIÁLNÍ PROTOKOL PEER-TO-PEER
TLDR: příliš dlouhé; nečetl jsem
- Solcial je budován tak, aby uživatelům poskytoval prostředí co nejbližší platformám sociálních médií Web2 a zároveň využíval technologie Web3.
- Jednou z překážek, se kterou se potýká každá platforma založená na blockchainu, jsou poplatky uživatelů. S cílem eliminovat uživatelské poplatky za operace nesouvisející s tokeny a zároveň zachovat soukromí a konsensus buduje Solcial vrstvu peer-to-peer (P2P) ukotvenou v Solaně a vystavěnou nad libp2p, která poskytuje obsah (kanály, lajky atd.) prostřednictvím selfhostingu a replikace peerů.
- Vyvinuli jsme také speciální typ uzlu, který má stejný vnější protokol jako typická desktopová nebo mobilní aplikace, s přidanými optimalizacemi navrženými tak, aby zvládl desítky tisíc souběžných peerů, nazvaný Beacon Nodes. Beacons jsou v podstatě sadou pinningových služeb, které zachovají obsah uživatelů, když autoři přejdou do režimu offline, a zpřístupní jej ostatním uživatelům; veškerý obsah uživatelů je uložen na IPFS a je k němu přistupováno prostřednictvím vrstvy P2P, aniž by se spoléhalo na cenzurovatelné servery nebo brány.
Úvod
Toto je první příspěvek ze série poznámek popisujících, jak vnitřní fungování protokolu Solcial zajišťuje jeho jedinečné vlastnosti odolnosti vůči cenzuře při zachování rozumného výkonu výměny dat.
Topologie sítě
Uzly komunikují přes veřejný internet a vytvářejí překryvnou síť specifickou pro Solcial pomocí upravené verze protokolu HyparView¹.
Každý uzel udržuje seznam aktivních partnerů o velikosti log2(N)+1,. kde N je odhadovaná velikost celé sítě. Hodnota N se získává z blockchainu zjištěním počtu dosud přihlášených uživatelských účtů a je pravidelně aktualizována podle toho, jak počet uživatelů roste. Spojení s aktivními peery jsou stabilní, obousměrná a trvalá a jsou to uzly, se kterými se komunikuje přímo během drbů nebo jiné p2p aktivity. Každý uzel také udržuje seznam pasivních peerů o velikosti 6⋅(log2(N)+1), které slouží jako záložní peery pro případ, že se některý z aktivních peerů odpojí nebo přestane reagovat. Základním protokolem pro spojení mezi aktivními peery je QUIC² se šifrováním NOISE, vše pohání libp2p³.
Překonávání NAT (Network address translator traversal - je v počítačových sítích způsob navázání a správy spojení pomocí IP protokolu přes síťové prvky, které provádějí NAT (překlad síťových adres) se provádí pomocí tří metod, které se používají v závislosti na síťových okolnostech peera. První metodou je použití IPv6 místo IPv4, kdykoli je to možné, protože v takovém případě není potřeba NAT, nicméně podle statistik je na IPv6⁴ pouze necelých 40 % internetu.
Záložním mechanismem je použití automatického NATu pomocí protokolu identity libp2p, který se ptá ostatních uzlů v síti na viditelnou adresu našeho počítače. Tato adresa, která je iniciována peerem stojícím za NATem, je již zaregistrována v jejich směrovači k cílovému stroji, nicméně existují okolnosti, kdy to nefunguje, pak se vracíme ke třetí a nejspolehlivější, ale nákladné možnosti.
Třetí možností je použití protokolu libp2p circuit relay⁵, který napodobuje fungování protokolu TURN⁶ tím, že má zprostředkující uzel, který předává pakety mezi dvěma peery za NAT. Tuto roli mohou převzít majákové uzly a některé peery s veřejnými IP, které se rozhodnou být relay s nastavenými limity. Více o majákových uzlech se dozvíte později v tomto příspěvku.
Identita peera
Peeryjsou identifikováni pomocí svého veřejného klíče ve formě multihash⁷, který se rovná veřejnému klíči adresy jejich peněženky na Solaně, která je registrována ve smlouvě Solcial on-chain. Jediný způsob, jak převzít danou veřejnou identitu peera, je vlastnit tajný klíč páru klíčů ED25519.
Tento pár klíčů se také používá k vytvoření šifrovaných kanálů pro předávání všech zpráv mezi peery a také jako způsob ověření pravosti zpráv, které jsou pravděpodobně vytvořeny vlastníkem peněženky.
Overlay členství
Peerům s veřejnými klíči, které nejsou zaregistrováni v řetězci, nebude umožněno připojit se k Overlay (překryvné) síti HyparView a tím budou automaticky vyloučeni z peer-to-peer sítě Solcial.
Všichni peery, které se chtějí připojit k p2p síti Solcial, zašlou zprávu JOIN jednomu ze zaváděcích uzlů (některé z těchto zaváděcích uzlů jsou zároveň majákovými uzly) na téma /solcial/public. Zavedení témat do HyparView je jednou z našich úprav původního dokumentu.
Každý uzel, který obdrží požadavek JOIN od peera, nejprve ověří, že multihash existuje na řetězci a je spojen s účtem Solcial, poté odešle zprávu FORWARDJOIN jednomu ze svých aktivních peerů s aktivní náhodnou procházkou nastavenou na 3, ty zase tuto zprávu rozšíří všem svým aktivním peerům, přičemž zvýší aktuální počet hopů o jeden, dokud nedosáhne 3 hopů. Jedná se o zmírnění DDoS útoků proti zaváděcím uzlům a také o účinnou decentralizační techniku, která má co nejvíce rozšířit a náhodně rozdělit konektivitu mezi uzly.
Každý uzel, který se nachází v okruhu 3 skoků od původního příjemce JOIN, odešle zprávu NEIGHBOR původnímu žadateli o JOIN a vytvoří mezi nimi aktivní trvalé spojení.
Pravidelně každých 15 sekund budou uzly vysílat zprávu SHUFFLE náhodnému aktivnímu peeru s náhodným vzorkem svých aktivních a pasivních peerů a nastaví délku náhodné procházky této zprávy na 4. Tím je zajištěno, že všechny peery v síti mají vždy čerstvé informace o ostatních peerech, které mohou uložit do svého pasivního zobrazení pro účely opravy sítě, kdykoli některý z jejich aktivních peerů přestane reagovat nebo se explicitně odpojí.
Efektivní drby (Gossiping)
Šíření zpráv mezi peery se účastní pouze aktivní peery. Aktivní peery tvoří překryvnou síť nad veřejným internetem a v grafu konektivity mezi uzly existují cykly. Abychom umožnili efektivní šíření zpráv mezi peery v síti, musíme zaprvé minimalizovat duplicitní šíření zpráv mezi peery a zadruhé najít nejoptimálnější trasu pro zprávy.
Toho dosáhneme pomocí algoritmu Epidemic Broadcast Trees⁸, který vytvoří minimální rozprostírající se strom mezi peery rozdělením peerů do skupiny uzlů eager-push a uzlů lazy push. Eager-push uzly dostanou zprávy vždy přeposlány, jakmile je některý uzel přijme.
Lazypush uzly dostávají periodicky, každých 500 ms, dávku ID zpráv, které viděl aktuální uzel. Kdykoli uzel zjistí, že v dávce lazy-push je ID zprávy, která nebyla přijata od jeho nadřazeného uzlu, obnoví spojení (GRAFT) a obnoví svůj status active-push. To představuje mechanismus opravy minimálního rozpínacího stromu v případě, že jeden z uzlů vypadne a vytvoří se nesouvislé grafy. Zprávy GRAFT obnovují plnou konektivitu sítě.
Kdykoli se zjistí, že přijatá zpráva je duplikátem dříve přijaté zprávy z aktivního uzlu, pak je spojení s tímto uzlem považováno za cyklus v grafu a je transformováno na Lazy-Push zasláním zprávy PRUNE.
Dalším případem pro ořezání aktivního spojení a jeho nahrazení spojením ze seznamu líných je situace, kdy zjistíme, že počet hopů, které zpráva urazila, aby k nám dorazila přes líný uzel, je menší než 4 hopy zprávy od horlivého aktivního partnera. To tvoří algoritmus optimalizace stromu vysílání.
Šíření obsahu
Zprávy šířené prostřednictvím protokolu p2p popsaného v předchozích částech jsou zprávy IPFS Bitswap⁹ s CID obsahu vytvořeného uživateli Solcial. Abychom lépe pochopili, jak se v systému Solcial využívá Bitswap a IPFS, popišme nejprve strukturu uživatelského profilu.
Každý uživatelský účet v síti má něco, co se nazývá index profilu. Tento index ukazuje na CID nejnovějších verzí jejich obsahu. Index je nakonec konzistentní sekvence CRDT, která tvoří neměnný záznam operací provedených účtem.
Profilový index si lze představit jako propojený seznam, kde každý prvek ukazuje na CID předchozího prvku a je rovnocennými partnery akceptován jako další prvek v pořadí, pouze pokud je podepsán soukromým klíčem vlastníka účtu. Vysokoúrovňový logický příklad kanálu profilu zveřejněného v tomto formátu vypadá takto:
{
“author”: “12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT”,
“prev”: “QmYtUc4iTCbbfVSDNKvtQqrfyezPPnFvE33wFmutw9PBBk”,
“action”: “append-feed-post”,
“timestamp”: “2022–01–11T15:58Z”,
“params”: {
“content”: “QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb”
“enckey”: “z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq”
},
“signature”: “2Lpnvt23H6qHswCNPmwCCUSas7YNP[…]jV1dC9qdNPR4zDqsCuBX”
}
Takový záznam má vlastní CID a je vysílán jako objekt IPFS PB-DAG¹⁰ do překryvného tématu /solcial/content HyparView. Tento záznam je propojen se svým předchozím záznamem a jakýmkoli dalším obsahem rekurzivním dotazem na propojené CID mohou uživatelé získat celou historii a obsah účtu.
Tento objekt je nejprve ověřen jakýmkoli přijímajícím partnerem, pokud se podpis obsahu shoduje s veřejným klíčem autora. V případě neúspěšného ověření podpisu je odesílající peer trvale vykázán z aktuálního uzlu pro porušení protokolu. Úspěšným ověřením podpisu se obsah rozšíří mezi všechny ostatní peery, kteří mají zájem o obsah, jehož autorem je tento účet.
Pokud takovýto CID peer obdrží, je přidán do protokolu operací autora. Součet všech operací provedených autorem tvoří aktuální stav profilu.
Ve výchozím nastavení každý uzel připíná a osazuje obsah svého vlastního účtu a obsah svých přátel. Existují speciální peery, které vytváříme jako součást naší infrastruktury a kterým říkáme beacon nodes a které jsou jako běžné uživatelské peery, až na to, že se zajímají o obsah všech uživatelů a slouží jako jakási služba IPFS pro připínání veškerého obsahu v případě, že jsou všechny současné seedery offline. Představte si je jako uzly, které jsou přítelem všech. Síť může fungovat i bez nich, ale poskytují další vrstvu dostupnosti obsahu.
Přístup ke čtení
Každý v p2p překryvné vrstvě Solcial se může dotazovat, stahovat a poskytovat libovolný uživatelský obsah vysíláním zpráv IWANT a IHAVE Bitswap do tématu /solcial/contents CID kořenového indexu nejvyšší úrovně účtu a poté rekurzivně žádat všechny propojené CID.
Počáteční synchronizace účtu nebo získání nejnovějších záznamů účtu se dosáhne vysíláním zprávy HEAD do tématu /solcial/sync, kde ostatní peeři, kteří jsou seedery (včetně beacon uzlů), odpovídají s CID nejnovějšího obsahu, o kterém vědí. Překlad mezi uživatelskými hesly a veřejnými klíči uživatelů se provádí dotazem na blokový řetězec Solana.
Pole předchozího záznamu lze použít k vyřešení konfliktních HEAD a k rozhodnutí o nejnovějším záznamu.
Přístup k zápisu
Aby mohl uživatel zapisovat do protokolu účtu, musí vlastnit soukromý klíč páru klíčů ED25519, který odpovídá jeho ID účtu. Díky vlastnictví tohoto klíče je uživatel schopen vygenerovat platný podpis záznamu, který připojuje do protokolu a který nebude odmítnut ostatními partnery v síti.
Privilegovaný přístup k obsahu
Některý obsah odeslaný uživateli je určen pouze pro vybranou skupinu příjemců, například kanály s předplatným úrovně 1 nebo 2. V případě, že je obsah odeslán uživateli, je určen pouze pro vybranou skupinu příjemců. Tyto příspěvky jsou nejprve zašifrovány pomocí symetrického šifrovacího klíče AES-256. Hash tohoto klíče je připojen k metadatům obsahu v původním příspěvku.
Klíč je šířen náhodné podmnožině způsobilých peerů prostřednictvím šifrovaného kanálu NOISE vytvořeného během handshake libp2p. Autor příspěvku se může rozhodnout, že umožní, aby se tohoto schématu výměny klíčů účastnily také majákové uzly, aby byl proces pro všechny uživatele téměř okamžitý, ale nemusí, pokud se domnívá, že jeho obsah je mimořádně citlivý. Když chce oprávněný uživatel dešifrovat obsah, pošle do překryvného tématu /solcial/keyexchange zprávu GETKEY s hashem šifrovacího klíče.
Všechny peery vlastnící tento klíč, které jsou online, zkontrolují oprávněnost peera pro získání tohoto klíče dotazem na blockchain a ověří, zda uživatel vlastní požadované tokeny pro přístup k obsahu. Po úspěšném ověření je klíč předán žádajícímu peerovi pomocí přímého spojení quic/noise (rychlý šum), které obchází drbací protokol.
Podpora platformy
Tento peer to peer protokol pro obsah odolný proti cenzuře je k dispozici pouze pro desktopové a mobilní klienty a není k dispozici přes webové rozhraní. Důvodem jsou omezení prohlížeče. Prohlížeče jsou ze své podstaty navrženy jako konzumenti obsahu hostovaného na serverech a jejich bezpečnostní model zakazuje přijímat náhodná připojení z jiných počítačů.
Webová verze bude téměř vždy centralizovaná vzhledem ke způsobu fungování prohlížečů a k tomu, že životnost karty prohlížeče je krátká, a veškerý obsah vytvořený prostřednictvím webového rozhraní bude zrcadlen na p2p uzly majáku. Jakýkoli obsah spotřebovaný webovým klientem bude kopií obsahu p2p. P2P je zdrojem pravdy.
Základní technický stack je implementován pomocí Rustu, libp2p s vazbami na React Native a Tauri¹¹.
[1] Leitao, Joao, José Pereira a Luis Rodrigues. "HyParView: A membership protocol for reliable gossip-based broadcast (Protokol členství pro spolehlivé vysílání založené na drbech)."
[2] https://en.wikipedia.org/wiki/QUIC
[4] https://www.google.com/intl/en/ipv6/statistics.html
[5] https://docs.libp2p.io/concepts/circuit-relay/
[6] https://datatracker.ietf.org/doc/html/rfc5766
[7] https://docs.libp2p.io/reference/glossary/#multihash
[8] Leitao, Joao, Jose Pereira a Luis Rodrigues. "Epidemic broadcast trees." 2007 26th IEEE International Symposium on Reliable Distributed Systems (SRDS 2007). IEEE, 2007.
[9] https://docs.ipfs.io/concepts/bitswap/
[10] https://github.com/ipld/ipld/blob/master/specs/codecs/dag-pb/spec.md
O projektu Solcial
Solcial je decentralizovaná sociální síť, která dává uživatelům sílu webu3 tím, že umožňuje lidem vzájemně komunikovat bez obav z cenzury a tvůrcům obsahu umožňuje spravedlivou odměnu podle tržní hodnoty.
Kontaktujte nás
Telegram: https://t.me/solcial
Discord: https://discord.gg/solcial
Twitter: https://twitter.com/solcialofficial
Blog: http://blog.solcial.io/
Webové stránky: https://solcial.io
E-mail: [email protected]
Linktree: https://linktr.ee/solcial
