Description
Describes the hash registrar initially used to register ENS .eth domains (formerly EIP-162).
Status
obsolete
Created
2016-10-25
Authors
  • nick.eth
  • avsa.eth
  • maurelian

ENSIP-2: Initial Hash Registrar

Abstract

This ERC describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS). The corresponding source code is here.

For more background, refer to ENSIP-1.

Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts.

- ENSIP-1

A well designed and governed registrar is essential to the success of the ENS described in ENSIP-1, but is described separately in this document as it is external to the core ENS protocol.

In order to maximize utility and adoption of a new namespace, the registrar should mitigate speculation and "name squatting", however the best approach for mitigation is unclear. Thus an "initial" registrar is proposed, which implements a simple approach to name allocation. During the initial period, the available namespace will be significantly restricted to the .eth top level domain, and subdomain shorter than 7 characters in length disallowed. This specification largely describes @alexvandesande and @arachnid's hash registrar implementation in order to facilitate discussion.

The intent is to replace the Initial Registrar contract with a permanent registrar contract. The Permanent Registrar will increase the available namespace, and incorporate lessons learned from the performance of the Initial Registrar. This upgrade is expected to take place within approximately 2 years of initial deployment.

Motivation

The following factors should be considered in order to optimize for adoption of the ENS, and good governance of the Initial Registrar's namespace.

Upgradability: The Initial Registrar should be safely upgradeable, so that knowledge gained during its deployment can be used to replace it with an improved and permanent registrar.

Effective allocation: Newly released namespaces often create a land grab situation, resulting in many potentially valuable names being purchased but unused, with the hope of re-selling at a profit. This reduces the availability of the most useful names, in turn decreasing the utility of the name service to end users.

Achieving an effective allocation may or may not require human intervention for dispute resolution and other forms of curation. The Initial Registrar should not aim to create to most effective possible allocation, but instead limit the cost of misallocation in the long term.

Security: The registrar will hold a balance of ether without an explicit limit. It must be designed securely.

Simplicity: The ENS specification itself emphasizes a separation of concerns, allowing the most essential element, the registry to be as simple as possible. The interim registrar in turn should be as simple as possible while still meeting its other design goals.

Adoption: Successful standards become more successful due to network effects. The registrar should consider what strategies will encourage the adoption of the ENS in general, and the namespace it controls in particular.

Specification

Initial restrictions

The Initial Registrar is expected to be in service for approximately two years, prior to upgrading. This should be sufficient time to learn, observe, and design an updated system.

During the initial two year period, the available name space will be restricted to the .eth TLD.

This restriction is enforced by the owner of the ENS root node who should not assign any nodes other than .eth to the Initial Registrar. The ENS's root node should be controlled by multiple parties using a multisig contract.

The Initial Registrar will also prohibit registration of names 6 characters or less in length.

Name format for hash registration

Names submitted to the initial registrar must be hashed using Ethereum's sha3 function. Note that the hashes submitted to the registrar are the hash of the subdomain label being registered, not the namehash as defined in ENSIP-1.

For example, in order to register abcdefg.eth, one should submit sha3('abcdefg'), not sha3(sha3(0, 'eth'), 'abcdefg').

Auctioning names

The registrar will allocate the available names through a Vickrey auction:

A Vickrey auction is a type of sealed-bid auction. Bidders submit written bids without knowing the bid of the other people in the auction. The highest bidder wins but the price paid is the second-highest bid. This type of auction... gives bidders an incentive to bid their true value.

- Vickrey Auction, Wikipedia

The auction lifecycle of a name has 5 possible states, or Modes.

  1. Not-yet-available: The majority of names will be initially unavailable for auction, and will become available some time during the 8 weeks after launch.
  2. Open: The earliest availability for a name is determined by the most significant byte of its sha3 hash. 0x00 would become available immediately, 0xFF would become available after 8 weeks, and the availability of other names is distributed accordingly. Once a name is available, it is possible to start an auction on it.
  3. Auction: Once the auction for a name has begun, there is a 72 hour bidding period. Bidders must submit a payment of ether, along with sealed bids as a hash of sha3(bytes32 hash, address owner, uint value, bytes32 salt). The bidder may obfuscate the true bid value by sending a greater amount of ether.
  4. Reveal: After the bidding period, a 48 hour reveal period commences. During this time, bidders must reveal the true parameters of their sealed bid. As bids are revealed, ether payments are returned according to the schedule of "refund ratios" outlined in the table below. If no bids are revealed, the name will return to the Open state.
  5. Owned: After the reveal period has finished, the winning bidder must submit a transaction to finalize the auction, which then calls the ENS's setSubnodeOwner function, recording the winning bidder's address as the owner of the hash of the name.

The following table outlines important parameters which define the Registrar's auction mechanism.

Registrar Parameters

| Name | Description | Value | | ------------------ | --------------------------------------------------------------------------------------------------- | ---------- | | totalAuctionLength | The full time period from start of auction to end of the reveal period. | 5 days | | revealPeriod | The length of the time period during which bidding is no longer allowed, and bids must be revealed. | 48 hours | | launchLength | The time period during which all names will become available for auction. | 8 weeks | | minPrice | The minimum amount of ether which must be locked up in exchange for ownership of a name. | 0.01 ether |

