Originaltext: „Social Protocol ist aufgerollt!“ Was ist Farcaster? 》

Autor: ELEN

Farcaster Protocol ist ein weiteres führendes Produkt im SocialFi-Bereich, nachdem Lens Protocol ein Projekt der ehemaligen Coinbase-Führungskräfte Dan Romero und Varun Srinivasan ist. Es hat derzeit eine Investition von 30 Millionen US-Dollar unter der Leitung von A16Z erhalten.

Das Ziel von Farcaster besteht darin, ein vertrauenswürdiges neutrales Protokoll für das WEB3-Ökosystem bereitzustellen, das Benutzern den direkten Kontakt mit ihrem Publikum ermöglicht und Entwicklern gleichzeitig die freie Erstellung neuer Clients ermöglicht.

Der Gott Viafarcaster V ließ sich nieder

Das langfristige Ziel von Farcaster besteht darin, eine wichtige zugrunde liegende Infrastruktur im WEB3-Social-Track zu werden. Dies steht im Einklang mit der Ausrichtung des Lens-Protokolls. Das architektonische Design von Farcaster ist jedoch viel ausgefeilter als das Lens-Protokoll und versucht, diese Lücke zu schließen zwischen WEB2 und WEB3. Eine Strategie, um einen optimalen Gleichgewichtspunkt zu finden.

ViaBlockTurbo

Heute werfen wir einen tieferen Blick auf das Protokollschichtdesign und die ökologischen Anwendungsideen von Farcaster. Wenn Sie sich eingehend damit befassen möchten, können Sie sich den offiziellen Github ansehen:

https://github.com/farcasterxyz/protocol

Einführung in Farcaster

Soziale Netzwerke waren in den letzten 10 Jahren die am schnellsten wachsende Branche. Viele soziale Plattformen stellen Entwicklern APIs zur Verfügung, die es Entwicklern ermöglichen, neue Ökosysteme zu erstellen, beispielsweise verschiedene unterhaltsame Plug-Ins. In den letzten Jahren scheint es jedoch immer weniger Dinge zu geben, die Entwickler tun können, und verschiedene Zensuren machen Entwickler nicht mehr frei, manchmal sogar ohne Vorankündigung das Auskunftsrecht entzogen.

Farcaster ist ein vollständig dezentralisiertes Protokoll, das Entwicklern die Erstellung dezentraler Anwendungen für soziale Netzwerke erleichtert. Farcasters Definition von Dezentralisierung ist einfach: Wenn zwei Benutzer miteinander kommunizieren möchten, gibt es keine Möglichkeit, dies zu verhindern. Das heißt, Benutzer haben die volle Kontrolle über ihre Identität, ihre Daten und ihre sozialen Verbindungen. Entwickler können eine vollständig dezentrale soziale Anwendung ohne Einschränkungen durch Dritte oder sogar Netzwerke erstellen.

Diese Vision ist auch das, was Lens Protocol erreichen möchte. Wir können davon ausgehen, dass der größte Wert des zugrunde liegenden Protokolls darin besteht, die zugrunde liegende technische Implementierungsmethode eines sozialen Netzwerks bereitzustellen, sodass es nicht von Dritten kontrolliert wird. Ähnlich dem Wert von IPFS im dezentralen Speichermarkt.

Viafarcaster.network Farcaster-Architektur

Farcaster übernimmt eine On-Chain- und Off-Chain-Hybridarchitektur, um den Aufbau eines dezentralen Protokolls abzuschließen. Die Identität von Farcaster wird in der Ethereum-Kette gespeichert und nutzt Ethereum, um seine Sicherheit, Zusammensetzbarkeit und Konsistenz zu gewährleisten. Identitäten werden über Ethereum-Adressen kontrolliert und Off-Chain-Nachrichten werden über Ethereum-Konten signiert.

Die Daten des Benutzers werden verschlüsselt und über die Identität signiert und auf vom Benutzer kontrollierten Servern (Farcaster Hubs) gespeichert. Der Grund, warum die Daten nicht in der Kette gespeichert werden, liegt darin, dass die Abwicklungskosten in den meisten L1- und L2-Netzwerken zu hoch sind und die Geschwindigkeit zu hoch ist ist zu langsam.

