以太坊轻客户端 Helios 基于 Rust 语言进行编写，提供完全无需信任的以太坊访问。

撰文：Noah Citron

编译：PANews，王尔玉

11 月 8 日，a16z Crypto 推出了以太坊轻客户端 Helios，基于 Rust 语言进行编写，提供完全无需信任的以太坊访问。以下是 PANews 对官方新闻的翻译。

我们使用区块链的主要原因之一是无需信任。藉此，我们可自主掌控自己的财富和数据。多数情况下，以太坊等区块链的确兑现了这一承诺：我们的资产真正属于我们自己。

但我们也为了追求方便而做了一些妥协。其中之一即我们使用了中心化的 RPC（远程调用）服务器。用户往往会通过 Alchemy 等中心化提供商访问以太坊。这些公司在云服务器上运行高性能节点，帮助大家轻松访问链上数据。当钱包查询其代币余额或检查一项待处理交易是否已纳入区块时，几乎总会用到这些中心化提供商。

当前系统的问题在于用户需要信任这些提供商，而无法验证查询结果是否正确。

Helios 是我们开发的基于 Rust 的以太坊轻客户端，它能提供完全无需信任的以太坊访问。Helios 使用了以太坊切换至 PoS 后促成的轻客户端协议，它能将来自不受信任的中心化 RPC 提供商的数据转换至安全可验证的本地 RPC 中。结合中心化 RPC，Helios 可在不运行完整节点的情况下验证数据的真伪。

难以兼顾便捷性与去中心化是一个常见痛点，我们的客户端（公众可在其基础上继续构建）能实现约两秒内完成同步，且无需存储，用户可通过任何设备（包括手机和浏览器插件）访问安全的链上数据。但依赖中心化基础设施到底有什么潜在陷阱呢？本文将梳理此类陷阱，介绍我们的设计方案，并提供一些思路，帮助大家为代码库添砖加瓦。

中心化基础设施的陷阱：以太坊「黑暗森林」中的理论产物

一个（理论性）产物潜伏在黑暗森林中。它没有在以太坊交易内存池（Mempool）中寻找猎物，而是通过模拟我们依赖的中心化基础设施来设置陷阱。落入该陷阱的用户并没有犯任何错误：他们只是访问了常去的去中心化交易所，设定了合理的滑点，并像往常一样买卖代币……他们没做错任何事，但仍然遭遇了一种新型三明治攻击，这是一种精心设置在以太坊黑暗森林入口处——RPC 提供商——的陷阱。

详细说明之前，我们先来看一下去中心化交易所是如何处理交易的。用户执行兑换交易时会向智能合约提供几个参数：要兑换的代币，兑换金额，以及最重要的，用户推进交易必须接收的最小代币数量。最后一项参数指明了兑换必须达到的「最小产出」，否则会撤销交易。这通常被称为「滑点」，因为它有效设定了从交易发送至内存池到交易被纳入区块之间可能出现的最大价差。如果滑点设置太低，用户有可能只能接收到较少代币。这种情况也可能导致三明治攻击，攻击者可将用户的出价夹在两个恶意交易之间。这些交易会推高现货价格，迫使用户以不太好的价格进行交易。然后，攻击者会立即出售代币，获取小额利润。

只要这个最小产出参数设置在公允值附近，你就不会受到三明治攻击。但如果你的 RPC 提供商没有提供去中心化交易所智能合约的准确报价呢？如此一来，用户可能会被蒙蔽，并以较低的最小产出参数签署兑换交易，更糟的是，用户还可能将交易直接发送给恶意的 RPC 提供商。提供商可以不将这笔交易广播至公共内存池（数十个机器人在其中竞相开展三明治攻击），而私下扣留并将被攻击的交易包直接发送给 Flashbots，以从中牟利。（为了应对中心化的问题，Flashbots 也在探索一些解决方案，延伸阅读：Flashbots 将推出 SUAVE：审查制度与去中心化的权衡术）

造成这一攻击的根本原因是信任他人来帮助你获取区块链状态。为解决该问题，有经验的用户通常会运行自己的以太坊节点，这项工作需要耗费大量时间和资源，至少需要一台持续在线的设备，数百 GB 的存储空间，以及大约一天的时间以从头开始同步。这个过程显然比过去简化了。Ethereum on ARM 等团体一直在不懈努力，帮助大家通过低成本硬件运行节点（例如带有外部硬盘驱动器的树莓派微型电脑）。但即便要求大幅降低，运行节点对于多数用户仍然很困难，特别是使用移动设备的用户。

需要注意的是，中心化 RPC 提供商攻击虽然完全可能发生，但通常只是简单的钓鱼攻击，我们说的那种攻击尚未发生。尽管 Alchemy 等大型提供商的过往记录让我们没有理由怀疑他们，但在将不熟悉的 RPC 提供商添加至钱包前，多做一些研究仍然是值得的。

Helios 简介：完全无需信任的以太坊访问

以太坊推出轻客户端协议，为快速的区块链交互和通过最低硬件需求验证 RPC 端点开辟了令人兴奋的可能性。在 The Merge 后的一个月里，一批彼此独立的轻客户端（Lodestar、Nimbus 和基于 JavaScript 的 Kevlar）相继涌现，它们各辟蹊径，只为了同一目标：无需信任的高效访问，且不必使用完整节点。

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

