Ethereum Name Service Returns For Relaunch
Today, May 4, 2017, marks the relaunch for the Ethereum Name Service (ENS), which was plagued by bugs on its initial launch forcing it back into development. ENS community launch manager Chris Remus, on a Medium blog post, announced the relaunch.
When active on the Ethereum Mainnet, an auction process will distribute ENS names onto the '.eth' domain. The blind auction process is fully described on Github, a site used by developers.
Those who wish to register domain names will have an eight week period during which the names will become available, and users will be able to look up when specific domain names can be bid upon.
Currently registration can be done in two ways. If registering with a Dapp or a web-based interphase, users are only required to access a URL with a “web3-enabled browser”. Otherwise a Linux server running the Ethereum Virtual Machine is necessary, and for users utilizing this method, a guide has been provided.
Back in March 2017, bugs prevented effective deployment of ENS, and, as ETHNews reported last April, a series of tests and fixes were implemented on the Ropsten testnet to get the services ready for launch. Now, root keyholders have approved the revised registrar and are ready to roll out the naming service.
Seven root causes were indicated in a report detailing the initial launch issues:
1 — Lack of unit test coverage
Although the registrar had a suite of unittests, this testing was not comprehensive. The unit tests were written after the contract by a different author. No concerted effort was made to ensure that all code paths or use cases were thoroughly covered.
Unit tests existed that could have caught the bugs, but they made insufficient assertions about the post-state of the contract, resulting in a missed opportunity.
2 — Insufficient code review
The changes to the contract that introduced the bugs were subject to review in a Pull Request, but the review did not catch the bugs. In future, more care is needed when reviewing changes to critical code to ensure reversions aren’t accidentally introduced.
3 — Lack of formal, independent audit
The registrar contract was reviewed informally by a number of community members during its deployment on the Ropsten testnet, resulting in the identification and remediation of several bugs. A review was also performed by Martin Swende shortly prior to launch, but on an informal basis with time constraints. No independent, comprehensive audit was done.
4 — No clear indication of bug bounty status
No clear indication was provided to the community as to whether ENS was covered by the Ethereum Foundation’s bug bounty process. Had it been announced that ENS was covered, more attention would likely have been directed towards the code at an earlier stage in the process, resulting in the bugs being found at a stage where they could be easily remedied without affecting the launch.
5 — Reluctance to cancel a launch
The launch should have been postponed after the first bug was discovered, to offer more time to assess the contract and determine if other related bugs existed. The decision to proceed was made in part due to the mistaken belief that the first bug was a one-off one, and in part due to a desire to meet the original stated launch day.
In future, this can be mitigated by ensuring there are independent stakeholders with the ability to call a launch off if, in their opinion, such an action is warranted.
6 — ‘Attention amplification’ effect of launch
Attention should also be drawn to the ‘attention amplification’ effect of launch. We believe that a significant reason the bugs were found so close to launch was due to the large amount of additional attention the launch directed at the code. This attention could have been harnessed for better use had there been an ENS bug bounty offered.
The amplified attention on the code resulting from the public launch, while now requiring postponement, has a silver lining in that it’s possible a ‘softer’ launch would have allowed the bugs to go undetected for much longer, at which point they could have done more damage.
7 — Difficulty of live upgrades
During the development of the registrar, a conscious choice was made to require positive action from users in order to migrate from one registrar to another. This was done because the registrar has total control over what happens to the user’s deposit; by requiring user input, it’s guaranteed that they’re able to make an informed choice if the code change.
Now launched, the ENS provides users a friendlier GUI to the Ethereum blockchain.