Diese Architektur unterscheidet sich vom Design des LENS-Protokolls und berücksichtigt eher die tatsächlichen Bedürfnisse der Entwickler und ähnelt eher der Ausdrucksform von WEB2, wodurch die Kosten für das Benutzerlernen gesenkt werden Identität, Daten und soziale Beziehungen basieren auf Blockchain.

Konto

Farcaster-Konten ähneln Konten in pseudonymen sozialen Netzwerken wie Twitter oder Reddit, und Einzelpersonen können mehrere Konten gleichzeitig betreiben. Jedem Konto ist eine eindeutige Nummer zugeordnet, die Farcaster-ID oder Fid genannt wird. Eine Farcaster-ID kann von einer Ethereum-Adresse erhalten werden, indem man das Farcaster ID Registry (FIR) anruft. Diese Adresse wird Treuhandadresse genannt und kann Off-Chain- und On-Chain-Informationen im Namen des Kontos signieren. Benutzer können wählen, ob sie einen Farcaster-Namen oder einen F-Namen von der Farcaster Name Registry (FNR) erhalten möchten, die ihnen einen eindeutigen Namen wie @alice zuweist.

Es versteht sich, dass Fid eine On-Chain-Identität ist, während FNR eine sozial lesbare Identität ist. Wenn Fid die Wallet-Adresse ist, dann ist FNR ENS.

Signaturinformationen

Bei den Signaturinformationen handelt es sich um ein manipulationssicheres und selbstzertifiziertes Objekt, signiert von fid. Signaturinformationen stellen Benutzeraktionen dar, z. B. Posten, soziales Feedback (Kommentare/Retweeten) oder das Ändern von Kontoinformationen, z. B. Benutzernamen.

Signierte Nachrichten verfügen über Nachrichtenattribute, die eine gewisse Nutzlast enthalten. Die Nutzlast wird serialisiert, gehasht und mit einem gültigen Schlüsselpaar (z. B. Costody-Adresse) signiert. Der Umschlag enthält den Hashwert, die Signatur und den öffentlichen Schlüssel des signierenden Schlüsselpaars, mit dem jeder Empfänger die Signatur des FID überprüfen kann.

Nachrichten müssen mit RFC-8785 serialisiert, mit BLAKE2b gehasht und mit dem Ed25519-Signaturschema signiert werden. Jede Nachricht muss außerdem einen FID zum Abfragen der On-Chain-Treuhandadresse und einen Zeitstempel zum Sortieren enthalten.

Anwendung

Anwendungen sind die Programme, mit denen Menschen mit dem Farcaster-Netzwerk interagieren. Eine einfache Anwendung könnte aus einem eigenständigen Desktop- oder mobilen Client bestehen, der direkt mit Farcaster Hub kommuniziert. Es kann neue Nachrichten veröffentlichen und von anderen FIDs veröffentlichte Nachrichten anzeigen. Solche Anwendungen werden selbst gehostet und müssen mit einer Hosting-Adresse oder einem gültigen Signaturschlüssel instanziiert werden.

Komplexere Anwendungen fügen möglicherweise einen Proxy-Backend-Server hinzu, um die Daten des Hubs zu indizieren. Durch die Indizierung kann der Server Funktionen wie Suche, Algorithmus-Feed und Spam-Erkennung implementieren, deren Ausführung auf dem Hub schwierig oder teuer ist. Eine solche Anwendung kann durch die Speicherung von Schlüsseln auf dem Client selbst gehostet werden; sie kann delegiert werden, indem der Benutzer einen delegierten Signaturschlüssel angibt, oder durch die Verwaltung aller Schlüssel treuhänderisch verwaltet werden.

Naben

Der Hub ist ein ständig verfügbarer Server, der Signaturinformationen überprüft, speichert und repliziert. Der Benutzer wählt einen Hub aus und veröffentlicht seine URL mithilfe von FIR in der Kette. Ihre Follower können diese URL verwenden, um ihre Nachrichten zu finden und herunterzuladen. Gleichzeitig können Benutzer den Hub auch selbst betreiben oder Hosting-Dienste von Drittanbietern nutzen.