Deeds

The Initial Registrar contract does not hold a balance itself. All ether sent to the Registrar will be held in a separate Deed contracts. A deed contract is first created and funded when a sealed bid is submitted. After an auction is completed and a hash is registered, the deed for the winning bid is held in exchange for ownership of the hash. Non-winning bids are refunded.

A deed for an owned name may be transferred to another account by its owner, thus transferring ownership and control of the name.

After 1 year of registration, the owner of a hash may choose to relinquish ownership and have the value of the deed returned to them.

Deeds for non-winning bids can be closed by various methods, at which time any ether held will either be returned to the bidder, burnt, or sent to someone else as a reward for actions which help the registrar.

The following table outlines what portion of the balance held in a deed contract will be returned upon closure, and to whom. The remaining balance will be burnt.

Refund schedule

| Reason for Deed closure | Refund Recipient | Refund Percentage | | ------------------------------------------------------ | ---------------- | ----------------- | | A valid non-winning bid is revealed. | Bidder | 99.5% | | A bid submitted after the auction period is revealed. | Bidder | 99.5% | | An otherwise valid bid is revealed on an owned name. 1 | Bidder | 0.5% | | An expired sealed bid is cancelled. 2 | Canceler | 0.5% | | A registered hash is reported as invalid. 3 | Reporter | 50% | | A registered hash is reported as invalid. 3 | Owner | 50% |

Notes:

  1. This incentivizes all bids to be revealed in time. If bids could be revealed late, an extortion attack on the current highest bidder could be made by threatening to reveal a new second highest bid.
  2. A bid which remains sealed after more than 2 weeks and 5 days may be cancelled by anyone to collect a small reward.
  3. Since names are hashed before auctioning and registration, the Initial Registrar is unable to enforce character length restrictions independently. A reward is therefore provided for reporting invalid names.

Deployment and Upgrade process

The Initial Registrar requires the ENS's address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the eth node.

The Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade:

  1. The Permanent Registrar contract will be deployed.
  2. The multisig account owning the root node in the ENS will assign ownership of the .eth node to the Permanent Registrar.
  3. Owners of hashes in the Initial Registrar will be responsible for registering their deeds to the Permanent Registrar. A couple options are considered here:
    1. Require owners to transfer their ownership prior to a cutoff date in order to maintain ownership and/or continue name resolution services.
    2. Have the Permanent Registrar query the Initial Registrar for ownership if it is lacking an entry.

Planned deactivation

In order to limit dependence on the Initial Registrar, new auctions will stop after 4 years, and all ether held in deeds after 8 years will become unreachable.

Registrar Interface

function state(bytes32 _hash) constant returns (Mode)

function entries(bytes32 _hash) constant returns (Mode, address, uint, uint, uint)

function getAllowedTime(bytes32 _hash) constant returns (uint timestamp)

function isAllowed(bytes32 _hash, uint _timestamp) constant returns (bool allowed)

function startAuction(bytes32 _hash);

function startAuctions(bytes32[] _hashes);

function shaBid(bytes32 hash, address owner, uint value, bytes32 salt) constant returns (bytes32 sealedBid);

function newBid(bytes32 sealedBid);

function startAuctionsAndBid(bytes32[] hashes, bytes32 sealedBid)

function unsealBid(bytes32 _hash, address _owner, uint _value, bytes32 _salt);

function cancelBid(bytes32 seal);

function finalizeAuction(bytes32 _hash);

After the registration date has passed, this function can be called to finalize the auction, which then calls the ENS function setSubnodeOwner() updating the ENS record to set the winning bidder as owner of the node.

function transfer(bytes32 _hash, address newOwner);

function releaseDeed(bytes32 _hash);

function invalidateName(string unhashedName);

function eraseNode(bytes32[] labels)

function transferRegistrars(bytes32 _hash) onlyOwner(_hash);

Rationale

Starting with a temporary registrar

Anticipating and designing for all the potential issues of name allocation names is unlikely to succeed. This approach chooses not to be concerned with getting it perfect, but allows us to observe and learn with training wheels on, and implement improvements before expanding the available namespace to shorter names or another TLD.

Valid names >= 7 characters

Preserving the shortest, and often most valuable, domain names for the upgraded registrar provides the opportunity to implement processes for dispute resolution (assuming they are found to be necessary).

Delayed release of names

A slower release allows for extra time to identify, and address any issues which may arise after launch.

Restricting TLD to .eth

Choosing a single TLD helps to maximize network effects by focusing on one namespace.

A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a special-use domain name. A recent precedent for this is the reservation of the .onion domain.

Holding ether as collateral

This approach is simpler than the familiar model of requiring owners to make recurring payments to retain ownership of a domain name. It also makes the initial registrar a revenue neutral service.

Prior work

This document borrows heavily from several sources:

Edits:

Copyright

Copyright and related rights waived via CC0.