image courtesy of Vitalik's endgame post
Preface
Ethereum can support both full nodes and light clients, it contains a peer to peer layer which allows nodes to send messages to each other. While Ethereum's current architecture is not particularly well-suited to light clients, the beacon chain architecture is. This means that post-merge, they will have an important role to play. A light client is a cheaper alternative to a full node (from a bandwidth and resource consumption perspective) since it only downloads the header from each block and trusts the full nodes to check that the state transitions are correct (in other words, a light client trusts the full nodes it is peered with to verify that the block producer hasn't tried to print new coins, spend coins from an address for which they don’t have the private key, or make larger blocks than the consensus rules allow them to do). This does beg the question however: under what assumptions are light clients able to protect themselves from malicious block producers?
Relaxing assumptions
In the endgame, we expect that most individuals will transact on Ethereum using light clients without even knowing it. For example, the plan has always been for the Status mobile app to come integrated with a light version of Nimbus.
Since light clients typically only download block headers, and don’t verify transactions themselves, we are used to thinking of them as having weak security guarantees compared to full nodes: under the conventional model, they are forced to rely on an honest majority assumption (which means they must assume the chain is valid by default).
However, it turns out that we can do significantly better than that.
Thanks to the magic of fraud and data availability proofs, we can relax the honest majority assumption, and make a 1/N honesty assumption instead. Practically speaking this means a light client only needs to be peered with a single honest full node in order to inherit almost the same security guarantees. In the rest of this post we will refer to this genre of light client as a light node.
A light sketch
While we won't get into the gory details here, here's a light sketch of how this works.
When a light node receives a block header, it probabilistically samples enough shares from the Merkle tree that the Merkle root represents to convince itself that the entire tree is indeed available for full nodes to verify (in other words, the light node is able to verify that the block producer has not withheld any data from the network).
At the same time, it listens for fraud proofs – a small, and quickly verifiable proof that a specific transaction in a block is invalid – from the nodes it is peered with. A valid fraud proof convinces that light node that the Merkle root in the block header is in fact incorrect. In the absence of a valid fraud proof, it goes ahead and accepts the block header as truthful.
What does this tell us?
The key takeaway here is that as long as a light node is peered with at least one honest full node, it has practically the same security guarantees as that full node (since it can expect to receive a fraud proof from it if the block header it receives is incorrect).
A more subtle insight to be gleaned here is the following: light nodes can only offer the same protection as full nodes if enough people run both light and full nodes. This is true because you need enough light nodes in the network to collectively recover blocks, and enough honest full nodes to give every light client a good chance of being connected to at least one of them.
It follows that to ensure a resilient network, one in which individuals transacting on Ethereum can detect if/when block producers are trying to change the rules on them, we need to do two things:
- Make it dead simple to run a light node on mobile devices (and other resource-restricted devices).
- Make it dead simple to run a full node on low-power commodity hardware (in particular this includes Raspberry Pis and everyday laptops).
These two things become especially important in a world in which block production is centralised (the likely endgame we are heading for).
A means to self-sovereignty
To fork the words of John Adler: thanks to fraud proofs and data availability sampling, we can think of decentralisation as some function of the cost to run a full node and the cost to run a light node. Not because running either is anything special, but because they are a means to an end: self sovereignty*.
*Self sovereignty in this context means that we, the community, are able to detect when block producers try to change the rules that we all agree on.
Resources
- Beacon Chain Light Client Classification
- Beacon Chain Light Client Networking
- Beacon Chain Light Client Design Doc
- Bootstrapping the Beacon Chain Light Client Ecosystem
- Altair: Minimum Light Client Spec
- Lodestar Light Client Demo
- Nimbus Light Client Syncing Implementation
- Experimental Nimbus Light Client Server
(expand the commit description ... for instructions on how to play with it) - Run a Nimbus Beacon Node
Thanks to Barnabé Monnot and Ștefan Talpalaru for reading drafts of this.