Farcasters Identität

Das Identitätssystem von Farcaster ermöglicht es, dass die Identität eines Benutzers die folgenden Merkmale aufweist:

Sicher und vollständig dezentralisiert. In sozialen Netzwerken leicht identifizierbar. Einfach einzurichten (schnell und kostengünstig). Wiederherstellbar (verstößt nicht gegen die Natur der Dezentralisierung).

Die Implementierung dieser Funktionen in einem Identitätssystem ist schwierig, da sie oft in Konflikt stehen. Beispielsweise ist es schwierig, ein dezentrales, vertrauenswürdiges Namenssystem zu haben (z. B. ob die Einzigartigkeit des Namenssystems gewährleistet werden soll).

Farcaster gleicht diese Funktionen durch zwei unabhängige Systeme aus. Das Farcaster ID Registry (FIR) vergibt neue ID-Nummern, sogenannte FIDs; das Farcaster Name Registry (FNR) vergibt neue Benutzernamen, sogenannte Fnames. Fids sind sichere, dezentrale Identifikatoren, die in jeder Nachricht vorhanden sind und vom Konzept her UUIDs ähneln.

FNames dienen hauptsächlich der FIR-Änderung, ersetzen FID beim Rendern und können jederzeit geändert werden. Die Aufteilung einer Identität in diese beiden Komponenten ermöglicht es uns, unsere Ziele zu erreichen, allerdings auf Kosten einer gewissen Komplexität des Systems. Beide Systeme implementieren außerdem einen Wiederherstellungsmechanismus, der den Verlust der Schlüsselpaare schützt, die Namen steuern, ohne die Dezentralisierung zu beeinträchtigen.

Farcaster-ID-Registrierung (FIR)

Farcaster-IDs sind numerische Bezeichner, ähnlich wie UUIDs. Wenn sie dem Benutzer angezeigt werden, wird ihnen ein Ausrufezeichen vorangestellt (zum Beispiel: !8098).

Ein FID stellt eine eindeutige Entität dar, beispielsweise eine Person oder eine Organisation. Jeder Verweis auf diese Entität muss ihre FID und nicht ihren Fname verwenden. Die Registrierungsgebühr für FID ist sehr niedrig und der Besitz bleibt lebenslang bestehen. FID-Verträge können in keiner Weise aktualisiert oder geändert werden.

Der FID beginnt bei 0 und wird bei jeder neuen Registrierung um 1 erhöht. Ein FID wird in der Kette als uint256 gespeichert und garantiert einen nahezu unbegrenzten Vorrat, da er auf ~10^77 erhöht werden kann.

Benutzer können FIR verwenden, um URLs zu konfigurieren, um den Speicherort ihrer Off-Chain-Informationen zu finden.

Farcaster-Namensregister (FNR)

Farcaster-Namen sind einzigartig, ähnlich wie Benutzernamen in anderen Netzwerken. Wenn sie dem Benutzer angezeigt werden, wird ihnen ein @-Symbol vorangestellt (zum Beispiel: @alice).

Fname hilft zusammen mit Profil-, Namens- und Verifizierungstokens dabei, eine Entität beim Surfen im Internet visuell zu identifizieren. Im Gegensatz zu fids ist fname in erster Linie lesbar und hat nichts mit den zugrunde liegenden, vom Benutzer erstellten Daten zu tun. Der Besitz von fname ist nicht dauerhaft und Benutzer müssen einige jährliche Gebühren zahlen. Die Verlängerung von fname kann 90 Tage vor Ablauf von fname durchgeführt werden. Abgelaufene Namen werden in einer niederländischen Auktion versteigert, wobei die Bieter eine jährliche Gebühr und eine Prämie ab 1.000 ETH zahlen müssen. Die Prämie verringert sich alle 8 Stunden um 10 %, bis sie 0 ETH erreicht.

