The ENS Blacklist
The first of many components used to create ENS’s dispute resolution.
One of the large areas of improvement for ENS right now is dispute resolution, which is currently non-existent. This allows malicious actors to squat names as well as register similar names with the goal of deceiving users. We need to do our best to prevent names from being used for malicious purposes, this will ensure better overall usability for our end users, one of the fundamental goals of ENS.
Blacklists are one of the first components we have built for ENS dispute resolution, additionally they will play a fundamental role in the enforcement of outcomes. The blacklists should act as a secondary layer on top of the base ENS contracts, this means that there are no plans for them to be natively added into core contracts. However, given an agreeable arbitration system most actors will likely choose to accept the “default” blacklist.
Additionally, a blacklisting system already significantly reduces the leverage a squatter has in an arbitration phase, thus directly reducing the incentive for a user to even squat an ENS name. This should reduce the amount of arbitration cases, as many potentially malicious actors will realize that there is barely any incentive in doing any harm.
The main focus for blacklists is to prevent a user from resolving and interacting with an address belonging to either a squatter or a scammer. It is important to differentiate between the two, as both parties affect different members of the ecosystem, squatters are focused on getting profits from those who desire a certain domain whereas scammers have the goal to manipulate users into sending funds to an incorrect address.
The integration of a blacklist is rather simple, before resolving a name the end user application would first ensure that it is permitted by the blacklist, meaning that it has not been entered into the list. If this is the case, the resolver would then be called as normal.
To make this easier there will be an ENS registry extending the base registry that takes the default blacklist into account, this ensures that end user applications would not need to do the blacklist call manually if they do not wish to do so. Before this can happen, a proper dispute resolution system needs to be implemented however.
Benefits of the blacklist system can be seen for every member of the network, this includes domain owners, end users along with application developers. End users are given a guarantee that the domains they are interacting with are not malicious, owners can ensure that impersonations of their domains and potential scammers are dealt with properly by all applications adhering to the “default” blacklist and application developers can guarantee to their users that they are interacting with a safe system that will protect them from potential scammers.
An interesting addition to preventing users from interacting with squatters or scammers, is to use the blacklist system to create selective filters that are interoperable between various dapps. Nick Johnson and I discussed this after it was mentioned in a tweet:
dApps could allow users to import custom blacklist, essentially allowing for custom user filtering, this for example could be useful for users who do not wish to see adult content at work. Those users could be given the choice to add custom blacklists to their applications which are managed using some form of curation system. It would be interesting to see various blacklists rise beside the “default” list which could be for various categories of content offering a versatile community managed filtering system that is completely opt-in.
Although simple, the ENS blacklist system allows us to cover various use-cases bringing us one step closer to a community based dispute resolution system that is completely dependent on the network effects of ENS. The current blacklist implementation can be found here on our github, it conforms to the ERC892 permission standard.
