[DRAFT] Client update incentivization

[notbdu]

Client updates are not currently incentivized within ICS-29.

This PR extends the ICS-29 spec with additional logic to escrow and pay out rewards for posting client updates. ICS-29 is extended instead of a creating a separate app spec because relayer registration is required for incentivized client updates as well.

[jackzampolin]

at a high level i'm super in support of this idea, however I think its prob best as its own spec. If we add this to the relayer incentives its overloading that module IMO.

[notbdu]

at a high level i'm super in support of this idea, however I think its prob best as its own spec. If we add this to the relayer incentives its overloading that module IMO.

Agree on this ideally being a separate spec. The tradeoff I was seeing was that I needed to re-create the relayer registration patterns which are already a part of the ICS-29 spec.

[AdityaSripal]

Agreed with @jackzampolin that this should be pulled out into its own spec.

In general, I don't see how this can't be DOSed by relayers. If there's a generic incentivization for submitting headers, I'm just going to submit every header even if its not necessary.

This is why I'm generally more in favor of packet incentivization. Even though the relayer submitting the client update may be different than packet relayer.

Ultimately the utility of IBC is cashed out in packet submission.

If the consensus state already exists before an incentivized packet, then thats good. For whatever reason, the relayer who submitted it found it useful to do so without incentivization.

Packet incentive should be high enough to pay for the cost of a client update and packet message imo. So it implicitly also incentivizes the client update that is necessary.

This changes a bit in the multihop case; but maybe we can do something else with packet incentivization to help here.

More in favor if we can find a non-gamable way to incentivize client updates