Web3.js: ENS is not supported on network private using cloudflare-eth

[lucadonnoh]

Expected behavior

ENS resolving domain

Actual behavior

ENS is not supported on network private

Steps to reproduce the behavior

var Web3 = require('web3');
const web3 = new Web3('https://cloudflare-eth.com');
var ens = web3.eth.ens;

async function reverseResolve(address) {
    var domain = await ens.getAddress(address+'.addr.reverse');
    return domain;
}

Log:

(node:23664) UnhandledPromiseRejectionWarning: Error: ENS is not supported on network private at ENS.checkNetwork (/Users/donnoh/node_modules/web3-eth-ens/lib/ENS.js:483:19) at processTicksAndRejections (internal/process/task_queues.js:93:5) (Use 'node --trace-warnings ...' to show where the warning was created) (node:23664) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:23664) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[cokia]

I don't think this is a web3 problem. Because the genesis hash of cloudflare-eth is not the same as the Genesis hash of Etherium Mainnet.
"web3.eth.net.getNetworkType()" This returns the private. That's why this error occurs, primarily because of the cloudplare ETH node operation.

I saw this issue and made a suggestion about "web3.js".

Ethereum's official document also recommends "web3.eth.net.getId()" over "web3.eth.net.getNetworkType()". Because getNetworkType() separates the network based on the hash of the Genesis block, and getId is based on the chain ID of the node.

So I think we should change the code of https://github.com/ethereum/web3.js/blob/942161c5db4c09582c8308c5a6e7363fc3b07be0/packages/web3-eth-ens/src/ENS.js#L523 based on getID().

@GregTheGreek What do you think of this opinion?

[cokia]

@GregTheGreek

I'm really sorry for tagging you twice. But I thought you missed this issue, so I called you again. What is your opinion on the above proposal?

[GregTheGreek]

Hey! This slipped my radar. Let me figure this out tomorrow morning I've set a reminder.

[cokia]

I think it would be good if you check this. @GregTheGreek
thx !

[GregTheGreek]

So here is the gist.

We did not write the original ens package, and the ens resolvers are explicitly hard coded for the safety reasons of users not sending funds to malicious parties.

At this time, we have no clear path forward on whether to unwind that decision.

Hard coded addresses are potentially dangerous as is, but at this point I'm hesitant to change it.

We're all open to suggestions, but this will be a very careful decision.

[cokia]

Oh! I didn't think this was a security problem. I naturally thought that the ENS of the network could be trusted.

I understood your opinion, and I think it is right that this modification is not reflected accordingly.

[GregTheGreek]

Yep, ens is simply a series of smart contracts on Ethereum. It is not within the protocol layer, thus we can't query it directly from a node etc...