02-client: Allow verification methods to verify parachains

[AdityaSripal]

Ref: #284

The Polkadot architecture allows a single beefy client to verify all para chains.

Currently in IBC, we have a single client for a single chain. We should determine how deeply this assumption is baked into the code, to see if we could easily change it.

1. If it is trivially changable, then we may decide to modify the ClientState interfaces to enable a client to represent multiple chain.
2. If it is not trivially changable, then I believe we can still get efficient clients. We can create two client implementations. One of which is the relay chain.

// Relay Chain ClientState
ClientState{
    ...
}

// Para Chain ClientState
ClientState{
    chainID string, // identifier for this individual parent chain
    relayClient *ClientState,
}

Here the RelayChain ClientState is going to be updated with the headers of the relay chain and can use the ClientState to verify the relay chain.

The ParaChain ClientState is just a thin wrapper around the RelayChain ClientState. Here it can No-Op or error on any UpdateClient. All verify functions will pass through to the underlying RelayChain ClientState and we can verify with the embedded chainID.

This second approach seems to me to get what we would want in terms of efficiency without major changes to the interfaces. Does this approach seem viable? cc: @colin-axner @seunlanlege @jackzampolin

[seunlanlege]

should be "para"-chains

[notbdu]

On an abstract level, looks like we're specifying client state dependencies here.

Could we also consider the case of rollups as well (and recursive rollups)?

For example, I think we'd need to be able to access finalized state roots of the parent chain to determine inclusion/finality?

Without digging into L2 specifics, I think we'd roughly need to associate child commitment path -> child commitment root -> parent commitment path -> parent commitment root for as many layers/levels as we need to.

[crodriguezvega]

@AdityaSripal is this issue still relevant? Is there anything from here that we should take into account for the work on conditional clients?

[AdityaSripal]

It's unclear to me if the RelayChain is only needed in UpdateClient, or also in the verifyMembership function. It's worth asking composable.

If VerifyMembership is also needed, we should ensure that we allow the querier calls for all client methods in our design, not just UpdateClient

[crodriguezvega]

@AdityaSripal I asked Composable and they said that they don't reference the state of the relay chain in VerifyMembership, so looks like it will not be needed. I will therefore close the issue for now, but we can reopen in the future if needed.