Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Draft EIP for ENS support for contract ABIs #205
referenced this pull request
Sep 11, 2017
Why is this being proposed as part of ENS? It seems more useful to have the ABI lookup occur on the contract address, and since ENS will resolve to a contract address it means we can easily go from current ENS to ABI lookup. In particular, if the ABI is tied to the ENS name then if the ENS name is changed to point at a different contract (e.g., as part of a contract upgrade) then the ABI potentially will no longer match.
Also, is there any way that the ABI can be verified? What prevents some random hacker from uploading an ABI for a particular contract address that is malicious (tricks users)?
Doing so would require contracts to return their own ABIs. That has a couple of disadvantages over this scheme:
Like with all metadata, it's the name owner's responsibility to make sure it's up-to-date.
Only the owner of the reverse record can set ABI records for the contract address. Nothing prevents J Random Hacker setting up an ENS name with ABI record pointing at a contract, but by the time they've persuaded you to use their ENS name to interact with the contract without verifying anything, it's already too late to ameliorate.
The contract could return a hash of the ABI rather than the full ABI, and the hash could then be used as a lookup key. Perhaps even better would be if the contract returned an array as a mechanism of asserting that it implements some interface (one of the hashes) and also some full ABI. However, your other point about deploy time is very valid.
I feel like the name owner should need to explicitly indicate which contract address an ABI is for. If the name redirects, the ABI should become invalid until such time as the name owner also redirects the ABI. From a management perspective, these two operations could be done at the same time, but I think defaulting to assume the ABI hasn't changed when the name redirects is introducing unnecessary risk.
This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:
If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.
In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.
Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt: