EIP-1193: Add chainChanged event

[pedrouid]

A Dapp should only concern with the integrity of the transactions and typed data messages signed by the provider, hence we should track the chainId which prevents transaction replay attacks as part of the EIP-155.

NetworkId only concerns with the p2p connection between peers but there is no guarantee that this Id is the same as the chainId which concerns with the transactions signed and broadcasted to a client.

The EIP-695 has been implemented by Parity and Geth to return the chainId using the eth_chainId method therefore we should stop using the networkId returned by the net_version.

My proposed change replaces the networkChanged event with chainChanged event. To ensure transactions and typed data messages are signed correctly we need to track the chainId and not the networkId

---

PS - As requested I've changed this PR to simply add the chainChanged event instead of replacing it completely with networkChanged to provide backwards compatibility with existing Dapps. I would like to still signal that chainId is used from now forward instead of networkId as this technical debt which being underestimated right now and has critical issues as the ones described above.

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1193 requires approval from one of (@MaiaVictor, @frozeman, @marcgarreau, @ryanio)

[axic]

There is another instance of networkChanged further down the document.

[pedrouid]

There is another instance of networkChanged further down the document.

Thanks, just fixed it!

[danfinlay]

I am in favor of adding a chainChanged event, but removing networkChanged is a breaking API for dapps, and so I think it's a bad idea.

Furthermore, it is strange to me that a PR can modify an already-merged EIP, changing the definition of that EIP. A wallet could be 1193 compatible one week, and no longer the next week? That doesn't make sense to me. I would prefer if changes like this had their own EIPs that amended previous standards, so they could be referred to in distinction from the previous standard. But this is up to the EIP editors to really enforce.

[axic]

Furthermore, it is strange to me that a PR can modify an already-merged EIP, changing the definition of that EIP.

This EIP is a draft, so it can be indefinitely modified. If you want to finalise it, I'd suggest to go through the "Last Call" process (see EIP-1) and arrive at the "Final" status.

[axic]

@danfinlay even if not changing the chainid, adding 1102 and 1474 as a requirement here may make sense.

[pedrouid]

I am in favor of adding a chainChanged event, but removing networkChanged is a breaking API for dapps, and so I think it's a bad idea.

Furthermore, it is strange to me that a PR can modify an already-merged EIP, changing the definition of that EIP. A wallet could be 1193 compatible one week, and no longer the next week? That doesn't make sense to me. I would prefer if changes like this had their own EIPs that amended previous standards, so they could be referred to in distinction from the previous standard. But this is up to the EIP editors to really enforce.

While you are technically right, @danfinlay, we are currently using the networkId incorrectly. The networkId is not meant to be used for signing yet it's exactly what we are doing. On the positive side, the networkId is coincidently the same as the chainId for most chains.

I think this is a very positive "breaking change" just like the EIP-1102 was which will push the Dapp development in the right direction. We've dragged this for way too long now in my opinion.

[danfinlay]

This is incredibly different from 1102, where the change was to remove insecurity. Here you remove an antipattern. There is no hard requirement that we break Ðapps for their own good to gain the benefits you seek here.

[pedrouid]

The only reason the networkId works right now is because it's the same value as the chainId. We have been doing it wrong since the EIP-155 and this will just get more amplified as we have more chains and side-chains interoperating. Event the EIP-712 relies on the chainId.

A lot of Dapps broke when the 1102 came around and they had to refactor their code. The change for the networkId and chainId will be even simpler, because the most supported chains have a chainId with the same value for networkId (mainnet, ropsten, rinkeby, kovan and goerli).

Instead of querying for web3.version.getNetwork they just need to query for web3.eth.getChainId which has been support by web3.js since v1.0.0-beta.48.

IMHO if we don't get rid of networkId, it will be misused forever, because it coincidently matches the chainId.

[nivida]

I think the solution would be to have both events in parallel for a time and to mark the networkChanged event as deprecated with a console warning.

Edit:
As mentioned in the PR #2090 is it probably the better way to define these events as separate EIP.

[alcuadrado]

I think the solution would be to have both events in parallel for a time and to mark the networkChanged event as deprecated with a console warning.

Agreed

[pedrouid]

As requested I've changed this PR to simply add the chainChanged event instead of replacing it completely with networkChanged to provide backwards compatibility with existing Dapps. I would like to still signal that chainId is used from now forward instead of networkId as this technical debt which being underestimated right now and has critical issues as the ones described above.

cc @nivida @danfinlay @alcuadrado

[danfinlay]

I approve of this change, thanks for hearing it.

[pedrouid]

Could we merge this?
cc @MaiaVictor @frozeman @marcgarreau @ryanio @axic @nivida @danfinlay @alcuadrado

[alcuadrado]

I think this is ready to be merged

[axic]

If the authors of 1193 are not responding for a long period I think it would make sense to include some new maintainers in the author list.

@nicksavers @Arachnid any comments?

[frozeman]

Looks good

[axic]

@frozeman thanks for reviewing. #2090 #2127 are also waiting for a review.