詳解Web3社交協議Farcaster Protocol：有何魔力能讓V神入駐？

原文：《社交協議捲起來了！ Farcaster是什麼？ 》

作者：ELEN

Farcaster Protocol是繼Lens Protocol之後的又一SocialFi賽道龍頭產品，Farcaster是前Coinbase高管Dan Romero和Varun Srinivasan的項目，目前已獲得了A16Z領投的3000萬美金。

Farcaster的目標是為WEB3生態提供一個可信的中立協議，使用戶與受眾有直接的聯繫，同時可以讓開發者自由的建立新的客戶端。

 Viafarcaster V神入駐

Farcaster的遠期目標是成為WEB3社交賽道中重要的底層基礎設施，這一點和Lens Protocol的方向是一致的，但Farcaster的架構設計相比Lens Protocol精細很多，採取了一個試圖在WEB2和WEB3之間尋找一個最優平衡點的策略。

 ViaBlockTurbo

今天我們來深入了解一下Farcaster的協議層設計與生態應用思路，如果想要深入研究可以去查看官方的github:

https://github.com/farcasterxyz/protocol

Farcaster介紹

社交網絡是去年10年發展的最迅速的行業，很多的社交平台為開發者提供了API，使開發者可以“二次創造”，並發展出新的生態，例如Twitter上的各類好玩的插件。但是，最近幾年，情況好像不太對了，開發者能做的事情似乎變得越來越少，API的限制與各種各樣的審查使得開發者不再自由，甚至有時在沒有任何通知的前提下，就被剝奪了訪問的權利。

Farcaster是一個完全的去中心化協議，方便開發者構建去中心化的社交網絡應用。 Farcaster對於去中心化的定義很簡單：當兩個用戶想互相交流的時候，沒有任何一種方式可以阻止這件事情發生。也就是說，用戶可以完全控制他們的身份，他們的數據以及他們的社交關係。開發人員可以打破任何第三方甚至是網絡的限制構建一個完全去中心化的社交應用。

這樣的願景也是Lens Protocol想要實現的，我們可以認為SocialFi的底層協議的最大價值，是提供一個完全去中心化的社交網絡的技術底層的實現方法，使其完全不會被任何的第三方控制。類似於IPFS在去中心化存儲市場中的價值。

 Viafarcaster.network

Farcaster架構

Farcaster採用的一種鏈上+鏈下的混合架構，來完成去中心化協議的搭建。 Farcaster的身份是被存儲在以太坊鏈上的，並利用以太坊來保證其安全性，可組合性與一致性。身份通過以太坊地址來控制，並通過以太坊賬戶來簽署鏈下信息。

用戶的數據則通過身份進行加密簽名，存儲在用戶控制的服務器上（Farcaster Hubs），之所以數據不存儲在鏈上是因為在大多數L1和L2網絡上的結算成本過高，速度過慢。

這一架構與LENS Protocol的設計不太一樣，Farcaster更多考慮了開發者的實際需求，並更類似於WEB2社交媒體的表現形式，降低用戶學習的成本，但Farcaster依舊是去中心化的，用戶的身份，數據和社交關係是基於區塊鏈的。

賬戶

Farcaster賬戶類似於Twitter或Reddit等假名社交網絡上的賬戶，個人可以同時操作幾個賬戶。每個賬戶都有一個與之相關的唯一號碼，稱為Farcaster ID或Fid。 Farcaster ID可以通過調用Farcaster ID註冊處（FIR）從一個以太坊地址獲得。這個地址被稱為託管地址，可以代表賬戶簽署鏈外和鏈上信息。用戶可以選擇從Farcaster名稱註冊處（FNR）獲得一個Farcaster名稱或fname，該處為其頒發一個獨特的名稱，如@alice。

可以這樣理解，Fid是鏈上身份，而FNR則是社交可讀身份。如果Fid是錢包地址的話，那麼FNR就是ENS。

簽名信息

簽名信息是一種防篡改和自我認證的對象，由fid來進行簽名。簽名信息代表了用戶的行為，如發帖、社交反饋（評論/轉發）或修改賬戶信息，如用戶名。