它如何运作呢？Helios 共识层使用一个已知的信标链区块哈希，并连接一个不受信任的 RPC，以可验证的方式同步至当前区块。Helios 执行层将这些经过验证的信标链区块与不受信任的执行层 RPC 结合，以验证有关链上状态的各种信息，例如账户余额、合约存储、交易收据和智能合约调用结果。这些组件协同工作，可为用户提供完全无需信任的 RPC，且无需运行完整节点。

共识层

共识层轻客户端符合信标链轻客户端规范，并利用了信标链的同步委员会（在 Altair 硬分叉的 Merge 之前推出）。同步委员会是随机选择的 512 个验证者构成的子集，服务周期约 27 小时。

验证者进入同步委员会后会签署看到的所有信标链区块头（block header）。如果超过三分之二的委员会成员签署了一个区块头，则该区块极有可能位于规范信标链中。如果 Helios 了解当前同步委员会的组成，它可以通过向不受信任的 RPC 查询最近的同步委员会签名，以有把握地追踪链头。

得益于 BLS 签名聚合，只需一次查询即可完成对新区块头的验证。只要签名有效且超过三分之二的委员会成员完成签名，即可保证区块已包含在链中（当然，它也可能被重组至链外，而追踪区块的最终性可提供更强的保证）。

但这个策略中显然缺少了一个环节：如何找到当前的同步委员会。首先要获取一个称为弱主观性检查点（weak subjectivity checkpoint）的信任根。别被名字吓到，它仅仅表示一个可以保证在过去的某个时刻被纳入链中的旧的区块哈希。关于检查点确切的存在时间，背后有一些有趣的数学计算：最坏的情况分析显示大约有两周，而更实际的估计表明有数月。

如果检查点太旧，理论上存在可以诱骗节点跟随错误链的攻击。此时，获取弱主观性检查点就超出了协议的能力范围。Helios 的解决办法是提供一个初始检查点，将之硬编码至代码库（很容易被覆盖），它会在本地保存最新的最终区块哈希，以便在节点同步时用作检查点。

通过哈希操作，信标链区块可方便地产生唯一的信标区块哈希。如此便可轻松向节点查询完整的信标区块，然后通过对之进行哈希操作并与已知的区块哈希进行比较，来证明区块内容的有效性。Helios 利用此属性来获取和验证弱主观性检查点区块内的某些字段，包括两个至关重要的字段：当前同步委员会和下个同步委员会。最关键的是，轻客户端可利用该机制快速检阅区块链历史。

现在有了弱主观性检查点，我们可以获取和验证当前和下个同步委员会。如果当前的链头和检查点都在相同的同步委员会周期内，我们可以立即开始使用已签名的同步委员会 header 来验证新区块。如果我们的检查点排在若干同步委员会之后，则可以：

1.使用检查点之后的下个同步委员会来获取和验证将在未来生成一个同步委员会的区块。

2.使用此新区块获取下个同步委员会。

3.如果检查点还在后面，返回步骤 1。

通过上述流程，我们能以 27 小时为单位，快速检阅该区块链的历史，从过去的任一区块哈希开始，一直同步至当前的区块哈希。

执行层

执行层轻客户端的目标是将经过共识层验证的信标区块头与不受信任的执行层 RPC 结合使用，提供经过验证的执行层数据。然后便可通过 Helios 在本地托管的 RPC 服务器访问此数据。

下面举一个获取帐户余额的简单例子，首先简单介绍一下以太坊是如何存储状态的。每个帐户包含若干字段，如合约代码哈希、随机数、存储哈希和余额。这些帐户存储在一个经过调整的大型 Merkle-Patricia 树中，称为状态树。只要知道状态树的根，就可以验证 Merkle 证明，来证明树中是否存在任何帐户。这一证明无法被伪造。

Helios 有一个来自共识层的经过验证的状态根（state root）。通过对不受信任的执行层 RPC 应用这一状态根和 Merkle 证明请求，Helios 可在本地验证所有存储在以太坊的数据。

我们使用不同的技术来验证执行层使用的各种数据，藉此，我们可以验证来自不受信任的 RPC 的所有数据。不受信任的 RPC 可拒绝提供数据访问，但再也不能提供错误的结果。

在狂野世界使用 Helios

难以兼顾便捷性与去中心化是一个常见痛点，通过轻量级的 Helios，用户可从任何设备（包括手机和浏览器插件）访问安全的链上数据。这将使更多人可以访问无需信任的以太坊数据，不论使用什么硬件。用户可以在 MetaMask 中将 Helios 作为他们的 RPC 提供商，以实现无需信任地访问各种 DApp，整个过程无需任何其他更改。

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

我们迫不及待地想知道社区对此的反应。有众多途径可以为 Helios 做贡献，除了为代码库添砖加瓦外，你也可以构建集成 Helios 的软件，以利用其优势。以下是让我们兴奋的几点思路：

• 支持直接从 P2P 网络、而非 RPC 获取轻客户端数据

• 部署一些缺失的 RPC 方法

• 构建可编译至 WebAssembly 的 Helios 版本

• 将 Helios 直接集成至钱包软件中

• 构建网络仪表板来查看代币余额，将 Helios 嵌入使用 WebAssembly 的网站中，以获取数据

• 部署引擎 API，将 Helios 共识层连接至现有执行层的全节点上

请点击此处查看代码库。