What are the design targets which the light client is being developed against?

Question

For example:

• persistent storage?
• volatile storage?
• connectivity?

The closest I could get to a definition for the above is the following: "1KB of data per 2 minutes". However the following remains unclear:

• is the light client required to store this 1KB every 2 minutes?
• what happens if the client runs out of capacity?
• what if the client looses connectivity for an hour... a day.. or perhaps longer?
• does the connectivity have to be synchronous or can it be asynchronous? i.e. can the client "wake up" at any time, or is it expected to synchronize at some specific points in time?

Answer 1

The light client fetches all needed data from other nodes in the network. This means that if you request some data from your client that is does not have, it needs to pull it from the network. So it needs connectivity for that. If you request something it already has, then it will use that to reply. Intermittent connection is not a problem as long as you don't want to use it while offline. However, it's designed to be an online tool.

There are no other connectivity requirements in that it doesn't sync anything automatically (except the headers, it does pull those and keep them around, that's 500 bytes / 15 seconds). In essence the light client is designed to consume as little storage and bandwidth as possible. It's not really designed to periodically sync with the network and have data available offline, for that use a full node.

Capacity wise we'll probably make it configurable that it uses as much or as little cache as you configure. It should be able to work with minimal disk space requirements (i.e. kilobytes), but there are always tradeoffs.