以太坊轻客户端Helios：实现无需信任的区块链访问

11月8日，一款新的以太坊轻客户端Helios正式推出。该客户端基于Rust语言开发,旨在提供完全无需信任的以太坊访问。

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

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

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

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

该客户端能在约两秒内完成同步,且无需存储,用户可通过任何设备(包括手机和浏览器插件)安全访问链上数据。但依赖中心化基础设施到底有哪些潜在风险?接下来将分析这些风险,介绍Helios的设计方案,并提供一些思路帮助完善代码库。

中心化基础设施的潜在风险

一种理论上的攻击方式潜伏在以太坊"黑暗森林"中。它不是在交易内存池中寻找目标,而是通过模仿我们依赖的中心化基础设施来设置陷阱。用户即便没有犯错也可能落入陷阱:他们只是像往常一样在DEX上交易,设定了合理的滑点......但仍可能遭遇一种新型三明治攻击,这是一种精心设置在RPC提供商处的陷阱。

去中心化交易所处理交易时,用户需要向智能合约提供几个参数:要兑换的代币、兑换金额,以及最重要的,用户愿意接受的最小代币数量。最后一项参数指明了兑换必须达到的"最小产出",否则交易会被撤销。这通常被称为"滑点",它有效设定了从发送交易到交易上链之间可能出现的最大价差。如果滑点设置过低,用户可能只能获得较少代币,还可能遭受三明治攻击。

只要最小产出参数设置在合理范围内,就不会受到三明治攻击。但如果RPC提供商没有提供DEX智能合约的准确报价呢?这可能导致用户被误导,以较低的最小产出参数签署兑换交易。更糟的是,用户还可能将交易直接发送给恶意的RPC提供商。提供商可以不将交易广播至公共内存池,而是私下扣留并将被攻击的交易包直接发送给特定机构以牟利。

造成这种攻击的根本原因是信任他人来获取区块链状态。为解决该问题,有经验的用户通常会运行自己的以太坊节点,但这需要耗费大量时间和资源,至少需要一台持续在线的设备、数百GB存储空间,以及大约一天时间从头开始同步。虽然现在运行节点的门槛已经降低,但对于多数用户来说仍然很困难,尤其是使用移动设备的用户。

需要注意的是,中心化RPC提供商攻击虽然完全可能发生,但通常只是简单的钓鱼攻击,我们描述的那种攻击尚未发生。尽管主流提供商的过往记录值得信赖,但在使用不熟悉的RPC提供商之前,多做一些研究仍然是明智之选。

Helios:实现无需信任的以太坊访问

以太坊推出轻客户端协议,为快速的区块链交互和通过最低硬件需求验证RPC端点开辟了新的可能性。The Merge后的一个月里,多个独立的轻客户端相继推出,它们采用不同方法,但目标一致:在不运行完整节点的情况下实现高效的无需信任访问。

Helios是一个以太坊轻客户端,可在约两秒内完成同步,无需存储,并提供完全无需信任的以太坊访问。与所有以太坊客户端一样,Helios包含执行层和共识层。但与多数客户端不同,Helios将两层紧密耦合,用户只需安装和运行单个软件即可。

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

共识层

共识层轻客户端遵循信标链轻客户端规范,利用了信标链的同步委员会。同步委员会是随机选择的512个验证者构成的子集,服务周期约27小时。

验证者进入同步委员会后会签署所有看到的信标链区块头。如果超过2/3的委员会成员签署了一个区块头,则该区块极可能位于规范信标链中。如果Helios了解当前同步委员会的组成,它可以通过查询最近的同步委员会签名来可靠地追踪链头。

得益于BLS签名聚合,只需一次查询即可完成对新区块头的验证。只要签名有效且超过2/3的委员会成员完成签名,即可保证区块已包含在链中。当然,追踪区块的最终性可提供更强的保证。

这个策略中还需要解决如何找到当前同步委员会的问题。首先要获取一个称为弱主观性检查点的信任根。它表示一个可以保证在过去某个时刻被纳入链中的旧区块哈希。关于检查点的存在时间,理论分析显示最坏情况约为两周,而实际估计可能长达数月。

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

通过哈希操作,信标链区块可方便地产生唯一的信标区块哈希。这样可以轻松查询完整的信标区块,然后通过哈希比对来证明区块内容的有效性。Helios利用此属性来获取和验证弱主观性检查点区块内的关键字段,包括当前同步委员会和下个同步委员会。最关键的是,轻客户端可利用该机制快速检阅区块链历史。

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

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

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

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

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

执行层

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

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

Helios从共识层获得经过验证的状态根。通过对不受信任的执行层RPC应用这一状态根和Merkle证明请求,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共识层连接至现有执行层的全节点