Making the ecosystem more light-client friendly

One of the challenges of the current Ethereum ecosystem is that while the protocol is theoretically light client friendly, and light clients even exist and can be used today, they're not nearly as commonplace as was originally envisioned. Particularly, all of the following environments could have been secured by light clients, but are instead typically secured by APIs connected to centralized services:

1. Mobile phone clients/wallets, even those where the key management is trustless (Status, Argent, Loopring, etc etc)
2. In-browser wallets (Metamask et al)
3. Other blockchains

There are two main problems:

1. The Ethereum light client verification protocol is not light enough.
2. There's not enough incentive to serve light clients, leading to weakened performance.

We can think of each of these two problems as being tied to a corresponding one of the two key parts of a light client protocol. The first part is to download and authenticate the header chain, giving you Merkle roots to transactions and history and state; this is the part that is stymied by the Ethereum light verification protocol's heaviness. The second part is, given the Merkle roots, to get Merkle branches for any data you want to learn so that you can authenticate the data.

Light client verification of headers

(1) is a big deal. For a light client to stay synced with the eth-PoW network today, they need to sync the eth-PoW header chain, which is about 600 bytes per 13 seconds: trivial for a phone or browser app, but already getting expensive for the light-client-inside-a-blockchain use case. And in all three cases, it precludes the user-experience gain of instant syncing after a long time offline. Even worse, the PoW algorithm (ethash) takes a long time to verify. Despite being explicitly designed for light client friendliness with its "cache" mechanism, cache-based verification still takes a significant amount of time.

The beacon chain has some upgrades in store, coming in the first hard fork, that allow light clients to stay synced with the beacon chain much more efficiently: a mere ~10 kB per day should suffice for basic connectivity. Verification will be significantly more computationally efficient than ethash.

Note that even before the merge, a light client of the beacon chain can double as a light client of the eth-PoW chain: the beacon chain contains a hash of an eth-PoW block about 10 hours old, and so a client could choose to use the beacon chain to sync up to that point and then download eth-PoW headers from there. This would not be nearly as efficient as pure beacon chain verification after the merge, but it would still be a considerable gain.

Merkle branches

The problem with Merkle branches is simple. There are a lot of potential light clients, and each light client wants to learn a lot of information about the history and state, and it's expensive to send all that information and generate Merkle proofs for it. The problem is worse because there's no incentive to help send information, so relatively few nodes are doing it.

There are two main kinds of solutions to this problem:

1. Create a channel-payment protocol where nodes can get paid for supplying proofs.
2. Reorganize the p2p network to make providing proofs simpler and cheaper; see Piper Merriam's work on this.

But either path will take some time to get right, and there's a lot of work to be done (realistically there's a good chance we'll need to do both).

A short term path

But we should not despair from the complexity of a fully functional light client network. Even if all we can do is have a trustless header chain verifier, and we can't make a reliable and decentralized protocol to fetch Merkle branches, this by itself can greatly increase the security guarantees of mobile phone and in-browser clients.

This is because instead of asking a server to provide responses to queries and trusting those responses, a wallet can now maintain the header chain locally, ask the server to provide responses along with Merkle proofs proving that the responses are correct, and verify the Merkle proofs. This is an intermediate mode that would be nice to move the Ethereum ecosystem over to soon. In the longer run, we can work harder on making a more fully decentralized light client ecosystem.