Ethereum light client Helios: Achieving trustless blockchain access

On November 8th, a new Ethereum light client Helios was officially launched. This client is developed based on the Rust language and aims to provide completely trustless access to Ethereum.

One of the main purposes of using Blockchain is to achieve trustlessness. Through Blockchain, we can have full control over our wealth and data. In most cases, blockchains like Ethereum do deliver on this promise: our assets truly belong to us.

However, in pursuit of convenience, we have also made some compromises. One of them is using centralized RPC( remote call) servers. Users typically access Ethereum through centralized providers. These companies run high-performance nodes on cloud servers, helping everyone easily obtain on-chain data. When wallets query token balances or check transaction statuses, these centralized providers are almost always involved.

The current problem with the system is that users need to trust these providers and cannot verify whether the query results are correct.

Helios is a Rust-based Ethereum light client that provides completely trustless access to Ethereum. It utilizes the light client protocol implemented after Ethereum's transition to PoS, allowing it to convert data from untrusted centralized RPC providers into securely verifiable local RPC. Combined with centralized RPC, Helios can verify data authenticity without the need to run a full node.

This client can complete synchronization in about two seconds without storage, and users can securely access on-chain data through any device (, including mobile phones and browser plugins ). But what are the potential risks of relying on centralized infrastructure? Next, we will analyze these risks, introduce Helios's design scheme, and provide some ideas to help improve the codebase.

Potential Risks of Centralized Infrastructure

A theoretical attack method lurks in Ethereum's "dark forest". It does not seek targets in the transaction memory pool, but sets traps by mimicking the centralized infrastructure we rely on. Users may fall into the trap even if they do not make mistakes: they are just trading on DEX as usual, setting reasonable slippage... but may still encounter a new type of sandwich attack, which is a carefully set trap at the RPC provider.

When processing transactions on a decentralized exchange, users need to provide several parameters to the smart contract: the tokens to be exchanged, the amount to be exchanged, and most importantly, the minimum number of tokens the user is willing to accept. The last parameter specifies the "minimum output" that the exchange must reach; otherwise, the transaction will be canceled. This is commonly referred to as "slippage," which effectively sets the maximum price difference that may occur between sending the transaction and the transaction being recorded on the blockchain. If the slippage is set too low, users may only receive fewer tokens and may also suffer from sandwich attacks.

As long as the minimum output parameters are set within a reasonable range, it will not be subject to sandwich attacks. But what if the RPC provider does not provide accurate quotes for the DEX smart contract? This could mislead users into signing exchange transactions with lower minimum output parameters. Worse, users may also send transactions directly to malicious RPC providers. These providers can withhold the transactions from being broadcast to the public memory pool and instead privately retain and send the attacked transaction packets directly to specific entities for profit.

The fundamental reason for this attack is trusting others to obtain the state of the blockchain. To address this issue, experienced users often run their own Ethereum nodes, but this requires a significant amount of time and resources, including at least one continuously online device, hundreds of GB of storage space, and about a day to sync from scratch. Although the barrier to running nodes has been lowered, it is still very difficult for most users, especially those using mobile devices.

It is important to note that while attacks from centralized RPC providers are entirely possible, they are usually just simple phishing attacks, and the type of attack we described has not yet occurred. Although the track record of mainstream providers is trustworthy, it is still wise to do some research before using unfamiliar RPC providers.

Helios: Achieving Trustless Access to Ethereum

Ethereum has launched a light client protocol, opening up new possibilities for fast blockchain interactions and validating RPC endpoints with minimal hardware requirements. In the month following The Merge, several independent light clients were successively launched, employing different methods but sharing a common goal: achieving efficient, trustless access without the need to run a full node.

Helios is an Ethereum light client that can sync in about two seconds without storage and provides completely trustless access to Ethereum. Like all Ethereum clients, Helios includes an execution layer and a consensus layer. However, unlike most clients, Helios tightly couples the two layers, allowing users to install and run a single piece of software.

The working mechanism of Helios is as follows: the consensus layer uses a known beacon chain block hash and connects to an untrusted RPC to synchronously verify to the current block in a verifiable manner. The execution layer combines these verified beacon chain blocks with untrusted execution layer RPCs to validate various information about the on-chain state, such as account balances, contract storage, transaction receipts, and smart contract call results. These components work together to provide users with a completely trustless RPC without the need to run a full node.

Consensus Layer

