Metamask-extension: Multi-Chain Support

Created on 25 Jul 2017 · 20Comments · Source: MetaMask/metamask-extension

MetaMask wants to support a plurality of chains in the future, but we don't want to just add a huge menu of providers, so how do we want to allow MetaMask usage with other chains?

[ ] Make EIP 155 support optional, may require a chainId method from RPCs.
[ ] Allow web UIs to specify the chain they use, providing an optional custom RPC provider for that chain.

Related to

1476

1555

L10-meta P4-someday T03-discussion

Source

danfinlay

👍1

Most helpful comment

The ETC Cooperative would like to revisit this and get a set of patches merged such that any Ethereum-based network will be able to use MetaMask. The first being ETC of course; but with the aim of having this be trivially configurable.

ETC Cooperative itself will manage this and pay for developer's time. However, before nailing down the plan I'd like to first confirm a few questions:

Are you still open to supporting other Ethereum-based networks?
Has anything has changed in the MetaMask codebase since last year that would make this easier or harder? Is there anything Ethereum-specific that you're currently depending on?
- For example: Ethereum now has a non-null status variable in their transactions, other chains do not or may add this support at a later time.
EIP-155 support can probably be done within a MetaMask config as it's just transaction signing, no? I don't think RPCs need to necessarily report their support of it. Network/RPC support for it should be known at the time of writing the config.
Roughly speaking, what would you expect the total number of weeks/months it would take to implement this change? Obviously only looking for an incredibly rough, non-committal ballpark, I'm just unfamiliar with the codebase.
Does your team know any developers/volunteers that are already familiar with the codebase and would be open to doing this paid work?
- I can source programmers myself but those already familiar with the codebase are obviously preferred.

pyskell on 30 May 2018

👍5

All 20 comments

LINK also needs this: https://www.link-blockchain.org/

ethernomad on 12 Sep 2017

ETC Cooperative itself will manage this and pay for developer's time. However, before nailing down the plan I'd like to first confirm a few questions:

Are you still open to supporting other Ethereum-based networks?
Has anything has changed in the MetaMask codebase since last year that would make this easier or harder? Is there anything Ethereum-specific that you're currently depending on?
- For example: Ethereum now has a non-null status variable in their transactions, other chains do not or may add this support at a later time.
EIP-155 support can probably be done within a MetaMask config as it's just transaction signing, no? I don't think RPCs need to necessarily report their support of it. Network/RPC support for it should be known at the time of writing the config.
Roughly speaking, what would you expect the total number of weeks/months it would take to implement this change? Obviously only looking for an incredibly rough, non-committal ballpark, I'm just unfamiliar with the codebase.
Does your team know any developers/volunteers that are already familiar with the codebase and would be open to doing this paid work?
- I can source programmers myself but those already familiar with the codebase are obviously preferred.

pyskell on 30 May 2018

👍5

ETC being first of course. 🙄

chrisfranko on 30 May 2018

I dont really know why having a menu full of networks is a bad thing.. it already has a menu full of networks, but the second option to make eip155 an optional param for custom rpcs is probably the easiest to implement.

chrisfranko on 30 May 2018

👍1

ETC being first of course. :roll_eyes:

I meant no disrespect to other networks of course and hope to see every Ethereum-based network supported.

If the ETC Cooperative were to commission this of course we'd include ETC in the first pull requests. There's also the practical aspect that we'd want to get everything working correctly/proven in the wild with one network before moving onto others for a few reasons:

It saves on rework if we encounter bugs we didn't see during testing
As the MetaMask team previously mentioned, they want to make sure they trust the node operators. This is something only they can determine. I'd rather not overwhelm them with too many nodes at the start.
ETC is the second largest Ethereum, it would give MetaMask the most added reach/impact.

We'd likely help with later PRs for ELLA and ESN as well since those two cooperate with various ETC-related teams on other projects. Expanse, Ubiq, and all other Ethereums should have a trivially easy time getting their PRs done once all the work is complete.

