ICS02: Tendermint light client integration for verification

[mossid]

Validity predicate under ICS02 should handle consensus state updating for tendermint headers. The implementation will have the following type:

type ConsensusState interface {
...
  Validate(Header) (ConsensusState, error)
...
}

Validate must be a pure function which takes a new header and returns the updated consensus state(which is defined as (AppHash, NextValidatorSet) in case of Tendermint).

The current implementation of Tendermint lightclient in IBC module is a simple ValidatorSet.VerifyFutureCommit which accepts a header produced later than the current one and have more than 2/3 vote from the current validator set. It has to be integrated with the Tendermint side lightclient progress.

[fedekunze]

@cwgoes @melekes @tessr @marbar3778 Can you point me to the right function that needs to be used from the new lite2 implementation?

EDIT:

https://github.com/tendermint/tendermint/blob/a3a09285de7cc16a2acb77085421ae10ddac65b7/lite2/verifier.go#L28-L79

[fedekunze]

@cwgoes @AdityaSripal @mossid @zaki which values should we use for trustingPeriod and trustLevel?

Verify(
	chainID string,
	h1 *types.SignedHeader,
	h1NextVals *types.ValidatorSet,
	h2 *types.SignedHeader,
	h2Vals *types.ValidatorSet,
	trustingPeriod time.Duration,
	now time.Time,
	trustLevel tmmath.Fraction)

[melekes]

trustLevel = 1/3 (https://godoc.org/github.com/tendermint/tendermint/lite2#pkg-variables)
trustingPeriod = 2/3 * unbondingPeriod (https://godoc.org/github.com/tendermint/tendermint/lite2#TrustOptions)

[cwgoes]

Hmm, I think they should be parameters that the user can choose when they create the client.

[fedekunze]

We can add them as params to the IBC client keeper and set the defaults to those values

[jackzampolin]

I think this issue has been closed by the wonderful ICS02 impl by @fedekunze