To Bellatrix and Beyond!

Any idea where Bellatrix is? I couldn't find it on a star map but I do know it's the second hardfork on the Ethereum Beacon chain and with it, we have a "merged" Ethereum world where light clients should have a relatively easy time tracking the head of the chain via the lightClientUpdate and syncCommittee, which gives them an up to date view of chain history. And, since it's part of the core Beacon chain spec that every node most implement in some capacity, some large-ish portion of nodes should support it out of the box, unlike the old LES protocol.

So, this is great. We have our light client that can connect to any beacon node that supports the light client API, grab the latest finalized headers from the sync committees that correspond to a large portion of the overall validator set, and feel reasonably confident that we have a correct view of the chain. Or can we?

Lets think this through. In the new, post-merge world of Bellatrix and beyond, light clients still depend on full nodes to serve this light client API that lets them read the sync committee updates and track the finalized headers that are attested to by a supermajority of validators (so therefore should be reliable for purposes of a light client trying to stay up to date with the chain). But can we trust full nodes?

At present, there isn't any single spec for the light client API that two implementations of the beacon chain share. As we've noted before, Lodestar has a REST API model for light client data implemented (think client/server like the LES model). Nimbus has a peer-to-peer implementation that presumably a light client can participate in by sharing the light client updates around the network. But they're minority clients on the chain. And...in the case of a REST API, you're 100% dependent on the the few Lodestar nodes out there that serve the REST API to be able to get your updates. So what happens if one goes down? Or what happens if the Nimbus client has a consensus bug that causes it to fork out of the network. Then you're stuck.

Proof of Stake (PoS), like Proof of Work(PoW), has potential weaknesses that can be exploited in certain circumstances, such that full nodes can end up on a malicious fork of the network where honest validators get removed and only a malicious set of validators. In PoW, the most familiar version of this is the 51% attack, where a bad actor gains 51% of the hash power in the network and rewrites history to suit their own needs, or selfish mining where a mining pool with a lot of hash power mines it's own fork of the chain for a number of blocks and then pushes those into the network and causes a reorg that follows the miner's specific version of the chain. In PoS, there is a class of attacks called "long range" attacks that are similar in that a malicious actor gains control of some significant minority of validator keys and then creates a fork of the chain from some point in chain history using only those validator keys and eventually succeeds in building that chain up to the point where it presents a viable alternative to the "majority"/honest validator chain. This long range attack is a particular danger to light clients who are in general online only occasionally so are dependent on full nodes that support the Light Client spec in the Altair hardfork to track the head of the chain. If the first node they connect to happens to be a malicious node on the minority fork of the chain, they may never realize they are on the wrong chain (with all sorts of obvious bad potential outcomes if that were to occur to a light client embedded in a popular web3 wallet or other popular web3 application). So how to do we protect against things like this?

In just the past few months, a new concept of a "superlight" client was introduced by Shresth Agrawal that uses some fancy new to sync the beacon chain on an exponentially faster scale than even current Beacon chain light clients. The implementation itself is still at the proof of concept stage but has some really exciting possibilities. The most notable one is that it can enable a light client to escape the long range attack through what the paper calls an "interactive bisection game". It's something like the interactive fraud proof game that the Arbitrum Layer 2 uses when posting updates to Ethereum mainnet and it can allow a superlight client to detect when it's being fed malicious data merely by querying data from a few other nodes and then comparing the sync committee updates between the two and doing some fancy "merkle mountain range" cryptography on those updates to determine which validator is lying and therefore must be on the wrong chain. You'll have to read the paper to understand the math on how it works but the concept looks very promising.

So, here we stand on the furthest edge of Bellatrix with some exciting light client possibilities on the horizon. As a certain plastic astronaut once said, to infinity and beyond!