Iroh的智慧

正如我们之前写过的，Lambda 的我们大多数都是互联网原住民。塑造我们人生的经历包括通过 IRC 与世界另一端的人们相遇，通过 BitTorrent、维基百科和软件版本控制系统分享知识、媒体和代码，第一批搜索引擎的诞生，以及 一切 都可以访问的感觉。然后我们长大后，发现这种体验尚未扩展到成为成年人所需的金融任务，并且像 围墙花园 这样的术语更好地描述了我们互联网家园的新状态，这让我们感到沮丧。

这就是为什么当我们了解像 Iroh 这样的项目时，我们会感到双重的兴奋：一个项目以一种赋予用户更多自主权的方式构建分布式系统，这种情感上的牵引，以及他们为实现它而解决的技术挑战带来的极客般的刺激。

它是什么？

Iroh 是一个分布式系统工具包，专注于轻松建立可靠的 p2p 连接。它包括建立直接连接、移动数据、同步状态和可插拔的应用层协议的设施。它正在生产中运行，并以低服务成本管理了同一网络上的 20 万个并发连接和数百万台设备。

用他们自己的话说：

Iroh 是一个库，用于在两个设备之间建立尽可能直接的 QUIC 连接。每个 端点 都使用加密密钥对的公共部分来标识自己。假设至少有一个配置的 中继服务器 可达，则端点保持与“主中继”的恰好一个 TCP 连接，其他节点使用该连接进行连接建立，并作为备用传输。Iroh 使用一套 发现服务 来解析主中继和端点 ID。端点之间的连接使用 QUIC ALPN 来区分 协议，而 路由器 自动化端点接受循环以进行协议多路复用。

我们喜欢 Iroh 的一点是，它清楚地说明了它的用途。它运行在 QUIC 上，最初是 IPFS 的一个新实现，经历了多次迭代，并缩小了范围，以便更好地解决他们所面临的问题。他们在其 Smaller is Better 和 Roadmap 帖子中写到了这个过程，我们完全同意这是一个良好的工程实践。

Iroh 可以用来做什么？

Iroh 背后的公司 n0 保留了一个构建在其之上的项目列表，但要快速了解，它可以用于任何需要文件同步、p2p 游戏流媒体、分布式对象存储、对等点发现和群组成员资格、本地优先设计或计算作业编排的场景。

我们的合作伙伴之一 Nous Research 正在一个去中心化程序中使用它，该程序依赖 iroh 来管理训练 LLM 的节点之间的通信，在客户端之间发送消息以推进网络状态并共享每个节点计算的梯度。

今天，我们采访了该团队以获得一些见解。

1. 许多 n0 团队成员是前 IPFS 或 libp2p 开发人员。首先要问的问题是 Iroh 与 libp2p 相比如何，据我们了解，答案与更紧密的关注点有关，保持核心在于使 p2p 连接正常工作，并将其余部分移至应用层协议，例如 iroh-gossip、-blobs 和 -docs，这些协议可以根据需要进行混合和匹配。你能详细说明一下这个过程以及缩小范围是如何帮助的吗？

b5：这个过程就是慢慢地摆脱大量的“p2p 项目包袱”。大多数 p2p 项目最终都默认采用“煮沸海洋”的姿态，他们试图交付所有东西的一个版本：一个 DHT、传输、发布/订阅、RPC，而且随着时间的推移，我们开始相信这是 p2p 项目感觉像是半成品原型的一个重要原因。当我们的 CTO dig 指出“没有人希望 nginx 团队交付 postgres”时，我们才明白过来。DHT 是一项艰巨的任务，可靠的同步是一项艰巨的任务，可靠的传输是一项艰巨的任务。去年某个时候，我们意识到用我们拥有的团队来交付所有这些东西是不可能的，所以我们选择了传输层，并且专注于与其他项目集成，并与 iroh 附近形成的社区一起完成我们无法交付的事情。我们打赌，如果像 loro 这样的项目交付可选的 iroh 支持，loro 团队创建一个真正强大的 CRDT，而我们创建一个真正强大的传输，事情会进展得更好。这两个团队都面临着使公共 API 尽可能小且可组合的压力，以使集成更容易。