Anyways, back to implementations:

For the menu I was actually wondering if it can be a two-step selection where you have an overarching menu structure like so (select outer-bullet point, then inner):

Ethereum
- Mainnet
- Testnet 1
- Testnet 2
ETC
- Mainnet
- Testnet 1
Expanse
- Mainnet
- Testnet 1

pyskell on 30 May 2018

👍2

Ok, sorry for getting defensive, id be willing to provide some resources to
get this done, perhaps even give an Expanse Grant to whoever wants to do
it. :) ClassicMask has already done alot of the work already for adding
network ids and stuff. Its really up to the MetaMask guys/ Ive reached out
before wanting to help and though they were very nice and respectful, they
seemed a little apprehensive of the idea. :/ Maybe our teams can get
together and just make a completely new product that is similar.

On 30 May 2018 at 12:07, Anthony notifications@github.com wrote:

ETC being first of course. 🙄

I meant no disrespect to other networks of course and hope to see every
Ethereum-based network supported.

If the ETC Cooperative were to commission this of course we'd include ETC
in the first pull requests. There's also the practical aspect that we'd
want to get everything working correctly/proven in the wild with one
network before moving onto others for a few reasons:

It saves on rework if we encounter bugs we didn't see during testing

As the MetaMask team previously mentioned, they want to make sure
they trust the node operators. This is something only they can determine.

We'd likely help with later PRs for ELLA and ETSC as well since those two
cooperate with various ETC-related teams on other projects. Expanse, Ubiq,
and all other Ethereums should have a trivially easy time getting their PRs
done once all the work is complete.

Anyways, back to implementations:

For the menu I was actually wondering if it can be a two-step selection
where you have an overarching menu structure like so (select outer-bullet
point, then inner):

Ethereum

Mainnet

Testnet 1

Testnet 2

ETC

Mainnet

Testnet 1

Expanse

Mainnet

Testnet 1

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MetaMask/metamask-extension/issues/1820#issuecomment-393219809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADYQsfndfJ7dJzdSgQHR7kBFjcasSX3qks5t3sPBgaJpZM4Oi4yg
.

chrisfranko on 31 May 2018

If you want ETC support, the way forward is the same as described in the parent post. All other proposals hinge on:

Make EIP 155 support optional, may require a chainId method from RPCs.

This would be a simple enough PR to submit, we don't need to debate network menus before this has been added.

danfinlay on 31 May 2018

👍2

@danfinlay Got it. We'll get this change submitted.

pyskell on 1 Jun 2018

👍3

Please see https://github.com/ethereum/go-ethereum/pull/15002#issuecomment-394560172