The consensus layer light client follows the beacon chain light client specification and utilizes the synchronization committee of the beacon chain. The synchronization committee is a subset of 512 validators selected at random, with a service period of approximately 27 hours.

After a validator enters the synchronization committee, they will sign all the beacon chain block headers they see. If more than 2/3 of the committee members sign a block header, that block is very likely to be included in the canonical beacon chain. If Helios understands the composition of the current synchronization committee, it can reliably track the chain head by querying the recent synchronization committee signatures.

Thanks to BLS signature aggregation, verification of a new block header can be completed with just one query. As long as the signatures are valid and more than 2/3 of the committee members have signed, it can be guaranteed that the block is included in the chain. Of course, tracking the finality of the block can provide a stronger guarantee.

This strategy also needs to address how to find the current synchronization committee. First, a trust root called a weak subjectivity checkpoint needs to be obtained. It represents an old block hash that can be guaranteed to have been included in the chain at some point in the past. Regarding the existence time of the checkpoint, theoretical analysis shows that the worst-case scenario is about two weeks, while the actual estimate could be several months.

If the checkpoint is too old, there is theoretically an attack that can deceive nodes into following an incorrect chain. At this point, obtaining weak subjectivity checkpoints is beyond the protocol's capabilities. Helios's solution is to provide an initial checkpoint, hardcoded into the codebase, which can easily be overridden (. It will locally save the latest finalized Block hash to be used as a checkpoint when nodes synchronize.

Through hash operations, the beacon chain block can conveniently produce a unique beacon block hash. This allows for easy querying of the complete beacon block, and then proving the validity of the block content through hash comparison. Helios utilizes this property to obtain and verify key fields within the weak subjectivity checkpoint block, including the current synchronization committee and the next synchronization committee. Most importantly, light clients can use this mechanism to quickly review the blockchain history.

With the weak subjectivity checkpoint, we can obtain and verify the current and next synchronization committee. If the current chain head and checkpoint are within the same synchronization committee cycle, we can immediately use the signed synchronization committee header to verify the new block. If the checkpoint is placed several synchronization committees later, then we can:

1. Use the next sync committee after the checkpoint to obtain and verify the block that will generate a sync committee in the future.

2. Use this new block to obtain the next synchronization committee.

3. If the checkpoint is still behind, return to step 1.

Through the above process, we can quickly review the history of the Blockchain in 27-hour intervals, starting from any past Block hash and synchronizing to the current Block hash.

) Execution Layer

The goal of the execution layer light client is to combine the verified beacon block headers from the consensus layer with untrusted execution layer RPC to provide verified execution layer data. This data can then be accessed via a locally hosted RPC server through Helios.

The following is a simple example of obtaining account balances, first briefly introducing how Ethereum stores state. Each account contains several fields, such as contract code hash, nonce, storage hash, and balance. These accounts are stored in a modified large Merkle-Patricia tree, known as the state tree. As long as the root of the state tree is known, Merkle proofs can be verified to prove the existence of any account in the tree. This proof cannot be forged.

Helios obtains the verified state root from the consensus layer. By applying this state root and Merkle proof requests to the untrusted execution layer RPC, Helios can locally verify all data stored on Ethereum.

We use different technologies to verify the various data used by the execution layer, allowing us to validate all data from untrusted RPCs. Untrusted RPCs can refuse to provide data access, but they cannot provide incorrect results.

The Application Prospects of Helios

Balancing convenience and decentralization is a common pain point. With the lightweight Helios, users can access secure on-chain data from any device ### including mobile phones and browser extensions (. This will enable more people to access Ethereum data without trust, regardless of the hardware used. Users can use Helios as an RPC provider in their wallets to access various DApps without trust, all without any additional changes.

In addition, Rust's support for WebAssembly allows application developers to easily embed Helios into Javascript applications such as wallets and DApps ). These integrations will enhance the security of Ethereum and reduce our reliance on centralized infrastructure.

The community can contribute to Helios in various ways. In addition to improving the codebase, they can also build software that integrates Helios to leverage its advantages. Here are some potential development directions:

• Supports obtaining light client data directly from the P2P network instead of relying on RPC.
• Implement the missing RPC methods
• Develop a Helios version that can be compiled to WebAssembly
• Integrate Helios directly into the wallet software.
• Build a network dashboard to view token balances and embed Helios into websites using WebAssembly to fetch data.
• Deploy the engine API to connect the Helios consensus layer to the existing full node of the execution layer.