其中很大一部分证明了 libp2p 在技术上是多么令人难以置信，尤其是当你看到如此多的语言实现时，这真是令人印象深刻。但是，如此多的工作伴随着巨大的 API 表面积，这使得将所有这些功能移植到一个在手机上运行良好的强大软件包中非常具有挑战性。它还创建了 libp2p 维护者致力于交付强大的 DHT 和 可靠的传输的期望。当我们更注重时，我们明确地意味着更少的功能，这些功能可以更一致地工作并且在各个组织之间集成。

2. 是如何决定使用 QUIC 的？几个月前，一些 研究 表明 QUIC 可能有一些缺点，并且似乎有传闻证据表明网络工程师对新协议怀有敌意。你的团队对这方面的任何方面有何看法？对于 Iroh 采用者来说，是否有任何可能源于 QUIC 使用的迹象？

b5：QUIC 的目标与我们试图用 iroh 做的事情非常相似：在互联网上 通过软件 交付新功能，因为更换硬件是不切实际的。QUIC 试图解决协议僵化的问题，因为路由器可以检查 TCP 标头，并且通过下降到 UDP 层并从那里开始工作来做到这一点。除了在“精神”层面保持一致之外，像 QUIC 多路径支持这样的东西似乎几乎是为我们确切的用例设计的。这是一项年轻的技术，我们全力以赴。

我没有听到太多来自网络工程师的敌意，但我并不感到惊讶。QUIC 有意试图减少路由器和互联网中间盒的可见表面积，我确定这会令人沮丧。我恰好认为互联网中间盒一开始就不应该干预这些数据包，但嘿，这只是我 😄

3. 你提到 Iroh 已经在同一个网络上看到了数百万台设备。这与公共 Iroh 中继有关还是在其他上下文中？你看到的可扩展性限制是什么？在哪些情况下？

我们看到的最大数字来自应用程序开发人员将 iroh 作为现有应用程序更新的一部分进行部署。其中每一个都以不同的方式强调了 iroh。在过去的 6 个月中，我们一直在针对这些压力测试进行交付。这绝不是完成的事情，但它为我们提供了生产中的反馈，这对于我们今年晚些时候完成 1.0 版本至关重要。

4. Iroh-gossip 作为 HyParView 和 Plumtree 的现代实现尤其有趣。是什么让你选择这些协议？你是否对该协议进行了负载测试？你通常的测试和负载测试方法是什么？

b5：电话。如果我们要让 p2p 在移动设备上工作，那么使用大量连接来补偿高网络 churn 的“星形”拓扑根本不可行，这使得 PlumTree 中的主动/被动划分特别有吸引力。在我撰写本文时，我们 discord 中的某个人正在使用 erlang supervisor 运行 2000 节点 iroh gossip 压力测试，所以是的，它正在被测试！我们还有一系列冒烟和模拟测试，这些测试作为 CI 的一部分针对 iroh gossip 协议运行。

Gossip 最近越来越受到关注，这促使我们投入更多时间。我们团队的 Frando 一直在积极致力于稳定性，正如我们所说。

5. 你鼓励用户为他们的网络设置自己的中继，但你也非常慷慨地提供你提供的三个公共中继。除了避免速率限制之外，为什么还要使用私有中继？是否有任何安全或其他功能方面的考虑？

b5：完全可以使用公共中继！老实说，我们很乐意看到更多使用，以便我们可以更多地强调它们:)。温馨提醒大家：中继流量是 e2ee 的，因此中继看不到流量，但是中继 确实 有一个 nodeID 列表，以及它们正在促进的连接列表，这是特权信息。我们许多更认真的用户正在使用私有中继来避免将该信息暴露给公众，甚至暴露给数字 0，这是我们认为工作正常的事情。我们有一些计划正在制定中，提供一项补充服务，这将使启动中继非常容易。请继续关注！

