Tekst oryginalny: „Protokół społeczny został zwinięty!” Co to jest Farcaster? 》

Autor: ELEN

Farcaster Protocol to kolejny po Lens Protocol wiodący produkt na ścieżce SocialFi. Farcaster to projekt byłych dyrektorów Coinbase Dana Romero i Varuna Srinivasana. Obecnie otrzymał inwestycje o wartości 30 milionów dolarów pod przewodnictwem A16Z.

Celem Farcaster jest zapewnienie zaufanego, neutralnego protokołu dla ekosystemu WEB3, umożliwiającego użytkownikom bezpośredni kontakt z odbiorcami, a jednocześnie umożliwiającego programistom swobodne budowanie nowych klientów.

Bóg Viafarcaster V zadomowił się

Długoterminowym celem Farcaster jest stać się ważną infrastrukturą leżącą u podstaw ścieżki społecznościowej WEB3. Jest to zgodne z kierunkiem Lens Protocol. Jednakże projekt architektoniczny Farcaster jest znacznie bardziej wyrafinowany niż Lens Protocol i stanowi próbę wypełnienia luki pomiędzy WEB2 i WEB3.Strategia znalezienia optymalnego punktu równowagi.

ViaBlockTurbo

Dziś zagłębimy się w projektowanie warstwy protokołu Farcaster i myśli o zastosowaniach ekosystemu. Jeśli chcesz zgłębić temat, możesz odwiedzić oficjalne github:

https://github.com/farcasterxyz/protocol

Wprowadzenie do Farcastera

Sieci społecznościowe były najszybciej rozwijającą się branżą w ciągu ostatnich dziesięciu lat, wiele platform społecznościowych oferuje programistom API, które umożliwiają „wtórne tworzenie” i rozwijanie nowych ekosystemów, takich jak różne zabawne wtyczki na Twitterze. Jednak w ostatnich latach sytuacja wydaje się być inna, to, co programiści mogą zrobić, wydaje się coraz bardziej ograniczone, a ograniczenia API oraz różne rodzaje cenzury sprawiają, że programiści nie są już wolni, a czasami są pozbawiani dostępu bez żadnych powiadomień.

Farcaster to całkowicie zdecentralizowany protokół, który umożliwia programistom budowanie zdecentralizowanych aplikacji sieci społecznościowych. Definicja decentralizacji w Farcasterze jest bardzo prosta: gdy dwóch użytkowników chce się ze sobą komunikować, nie ma żadnej metody, która mogłaby temu zapobiec. Oznacza to, że użytkownicy mają pełną kontrolę nad swoją tożsamością, swoimi danymi i swoimi relacjami społecznymi. Programiści mogą złamać wszelkie ograniczenia ze strony osób trzecich, a nawet sieci, aby stworzyć całkowicie zdecentralizowaną aplikację społeczną.

Taka wizja jest również celem protokołu Lens, możemy uznać, że największą wartością podstawowego protokołu SocialFi jest zapewnienie całkowicie zdecentralizowanego technicznego podłoża dla sieci społecznościowej, która nie będzie kontrolowana przez żadną osobę trzecią. Podobnie jak wartość IPFS w rynku zdecentralizowanej pamięci.

Viafarcaster.network Architektura Farcastera

Farcaster przyjmuje mieszane podejście on-chain + off-chain do budowy zdecentralizowanego protokołu. Tożsamość Farcastera jest przechowywana na łańcuchu Ethereum i wykorzystuje Ethereum do zapewnienia bezpieczeństwa, kompozycji i spójności. Tożsamość jest kontrolowana przez adres Ethereum i podpisywana przez konto Ethereum, aby podpisać informacje poza łańcuchem.

Dane użytkownika są szyfrowane za pomocą podpisu tożsamości i przechowywane na serwerach kontrolowanych przez użytkownika (Hubs Farcastera), powód, dla którego dane nie są przechowywane na łańcuchu, to zbyt wysokie koszty rozliczeń na większości sieci L1 i L2 oraz zbyt niska prędkość.

Ta architektura różni się od projektu protokołu LENS, Farcaster bardziej uwzględnia rzeczywiste potrzeby programistów i bardziej przypomina formę działania mediów społecznościowych WEB2, zmniejszając koszty nauki dla użytkowników, ale Farcaster wciąż jest zdecentralizowany, tożsamość użytkownika, dane i relacje społeczne są oparte na blockchainie.

