istanbul chainId opcode returns bad value

[Amxx]

Steps to reproduce

1. Start ganache-cli using the following command:

ganache-cli -l 8000000 -i 65535 -h 0.0.0.0 -k istanbul

2. Compile/deploy the following contract:

contract ChainIdTest
{
	function chainId()
	public pure returns (uint256 id)
	{
		assembly { id := chainid() }
	}
}

3. Call the chainId() function.

I expect the returned value to be the chainId passed using the -i flag and accessible using await web3.eth.net.getId(); ... but I get a value of 1

[Amxx]

After some investigation, this is what I've noticed:

• The chainId is retreived from the ethereumjs-common object used by ethereumjs-vm (a dependency of ganache-core):
  https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/evm/eei.ts#L288

• In our case, this common object is created by the constructor of the ethereumjs-vm. This uses a chain field from the opts (or mainnet by default):
  https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/index.ts#L103

• Apparently, ganache-core does not pass any chain field when constructing the VM
  https://github.com/trufflesuite/ganache-core/blob/develop/lib/blockchain_double.js#L128

• This is why the "mainnet" is selected by default, and why I get 1 when doing my test.

• A "obvious" solution would be to pass the chainId to the VM, which will then be interpreted by the Common constructor:
  https://github.com/ethereumjs/ethereumjs-common/blob/master/src/index.ts

• If we put a number into the chain field, common pass it from the constuctor to setChain then to _getChainParams which will then lookup the name of the of this chain in chainParams['names']
  https://github.com/ethereumjs/ethereumjs-common/blob/master/src/index.ts#L50

• chainParams only knows mainnet, ropsten, rinkeby an goerli (strangly with number 6284 and not 5)
  https://github.com/ethereumjs/ethereumjs-common/blob/master/src/chains/index.ts

Long story short, fixing this needs:

• Passing the chainid to ethereumjs-common

AND

• fixing ethereumjs-common to accept arbitrary chain ids

[davidmurdoch]

The -i option is the networkId, not the chainId. But you are still right; because we currently don't pass the chain id into ethereumjs-vm (or the transaction), but in our case it doesn't matter because it defaults to a chainId of 1.

What we need to do (and will do in our v3 release) is expose a customisable chainId option in ganache-core and ganache-cli. We'll also update the default chainId from 1 to 1337 at the same time. Currently the RPC method eth_chainId returns 1337, but all transactions are signed as if they were on a chain with an Id of 1.

The develop branch currently sets things up to use a custom chainId, but due to the misalignment of the RPC response and the actual response we are waiting until the next major release to make this breaking change.

Of course, if users find that this chainId misalignment bug needs to be fixed ASAP we can do a major update with this fix a bit sooner (but so far no one has reported it, as far as I'm aware).

[Amxx]

No one else might see the point, but if the chainId opcode was added it's because there are use-cases for that. I would personally say that it not being supported by ganache is currently preventing me from testing my 2 main projects.
The only reason I've not moved away from truffle is that no-one else seems to support it either...

[Amxx]

Also, while chainID and networkID are not strictly speaking the same thing, in the ETH community, the mainnet and the testnests (rinkey, ropsten, kovan, goerli) have this property that chainID = networkID.

My usage is to be able to verify meta-transaction signatures that target contracts deployed at the same address on multiple network. When running ganache-cli with option -i we assume that this will set both chainId and networkId so that the ganache behaves just like "one more eth testnet"

[dmihal]

Just spent hours debugging this, extremely frustrating.

web3.eth.chainId() should give the same value as the chainId opcode

[drortirosh]

It's an issue when using eip712.
The "domain separator" usually contains the chain id. It is very problematic that the on-chain code reports a signature mismatch when running locally, while it works on real network

[saurik]

We have a contract that relies on the chainid to protect layer 2 transactions during a fork, and I've been sitting here trying to figure out why Ganache wasn't working correctly and tracked it down to this issue: chainid() should return the same thing as eth_chainId. I see there seems to be some confusion related to the network id: from EIP-695 eth_chainId is supposed to return the chain id (thankfully, given its name ;P), not the network id. This is simply a bug, and should be fixed without waiting for a new major version, because it simply makes Ganache incompatible with all production environments: eth_chainId is simply returning the wrong value (or alternatively is chainid), and so anyone who is attempting to use the chain id right now (which is probably rare, as this is a rather recent feature: only deployed a month after when this bug was filed) already has broken code when run against Ganache.

[davidmurdoch]

@saurik, @dmihal you can pass in {_chainId: 1337} to your ganache-core server/provider as a temporary workaround. This should align the the chainId opcode with the eth_chainId RPC response. I'll add this option into ganache-cli's beta release next week.

We were intending on releasing a major version release of ganache-core a while back, but haven't been able to devote the time to working on planned changes until recently. We have fixed this behavior in the ts branch, but the branch isn't 100% ready for release just yet.

[davidmurdoch]

Related issue: #557

[davidmurdoch]

PR to expose the chainId option in ganache-cli: #787

PR to allow for separately configuring the chain's chainId and the eth_chainId in ganache-core: #629

[saurik]

@davidmurdoch Thanks; I don't actually know what a "ganache-core server/provider" is, but if this is exposed to the CLI version I can certainly switch to the CLI version and pass the flag. (Is this not going to be supported in the GUI? ;P Your web page only mentions a download for a GUI tool, and so that's what I was using before and what I had my Q/A team learn how to use.)

[davidmurdoch]

@saurik you can now use the --chainId option in the latest version of ganache-cli!

Ganache UI will be updated to add support for this option in the future :-)

[davidmurdoch]

done in ganache@3.0.0-internal.0

[frangio]

Could this be backported to the current version? It makes it difficult to test contracts that use chainId.

[drortirosh]

Could this be backported to the current version? It makes it difficult to test contracts that use chainId.

not sure why you want it to be backported - it is already available in published ganache-cli@6.12.2

When started with --chainId 1337 param, eth_chainId returns the same value as opcode CHAINID

(they said they will make it the default with next major version)

[frangio]

Thanks, that wasn't clear from the last few comments in the issue. I can't get the _chainId option to work with solidity-coverage but I'll keep trying. (Fixed)

I do hope the default gets fixed soon though, because this can be really difficult for people to debug in the context of EIP712 signatures.

[thomasoss]

I had a similiar problem. In truffel.js the networkId was set to 1337. In the Ganache GUI, too. But when I return the the chainId with the contract function

function getChainId() public view returns (uint256 chainId) {
     assembly {
        chainId := chainid()
    }
}

then i got 1 for the chainId. I know that the networkId is not the chainId. But theres is no way to configure the chainId when using the Ganache GUI.

I could not solve the problem but it works with using the trufflesuite / ganache (https://github.com/trufflesuite/ganache) instead. When I start ganache with

ganache --chain.chainId 1337 --chain.networkId 1337
then I get 1337 as chainId with the function described above.

The Ganache started on the command line work as good as the Ganache GUI but it is more flexible, because there are much more possibilities to configure Ganache when starting it up.

[MicaiahReid]

@thomasoss It's on our road map to get Ganache UI updated with the latest Ganache. Since your problem is now more related to Ganache UI, I'm going to make your comment an issue in the ganache-ui repo. Thanks!