Repository navigation
Consider preparing native optimint arguments in cosmos-sdk #15
Description
Currently arguments passed from cosmos-sdk to Optimint use cosmos/tendermint types. @liamsi pointed that it may be reasonable to create Optimint-native arguments (libp2p types, etc) directly in cosmos-sdk.
- Passing cosmos-sdk/tendermint types
- Pros
- cleaner code in Optimint
- no need to "translate" types, avoid overhead
- we need to change cosmos-sdk anyways
- Cons
- need more changes in cosmos-sdk
- Pros
- Passing Optimint/libp2p types
- Pros
- very few changes to cosmos-sdk, easy scaffolding
- Cons
- type "translation" required
- mixing concerns in Optimint
- extra overhead
- no clear "adapter" pattern (in current code)
- type "translation" required
- Pros
Metadata
Metadata
Assignees
Labels
No labels
Activity
tzdybal commentedon Mar 1, 2021
For some arguments, it's better to generate them directly in cosmos-sdk.
But for example for configuration, I think it's better to reuse existing one and translate/convert it to Optimint's native type.
For now, I'll move forward with such approach: I'll keep "native" types in Optimint method signature, and provide methods for type conversion.