Web3 ソーシャルプロトコル Farcaster プロトコルの詳細説明: V 神を住み着かせる魔法は何ですか?

原文：「ソーシャルプロトコルが巻き上がった！」ファーキャスターとは何ですか？ 》
作者: エレン
Farcaster Protocolは、Lens Protocolに次ぐSocialFiトラックのもう1つの主要製品です。Farcasterは、元Coinbase幹部のDan Romero氏とVarun Srinivasan氏のプロジェクトであり、現在A16Zが主導して3,000万米ドルの投資を受けています。
Farcaster の目標は、WEB3 エコシステムに信頼できる中立的なプロトコルを提供し、ユーザーが視聴者と直接連絡できるようにしながら、開発者が自由に新しいクライアントを構築できるようにすることです。
 ヴィアファルキャスターV神が住み着いた
Farcaster の長期的な目標は、WEB3 ソーシャル トラックの重要な基盤インフラストラクチャになることです。これは、Lens Protocol の方向性と一致しています。ただし、Farcaster のアーキテクチャ設計は、Lens Protocol よりもはるかに洗練されており、ギャップを埋める試みが採用されています。 WEB2とWEB3の間で最適なバランスポイントを見つける戦略。
ブロックターボ経由
今日は、Farcaster のプロトコル層設計とエコロジカルなアプリケーションのアイデアを詳しく見ていきます。詳しく知りたい場合は、公式 github をチェックしてください。
https://github.com/farcasterxyz/プロトコル
 ファーキャスターの紹介
ソーシャル ネットワークは、過去 10 年間で最も急速に成長した業界であり、多くのソーシャル プラットフォームが開発者に API を提供し、開発者が Twitter 上のさまざまな楽しいプラグインなどの新しいエコシステムを開発できるようにしています。しかし、近年では、API の制限やさまざまな検閲により、開発者が自由にできることは、場合によっては予告なく行われることも少なくなってきているようです。アクセスする権利を剥奪されます。
Farcaster は、開発者が分散型ソーシャル ネットワーク アプリケーションを構築することを容易にする、完全に分散型のプロトコルです。 Farcaster の分散化の定義はシンプルです。2 人のユーザーが相互に通信したい場合、これを防ぐ方法はありません。つまり、ユーザーは自分のアイデンティティ、データ、社会的つながりを完全に制御できます。開発者は、サードパーティやネットワークの制限を受けることなく、完全に分散化されたソーシャル アプリケーションを構築できます。
このビジョンは、Lens Protocol が達成したいことでもあり、SocialFi の基盤となるプロトコルの最大の価値は、サードパーティによって制御されないように、完全に分散化されたソーシャル ネットワークの基盤となる技術的実装方法を提供することであると考えられます。分散ストレージ市場における IPFS の価値と同様です。
 Viafarcaster.network ファーキャスター アーキテクチャ