Konto

Konto Farcastera jest podobne do kont na pseudonimowych sieciach społecznościowych, takich jak Twitter czy Reddit, gdzie jednostka może jednocześnie obsługiwać kilka kont. Każde konto ma unikalny numer związany z nim, zwany ID Farcastera lub Fid. ID Farcastera można uzyskać poprzez wywołanie Rejestru ID Farcastera (FIR) z jednego adresu Ethereum. Adres ten nazywa się adresem przechowującym, który może podpisywać informacje off-chain i on-chain w imieniu konta. Użytkownicy mogą wybierać, aby uzyskać nazwę Farcastera lub fname z Rejestru Nazw Farcastera (FNR), który przyznaje im unikalną nazwę, taką jak @alice.

Można to zrozumieć, że Fid jest tożsamością on-chain, podczas gdy FNR to tożsamość czytelna społecznie. Jeśli Fid to adres portfela, to FNR jest jak ENS.

Informacje o podpisie

Informacje o podpisie to obiekt odporny na manipulacje i samoautoryzujący się, podpisywany przez fid. Informacje o podpisie reprezentują działania użytkownika, takie jak publikowanie, reakcje społeczne (komentarze/retweety) lub modyfikacje informacji o koncie, takie jak nazwa użytkownika.

Wiadomości o podpisie mają atrybuty wiadomości, które zawierają pewne ładunki (payload). Ładunki są serializowane, haszowane i podpisywane przez ważną parę kluczy (np. adres przechowujący). Envelope zawiera wartość hash, podpis i publiczny klucz pary podpisującej, który każdy odbiorca może użyć do weryfikacji podpisu fid.

Informacje muszą być serializowane zgodnie z RFC-8785, haszowane za pomocą BLAKE2b i podpisywane za pomocą schematu podpisu Ed25519. Każda informacja musi również zawierać fid do zapytania o adres przechowujący na łańcuchu oraz znacznik czasu do sortowania.

Aplikacja

Aplikacje to programy, które ludzie używają do interakcji z siecią Farcastera. Prosta aplikacja może obejmować samodzielnego klienta desktopowego lub mobilnego, który bezpośrednio łączy się z Hubem Farcastera. Może publikować nowe wiadomości i przeglądać wiadomości publikowane przez inne fidy. Takie aplikacje są samo-hostowane i muszą być zainicjowane za pomocą adresu przechowującego lub ważnego klucza podpisującego.

Bardziej skomplikowane aplikacje mogą dodać serwer zaplecza pośredniczącego, aby indeksować dane Huba. Indeksowanie pozwala serwerowi na realizację funkcji takich jak wyszukiwanie, algorytmiczne kanały i wykrywanie spamu, które są trudne do wykonania lub kosztowne na Hubie. Takie aplikacje mogą być realizowane poprzez przechowywanie klucza w kliencie; wymagając od użytkownika dostarczenia klucza podpisującego delegowanego; lub zarządzając wszystkimi kluczami, aby zrealizować hosting.

Hubs

Hub to serwer, który jest zawsze online, służący do weryfikacji, przechowywania i replikacji informacji o podpisach. Użytkownicy wybierają Hub i publikują swój URL na łańcuchu za pomocą FIR. Ich obserwujący mogą używać tego URL, aby znaleźć i pobrać ich wiadomości. Jednocześnie użytkownicy mogą również uruchamiać własny Hub lub korzystać z usług hostingu osób trzecich.

Tożsamość Farcastera

System tożsamości Farcastera sprawia, że tożsamość użytkowników ma następujące cechy:

Bezpieczna i całkowicie zdecentralizowana Łatwa do rozpoznania w sieciach społecznościowych Łatwe do zbudowania (szybkie i niskokosztowe) Odzyskiwalna (nie narusza cech decentralizacji)

Wdrażanie tych cech w systemie tożsamości jest wyzwaniem, ponieważ często są one sprzeczne. Na przykład, posiadanie zdecentralizowanego, zaufanego systemu nazw jest trudne (np. czy zapewnić unikalność systemu nazw).

