Are we there yet?

Photo by Brandon Kaida on Unsplash

If you haven't been following this series, please see my previous four articles. A lot of the things I reference have been covered previously so I won't be going back to define terms again.

To be honest, not a lot. But that's okay because something bigger happened that has a lot of ramifications for the road map of the project. And that is...the Ethereum Merge :tm: happened. This series doesn't care about Proof of Work vs Proof of Stake and how much electricity the node operators are using. Let's set aside the huge technical accomplishment that was the Merge and talk about what it means for the Portal Network and light clients. See, the one thing the Portal Network has built so far that is somewhat interesting is a relatively memory efficient way for a light client to track the entire history of the chain, something called a Header Accumulator. Let's break that down.

• Header -- This just refers to block headers, which is the metadata for each block in the chain that tells you the block hash, who mined it, the current total difficulty, etc. This is the thing that traditional Ethereum light clients collect one at a time to build up their view of chain history (which is important for a light client to be able to trust the network since we have to know we're on the right chain!).

• Accumulator -- This is a fancy way of saying a collection of something. What's important about this accumulator is that it's a sequential list of the block hashes (starting from the genesis block up to the present) that somebody has built up over time. Which sort of sounds like what Ethereum LES clients already do.

So what's special about a Header Accumulator. Well, it's not a list of all the headers. It's a compressed list of all of the block hashes from those headers that can then be used to reliably know the entirety of chain history maintaining only this fancy SSZ data structure. Which means in relatively normal English that if I have an up to date header accumulator, I ask for a header from the Portal Network and another node sends me one back, I can verify that it's the right header for which ever block I want to see because of the magic of merkle proofs. And, this whole data structure is only a few megabytes, which is perfectly reasonable for any light client to maintain. But then, the Merge :tm: happened. Without going into the details (which require several whole Github issues to really explain), when the Merge happened, the header accumulator is basically done. It freezes as the last Proof of Work block and is now frozen in time, a sort of permanent history of the pre-Merge chain that light clients can use to verify any block header from that era of Ethereum time.

I referenced this before but the post-Merge Ethereum world has somewhat better support for light clients than the LES protocol.

Before we dive into the details, I want to define one term finality or finalized. When applied to Ethereum's proof of stake consensus, this means that a block has been finalized (i.e. attested to by a majority of validators and included in a completed epoch) and enshrined in the history of the chain and cannot be rolled back so a bad actor would have to acquire a majority of the stake and then fork the chain

With the Altair hardfork, there are two new light-client specific additions:

1. Light client updates are general purpose chunk(s) of data that includes a finalized block header per update period (~27 hours) that the light client uses as a reference point syncing forward on the chain. Think of it like a "canonical header" used as a starting point for syncing the recent history of the pre-merge proof of work chain.

2. "Sync committees" that are a rotating subset of the validators that have the job of attesting to the validity of each block in the chain as progresses. If a validator fails to participate in the sync committee process, it misses outs on sync committee rewards that substantially exceed the normal attestation reward/penalty so all validators are incentivized to do this work.

Once a light client gets its snapshot of a recently, finalized block header, it can track the progress of the chain using the sync committee updates and can leapfrog forward in epochs of chain history based on the sync committee updates that are provided by validators as part of their ongoing participation in consensus.

So, between the Portal Network's header accumulator and post-Merge light client updates/sync committees, light clients are now better equipped to easily validate the history of the chain and see what the current tip is, which means its easier for them to trust other participants in the network (i.e. full nodes) since full nodes can't easily fool a light client into thinking it's on the correct network when a full node feeds it malicious data.

In the current state, light clients are still dependent on full nodes to provide this light client snapshot and sync committee update via some not yet finalized interface (the same way that full nodes had to willingly serve LES data to old-style Ethereum light clients) and there's no built in incentive for them to do it yet. And, there is no agreed upon specification. Two teams, Chainsafe and Nimbus, are working a client/server model (which we don't like) and a peer-to-peer model (which we do like) for how light clients can more trustly get this data, but neither is yet a compulsory part of the beacon chain consensus rules.

So...we've still got some work to do, but it's encouraging to see where things have come. Through the rest of the series, I'm going to explore some other light client models to see if we can gain any new ideas for how to improve on the status quo for Ethereum.