Multi-Chain Support #1820

danfinlay · 2017-07-25T17:40:36Z

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

ethernomad · 2017-09-12T08:01:18Z

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

pyskell · 2018-05-30T15:23:40Z

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.

chrisfranko · 2018-05-30T15:46:24Z

ETC being first of course. 🙄

chrisfranko · 2018-05-30T15:48:00Z

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.

pyskell · 2018-05-30T16:07:19Z

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. 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

chrisfranko · 2018-05-31T18:07:59Z

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 ***@***.***> 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 <#1820 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADYQsfndfJ7dJzdSgQHR7kBFjcasSX3qks5t3sPBgaJpZM4Oi4yg> .

danfinlay · 2018-05-31T20:42:46Z

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.

pyskell · 2018-06-01T13:18:28Z

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

hackmod · 2018-06-05T02:52:39Z

Please see ethereum/go-ethereum#15002 (comment)

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. (ethereum/go-ethereum#15002 (comment))

hackmod · 2018-06-05T03:52:46Z

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 · 2018-08-07T05:13:00Z

[ ] 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 · 2018-09-10T01:19:57Z

See also PR #5552

whymarrh · 2018-10-26T09:22:24Z

Refs #5134 as well

bobsummerwill · 2019-03-25T19:55:47Z

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 · 2019-03-25T19:58:26Z

It looks like this change was merged and then unmerged:

#5552

Because of this Infura issue:

#5664

But then @kumavis did this fix:

#5670

But this was never remerged and then everything stalled?

#5552

bobsummerwill · 2019-03-25T20:00:17Z

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

dominicletz · 2020-10-20T14:34:07Z

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?

jimthedj65 · 2020-10-27T10:45:20Z

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.

brad-decker · 2021-03-04T23:31:36Z

I think, with the addition of wallet_addEthereumChain we can safely close this. Supporting multiple chains is, at the very least, part of our ongoing philosophy at MetaMask.

danfinlay · 2021-03-04T23:32:47Z

Thank you for that Brad, we shall close!

Anyone who's been waiting for this can read the EIP 3086 here or read the docs here.

bobsummerwill · 2021-03-04T23:49:09Z

Hurrah :-)

Thank you, MetaMask crew!

chrisfranko · 2021-03-05T16:50:52Z

Four years and some change in the making. Im glad to see the air around "forks" clear up.

danfinlay added type-discussion epic labels Jul 25, 2017

2-am-zzz added the P4-someday label Jul 25, 2017

This was referenced Jul 26, 2017

Ethereum Classic Support #1476

Closed

Adding expanse network #1555

Closed

hackmod mentioned this issue Jun 5, 2018

support optional chainId #4516

Closed

11 tasks

ghost mentioned this issue Jul 17, 2018

Add Multi-Chain Support #4816

Closed

hackmod mentioned this issue Aug 1, 2018

Initial multi-chain support (aka. optional chainid fix) #4932

Closed

8 tasks

danjm mentioned this issue Nov 5, 2018

network - infura - hardcode net_version and eth_chainId #5670

Merged

bdresser mentioned this issue Nov 5, 2018

how to create a BTC address with keyring in metamask? #5667

Closed

hackmod mentioned this issue Jan 15, 2019

Add Webchain chain id ethereum/EIPs#1694

Closed

pavelkrolevets mentioned this issue Sep 15, 2020

Transiction send error "invalid sender" when sending over private Ethereum network MetaMask/metamask-mobile#1832

Closed

dominicletz mentioned this issue Oct 27, 2020

Chain Agnostic Provider Handshake ChainAgnostic/CAIPs#25

Merged

Gudahtt removed the P4-someday label Jan 19, 2021

danfinlay closed this as completed Mar 4, 2021

massa-bot mentioned this issue Nov 11, 2021

Explore what needs to be done to expose ETH RPC massalabs/massa#1058

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multi-Chain Support #1820

Multi-Chain Support #1820

danfinlay commented Jul 25, 2017

ethernomad commented Sep 12, 2017

pyskell commented May 30, 2018

chrisfranko commented May 30, 2018

chrisfranko commented May 30, 2018

pyskell commented May 30, 2018 •

edited

Loading

chrisfranko commented May 31, 2018 via email

danfinlay commented May 31, 2018

pyskell commented Jun 1, 2018

hackmod commented Jun 5, 2018 •

edited

Loading

hackmod commented Jun 5, 2018 •

edited

Loading

hackmod commented Aug 7, 2018 •

edited

Loading

hackmod commented Sep 10, 2018 •

edited

Loading

pyskell commented Oct 2, 2018

hackmod commented Oct 24, 2018

whymarrh commented Oct 26, 2018

bobsummerwill commented Mar 25, 2019

bobsummerwill commented Mar 25, 2019

bobsummerwill commented Mar 25, 2019 •

edited

Loading

dominicletz commented Oct 20, 2020 •

edited

Loading

jimthedj65 commented Oct 27, 2020

brad-decker commented Mar 4, 2021 •

edited

Loading

danfinlay commented Mar 4, 2021

bobsummerwill commented Mar 4, 2021

chrisfranko commented Mar 5, 2021 •

edited

Loading

Multi-Chain Support #1820

Multi-Chain Support #1820

Comments

danfinlay commented Jul 25, 2017

ethernomad commented Sep 12, 2017

pyskell commented May 30, 2018

chrisfranko commented May 30, 2018

chrisfranko commented May 30, 2018

pyskell commented May 30, 2018 • edited Loading

chrisfranko commented May 31, 2018 via email

danfinlay commented May 31, 2018

pyskell commented Jun 1, 2018

hackmod commented Jun 5, 2018 • edited Loading

hackmod commented Jun 5, 2018 • edited Loading

hackmod commented Aug 7, 2018 • edited Loading

hackmod commented Sep 10, 2018 • edited Loading

pyskell commented Oct 2, 2018

hackmod commented Oct 24, 2018

whymarrh commented Oct 26, 2018

bobsummerwill commented Mar 25, 2019

bobsummerwill commented Mar 25, 2019

bobsummerwill commented Mar 25, 2019 • edited Loading

dominicletz commented Oct 20, 2020 • edited Loading

jimthedj65 commented Oct 27, 2020

brad-decker commented Mar 4, 2021 • edited Loading

danfinlay commented Mar 4, 2021

bobsummerwill commented Mar 4, 2021

chrisfranko commented Mar 5, 2021 • edited Loading

pyskell commented May 30, 2018 •

edited

Loading

hackmod commented Jun 5, 2018 •

edited

Loading

hackmod commented Jun 5, 2018 •

edited

Loading

hackmod commented Aug 7, 2018 •

edited

Loading

hackmod commented Sep 10, 2018 •

edited

Loading

bobsummerwill commented Mar 25, 2019 •

edited

Loading

dominicletz commented Oct 20, 2020 •

edited

Loading

brad-decker commented Mar 4, 2021 •

edited

Loading

chrisfranko commented Mar 5, 2021 •

edited

Loading