[client] light client implementation

[rgeraldes]

• If the header was signed by over two-thirds of the static VS, the client can be certain that it is a valid block that has been included in the chain.

• With a dynamic validator set, a client has to keep track of the changes to the validator set. For this reason, any time there is a change in that set, the client has to download a new header, verify the validator set change is valid, and update the local validator set.

• The Tendermint Proof-of-Stake algorithm introduces a four week unbonding period in order to avoid long-range nothing-at-stake attacks. This means that as long as the last trusted header was more recent than the unbonding period, a client is secure.

• If the validator set did change considerably in the time a client was offline, it still does not have to download all headers. Instead, it can find a path of intermediate headers. The requirement for this path for any two consecutive headers is that the validator set changes by less than one-third.

  https://blog.cosmos.network/light-clients-in-tendermint-consensus-1237cfbda104

[JekaMas]

@rgeraldes Do we want stateless client in future steps - https://ethresear.ch/t/the-stateless-client-concept/172 ?

[rgeraldes]

It's your turn to research :) We should add everything that is an improvement but we need to take into account that we need to have a stable product in a couple of months and we need to delay some improvements such as sharding.

[rgeraldes]

Here's a good start - https://blog.cosmos.network/light-clients-in-tendermint-consensus-1237cfbda104

[rgeraldes]

Closing this one for now. We'll get back to it if necessary.

[JekaMas]

@rgeraldes nice! Will fix last 2 issues and get this one.