Fnames sind NFTs, die von der Farcaster Name Registry nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ ausgegeben werden. Jeder Name muss mit dem regulären Ausdruck /^[a-z0-9][a-z0-9-]{0,15}$/ übereinstimmen. Sie verfügen über spezifische Eigenschaften, die sie in sozialen Netzwerken im Vergleich zu anderen Namespaces wie ENS nützlicher machen. Sie sind kostengünstiger in der Herstellung und im Besitz, aufgrund von Zeichensatzbeschränkungen weniger anfällig für homophone Angriffe und außerdem wiederherstellbar. Für Farcaster ist die Verwendung von fname nicht erforderlich. Benutzern steht es frei, andere Namespaces und deren FIDs zu verwenden.

Der Verzicht auf die Verwendung von fname wird keine großen Auswirkungen haben, da Farcaster auf fid basiert und alle Informationen und Verhaltensweisen eher auf fid als auf den Rahmen hinweisen. fnames können jederzeit geändert werden, ohne dass vorherige Abhängigkeitsinformationen verloren gehen.

Benutzernamenrichtlinie

Während der Beta-Phase können Benutzernamen kostenlos registriert werden und unterliegen einer einfachen Richtlinie. Der Zweck dieser Richtlinie besteht darin, zu verhindern, dass Namen von inaktiven Benutzern übernommen oder in böswilliger Absicht verwendet werden, um sich als andere auszugeben. Die Lösung dieses Problems lässt sich nicht einfach automatisieren und erfordert menschliches Urteilsvermögen. Die Benutzernamenrichtlinie basiert auf zwei Grundprinzipien:

Identitätsdiebstahl – Wenn Sie sich unter einem Benutzernamen registrieren, der einer bekannten Persönlichkeit oder Organisation des öffentlichen Lebens gehört, wird Ihr Name möglicherweise abgemeldet. Zum Beispiel @elonmusk, @vitalikbuterin, @google oder @whitehouse. Inaktivität – Wenn Sie einen Benutzernamen länger als 60 Tage lang nicht aktiv verwendet haben, kann Ihr Name auf Antrag eines anderen Benutzers oder nach unserem Ermessen abgemeldet werden.

Wir gehen davon aus, dass häufig ein manueller Eingriff erforderlich sein wird, da möglicherweise legitime Konflikte vorliegen. Sie haben beispielsweise @vitalik registriert und Vitalik Buterin hat sich nach Ihnen registriert und wollte diesen Namen. In diesem Fall stellen wir drei Fragen, um die Entscheidung zu leiten:

Ist dieser Benutzer auf Farcaster aktiv und engagiert? (Zum Beispiel, wenn er in den letzten Monaten qualitativ hochwertige Beiträge veröffentlicht hat.) Hat dieser Benutzer einen berechtigten Anspruch auf den Namen? (Zum Beispiel, wenn ihr Name auch Vitalik ist) Verfügt dieser Benutzer über ähnliche, aktive Konten in anderen Netzwerken? (Zum Beispiel, wenn sie vitalik und vitalik.ens auf Twitter haben).

Wenn die Antworten auf diese Fragen überwiegend „Ja“ lauten, behalten sie den Anspruch auf ihren Namen. Im Testnetz wird das Kernteam diesen Konflikt schlichten, und wir hoffen, mit der Annäherung an das Hauptnetz offiziell ein Managementsystem für dieses Problem zu etablieren. Wenn ein Name aufgrund eines Schiedsverfahrens zurückgezogen wird, erhält der Benutzer keine Rückerstattung.

Konto-Wiederherstellung

Wenn ein Benutzer den Schlüssel zu der Adresse verliert, die die ID und den Namen enthält, können die Farcaster-ID und der Name wiederhergestellt werden. Beide Verträge implementieren ein verzögertes Wiederherstellungssystem, das die Übertragung von Wiederherstellungsadressenanfragen an eine neue Adresse ermöglicht. Wenn die Depotadresse die Übertragung nicht innerhalb von drei Tagen storniert, kann die Wiederherstellungsadresse die Übertragung abschließen.

Benutzer können die Wiederherstellungsadresse auf eine andere Adresse in ihrer eigenen Wallet, eine mit Freunden geteilte Multisig-Adresse oder einen Wiederherstellungsdienst eines Drittanbieters festlegen. Benutzer können die Wiederherstellungsadresse auch jederzeit ändern. Das Eigentum bleibt dezentral, da die Wiederherstellungsadresse keine Übertragungen vornehmen kann, denen die Depotadresse nicht zustimmt.

