使用区块链的原因之一：无信任性

我们使用区块链的主要原因之一是无信任性。这一属性承诺使我们能够自主访问我们的财富和数据。大多数时候，像以太坊这样的区块链已经兑现了这一承诺——我们的资产确实属于我们。

然而，为了便利我们做出了一些让步。一个这样的领域就是我们使用中心化 RPC（远程过程调用）服务器。用户通常通过中心化提供商如 Alchemy 访问以太坊。这些公司在云服务器上运行高性能节点，以便其他人可以轻松访问链数据。当一个钱包查询其代币余额或检查待处理交易是否已包含在区块中时，几乎总是通过这些中心化提供商之一进行的。

现有系统的问题在于用户需要信任这些提供商，而且没有办法验证其查询的正确性。

推出 Helios，这是我们开发的一种基于 Rust 的以太坊轻客户端，它提供完全无信任的以太坊访问。Helios—使用以太坊的轻客户端协议，这得益于 最近的转变 到 权益证明—将来自不可信的中心化 RPC 提供商的数据转换为可验证的安全本地 RPC。Helios 与中心化 RPC 协同工作，使验证其真实性成为可能，而无需运行完整节点。

在可移植性和去中心化之间的权衡是一个常见的问题，但我们的客户端——我们已向公众提供以供构建——大约在两秒内同步，不需要存储，并允许用户从任何设备（包括手机和浏览器扩展）访问安全链数据。但依赖中心化基础设施的潜在陷阱是什么？我们在这篇文章中讨论它们可能的后果，讲解我们的设计决策，并概述了一些供其他人参与 代码库 的想法。

中心化基础设施的陷阱：以太坊“黑暗森林”中的理论生物

在 黑暗森林 中潜伏着一种（理论）生物。这种生物并不在以太坊的记忆池中捕猎自己的猎物，而是通过模仿我们依赖的中心化基础设施设置陷阱。陷入这个陷阱的用户并没有犯任何错误：他们访问他们最喜欢的去中心化交易所，设置合理的滑点容忍度，像往常一样买卖代币……他们做到了一切正确的事情，但仍然成为一种新型三明治攻击的受害者，这是一种小心翼翼地在以太坊黑暗森林入口处设置的 trap：RPC 提供商。

在我们详细说明之前，让我们先看看去中心化交易所中的交易是如何工作的。当用户发送交换交易时，他们向智能合约提供几个参数——交换哪些代币、交换金额，以及最重要的，交易必须成功执行的用户最低代币数量。这个最后的参数指定交换必须满足“最低输出”，否则将回退。这通常被称为“滑点容忍度”，因为它有效地设定了在交易被发送到记忆池时和在交易被包含在区块中时之间的最大价格变化。如果这个参数设定得过低，用户就接受了接受到更少代币的可能性。这种情况也可能导致三明治攻击，其中攻击者有效地在两个恶意交换之间夹击该出价。这些交换提升了现货价格，迫使用户的交易以不太有利的价格执行。然后攻击者立即卖出以获得小额利润。

只要这最低输出参数设置在合理价值附近，你就可以避免三明治攻击。但是，如果你的 RPC 提供商没有提供来自去中心化交易所智能合约的准确价格报价，用户可能会被误导去签署一个较低最低输出参数的交换交易，更糟糕的是，交易被直接发送到恶意 RPC 提供商。相反，该提供商可能会将此交易直接发送给 Flashbots，确保自己独占利润，而不是将该交易广播到公共记忆池，数十个机器人竞争执行三明治攻击。

这种攻击的根本原因在于信任他人获取区块链的状态。经验丰富的用户通常通过运行自己的以太坊节点来解决这个问题——这是一个耗时且资源密集的过程，至少需要一台时刻在线的机器，几百GB 的存储空间，而且大约需要一天的时间从头同步。这个过程显然比以前更容易；像 Ethereum on ARM 这样的群体不懈努力，使得在低成本硬件（如带有外部硬盘的 Raspberry Pi）上运行节点成为可能。但即使用这些相对较低的要求，运行节点对大多数用户来说仍然很困难，特别是对于使用移动设备的用户。

重要的是要注意，中心化 RPC 提供商的攻击虽然完全合理，但一般来说是 简单的网络钓鱼攻击——我们描述的这个攻击尚未发生。即使较大提供商如 Alchemy 的履历给我们留下了不小的怀疑，但在将不熟悉的 RPC 提供商添加到你的钱包之前，进行一些进一步的研究值得。

介绍 Helios：完全无信任访问以太坊

通过引入其轻客户端协议（得益于最近转向权益证明），以太坊为快速交互以及以最低硬件要求验证 RPC 端点开辟了激动人心的新可能。在 合并 以来的几个月中，我们已经看到一批轻客户端相互独立出现（Lodestar、Nimbus 和基于 JavaScript 的 Kevlar），这些微客户端采用不同的方法实现同一目标：有效且无信任的访问，而不使用完整节点。

我们的解决方案 Helios，是一个大约在两秒内同步，不需要存储，并提供完全无信任的以太坊访问的以太坊轻客户端。与所有以太坊客户端一样，Helios 包含执行层和共识层。与大多数其他客户端不同的是，Helios 紧密耦合这两个层，因此用户只需安装并运行一个软件。（Erigon 也在朝这个方向发展，直接在他们的存档节点中添加一个共识层轻客户端）。

那么它是如何工作的呢？Helios 共识层使用一个之前已知的信标链区块哈希和一个与不可信 RPC 的连接来可验证地同步到当前区块。Helios 执行层使用这些经过身份验证的信标链区块，配合不可信的执行层 RPC 来证明关于链状态的任意信息，例如账户余额、合同存储、交易回执和智能合约调用结果。这些组件相互协作，以便为用户提供完全无信任的 RPC，而无需运行一个完整节点。

