The Road Ahead for Ethereum Light Clients

The Road Ahead for Ethereum Light Clients

Authored by Phil Ngo

New layer one blockchains promise a blazing fast decentralized future. But in reality, what we typically find is a set of sporadic non-committed users who connect to a single sponsored JSON RPC maintained by a foundation that connects to a small network of validator cartels.

It's worth asking ourselves, is this the future we want or a replica of old power structures? Maybe this is okay for now. But the truth is we can do better.

Decentralization matters

Decentralization matters for many reasons. It removes single points of failure and makes a system resistant to hostile takeovers and censorship by individuals or entities because of their governments.

Remember, there are several validator pools with non-trivial shares in the beacon chain. This is why we need a broad base of validators. We must be vigilant and need more people evangelizing decentralization.

Where do light clients fit? They can significantly increase the number of active network participants. Although they don't confirm blocks, they're valuable in terms of direct access to trustless blockchain data.

Light clients enable more people to participate as first-class citizens, verifying on-chain data without relying on single and centralized JSON RPC endpoints.

Light clients: trust minimization

In Ethereum, there are two methods for interaction, either running a full node or relying on a third-party service. A full node gives maximum security. You validate all the blocks, the state transitions, etc. With a full node, you cannot be fooled.

But running a full node, which consists of a consensus layer client (CL) such as Lodestar, and an execution layer client (EL), requires significant resources like a desktop computer. For post-merge Ethereum, it will be necessary to run an execution layer client like Erigon, Go-Ethereum (Geth), Hyperledger Besu, or Nethermind alongside Lodestar. This includes a good deal of heavy lifting to produce execution payloads and adds to the complexity of running full nodes for that full security.

The result is that most people will end up using Remote RPC, and in this case, you're just trusting whatever Infura, Alchemy, or any other JSON ROC endpoint spit outs.

Using someone else's RPC endpoints means potential exposure to data collection and censorship if they choose not to serve or publish your requests, as seen recently with TornadoCash interactions being blocked by Infura and Alchemy.

Lodestar's Dapplion presenting on light clients at ETHDubai.

Enter light clients - software that connects to full nodes to interact with the blockchain. Light clients are a resource-friendly and trustless alternative.

Because they offer a subset of functionality and don't store the full network history, they‘re performant for lower-end or resource-constrained devices. Imagine a world where your internet of things devices can trustlessly verify blockchain headers plus data by just downloading a snapshot.

With light clients, you still get the information from an endpoint (and in the future, a p2p layer), but it's possible to verify the information without running a full node. Critically, this removes the element of blind trust. In addition, light clients minimize hardware requirements without sacrificing the need for trust.

**Note that this assumes a model where miners follow the rules of Ethereum, and at least a full node in the system is completely honest.

The current landscape

We aim to foster the middle area where super-users, dApps, and perhaps even some sporadic users would pay a bit extra in exchange for more security. One way to do that is through light clients, a big part of the Lodestar vision and Vitalik's endgame.

Light clients in a proof of stake world

While Ethereum's Proof of Work architecture is not well-suited to light clients, the beacon chain's Proof of Stake is. In particular, post-merge, we'll rely on the sync committee, a feature that was introduced in the Altair hard work. The sync committee, and its associated infrastructure, allow a light client to stay updated to the head of the chain inexpensively. And it does this with a "good enough" guarantee of verifiability.

Given its design, the sync committee is difficult to corrupt. Randomly selected from the current validator set every 1.1 days, the sync committee consists of 512 validators responsible for signing headers of recently attested blocks. Every new block contains a sync committee signature and bitfield, saved directly into its fields. Instead, you can follow this validator committee which can be done cheaply.

Using this information, the light client can cost-effectively keep track of the latest header. Once you have that, you'd navigate through the consensus and execution layers to get all the required data, balances, contracts, calls, etc.

Here's what it looks like:


Lodestar: browser light clients

Lodestar implements an endpoint that exposes light client-friendly data and also introduces a server that can be used to track the blockchain. Best of all, Lodestar is written in TypeScript, which makes it possible to use all these elements in the browser to create browser-based light clients.

With a browser-based light client, once you have a safe head, you go into the consensus layer data, and you can get fun stuff like the latest execution head with Merkle proofs. You can repeat the same with the execution layer (state proofs), and you can retrieve things like account balance, nonce, contract storage, proofs for blocks, etc.

Bottom line: it's possible to cover almost all the JSON RPC with these sorts of tricks.

Latest updates

So far, with Lodestar, we've built a Rest API. For those who want to try it, you can run a Lodestar node and query the available endpoints:





Apart from these REST endpoints, the team is currently working on making light client data available via a p2p interface. This makes serving light client data more idiomatic and decentralized, as any light client can request the data from the p2p network instead of relying on an endpoint.

It's also worth mentioning the Portal Network, a coordinated, cross-team initiative to realize the light client vision that focuses on p2ping JSON-RPC endpoints.

This introduces another mechanism for a light client to request data it needs from a full node. In addition, Portal Network includes work on an "ultralight client," which allows JavaScript applications to connect to that network for data.

The Portal Network is important because it represents a more resilient solution than what we have right now.

Light client summit @ Devcon VI

Another important thing to be aware of is a potential light client summit at Devcon. Topics could include trust-minimized L2 bridges based on light client data, p2ping light client data, hardware and software wallets, light client applications in lower resource devices, etc. If you're interested in light clients, we want to hear from you!

Etan Kissling at Nimbus and Alex Stokes at the Ethereum Foundation are spearheading some of the work on Ethereum Light Clients, and you can get involved too via the Eth R&D Discord under the #light-clients channel. You can also reach out to us at Lodestar or subscribe to the Ethereum light clients telegram channel for further updates.


At Lodestar, we have a light client browser demo, we're actively contributing to the spec, and you can check out our work in detail here. Run Lodestar today with our quick start guide or drop by our Discord👋 . Much more to come. Stay tuned!

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, Mina, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs and decentralized storage.
As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.

Website |Twitter |Linkedin |GitHub |Discord |YouTube


This article was co-authored by Colin Adams.