Light clients

Let’s talk about light clients. Before we launch, we need at the very least a compelling story for light clients. Ideally, we have it all figured out and implemented. Certain functionalities of light clients may only be possible with protocol changes, making it harder to tack on after the fact.

There are also various ‘levels’ of light clients we could support:
- Fully trusted other node
- Simply select another node that you trust fully, and use it for getting the latest chain state. Trust that it has correctly validated blocks, to avoid having to check signatures and chain validity.
- Header-only chain validation
- Perform chain sync as usual, but do not validate state changes. Just Validate that the miner of each block was the correct miner, and that they correctly submit their proofs.
- Checking the proofs gives reasonable certainty, Similar to how bitcoin light clients validate the (unforgeable) proof of work (very cheaply)
- Validate from checkpoint
- Select a block that you trust, and validate the chain fully moving forward from that block. Periodically drop old chain state from your node as you update your checkpoint.
- Note: this mode may be the future of *all* filecoin ‘full nodes’

Once you trust a specific block, you can trust the state tree contained within it. Then things like looking up a balance become just requesting a merkleproof of the account within the state tree.

Things to think about for making light clients efficient:
- Given a trusted state tree root, how much data has to be fetched to:
- look up asks/bids
- validate a PoSt
- check an account balance
- check if a miner needs to be slashed
- validate a state channel
- What is the best trust vs compute/bandwidth trade off we can make? What are our options?
- Can we use our magic snark wand?

The issue names no files, tests, or entry points to begin with. Start by reviewing the three proposed light-client trust levels and the listed balance, asks/bids, PoSt, slashing, and state-channel questions; the work is not complete until a specific scope, trust-versus-compute trade-off, and any required protocol changes are established.

Written by the indexing model from the issue text.