Dashboard shows odd network name when connecting with Ganache

[benjamincburns]

Issue

When I connect the dashboard to Ganache via Metamask, it tells me that I've connected to a network called "CENNZNET OLD."

Steps to Reproduce

1. Start truffle dashboard
2. Configure MetaMask to point at localhost:8545
3. Observe network name shown in dashboard

Expected Behavior

Network name should ideally be resolved in the following order (with each step falling back to the next):

1. User's truffle-config.js
2. Metamask's name for the network
3. https://chainid.network/chains.json (but pulled from the Truffle relay so we can unbreak old versions if that disappears/moves)

Actual Results

Environment

• Truffle version (truffle version): v5.5.9

[haltman-at]

Note that the reason this is happening at present is due to the prioritization of (3) over the others (together with the use of chain ID 1337).

[cliffoo]

Some updates on this issue as I work through pull#5241.

In fear of potential supply chain attack (no hard feelings to lists.eth or defillama), I'd like the new Dashboard to minimize all network requests that are not strictly related to processing Dashboard messages.

So chainid.network/chains.json appears to come from ethereum-lists/chains, and since:

• For a given chain, we only need its id and name for now.
• I'd like this id-to-name mapping to go into version control (like how we update sourcify fetcher).

I made a little script to parse the chain data in ethereum-lists/chains, which outputs a json small enough that I want to bundle it into the Dashboard frontend, and use like

import chainIDtoNameJson from "src/assets/chainIDtoName.json";
function getChainNameByID(id) {
  return chainIDtoName[id];
}
getChainNameByID(1337) // => "Ganache"

This, on top of my discovery that MetaMask doesn't seem to provide network names, I think the expected behavior can be modified as such:
Resolve chain name by:

1. truffle-config.js
2. chainIDtoName.json in packages/dashboard/src/assets

Note: Here's why 1337 resolves to "Ganache".

[gnidan]

ah @cliffoo you found a familiar problem! thanks for the write up on the specifics here!

@haltman-at @davidmurdoch how does @cliffoo's concern above fit into the prior work done on suite-wide network housekeeping? Is __experimentalInfo fit for this purpose? (and obligatory comment about can we get it a proper name :). thanks!

[davidmurdoch]

I don't think it's fit for that purpose, since Truffle/Dashboard might not have access to the provider. 1337 has been the id for devnets (i think it was geth that first used it) since chains had chain ids. Ganache does identify itself via web3_clientVersion RPC though.

[benjamincburns]

Open question (no bias from me toward yes/no here) - if we're considering bundling the network list in with the dashboard that will mean that old versions will never "discover" new network configurations. Do we care about that? If so, perhaps we could make that JSON object something that could be fetched periodically?