(Part 1 of my series on light clients and why we should care about them)
In my previous post, we dealt with some of the preliminaries of trying to define a light client and what it is and isn't in the context of the Ethereum blockchain. Let's take things a bit further though and try to understand why we're even having this conversation.
A light client isn't...
...a full node which in general terms is the piece of software that runs a blockchain, or at least your local copy of a blockchain. When your full node talks to all the other full nodes, you get consensus (i.e. agreement on who has what money and who's sending money to who or interacting with which smart contract in the current block), history (i.e. who has sent money to to who and who has interacted with what smart contract), and state (i.e. who has what money and what NFTs at present and which smart contracts are out there that you can interact with).
A light client doesn't really do any of these things well since it's supposed to be light (i.e. not require hundreds of gigabytes of storage for history or state) and not always on (i.e. not have -- or maybe not want -- to participate in consensus). What does it do well? To answer this question, let’s explore a few light client implementations and think about what they do that's useful.
Prior art
In the previous post, we gave a very high level look at the current Ethereum light client and why it's doesn't really work that well at present. So, what are other people doing out there in the world that might work better?
Plumo
The Plumo light client protocol is a recent creation of the Celo blockchain, an EVM based chain that aims to be mobile first, so a logical place to want light clients. If we very much oversimplify what Plumo does is that it allows a light client to quickly and trustlessly start at the genesis block and quickly skip over huge chunks of block history and get to the tip of the chain through the math-magic of zero knowledge (ZK) proofs. These proofs basically take a huge stretch of blockchain history and boil it down to a magically trustworthy proof that from time X in the past when my Plumo client was last online until I just now turned my Plumo client back on, all these blocks have been mined and the blockhash that this full node just sent me along with the ZK proof is really the tip of the chain (or close to it). I'm not even going to try and explain the underlying math (since I don't really understand it myself) but go here if you want to nerd out on the math and why Plumo works. Let's just assume this works. So what? This gets us to the place where a light client at least has a trustworthy view of the current tip of the chain (i.e. consensus) and therefore can trustlessly retrieve history (i.e. they can ask any full node for any block prior to the tip of the chain and can verify that it's the correct block at the place the full node claims it is). That gets us two of the three things we said a full node would give us "for free." So that's cool, but Plumo doesn't currently run on Ethereum proper so that doesn't help us all that much.
Beacon Chain light clients
In Ethereum's post-merge world, there is something similar to Plumo afoot. In the Altair hardfork, explicit support for light clients was baked in following basically similar logic to how Plumo works. Instead of super fancy ZK proofs, the beacon chain (Ethereum's consensus protocol/layer after the merge) produces updates and proofs that allow a light client to quickly sync to the head of the chain, using similar logic to Plumo. Multiple teams are working on light client support for the beacon chain.
But...who cares? Everything we've seen above only helps us get to the tip of the chain, not actually know my account's current balance or how to interact with a smart contract (not entirely true but close enough for the current discussion). How does this help me and Metamask trustlessly interact with the blockchain and not count on Infura/Alchemy to not let us down?
Client/Server architecture - the light client’s original sin
I referenced this last time but but perhaps the biggest issue in light client design is that everything we've explored is based on a client/server architecture. Here again, that in itself isn't necessarily a problem. It's how the internet as a whole generally works. The programs on your phone or on your computer are clients that get the data they need from servers running somewhere else. But that's not how blockchains are supposed to work. The whole idea is that a decentralized network of peers (i.e. full nodes) are all able to produce agreement (i.e. consensus) about the state of things in a way that nobody can question the results because the math makes it so. The problem is that the light client designs we've explored all rely on full nodes to play the role of servers and feed the data to the light client. So, even if we can be 100% confident that the blocks a full node is sending my light client are part of the correct chain, if I can't get a full node to send me those blocks, my light client is worse than useless, and full nodes aren't required to support light clients, at least not on Ethereum. Some people have tried to solve this problem by paying full node operators to serve light clients the data they need. But, that's really no different than just using Infura.
So, seriously, what's the point of all this? Are light clients that actually work a possibility? I'm not sure but we'll think about it some more next week.
- Loading comments...