Ethereum Foundation Introduces Light Client For Dapp Developers
In a recent post on the Ethereum Foundation’s blog, Zsolt Felföldi introduced the first version of the Light Ethereum Subprotocol (LES). The LES is a light client for the Ethereum network, and through the protocol’s Geth implementation, Dapp developers will be able to start utilizing the protocol while it’s in its experimental stage.
A light client is like a normal Ethereum client, except it only downloads block headers by default, instead of the full blockchain and every transaction across the network. A light client only verifies a small portion of network data – processing only what it specifically needs to function. While the light client protocol is mainly geared toward users in low-capacity environments such as smartphones or browser extensions, these users still need a highly secure assurance over the current state of the Ethereum network, or of a particular part of the Ethereum state.
While the LES functions similar to a “full” client, its “lightness” comes at a cost. These shortcomings are worth keeping in mind if you’re a Dapp developer thinking about implementing the protocol. Currently, the LES has a few limitations regarding pending transactions and finding a transaction by hash.
As far as pending transactions are concerned, a light client only knows about transactions that have been created and sent from that same client. They do not receive all pending transactions across the main Ethereum network. As to searchability, the light client would only be able to search by hash for transactions created locally. There is still work to be done on reliably finding other transactions by hash since there is currently no ironclad way to determine the existence, or non-existence, of a transaction outside of ones created by the light client itself.
There are also several performance issues to consider with this very early version of the protocol. Seeing as how a light client only stores the last few thousand block headers in its database, a light client would need to send a request to a light server to retrieve any additional information, which can contribute to latency. In an attempt to optimize request distribution and reduce latency, the light client collects data on server response times, so it can weed out slower servers, eventually only relying on servers with the quickest response times.
Once more improvements are implemented into LES, and the protocol is able to retrieve anything on demand, its database will act more like a cache. That means a light client will be able to allegedly run with as low as 10Mb of storage space. This would be a major benefit for smartphone Dapps. The current Geth implementation of LES uses about 200Mb of memory, which the developers hope to continue reducing.
This light client subprotocol is still being developed, so there are some future improvements on the roadmap that should help with latency and verification issues. Developers are working toward having the protocol do as much computation outside of the light client as possible, instead of the alternative: passing data back and forth between a light client and a server. In this case, the server would execute a function on its end and only send the light client enough data to verify that function, decreasing latency by eliminating several round-trips for data.
Another improvement would be the ability to verify complex calculations indirectly, which would allow a light server to be able to remotely evaluate an operation that a light client wouldn’t be able to efficiently perform itself, for logistical reasons, due to a lack of storage, bandwidth, or processing power. Developers are actively working on this type of verification method.
There is still a fair amount of work to be done before the Light Ethereum Subprotocol can function at peak efficiency. Good things are coming this year, and a fully-functioning light client will be an exciting tool for Dapp developers.