Farcaster は、オンチェーン + オフチェーンのハイブリッド アーキテクチャを採用し、分散型プロトコルの構築を完了します。 Farcaster の ID はイーサリアム チェーンに保存され、イーサリアムを活用してセキュリティ、構成可能性、一貫性を確保します。 ID はイーサリアム アドレスを通じて制御され、オフチェーン メッセージはイーサリアム アカウントを通じて署名されます。
ユーザーのデータは、ID を介して暗号化および署名され、ユーザーが制御するサーバー (Farcaster ハブ) に保存されます。データがチェーン上に保存されない理由は、ほとんどの L1 および L2 ネットワークの決済コストと速度が高すぎるためです。遅すぎます。
このアーキテクチャは LENS プロトコルの設計とは異なり、開発者の実際のニーズをより考慮しており、WEB2 ソーシャル メディアの表現形式により似ており、ユーザーの学習コストを削減します。アイデンティティ、データ、社会的関係はブロックチェーンに基づいています。
アカウント
Farcaster アカウントは、Twitter や Reddit などの仮名ソーシャル ネットワークのアカウントに似ており、個人が同時に複数のアカウントを運用できます。各アカウントには、Farcaster ID または Fid と呼ばれる固有の番号が関連付けられています。 Farcaster ID は、Farcaster ID Registry (FIR) を呼び出すことでイーサリアム アドレスから取得できます。このアドレスはエスクロー アドレスと呼ばれ、アカウントに代わってオフチェーンおよびオンチェーンの情報に署名できます。ユーザーは、Farcaster 名レジストリ (FNR) から Farcaster 名または fname を取得することを選択でき、FNR によって @alice などの一意の名前が発行されます。
Fid はオンチェーン ID であるのに対し、FNR はソーシャルで読み取り可能な ID であることが理解できます。 Fid がウォレット アドレスの場合、FNR は ENS です。
署名情報
署名情報は、fid によって署名された、改ざん防止された自己認証オブジェクトです。署名情報は、投稿、ソーシャル フィードバック (コメント/リツイート)、またはユーザー名などのアカウント情報の変更などのユーザー アクションを表します。
署名付きメッセージにはメッセージ属性があり、これには何らかのペイロードが含まれます。ペイロードはシリアル化され、ハッシュされ、有効なキー ペア (コストディ アドレスなど) によって署名されます。エンベロープにはハッシュ値、署名、署名鍵ペアの公開鍵が含まれており、受信者はこれを使用して fid の署名を検証できます。
メッセージは、RFC-8785 を使用してシリアル化し、BLAKE2b を使用してハッシュし、Ed25519 署名スキームを使用して署名する必要があります。各メッセージには、オンチェーンエスクローアドレスを照会するための fid と、並べ替えのためのタイムスタンプも含まれている必要があります。
応用
アプリケーションは、Farcaster ネットワークと対話するために使用されるプログラムです。単純なアプリケーションは、Farcaster Hub と直接通信するスタンドアロンのデスクトップまたはモバイル クライアントで構成されている場合があります。新しいメッセージを公開したり、他の FID によって公開されたメッセージを表示したりできます。このようなアプリケーションは自己ホスト型であり、ホスティング アドレスまたは有効な署名キーを使用してインスタンス化する必要があります。
より複雑なアプリケーションでは、ハブのデータにインデックスを付けるためにプロキシ バックエンド サーバーを追加する場合があります。インデックス作成により、サーバーは検索、アルゴリズム フィード、スパム検出などの機能を実装できますが、これらの機能はハブ上で実行するのが難しく、コストがかかります。このようなアプリケーションは、クライアントにキーを保存することによって自己ホストすることができ、ユーザーに委任された署名キーの提供を要求することによって委任することも、すべてのキーを管理することによってエスクラウドにすることもできます。
ハブ
ハブは、署名情報を検証、保存、複製する常時接続サーバーです。ユーザーはハブを選択し、FIR を使用してその URL をチェーン上に公開します。フォロワーはこの URL を使用してメッセージを検索し、ダウンロードできます。同時に、ユーザーは自分でハブを実行したり、サードパーティのホスティング サービスを使用したりすることもできます。
 ファーキャスターの正体
Farcaster の ID システムにより、ユーザーの ID に次の特性を持たせることができます。
 安全で完全に分散化されている ソーシャルネットワークで簡単に識別できる セットアップが簡単（迅速かつ安価） 回復可能（分散化の性質に違反しない）
