Multi-Chain Support

[danfinlay]

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]

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

[pyskell]

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]

ETC being first of course. 🙄

[chrisfranko]

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]

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]

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]

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]

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

[hackmod]

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]

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]

[ ] 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]

See also

• eth_chainId PR for Ethereum (geth) - eth,internal: add eth_chainId method to PublicEthereumApi JSONRPC ethereum/go-ethereum#15002, add eth_chainId method ethereum/go-ethereum#17617 merged(9/30)
• eth_chainId PR for ETC (classic-geth) - implement 'eth_chainId' JSON-RPC method ethereumproject/go-ethereum#336 merged
• EIP:695 - Implement eth_chainId method in JSON-RPC - EIP: Implement eth_chainId method in JSON-RPC ethereum/EIPs#695 accepted

[pyskell]

Can we address this? Is EIP-155 really needed if every blockchain implements it? @danfinlay

[hackmod]

See also PR #5552

[whymarrh]

Refs #5134 as well

[bobsummerwill]

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]

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]

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]

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]

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]

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]

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]

Hurrah :-)

Thank you, MetaMask crew!

[chrisfranko]

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