Msg, Querier & Client Introspection

[okwme]

Summary

In order for a third party app to interact with an Ethereum smart contract they need to know the Application Binary Interface (ABI) of the contract. This reveals all the functions, events and types within the contract. With the ABI and the deployed contract it is possible for anyone to communicate with the contract.

On an sdk-chain the more important information is Queriers, Msgs and the various client endpoints made available associated with those Msgs and Queriers. Some of these endpoints are used for generating and/or signing Msgs or reading data from the state via Queriers.

In order for a third party to interact with the chain they would need this information. This could be possible through a swagger file, like a standin for the ABI. Since we are building blockchains and we can add cool features I wanted to bring up the possibility of a default endpoint for cosmos chains that will return a swagger file or similar configuratoin informatoin that would reveal to a third party all the possible queriers, msgs and endpoints available for interacting with that specific blockchain.

Problem Definition

This would make it really easy for developers to test features of a chain via a scaffolded GUI which could build out forms based on the information contained within the configuration file. A similar feature is available with substrate here: https://polkadot.js.org/apps/#/explorer by changing the node under settings.

Proposal

Spike what would go into adding such a feature to see whether the work would be worthwhile

---

For Admin Use

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

[rigelrozanski]

Trying to grasp this idea. If I understand the idea correctly - we want the capability to export properties of what your blockchain is capable of (and what the requirements are for a GUI) and in addition have some form of automated GUI scaffolding which is able to interpret this information and build out a functional interface (which then could be further customized obv.)

What's the purpose of this feature do you think? To serve as a nice starting point for new blockchain projects to quickly get something out, ease the GUI dev. process?

default endpoint for cosmos chains that will return a swagger file or similar configuratoin informatoin that would reveal to a third party all the possible queriers, msgs and endpoints available for interacting with that specific blockchain

Would adding this to the CLI suffice? why do we need this as a REST endpoint? it sounds like this would only ever be run as a custom single action prior to building out a test GUI for a custom blockchain project built on the sdk.

---

p.s. we should add a more descriptive title to this issue

[jackzampolin]

I think a first step here would be to generate js libs for interacting with module's store in Javascript. Then we could build components on top of it. I would be a fan of that.

[okwme]

@rigelrozanski I think being able to export the capabilities is all that should be considered as part of the SDK issue. It would enable the client work to be done by the ecosystem or as part of the client libs work that will beginning soon. Just thinking that it seems like it would not be a large task-especially with your new module manager-to export that kind of info. Then it would make it much easier to build flexible front ends that can communicate with multiple chains. This would be useful for developing process but also for wallets who want to be able to easily support many chains in a potentially permission-less fashion.

I think a first step would be to add this as a CLI endpoint to the module manager (?) because it will have info about all the modules being used in a chain. This is useful but doesn't really achieve what i think is the real value of this proposal, because someone with CLI access to a chain already knows quite a bit about it or at least has access to that info by other means. An RPC endpoint is more for someone encountering a chain for the first time or for scaffolding software (which is essentially encountering the chain for the first time).

Again I presuppose all of this that I'm assuming it wouldn't be that hard to export a summary configuration of a chain. We should also try to walk through a user story of someone encountering a chain for the first time. There is the Wallet scenario that I could imagine something like:

• I'm a user with a cosmos wallet and I've been using trustory for a little while
• Trustory only has a webapp and i'm curious as to my account balance while on my phone
• I open my wallet and tell it to add a new app-chain, I know that trustory has a public RPC endpoint at rpc.trustory.io
• I add rpc.trustory.io and a new page is added to my wallet with all of the data and functions available via RPC on that chain.
• The wallet builds forms for each of the functions that i may want to access directly. On a simple scale this could be a transfer of my tokens, on a more complicated level (and depending on how the app is architectured) it might show the different msg types that have other functions.
• This is how etherscan.io works with verified contracts and is really useful for confirming a contract is doing what it says it is doing
• This is also the fundamental difference between a blockchain app and a normal app-their public API is always accessible and transparent

Another user story might be the developer:

• Trying out cosmos-sdk, building the nameservice app
• Running the node an opening a demo-app that points to my local node
• The demo app can tell what endpoints are available and builds a form for each one
• The developer can run some test transactions and tell that the state updates as expected

@jackzampolin totally agree this whole thing should be informed by the js libs. This is absolutely a feature for front end users.

[jackzampolin]

cc @jordansexton

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tac0turtle]

@aaronc is this possible with gRPC?

[aaronc]

Yes, the .proto files cover all Msg and querier types. So I would consider this done and am marking as closed. It would be nice to also support introspection around a few other things like interface implementations and the store layout, but that's all being tracked elsewhere.

[okwme]

Thanks @aaronc! What do you think about adding a new endpoint that serves up those protofiles? Then a developer / app just needs to know a node’s IP to scaffold up interactions.

[aaronc]

This probably covers most stuff @okwme: https://github.com/grpc/grpc/blob/master/src/proto/grpc/reflection/v1alpha/reflection.proto. But we also want to add an endpoint that lists all interface implementations (such as Msg's) and their corresponding .proto files.

[okwme]

Oh nice! This is already becoming possible 😍

[aaronc]

gRPC reflection probably won't be possible until #6463 is done. A reflection API that covers interfaces is actually pretty easy. Maybe I'll make a quick PR now.

[tac0turtle]

gRPC reflection probably won't be possible until #6463 is done. A reflection API that covers interfaces is actually pretty easy. Maybe I'll make a quick PR now.

Hey, @aaronc did this get merged?