#区块链#FarcasterProtocol是继LensProtocol之后的又一SocialFi赛道龙头产品，Farcaster是前Coinbase高管DanRomero和VarunSrinivasan的项目，目前已获得了A16Z领投的万美金。
Farcaster的目标是为WEB生态提供一个可信的中立协议，使用户与受众有直接的联系，同时可以让开发者自由的建立新的客户端。
Farcaster的远期目标是成为WEB社交赛道中重要的底层基础设施，这一点和LensProtocol的方向是一致的，但Farcaster的架构设计相比LensProtocol精细很多，采取了一个试图在WEB2和WEB之间寻找一个最优平衡点的策略。
今天我们来深入了解一下Farcaster的协议层设计与生态应用思路。
Farcaster介绍
社交网络是去年10年发展的最迅速的行业，很多的社交平台为开发者提供了API，使开发者可以“二次创造”，并发展出新的生态，例如Twitter上的各类好玩的插件。但是，最近几年，情况好像不太对了，开发者能做的事情似乎变得越来越少，API的限制与各种各样的审查使得开发者不再自由，甚至有时在没有任何通知的前提下，就被剥夺了访问的权利。
Farcaster是一个完全的去中心化协议，方便开发者构建去中心化的社交网络应用。Farcaster对于去中心化的定义很简单：当两个用户想互相交流的时候，没有任何一种方式可以阻止这件事情发生。也就是说，用户可以完全控制他们的身份，他们的数据以及他们的社交关系。开发人员可以打破任何第三方甚至是网络的限制构建一个完全去中心化的社交应用。
这样的愿景也是LensProtocol想要实现的，我们可以认为SocialFi的底层协议的最大价值，是提供一个完全去中心化的社交网络的技术底层的实现方法，使其完全不会被任何的第三方控制。类似于IPFS在去中心化存储市场中的价值。
Farcaster架构
Farcaster采用的一种链上+链下的混合架构，来完成去中心化协议的搭建。Farcaster的身份是被存储在以太坊链上的，并利用以太坊来保证其安全性，可组合性与一致性。身份通过以太坊地址来控制，并通过以太坊账户来签署链下信息。
用户的数据则通过身份进行加密签名，存储在用户控制的服务器上（FarcasterHubs），之所以数据不存储在链上是因为在大多数L1和L2网络上的结算成本过高，速度过慢。
这一架构与LENSProtocol的设计不太一样，Farcaster更多考虑了开发者的实际需求，并更类似于WEB2社交媒体的表现形式，降低用户学习的成本，但Farcaster依旧是去中心化的，用户的身份，数据和社交关系是基于区块链的。
账户
Farcaster账户类似于Twitter或Reddit等假名社交网络上的账户，个人可以同时操作几个账户。每个账户都有一个与之相关的唯一号码，称为FarcasterID或Fid。FarcasterID可以通过调用FarcasterID注册处（FIR）从一个以太坊地址获得。这个地址被称为托管地址，可以代表账户签署链外和链上信息。用户可以选择从Farcaster名称注册处（FNR）获得一个Farcaster名称或fname，该处为其颁发一个独特的名称，如
alice。可以这样理解，Fid是链上身份，而FNR则是社交可读身份。如果Fid是钱包地址的话，那么FNR就是ENS。
签名信息
签名信息是一种防篡改和自我认证的对象，由fid来进行签名。签名信息代表了用户的行为，如发帖、社交反馈（评论/转发）或修改账户信息，如用户名。
签名消息具有消息属性，消息属性包含了一些有效载荷（payload）。有效载荷被序列化、散列化，并由一个有效的密钥对签名（例如costodyaddress）。envelope包含哈希值、签名和签名密钥对的公钥，任何接收者都可以用它来验证fid的签名。
信息必须用RFC-进行序列化，用BLAKE2b进行散列，并用Ed签名方案进行签名。每条信息还必须包含一个fid来查询链上的托管地址，以及一个用于排序的时间戳。
应用
应用程序是人们用来与Farcaster网络互动的程序。一个简单的应用程序可能包括一个独立的桌面或移动客户端，直接与FarcasterHub会话。它可以发布新消息，并查看其他fids发布的消息。这样的应用程序是自托管的，必须用托管地址或有效的签名密钥才能进行实例化。
更复杂的应用程序可能会添加一个代理后台服务器，对Hub的数据进行索引。索引允许服务器实现搜索、算法馈送和垃圾邮件检测等功能，这些功能在Hub上很难执行或很昂贵。这样的应用可以通过在客户端存储密钥来实现自托管；通过要求用户提供委托签名密钥来实现委托；或者通过管理所有密钥来实现托管。
Hubs
Hub是一个永远在线的服务器，用于验证、存储和复制签名信息。用户选择一个Hub，并使用FIR在链上发布其URL。他们的Follower可以使用这个URL来寻找和下载他们的消息。同时，用户也可以自己运行Hub或使用第三方托管服务。
Farcaster的身份
Farcaster的身份系统使用户的身份具有以下特性：
安全且完全去中心化
在社交网络中容易被识别
建立起来很容易（快速且低成本）
可恢复（不违背去中心化的特性）
这些特性在一个身份系统中实现是具有挑战性的，因为它们经常是冲突的。例如，拥有一个去中心化的、值得信赖的名称系统是很难的（例如是否要保证名称系统的唯一性）。
Farcaster通过两个独立的系统来平衡这些特性。FarcasterIDRegistry（FIR）发布新的ID号码，称为fids；FarcasterNameRegistry（FNR）发布新的用户名，称为fnames。Fids是安全的、分散的标识符，存在于每条信息中，在概念上类似于uuids。
Fnames主要是对于FIR修饰，在渲染时取代fid，并可在任何时候改变。将一个身份分离成这两个组件使我们能够实现我们的目标，但代价是给系统增加了一些复杂性。这两个系统还实现了一个恢复机制，在不影响去中心化的情况下保护控制名字的密钥对的丢失。
FarcasterIDRegistry(FIR)
FarcasterID是数字标识符，类似于uuids。当显示给用户时，它们前面会有一个感叹号（例如：！）。
一个FID代表一个独特的实体，如一个人或一个组织。每个引用该实体的信息都必须使用它的fid，而不是它的fname。fid的注册费用很低，而且是终身拥有。FID合约不能以任何方式升级或修改。
FID从0开始，每当有新的注册发生时就会递增1。一个fid以uint的形式存储在链上，保证了近乎无限的供应，因为它可以被递增到~10^77。
用户可以使用FIR来配置URL，用来寻找他们的链外信息的位置。
FarcasterNameRegistry(FNR)
Farcaster名称是唯一的，类似于其他网络的用户名。当显示给用户时，他们会在前面显示一个
符号（例如：alice）。Fname，连同个人资料、名称和验证标记，有助于在浏览网络时直观地识别一个实体。与fids不同，fname主要是可读的，与用户创建的基础数据没有关系。fname的所有权不是永久性的，用户必须每年支付一些费用。fname续费可以在fname到期前90天进行。过期的名字将以荷兰式拍卖的方式进行拍卖，投标人必须支付年费和溢价，起价为1ETH。溢价每8小时减少10%，直到达到0ETH。
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，而VitalikButerin在你之后注册并想要这个名字。在这种情况下，我们会问三个问题来指导决策：该用户在Farcaster上是否活跃并参与？(例如，如果他们在过去的几个月里发表了高质量的帖子。）
该用户是否对这个名字有合理的要求？(例如，如果他们的名字也是Vitalik)
该用户是否在其他网络上拥有类似的、活跃的账户？(例如，如果他们在twitter上拥有vitalik和vitalik.ens）。
如果这些问题的答案大多是肯定的，他们将保留对自己名字的要求。在测试网中，核心团队将对这种冲突进行仲裁，我们希望在接近主网时，围绕这个问题正式建立一个管理制度。如果一个名字由于仲裁的结果而被收回，用户将不会被退款。
账户恢复
如果用户失去了持有ID和名字的地址的密钥，FarcasterID和名字是可以恢复的。这两个合约都实施了一个延时恢复系统，允许恢复地址请求转移到一个新的地址。如果保管地址在三天内没有取消转移，恢复地址可以完成转移。
用户可以将恢复地址设置为自己钱包中的另一个地址，与朋友共享的多重签名，或第三方恢复服务。用户也可以在任何时候改变恢复地址。所有权仍然是去中心化的，因为恢复地址不能进行保管地址不同意的转移。
将资产转移到一个新的托管地址将解除恢复地址的设置。否则，用户可能会在OpenSea上购买一个名字，但以前的所有者却用他们的恢复地址隐秘地将其领回。
信息处理
信息处理是Hub接受新消息和确定用户状态的过程。用户为他们的每一个行动向一个Hub发送消息。如果一个用户喜欢一个URL，不喜欢它，又喜欢它，就会产生三条信息。一个收到所有信息的Hub将确定用户喜欢的URL的当前状态。
Hub可以丢弃前两条信息以节省空间。Hub可以使用合并操作来压缩这样的消息，这就避免了客户端的不一致性并节省了空间。消息可能对其合并操作有不同的规则。例如，一个用户对同一个用户的两个喜欢可以压缩成一个，而两个回复则不能。
Hub可能会遗失用户的一些信息，并最终处于一个错误状态。例如，它可能只收到第一个喜欢和不喜欢的信息，这就把当前状态设定为不喜欢。合并操作应该允许状态向前发展，并在缺失的消息被重新广播时达到一致性。换句话说，合并应该确保最终的强一致性。
Hub通过为每个消息类型实现CRDT集，编码特定的验证和合并规则来实现这一点。这一特性使得Hub具有很高的可用性，因为它们可以在任何时候下线，并且总是能够恢复同步。从形式上看，我们的CRDT集是匿名的Δ-状态的CRDT2，每条消息都是集上的一个连接且不可减少的更新。
信息排序
信息集合可以通过时间戳对签名信息进行排序，以最后写入的策略解决合并冲突。然而，他们不能保证完美的排序，因为时间戳容易受到时钟偏移、时钟漂移、恶意用户欺骗的影响，并且可能因为一些原因发生碰撞。应用程序可以使用混合时钟来产生完美排序的时间戳，不发生碰撞，但我们不能强制使用它们。
相反，我们为消息定义了一个排序系统，通过使用时间戳来确定初始排序，并使用哈希值来打破冲突，从而确保总排序。总排序是有保证的，因为两个消息不能有相同的哈希值，除非它们是同一消息。两个消息a和b可以用这个算法进行比较：
如果a.timestampb.timestamp，则a更大。
如果a.timestampb.timestamp，则b更大。
如果a.timestamp==b.timestamp
-如果a.hashb.hash，则a大。
-如果a.hashb.hash，则b更大。
-如果a.hash=b.hash，a==b
时间戳是作为数字比较的，而哈希值是作为字符串比较的。由于字符串的比较在不同的实现中会有差异，我们必须在比较算法中精确。我们认为，两个哈希值x和y可以通过比较每一对字符来进行比较：
如果所有的字符对都相等，并且x和y都终止，那么x==y
如果所有的字符对都相等，并且x先终止，那么yx
如果遇到一个不同的字符对xC，yC，那么如果ASCII(yC)ASCII(xC)，则yx
信息验证
除了消息类型的特定验证外，所有消息必须通过以下验证：
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被存储在一个两阶段的集合CRDT中，解决消息之间的冲突。
一个Cast可以通过CastAdd消息来添加，该消息被放置在CRDT的add-set中。每个Cast都被其哈希值所索引，除非Cast是相同的，否则哈希值保证是唯一的。推而广之，两个添加消息永远不会冲突，除非它们是相同的，在这种情况下，一个可以被安全地丢弃。
Cast可以通过CastRemove消息来移除，该消息包含对目标CastAdd的哈希值的引用。当收到该消息时，如果目标存在，则从add-set中移除，而移除则被添加到rem-set中。添加和删除之间的冲突用Remove-Wins规则处理，而删除之间的冲突用Last-Write-Wins规则处理，在平局的情况下回到lexicographical排序。
添加信息
一个CastAdd可以包含最多20个字符的unicode文本和两个最多个字符的URI。客户端负责将URI和文本一起解码和渲染。
没有父代的Cast是一个顶级的Cast，客户应该显示在用户的个人资料或时间线上。有父代的cast是对另一个cast、webURL或链上对象的回复，应该在一个线程中显示。
投票形成一系列的树，每个根是一个投票或URI，每个子节点是一个回复投票。每个树都可以被渲染成一个线程对话。树被保证为非周期性的，因为在子节点指向它之前，父节点必须被散列和签名。对父节点数据的任何改变都会破坏与其子节点的所有关系。
Cast信息必须通过以下验证步骤。
文本必须包含=20个有效的unicode字符
embed必须包含0到2个项目
项目必须是一个最多个字符的URI
如果存在父代，必须是一个有效的URI，不等于这个消息的URI（例如，fid:/cast:）。
删除信息
CastRemove只包含一个对CastAdd的哈希值的引用。它允许永久删除Cast，同时删除原始Cast的数据。
该消息必须通过以下验证步骤:
message.data.body.hash必须不等于message.envelope.hash。
message.timestamp必须=系统时钟+10分钟
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，如果rr，丢弃r；如果r
Actions
Action是用户对一个目标进行的公开操作，这个目标可以是另一个用户，也可以是链上活动。目前支持两种类型的操作：喜欢和