WEB - SKALOWALNY SPOŁECZNY PEER-TO-PEER PROTOKÓŁ
TLDR:
- Solcial jest tworzony w celu zapewnienia użytkownikom doświadczenia jak najbardziej zbliżonego do platform mediów społecznościowych Web2, przy jednoczesnym wykorzystaniu wszystkich zalet Web3 technologii.
- Jedną z przeszkód, z którymi zderza się każda blockchain platforma, są prowizje. Aby je wyeliminować, prowizje za operacje niezwiązane z tokenami, zachowując jednocześnie prywatność i konsensus, Solcial buduje warstwę peer-to-peer (P2P) przywiązaną w Solanie i zbudowaną na bazie libp2p, która dostarcza treści (kanały, polubienia itp.) poprzez self-hosting i peer replikacje.
- Opracowaliśmy również specjalny typ węzła, który ma ten sam protokół zewnętrzny, co typowa aplikacja komputerowa lub mobilna, z dodanymi optymalizacjami zaprojektowanymi do obsługi dziesiątek tysięcy peerów, zwany Beacon Nodes. Beacony to zasadniczo zestaw usług przypinania, które zachowują treści użytkowników, gdy twórcy przechodzą w tryb offline i udostępniają je innym użytkownikom; cała zawartość użytkownika jest przechowywana w IPFS i dostępna za pośrednictwem warstwy P2P bez polegania na podlegających cenzurze serwerach lub bramach.
Wstęp
Jest to pierwszy post z serii notatek, które opisują w jaki sposób wewnętrzne działanie protokołu Solcial nadaje mu wyjątkowe właściwości odporności na cenzurę, przy jednoczesnym zachowaniu rozsądnej wydajności wymiany danych.
Topologia sieci
Węzły (nodes) komunikują się przez publiczny Internet, tworząc przy użyciu zmodyfikowanej wersji protokołu HyparView¹sieć nakładek (overlay sieć) specyficzną dla Solcial.
Każdy węzeł utrzymuje listę aktywnych peerów o rozmiarze log2(N)+1, gdzie N jest szacowanym rozmiarem całej sieci. Wartość N jest pobierana z blockchainu poprzez znalezienie liczby kont użytkowników zarejestrowanych do tej pory i jest okresowo aktualizowana wraz ze wzrostem liczby użytkowników. Połączenia z aktywnymi peerami są stabilne, dwukierunkowe i trwałe i są to węzły, z którymi komunikują się bezpośrednio podczas plotkowania lub innej aktywności p2p. Każdy węzeł utrzymuje również listę pasywnych peerów o rozmiarze 6⋅(log2(N)+1), które są używane jako zapasowe peery w przypadku, gdy którykolwiek z aktywnych peerów rozłączy się lub przestanie odpowiadać .Podstawowym protokołem dla połączeń między aktywnymi peerami jest QUIC² z szyfrowaniem NOISE, wszystkie obsługiwane przez libp2p³.
Obejście NAT uzyskuje się za pomocą trzech metod, które są używane w zależności od warunków sieciowych peeru. Pierwsza metoda polega na używaniu IPv6 zamiast IPv4, gdy tylko jest to możliwe, ponieważ w tym przypadku nie ma potrzeby stosowania NATów, jednak według statystyk tylko mniej niż 40% internetu korzysta z IPv6⁴.
Mechanizmem awaryjnym jest użycie AutoNAT poprzez wykorzystanie identity protokołu libp2p, który pyta inne węzły w sieci o widoczny adres naszej maszyny. Adres ten, inicjowany przez peera poza NAT, jest już zarejestrowany z jego routerem na maszynie docelowej, jednak istnieją okoliczności, w których to nie działa, wtedy wracamy do trzeciej i najbardziej niezawodnej, ale drogiej opcji.
Trzecią opcją jest użycie protokołu libp2p circuit relay⁵, który imituje działanie protokołu TURN⁶ poprzez posiadanie węzła pośredniego, który przekazuje pakiety między dwoma peerami poza NAT-ami. Tę rolę mogą przejąć węzły nawigacyjne i niektóre peery z publicznymi adresami IP, które decydują się na bycie przekaźnikami ze skonfigurowanymi limitami. Więcej o węzłach beaconów w dalszej części tego postu.
Identyfikacja peerów
Peery są identyfikowani za pomocą ich klucza publicznego w postaci multihash⁷, który jest równy kluczowi publicznemu ich adresu portfela na Solanie, który jest zarejestrowany w kontrakcie w sieci Solcial. Jedynym sposobem przyjęcia danego publicznego identyfikatora peera jest posiadanie tajnego klucza pary kluczy ED25519.
Ta para kluczy służy również do ustanawiania zaszyfrowanych kanałów dla wszystkich wiadomości przesyłanych między peerami, a także do weryfikacji autentyczności wiadomości, które prawdopodobnie są tworzone przez właściciela portfela.
Członkostwo overlay
Peery z kluczami publicznymi nie zarejestrowanymi w łańcuchu nie będą mogli dołączyć do overlaju sieci HyparView, a tym samym zostaną automatycznie wykluczeni z sieci peer-to-peer Solcial.
Wszyscy peery, którzy chcą dołączyć do Solcial p2p, wyślą wiadomość JOIN do jednego z węzłów ładowania początkowego (niektóre z tych węzłów ładowania początkowego są również węzłami typu beacon) w temacie /solcial/public. Wprowadzenie tematów do HyparView jest jedną z naszych modyfikacji oryginalnego dokumentu.
Każdy węzeł otrzymujący żądanie JOIN od peera najpierw zweryfikuje, że multihash istnieje w łańcuchu i jest powiązany z kontem Solcial, a następnie wyśle wiadomość FORWARDJOIN do jednego ze swoich aktywnych peerów z aktywnym krokiem losowym ustawionym na 3, one z kolei przekażą tę wiadomość do wszystkich aktywnych peerów, zwiększając bieżącą liczbę przeskoków o jeden, aż osiągnie 3 przeskoki. Jest to łagodzenie ataków DDoS na węzły ładowania początkowego, a także skuteczna technika decentralizacji w celu maksymalnego rozproszenia i randomizacji połączeń między węzłami.
Każdy węzeł, który znajduje się w odległości 3 przeskoków od początkowego JOIN odbiorcy, wyśle komunikat NEIGHBOR do początkowego JOIN żądającego, ustanawiając między nimi aktywne trwałe połączenie.
Okresowo co 15 sekund węzły będą rozsyłać wiadomość SHUFFLE do losowego aktywnego peera z losową próbką aktywnych i pasywnych peerów i ustawią długość losowego kroku tej wiadomości na 4. Zapewnia to, że wszyscy peery w sieci zawsze mają świeże informacje o inne peery, które mogą przechowywać w widoku pasywnym w celu naprawy sieci, gdy którykolwiek z ich aktywnych peerów przestaje odpowiadać lub wyraźnie rozłącza się.
Wydajne wiadomości błyskawiczne
Tylko aktywni peery uczestniczą w rozpowszechnianiu wiadomości między peerami. Aktywni peery tworzą overlay sieć w publicznym Internecie, a na wykresie połączeń między węzłami występują cykle. Aby umożliwić wydajne wiadomości błyskawiczne pomiędzy peerami w sieci, musimy najpierw zminimalizować propagację zduplikowanych wiadomości pomiędzy peerami, a po drugie znaleźć najbardziej optymalną trasę dla wiadomości.
Osiąga się to za pomocą algorytmu Epidemic Broadcast Trees⁸, który tworzy minimalne drzewo rozpinające pomiędzy peerów, dzieląc peerów na grupę eager-push węzłów i lazy push węzłów. Eager-push węzły zawsze otrzymują komunikaty przekazywane dalej, gdy tylko zostaną odebrane przez dowolny węzeł.
Węzły typu lazy push otrzymują okresowo, co 500 ms, partię identyfikatorów komunikatów widzianych przez bieżący węzeł. Za każdym razem, gdy węzeł zauważy, że w paczce lazy-push znajduje się identyfikator wiadomości, który nie został odebrany z jego węzła nadrzędnego, odbuduje (GRAFT) połączenie i przywróci jego active-push stan. Stanowi to minimalny mechanizm naprawy drzewa opinającego w przypadku, gdy jeden z węzłów ulegnie uszkodzeniu i powstaną rozłączne grafy. Wiadomości GRAFT przywracają pełną łączność sieciową.
Za każdym razem, gdy odebrana wiadomość okaże się duplikatem wcześniej odebranej wiadomości z aktywnego węzła, połączenie z tym węzłem jest traktowane jako cykl na grafie i przekształcane w Lazy-Push przez wysłanie wiadomości PRUNE.
Innym przypadkiem oczyszczenia aktywnego połączenia i zastąpienia go jednym z listy lazy jest zaobserwowanie, że liczba przeskoków, które przebyła wiadomość, aby dotrzeć do nas przez węzeł lazy, jest mniejsza niż 4 przeskoki niż w przypadku wiadomości od eager active peera. To tworzy algorytm optymalizacji drzewa rozgłoszeniowego.
Rozpowszechnianie treści
Wiadomości wysyłane poprzez protokoł p2p, opisany w poprzednich sekcjach, to wiadomości IPFS Bitswap⁹ z identyfikatorami CID treści produkowanymi przez użytkowników Solcial. Aby lepiej zrozumieć, w jaki sposób Bitswap i IPFS są wykorzystywane w Solcial, najpierw opiszmy strukturę profilu użytkownika.
Każde konto użytkownika w sieci ma coś, co nazywa się indeksem profilu. Ten indeks wskazuje CID najnowszych wersji ich treści. Indeks jest CRDT ostatecznie spójnej sekwencji, który tworzy niezmienny dziennik operacji wykonywanych przez konto.
Indeks profilu można traktować jako połączoną listę, w której każdy element wskazuje CID poprzedniego elementu i jest akceptowany przez peerów jako kolejny element w kolejce tylko wtedy, gdy jest podpisany kluczem prywatnym właściciela konta. Logiczny przykład wysokiego poziomu kanału profilu opublikowanego zakodowany w tym formacie wygląda tak:
{
“author”: “12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT”,
“prev”: “QmYtUc4iTCbbfVSDNKvtQqrfyezPPnFvE33wFmutw9PBBk”,
“action”: “append-feed-post”,
“timestamp”: “2022–01–11T15:58Z”,
“params”: {
“content”: “QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb”
“enckey”: “z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq”
},
“signature”: “2Lpnvt23H6qHswCNPmwCCUSas7YNP[…]jV1dC9qdNPR4zDqsCuBX”
}
Taki wpis ma swój własny identyfikator CID i jest emitowany jako IPFS PB-DAG¹⁰ obiekt do /solcial/content HyparView overlay tematu. Ten wpis jest powiązany z poprzednim wpisem, a wszelkie dodatkowe treści poprzez rekurencyjne zapytania połączone z CID, użytkownicy mogą uzyskać całą historię i zawartość konta.
Ten obiekt jest najpierw weryfikowany przez każdego odbierającego peera, jeśli podpis treści jest zgodny z kluczem publicznym autora. W przypadku nieudanej weryfikacji podpisu peer-nadawca zostaje trwale wykluczony z bieżącego węzła za naruszenie protokołu. Pomyślna weryfikacja podpisu propaguje treść do wszystkich innych peerów zainteresowanych treścią stworzoną przez to konto.
Gdy taki CID zostanie odebrany przez peera, zostanie on dodany do dziennika operacji autora. Suma wszystkich operacji wykonanych przez autora stanowi aktualny stan profilu.
Domyślnie każdy węzeł przypina i wysyła własną zawartość konta i zawartość konta swoich przyjaciele. Istnieją specjalne peery, które budujemy w ramach naszej infrastruktury, które nazywamy węzłami beacon i są jak zwykli peery, z wyjątkiem tego, że są zainteresowani zawartością wszystkich i służą jako Społecznie-specyficzny IPFS serwis przypinania dla wszystkich treści w przypadku, gdy wszyscy obecni seedy są offline. Pomyśl o nich jako o węzłach, które są przyjaciółmi wszystkich. Sieć może działać bez nich, jednak zapewniają dodatkową warstwę dostępności treści.
Dostęp do odczytu
Każdy użytkownik Solcial p2p overlay może wysyłać zapytania, pobierać i udostępniać dowolne treści użytkownika, emitując wiadomości IWANT i HAVE Bitswap do tematu /solcial/content z identyfikatorem CID indeksu głównego najwyższego poziomu konta, a następnie rekursywnie żądać wszystkich połączonych identyfikatorów CID.
Początkową synchronizację konta lub pobranie najnowszych wpisów na koncie uzyskuje się poprzez rozesłanie wiadomości HEAD do tematu /solcial/sync, gdzie inne peery, które są seederami (w tym węzły beacon), odpowiadają CID najnowszej znanej im zawartości. Tłumaczenie między nazwą użytkownika a kluczami publicznymi użytkownika odbywa się poprzez zapytanie w blockchainie Solana.
Poprzednie pole wpisu może być użyte do rozwiązania konfliktów HEAD i podjęcia decyzji o najnowszym wpisie.
Dostęp do zapisu
Aby móc zapisywać w dzienniku konta, użytkownik musi posiadać klucz prywatny pary kluczy ED25519, który odpowiada identyfikatorowi jego konta. Posiadając ten klucz, użytkownik jest w stanie wygenerować prawidłowy podpis wpisu, który dołącza do dziennika, który nie zostanie odrzucony przez innych peerów w sieci.
Uprzywilejowany dostęp do treści
Niektóre treści publikowane przez użytkowników są przeznaczone tylko dla wybranej grupy odbiorców, na przykład kanały subskrypcji poziomu 1 lub 2. Posty te są najpierw szyfrowane przy użyciu symetrycznego klucza szyfrowania AES-256. Hash tego klucza jest dołączony do metadanych treści w oryginalnym poście.
Klucz jest rozpowszechniany do losowego podzbioru uprawnionych peerów przez zaszyfrowany kanał NOISE, założony podczas libp2p porozumienie. Autor postu może zezwolić węzłom beacon również na udział w tym schemacie wymiany kluczy, aby proces ten był niemal natychmiastowy dla wszystkich użytkowników, ale nie musi tego robić, jeśli uważają, że ich zawartość jest bardzo wrażliwa. Gdy uprawniony użytkownik chce odszyfrować zawartość, wysyła komunikat GETKEY do /solcial/keyexchange overley ze skrótem klucza szyfrowania.
Wszyscy peery będący w posiadaniu tego klucza, którzy są w trybie online, sprawdzą uprawnienia partnera do uzyskania tego klucza, wysyłając zapytanie do blockchainu i weryfikując, czy użytkownik posiada wymagane tokeny umożliwiające dostęp do treści. Po pomyślnej weryfikacji klucz jest przesyłany do żądającego peera za pomocą połączenia typu direct quic/noise, które omija gossip protokół.
Wsparcie platformy
Ten protokół peer-to-peer dla treści odpornych na cenzurę jest dostępny tylko dla klientów stacjonarnych i mobilnych i nie jest dostępny przez web interfejs. Wynika to z ograniczeń przeglądarki. Przeglądarki są z natury zaprojektowane jako konsumenci treści hostowanych na serwerach, a ich model bezpieczeństwa zabrania akceptowania losowych połączeń z innych komputerów.
Wersja internetowa będzie prawie zawsze scentralizowana ze względu na sposób działania przeglądarek i krótki czas życia karty przeglądarki, a wszelkie treści tworzone za pośrednictwem interfejsu internetowego będą odzwierciedlane w sieci p2p przez węzły beacon. Wszelkie treści używane przez web klienta będą kopią p2p. P2P to źródło prawdy.
Bazowy stack techniczny jest implementowany przy użyciu Rust, libp2p z wiązaniem do React Native and Tauri¹¹.
[1] Leitao, Joao, José Pereira, and Luis Rodrigues. “HyParView: A membership protocol for reliable gossip-based broadcast.”
[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, and 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
Czym jest Solcial
Solcial to zdecentralizowana sieć społecznościowa, która ma na celu dać użytkownikom całą moc Web3, dająca możliwość interakcję ze sobą bez obawy o cenzurę i umożliwiając uczciwe, według wartości rynkowej, nagrodzenie dla twórców treści.
Skontaktuj się z nami
Telegram: https://t.me/solcial
Twitter: https://twitter.com/solcialofficial
Discord: https://discord.com/invite/3EpaAbcRPp
Blog: https://blog.solcial.io/
Web: https://solcial.io
Email: [email protected]
Linktree: https://linktr.ee/solcial
