ICS03: Historical header module for Handshaking

[mossid]

Connection handshaking requires to check the existence of a header of the verifying chain on the verified chain. Opening handshake under ICS03

function connOpenTry(
  desiredIdentifier: Identifier,
  counterpartyConnectionIdentifier: Identifier,
  counterpartyPrefix: CommitmentPrefix,
  counterpartyClientIdentifier: Identifier,
  clientIdentifier: Identifier,
  counterpartyVersions: string[],
  proofInit: CommitmentProof,
  proofHeight: uint64,
  consensusHeight: uint64) {
    ...
    expectedConsensusState = getConsensusState(consensusHeight)
    ...
    abortTransactionUnless(
      connection.verifyMembership(proofHeight, proofInit,
                                  consensusStatePath(counterpartyClientIdentifier),
                                  expectedConsensusState))
    ...
}

This requires the verifying chain able to introspect its own headers. ICS02 module needs to hold the reference to the historical header module and retrieve headers from recent n heights.

Dependent on: #4647
Replaces [^2] in #4723

[fedekunze]

I'm not sure what are the actionable items here. cc: @cwgoes

[cwgoes]

We need internal header introspection in SDK state (or retrieved from Tendermint).

[fedekunze]

We need internal header introspection in SDK state (or retrieved from Tendermint).

I assume the introspection is related to retrieving past light client headers?

[cwgoes]

Past Tendermint headers (which the light client uses, yes) for the running chain.

[fedekunze]

ok, yeah this def needs an ADR. cc: @mossid @jackzampolin

[jackzampolin]

@mossid do you have some bandwidth to write up this ADR?

[cwgoes]

There is no way for the application to retrieve past headers from Tendermint through ABCI, right?

I am writing an ADR for the SDK right now and thinking that it might be easiest to just store duplicate data in the store (for the past n heights - validator set and commit hash, basically, the same data the light client keeps), but if there is some way for the application to query this from Tendermint (which stores it I presume) that would be more space-efficient