Chain name aliases

[schmidsi]

Do you want to request a feature or report a bug? feature

What is the current behavior? Every chain has a unique network identifier, like mainnet, matic, xdai. Some of these chains were renamed but their unique identifier stayed the same. Eventually, new developers will be confused because they do not intuitively understand why a subgraph running on Polygon should have matic as network identifier. Same for xDai which was renamed to Gnosis Chain.

Though, just changing these network identifiers would break all existing subgraphs that still have matic as network and not polygon.

What is the expected behavior?

I would recommend to introduce network identifier aliases, so we can start to communicate the new names but still support the old ones.

Example:

matic -> polygon xdai -> gnosis-chain

Etc.

[azf20]

This makes sense, though perhaps the underlying problem is that graph-node isn't using the canonical chain identifiers (chainID for EVM chains) which are unchanged. That will always be a painful migration, but perhaps this aliasing is also a good first step in that direction. Presumably this could just be part of the advanced graph-node config:

networkAliases = [
{ alias = "matic", network = "polygon" }
{ alias = "xdai", network = "gnosis-chain" }
]

That would then give us future leeway to move to more robust (but less human readable) identifiers Interested in your thoughts @lutter

[lutter]

If we do this in the config file, I would just make that another property for the provider, something like

[chains.matic]
shard = "blocks_b"
provider = [ .. ]
aliases = ["polygon"]

[azf20]

Thanks @lutter that makes sense to me.

There are two general concerns here:

• Supporting aliases (due to chain renames, supporting human readable settings etc.)
• Establishment of canonical naming on the network

David's suggestion meets the first need. I think the second is outside the remit of Graph Node, which isn't network aware. I propose that new chain names should be added to networks.md, with an aliases column for other accepted names. This may require all indexers to use more advanced graph node configuration, @fordN are most indexers doing so already, or are some using CLI args?

[azf20]

Adding a GIP on this improvement, as it is relevant to the network https://forum.thegraph.com/t/chain-identification-aliasing-for-the-graph-protocol/3514

[azf20]

Considerations:

• defaults in graph node?
• places where the network name is stored (database tables, names)
• one to many, not one to one

[neysofu]

As I'm working my way through the changes necessary to get aliasing of of the door, I'll try to summarize the most important changes in this comment. The ticks as in "done" are approximations. I may be missing something, in that case I'll update this comment and/or the future PR description.

• [x] Establish a list of predefined chain name aliases. This list will associate all currently supported chain names with their respective CAIP2s, as well as mainnet -> ethereum and xdai -> gnosis.
• [x] Furthermore, custom chain aliases can be defined with this syntax:

[chains.matic]
shard = "blocks_b"
provider = [ "..." ]
aliases = ["polygon"]

• [x] Create a data structure that lets you easily query for the original alias of a chain name. By "original" or "canonical" alias, we mean the chain name used in the graph-node-config.toml.
• [x] Expand BlockchainMap with this data structure.
• [x] Extract the name column from the chains and ethereum_networks table into a chain_identifiers or chain_aliases table.
• [ ] Fix all SQL queries store::block_store::primary, which reference chains by name.
• [ ] Apply similar modifications to Storage and ChainStore in chain_store.rs, and other places where chains are referenced/queried by name.
• [ ] Go through all index node endpoints and make sure, for each of them, that we correctly reference chain names in the responses. Correctly means:
  1. If the chain name was explicit in the request, then reuse that alias in the response as well.
  2. Otherwise, use the canonical alias.
• [x] Address determinism issues that arise from dataSource.network(): this host call should always return the canonical alias, which will be the same for all indexers.
• [ ] graphman will follow similar rules to the index node server: whenever the user inputs a chain alias which will also be present in the output, we should use such alias. Otherwise, in other situations which require us to choose an alias ourselves, we will default to the canonical alias. This is not awesome (it means graphman will keep outputting deprecated chain names like xdai in a variety of scenarios), but it seems like a decent solution for the time being.
• [x] A few integration tests. 😬