Ethereum Light Client Helios: Trustless On-Chain Data Access

On November 8th, a well-known venture capital institution launched the Ethereum light client Helios. This client, written in Rust, aims to provide completely trustless access to Ethereum.

One major advantage of blockchain technology is the absence of the need to trust third parties. Through blockchain, users can have full control over their wealth and data. Blockchains like Ethereum have indeed fulfilled this promise in most cases: our assets truly belong to us.

However, in pursuit of convenience, we have also made some compromises. One of them is the use of centralized RPC (Remote Procedure Call) servers. Users typically access Ethereum through centralized providers. These companies run high-performance nodes on cloud servers, helping users easily obtain on-chain data. Whenever a wallet queries token balances or checks whether pending transactions have been packaged, it almost always utilizes the services of these centralized providers.

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

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 the authenticity of data without the need to run a full node.

Balancing convenience and decentralization is a common pain point. This new type of client (open for public development) can complete synchronization in about two seconds without requiring storage space, allowing users to securely access on-chain data through any device (including mobile phones and browser plugins). So, what are the potential risks associated with relying on centralized infrastructure? This article will explore these risks in detail, introduce the design solution of Helios, and provide some suggestions to help developers contribute to the codebase.

Potential Risks of Centralized Infrastructure: Theoretical Threats in the Ethereum Ecosystem

There is a theoretical threat lurking in the Ethereum ecosystem. It does not seek targets within the transaction memory pool (Mempool), but rather sets traps by mimicking the centralized infrastructure we rely on. Users who fall into this trap have not done anything wrong: they are simply accessing familiar DEXs as usual, setting reasonable slippage, and trading tokens... Their actions are perfectly fine, yet they may encounter a new type of sandwich attack, which is a trap carefully laid at the entrance of the Ethereum ecosystem — the RPC providers.

Before detailing further, let’s take a look at how DEX handles transactions. When users perform token swaps, they provide several parameters to the smart contract: the token to be swapped, the amount to be exchanged, and most importantly, the minimum amount of tokens the user is willing to accept. The last parameter determines the "minimum output" that the swap must achieve, otherwise the transaction will be reverted. This is commonly referred to as "slippage," as it effectively limits the maximum price fluctuations that may occur from the time the transaction is sent to the mempool until it is packaged into a block. If the slippage is set too low, users may receive fewer tokens. This situation can also lead to a sandwich attack, where attackers can place the user’s transaction between two malicious transactions. These transactions will push up the spot price, forcing the user to execute at an unfavorable price. Subsequently, the attacker will immediately sell the tokens to make a small profit.

As long as the minimum output parameters are set within a reasonable range, users will not be affected by sandwich attacks. But what if the RPC provider does not provide accurate quotes for the DEX smart contracts? In this case, users may be misled into signing exchange transactions with lower minimum output parameters. Worse, users might send transactions directly to malicious RPC providers. Providers can choose not to broadcast the transaction to the public mempool (where many bots are competing to execute sandwich attacks), but rather keep it private and send the attacked transaction package directly to a specific platform for profit.

The root cause of this attack lies in trusting others to help obtain the on-chain state of the blockchain. To address this issue, experienced users often choose to run their own Ethereum nodes. This requires a significant investment of time and resources, including at least one device that is continuously online, hundreds of GB of storage space, and about a day to sync from scratch. Although this process has been simplified significantly compared to before, some teams have been working to help users run nodes with low-cost hardware (such as a Raspberry Pi with an external hard drive). However, even with significantly reduced requirements, running a node remains a daunting task 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 currently only a theoretical risk and have not yet occurred in practice. Although the track record of mainstream providers is trustworthy, it is still advisable to conduct thorough research before adding unfamiliar RPC providers to your wallet.

Introduction to Helios: Trustless Access to Ethereum

The light client protocol launched by Ethereum opens up exciting possibilities for fast blockchain interactions and validating RPC endpoints with minimal hardware requirements. Within a month after the merge, several independent light clients emerged one after another, employing different approaches but all aimed at achieving the same goal: efficient, trustless access without the need for full nodes.

