Add support for ENS contenthash methods

[cgewecke]

Description

Adds getContenthash and setContenthash methods to the ENS module.

Example

await web3.eth.ens.getContenthash('ethereum.eth');

> {
  "protocolType": "ipfs",
  "decoded": "QmaEBknbGT4bTQiQoe2VNgBJbRfygQGktnaW5TbuKixjYL"
}

await web3.eth.ens.setContenthash(
  'ethereum.eth', 
  'ipfs://QmaEBknbGT4bTQiQoe2VNgBJbRfygQGktnaW5TbuKixjYL,
);

As discussed in #3392, there are now two widely used resolver contracts for ENS with different interfaces.

PR adds support for the newer PublicResolver ABI, toggling between the two candidates by making an EIP 165 supportsInterface call for the contenthash method before selecting which ABI to use. If the Resolver address associated with the ENS name supports contenthash, the PublicResolver ABI is used, otherwise module defaults to the legacy Resolver ABI.

PR updates the ENS Resolver ABI to include contenthash interface as well as deprecated content. Makes EIP 165 supportsInterface calls for a subset of resolver methods to verify that the target contract implements them.

ENS has a feature that allows nodes to register ABIs on-chain for contract addresses but this does not appear to be implemented for the publicly deployed Resolver contracts themselves.

Running a reverse address check on Etherscan for the mainnet PublicResolver at: 0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41 does not discover an ENS node which might supply an ABI.

Fixes #3392

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run dtslint with success and extended the tests and types if necessary.
• I ran npm run test:unit with success.
• I have executed npm run test:cov and my test cases do cover all lines and branches of the added code.
• I ran npm run build-all and tested the resulting file/'s from dist folder in a browser.
• I have updated the CHANGELOG.md file in the root folder.
• I have tested my code on the live network.

[coveralls]

Coverage increased (+0.8%) to 89.43% when pulling 7b8d535 on issue/3392-ens-contenthash into 2a5c5cb on 1.x.

[ricmoo]

ABI is supported in the public resolver (resolver.eth) See line 72: https://etherscan.io/address/0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41#code

[cgewecke]

@ricmoo I might misunderstand this but isn't that ABI method similar to contentHash, e.g it lets you associate an ABI with a name?

In this case we're looking for the ABI of the resolver itself and I wasn't able to see a way of retrieving it.

If it is possible it would be the best solution by far though...

[ricmoo]

Oh! I see what you mean.

We could talk to @Arachnid about adding the ABI to resolver.eth, but I think it would be fine to just hardcode the getters (and maybe the setters) into it; each has an associated EIP.

Also, maybe it should be contenthash, not contentHash (and setContenthash, not setContentHash) to keep it inline with the EIP-1577 standard?

[cgewecke]

Also, maybe it should be contenthash, not contentHash (and setContenthash, not setContentHash) to keep it inline with the standard?

@ricmoo Ah yes, that's a good point.

[cgewecke]

Have revised per initial review - think this is moving in a better direction...

• Removed ABI toggling
• Added logic to query supportsInterface for each resolver method call Web3 wraps and ENS advertises an interface ID for in their docs. This is tolerant - e.g it will error if the Resolver doesn't support content but ignore methods it doesn't know about.
• Replaced ABI with the Resolver generic from @ensdomain/[email protected]. (This includes definitions for deprecated methods like content).
• Added an E2E test for pubkey set/get - its interface is also getting validated now.
• Removed camel-casing of contenthash

[nivida]

The outputFormatter addition wouldn't be required.. you can just wrap the promise as on other places :-)

[nivida]

(This ugly handler has to get refactored/removed anyways.. just ping me.. I do have a solution somewhere on a handwritten paper)

[cgewecke]

Not sure I follow, but yes this could be refactored at some point.

[nivida]

I remember a discussion I had once with @cgewecke about additional network requests and their impact. Shouldn't this checkInterface call not also be optional with a strictEns flag or so? Otherwise, the arguments in the discussion we had are false:)

[cgewecke]

The origin of this design is the discussion beginning in #3392 comment. In this case there are two widely deployed resolvers with different APIs, so there's a strong case for validating the request before-hand.

I think you're alluding here to a debate in #3428 about whether or not to gate revert-with-reason behind an option flag. The ENS module is not subject to the similar considerations AFAIK, personally don't think this will impact people in the same way 🤷

[nivida]

Instead of just copy it should we probably create an EF package for it with working together with ENS @Arachnid

[cgewecke]

This code comes out of @ensdomains/ui which is relatively large. This seemed like the lightest approach.

[nivida]

Noice! 🎊

[cgewecke]

Rebased on bcf248f

[cgewecke]

Update: Have made suggested improvements per @nivida's review:

• interfaceIds moved to config
• preserved the legacy ABI and only added contentHash methods as necessary
• deleted a stray mocha timeout

[andrewheadricke]

Just stumbled across this issue, looking forward to getting this incorporated into web3

[ryanio]

LGTM! Nice comprehensive work @cgewecke.

New tests are passing successfully in CI:

    ✓ should error when calling "getContent" if resolver does not support it
    ✓ should error when calling "setContent" if resolver does not support it
    ✓ getContenthash return object keys are null if no contentHash is set
    ✓ should get/set an IPFS contenthash (ipfs://)
    ✓ should get/set an IPFS contenthash (/ipfs/)
    ✓ should get/set a bzz contenthash
    ✓ should get/set an onion contenthash
    ✓ should get/set an onion3 contenthash
    ✓ setContenthash errors when encoding an invalid contenthash (promise)
    ✓ setContentHash errors when encoding an invalid contenthash (callback)