Add block number parameter to resolver methods

[wbt]

TL;DR: Functions like getName, getOwner, getProfile, getRecords, getResolver, getContentHash, getText, and other getters should take a second parameter 'blockNumber' which defaults to 'latest'.

---

A use case I have at the moment (which seems likely to be common) is a Dapp that allows use of and displays ENS names instead of addresses (where available), including looking for and displaying data about past transactions and the ENS-labeled names of who took various actions.

Existing library methods do the translation as of the latest block with no parameter for being able to resolve names in either direction as of some past block. The link goes to ethers but the issue is here too, and will probably have to be fixed in an ENS-maintained library before it gets to ethers.js.

Sometimes, ENS addresses change hands, and it's not always through kind good-faith means between fully mutually trusting parties.

I don't have a proof-of-concept demo at hand at the moment of why the lack of this feature seems dangerous, but it seems like there are probably some exploits out there which involve changing the ENS name <=> address correspondence and then executing functions or encouraging/letting people use interfaces that consider past transaction data but only through the lens of present ENS names.

In some settings, the use of present names is exactly appropriate, but it isn't always, and Dapp developers who want to do the right thing when it isn't currently have a lot of work ahead to figure out how to get the historical data. Having commonly used libraries (or at least the one maintained by ENS!) be able to support historical forward & reverse resolution by passing a block number parameter to the resolver functions (w/default value 'latest') could help improve the overall state of Dapp security.

Here’s one example not requiring any bad actors: suppose a DAO that takes great pains to avoid conflicts of interest or appearances thereof. A DAO president awards a grant to new ecosystem member Joe and the grant is wildly successful in its goals; over time Joe becomes integrated as a valuable member of the community, then a core member, and then even the DAO president with the associated ENS name. However, an outside observer looking at the DAO’s financial records would then be able to see using even the DAO’s own tooling that in the past President Joe gave a large grant to...himself, and all that language about avoiding even the appearance of a conflict of interest must just be BS in this DAO (when really it’s not).

While it appears that a workaround for the absence of this feature likely exists, it’s a long detour / lot-of-work workaround compared to adding another parameter in a read call (as can be done when reading from custom contracts in ethers or web3).