Minimal Multi-Network MetaMask Using Plugins

[danfinlay]

MetaMask has been tied to a multi-network single-transaction controller architecture for a long time, and there has been a long running initiative to get us to a place where we can support multiple networks for a long time.

What exactly this will look like has been unclear, but given the context of the plugin system, I would like to suggest a new and simple path:

Ethereum by Default, Test Networks as Plugins

1. We make MetaMask Controller into a one-network thing.
2. We bundle the network controller and the transaction controller into a shared plugin we call an "Ethereum network plugin", which can have multiple instances with different chain IDs, providers, and block explorers.
3. These test networks would render their assets alongside other "main net" assets.
4. This immediately allows connecting to a test-net via plugin, but using an app key instead of the same account per site.
5. We add a new permission: Permission to provide connection to [Network with Chain ID X](Replace with network name if known). This permission will forward approved transactions to this plugin for transmission to the blockchain, and will forward other RPC calls with that chain_id to that plugin.
6. At this point, current dapps can simply add a chain_id parameter to any call and interact with any installed EVM chain.
7. We can then remove the network menu?

[iquidus]

Overall this direction makes a lot of sense, and will more so moving forward. (Most users are only interested in mainnet), and of course I'm in favor of anything adding better/easier/smoother alternative EVM network support.

Could you elaborate further from a UX perspective?

common scenarios:

• mainstream ethereum user (nothing needs explaining, ethereum by default).
• developers, commonly switching between mainnet(s) and testnet(s).
• mainstream multi-evm users, commonly switching between mainnets. (same as above except can not assume technical experience/understanding).

My initial thoughts on things to consider/keep in mind (just so they're noted):

networkId != chainId: networkId and chainId need to be handled properly, this is often neglected due to them matching on eth mainnet, however they are separate values that serve separate purposes.

eth_contract_metadata: Do you have any thoughts on how to handle this on a per network basis? Ideally this should be separate for each chain (maintained by the plugin maintainer(s)).

[danfinlay]

Could you elaborate further from a UX perspective?

common scenarios:

mainstream ethereum user (nothing needs explaining, ethereum by default).

Agreed.

developers, commonly switching between mainnet(s) and testnet(s).

Plugins are added at log-in time on a per-dapp and per-account basis.

That plugin can display its assets in the token list alongside the user's other main-net assets (like Ropsten Eth, for example, with non-overlapping names, and assets being marked with the plugin that added them).

Apps wanting to interact with this network could either:

• Use the plugin RPC method, for example ethereum.send('wallet_plugin_ropsten.eth, rpcMessage)`.
• Add a mandatory chainId parameter to the usual eth_* methods to indicate to MetaMask where to route those requests (to that plugin instead of the main-net provider/wallet).

This means dapps that use test-nets would remember their networks, and to the user it would simply be like logging into a different app, and using a different currency for its gas cost.

mainstream multi-evm users, commonly switching between mainnets. (same as above except can not assume technical experience/understanding).

A user interacting with dapps simply logs into them as above. When they want to send an other-evm asset, assuming they had that plugin installed, they could click that asset in their token list, and they would get a screen provided by that plugin for managing that asset. It could resemble the tx history, along with send and deposit of the current screen, or it could be very different, depending on the asset type.

[Bunjin]

Long term, we could even extend this further and support non Ethereum networks in the same way

This alongside #104 would unlock great features for multicrypto snaps