详解 a16z 推出的 Helios：完全无需信任的以太坊访问

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

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

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

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

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

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

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

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

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

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

造成这一攻击的根本原因是信任他人来帮助你获取区块链状态。为解决该问题，有经验的用户通常会运行自己的以太坊节点，这项工作需要耗费大量时间和资源，至少需要一台持续在线的设备，数百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共识层连接至现有执行层的全节点上