Farcaster działa poprzez dwa niezależne systemy, aby zrównoważyć te cechy. Rejestr ID Farcastera (FIR) wydaje nowe numery ID, zwane fidami; Rejestr Nazw Farcastera (FNR) wydaje nowe nazwy użytkowników, zwane fnames. Fidy są bezpiecznymi, rozproszonymi identyfikatorami, które istnieją w każdej informacji, koncepcyjnie podobnymi do uuid.

Fnames są głównie modyfikowane przez FIR, zastępując fid podczas renderowania i mogą być zmieniane w dowolnym momencie. Rozdzielenie tożsamości na te dwa komponenty pozwala nam osiągnąć nasze cele, ale kosztem dodania pewnej złożoności do systemu. Te dwa systemy wdrażają również mechanizm odzyskiwania, który chroni klucze do kontroli nazw przed utratą, nie wpływając przy tym na decentralizację.

Rejestr ID Farcastera (FIR)

ID Farcastera to cyfrowy identyfikator, podobny do uuid. Gdy jest wyświetlany użytkownikowi, poprzedza go wykrzyknik (np.: !8098).

Jeden FID reprezentuje unikalny podmiot, taki jak osoba lub organizacja. Każda informacja odnosząca się do tego podmiotu musi używać jego fid, a nie fname. Opłata za rejestrację fidów jest bardzo niska i jest na całe życie. Umowy FID nie mogą być w żaden sposób aktualizowane lub modyfikowane.

FID zaczyna się od 0 i zwiększa się o 1 za każdym razem, gdy następuje nowa rejestracja. Fid jest przechowywany na łańcuchu w formie uint256, co zapewnia niemal nieskończoną podaż, ponieważ może być zwiększany do ~10^77.

Użytkownicy mogą używać FIR do konfigurowania URL, aby znaleźć lokalizację swoich informacji poza łańcuchem.

Rejestr Nazw Farcastera (FNR)

Nazwy Farcastera są unikalne, podobnie jak nazwy użytkowników w innych sieciach. Gdy są wyświetlane użytkownikowi, poprzedza je symbol @ (np.: @alice).

Fname, wraz z profilem, nazwą i znakiem weryfikacyjnym, pomaga intuitywnie zidentyfikować podmiot podczas przeglądania sieci. W przeciwieństwie do fidów, fname jest głównie czytelny i nie jest związany z danymi podstawowymi tworzonymi przez użytkownika. Własność fname nie jest trwała, użytkownicy muszą płacić pewne opłaty co roku. Odnowienie fname można przeprowadzić w ciągu 90 dni przed wygaśnięciem fname. Wygasłe nazwy będą wystawiane na aukcję w stylu holenderskim, a licytujący będą musieli zapłacić roczną opłatę oraz premię, zaczynając od 1000 ETH. Premia zmniejsza się o 10% co 8 godzin, aż osiągnie 0 ETH.

Fnames są NFT wydawanymi przez Rejestr Nazw Farcastera na zasadzie pierwszeństwa. Każda nazwa musi spełniać wyrażenie regularne /^[a-z0-9][a-z0-9-]{0,15}$/. Mają one specyficzne właściwości, które sprawiają, że są bardziej użyteczne w sieciach społecznych w porównaniu do innych przestrzeni nazw (takich jak ENS). Ich koszt emisji i posiadania jest niski, ze względu na ograniczenia zestawu znaków, są mniej podatne na ataki homofonowe, a także można je odzyskać. Farcaster nie wymusza korzystania z fname, użytkownicy mogą swobodnie korzystać z innych przestrzeni nazw oraz swoich fidów.

Rezygnacja z używania fname nie wpłynie znacząco, ponieważ Farcaster został zaprojektowany wokół fid, a każda informacja i akcja wskazuje na fid, a nie frame. Fnames mogą być zmieniane w dowolnym czasie, nie tracąc żadnych wcześniejszych informacji zależnych.

Polityka nazw użytkowników

W trakcie testów, nazwy użytkowników mogą być rejestrowane bezpłatnie i podlegają prostej polityce. Celem tej polityki jest zapobieżenie zajmowaniu nazw przez nieaktywnych użytkowników lub używaniu ich w sposób złośliwy, aby podszywać się pod innych. Rozwiązanie tego problemu nie jest łatwe do zautomatyzowania i wymaga ludzkiej oceny do wykonania. Polityka nazw użytkowników ma dwie zasadnicze zasady:

