ICS 2.a: IBC minimum viable Tendermint lite client

[cwgoes]

Will cover:

• Algorithm & data structures for minimum correct (probably not optimal) IBC lite client
• Encoding specification for proofs

[cwgoes]

Maybe we don't need this; it seems like #25 will define the requirements of lite-client verification.

Alternatively, this could be a protocol specification for a safe PBFT-class (e.g. Tendermint) lite client.

[ebuchman]

Not sure, but might be valuable to differentiate the full and lite node abstractions. That said the full node abstraction isn't really relevant to IBC, so it probably makes sense to specify the Tendermint-level lite client requirements as part of ICS-2 as well. This would need to capture everything we've talked about re dynamic validator sets, bisection, counterfactual slashing, etc, which could become quite a bit, and might make sense to split it up (eg. ICS-2a is the core for static-validator sets, ICS-2b supports dynamic validator sets with < 1/3 change over epoch, and ICS-2c supports arbitrary dynamic validator sets) ?

[cwgoes]

Splitting up ICS-2 sounds prudent, and would be useful for IBC implementations by simpler networks (which might not need techniques such as counterfactual slashing).

I think we should include the requisite consensus properties (~ full node abstractions) to make definitive statements about precisely which Byzantine behaviors by which fractions of validators could break the high-level guarantees provided by IBC, but probably not more than that.

[cwgoes]

This will become a sub-standard of ICS 2.

[cwgoes]

Blocked on Tendermint spec work at present.

[cwgoes]

The main specification will live in the Tendermint repository, I think.

Perhaps there ought to be a "bridge specification" in this repository as well (how to hook up the functions exposed by the Tendermint light client to the interface required by ICS 2).

[cwgoes]

The "bridge spec" is ICS 7 - #332.