Web3去中心化社交网络-farcaster

Farcaster 是由Coinbase 前员工Dan Romero 和Varun Srinivasan 开发的Web3 社交网络。它是一个用于构建去中心化社交网络的底层应用协议，支持开发者在协议上搭建各种应用程序，且用户能够在不同应用程序之间自由迁移社交资源及身份。

taisen_1

2192人浏览 · 2024-12-15 20:44:12

taisen_1 · 2024-12-15 20:44:12 发布

一、项目简介

Farcaster 是由Coinbase 前员工Dan Romero 和Varun Srinivasan 开发的Web3 社交网络。它是一个用于构建去中心化社交网络的底层应用协议，支持开发者在协议上搭建各种应用程序，且用户能够在不同应用程序之间自由迁移社交资源及身份

核心价值

L1 用户身份管理合约

用户身份通过部署在ETH的合约来管理，用户身份包含以下

属性：a.唯一的数字标识符（例如8098）b.可以签署消息的 ECDSA 密钥对，使用的是ETH账户的公私钥）c .来自名称注册表的可选的修饰用户名（例如alice）

操作：a.注册（用户注册、管理员注册、批量注册）b.用户名找回 c.用户名的续费、转让、购买

L2 管理用户社交行为信息的farcaster Hub网络

a.Farcaster Hub 节点通过libp2p组件的gossipsub协议相互通信

b.使用Delta-Graph（增量图）将用户的社交信息分解成6种增量在多个Farcaster Hub 节点之间同步，一组增量在以任何顺序组合时总是产生相同的图，并且丢弃的消息可以在副本之间安全地重新共享而不会破坏图的状态，是通过使增量在图中具有可交换性、关联性和幂等性来简化同步。

c.用户发出的社交信息需要通过用户的密钥签名，Farcaster Hub 节点在更新信息是需要对签名做验证，避免恶意破外

二、项目架构与原理

项目架构

farcaster架构如上图所示：

L1 社交用户身份管理合约

实现用户注册、控制账户找回、用户名（域名）的转让与查询等

L2Farcaster Hub网络

a.Farcaster Hub 节点通过libp2p组件的gossipsub协议相互通信

b.使用Delta-Graph（增量图）将用户的社交信息分解成6种增量在Farcaster Hub 节点之间、客户端与Farcaster Hub 之间传输

c.共识算法使用pbft

d. hub的底层存储使用的是RocksDB

L2 网络部署架构

应用层

可以是手机端的APP，也可以是电脑端应用，也可以通过后端服务（server）连接网络

交互流程

用户在Farcaster Client上生成或者导入eth账户密钥作为社交身份的托管地址（custody address）。
用户使用Farcaster Client组装交易向区块链（ETH）的Farcaster合约注册社交身份
Farcaster hub监听合约的身份注册与变更事件，及时将用户信息缓存到hub
用户通过Farcaster Client发起社交行为（发帖、点赞、回复等），Farcaster Client将用户发起的信息使用托管地址（custody address）的签名并发送到Farcaster hub上
Farcaster hub验证Client对发送的消息验证签名，验证通过之后将消息广播给其他的Farcaster hub

社交用户身份管理

Farcaster通过智能合约的方式实现社交身份的管理，社交身份包括以下几个部分：

farcaster id：唯一的数字标识符（例如!8098）,通过在它们前面加上感叹号来区别于其他数字.用户将 fids 注册到以太坊地址(custody address)用户可以将 fid 转移到一个新的托管地址，尽管每个地址一次只能拥有一个 fid。
farcaster name：用户和组织的可选、人类可读的标识符，类似于web的社交用户名,用于社交过程展示
custody address：托管地址，是farcaster id和farcaster name的控制者，custody address的私钥用于社交消息的签名认证
recover address: 恢复地址，用户无法访问托管地址时，可以通过恢复地址来修改托管地址（custody address）来重新获得对farcaster id和farcaster name的控制。

社交身份的管理主要包括以下几个核心流程：

身份注册

用户通过DAPP生成或者导入一个以太坊账户作为 custody address，该账户私钥在Farcaster DAPP中去中心化保存；
用户通过DAPP调用合约的BundleRegistry合约的register接口注册farcaster id和farcaster name，该交易通过custody address的私钥签名，注册的时候需要设置recover address；
DAPP监听链上事件注册成功事件，将用户的farcaster id保存到本地。

身份恢复