Rejestracja na miano - Jeśli zarejestrowana nazwa użytkownika należy do znanej osoby publicznej lub podmiotu, twoja nazwa może zostać anulowana. Na przykład, @elonmusk, @vitalikbuterin, @google lub @whitehouse. Nieaktywność - Jeśli nie aktywnie używasz nazwy użytkownika przez ponad 60 dni, twoja nazwa może zostać anulowana na żądanie innych użytkowników lub według naszej decyzji.

Oczekujemy, że często będzie potrzebna interwencja ludzka, ponieważ mogą wystąpić uzasadnione konflikty. Na przykład, zarejestrowałeś @vitalik, a Vitalik Buterin zarejestrował się po tobie i chce tej nazwy. W takim przypadku zadamy trzy pytania, aby poprowadzić decyzję:

Czy ten użytkownik jest aktywny i zaangażowany na Farcasterze? (np. jeśli opublikował wysokiej jakości posty w ciągu ostatnich kilku miesięcy). Czy ten użytkownik ma uzasadnione roszczenie do tej nazwy? (np. jeśli ich imię to również Vitalik). Czy ten użytkownik posiada podobne, aktywne konta w innych sieciach? (np. jeśli ma vitalik i vitalik.ens na Twitterze).

Jeśli odpowiedzi na te pytania są w większości pozytywne, będą utrzymywać swoje roszczenie do nazwy. W sieci testowej, zespół rdzeniowy będzie pośredniczyć w takich konfliktach, a my mamy nadzieję, że w miarę zbliżania się do głównej sieci, formalnie ustanowimy system zarządzania wokół tej kwestii. Jeśli nazwa zostanie odebrana w wyniku arbitrażu, użytkownik nie otrzyma zwrotu.

Odzyskiwanie konta

Jeśli użytkownik straci klucz do adresu, który posiada ID i nazwę, ID i nazwa Farcastera mogą być odzyskane. Oba te kontrakty wdrażają system opóźnionego odzyskiwania, który pozwala na przeniesienie adresu odzyskiwania na nowy adres. Jeśli adres przechowujący nie anulował transferu w ciągu trzech dni, adres odzyskiwania może zakończyć transfer.

Użytkownicy mogą ustawić adres odzyskiwania jako inny adres w swoim portfelu, jako wielopodpisowy współdzielony z przyjaciółmi lub jako usługę odzyskiwania osób trzecich. Użytkownicy mogą również zmieniać adres odzyskiwania w dowolnym momencie. Własność pozostaje zdecentralizowana, ponieważ adres odzyskiwania nie może przenosić adresu przechowującego bez zgody.

Przeniesienie aktywów na nowy adres przechowujący spowoduje anulowanie ustawienia adresu odzyskiwania. W przeciwnym razie, użytkownik może kupić nazwę na OpenSea, ale poprzedni właściciel może potajemnie odebrać ją za pomocą swojego adresu odzyskiwania.

Przetwarzanie informacji

Przetwarzanie informacji to proces, w którym Hub przyjmuje nowe wiadomości i ustala status użytkownika. Użytkownicy wysyłają wiadomości do Huba za każde swoje działanie. Jeśli użytkownik polubi URL, nie polubi go, a następnie znowu polubi, powstają trzy wiadomości. Hub, który otrzymał wszystkie te wiadomości, ustali obecny status URL, który użytkownik polubił.

Hub może zrzucić pierwsze dwie wiadomości, aby zaoszczędzić miejsce. Hub może używać operacji scalania do kompresji takich wiadomości, co unika niespójności w kliencie i oszczędza miejsce. Wiadomości mogą mieć różne zasady dotyczące operacji scalania. Na przykład, dwa polubienia jednego użytkownika mogą zostać skompresowane w jedno, podczas gdy dwa odpowiedzi nie mogą.

Hub może przegapić niektóre informacje użytkownika i ostatecznie znajdować się w błędnym stanie. Na przykład, może otrzymać tylko pierwsze polubienie i niepolubienie, co ustawia obecny stan na niepolubienie. Operacje scalania powinny pozwolić na rozwój stanu i osiągnięcie spójności, gdy brakujące wiadomości zostaną ponownie nadawane. Innymi słowy, scalanie powinno zapewnić ostateczną silną spójność.