これらの機能は競合することが多いため、アイデンティティ システムに実装するのは困難です。たとえば、分散型で信頼できる名前システムを実現することは困難です (名前システムの一意性を保証するかどうかなど)。
Farcaster は、2 つの独立したシステムを通じてこれらの機能のバランスをとります。 Farcaster ID Registry (FIR) は fid と呼ばれる新しい ID 番号を発行し、Farcaster Name Registry (FNR) は fnames と呼ばれる新しいユーザー名を発行します。 Fid は、すべてのメッセージに存在する安全な分散型識別子であり、概念的には uuid に似ています。
Fname は主に FIR 変更用であり、レンダリング時に fid を置き換え、いつでも変更できます。 ID をこれら 2 つのコンポーネントに分離することで目的を達成できますが、その代償としてシステムがいくらか複雑になります。どちらのシステムも、分散化に影響を与えることなく、名前を制御するキー ペアの損失を保護する回復メカニズムを実装しています。
ファーキャスター ID レジストリ (FIR)
Farcaster ID は、uuid と同様の数値識別子です。ユーザーに表示されるときは、その前に感嘆符が付きます (例: !8098)。
FID は、個人や組織などの一意のエンティティを表します。このエンティティへの参照はすべて、fname ではなく fid を使用する必要があります。 FID の登録料は非常に安く、生涯所有されます。 FID 契約はいかなる方法でもアップグレードまたは変更することはできません。
FID は 0 から始まり、新しい登録が発生するたびに 1 ずつ増加します。 fid は uint256 としてオンチェーンに保存され、~10^77 まで増分できるため、ほぼ無限の供給が保証されます。
ユーザーは FIR を使用して URL を構成し、オフチェーン情報の場所を見つけることができます。
ファーキャスター名前登録 (FNR)
Farcaster の名前は一意であり、他のネットワークのユーザー名と同様です。ユーザーに表示されるときは、先頭に @ 記号が付きます (例: @alice)。
Fname は、プロファイル、名前、検証トークンとともに、Web の閲覧中にエンティティを視覚的に識別するのに役立ちます。 fid とは異なり、fname は主に読み取り可能であり、ユーザーが作成した基礎となるデータとは何の関係もありません。 fname の所有権は永続的なものではなく、ユーザーはいくらかの年会費を支払う必要があります。 fname の更新は、fname の有効期限が切れる 90 日前に実行できます。期限切れの名前はオランダのオークションで競売にかけられ、入札者は年会費と 1,000 ETH から始まるプレミアムを支払う必要があります。プレミアムは 0 ETH になるまで 8 時間ごとに 10% ずつ減少します。
Fname は、Farcaster Name Registry によって先着順で発行される NFT です。各名前は正規表現 /^[a-z0-9][a-z0-9-]{0,15}$/ と一致する必要があります。これらには、ENS などの他の名前空間と比較して、ソーシャル ネットワークでより役立つ特定のプロパティがあります。これらは鋳造して所有するのに安価であり、文字セットの制限により同音異義語攻撃の影響を受けにくく、回復可能でもあります。 Farcaster では fname を使用する必要がなく、ユーザーは他の名前空間とその fid を自由に使用できます。
Farcaster は fid を中心に設計されており、すべての情報と動作がフレームではなく fid を指すため、fname の使用を放棄しても大きな影響はありません。 fname は、以前の依存関係情報を失うことなく、いつでも変更できます。
ユーザー名ポリシー
ベータ期間中、ユーザー名は無料で登録でき、シンプルなポリシーが適用されます。このポリシーの目的は、非アクティブなユーザーが名前を取得したり、他人になりすますために悪意を持って使用されたりするのを防ぐことです。この問題の解決策は簡単には自動化できず、実行するには人間の判断が必要です。ユーザー名ポリシーには 2 つの基本原則があります。
 なりすまし - 有名な著名人または団体に属するユーザー名で登録した場合、名前の登録が抹消される場合があります。たとえば、@elonmusk、@vitalikbuterin、@google、@whitehouse などです。 非アクティブ - ユーザー名を 60 日以上アクティブに使用していない場合、別のユーザーの要求または当社の裁量により、名前の登録が抹消される場合があります。
正当な競合が存在する可能性があるため、手動による介入が必要になる場合が多いと予想されます。たとえば、あなたが @vitalik を登録し、Vitalik Buterin があなたの後に登録し、その名前を希望したとします。この場合、決定を導くために 3 つの質問をします。
 このユーザーはアクティブで Farcaster に参加していますか? (たとえば、過去数か月間で質の高い投稿を公開した場合など) このユーザーはその名前に対して正当な権利を持っていますか? (たとえば、名前も Vitalik の場合) このユーザーは他のネットワーク上に同様のアクティブなアカウントを持っていますか? (たとえば、twitter に vitalik と vitalik.ens がある場合)。
これらの質問に対する答えがほとんど「はい」であれば、彼らは自分たちの名前の主張を保持するでしょう。テストネットでは、コアチームがこの競合を仲裁し、メインネットに近づくにつれて、この問題に関する管理システムを正式に確立したいと考えています。仲裁の結果として名前が取り消された場合、ユーザーには返金されません。
アカウント復旧
ユーザーが ID と名前を保持するアドレスのキーを紛失した場合でも、Farcaster ID と名前は回復可能です。どちらの契約も、回復アドレス要求を新しいアドレスに転送できる遅延回復システムを実装しています。保管アドレスが 3 日以内に転送をキャンセルしない場合、回復アドレスは転送を完了できます。
ユーザーは、回復アドレスを自分のウォレット内の別のアドレス、友人と共有するマルチシグ、またはサードパーティの回復サービスに設定できます。ユーザーはいつでも回復アドレスを変更できます。回復アドレスは保管アドレスが同意しない転送を行うことができないため、所有権は分散されたままになります。
資産を新しいエスクロー アドレスに転送すると、回復アドレスの設定が解除されます。そうしないと、ユーザーが OpenSea で名前を購入した結果、前の所有者が回復アドレスを使用して秘密裏にその名前を取り戻すことになる可能性があります。
 情報処理
