Add common getter and setter to message types

[mmsqe]

Summary

support generic unmarshal and exec msg server methods

Problem Definition

Currently it's hard to handle different message types with a generic approach. Since common methods to access attributes like Signer, ClientState, ConsensusState are missing, we can only manipulate with that message concrete type.

Proposal

Add common exported methods to all message types to get attributes including Signer, ClientState, ConsensusState and Misbehaviour, also methods to set those except Signer. With these methods, it allows us to define common Interface and thus generics when handling these message types.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[colin-axner]

Thanks for opening up the issue @mmsqe. A couple initial questions that come to mind:

1. In what context are you unmarshaling messages? (via smart contracts, or off chain, or sdk module?)
2. I see the SDK will be adding proto annotations to indicate the Signer of a msg, would this be sufficient for getting the signer. Why can't GetSigners be used currently?
3. What generic handling are you trying to perform? Why do you need access to the client or consensus state in a generic manner?

[mmsqe]

Thanks for opening up the issue @mmsqe. A couple initial questions that come to mind:

@colin-axner Follow you questions:

1. sdk module
2. I change to use sdk's GetSigners with single signer, which is the current case.
3. generic handling is allow msg server call msg directly in precompile, which accept the protobuf encoded message as input, pass that directly to native handlers.

[damiannolan]

Hey @mmsqe, I'm having trouble understanding the precompile ethermint/evm code snippet you've provided and what problem it is trying to solve. Is there an issue in ethermint which states the problem?

From what I can tell the code is relying on a large switch statement which checks some byte prefix for specific cases(?) - this doesn't seem to lend itself well to a generic msg handling pattern.

[crodriguezvega]

@mmsqe Is this issue still relevant? If yes, can you provide us more information so that we can understand better the problem? (see Damian's question above)

[mmsqe]

@damiannolan @crodriguezvega sorry for the late reply, we come up with a generic way to handle, we could close this now.