Hub osiąga to, implementując zbiory CRDT dla każdego typu wiadomości, kodując specyficzne zasady weryfikacji i scalania. Ta cecha sprawia, że Hub jest bardzo dostępny, ponieważ mogą być offline w dowolnym czasie i zawsze mogą odzyskać synchronizację. Formalnie, nasze zbiory CRDT są anonimowymi zbiorami stanu Δ-CRDT2, każda wiadomość jest połączeniem na zbiorze i niepodzielnym aktualizowaniem.

Sortowanie informacji

Zbiory informacji mogą sortować podpisane informacje za pomocą znaczników czasu, aby rozwiązywać konflikty scalania zgodnie z zasadą ostatniego zapisu. Niemniej jednak nie mogą zapewnić doskonałego sortowania, ponieważ znaczniki czasu mogą być podatne na przesunięcia zegara, dryf zegara, oszustwa ze strony złośliwych użytkowników i mogą kolidować z różnych powodów. Aplikacje mogą używać zegarów mieszanych, aby generować znaczniki czasu o doskonałym sortowaniu, bez kolizji, ale nie możemy wymuszać ich użycia.

Zamiast tego definiujemy system sortowania dla wiadomości, określając początkowe sortowanie za pomocą znaczników czasu i używając wartości hash do rozwiązywania konfliktów, aby zapewnić całkowite sortowanie. Całkowite sortowanie jest gwarantowane, ponieważ dwie wiadomości nie mogą mieć tej samej wartości hash, chyba że są tą samą wiadomością. Dwie wiadomości a i b można porównać za pomocą tego algorytmu:

Jeśli a.timestamp>b.timestamp, to a jest większe. Jeśli a.timestamp < b.timestamp, to b jest większe. Jeśli a.timestamp == b.timestamp

- Jeśli a.hash>b.hash, to a jest większe.

- Jeśli a.hash < b.hash, to b jest większe.

- Jeśli a.hash = b.hash, a == b

Znaczniki czasu są porównywane jako liczby, podczas gdy wartości hash są porównywane jako ciągi. Ponieważ porównania ciągów mogą różnić się w różnych implementacjach, musimy być precyzyjni w algorytmie porównawczym. Uważamy, że dwa hashe x i y można porównać, porównując każdą parę znaków:

Jeśli wszystkie pary znaków są równe i x oraz y kończą się, wtedy x == y Jeśli wszystkie pary znaków są równe i x kończy się wcześniej, wtedy y>x Jeśli napotkano różną parę znaków xC, yC, wtedy jeśli ASCII(yC)>ASCII(xC), to y>x

Weryfikacja informacji

Oprócz specyficznej weryfikacji dla typów wiadomości, wszystkie wiadomości muszą przejść przez następującą weryfikację:

message.timestamp nie może być wcześniejszy niż systemowy czas o więcej niż 1 godzinę. message.fid musi być znanym numerem fid w FIR. signerPubKey powinien być ważnym podpisującym dla message.fid lub delegowanym podpisującym hashFn(serializeFn(message)) musi pasować do envelope.hash, gdzie hashFn jest funkcją Blake2B, a serializeFn wykonuje normalizację JSON. EdDSA_signature_verify(envelope.hash, envelope.signerPubKey, envelope.signature) powinno przejść.

Casty

Cast to publiczne informacje stworzone przez użytkownika, które zawierają tekst, a także mogą zawierać wbudowane media, aktywności on-chain lub inne Casty. Casty są przechowywane w dwuetapowym zbiorze CRDT3, który rozwiązuje konflikty między wiadomościami.

Casty mogą być dodawane za pomocą wiadomości CastAdd, która jest umieszczana w zbiorze add-set CRDT. Każdy Cast jest indeksowany przez swój hash, chyba że Cast jest ten sam, w przeciwnym razie hash jest gwarantowany jako unikalny. Co do zasady, dwa wiadomości dodające nigdy nie będą kolidować, chyba że są takie same, w takim przypadku jeden może być bezpiecznie odrzucony.

Casty mogą być usuwane za pomocą wiadomości CastRemove, która zawiera odniesienie do hash CastAdd. Gdy ta wiadomość jest odbierana, jeśli cel istnieje, zostaje usunięty z add-set, a usunięcie jest dodawane do rem-set. Konflikty między dodawaniem i usuwaniem są rozwiązywane za pomocą reguły Remove-Wins, podczas gdy konflikty między usunięciem są rozwiązywane za pomocą reguły Last-Write-Wins, w przypadku remisu powracając do sortowania leksykograficznego.