…在共识层

共识层轻客户端遵循信标链轻客户端 规范，并利用信标链的同步委员会（在合并之前首次引入于 Altair 硬分叉）。同步委员会是一个随机选取的 512 个验证者的子集，服务约 27 小时。

当一个验证者在同步委员会中时，他们会签署他们看到的每个信标链区块头。如果超过三分之二的委员会签署了某个给定的区块头，那么这个区块很可能在规范信标链中。如果 Helios 知道当前同步委员会的构成，它可以通过向不可信 RPC 请求最新的同步委员会签名，准确地跟踪区块链的头部。

得益于 BLS 签名 聚合，只需要一次检查就可以验证新头。如果签名有效且由超过三分之二的委员会签名，那么可以安全地假定该区块已被包含在链中（当然，它可能会被重新组织出链，但跟踪区块的最终性可以提供更严格的保证）。

然而，这一策略明显缺少一个重要环节：如何找到当前的同步委员会。这开始于获取一个称为 弱主观性检查点 的信任根。不要让这个名字让你感到害怕——它只是意味着一个旧的区块哈希， 我们可以保证它在过去某个时刻被包含在链中。实际上，关于检查点究竟可以有多旧的数学运算非常有趣；最坏情况下的分析表明大约两周，而更多可行性的估算建议许多个月。

如果检查点过旧，会有 理论攻击 可能欺骗节点遵循错误的链。获取弱主观性检查点的方式超出协议范围。我们在 Helios 中的做法提供了一初始检查点，该检查点被硬编码到代码库中（可以轻松覆盖）；然后将最新的最终哈希存储在本地，以在将来的同步时将其用作检查点。

方便的是，信标链区块可以进行哈希处理以生成唯一的信标区块哈希。这意味着可以轻松请求一个节点完整的信标区块，然后通过对其进行哈希处理并与已知的区块哈希进行比较来证明区块内容的有效性。Helios 使用这一特性来获取和证明弱主观性检查点区块中的某些字段，包括两个非常重要的字段：当前同步委员会和下一个同步委员会。重要的是，这一机制允许轻客户端迅速浏览区块链的历史。

现在我们拥有弱主观性检查点，我们可以获取和验证当前和下一个同步委员会。如果当前链头处于与检查点相同的同步委员会期间，那么我们立即开始使用签名同步委员会头验证新区块。如果我们的检查点落后于几轮同步委员会，我们可以：

1. 使用检查点后的下一个同步委员会获取并验证一个来自未来一个同步委员会的区块。
2. 使用这个新区块获取新的下一个同步委员会。
3. 如果仍然落后，返回步骤 1。

这个过程的每次迭代都允许我们快速从区块链历史中快进 27 小时，从过去的任何区块哈希开始，并同步到当前区块哈希。

…在执行层

执行层轻客户端的目标是获取由共识层验证的信标区块头，并将它们与不可信的执行层 RPC 一起使用，以提供经过验证的执行层数据。这些数据随后可以通过由 Helios 本地托管的 RPC 服务器访问。

这是获取一个账户余额的简单示例，先快速介绍以太坊中状态如何存储。每个账户包含几个字段，如合同代码哈希、nonce、存储哈希和余额。这些账户存储在一个大型的、经过修改的 Merkle-Patricia 树 中，称为状态树。如果我们知道状态树的根，我们可以验证 merkle 证明 来证明树中任何账户的存在（或排除）。这些证明实际上几乎不可能伪造。

Helios 从共识层获取经过身份验证的状态根。使用这个根 和 merkle 证明请求到不可信的执行层 RPC，Helios 可以在本地验证所有存储于以太坊的数据。

我们应用不同的技术来验证执行层使用的各种数据；结合使用这些技术，使我们能够验证从不可信 RPC 检索的所有数据。虽然不可信的 RPC 可以拒绝访问数据，但它无法再为我们提供不正确的结果。

在实际环境中使用 Helios

可移植性和去中心化之间的权衡是一个常见的问题——但由于 Helios 非常轻量级，用户可以从任何设备（包括手机和浏览器扩展）访问安全链数据。可以随处运行 Helios 使更多人能够访问无信任的以太坊数据，而不管他们的硬件。这意味着用户可以在 MetaMask 中使用 Helios 作为他们的 RPC 提供商，完全无信任地访问 dapp，且无需做任何其他更改。

此外，Rust 对 WebAssembly 的支持使应用程序开发人员可以轻松地将 Helios 嵌入到 JavaScript 应用程序中（比如钱包和 dapp）。这些集成将使以太坊更安全，并减少我们对中心化基础设施的信任需求。

我们迫不及待想看看社区会有什么新创意。但与此同时，还有很多方法可以为 Helios 做出贡献——如果你不想为代码库做贡献，你也可以构建集成 Helios 的软件，以利用其优势。这些只是我们感到兴奋的一些想法：

• 支持直接从 P2P 网络获取轻客户端数据，而不是通过 RPC
• 实现一些缺失的 RPC 方法
• 构建一个编译为 WebAssembly 的 Helios 版本
• 将 Helios 直接集成到钱包软件中
• 构建一个网页仪表盘，以通过嵌入到网站的 Helios 获取并查看你的代币余额，使用 WebAssembly
• 实现引擎 API，使 Helios 的共识层能够与现有的执行层完整节点连接

查看代码库 开始——我们欢迎你的错误报告、功能请求和代码。如果你构建了更多内容，请通过 Twitter、Telegram 或 Farcaster @a16zcrypto 与我们分享。

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