Ed25519支持登陆Chrome：让网络更快速、更安全
我们很高兴地宣布，Ed25519现已获得Chrome浏览器（版本137）的支持。继2024年8月Firefox 129和Safari 17.0之后，Chrome也于今年5月发布的137版本跟进了这一功能。现在所有主流浏览器引擎都已支持Ed25519，覆盖了79%且仍在增长的网络用户。
Ed25519是一种密钥类型，最著名的是它是生成和验证椭圆曲线密码学签名的最小且最快的常用密钥。数字签名算法让你能够证明某段数据是由持有特定私钥的人创建的，而无需透露该密钥。它们对于验证软件更新、Git提交、加密货币交易至关重要，在像IPFS这样的分布式网络中，还用于验证对等身份并快速建立对等信任。
WebCrypto API中的Ed25519对开发者意味着什么
为什么浏览器支持Ed25519很有价值？如果你来自传统Web开发领域，可能已经熟悉了常见的哈希算法（如SHA-256）和密钥类型（如RSA），这些是"基础能力"（通常甚至可以通过标准库获得），除非你有非常小众的加密需求。对Ed25519的内置支持代表了一次全面的重大升级，将Ed25519带入了"基础能力"的范畴，开发者可以停止担心并将其视为理所当然。
主要优势包括：
- 更小的占用空间：Ed25519密钥仅为32字节（256位），而同等安全级别的RSA密钥需要256+字节。签名大小为64字节，而RSA需要256+字节。
- 更快的操作：签名验证比RSA快大约10倍，并且 consistently 比ECDSA快。签名生成也更快。
- 设计安全性：Ed25519从头开始构建，以抵抗时序攻击，使用确定性签名（没有可能出错的随机数生成），并提供大约128位的安全级别——相当于3072位的RSA密钥。
- 更简单的实现：与ECDSA不同，Ed25519不需要开发者处理棘手的参数或担心可延展性攻击。
Ed25519签名密钥长期以来一直是除浏览器外各处最顶级的密钥类型和签名之一，用于支持日常连接协议，如SSH（远程终端）和sFTP（文件传输）和PGP（加密电子邮件）以及各种应用。但直到现在，如果你的Web应用需要验证Ed25519签名（例如，验证Git提交或通过基于SSH的服务进行身份验证），你必须捆绑自己的密码学库，这通常可以占到你今天使用Ed25519签名的Web应用"重量"（下载大小）的一半！
当然，Ed25519签名不仅使支持长期存在的协议变得更容易，它们也为许多尖端和前瞻性的身份系统提供动力。例如，Radicle，一个开放世界/去中心化的git社区，使用EdDSA密钥作为用户名，并要求所有存储库都由它们签名（因为几乎所有跨语言的git工具在操作系统级别都默认使用EdDSA密钥管理器）。像Radicle这样的身份系统并不是唯一能够从在浏览器中生成或检查签名中受益的；大多数"本地优先"软件，当然还有所有基于内容可寻址数据的软件也会受益。例如，许多web3应用程序和分布式系统通常使用内容寻址的信封和文档，而不是扁平的、传统的授权令牌。其中的两个，UCANs和BeeHive（UCANs的本地优先/CRDT变体），通过给每个进程、容器和资源一个EdDSA密钥，来扩展CRDT和分布式工作流，以便所有这些授权文档都可以在任何信任边界（包括最终用户的浏览器中）快速且廉价地检查。在任何这些系统上制作安全的验证器或Web视图，其构建速度刚刚提高了几天，甚至几周，这导致二进制文件更小，小到它们因此可以去更多地方。
随着Ed25519现在进入WebCrypto，这些操作变成了一个简单的浏览器API调用——没有外部依赖，没有捆绑包膨胀，并且性能更好。这个"轻量级"的限定词是对日益加密的网络公共资源的主要贡献（并且是一个反直觉地非常重要的贡献）。未来的网络将越来越多地积累环境可验证性（即使对于不支付CDN税的发布者也是如此！），并且许多其他下游效率来自于能够连接EdDSA密钥，这些密钥在普通最终用户的操作系统和平台的其他地方已经无处不在。
从想要到拥有的旅程
你在本博客上看到的大多数更新都是关于让IPFS与今天的网络更好地协作。最近，我们写了关于通过仅限HTTPS的网络使用AutoTLS启用真正的点对点连接的文章，在此之前，IPFS Shipyard团队有一系列稳定的改进，使得更容易通过网络平滑地发现和分发IPFS数据。但有时，如果你的梦想足够大，并且投资时间跨度足够长，你实际上可以让网络工作得更像IPFS。近年来，随着密码学逐渐融入Web标准，出现了一场更广泛的运动，朝着更加基于哈希的、无需信任的网络发展，因为反应式、边缘缓存、CDN支持的网络将用户期望转向越来越好的用户体验。干预这一趋势并提供资金在Web标准中进行缓慢、不懈的推动，为更符合IPFS原则的网络播下了种子。
网络标准实际上是如何管理的
事实上，网络在我们大多数人有记忆以来就已经是全球性的了，即使我们中那些年纪大到记得它普及前阶段的人，也很难记得那时每个浏览器对HTML互操作性以及HTTPS和TCP/IP细节如何稳定配置采取漠不关心态度的混乱Web开发日子。标准化网络几乎和使其全球化或盈利一样是一个漫长而复杂的技术社会过程，并且涉及在邮件列表上的大量嘲讽，远在GitHub线程和Slack服务器开辟新的嘲讽表面之前。将软件标准迭代和微调到多个完全独立的浏览器在如何渲染给定的混乱标记语言（更不用说JavaScript了！）方面可以被证明是统一的程度，是一项持续且大规模的基础设施成就，至今仍在进行中。
这项维护工作由一个全球性的社区领导，有许多志愿者、报酬过低的专家和疲惫的学者提供额外的耐心和人力。他们的奉献使网络成为一个持久和开放的信息平台，如果完全留给大型商业参与者，它可能会退化为仅仅是商业的管道。当你想到Web标准时，人们自然会想到围绕特定技术的重大决策和治理困境：JavaScript如何被沙盒化和策略绑定以安全地跨域运行，CSS在层叠覆盖这些相同域时如何被继承、细致化和处理最后一英里异常等等。较小的语言、在网络上运行的瘦协议（联合身份、社交网络、支付）、可访问性和本地化标准以及大语义学完善了我们称之为"Web标准"的其余部分，主要在万维网联盟（W3C）标准化，并定期与相邻的标准开发组织合作。
历史上，大多数关于密码学的辩论和标准化发生在网络下一层的IETF：根据经验，你可以说"网络"是为人及其混乱的语义而设，而"互联网"是一个由机器驱动的超集，这些机器可以标准化那些几乎没有人理解的东西。但越来越多地，为了使网络更安全（想想：通行密钥、FIDO、钱包），Web标准也越来越需要在全网范围内共享密码学的基本事实。这使得W3C中受到最密切关注的小组之一是"WebCrypto API"——浏览器开发者在这里商定将基本密码学构建块构建到浏览器本身的接口，通过将加密复杂性卸载到"Web平台"本身（关于整个网络在任何浏览器中如何工作的基本假设）来激励重用和透明度。WebCrypto接口为所有Web开发者提供了一个强大的外卖窗口，可以从中订购可靠和确定性的签名和哈希，这使得各种强大的构建块只需几行代码即可实现。例如，日益通用的子资源完整性模式允许Web开发中最重的部分（大媒体文件、由于安全和依赖树而经常更改的JavaScript捆绑包）被"校验和"，即通过哈希进行完整性保护。这与IPFS为Web开发带来的通用完整性保护完美契合；加速浏览器对更多子资源完整性机制的支持也使网络更易于支持IPFS，并使IPFS对未来的Web开发者更加直观。
Igalia、标准工作和实际采用
那么IPFS支持究竟是如何直接促使Ed25519成为浏览器默认功能的呢？答案涉及与Igalia长达三年的合作，这是一家员工拥有的开源咨询公司和合作社，自2001年以来已成为浏览器开发的主要贡献者。即使对于像这样相对简单的Web平台功能，投入的工作量也难以夸大。如果你想窥探幕后发生的事情，我强烈推荐Javi在2025年2月总结迄今进展的博客文章。
这次合作的具体重点是通过默认方式将Ed25519"引入浏览器"，并着眼于像Verified Fetch这样的工具。Verified Fetch不仅像任何其他客户端一样通过CID从IPFS获取内容，而且关键的是，它还验证每个块是否与其CID匹配。由于Verified Fetch需要能够尽可能接近"无形"地安装，将其下载大小减少两位数百分比是一个巨大的UX改进，这是通过将数学和逻辑外包给浏览器的内置库来实现的。
浏览器引擎上的PR比典型的开源贡献要复杂得多。它需要跨实现、规范、安全审查流程、性能审查流程、质量保证等进行广泛的协调。Igalia的Javier (“Javi”) Fernandez并行地针对所有三个主要的独立浏览器引擎驱动了PR，同时处理变更请求、细微问题和边缘情况，以确保所有三个引擎在任何配置或扩展组合下都以完全相同的方式处理任何输入。这项工作始于识别并修复了管理WebCrypto接口的W3C规范中的一个错误。三年多来，Javi系统地解决了3个浏览器代码库中的技术挑战，从低级C实现到API表面设计。
下一步是什么
Ed25519支持于2025年5月在Chrome 137中上线，加入了之前所有其他主要浏览器的行列。通常，新浏览器版本需要2-3年时间才能在用户中普及。我们预计，到2027年左右，开发者可以自信地开始在大多数用户的浏览器中依赖简单稳定的Ed25519支持。随着这一转变的发生，开发者可以从我们的软件包中减少重量，从测试和维护中减少复杂性，并减少加载时间和带宽。总的来说，这使得网络对每个人都更强大，并且更符合IPFS原则：简单、模块化和可验证。这是一个罕见的各方共赢的案例，整个网络也因此变得更加稳定和美好。
感谢Protocol Labs（发起与Igalia的合作）、IPFS基金会、Open Impact Foundation和WebTransitions.org继续引导这一倡议。更多使网络更简单、模块化和可验证的IPFS倡议和合作正在进行中。它们包括ElectronJS构建变体（以支持更好的协议处理）、浏览器扩展中更有用的协议处理（webtransitions主题），以及（我们希望）浏览器密码学API中的流支持！