Dodawanie informacji

Cast Add może zawierać tekst unicode o maksymalnej długości 320 znaków i dwa URI o maksymalnej długości 256 znaków. Klient odpowiada za dekodowanie i renderowanie URI oraz tekstu razem.

Cast bez rodzica jest górnym Castem, który klienci powinni wyświetlać na profilu użytkownika lub na osi czasu. Casty z rodzicami są odpowiedzią na inny cast, adres URL w sieci lub obiekt on-chain i powinny być wyświetlane w wątku.

Głosowanie tworzy drzewa, gdzie każdy korzeń to głos lub URI, a każdy węzeł potomny to odpowiedź na głos. Każde drzewo można renderować jako wątek konwersacji. Drzewa są gwarantowane jako acykliczne, ponieważ przed wskazaniem na nie, węzeł rodzica musi być zhaszowany i podpisany. Jakiekolwiek zmiany danych węzła rodzica zniszczą wszystkie powiązania z jego węzłami potomnymi.

Informacje o Cast muszą przejść przez następujące kroki weryfikacji.

Tekst musi zawierać <=320 ważnych znaków unicode embed musi zawierać od 0 do 2 pozycji Pozycja musi być maksymalnie 256-znakowym URI Jeśli istnieje rodzic, musi być to ważny URI, różny od URI tej wiadomości (np. fid:/cast:).

Usuwanie informacji

Cast Remove zawiera tylko odniesienie do hash Cast Add. Pozwala to na trwałe usunięcie Casta, jednocześnie usuwając dane oryginalnego Castu.

Wiadomość musi przejść przez następujące kroki weryfikacji:

message.data.body.hash musi być różny od message.envelope.hash. message.timestamp musi <= systemowy zegar + 10 minut message.data.fid musi być znanym numerem fid w FIR.

Reguły scalania

Gdy otrzymana jest wiadomość dodawania a, jeśli w rem-set istnieje r, a r.data.body.hash jest równe a.hash, to a jest odrzucane. W przeciwnym razie a jest dodawane do zbioru dodawania. Gdy otrzymana jest wiadomość usunięcia r, jeśli w zbiorze dodawania istnieje a.hash równe r.data.body.hash, to jest usuwane. Jeśli w rem-set istnieje r', gdzie r.data.body.hash jest równe r'.data.body.hash, jeśli r' >r, odrzuca r'; jeśli r'

Akcje

Akcja to publiczna operacja użytkownika na celu, którym może być inny użytkownik lub aktywność on-chain. Obecnie wspierane są dwa rodzaje operacji: polubienia i obserwacje. Protokół może być łatwo rozszerzany, aby wspierać nowe Akcje. Użytkownicy mogą cofać i ponownie wykonać akcje, zmieniając atrybut aktywności w wiadomości. Koncepcyjnie każda akcja to krawędź w grafie społecznym.

Akcja jest zarządzana przez CRDT LWW-Element-Set, który zapewnia ostateczną spójność. Koncepcyjnie istnieje pojedynczy zbiór do przechowywania wszystkich wiadomości, konflikty są rozwiązywane za pomocą znaczników czasu oraz leksykograficznej kolejności hasha. Dodawanie odbywa się poprzez zbudowanie wiadomości akcji z aktywnym a, a usuwanie poprzez ustawienie aktywności na fałsz. W obu przypadkach logika scalania wiadomości do zbioru jest następująca:

Jeśli w zbiorze istnieje Akcja x, której typ, cel Uri i wartość fid są takie same jak nadchodzącej akcji y. Jeśli x>y, odrzuć y; jeśli x

Weryfikacja

Weryfikacja to dwukierunkowy dowód posiadania między kontem Farcastera a zewnętrznymi podmiotami. Weryfikacja może być używana do dowodzenia posiadania adresu Ethereum, konkretnego NFT, innych kont w mediach społecznościowych, a nawet domen.

Weryfikacja ma trzy podstawowe koncepcje:

Deklaracje, które obejmują odniesienia do konta Farcastera i zewnętrznych podmiotów. Deklaracje mogą być haszowane, aby stworzyć unikalny identyfikator dla każdego roszczenia. Kierunkowe dowody od zewnętrznych podmiotów, które są upoważnione do składania roszczeń, pokazując ich intencje związane z kontem Farcastera. Kierunkowe dowody od konta Farcastera, akceptujące prośby o powiązanie roszczenia z kontem Farcastera.

Upoważnienie sygnatariusza

Upoważnienie sygnatariusza to wiadomość, która upoważnia nową parę kluczy do generowania podpisów dla konta Farcastera.

Gdy fid jest wybijany, tylko adres przechowujący może w jego imieniu podpisywać wiadomości. Użytkownicy mogą nie chcieć ładować tej pary kluczy na każde urządzenie, ponieważ zwiększa to ryzyko kompromitacji konta. Adres przechowujący, zwany także podpisującym przechowującym, może upoważnić inne pary kluczy, zwane podpisującymi delegowanymi. W przeciwieństwie do podpisujących regulacyjnych, podpisujący delegowani mogą tylko publikować informacje poza łańcuchem, nie mogą wykonywać żadnych operacji on-chain.

Podpisujący przechowujący generuje podpis ECDSA na krzywej secp256k1 i może tylko publikować informacje upoważnione przez sygnatariusza. Wszystkie inne typy wiadomości muszą być podpisane przez podpisującego delegowanego, który tworzy podpis EdDSA na krzywej curve255194. Podpisujący delegowani mogą być używani do upoważnienia nowych urządzeń, a nawet usług osób trzecich do podpisywania wiadomości w imieniu konta. Jeśli podpisujący delegowany zostanie skompromitowany, może zostać unieważniony przez siebie, swoich przodków w łańcuchu zaufania lub jakiegokolwiek podpisującego przechowującego. Gdy podpisujący zostanie unieważniony, Hubs odrzucą wszystkie jego podpisane informacje, ponieważ nie ma sposobu na odróżnienie informacji użytkownika od informacji atakującego.

Użytkownicy mogą również przenieść jeden id na nowy adres przechowujący z powodu odzyskiwania kluczy lub zmiany portfela. Zwykle chcą zachować historię, więc oba adresy przechowujące stają się ważnymi podpisującymi. Zbiór ważnych sygnatariuszy dla jednego id tworzy szereg różnych drzew. Korzeń każdego drzewa jest historycznym adresem przechowującym, a liście to podpisujący delegowani.

Zbiór sygnatariuszy to zmodyfikowany dwuetapowy zbiór, który ma semantykę usuwania-wygrywa i ostatniego zapisu-wygrywa. Jeśli nowe informacje są podpisywane przez ważnego delegata lub opiekuna, są dodawane do zbioru. Jeśli usunięte informacje są podpisywane przez siebie lub przodków, są akceptowane. Gdy podpisujący zostanie usunięty, nie można go ponownie dodać, a wszystkie jego potomne i wiadomości zostaną odrzucone.

Jeśli dwóch ważnych sygnatariuszy upoważnia tego samego podpisującego delegowanego, wystąpi konflikt zbioru, co zniszczy strukturę danych w postaci drzewa. W takim przypadku zbiór zachowa wiadomość z najwyższym znacznikiem czasu i leksykograficznym hashem, uporządkowaną według kolejności.

Slicing

Hubs mogą kopiować tylko dane określonych kont, co jest przydatną cechą dla rozwoju sieci. Jeśli Farcaster rozwinie się na tyle, że jedna serwer nie będzie w stanie obsłużyć kopiowania całej sieci Hub, obciążenie może być rozdzielone na wiele Hubów. Operatorzy hubów mogą również unikać synchronizacji danych dla użytkowników, którzy mają złośliwe zachowania lub nie są związani z operatorem.

Selektywna replikacja może dostarczyć tylko częściowy widok sieci. Jeśli Hub synchronizuje dane Alice, będzie wiedział, że odpowiedziała i polubiła post Boba. Nie będzie jednak wiedział o treści postu Boba ani o tym, że Bob polubił jej odpowiedź, a następnie kontynuował rozmowę. Aplikacja, która ma na celu zapewnienie dokładnego liczenia polubień i dostarczenia wszystkich informacji o odpowiedziach, powinna synchronizować użytkowników tak bardzo, jak to możliwe.