簽名消息具有消息屬性，消息屬性包含了一些有效載荷（payload）。有效載荷被序列化、散列化，並由一個有效的密鑰對簽名（例如costody address）。 envelope包含哈希值、簽名和簽名密鑰對的公鑰，任何接收者都可以用它來驗證fid的簽名。

信息必須用RFC-8785進行序列化，用BLAKE2b進行散列，並用Ed25519簽名方案進行簽名。每條信息還必須包含一個fid來查詢鏈上的託管地址，以及一個用於排序的時間戳。

應用

應用程序是人們用來與Farcaster網絡互動的程序。一個簡單的應用程序可能包括一個獨立的桌面或移動客戶端，直接與Farcaster Hub會話。它可以發布新消息，並查看其他fids發布的消息。這樣的應用程序是自託管的，必須用託管地址或有效的簽名密鑰才能進行實例化。

更複雜的應用程序可能會添加一個代理後台服務器，對Hub的數據進行索引。索引允許服務器實現搜索、算法饋送和垃圾郵件檢測等功能，這些功能在Hub上很難執行或很昂貴。這樣的應用可以通過在客戶端存儲密鑰來實現自託管；通過要求用戶提供委託簽名密鑰來實現委託；或者通過管理所有密鑰來實現託管。

Hubs

Hub是一個永遠在線的服務器，用於驗證、存儲和復制簽名信息。用戶選擇一個Hub，並使用FIR在鏈上發布其URL。他們的Follower可以使用這個URL來尋找和下載他們的消息。同時，用戶也可以自己運行Hub或使用第三方託管服務。

Farcaster的身份

Farcaster的身份系統使用戶的身份具有以下特性：

• 安全且完全去中心化
• 在社交網絡中容易被識別
• 建立起來很容易（快速且低成本）
• 可恢復（不違背去中心化的特性）

這些特性在一個身份系統中實現是具有挑戰性的，因為它們經常是衝突的。例如，擁有一個去中心化的、值得信賴的名稱系統是很難的（例如是否要保證名稱系統的唯一性）。

Farcaster通過兩個獨立的系統來平衡這些特性。 Farcaster ID Registry（FIR）發布新的ID號碼，稱為fids；Farcaster Name Registry（FNR）發布新的用戶名，稱為fnames。 Fids是安全的、分散的標識符，存在於每條信息中，在概念上類似於uuids。

Fnames主要是對於FIR修飾，在渲染時取代fid，並可在任何時候改變。將一個身份分離成這兩個組件使我們能夠實現我們的目標，但代價是給系統增加了一些複雜性。這兩個系統還實現了一個恢復機制，在不影響去中心化的情況下保護控制名字的密鑰對的丟失。

Farcaster ID Registry (FIR)

Farcaster ID是數字標識符，類似於uuids。當顯示給用戶時，它們前面會有一個感嘆號（例如：！8098）。

一個FID代表一個獨特的實體，如一個人或一個組織。每個引用該實體的信息都必須使用它的fid，而不是它的fname。 fid的註冊費用很低，而且是終身擁有。 FID合約不能以任何方式升級或修改。

FID從0開始，每當有新的註冊發生時就會遞增1。一個fid以uint256的形式存儲在鏈上，保證了近乎無限的供應，因為它可以被遞增到~10^77。

用戶可以使用FIR來配置URL，用來尋找他們的鏈外信息的位置。

Farcaster Name Registry (FNR)

Farcaster名稱是唯一的，類似於其他網絡的用戶名。當顯示給用戶時，他們會在前面顯示一個@符號（例如：@alice）。

Fname，連同個人資料、名稱和驗證標記，有助於在瀏覽網絡時直觀地識別一個實體。與fids不同，fname主要是可讀的，與用戶創建的基礎數據沒有關係。 fname的所有權不是永久性的，用戶必須每年支付一些費用。 fname續費可以在fname到期前90天進行。過期的名字將以荷蘭式拍賣的方式進行拍賣，投標人必須支付年費和溢價，起價為1000ETH。溢價每8小時減少10%，直到達到0 ETH。