Durch die Übertragung von Vermögenswerten an eine neue Treuhandadresse wird die Wiederherstellungsadresse gelöscht. Andernfalls könnte ein Benutzer einen Namen auf OpenSea erwerben, nur um den Vorbesitzer dann heimlich unter Verwendung seiner Wiederherstellungsadresse zurückfordern zu lassen.

Informationsverarbeitung

Bei der Informationsverarbeitung handelt es sich um den Prozess, durch den der Hub neue Nachrichten akzeptiert und den Status des Benutzers ermittelt. Benutzer senden für jede ihrer Aktionen Nachrichten an einen Hub. Wenn einem Benutzer eine URL gefällt, sie nicht gefällt und sie gefällt, werden drei Nachrichten generiert. Ein Hub, der alle Informationen empfängt, ermittelt den aktuellen Status der bevorzugten URLs des Benutzers.

Der Hub kann die ersten beiden Informationen verwerfen, um Platz zu sparen. Der Hub kann solche Nachrichten mithilfe einer Zusammenführungsoperation komprimieren, wodurch clientseitige Inkonsistenzen vermieden und Platz gespart werden. Nachrichten können unterschiedliche Regeln für ihre Zusammenführungsvorgänge haben. Beispielsweise können zwei „Gefällt mir“-Angaben eines Benutzers an denselben Benutzer zu einer zusammengefasst werden, zwei Antworten jedoch nicht.

Der Hub verliert möglicherweise einige Benutzerinformationen und gelangt in einen Fehlerzustand. Beispielsweise erhält es möglicherweise nur die erste „Gefällt mir“- und „Gefällt mir nicht“-Nachricht, wodurch der aktuelle Status auf „Gefällt mir nicht“ gesetzt wird. Der Zusammenführungsvorgang sollte es dem Staat ermöglichen, voranzukommen und Konsistenz zu erreichen, da fehlende Nachrichten erneut gesendet werden. Mit anderen Worten: Durch die Zusammenführung soll am Ende eine starke Konsistenz gewährleistet werden.

Hub erreicht dies durch die Implementierung einer Reihe von CRDTs für jeden Nachrichtentyp sowie die Codierung spezifischer Validierungs- und Zusammenführungsregeln. Diese Funktion macht Hubs hochverfügbar, da sie jederzeit offline geschaltet und jederzeit wiederhergestellt werden können, um synchronisiert zu werden. Formal ist unser CRDT-Set ein anonymes Delta-State-CRDT2, und jede Nachricht ist eine verbundene und irreduzible Aktualisierung des Sets.

Informationssortierung

Die Informationssammlung kann Signaturinformationen nach Zeitstempel sortieren und Zusammenführungskonflikte mit einer zuletzt geschriebenen Richtlinie lösen. Sie können jedoch keine perfekte Reihenfolge garantieren, da Zeitstempel anfällig für Taktabweichungen, Taktabweichungen und Spoofing durch böswillige Benutzer sind und aus verschiedenen Gründen kollidieren können. Anwendungen können gemischte Uhren verwenden, um perfekt geordnete Zeitstempel ohne Kollisionen zu erzeugen, aber wir können ihre Verwendung nicht erzwingen.

Stattdessen definieren wir ein Ordnungssystem für Nachrichten, das die Gesamtordnung sicherstellt, indem es Zeitstempel zur Bestimmung der anfänglichen Reihenfolge und Hashes zur Aufhebung von Kollisionen verwendet. Die vollständige Reihenfolge ist garantiert, da zwei Nachrichten nicht denselben Hashwert haben können, es sei denn, es handelt sich um dieselbe Nachricht. Zwei Nachrichten a und b können mit diesem Algorithmus verglichen werden:

Wenn a.timestamp>b.timestamp, dann ist a größer. Wenn a.timestamp < b.timestamp, dann ist b größer. wenn a.timestamp == b.timestamp

- Wenn a.hash>b.hash, dann ist a größer.

- Wenn a.hash < b.hash, dann ist b größer.

      - Ergebnis a.hash = b.hash, a == b

