On 30/06/2016, the public test phase for the Ethereum Light Client has started. During this period users, application developers and alternative client developers will already have a chance to evaluate the Light Ethereum Subprotocol (LES) and its Go Ethereum implementation while we're shaving off the remaining rough edges and implementing the missing parts. The protocol and API implementation is mostly working but not thoroughly tested yet so expect some surprises, please be careful (try on the testnet or do not operate with too much money if you're using it on the mainnet). If something is not working as expected, please report it on the https://gitter.im/ethereum/light-client gitter channel after checking the Known Bugs and Missing Features and Recent Updates sections.

• git clone -b light-stable https://github.com/zsfelfoldi/go-ethereum.git
• build it with Go 1.6 (won't compile with earlier versions)
• add the "--light" flag for light client mode (run "geth --light console" for console mode)
• you can also run it on the testnet by specifying the "--testnet" flag or the original unforked "classic" chain with the "--oppose-dao-fork" flag
• you can run the light client with the same (default) data directory you use with the normal client, it uses a separate "lightchaindata" database directory instead of the standard "chaindata" so it won't interfere with your regular chain database (can't run the two simultaneously with the same datadir though).
• initial syncing starts from a trusted checkpoint (later this will be implemented in a trustless way). Past headers are still accessible on-demand. Trusted checkpoints are hardcoded into the source both for the mainnet and testnet.

LES is an asymmetrical (client-server) protocol which needs to download data from a regular "full" node. After the official release of a LES-capable Geth version, hopefully many full nodes will offer LES services with a limited bandwidth that ensures that it doesn't interfere with their normal operation. In a subsequent release a micropayment option is planned that can buy a higher priority/bandwidth for clients and provide incentive for the servers. In the meantime though, there are no user-operated LES servers available, and also our current peer discovery mechanism needs to be improved (work in progress) in order for clients to be able to reliably find servers.

For the test period, we have set up two test servers (one for mainnet, one for testnet) and hardwired their addresses to the client test version so that in light mode, the appropriate server is added to the peer set by default and automatic discovery is disabled. If you'd like to run your own LES server (for a private net, for example), that's also possible. If you run this version of Geth in the regular "full client" mode, it automatically acts as an LES server, you just need to add it as a peer manually to the light client. You can run the server and client on the same machine too, in this case specify a different port and data directory for them.

If a light client has no server attached or the server is too busy, it cannot read anything from the chain/state so it is possible that requests get blocked. Every request can be cancelled by closing and reopening the RPC channel. In the current version the console has a 5 second timeout (will be user configurable in later versions).

• applications should also be aware of the possibility that requests get blocked for a longer period
• in many cases, apps retrieve blocks but really only need data that are present in the block headers. With a light client, retrieving headers is much cheaper (faster) than retrieving blocks since headers are present locally while block bodies are requested from a server. Currently there are no functions to retrieve header data only but we'll probably add such API extensions soon.
• in a light client, transaction pool works differently. It never receives transactions that are created elsewhere, it only keeps track of locally created ones. This means that retrieving pending transactions will only return locally created (but not yet mined) transactions.

• VM log filter for new blocks doesn't work yet. Searching for past logs works, but be aware that it is slower because the "MIP mapping" optimization is a bit more complicated to properly implement in a light client (not impossible though, will probably be added in future versions). Currently, scanning the entire chain for logs might take 1-2 minutes.

• 06/30/2016 Initial test release
• 07/08/2016 Instant sync from trusted checkpoint
• 07/19/2016 Rewrote header fetcher, rebased on latest develop