当用户身份的托管地址（custody address）的密钥丢失，需要恢复身份；
用户通过recover address向Registry合约发起requestRecovery交易，申请更换托管地址（custody address）；
等待冻结时间结束（requestRecovery），用户通过recover address向Registry合约发起completeRecovery交易，完成恢复操作；
用户可以用新的托管地址操作Farcaster身份。；

身份验证

用户通过client发起任何的社交行为（发贴、点赞、转发、评论等），都需要用户使用custody address的私钥对社交数据进行签名；
Farcaster Hub在收到client消息之后，查看本地是否有缓存farcaster id的custody address，如果没有向Registry查询custody address；
Farcaster Hub通过社交数据原文与签名，恢复出签名地址，与custody address比较，确定签名是否正确；
验证通过的消息会在Farcaster 网络中传播，并通过Farcaster name来标识用户。

Delta-Graph（增量图)--核心技术

增量图是一种数据结构，用于表示和同步多个副本之间的社交网络状态。社交网络的状态是一个图，其中每个顶点都是一个实体，例如用户或消息，每个边是实体之间的关系。@alice 创建一条消息并且@bob 点赞并回复它的网络将生成此图：

该图分解为一系列增量这有助于在去中心化的网络进行同步。增量是用户执行的操作，例如发布消息或喜欢某事。Farcaster 协议定义了六种类型的增量：

Signers- 授权代表用户签署消息的密钥对，增量图中的每条消息都必须由有效的签名者签名，除了签名者本身必须由有效的保管地址签名。用户可以随时使用和来添加和删除签名SignerAdd者SignerRemove。
Cast- 公开，用户发布的信息，其中包含一些文本并显示在他们的帐户上。Casts 还可能包含指向媒体、链上活动甚至其他 casts 的 URI。创建cast的用户也可以随时删除cast
Reactions- 用户和对象(消息)之间的图形关系，可以是 cast、url 或链上活动。两种类型的反应是喜欢和取消，协议可以扩展以支持新类型。可以随时添加和删除反应，并代表社交图中的边缘。
Amp- 两个用户之间的图形关系，它们可以随时添加和删除，并代表社交图中的一条边。
Verifications- 用户创建的资产所有权证明，验证是 Farcaster 账户和外部账户之间的双向加密所有权证明。它们可用于证明以太坊地址、特定 NFT、社交媒体帐户或域名的所有权
UserData- 用户添加的用户元数据，用户数据存储有关用户的元数据，例如他们的个人资料图片或显示名称

每个增量都是一个原子操作，可以将一个或多个顶点或边添加到社交图。一些增量可能会在单个操作中添加多个节点和边缘上例中的图表可以分解为以下增量：

同步

增量图必须能够在不可靠的网络中同步社交图。如果一组增量在以任何顺序组合时总是产生相同的图，并且丢弃的消息可以在副本之间安全地重新共享而不会破坏图的状态，是通过使增量在图中具有可交换性、关联性和幂等性来简化同步。

幂等性：要求增量不会多次应用于图形。如果@alice 喜欢@bob 的发文，但她不小心发送了两次 delta，则不能算作两次喜欢。增量必须包含唯一标识符，这是增量操作字节的哈希摘要。增量图根据所有已知的增量检查任何新增量的标识符，如果重复则将其丢弃。

交换性和结合性：要求一组增量总是产生相同的图。如果@alice 喜欢@bob 的发文但后来又不喜欢它，则会生成两个冲突的增量，这些增量会更改图形的相同部分。增量必须有一个冲突标识符和一个总的排序规则。当两个 delta 具有相同的值时，delta graph 会丢弃顺序最低的 delta价值

增量的冲突标识符：必须唯一标识它修改的边和顶点。具有相同的delta c必须更改图形的相同部分，并且具有不同的增量c值必须改变图形的不同部分。在相似和不同的例子中，三元组(bob, like, Hello World!)足以作为c两个增量的值。增量还必须具有用户报告的时间戳, 连同标识符可以产生总排序。这样的排序在副本之间是确定性的，因为它不依赖于接收时间。

增量图需要满足CRDT（无冲突复制数据类型）的特性具有以下特点：

应用程序可以独立、并发地更新任何副本，而无需与其他副本协调。
算法（本身是数据类型的一部分）会自动解决可能发生的任何不一致问题。
尽管副本在任何特定时间点可能具有不同的状态，但它们保证最终会收敛。

排序

时间戳顺序，每个增量都有一个时间的字段，它源自用户报告的时间戳，不可信，时间戳来至用户
字典哈希顺序：字典哈希顺序是总的，因为每条消息都有一个唯一的哈希值。它是任意的但具有确定性，CRDT 将它与时间戳顺序结合使用来解决冲突
逻辑排序：增量可能有一个可选的、由用户设置的因果顺序