Zeitstempel werden als Zahlen verglichen, während Hashes als Zeichenfolgen verglichen werden. Da Zeichenfolgenvergleiche je nach Implementierung variieren, müssen wir bei unseren Vergleichsalgorithmen präzise sein. Wir glauben, dass zwei Hashwerte x und y durch den Vergleich jedes Zeichenpaars verglichen werden können:

Wenn alle Zeichenpaare gleich sind und x und y beide enden, dann x == y Wenn alle Zeichenpaare gleich sind und x zuerst terminiert, dann y>x Wenn ein anderes Zeichenpaar xC, yC angetroffen wird, dann Wenn ASCII( yC)>ASCII(xC), dann y>x

Informationsüberprüfung

Zusätzlich zu den nachrichtentypspezifischen Validierungen müssen alle Nachrichten die folgenden Validierungen bestehen:

message.timestamp ist der Systemzeit nicht mehr als 1 Stunde voraus. message.fid muss eine bekannte FID-Nummer im FIR sein. signerPubKey sollte ein gültiger verwalteter Unterzeichner oder eine delegierte Signatur für die Nachricht sein. fid hashFn(serializeFn(message)) muss mit Envelope.hash übereinstimmen, wobei hashFn eine Blake2B-Funktion ist und serializeFn eine JSON-Normalisierung durchführt. EdDSA_signature_verify(envelope.hash,velope.signerPubKey,velope.signature) sollte bestehen.

Besetzung

Bei Cast handelt es sich um von Benutzern erstellte öffentliche Informationen, die Text enthalten und auch in Medien, On-Chain-Aktivitäten oder andere Casts eingebettet werden können. Casts werden in einer zweistufigen Sammlung CRDT3 gespeichert, um Konflikte zwischen Nachrichten zu lösen.

Ein Cast kann über die CastAdd-Nachricht hinzugefügt werden, die im Add-Set des CRDT platziert wird. Jeder Cast wird durch seinen Hash-Wert indiziert, der garantiert eindeutig ist, es sei denn, die Casts sind identisch. Im weiteren Sinne kommt es nie zu Konflikten zwischen zwei Add-Nachrichten, es sei denn, sie sind identisch. In diesem Fall kann eine davon getrost verworfen werden.

Casts können über die CastRemove-Nachricht entfernt werden, die einen Verweis auf den Hash des Ziel-CastAdd enthält. Wenn diese Nachricht empfangen wird, wird das Ziel aus dem Add-Set entfernt, sofern es existiert, und das entfernte Ziel wird dem Rem-Set hinzugefügt. Konflikte zwischen Hinzufügungen und Löschungen werden mit der Remove-Wins-Regel behandelt, während Konflikte zwischen Löschungen mit der Last-Write-Wins-Regel behandelt werden, wobei im Falle eines Gleichstands auf die lexikografische Reihenfolge zurückgegriffen wird.

Information hinzufügen

Ein Cast Add kann Unicode-Text mit bis zu 320 Zeichen und zwei URIs mit bis zu 256 Zeichen enthalten. Der Client ist für die Dekodierung und gemeinsame Darstellung von URI und Text verantwortlich.

Eine Besetzung ohne übergeordnetes Element ist eine Besetzung der obersten Ebene und der Kunde sollte im Profil oder in der Chronik des Benutzers erscheinen. Eine übergeordnete Besetzung ist eine Antwort auf eine andere Besetzung, Web-URL oder ein On-Chain-Objekt und sollte in einem Thread angezeigt werden.

Umfragen bilden eine Reihe von Bäumen, wobei jeder Stamm eine Umfrage oder ein URI und jeder untergeordnete Knoten eine Antwortabfrage ist. Jeder Baum kann als Thread-Konversation gerendert werden. Der Baum ist garantiert aperiodisch, da der übergeordnete Knoten gehasht und signiert werden muss, bevor ein untergeordneter Knoten darauf verweisen kann. Alle Änderungen an den Daten des übergeordneten Knotens zerstören alle Beziehungen zu seinen untergeordneten Knoten.

Besetzungsinformationen müssen die folgenden Überprüfungsschritte bestehen.

