Helios——a16z crypto构建的去中心化以太坊轻节点
1. 引言
目前，区块链的去中心化方面存在以下问题：
- 使用中心化的RPC服务（Remote Procedure Call）：用户访问以太坊需通过中心化供应商（如Alchemy）。这些厂商在云服务器上运行高性能节点，使得其它人很容易可访问链上数据。当某钱包查询其token余额时或检查某pending交易是否被包含在某去看，该钱包一般总是通过访问中心化供应商来解决。
现有系统的问题在于，用户需信任供应商，且无法验证其所查询信息的正确性。
https://github.com/a16z/helios，以Rust语言实现，采用以太坊light client协议，可将来自于 不信任的中心化的RPC供应商 的数据 转换为 可安全验证的local RPC。Helios与中心化RPC一起，在无需运行全节点的情况下，可验证数据的真实性。
轻便性和去中心化之间通常很难取舍，但基于Helios，公众可在约2秒完成同步，无需存储，使得用户可从任意设备（包括手机或浏览器扩展程序，如MetaMask）中访问链上安全数据。
2. Helios: fully trustless access to ethereum
以太坊切换到PoS之后，无需全节点的无需信任的高效轻节点方案有：
- Lodestar
- Nimbus
- 基于JavaScript的 Kevlar
- Helios：可在约2秒内完成同步，无需存储，提供fully trustless access to Ethereum。Helios与所有以太坊节点一样，其包括执行层和共识层，但是不同之处在于，Helios将这2层紧耦合，使得用户仅需安装和运行某单一软件。Erigon目前也在转向这个方向，将共识层轻节点直接加到其archive node中。
- Helios共识层：采用beacon chain的blockhash 和 与某不可信RPC连接提供可验证的区块同步。
- Helios执行层：采用tandem中经认证的beacon chain 区块 + untrusted execution layer RPC 来提供关于链上状态的任意信息（如账户余额、合约storage、交易receipts、合约调用结果等）。
2.1 Helios共识层
遵循beacon链轻节点说明，并使用了beacon链的sync committees。该sync committee随机选出512个validators工作周期为约27小时。
在sync committee的validator，会对其看到的每个beacon chain block header进行签名。对于某block header，若有超过2/3的committee签名了，则大概率该区块在canonical beacon链上。若Helios知道当前的sync committee，则可自信地跟踪链上区块头——问untrusted RPC要最新的sync committee签名。
多亏有BLS signature aggregation，仅需做一次check就可验证新的区块头。若签名有效且超过了2/3 committee，则可安全的认为该区块已包含在链上（当然可能会被reorg出链，但跟踪区块finality可提供更严格的保证）。
关键在于：如何找到当前的sync committee？
- 首先需获得名为“weak subjectivity checkpoint”的trust root——为某old blockhash，用于保证过去链上的某个point。其背后有一些有趣的数学来计算how old the checkpoint can be。最差情况下，建议需要约2周时间，更实用的评估为数月。
若checkpoint太老，则存在theoretical attacks可欺骗节点跟从错误的链。具体获取checkpoint的方法本文不讨论。Helios在其代码库中硬编码了某初始checkpoint（后续可替代），当节点同步时，可在本地存储最新的固化blockhash供未来实用。 - beacon链区块可哈希生成唯一的beacon blockhash。这意味着很容易向节点请求a full beacon block，然后通过哈希证明区块内容是有效的 并 与已知区块哈希值对比。Helios实用该属性来获取和证明特定fields inside the weak subjectivity checkpoint block，包含2个重要的field：
- 当前sync committee
- 下一轮sync committee
这种机制可保证轻节点快速forward through the blockchain’s history。
目前，有a weak subjectivity checkpoint，可获取和验证当前和下一sync committee。若If the current chain head is within the same sync committee period as the checkpoint, then we immediately start verifying new blocks with the signed sync committee headers. If our checkpoint is several sync committees behind, we can:
- 1）Use the next sync committee after our checkpoint to fetch and verify a block that originates one sync committee in the future.
- 2）Use this new block to fetch the new next sync committee.
- 3）If still behind, return to step 1.
以上流程每次迭代可fast forward through 27 hours of the chain’s history，start with any blockhash in the past, and sync to the current blockhash。
2.2 Helios执行层
轻节点执行层的目的是获取经共识层验证的beacon区块头，与untrusted execution layer RPC一起提供verified execution layer data。该数据可由Helios本地RPC服务访问。
举例：
每个账号包含的field有：合约code hash、nonce、storage hash和balance。这些账号存储在大的修改了的名为“Merkle-Patricia tree”的state tree。若知道该state tree的root，可验证merkle proof来证明某账号在树中的存在性或不存在性。
Helios有来自共识层的经认证的state root。借助该root和merkle proof给untrusted execution layer RPC，Helios可本地验证存在链上的所有的数据。
可在执行层应用不同技术来验证所有数据，结合起来，可认证从untrusted RPC获得的所有数据。
3. 展望
可将Helios用于：
- Support fetching light client data directly from the P2P network rather than via RPC
- Implement some of the missing RPC methods
- Build a version of Helios that compiles to WebAssembly
- Integrate Helios directly into wallet software
- Build a web dashboard to view your token balances that fetches data from Helios embedded into the website with WebAssembly
- Implement the engine API so that Helios’ consensus layer can be connected to an existing execution layer full node