情報処理は、ハブが新しい​​メッセージを受け入れ、ユーザーのステータスを判断するプロセスです。ユーザーは、アクションごとにメッセージをハブに送信します。ユーザーが URL を好き、嫌い、そして好きの場合、3 つのメッセージが生成されます。すべての情報を受信するハブは、ユーザーのお気に入りの URL の現在のステータスを判断します。
ハブは、スペースを節約するために最初の 2 つの情報を破棄できます。ハブはマージ操作を使用してこのようなメッセージを圧縮できるため、クライアント側の不整合が回避され、スペースが節約されます。メッセージには、マージ操作に対して異なるルールが適用される場合があります。たとえば、あるユーザーから同じユーザーへの 2 つの「いいね！」は 1 つに圧縮できますが、2 つの返信は圧縮できません。
ハブはユーザー情報の一部を失い、エラー状態になる可能性があります。たとえば、最初の「いいね！」メッセージと「嫌い」メッセージのみを受信し、現在のステータスを「嫌い」に設定する場合があります。マージ操作により、状態が前進し、欠落したメッセージが再ブロードキャストされるときに一貫性が得られるようになります。言い換えれば、マージは最終的に強い一貫性を確保する必要があります。
ハブは、メッセージ タイプごとに一連の CRDT を実装し、特定の検証とマージ ルールをエンコードすることでこれを実現します。この機能により、ハブはいつでもオフラインにでき、いつでも復元して同期できるため、ハブの可用性が高くなります。形式的には、私たちの CRDT セットは匿名のデルタ状態 CRDT2 であり、各メッセージはセット上の接続された還元不可能な更新です。
情報整理
情報収集では、署名情報をタイムスタンプで並べ替え、最後に作成されたポリシーとのマージ競合を解決できます。ただし、タイムスタンプはクロック スキュー、クロック ドリフト、悪意のあるユーザーによるスプーフィングの影響を受けやすく、さまざまな理由で衝突する可能性があるため、完全な順序を保証することはできません。アプリケーションは混合クロックを使用して、衝突することなく完全に順序付けされたタイムスタンプを生成できますが、その使用を強制することはできません。
代わりに、タイムスタンプを使用して初期順序を決定し、ハッシュを使用して衝突を解消することにより、完全な順序付けを保証するメッセージの順序付けシステムを定義します。 2 つのメッセージが同じメッセージでない限り、同じハッシュ値を持つことはできないため、完全な順序付けが保証されます。 2 つのメッセージ a と b は、次のアルゴリズムを使用して比較できます。
 atimestamp>btimestamp の場合、a の方が大きいです。 a.timestamp < b.timestamp の場合、b の方が大きくなります。 if a.timestamp == b.timestamp
- a.hash > b.hash の場合、a の方が大きくなります。
- a.hash < b.hash の場合、b の方が大きくなります。
        - 如果a.hash = b.hash，a == b
タイムスタンプは数値として比較され、ハッシュは文字列として比較されます。文字列の比較は実装ごとに異なるため、比較アルゴリズムを正確にする必要があります。 2 つのハッシュ値 x と y は、文字の各ペアを比較することで比較できると考えられます。
 すべての文字ペアが等しく、x と y が両方とも終了する場合、x == y すべての文字ペアが等しく、x が最初に終了する場合、y>x 異なる文字ペア xC、yC が見つかった場合、If ASCII( yC)>ASCII(xC)、その後 y>x