Der Text muss <=320 gültige Unicode-Zeichen enthalten. Die Einbettung muss 0 bis 2 Elemente enthalten. Elemente müssen eine URI mit bis zu 256 Zeichen sein. Wenn ein übergeordnetes Element vorhanden ist, muss es eine gültige URI sein, die nicht mit der URI dieser Nachricht übereinstimmt (z. B. fid:/cast:).

Nachricht löschen

Cast Remove enthält lediglich einen Verweis auf den Hash von Cast Add. Es ermöglicht das dauerhafte Löschen des Casts und gleichzeitig das Löschen der Daten des ursprünglichen Casts.

Die Nachricht muss die folgenden Überprüfungsschritte bestehen:

message.data.body.hash darf nicht gleich message.envelope.hash sein. message.timestamp muss <= Systemuhr + 10 Minuten sein. message.data.fid muss eine bekannte FID im FIR sein

Zusammenführungsregeln

Wenn eine Add-Nachricht a empfangen wird, wenn r im Rem-Set vorhanden ist und r.data.body.hash gleich a.hash ist, wird a verworfen. Andernfalls fügen Sie a zum Additionssatz hinzu. Wenn eine Entfernungsnachricht r empfangen wird und im hinzugefügten Satz ein.hash gleich r.data.body.hash vorhanden ist, löschen Sie ihn. Wenn es ein r' im rem-set gibt, wobei r.data.body.hash gleich r'.data.body.hash ist, wenn r'>r, r' verwerfen, wenn r';

Aktionen

Eine Aktion ist eine öffentliche Operation, die von einem Benutzer an einem Ziel ausgeführt wird. Dabei kann es sich um einen anderen Benutzer oder eine Aktivität in der Kette handeln. Derzeit werden zwei Arten von Aktionen unterstützt: „Gefällt mir“ und „Folgen“. Das Protokoll kann problemlos erweitert werden, um neue Aktionen zu unterstützen. Benutzer können Aktionen rückgängig machen und wiederholen, indem sie das Aktivitätsattribut in der Nachricht umschalten. Konzeptionell ist jede Aktion eine Kante im sozialen Diagramm.

Die Aktion wird mithilfe des LWW-Element-Set CRDT verwaltet, was letztendliche Konsistenz garantiert. Konzeptionell gibt es eine einzige Sammlung, die alle Nachrichten speichert, und Konflikte werden durch Zeitstempel und lexikografische Hash-Reihenfolge gelöst. Das Hinzufügen erfolgt durch Erstellen einer Aktionsnachricht a, wobei „active“ auf „true“ gesetzt ist, während das Löschen durch Setzen von „active“ auf „false“ erfolgt. In beiden Fällen lautet die Logik zum Zusammenführen von Nachrichten zu Sätzen:

Wenn die Sammlung eine Aktion x enthält, stimmen ihr Typ, ihr Ziel-URI und ihre FID-Werte mit denen der eingehenden Aktion y überein. Wenn x>y, verwerfen Sie y; wenn x

verifizieren

Die Verifizierung ist ein wechselseitiger Eigentumsnachweis zwischen einem Farcaster-Konto und einer externen Entität. Durch die Verifizierung kann der Besitz von Ethereum-Adressen, bestimmten NFTs, anderen Social-Media-Konten und sogar Domainnamen nachgewiesen werden.

Bei der Verifizierung gibt es drei Kernkonzepte:

Aussagen, einschließlich Verweise auf Farcaster-Konten und externe Unternehmen. Ansprüche können gehasht werden, um für jeden Anspruch eine eindeutige Kennung zu erstellen. Nachweis der Direktionalität von einer externen Entität, die berechtigt ist, die Anfrage zu stellen und ihre Absicht zeigt, eine Verbindung zum Farcaster-Konto herzustellen. Nachweis der Direktionalität von einem Farcaster-Konto zur Annahme von Anfragen zur Verknüpfung eines Anspruchs mit einem Farcaster-Konto.

Autorisierung des Unterzeichners

Eine Unterzeichnerautorisierung ist eine Nachricht, die ein neues Schlüsselpaar autorisiert, Signaturen für ein Farcaster-Konto zu generieren.