currently, lookupNetwork() use net_version value and it is the networkID.
MetaMask use this networkID as the chainID.
(https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/controllers/network/network.js#L80)

@turbobit can manage this issue (chainID != networkID cases) by hack/workaround net_version return value. (https://github.com/ethereum/go-ethereum/pull/15002#issuecomment-394560172)

hackmod on 5 Jun 2018

👍2

from https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md

(networkID column added)

NetworkID |CHAIN_ID | Chain(s)
-- | -- | --
1 | 1 | Ethereum mainnet
2 | 2 | Morden (disused)
3 | 3 | Ropsten
4 | 4 | Rinkeby
? | 30 | Rootstock mainnet
? | 31 | Rootstock testnet
? | 42 | Kovan
1 | 61 | Ethereum Classic mainnet
3 | 62 | Ethereum Classic testnet
1 | 2 | Expanse mainnet ([[1]], [[2]], [[3]])
1 | 8 | Ubiq mainnet ([[2]] , [[3]])
60 | 60 | GoChain
76 | 76 | Mix
89 | 89 | Tomo Testnet
99 | 99 | POA Network
37129 | 101 | webchain
1 | 101 | etherinc
164 | 164 | Ellaism
1 | 820 | Callisto mainnet ([[2]] , [[3]])
11235813 | 1620 | Atheios
1987 | 1987 | EtherGem
1 | 31102 | EtherSocial Network
200625 | 200625 | Akaroma
1313114 | 1313114 | Ether-1
7762959 | 7762959 | Musicoin
18289463 | 18289463 | IoLite
3125659152 | 3125659152 | Pirl

[1] https://github.com/expanse-org/go-expanse/blob/master/eth/config.go#L42
[2] https://www.ethernodes.org/network/1/nodes
[3] https://github.com/kvhnuke/etherwallet/blob/mercury/app/scripts/nodes.js

hackmod on 5 Jun 2018

[ ] Make EIP 155 support optional, may require a chainId method from RPCs.

no other web wallets even support EIP155 disabled blockchians.
without optional EIP155 support, Multi-chain support is much simpler than we expected.

hackmod on 7 Aug 2018

See also PR #5552

hackmod on 24 Oct 2018

Refs #5134 as well

whymarrh on 26 Oct 2018

Hey @danfinlay and @kumavis!

I am just trying to figure out where everything is sitting on this.

It looks like abortive attempts were made in 2017 and 2018 to get ETC (and other chains) working with MetaMask which we can maybe complete now without too much pain?

Everything which @pyskell said there in May 2018 remains the case. The ETC Cooperative can drive this, find volunteers or fund developers to make the PRs, etc.

bobsummerwill on 25 Mar 2019

It looks like this change was merged and then unmerged:

https://github.com/MetaMask/metamask-extension/pull/5552

Because of this Infura issue:

https://github.com/MetaMask/metamask-extension/issues/5664

But then @kumavis did this fix:

https://github.com/MetaMask/metamask-extension/pull/5670

But this was never remerged and then everything stalled?

https://github.com/MetaMask/metamask-extension/pull/5552

bobsummerwill on 25 Mar 2019

Anyway - I am happy to jump on this horse and start riding again. I just want to confirm where we are, and that you guys are OK with this work picking up again.

Aside - We are talking to EG at Infura too, about what it might take to get Infura ETC support. That would be easiest of all, but may or may not be possible.

@sorpaas, +@hackmod

bobsummerwill on 25 Mar 2019

👍1

Is there an API proposal for this existing that external devs could start making pull requests against?

E.g. I could imagine a new api overload of request() with a new client only wallet_requestChainId method, so that each DApp can decide which ChainId to operate on.

ethereum
  .request({ method: 'wallet_requestChainId', params: [1] })
  .then((chainId) => {
    console.log(`hexadecimal string: ${chainId}`);
    console.log(`decimal number: ${parseInt(chainId, 16)}`);
  })
  .catch((error) => {
    console.error(`Error requesting chainId: ${error.code}: ${error.message}`);
  });

That could then be resolved using the offical EIP-155 https://chainid.network/chains.json, or the file could also be cached as part of the metamask distribution. Is this along the lines of the initial thinking? Or is there something more concrete/different in the making?

dominicletz on 20 Oct 2020

👍1

Is there an API proposal for this existing that external devs could start making pull requests against?

E.g. I could imagine a new api overload of request() with a new client only wallet_requestChainId method, so that each DApp can decide which ChainId to operate on.
ethereum
  .request({ method: 'wallet_requestChainId', params: [1] })
  .then((chainId) => {
    console.log(`hexadecimal string: ${chainId}`);
    console.log(`decimal number: ${parseInt(chainId, 16)}`);
  })
  .catch((error) => {
    console.error(`Error requesting chainId: ${error.code}: ${error.message}`);
  });
That could then be resolved using the offical EIP-155 https://chainid.network/chains.json, or the file could also be cached as part of the metamask distribution. Is this along the lines of the initial thinking? Or is there something more concrete/different in the making?

I would seriosuly welcome this, I am building a Peering Exchange on mellanox and Intel Tech and anything that can automate Metmask at API level is a real benefit. Especially when handling highly encrypted traffic at 800 gbps plus per 2u. This would allow me to build a central hub for automating all smart contracts based on a more flexible architecture and design.