Ethereum Light Client Helios: A New Option for Trustless Access

On November 8, a new Ethereum light client Helios was launched. This client, developed in Rust, aims to provide completely trustless access to Ethereum.

One of the major advantages of blockchain is the need for trustlessness. Through blockchain technology, users can have full control over their wealth and data. Blockchains like Ethereum have indeed delivered on this promise in most cases, allowing users to truly own their assets.

However, for convenience, users often make some compromises. One of them is using 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. When wallets query token balances or check whether pending transactions have been packaged, these centralized providers are almost always used.

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

Helios, as an Ethereum light client, provides completely trustless access to Ethereum. It utilizes the light client protocol enabled by Ethereum's transition to PoS, converting data from untrusted centralized RPC providers into securely verifiable local RPC. Combined with centralized RPC, Helios can verify the authenticity of data without running a full node.

This client can complete synchronization in about two seconds without storage, allowing users to 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? This article will outline these risks, introduce Helios's design plan, and provide some ideas to help developers contribute to the codebase.

Potential Risks of Centralized Infrastructure

In theory, a new type of attack may lurk within the Ethereum ecosystem. This attack does not directly target the transaction memory pool (Mempool), but rather sets traps by mimicking the centralized infrastructure that users rely on. The users who are attacked have not done anything wrong: they are simply accessing the DEX as usual, setting reasonable slippage, and trading tokens. However, they may face a new type of sandwich attack, which is carefully laid out at the entrance of the Ethereum ecosystem—RPC providers.

To understand this type of attack, we first need to understand 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 sets the "minimum output" for the transaction; if this value cannot be reached, the transaction will be canceled. This is commonly referred to as "slippage," which effectively limits the maximum price movement that may occur from the time the transaction is sent to when it is packaged.

If the slippage setting is too low, users may only receive a small amount of tokens. This situation may also lead to a sandwich attack, where the attacker places the user's transaction between two malicious transactions. These transactions will drive up the spot price, forcing the user to complete the trade at an unfavorable price. Subsequently, the attacker will immediately sell the tokens to gain a small profit.

As long as the minimum output parameters are set within a reasonable range, users will not suffer from sandwich attacks. But what if the RPC provider does not provide an accurate quote for the DEX smart contract? This may lead to users unknowingly signing unfavorable exchange transactions. Worse still, users might send transactions directly to malicious RPC providers. The provider could choose not to broadcast the transaction to the public mempool, but instead privately withhold and send the attacked transaction bundle directly to specific services, profiting from it.

The root cause of this attack is the trust in others to obtain the state of the blockchain. To address this issue, experienced users often choose to run their own Ethereum node. However, this requires a significant amount of time and resources, needing at least one continuously online device, hundreds of GB of storage space, and about a day to complete the initial synchronization. Although some teams have been working to simplify this process, running a node remains a challenge for most users, especially mobile device users.

It is important to note that while attacks on centralized RPC providers are theoretically possible, there have been no actual cases so far. Although the track record of large providers is trustworthy, it is still wise to conduct thorough research before adding unfamiliar RPC providers to your wallet.

Helios: Trustless Ethereum Access Solution

After Ethereum launched the light client protocol, it opened up new possibilities for fast blockchain interactions and validating RPC endpoints with minimal hardware requirements. In the month following The Merge, several independent light client projects emerged, each employing different approaches, but all dedicated to achieving the same goal: efficient, trustless access without the need to use full nodes.

Helios is an Ethereum light client that can complete synchronization in about two seconds, requires no storage, 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 couples these two layers, allowing users to install and run a single piece of software.

The working principle of Helios is as follows: the consensus layer uses a known beacon chain block hash and connects to an untrusted RPC to synchronize to the current block in a verifiable manner. The execution layer then combines these verified beacon chain blocks with an untrusted execution layer RPC to verify 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.

Practical Applications of Helios

Helios, as a light client, allows users to securely access on-chain data from any device (including mobile phones and browser plugins). This will enable more people to access Ethereum data without trust and without hardware limitations. Users can set Helios as the RPC provider in their wallets to access various DApps without trust, with the entire process requiring no other 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 reliance on centralized infrastructure.

The community can contribute to Helios in various ways, not only by adding to the codebase but also by building software that integrates Helios. Some promising directions include:

• Supports obtaining light client data directly from the P2P network
• 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 a website using WebAssembly.
• Deploy the engine API to connect the Helios consensus layer to the existing full node of the execution layer.

The emergence of Helios brings new possibilities to the Ethereum ecosystem, promising to enhance user convenience in accessing blockchain data while ensuring security. With continued contributions and improvements from the community, Helios could become an important tool for further decentralizing and popularizing Ethereum.