Wenn ein FID erstellt wird, kann nur die Depotadresse Nachrichten in seinem Namen signieren. Benutzer möchten dieses Schlüsselpaar möglicherweise nicht auf jedes Gerät laden, da dies das Risiko einer Kontokompromittierung erhöht. Eine Depotadresse, auch Depotunterzeichner genannt, kann die Schlüsselpaare anderer sogenannter delegierter Unterzeichner autorisieren. Im Gegensatz zu behördlichen Unterzeichnern dürfen delegierte Unterzeichner nur Informationen außerhalb der Kette veröffentlichen und keine Vorgänge in der Kette durchführen.

Escrow-Unterzeichner generieren ECDSA-Signaturen auf der secp256k1-Kurve und können nur Autorisierungsinformationen des Unterzeichners veröffentlichen. Alle anderen Nachrichtentypen müssen von einem delegierten Unterzeichner signiert werden, der die EdDSA-Signatur auf Kurve255194 erstellt. Delegierte Signierer können verwendet werden, um neue Geräte oder sogar Drittanbieterdienste zum Signieren von Nachrichten für ein Konto zu autorisieren. Wenn ein delegierter Unterzeichner kompromittiert wird, kann er von ihm selbst, seinen Vorgängern in der Vertrauenskette oder einem beliebigen delegierten Unterzeichner widerrufen werden. Wenn ein Unterzeichner widerrufen wird, verwirft Hubs alle seine Signaturinformationen, da es keine Möglichkeit gibt, die Informationen des Benutzers von denen des Angreifers zu unterscheiden.

Benutzer können eine ID aufgrund einer Schlüsselwiederherstellung oder eines Wallet-Wechsels auch an eine neue Treuhandadresse übertragen. Oft ist es wünschenswert, den Verlauf zu bewahren, damit beide Treuhandadressen zu gültigen Treuhandunterzeichnern werden. Die Menge der gültigen Unterzeichner für eine ID bildet eine Reihe verschiedener Bäume. Die Wurzel jedes Baums ist eine historische Aufbewahrungsadresse und die Blätter sind delegierte Unterzeichner.

Der Unterzeichnersatz ist ein modifizierter Zweiphasensatz mit der Semantik „Löschen-Win“ und „Last-Write-Win“. Neue Informationen werden der Sammlung hinzugefügt, wenn sie von einem gültigen Vollmachtgeber oder Erziehungsberechtigten unterzeichnet sind. Löschungen werden akzeptiert, wenn Sie von Ihnen oder einem Vorfahren unterzeichnet haben. Sobald ein Unterzeichner entfernt wurde, kann er nicht mehr hinzugefügt werden und alle seine Nachkommen und Nachrichten werden verworfen.

Wenn zwei gültige Unterzeichner jeweils denselben delegierten Unterzeichner autorisieren, kommt es zu einem Satzkonflikt, der die Baumdatenstruktur zerstört. In diesem Fall behält die Sammlung die Nachricht mit dem höchsten Zeitstempel und lexikografischen Hash in der richtigen Reihenfolge bei.

Zersplitterung

Hubs können nur Daten für bestimmte Konten kopieren, was eine nützliche Eigenschaft für die Skalierung von Netzwerken ist. Wenn Farcaster so groß wird, dass ein einzelner Server die Replikation des gesamten Hub-Netzwerks nicht unterstützen kann, kann die Arbeitslast auf mehrere Hubs verteilt werden. Hub-Betreiber können auch die Synchronisierung von Daten für Benutzer vermeiden, die sich böswillig verhalten oder nicht mit dem Betreiber verbunden sind.

Die selektive Replikation bietet nur eine Teilansicht des Netzwerks. Wenn ein Hub Alices Daten synchronisiert, weiß er, dass sie auf einen von Bobs Beiträgen geantwortet und diesen mit „Gefällt mir“ markiert hat. Es erfährt jedoch weder den Inhalt von Bobs Beitrag noch die Tatsache, dass Bob ihre Antwort mochte und dann weiter antwortete. Eine App, die darauf abzielt, eine genaue Like-Zählung bereitzustellen und alle Antwortinformationen bereitzustellen, sollte so viele Benutzer wie möglich reproduzieren.