Reverse ENS lookup

[modersohn]

Initially started by @fudgebucket27 in b0058ee9eda15267dc412e6ceabf01fd0bc75aa7 using Ethereum service.

Different approach by @danielsolistensvik using Loopring API in 80c16f2f71dea2ccb283715e1be617278aafa344.

We need to discuss

1. whether we actually want to drag in the Loopring API at this stage
2. if yes, how do we want to cope with the rate limit of the Loopring API of 5 calls per second? This is especially problematic, if we want to show ENS names on overviews, like in the new token overview of #218.
3. do both services cover the same set of ENS names or does Loopring e.g. only cover *.loopring.eth?
4. how to separate models/DTOs. Currently LoopringV3.cs reflects the graph entities - which the name doesn't really suggest.
5. Loopring API DTOs are different and should be kept separate.

[daniel-soli]

3. From my testing, the loopring api covers only .loopring.eth and nethereum package only covers .eth

[fudgebucket27]

Yep, the rate limit is going to be a big issue. Is it possible to somehow make the API calls via the client?

[modersohn]

3. From my testing, the loopring api covers only .loopring.eth and nethereum package only covers .eth

But then why are we able to resolve ENS addresses like icecream.loopring.eth when you search for them? I know this is not reverse lookup, but it seems odd it would work for lookup and not reverse lookup.

Is it possible to somehow make the API calls via the client? Even if (and I have no idea how exactly) that would make caching impossible etc. etc.

If Ethereum works and we do heavy caching (data will never change, will it?) then I'd still prefer sticking with Ethereum and then just let its do its job. With cancellation tokens etc. this shouldn't really be an issue. In then end, everybody will be looking at the LRC whales only anyway ;-)

[modersohn]

Who would have thought, there's a graph for ENS lookup as well: https://thegraph.com/hosted-service/subgraph/ensdomains/ens

And it shows that one address (i.e. account in their scheme of things) can have more than one domain registered.

And I saw that some names are actually registered as hashes (e.g. fudgey.loopring.eth is nowhere to be found, but [f9a8692a897e8651112fb8a6c9adaebd6f1d57c3d31df079187583714e958b67].loopring.eth is).

Last but not least, there's an Eth contract that is intended to reverse lookup a lot of addresses at once: https://github.com/ensdomains/reverse-records

[modersohn]

I had high hopes of using the subgraph for reverse lookup (because you could retrieve a handful with a single query), but it seems this is simply not possible, because at least for some like fudgey.loopring.eth, the actual label name is not stored:

{
  "data": {
    "accounts": [
      {
        "id": "0x99fdddfdc9277404db0379009274cc98d3688f8b",
        "domains": [
          {
            "id": "0x4de08a3ddea1e84c5434ca41638f35d0dea0ce3e5c62addc8d17bc45c739d02e",
            "name": "[f9a8692a897e8651112fb8a6c9adaebd6f1d57c3d31df079187583714e958b67].loopring.eth",
            "labelName": null,
            "labelhash": "0xf9a8692a897e8651112fb8a6c9adaebd6f1d57c3d31df079187583714e958b67"
          }
        ],
        "registrations": []
      }
    ]
  }
}

And while you can get the hash from the label (keccak256), it doesn't work the other way around.

Also, the reverse-records contract mentioned above, is not able to resolve *.loopring.eth subdomains it seems and oh boy, lo and behold, Netherum is also unable to reverse-lookup these.