权限验证

每个增量类型可以定义不同的规则来管理用户可以更改的内容。用户通过使用非对称密钥对对增量进行散列和签名来验证增量。签名使 delta 防篡改，允许在不受信任的网络上传输。CRDT 检查用户修改的签名和图段，并且仅合并通过两个验证的更改。

冲突合并处理原则

每一种增量，都会定义一个冲突标识符，例如amp 消息由元组(fid, userId)定义冲突标号，如果两个增量，冲突编号一致，则认为存在冲突

如果收到一条新消息与任何一组中的另一条消息相同，就会产生冲突。此类冲突使用以下规则处理：

如果时间戳不同，则保留时间戳最高的那个。
如果一条消息是删除消息，而另一条消息是添加消息，则保留删除消息并丢弃添加消息。
如果时间戳相同并且两条消息属于同一类型，则保留具有最高词典哈希值的消息。

存储大小的限制

个可以永远增长的增量图将使中心的存储成本非常昂贵，从而对去中心化产生不利影响。节点运营商的数量会随着时间的推移而减少，而他们勾结和阻止参与者的能力将会增强。我们的目标是在许多地区拥有至少 100 个中心，以确保去中心化。限制硬件最多具有 64 TB 的附加存储，为了实现以下目标采取以下措施：

增量只允许包含少量文本，较大的有效负载必须通过引用存储。它们必须足够小以适合单个 TCP 数据包。IPFS 等专用存储系统可以承载更大的有效负载，应用程序可以在渲染时对它们进行水合。
用户只能存储有限数量的每种类型的增量。该协议选择的限制将使增量图的大小保持在 64 TB 以下。CRDT 通过逐出图中最早排序的消息来强制执行大小限制。由于增量总是完全有序的，这不会改变 CRDT 的保证。
只允许用户在固定时间内存储某些增量。使非常旧的增量过期允许我们回收空间，从而允许对最近的消息进行更慷慨的限制。这对于嘈杂的数据类型特别有用，例如用户更看重新近度的反应。只要集线器控制时钟偏移和漂移，基于时间的增量到期就可以是确定性的。

Farcaster Hubs

hub是 Farcaster 网络中同步增量图的节点。它类似于区块链节点，但具有不同的共识机制。hub从客户端获取增量，通过对等协议将它们广播到其他hub 节点。他们听取来自以太坊区块链的更新，并根据需要更新增量图的身份状态。

hub之间的同步协议简述如下

1、hub通过libp2p组件的gossipsub协议相互通信主要包括：Peer节点发现、验证节点、处理网络故障和攻击、广播增量消息

2、新的Hub通过连接已知的Hub 节点来加入网络，然后通过差异同步从选定的Peer节点下载所有已知的增量。
3、gossiping更新并不能保证最终的强一致性，为了解决这已问题，Hub会定期选择一个随机Peer节点并执行完整的差异同步以确保它们捕获任何丢失的消息。

同步树

hub使用Merkle Patricia Trie来跟踪和同步已知的增量。为每个增量计算一个唯一的同步 ID 并将其插入到 trie 中。同步 ID 的长度为 36 个字节，前 10 个字节保留用于增量时间戳，其余字节保留用于增量存储密钥。存储键唯一标识具有相同时间戳的增量，并允许从存储中查找增量。使用以时间戳为前缀的 id 使同步 trie 按时间顺序排列，最右边的分支包含最新消息的同步 id。

差异同步

通过比较排除集可以快速区分两个同步尝试，这利用了尝试按时间顺序排列的事实，新消息主要添加在右侧。排除节点（绿色）是与最新分支（红色）中的节点共享父节点的节点。将每个级别的排除节点组合并散列，为 trie 的每个级别生成唯一的排除值。trie 中所有级别的排除值集合是排除集，它是[hash(2021), hash(oct, nov, dec), hash (1, 2)]下面人类可读的示例 trie 中的数组。

通过从左到右比较排除集，可以在恒定时间内确定两次尝试发生分歧的点。在下面的示例中，第一级hash(2022)和第二级hash(feb)相同，但第三级不同：hash(10)vs hash(10, 11)。父节点mar是两次尝试的分歧点。差异同步然后移动到第二个短语，其中集线器请求发散节点下的完整 trie。然后将这些尝试与在对数时间内工作的更传统的差异算法进行比较。最后，缺失的分支被转换为同步 ID，从另一个集线器请求并合并到集线器的状态中以使其同步。