[Epic]: State machine needs vs Client needs

[tac0turtle]

Summary

Within the Cosmos SDK users are allowed to build complex data structures in order to better suit the needs of clients. This adds complexity and potentially performance overhead in modules being written.

I believe the reason for this is that our client side tooling is not the best today, while there is transaction indexing built into comet there is no default tool for state streaming to get the data out from a node. We support state streaming but little to no users use it because it doesnt come with a default set of tools outside of the node.

While it is a good thing to add complex data structures in a node, decentralised data providers (RPCs) we should aim to provide users with a set of tools to build complex clients outside the node binary.

If you're reading this issue and have ideas on how to better the client side support please leave a comment

Problem Definition

Users and default modules in the Cosmos SDK provide external clients with many ways to query data at the cost of computation and complexity of data stored on disk.

Work Breakdown

This is meant to be a long lived issue in order to accumulate different needs for users to build offchain complex clients.

• Default postgres ingester for state streaming and events
• Collections schema support

[tac0turtle]

closing in favour of #20352