The following is based on a recent Twitter Spaces, with light client enthusiasts Phil Ngo, Gajinder Singh (Lodestar), Guillaume Ballet (Geth), and Matt Garnett (EF).

At Lodestar, we’ve been long-time proponents of light clients, software that connects to full nodes to interact with the blockchain. As a resource-friendly and trustless alternative to running your own full node, light clients reduce the need to trust third parties. Although they don’t confirm blocks, they’re valuable in terms of direct access to trustless blockchain data.

However, for all their theoretical value, there’s still work to make light clients a standard part of interacting with Ethereum. Below, we’ll delve into some existing challenges (and progress) while emphasizing the importance of trustlessness without hindering user experience.

What are light clients?

The most decentralized and trustless way to engage with Ethereum is to run a full node. But this is no easy task—it involves maintaining an independent copy of the blockchain, and instant and direct access to Ethereum’s peer-to-peer network, which demands substantial memory, storage, and CPU, rendering it unfeasible for many users. This is all not to mention that, in many cases, it’s unnecessary to validate the entire chain.

Solutions to this issue, such as statelessness, are years away from becoming a reality. For now, sacrificing a few benefits of running a full node to function with minimal hardware requirements is a promising solution that we’re optimistic about.

Indeed we published an article on light clients last year, championing them as a solution to some of our problems.

To this end, light clients play a pivotal role in blockchain systems, offering users who do not want to run full nodes secure access to Ethereum without synchronizing the entire network.

Instead of storing local blockchain data and autonomously verifying changes, light clients acquire the data they need from a provider, which could connect directly to a full node. This data is then processed by the light node, allowing it to confirm it’s part of the canonical chain and stay updated.

Ethereum is not the only ecosystem actively working on light clients.

The challenges of light clients

As we all know, running a full node involves resource-intensive tasks and limitations concerning device capabilities and computational requirements. While light clients might seem like a simple alternative, historically, they’ve been hard to implement.

However, the merge fundamentally altered what it means to be a light client on Ethereum, both in terms of how they’ll work and what they will offer. The Altair hard fork introduced the sync committee, i.e., a useful way to get a light consensus on what the head of the chain is. In essence, this is a more native integration of light clients into the protocol.

With proof of stake, we now have a light client protocol where you can basically pick any part of the chain, construct a proof, and do a deep dive. This wasn’t previously available, making the whole space more interesting and encouraging more people to build around light clients.

Lodestar prover
One of the things the Lodestar team has been working on is a prover. That is, using the light client sync to verify data from the execution side, so verifying the info you’re getting from a provider (like Infura) is correct.

The hope is that things like this will add another layer of security and a bit more decentralization to the protocol. This is also just a first step. We need more concrete examples of what can be built with this potential.

What’s stopping us from using light clients today?

The answer to this has less to do with the technical side and more with the adoption of the PoCs and infrastructure we have (e.g., the Prover Library).

We need to add more proving capabilities regarding transactions and receipts, which would require us to move to SSZ encoding of transactions, but apart from that, protocol-wise, we’re there.

We can actually use this tech right now! In terms of UX, though, we need to get to a place where the light client is just running in the background and does not disrupt users or require additional steps from them.

It’s, of course, hard to force the adoption of something in a decentralized space, but we should be thinking about how to use incentives to promote this and how we might get MetaMask, Rainbow, etc, to consider it as well.

The shift from Merkle to Verkle trees

Changing the data structure for greater efficiency—moving from the Merkle Patricia tree setup to the newer Verkle trees is a game-changer for light clients that would otherwise struggle with hefty proof sizes.

The introduction of Verkle trees addresses this concern via a new data structure. Through its innovative use of polynomial-based techniques, Verkle trees substantially reduce the size of proofs required for verification, making the process more manageable and streamlined for light clients.

“The idea is that thanks to Verkle, you have small proofs. And because of that, you can provide light clients, let’s call them stateless clients, with a way to verify everything that’s been given so there’s less trust involved.”

This update signifies a fundamental shift in how light clients interact with Ethereum’s data, enhancing their capability to efficiently verify the blockchain’s state without compromising on security or trust.

Not only does this benefit the current light clients, but it also sets the stage for future innovations, creating a space where users can deal with Ethereum more smoothly, securely, and efficiently.

Should light clients be standardized across L1 and L2?

This is a somewhat controversial topic that’s currently up for debate. Per Guillaume, “I think we should not harmonize the data structure yet because L2s are experimenting, they are the move-fast-and-break-things people, and the L1 is more cautious and a bit more conservative.”

The truth is that we likely need more time to consider standardization. What makes sense regarding timing is an open question, but we’re perhaps five to ten years before the community can even think about a harmonization process.

This delay is arguably justified by the complex nature of the Ethereum layers and the challenge of implementing changes due to the technologies and designs already in place. The bottom line: we should wait for a more suitable time for any potential standardization efforts, allowing for a more mature and stabilized Ethereum infrastructure.

The Light Client Summit @ DevConnect 🇹🇷

Ethereum builders from around the world are set to gather in Istanbul, Türkiye, next week for Devconnect—join us for the third iteration of Light Client Summit, featuring presentations and discussion on the direction of light client development!

Can’t make it? Stay tuned on Twitter, join the conversation on Telegram, or get in on the action via Discord #light-clients.

Lodestar

Lodestar is the newest Ethereum consensus client built with TypeScript and maintained by ChainSafe. Our open-source client and libraries make developing on Ethereum accessible to the largest group of developers in the world. With a focus on light clients, Lodestar aims to improve the usability of verifiable blockchain data for all types of devices and their users.

Contribute to client diversity. Run Lodestar with our quick start guide. Have a question? Drop by our Discord👋

Disclaimer：

1. This article is reprinted from [chainsafe]. All copyrights belong to the original author [Colin A]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.