以太坊轻客户端Helios：无需信任的链上数据访问

11月8日，一家知名风投机构推出了以太坊轻客户端Helios。这款基于Rust语言编写的客户端，旨在提供完全无需信任的以太坊访问。

区块链技术的一大优势在于无需信任第三方。通过区块链，用户可以自主掌控自己的财富和数据。以太坊等区块链在大多数情况下确实实现了这一承诺：我们的资产真正归属于我们自己。

然而，为了追求便利，我们也做出了一些妥协。其中之一就是使用中心化的RPC（远程调用）服务器。用户通常会通过中心化提供商访问以太坊。这些公司在云服务器上运行高性能节点，帮助用户轻松获取链上数据。当钱包查询代币余额或检查待处理交易是否已被打包时，几乎都会用到这些中心化提供商的服务。

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

Helios是一款基于Rust的以太坊轻客户端，能够提供完全无需信任的以太坊访问。它利用了以太坊转向PoS后实现的轻客户端协议，可以将来自不受信任的中心化RPC提供商的数据转换为安全可验证的本地RPC。结合中心化RPC，Helios无需运行完整节点就能验证数据的真实性。

难以兼顾便捷性与去中心化是一个普遍存在的痛点。这款新型客户端（开放给公众继续开发）能在约两秒内完成同步，且无需存储空间，用户可通过任何设备（包括手机和浏览器插件）安全地访问链上数据。那么，依赖中心化基础设施究竟有哪些潜在风险呢？本文将详细探讨这些风险，介绍Helios的设计方案，并提供一些建议，帮助开发者为代码库贡献力量。

中心化基础设施的潜在风险：以太坊生态中的理论威胁

在以太坊生态中潜伏着一种理论上的威胁。它不是在交易内存池（Mempool）中寻找目标，而是通过模仿我们依赖的中心化基础设施来设置陷阱。落入这种陷阱的用户并没有做错什么：他们只是像往常一样访问熟悉的DEX，设置了合理的滑点，并进行代币交易......他们的操作没有任何问题，却可能遭遇一种新型的三明治攻击，这是一种精心布置在以太坊生态入口处——RPC提供商——的陷阱。

在详细说明之前，我们先来看看DEX是如何处理交易的。用户进行代币兑换时，会向智能合约提供几个参数：要兑换的代币、兑换金额，以及最关键的，用户愿意接受的最小代币数量。最后一项参数确定了兑换必须达到的"最小产出"，否则交易将被撤销。这通常被称为"滑点"，因为它有效地限制了从交易发送至内存池到被打包进区块期间可能出现的最大价格波动。如果滑点设置过低，用户可能只能获得较少的代币。这种情况也可能导致三明治攻击，攻击者可能会将用户的交易夹在两个恶意交易之间。这些交易会推高现货价格，迫使用户以不利的价格成交。随后，攻击者会立即出售代币，获取小额利润。

只要最小产出参数设置在合理范围内，用户就不会受到三明治攻击的影响。但如果RPC提供商没有提供DEX智能合约的准确报价呢？这种情况下，用户可能会被误导，以较低的最小产出参数签署兑换交易。更糟糕的是，用户可能会将交易直接发送给恶意的RPC提供商。提供商可以选择不将这笔交易广播到公共内存池（那里有大量机器人在竞相进行三明治攻击），而是私下保留并将被攻击的交易包直接发送给特定平台，以从中牟利。

这种攻击的根本原因在于信任他人来帮助获取区块链状态。为了解决这个问题，有经验的用户通常会选择运行自己的以太坊节点。这需要投入大量时间和资源，至少需要一台持续在线的设备、数百GB的存储空间，以及大约一天的时间来从头开始同步。尽管这个过程比以前简化了许多，一些团队一直在努力帮助用户通过低成本硬件（如带外接硬盘的树莓派）运行节点。但即便要求大幅降低，对于大多数用户来说，尤其是使用移动设备的用户，运行节点仍然是一项艰巨的任务。

需要注意的是，虽然中心化RPC提供商的攻击完全可能发生，但目前还只是理论上的风险，实际上还未出现过。尽管主流提供商的过往记录值得信赖，但在将不熟悉的RPC提供商添加到钱包之前，仍然建议进行充分的调研。

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

以太坊推出的轻客户端协议为快速的区块链交互和通过最低硬件要求验证RPC端点开辟了令人兴奋的可能性。合并后的一个月内，多个相互独立的轻客户端相继出现，它们采用不同的方法，但都为了实现同一目标：无需信任的高效访问，且不必使用完整节点。

Helios是一款以太坊轻客户端，可在大约两秒内完成同步，不需要存储空间，并提供完全无需信任的以太坊访问。与所有以太坊客户端一样，Helios由执行层和共识层组成。但与大多数其他客户端不同，Helios将这两层紧密结合，用户只需安装和运行单个软件即可。

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

共识层

共识层轻客户端遵循信标链轻客户端规范，并利用了信标链的同步委员会（在合并前的Altair硬分叉中引入）。同步委员会是由随机选择的512个验证者组成的子集，服务周期约为27小时。

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

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

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

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

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

有了弱主观性检查点后，我们就可以获取和验证当前和下一个同步委员会。如果当前的链头和检查点都在同一个同步委员会周期内，我们可以立即开始使用已签名的同步委员会头来验证新区块。如果我们的检查点落后于几个同步委员会，那么我们可以：

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

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

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

通过这个过程，我们能够以27小时为单位，快速检查该区块链的历史，从过去的任何区块哈希开始，一直同步到当前的区块哈希。

执行层

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

让我们以获取账户余额为例，简单介绍一下以太坊如何存储状态。每个账户包含几个字段，如合约代码哈希、随机数、存储哈希和余额。这些账户存储在一个经过修改的大型Merkle-Patricia树中，称为状态树。只要知道状态树的根，就可以验证Merkle证明，来证明树中是否存在任何账户。这种证明是无法伪造的。

Helios从共识层获得了经过验证的状态根。通过将这个状态根和Merkle证明请求应用于不受信任的执行层RPC，Helios可以在本地验证所有存储在以太坊上的数据。

我们使用不同的技术来验证执行层使用的各种数据，通过这种方式，我们可以验证来自不受信任的RPC的所有数据。不受信任的RPC可以拒绝提供数据访问，但无法提供错误的结果。

在复杂环境中使用Helios

难以兼顾便捷性与去中心化是一个普遍存在的问题。通过轻量级的Helios，用户可以从任何设备（包括手机和浏览器插件）安全地访问链上数据。这将使更多人能够无需信任地访问以太坊数据，不受硬件限制。用户可以在某些钱包中将Helios设置为RPC提供商，实现无需信任地访问各种DApp，整个过程无需任何其他更改。

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

社区对此的反应令人期待。有多种方式可以为Helios做出贡献，除了为代码库添砖加瓦外，还可以构建集成Helios的软件，以利用其优势。以下是一些令人兴奋的想法：

• 支持直接从P2P网络（而非RPC）获取轻客户端数据
• 实现一些尚未支持的RPC方法
• 开发可编译为WebAssembly的Helios版本
• 将Helios直接集成到钱包软件中
• 构建网络仪表板来查看代币余额，将Helios嵌入使用WebAssembly的网站中以获取数据
• 部署引擎API，将Helios共识层连接到现有执行层的全节点上