Fnames是由Farcaster名稱註冊處以先到先得的方式發行的NFT。每個名字必須符合正則表達式/^[a-z0-9][a-z0-9-]{0,15}$/。它們具有特定的屬性，使它們在社會網絡中相對於其他命名空間（如ENS）來說更加有用。它們的鑄造和擁有成本較低，由於字符集的限制，不容易受到同音字的攻擊，而且也可以恢復。 Farcaster並不強制要求使用fname，用戶可以自由地使用其他的名字空間和他們的fids。

放棄fname的使用並不會有太大的不影響，因為Farcaster是圍繞fid設計的，每條信息和行為都指向fid而非frame。 fnames可以在任何時候改變，而不會失去任何一個之前的依賴信息。

用戶名的政策

在測試期間，用戶名可以免費註冊，並受一個簡單的政策約束。該政策的目的是防止名字被不活躍的用戶佔用或被惡意用來冒充他人。這個問題的解決方案不容易自動化，需要人工判斷來執行。用戶名政策有兩個核心原則：

• 冒名註冊- 如果你註冊的用戶名屬於一個知名的公眾人物或實體，你的名字可能會被取消註冊。例如，@elonmusk、@vitalikbuterin、@google或@whitehouse。
• 不活躍- 如果你在60天以上沒有積極使用一個用戶名，你的名字可能會在其他用戶的要求下被取消註冊，或者由我們決定取消註冊。

我們預計經常需要人工干預，因為可能會有合理的衝突。例如，你註冊了@vitalik，而Vitalik Buterin在你之後註冊並想要這個名字。在這種情況下，我們會問三個問題來指導決策：