Helios is an Ethereum light client that can synchronize in about two seconds, requires no storage space, and provides fully trustless access to Ethereum. Like all Ethereum clients, Helios consists of an execution layer and a consensus layer. However, unlike most other clients, Helios tightly integrates these two layers, allowing users to install and run a single piece of software.

Its working principle is as follows: The Helios consensus layer uses a known beacon chain block hash and connects to an untrusted RPC to synchronously verify the current block. The Helios 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 fully trustless RPC without the need to run a full node.

Consensus Layer

The consensus layer light client follows the beacon chain light client specifications and utilizes the synchronization committee of the beacon chain (introduced in the Altair hard fork before the merge). The synchronization committee is a subset of 512 randomly selected validators, with a service period of approximately 27 hours.

After validators enter the sync committee, they will sign all the beacon chain block headers they see. If more than two-thirds of the committee members sign a block header, then that block is very likely to be part of the canonical beacon chain. If Helios understands the current composition of the sync committee, it can track the chain head with high confidence by querying the recent sync committee signatures from an untrusted RPC.

Thanks to BLS signature aggregation, verifying a new block header can be completed with just one query. As long as the signature is valid and more than two-thirds of the committee members have signed, it can be guaranteed that the block is included on-chain (of course, it may also be reorganized out of the chain, while tracking the finality of the block can provide stronger guarantees).

But this strategy clearly lacks a step: how to find the current synchronization committee. First, it is necessary to obtain a trust root known as a weak subjectivity checkpoint. This is simply an old block hash that can guarantee it was included in the chain at some point in the past. There are some interesting mathematical calculations behind the exact existence time of the checkpoint: worst-case analysis shows about two weeks, while more practical estimates suggest 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 a weak subjectivity checkpoint exceeds the protocol's capabilities. Helios's solution is to provide an initial checkpoint, hardcoded into the codebase (which can be easily overridden), that will locally save the latest finalized block hash to be used as a checkpoint during node synchronization.

Through hash operations, beacon chain blocks can easily generate unique beacon block hashes. This allows for easy querying of the complete beacon block by nodes, and then by hashing it and comparing it with known block hashes, to prove the validity of the block content. Helios utilizes this feature to retrieve and verify certain fields within weak subjectivity checkpoint blocks, including two crucial fields: the current sync committee and the next sync committee. Most importantly, light clients can leverage this mechanism to quickly check the blockchain history.

With the weak subjectivity checkpoint in place, we can obtain and verify the current and next synchronization committee. If the current chain head and the checkpoint are within the same synchronization committee period, we can immediately start using the signed synchronization committee head to validate new blocks. If our checkpoint is behind several synchronization committees, then we can:

1. Use the next synchronization committee after the checkpoint to obtain and verify the blocks that will generate a synchronization 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 this process, we are able to quickly check the history of the blockchain in 27-hour increments, synchronizing from any past block hash to the current block hash.

Execution Layer

The goal of the execution layer light client is to utilize the beacon block headers verified by the consensus layer in conjunction with the untrusted execution layer RPC, providing verified execution layer data. This data can then be accessed through locally hosted RPC servers via Helios.

Let's take retrieving account balances as an example to briefly introduce 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 whether any account exists in the tree. This proof is tamper-proof.

Helios obtains the verified state root from the consensus layer. By applying this state root and Merkle proof request 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. In this way, we can verify all data from untrusted RPCs. Untrusted RPCs can refuse to provide data access, but they cannot provide incorrect results.

Using Helios in Complex Environments

Balancing convenience and decentralization is a common issue. With the lightweight Helios, users can securely access on-chain data from any device, including mobile phones and browser extensions. This will enable more people to access Ethereum data trustlessly, without hardware limitations. Users can set Helios as the RPC provider in certain wallets, allowing trustless access to various DApps, all without any other modifications.

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 Ethereum's security and reduce our reliance on centralized infrastructure.

The community's reaction to this is highly anticipated. There are various ways to contribute to Helios, in addition to adding to the codebase, such as building software that integrates Helios to take advantage of its benefits. Here are some exciting ideas:

• Supports retrieving light client data directly from the P2P network (instead of RPC)
• Implement some unsupported 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, embedding Helios into websites using WebAssembly to obtain data.
• Deploy the engine API to connect the Helios consensus layer to the existing full node of the execution layer.