6. 在开发分布式系统时，可观察性成为首要关注的问题。Iroh-doctor 似乎是一个很酷的工具。Iroh 是否提供其他工具来观察和调试其内部或应用程序？Iroh-metrics 在这方面发挥什么作用？

b5：我们正在积极地致力于此。在 p2p 系统中收集可操作的网络指标至关重要，因为我们将 p2p 变成一个成熟、可靠的事物。在未来的几个月中，我们将有更多关于此的信息要说。

7. P2P 系统通常会披露参与节点的 IP 地址，并且 Iroh 明确选择让应用程序在（如果有的话）在这方面具有灵活性。你认为通常会采取哪些选择，并且应用程序可以实施哪些机制（除了 VPN）？

b5：我应该澄清一下，iroh 中的任何连接 总是 会将你的 IP 地址暴露给你拨号的对等方，以及你的节点用作其主页的中继服务器。你每天使用的 如此多的 服务也是如此，因此 iroh 在这方面并不是什么新鲜事物。话虽如此，VPN 很少是一个坏主意，并且我们明确地在 n0 员工之间运行一次性测试，我们在其中启动一个大型文件传输并在传输过程中打开和关闭 VPN 以确认它是否有效（剧透：它确实有效）。

连接用户的影响对于每个应用程序都将不同，但我们通常要求人们动动脑筋：如果你的应用程序是 5-100 人的仅限邀请的聊天室，那么将 iroh 连接与房间成员资格结合起来是有意义的。如果你的应用程序是，比如说，twitter，那么你可能需要引入一种新的选择加入机制，该机制向用户明确表明你正在披露可能被滥用的内容。

8. 本地优先软件运动（优先考虑用户数据存储和处理在他们自己的设备上，而不是依赖云服务器）是新的并且正在慢慢获得关注。你是否认为 Iroh 会在这种情况下使用，还是大多数主要用户都专注于其他用例？

b5：是的。我们非常喜欢本地优先，并且认为 p2p 是获得既是本地优先又是联网的软件的唯一途径。用户代理、p2p 和本地优先的共同点是向终端用户的设备交付比我们传统上从今天的“API 上的视图层”应用程序中获得的更多功能。

9. 将 Iroh 与 CRDT（如 automerge）结合似乎是一种常见的模式。Iroh-docs 似乎是为了成为一个分布式键值存储，但它是基于基于范围的集合协调。你是否认为这些更高级别的使用模式会被编纂为其他协议？是否有其他正在开发的协议，或者你是否认为任何特定模式可能会成为未来的协议？

b5：是的，iroh + automerge 绝对是“按预期使用 iroh”，并且你提出了一个很好的观点：存在一些常见模式，例如消息引导、增量更新和成对协调，这些模式在一堆协议中都很常见。为了能够真正让这些协议共享这些模式的抽象，我们需要比我们目前拥有的更强大的协议组合故事，因为我们需要一种协议来表达依赖关系并进行协议版本匹配的方法，该匹配跨编译时注册的协议集。即使那样，也需要像 automerge 这样的项目的支持，但这实际上不是我们的目标。

我认为这需要数年时间，但我确实认为我们会到达这样一个地方，我们可以声明一个协议的依赖关系图，编译器将能够告诉你是否存在版本不匹配，并且我们将能够进一步分解这些模式作为一个社区。我在这方面做一些实验，但在我们削减 iroh 1.0 之前，不要期望看到这方面的任何内容。

10. 你已经写过 使用 async rust 的挑战，我们当然可以理解！根据我们的经验，Greenspun 第十条规则适用于转换为分布式系统（有时称为 Virding 规则）“另一种语言中任何足够复杂的并发程序都包含一个临时的、非正式指定的、充满错误的、缓慢的 Erlang 一半的实现。”你在使用 actor 和消息传递方法方面的经验如何？在 Rust 中实现 Iroh 时，以及更普遍地在使用 Iroh 构建通信系统时？

