Cosmos-sdk: Allow Client State modifications via VerifyXYZ functions

[colin-axner]

Summary

Verification functions need to be able modify ClientState in order to things like replay protection in the case of 06 solo machine

Problem Definition

Currently the ClientState interfaces only return an error so any modification to ClientState won't be persisted outside of the Verify function.

Proposal

VerifyXYZ functions should have the return signature (ClientState, error) and the verify functions in /03-connection/keeper/verify.go should call SetClientState before returning the error.

Should SetClientState still be called if the error retrieved is not nil. This would just be for debugging purposes, what would be more useful?

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[AdityaSripal]

I undrestand why this is necessary. Because we need to update the clientstate of solo machine after each successful signature verification to modify the sequence.

But it feels wrong from an interface level, to have the verify functions be stateful.

I wonder if there's a way to prevent a replay of the verify function for solo machines without making the verify interfaces stateful. @cwgoes

[cwgoes]

I wonder if there's a way to prevent a replay of the verify function for solo machines without making the verify interfaces stateful. @cwgoes

Hmm, not that I can think of that doesn't require a lot of additional functions (it would be possible to separate the verify functions into state changes & verifications which are stateless, but this would double the number of functions).

We can change the names to reflect the statefulness though, maybe "verifyXYZAndUpdateState" or "statefulVerifyXYZ"?

[fedekunze]

We can change the names to reflect the statefulness though, maybe "verifyXYZAndUpdateState" or "statefulVerifyXYZ"?

I don't think we need to rename functions as long as we document that client states can be stateful.

[colin-axner]

closed via #6202