在去中心化系统中，群聊应该如何运作？

# 去中心化系统中的群聊应该如何运作？ 来源: https://marindedic.com/groups/ ## 引言 我最近发布了Kiyeovo (https://github.com/Realman78/Kiyeovo) 的初始版本——一款去中心化的P2P即时通讯桌面应用程序。 我无法强调我在群聊设计上投入了多少时间。我想到的每个模式都存在重大缺陷，而这正是“无服务器”带来的痛点。我意识到没有“最佳”实现方式，为了保持应用的完全去中心化，我必须做出一些权衡。 ## 为什么服务器能让群组变得简单 有了中心服务器，你就拥有了一个可信任的权威机构，用于回答以下问题： 1. 目前群组成员有谁？ 2. 用什么密钥加密消息，谁应该有这个密钥？ 3. 消息发生的顺序是什么？ 4. 我离线时错过了什么？ 即使是端到端加密的应用程序，虽然无法读取你的消息，但仍然使用服务器来处理这些问题。 - Signal的服务器存储群组成员名单（并转发消息） - Matrix的服务器存储群组状态并排序事件 它们将群组状态提供给新加入的用户，并简单地阻止被移除的用户接收更新和消息。内容是加密的，但协调工作——谁在群里、最新状态是什么、消息顺序、离线时错过了什么——都由中心化服务器完成。 如果删除服务器会发生什么？再也没有一个“地方”能确切知道成员名单，没有用于排序的序列器，也没有供离线用户使用的全天候邮箱。 ## 2. 其他去中心化系统如何处理——以及我为何另辟蹊径 有很多种方法，以下是我考虑过的一些方案。 ### (a) 保留协调服务器 (Signal, WhatsApp, Matrix) 内容采用端到端加密，但服务器（或主服务器）仍然持有之前描述的一切。群组密钥方案通常是： - Sender keys: Signal —— 每个发送者一个对称密钥，当成员离开时轮换密钥 - Megolm: Matrix —— 每个发送者的ratcheting会话，在成员离开/加入时轮换 **为何不选：** 这直接被我否决，因为它包含中心化，这是我的底线之一。这违背了无服务器应用的目的——网络需要在没有“特权”节点的情况下持续工作。 ### (b) MLS / TreeKEM (RFC 9420) MLS是群组加密的最新技术。每个成员的密钥排列在一棵树中，因此当你添加或移除某人时，只影响树的一部分。换句话说，它非常可扩展——即使在数千人的群组中也保持快速。 **为何不选：** MLS需要一个“投递服务”来分发其密钥更改消息。在没有服务器、基于DHT、节点可能离线的情况下实现这个……非常复杂。而且，这种树结构只在大型群组中才有优势，而Kiyeovo的群组上限是10人。 ### (c) 无领导成员管理 允许任何成员添加或移除其他成员，并通过某种合并逻辑最终收敛。权威完全去中心化——根本没有管理员。 **为何不选：** 当两个人同时更改成员资格时，不同节点最终会看到不同的群组成员列表。虽然最终可以合并回来，但合并规则变得复杂。例如，在没有可信时钟的情况下，无法回答排序问题。“X是在发送消息之前还是之后被踢出群组的？”这个问题在成员对“全局事件顺序”没有共识的情况下无解。我考虑过引入工作量证明层，但那样太重了。 ### (d) 创建时固定成员 (例如Briar风格的私人群组) 一些P2P应用通过不支持动态成员管理来完全规避这个问题：成员集合在群组创建时固定，之后无法添加或移除任何人。 **为何不选：** 这实际上是我的最初想法。但是，无法邀请或移除成员对我来说是太大的缺点。在写这篇文章时，我实际上在想我所在的群组变更成员的频率，答案是——并不频繁。这会让事情简化很多，但现在动态群组已经实现并正常工作，所以相当不错。 ## 3. 我实际是如何实现的 **规则：没有任何服务器，收敛过程要简单。** ### 3.1 成员管理：一位创建者 每个群组都有一个创建者，由Ed25519密钥标识。所有其他成员都有创建者的密钥，以便他们可以确认更新确实来自创建者。**只有创建者可以邀请和踢出成员**。想要离开的成员发送一条签名的离开请求，创建者应用移除操作。 - **优点：** 不会出现“两个管理员在分区期间踢了不同的人”的合并问题——只有一个合法的成员状态写入者。当只有一个作者时，收敛很简单——这实际上与方法(c)相反。 - **缺点：** 创建者是单点故障。如果他们丢失了设备（身份）或不在线，现有成员可以继续使用当前密钥交流，但无法添加或移除任何人（用户可以离开并不再接收消息，但其他群组成员不会收到X已离开群组的验证通知）。 ### 3.2 密钥：每个epoch轮换的Sender keys 一个**epoch**只是一个“群组版本”。每个epoch有一个由整个群组共享的随机32字节对称密钥。消息使用XChaCha20-Poly1305加密，密钥就是这个对称密钥。为了分发密钥，创建者将密钥分别密封给每个成员（使用每个成员的公钥加密），放在一条签名的控制消息中，然后投递到他们的私有收件箱。 - **优点：** 重新密钥成本是O(n)个密封副本。群组上限是10人——非常轻量。 - **代价：** 没有在epoch内的轮换，因此在稳定群组中没有持续的向前保密。 ### 3.3 轮换：成员变更触发密钥轮换 加入、离开和踢出会创建新的epoch。新成员只会收到他们加入的epoch的密钥，因此无法读取更早的历史。 在libp2p中，主题基本上是“频道”。如果你订阅了一个名为“cars”的主题，你会收到该主题的消息。这就是群组实时消息的工作原理——你向一个主题发送消息。当然，消息是加密的，所以即使有人猜到了主题（基本不可能），也无法解密消息。为什么我说猜到主题基本不可能？主题名称是从群组密钥派生出来的，因此轮换密钥的同时也轮换了主题。被移除的成员甚至无法计算新主题，更不用说订阅了。 ### 3.4 群组状态分发：DHT中的追加日志 群组元数据（成员列表、每个发送者的序列边界[稍后解释]）存储在DHT中，有两种记录类型： - 一个可变的“最新版本”指针 - 一条由哈希链接的不可变版本记录链——一个追加日志，每个条目由创建者签名并链接到前一个条目的哈希。 载荷（成员更新）使用前面提到的每epoch密钥加密。 - **优点：** 为离线成员提供了群组“演进”的可验证历史。此外，DHT验证器会拒绝任何不推进群组或未经创建者签名的内容。 - **代价：** 这是“最后写入者胜出”，只有一个写入者时才是安全的。 ### 3.5 排序与离线：每个发送者的序列，每个发送者的桶 每个发送者维护一个序列号，用于每个`(群组, 主题/epoch)`——序列号基本上是“这是我的第N条消息”。接收者可以据此检测某个发送者的消息缺失。 当某人离线时，他们的消息存储在DHT中。然而，这里没有按接收者划分的桶，而是**按发送者划分**——让我解释一下，因为这不常见。每条发送的消息都写入发送者自己的桶中（针对当前epoch）。当用户上线时，他必须扫描`群组 x 成员 x 未关闭的epoch`个桶来获取所有离线消息。为什么这样做？因为在我看来，其他替代方案更糟糕： 1. 使用按接收者划分的桶 —— 发送消息时，发送者需要写入`群组 x 成员 x 未关闭的epoch`个桶。除此之外，他还需要跟踪每个发送者的*未关闭的epoch*，这又引入另一套问题和低效。 2. 使用共享桶 —— 桶名称包含其所有者的公钥签名，以防止其他用户篡改（DHT验证器强制执行这一点）。我曾经考虑过只需将所有公钥签名包含在桶名称中，但这样就要处理多个用户同时写入同一桶，甚至重写整个桶的问题。这很快就会变得很糟糕。 所以，总的来说，我选择的方案似乎是最好的。 ## 权衡 - **单创建者权威**是最大的问题。单点故障，以及中心化的信任。 - **Sender keys，而非MLS。** 实现了跨epoch的向前保密和移除后的安全性，但没有epoch内的ratchet。对于≤10人的群组来说，我认为可以接受。 - **公钥加密密钥包装**我复用了1对1消息中已有的身份密钥对，但这不是现代的默认做法。 - **尽力而为的排序**——相比于有时钟的系统存在局限性。 感谢阅读。如果您有任何建议或问题，请使用页脚中的联系方式与我联系。