b5：lol 是的，非常符合一半 Erlang 的说法。我们现在非常处于 iroh 的恐怖谷中。大多数内部结构都是使用 actor 实现的，但我们尚未将其形式化为 actor 抽象，并且不清楚我们是否会这样做。这种痛苦更加明显的地方是在协议级别。在协议开发级别，拥有易于实现的模式会非常好，这些模式围绕分布式容错进行抽象，并为你提供 supervisor 树带来的“随时失败”的特性。协议开发也在堆栈中的正确高度，处理逻辑消息而不是原始数据包。

我们仍在为编写协议提供教程奠定基础，但我很乐意看到我们花更多时间来编写基于 actor 模型之上的协议开发的配方。

11. 你的 路线图 非常清楚，webassembly 支持是被频繁请求的并且最近已合并，并且对于希望在浏览器中使用 Iroh 而无需通过中继发送所有数据的客户端，更好的支持正在进行中。在更遥远的路线图中，一些值得注意的项目是规范和 FFI 集成。你能否详细说明它们的重要性或动机？你是否对 1.0 的到期时间有任何估计，对推动即将推出的功能有什么看法？你最兴奋的是什么？

b5：规范部分很有趣，因为 iroh 可以很容易地表达为现有规范的组合，这是我们的计划。在我们看来，1.0 意味着你清楚地知道这个东西是什么，以及它 应该 如何表现，所以为什么不将其写在规范中呢？也就是说，我们更关心的是可用的软件而不是规范，并且认为花时间编写规范是确认我们已经考虑了作为 1.0 推送的一部分所需的一切，并且可以清楚地传达这种考虑手段。至于 FFI 绑定，我们 真的、真的 想要进入 rust 之外的语言，但我们有很多工作要做。有关 FFI 的更多信息将在 7 月至 8 月的时间范围内发布。当前 1.0 的计划是在 9 月的某个时候。

至于兴奋，我们团队的 Divma 和 Floris 几个月来一直在努力支持 QUIC 多路径。这是一项艰巨的任务，我们都非常兴奋地看到它结合在一起。

12. 是否有与其他语言的绑定或绑定计划？Iroh-ffi 似乎提供对 Python 的支持，它的状态如何？你是否计划提供对任何其他语言的官方支持？

b5：是的，我们有计划，但首先需要弄清楚围绕 UniFFI 绑定中基本上相当于鸭子类型的东西的一些困难的东西 :)

非常感谢 Iroh 团队抽出时间回答我们的问题！

参考文献

• https://www.iroh.computer/proto/iroh-gossip

• https://www.bartoszsypytkowski.com/hyparview

• https://asc.di.fct.unl.pt/~jleitao/pdf/dsn07-leitao.pdf

• https://www.bartoszsypytkowski.com/plumtree/

• https://asc.di.fct.unl.pt/~jleitao/pdf/srds07-leitao.pdf

• https://www.iroh.computer/proto/iroh-docs

• https://www.iroh.computer/proto/iroh-blobs

[简介

交互式证明是证明者 PP 和验证者 VV 之间的协议，其中证明者试图使验证者相信陈述的有效性。通过利用随机性和交互，验证者可以比通过执行所有操作更有效地检查语句](https://blog.lambdaclass.com/gkr-protocol-a-step-by-step-example/)

简而言之：这篇文章讨论了 Pod，这是一种新的共识概念，它通过消除副本间的通信，实现了 200 毫秒单轮往返的最佳延迟。我们相信这篇论文和 pod 网络的工作是开创性的，我们希望其他人分享我们对他们的工作的兴奋和热情，

1 月 26 日，Starkware 通知我们，他们发现在 Cairo VM 中存在一个关键问题，该问题与一个程序有关，该程序可以在 VM 上成功执行，但会违反 AIR 约束。修复程序已经在一个 PR 中实现、合并，并且已经发布和部署。

• 原文链接： blog.lambdaclass.com/the...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～