Implementations for registrars and local resolvers for the Ethereum Name Service.
For documentation of the ENS system, see docs.ens.domains.
To run unit tests, clone this repository, and run:
$ npm install
$ npm test
Implementation of the ENS Registry, the central contract used to look up resolvers and owners for domains.
Implementation of a simple first-in-first-served registrar, which issues (sub-)domains to the first account to request them.
Implementation of a registrar based on second-price blind auctions and funds held on deposit, with a renewal process that weights renewal costs according to the change in mean price of registering a domain. Largely untested!
Simplified version of the above, with no support for renewals. This is the current proposal for interim registrar of the ENS system until a permanent registrar is decided on.
Simple resolver implementation that allows the owner of any domain to configure how its name should resolve. One deployment of this contract allows any number of people to use it, by setting it as their resolver in the registry.
The ENS registry is a single central contract that provides a mapping from domain names to owners and resolvers, as described in EIP 137.
The ENS operates on 'nodes' instead of human-readable names; a human readable name is converted to a node using the namehash algorithm, which is as follows:
def namehash(name):
if name == '':
return '\0' * 32
else:
label, _, remainder = name.partition('.')
return sha3(namehash(remainder) + sha3(label))
The registry's interface is as follows:
Returns the owner of the specified node.
Returns the resolver for the specified node.
Updates the owner of a node. Only the current owner may call this function.
Updates the owner of a subnode. For instance, the owner of "foo.com" may change the owner of "bar.foo.com" by calling setSubnodeOwner(namehash("foo.com"), sha3("bar"), newowner)
. Only callable by the owner of node
.
Sets the resolver address for the specified node.
Resolvers must implement one mandatory method, has
, and may implement any number of other resource-type specific methods. Resolvers must throw
when an unimplemented method is called.
Returns true iff the specified node has the specified record kind available. Record kinds are defined by each resolver type and standardised in EIPs; currently only "addr" is supported.
has()
must return false iff the corresponding record type specific methods will throw if called.
Implements the addr resource type. Returns the Ethereum address associated with a node if it exists, or throw
s if it does not.
ENS.lll.bin was generated with the following command, using the lllc packaged with Solidity 0.4.4:
$ lllc ENS.lll > ENS.lll.bin
The files in the abi directory were generated with the following command:
$ solc --abi -o abi AbstractENS.sol FIFSRegistrar.sol HashRegistrarSimplified.sol PublicResolver.sol
Install Truffle
$ npm install -g truffle
Launch the RPC client, for example TestRPC:
$ testrpc
Deploy ENS
and FIFSRegistrar
to the private network, the deployment process is defined at here:
$ truffle migrate --network dev.fifs
alternatively, deploy the HashRegistrar
:
$ truffle migrate --network dev.auction
Check the truffle documentation for more information.