• 該用戶在Farcaster上是否活躍並參與？ (例如，如果他們在過去的幾個月裡發表了高質量的帖子。）
• 該用戶是否對這個名字有合理的要求？ ( 例如，如果他們的名字也是Vitalik)
• 該用戶是否在其他網絡上擁有類似的、活躍的賬戶？ (例如，如果他們在twitter上擁有vitalik和vitalik.ens）。

如果這些問題的答案大多是肯定的，他們將保留對自己名字的要求。在測試網中，核心團隊將對這種衝突進行仲裁，我們希望在接近主網時，圍繞這個問題正式建立一個管理制度。如果一個名字由於仲裁的結果而被收回，用戶將不會被退款。

賬戶恢復

如果用戶失去了持有ID和名字的地址的密鑰，Farcaster ID和名字是可以恢復的。這兩個合約都實施了一個延時恢復系統，允許恢復地址請求轉移到一個新的地址。如果保管地址在三天內沒有取消轉移，恢復地址可以完成轉移。

用戶可以將恢復地址設置為自己錢包中的另一個地址，與朋友共享的多重簽名，或第三方恢復服務。用戶也可以在任何時候改變恢復地址。所有權仍然是去中心化的，因為恢復地址不能進行保管地址不同意的轉移。

將資產轉移到一個新的託管地址將解除恢復地址的設置。否則，用戶可能會在OpenSea上購買一個名字，但以前的所有者卻用他們的恢復地址隱秘地將其領回。

信息處理

信息處理是Hub接受新消息和確定用戶狀態的過程。用戶為他們的每一個行動向一個Hub發送消息。如果一個用戶喜歡一個URL，不喜歡它，又喜歡它，就會產生三條信息。一個收到所有信息的Hub將確定用戶喜歡的URL的當前狀態。

Hub可以丟棄前兩條信息以節省空間。 Hub可以使用合併操作來壓縮這樣的消息，這就避免了客戶端的不一致性並節省了空間。消息可能對其合併操作有不同的規則。例如，一個用戶對同一個用戶的兩個喜歡可以壓縮成一個，而兩個回复則不能。

Hub可能會遺失用戶的一些信息，並最終處於一個錯誤狀態。例如，它可能只收到第一個喜歡和不喜歡的信息，這就把當前狀態設定為不喜歡。合併操作應該允許狀態向前發展，並在缺失的消息被重新廣播時達到一致性。換句話說，合併應該確保最終的強一致性。

Hub通過為每個消息類型實現CRDT集，編碼特定的驗證和合併規則來實現這一點。這一特性使得Hub具有很高的可用性，因為它們可以在任何時候下線，並且總是能夠恢復同步。從形式上看，我們的CRDT集是匿名的Δ-狀態的CRDT2，每條消息都是集上的一個連接且不可減少的更新。

信息排序

信息集合可以通過時間戳對簽名信息進行排序，以最後寫入的策略解決合併衝突。然而，他們不能保證完美的排序，因為時間戳容易受到時鐘偏移、時鐘漂移、惡意用戶欺騙的影響，並且可能因為一些原因發生碰撞。應用程序可以使用混合時鐘來產生完美排序的時間戳，不發生碰撞，但我們不能強制使用它們。

相反，我們為消息定義了一個排序系統，通過使用時間戳來確定初始排序，並使用哈希值來打破衝突，從而確保總排序。總排序是有保證的，因為兩個消息不能有相同的哈希值，除非它們是同一消息。兩個消息a和b可以用這個算法進行比較：

• 如果a.timestamp>b.timestamp，則a更大。
• 如果a.timestamp < b.timestamp，則b更大。
• 如果a.timestamp == b.timestamp

-如果a.hash>b.hash，則a大。

-如果a.hash < b.hash，則b更大。

-如果a.hash = b.hash，a == b

時間戳是作為數字比較的，而哈希值是作為字符串比較的。由於字符串的比較在不同的實現中會有差異，我們必須在比較算法中精確。我們認為，兩個哈希值x和y可以通過比較每一對字符來進行比較：

• 如果所有的字符對都相等，並且x和y都終止，那麼x == y
• 如果所有的字符對都相等，並且x先終止，那麼y>x
• 如果遇到一個不同的字符對xC，yC，那麼如果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) 應該通過。

Casts

Cast是由用戶創建的公共信息，其中包含文本，也可以嵌入媒體、鏈上活動或其他Cast。 Cast被存儲在一個兩階段的集合CRDT3中，解決消息之間的衝突。

一個Cast可以通過CastAdd消息來添加，該消息被放置在CRDT的add-set中。每個Cast都被其哈希值所索引，除非Cast是相同的，否則哈希值保證是唯一的。推而廣之，兩個添加消息永遠不會衝突，除非它們是相同的，在這種情況下，一個可以被安全地丟棄。

Cast可以通過CastRemove消息來移除，該消息包含對目標CastAdd的哈希值的引用。當收到該消息時，如果目標存在，則從add-set中移除，而移除則被添加到rem-set中。添加和刪除之間的衝突用Remove-Wins規則處理，而刪除之間的衝突用Last-Write-Wins規則處理，在平局的情況下回到lexicographical排序。

添加信息

一個Cast Add可以包含最多320個字符的unicode文本和兩個最多256個字符的URI。客戶端負責將URI和文本一起解碼和渲染。

沒有父代的Cast是一個頂級的Cast，客戶應該顯示在用戶的個人資料或時間線上。有父代的cast是對另一個cast、web URL或鏈上對象的回复，應該在一個線程中顯示。

投票形成一系列的樹，每個根是一個投票或URI，每個子節點是一個回复投票。每個樹都可以被渲染成一個線程對話。樹被保證為非週期性的，因為在子節點指向它之前，父節點必須被散列和簽名。對父節點數據的任何改變都會破壞與其子節點的所有關係。

Cast信息必須通過以下驗證步驟。

1. 文本必須包含<=320個有效的unicode字符
2. embed必須包含0到2個項目
3. 項目必須是一個最多256個字符的URI
4. 如果存在父代，必須是一個有效的URI，不等於這個消息的URI（例如，fid:/cast:）。

刪除信息

Cast Remove只包含一個對Cast Add的哈希值的引用。它允許永久刪除Cast，同時刪除原始Cast的數據。

該消息必須通過以下驗證步驟:

1. message.data.body.hash必須不等於message.envelope.hash。
2. message.timestamp必須<=系統時鐘+10分鐘
3. message.data.fid必須是FIR中的一個已知fid

合併規則

當收到一個添加消息a時，如果在rem-set中存在r，並且r.data.body.hash等於a.hash，則丟棄a。否則，將a添加到添加集中。當收到一個移除信息r時，如果在添加集中有一個a.hash等於r.data.body.hash，則刪除它。如果在rem-set中存在一個r'，其中r.data.body.hash等於r'.data.body.hash，如果r'>r，丟棄r'；如果r'

Actions

Action是用戶對一個目標進行的公開操作，這個目標可以是另一個用戶，也可以是鏈上活動。目前支持兩種類型的操作：喜歡和關注。該協議可以很容易地被擴展以支持新的Action。用戶可以通過切換消息上的活動屬性來撤銷和重做行動。從概念上講，每個行動是社交圖中的一條邊。

Action是用LWW-Element-Set CRDT管理的，它保證了最終的一致性。從概念上講，有一個單一的集合來存儲所有的消息，衝突是通過時間戳和lexicographical hash順序來解決。增加是通過構建一個active為真的行動消息a來進行的，而刪除則是通過將active設置為假來進行的。在這兩種情況下，將消息合併到集合中的邏輯是:

如果集合中存在一個Action x，其類型、目標Uri和fid的值與傳入的動作y相同。如果x>y，丟棄y;如果x

驗證

驗證是Farcaster賬戶和外部實體之間所有權的雙向證明。驗證可以用來證明以太坊地址、特定的NFT、其他社交媒體賬戶、甚至是域名的所有權。

驗證有三個核心概念：

1. 聲明，包括對Farcaster賬戶和外部實體的引用。聲明可以被哈希化，以便為每個索賠創建一個獨特的標識符。
2. 來自外部實體的方向性證明，該實體被授權提出要求，顯示其與Farcaster賬戶的連接意圖。
3. 來自Farcaster賬戶的方向性證明，接受將索賠與Farcaster賬戶關聯的請求。

簽名者授權

簽名者授權是一個消息，授權一個新的密鑰對為Farcaster賬戶生成簽名。

當一個fid被鑄成後，只有保管地址可以代表它簽署信息。用戶可能不想把這個密鑰對加載到每個設備中，因為它增加了賬戶被破壞的風險。保管地址，也被稱為保管簽名者，可以授權其他被稱為委託簽名者的密鑰對。與監管簽名者不同，委託簽名者只允許發布鏈外信息，不能執行任何鏈上操作。

託管簽名人在secp256k1曲線上生成ECDSA簽名，只能發布簽名人授權信息。所有其他類型的消息必須由委託簽名者簽署，委託簽名者在curve255194上創建EdDSA簽名。委託簽名者可以用來授權新的設備甚至第三方服務來為一個賬戶簽署消息。如果一個委託簽名者被破壞，它可以被自己、其信任鏈中的祖先或任何託管簽名者撤銷。當一個簽名者被撤銷時，Hubs會丟棄它所有的簽名信息，因為沒有辦法區分用戶的信息和攻擊者的信息。

用戶也可能因為密鑰恢復或更換錢包而將一個id轉移到一個新的託管地址。通常希望保留歷史，因此兩個託管地址都成為有效的託管簽名者。一個id的有效簽名人集合形成了一系列不同的樹。每棵樹的根是一個歷史保管地址，而葉子是委託簽名人。

簽名人集合是一個修改過的兩階段集合，具有刪除-贏和最後寫入-贏的語義。如果新信息被有效的委託人或監護人簽名，則被添加到該集合中。如果是由自己或祖先簽署的刪除信息則被接受。簽名者一旦被移除就不能再被添加，它的所有後代子代和消息都會被丟棄。

如果兩個有效的簽名者分別授權同一個委託簽名者，就會發生集合衝突，這就破壞了樹狀數據結構。如果發生這種情況，集合將保留具有最高時間戳和lexicographical hash的消息，按順序排列。

分片

Hubs可以只複製特定賬戶的數據，這對擴展網絡是一個有用的屬性。如果Farcaster發展到足夠大，以至於一台服務器無法支持複製整個網絡的Hub，那麼工作負載可以分散到多個Hub上。集線器運營商也可以避免為那些有惡意行為或與運營商無關的用戶同步數據。

選擇性複制只能提供網絡的部分視圖。如果一個Hub正在同步Alice的數據，它就會知道她回复並喜歡Bob的一個帖子。然而，它不會知道Bob的帖子的內容，或者Bob喜歡她的回复，然後繼續回复的事實。一個旨在提供準確的喜歡計數並提供所有回复信息的應用程序應該盡可能多地複制用戶。