Add canonical identifier to Cosmos ChainNodes

[jnaviask]

Description

Currently our ChainNodes have no means of being canonically identified, i.e. if referenced from an external source or from the chain itself. We want to use the chain moniker as the canonical mode of identification for Cosmos ChainNodes.

Engineering Requirements

• Migration that adds a moniker column to ChainNodes and populates existing Cosmos nodes
• Update to CreateCommunity tab for Cosmos (and corresponding create routes) that takes + validates the chain's moniker.

Additional context

The alternative approach was to use the chain id, such as osmosis-5, but this chain id is not guaranteed to be persistent, as it changes with on-chain upgrades. So we determined the moniker was the better solution for uniquely identifying cosmos chains.

[mhagel]

We want to use the chain moniker as the canonical mode of identification for Cosmos ChainNodes.

I have learned a bit more about the identifier I was calling "moniker." Each node has its own moniker, but it is an identifier for a specific RPC-providing node, not a chain.

So this would make sense if we kept true to the "ChainNodes" table name. However, that is not the spirit of this ticket.

Therefore I suggest we use the "chain_name" in cosmos.directory as our identifier. It is the primary key for that registry, so it makes sense for our purposes as well. There are also some downstream benefits: we can use this to open up queries to the cosmos.directory API for things like bip32, or ay other useful chain info: For example: https://proxy.atomscan.com/directory/injective/chain.json

---

@jnaviask

Thinking about this brings up some questions:

• Why aren't we putting this unique chain identifier in the "Chains" table instead?
• Will we ever want to have many ChainNodes for a Chain? It would make sense if we need to improve uptime in the future, and automatically cycle to a secondary ChainNode in the event of one node experiencing downtime.
  • Considering this, should we hold off on a UNIQUE constraint in ChainNodes (unless we actually use node moniker)?

cc @ianrowan @timolegros @CowMuon

[ianrowan]

To answer the last part the main reason for having a canonical name in the chainNodes table is to allow a feature/future features like requirements to only need knowledge of global naming(outside of the CW naming domain) to build a requirement.

In practice for requirements, we only need a chainNode to fulfill a token balance check. Therefore the requirement object holds the global canonical name(for cosmos) or id(for eth). The module then only needs to make a check to chainNodes as its provider/node directory/source.

On the flip side if chainNodes do not have a id that is globally agreed upon requirements will have a hard requirement of having access to the Chain table and wont be able to decouple from CW data as easily as it could it if only needs to speak the global language to get a chainNode

@mhagel

[timolegros]

I have learned a bit more about the identifier I was calling "moniker." Each node has its own moniker, but it is an identifier for a specific RPC-providing node, not a chain.

Curious as to where/how you discovered this @mhagel. There is a literal 'moniker' property (named exactly that, not referenced as such). Is that what you are referencing or are you referencing something else as a moniker?

[mhagel]

@timolegros

I am referring to what you can find for "moniker" in https://rpc-juno.architectnodes.com/net_info? for example. Have you found a chain-level moniker?

[mhagel]

Instead of moniker, current PR adds the column cosmos_chain_id to ChainNodes, to follow convention from eth_chain_id.

cosmos_chain_id is expected to be equivalent to chain_name from chain.json for a chain in Cosmos Chain Registry.

It is an alphanumeric lowercase string.

This is documented in a comment.

[mhagel]

Bookmarking alternate API if needed: https://api.cros-nest.com/chain