情報の確認
メッセージ タイプ固有の検証に加えて、すべてのメッセージは次の検証に合格する必要があります。
 message.timestamp はシステム時刻より 1 時間以上進んでいません。 message.fid は、FIR 内の既知の FID 番号である必要があります。 SignerPubKey は、message.fid の有効な管理対象署名者または委任された署名である必要があります。 hashFn(serializeFn(message)) は、envelope.hash と一致する必要があります。ここで、hashFn は Blake2B 関数であり、serializeFn は JSON 正規化を実行します。 EdDSA_signature_verify(envelope.hash、envelope.signerPubKey、envelope.signature) は合格するはずです。
キャスト
キャストはユーザーが作成した公開情報であり、テキストが含まれており、メディア、オンチェーン アクティビティ、または他のキャストに埋め込むこともできます。キャストは、メッセージ間の競合を解決するために 2 段階のコレクション CRDT3 に保存されます。
キャストは、CRDT のアドセットに配置される CastAdd メッセージを介して追加できます。各キャストはハッシュ値によってインデックス付けされ、キャストが同一でない限り一意であることが保証されます。拡張すると、2 つの追加メッセージが同一でない限り競合することはなく、同一の場合は 1 つを安全に破棄できます。
キャストは、ターゲット CastAdd のハッシュへの参照を含む CastRemove メッセージを介して削除できます。このメッセージを受信すると、ターゲットが存在する場合は add-set から削除され、削除されたターゲットが rem-set に追加されます。追加と削除の間の競合は Remove-Wins ルールで処理されますが、削除間の競合は Last-Write-Wins ルールで処理され、同点の場合は辞書編集順にフォールバックします。
情報を追加する
Cast Add には、最大 320 文字の Unicode テキストと、最大 256 文字の 2 つの URI を含めることができます。クライアントは、URI とテキストを一緒にデコードしてレンダリングする責任があります。
親のないキャストはトップレベルのキャストであり、クライアントはユーザーのプロフィールまたはタイムラインに表示される必要があります。親キャストは、別のキャスト、Web URL、またはオンチェーン オブジェクトへの応答であり、スレッドに表示される必要があります。
ポーリングは一連のツリーを形成します。各ルートはポーリングまたは URI、各子ノードは応答ポーリングです。各ツリーはスレッド化された会話としてレンダリングできます。子ノードが親ノードを指す前に親ノードをハッシュして署名する必要があるため、ツリーは非周期的であることが保証されます。親ノードのデータを変更すると、その子ノードとのすべての関係が破壊されます。
キャスト情報は次の検証手順を通過する必要があります。
 テキストには <=320 の有効な Unicode 文字が含まれている必要があります 埋め込みには 0 ～ 2 個の項目が含まれている必要があります 項目は最大 256 文字の URI である必要があります 親が存在する場合は、このメッセージの URI と等しくなく、有効な URI である必要があります (例: fid:/cast:)。
メッセージを削除する
Cast Remove には、Cast Add のハッシュへの参照が含まれているだけです。元のキャストのデータを削除しながら、キャストを完全に削除できます。
メッセージは次の検証手順を通過する必要があります。
 message.data.body.hash は message.envelope.hash と等しくない必要があります。 message.timestamp は <= システム クロック + 10 分である必要があります message.data.fid は FIR 内の既知の FID である必要があります
マージルール
add メッセージ a を受信したときに、r が rem-set に存在し、r.data.body.hash が a.hash と等しい場合、a は破棄されます。それ以外の場合は、 を加算セットに追加します。削除メッセージ r を受信した場合、追加されたセット内に r.data.body.hash と等しい a.hash が存在する場合、それを削除します。 rem-set に r' があり、r.data.body.hash が r'.data.body.hash に等しい場合、r' > r の場合は r' を破棄します。
行動
アクションは、ターゲットに対してユーザーによって実行されるパブリック操作であり、別のユーザーまたはオンチェーンアクティビティが可能です。現在、「いいね」と「フォロー」の 2 種類のアクションがサポートされています。このプロトコルは、新しいアクションをサポートするために簡単に拡張できます。ユーザーは、メッセージのアクティビティ属性を切り替えることで、アクションを元に戻したりやり直したりできます。概念的には、各アクションはソーシャル グラフのエッジです。
アクションは LWW-Element-Set CRDT を使用して管理され、結果的な整合性が保証されます。概念的には、すべてのメッセージを格納する単一のコレクションがあり、競合はタイムスタンプと辞書編集上のハッシュ順序によって解決されます。追加は、active を true に設定してアクション メッセージ a を構築することによって実行され、削除は active を false に設定することによって実行されます。どちらの場合も、メッセージをセットにマージするロジックは次のとおりです。
コレクションにアクション x がある場合、そのタイプ、ターゲット Uri、および fid 値は、受信アクション y と同じです。 x>y の場合、x の場合は y を破棄します。
確認する
検証は、Farcaster アカウントと外部エンティティの間の双方向の所有権の証明です。検証は、イーサリアム アドレス、特定の NFT、その他のソーシャル メディア アカウント、さらにはドメイン名の所有権を証明するために使用できます。
検証には 3 つの中心的な概念があります。
 Farcaster アカウントおよび外部エンティティへの言及を含むステートメント。クレームをハッシュして、各クレームに一意の識別子を作成できます。 Farcaster アカウントに接続する意図を示すリクエストを行う権限のある外部エンティティからの方向性の証明。 Farcaster アカウントにクレームを関連付けるリクエストを受け入れるための Farcaster アカウントからの方向性の証明。
