As a reminder, there are three previous articles in this series that are helpful background for the current post.
Light clients, redux
Okay, so we've talked about what I'll call traditional light clients and how they don't work because they're based on a client-server model that's broken so therefore nobody uses them. Does that leave us with just Infura, Alchemy, and the like? The short answer is hopefully not.
The Portal Network - where we want to go
The Portal Network is a re-imagining of the light client as as a set of standalone peer to peer subnetworks of nodes that can run on consumer hardware (i.e. phones and laptops) that give normal users the ability to have a trustless view of the Ethereum network. So, let's break that down into the three important pieces we talked about in post 2, history, state, and consensus.
First, clients will need to be able to retrieve the history of the network (i.e. be able to retrieve past blocks). If there are lots of clients participating in this History subnetwork and everyone stores a little bit of the chain history (i.e. a few thousand blocks) and can find the other nodes in the network, then you can imagine a network where light clients can view the chain history.
Once we are able to share chain history, then you can imagine a world where light clients can reconstruct the chain trustlessly because everyone shared the history so you just sequentially rebuild the chain to the present and then you have state. But that's what full nodes do, not light clients. If we had to do that, we wouldn't have light clients. Instead, the State subnetwork is a second piece of the puzzle where all of the participants in the network share chunks of state and if you ask the network for your current account balance, you should be able to find it.
So now, we're in the magical land where we are able to pull past history and we have access to the current (or relatively current) state, how do we know we're on the right chain? How do we participate in consensus? The truth is, light clients will never participate in consensus. But, we can at least keep track of it via Header Gossip. That sounds strange but it's basically just a game of telephone where every time a full node somewhere creates the next block in the Ethereum chain, it gets broadcasted around this Header Gossip subnetwork. That way, we can have some confidence that our view of the chain is current.
There's one more piece we need to make our light clients to be able to do more than tell you your current ETH balance or how many bored monkeys you own. We need to be able to send transactions in order for any of the above to be genuinely useful. To do that, we need a Transaction Gossip subnetwork that allows to create and send transactions. This subnetwork lets us share these transactions amongst the light clients and make sure that Infura and Alchemy don't reject our transactions because of where our IP address says we're from.
There's just one problem with all of this. Where does all the data for all these subnetworks come from? Full nodes are the ones that have all this data and are they going to share it with the Portal Network?
Where we are today - 8/8/22
This whole Portal Network thing sounds magical and perfect, if it works, but does it? In a word, no, not yet. At the present moment (8/8/2022), there's a barely functional testnet for the History Subnetwork, and a bunch of Portal Network clients running mainly on servers...so, we're not there yet. But, here's what we have so far:
We have a proof of concept that allows light clients to connect directly to each other
The content behind those links is a lot of proof-of-concept, mostly technical jargon and I haven't even begun to address the cryptographic magic of merkle proofs - not really but tried to explain to a kindergartener, SimpleSerialiZe, and merkle log accumulators that make any of this possible but we just might be on to something here.
How do we get from here to there?
Keep building. -
- Loading comments...