署名者の承認
署名者の承認は、Farcaster アカウントの署名を生成するための新しいキー ペアを承認するメッセージです。
FID が作成されると、保管アドレスのみがその代わりにメッセージに署名できます。アカウント侵害のリスクが高まるため、ユーザーはこのキー ペアをすべてのデバイスにロードしたくない場合があります。管理アドレス (管理署名者とも呼ばれます) は、委任署名者として知られる他の鍵ペアを認証できます。規制署名者とは異なり、委任された署名者はオフチェーン情報の公開のみが許可されており、オンチェーン操作を実行することはできません。
エスクロー署名者は secp256k1 曲線で ECDSA 署名を生成し、署名者の認証情報のみを公開できます。他のタイプのメッセージはすべて、curve255194 で EdDSA 署名を作成する委任された署名者によって署名される必要があります。委任された署名者を使用すると、新しいデバイスやサードパーティのサービスがアカウントのメッセージに署名することを承認できます。委任された署名者が侵害された場合、それ自体、信頼チェーン内のその祖先、または任意の委任された署名者によって取り消される可能性があります。署名者が取り消されると、ユーザーの情報と攻撃者の情報を区別する方法がないため、ハブはその署名情報をすべて破棄します。
ユーザーは、キーの回復やウォレットの変更により、ID を新しいエスクロー アドレスに転送することもできます。多くの場合、両方のエスクロー アドレスが有効なエスクロー署名者になるように履歴を保存することが望ましいです。 ID の有効な署名者のセットは、一連の異なるツリーを形成します。各ツリーのルートは歴史的な保管アドレスであり、葉は委任された署名者です。
署名者セットは、delete-win および last-write-win セマンティクスを備えた修正された 2 フェーズ セットです。有効な本人または保護者によって署名された場合、新しい情報がコレクションに追加されます。あなた自身または先祖によって署名された場合、削除は受け入れられます。署名者が削除されると、署名者を追加できなくなり、その子孫とメッセージはすべて破棄されます。
2 人の有効な署名者がそれぞれ同じ委任された署名者を承認すると、セットの競合が発生し、ツリー データ構造が破壊されます。これが発生した場合、コレクションは、最も高いタイムスタンプと辞書編集上のハッシュを持つメッセージを順番に保持します。
断片化
ハブは特定のアカウントのデータのみをコピーできます。これは、ネットワークを拡張する場合に便利な特性です。 Farcaster が大きくなり、単一のサーバーでハブのネットワーク全体のレプリケーションをサポートできなくなると、ワークロードが複数のハブに分散される可能性があります。ハブ オペレーターは、悪意のある行動をするユーザーやオペレーターと関係のないユーザーのデータの同期を回避することもできます。
選択的レプリケーションでは、ネットワークの部分的なビューのみが提供されます。ハブがアリスのデータを同期している場合、アリスがボブの投稿の 1 つに返信し、「いいね！」をしたことがわかります。ただし、ボブの投稿の内容や、ボブが彼女の返信を気に入って返信を続けたという事実はわかりません。正確ないいね数を提供し、すべての返信情報を提供することを目的としたアプリは、できるだけ多くのユーザーを複製する必要があります。