hi there my name as you already know is
Nick Johnson I work for the foundation
on the NGO aetherium team and on Swarm
and I'm here to talk to you about the
ENS the etherium name service can I have
some slides excellent I don't know if I
can recite the whole thing from memory
so so the first thing you're probably
asking is why do we need another name
service this comic is probably familiar
to a significant proportion of you and
first of all why do we need a name
service at all our goal is to be able to
name users wallets to name contracts and
to name resources on Swarm and IP
affairs and as denise has demonstrated
there's a vast number of other uses for
a good and robust name service and as
for why we need another one if you're
familiar with name reg you'll know that
this isn't the first name service on
etherium the reason is that the existing
name services are paradoxically quite
centralized they have a single central
contract there's no facility for
upgradability there's no facility for
adding new record types in the future so
it's useful to be able to build
something that well still being as
simple as possible is a lot more robust
and a lot more future proof so what
makes a good name service separation of
concerns there are three separate things
three separate components and a good
name service at least in my mind one of
them is the actual resolution of the
names one of them is the updating and
the registration of names and the third
one is registrar's so how you actually
get the top-level name in the first
place where you would go to you know
GoDaddy or Gandhi or whatever on the DNS
system and existing systems can plate
those and there's the matter of
distributed Authority and implementation
as I already alluded to it needs to be
Ford compatible we there will be uses
for the name system we haven't thought
of yet and it needs to have efficient on
chain resolution so a lot of the
applications are in depth there in swarm
and browsers but it's also very useful
for contracts to be able to refer to
other contracts by name because it makes
for better upgrade ability so these are
the three main components of the ens
we have the ENS registry which is the
centralized contract and somebody's skip
to hidden my slides nevermind the
centralized contract which contains the
entire name tree it's the only component
to the system that isn't upgradable
because it's extremely simple and its
job is simply to map from the name you
enter into the the resolver so the
second component is the resolvers
resolvers can be written by individual
users or you can use a premade one they
can use any system they like and they go
from the name to the record so when you
do a name lookup first you ask the
registry where is the resolver for Nik
death and then you ask the resolver what
is the address of Nik Dottie's so
looking at the registry there we go we
conceptually it's structured like a tree
you have the root node under there you
have all the top-level domains under
that you have all the users domains like
Swati Earth Wallet dotty
and so on it's hierarchical so once you
own a name you can create names under
that each of these is associated with a
node ID and the node ID represents the
name so although the conceptual
structure here is a tree internally it
looks quite different it's actually just
a big lookup table which is why it's
such a simple contract and why we
believe that we can deploy it without a
built-in upgrade facility it Maps a node
number which represents the name to an
owner who is the account that has the
right to update the name and a resolver
which if it exists turns names into
values you might be wondering how the
last I really have you might be
wondering how you go from a name to a
node ID this is using a system called
name hash what we do first is you break
the name up into components so you can
see there we head Nick wallet Earth has
been broken up into three components you
reverse them so you start with if and
you char three hash that and you get
that first value here then you take that
and you shower through it with zero
which is the root node and you take that
and you
that and you do the whole operation all
over again you feed us in as the as the
parent node you share three wallet you
put it into the next one you shower
through that with NICU feeds into the
next one and what you get out if I can
make my slides work is the final note -
the purpose of all of us convoluted
though it may seem is that you can look
up a no-name of arbitrary dips you food
Bardot pears quack studies in a single
lookup operation and yet the registry
contract can still deter answer
questions like does this person own the
parent name for this name and so forth
which allows the distributed Authority
and allows assignment of authority so
the next component of ENS is the
resolvers resolvers can be written by
individual users they can be extremely
simple or they can be very sophisticated
they're an extremely simple resolver
here that is owned by a particular user
and only registers names for them is
here it has three main functions has
answers the question do you know the
answer to this particular question so in
this case it only supports address
records and it only supports the ones
that have been added to it and if it has
it returns true the second function is
the one that everyone trying to resolve
names calls its error so you pass in the
node which again is the value of this
operation previously if it has it it
returns it if it doesn't throw as an
exception and finally you have the
function that this is not part of the
spec it's part of the interface of your
individual resolver which is set error
which leads the owner set the address
and as you can see it's an extremely
simple contract and that is the entirety
of a fully functional resolver finally
the third component of ENS is the
registrar's registrar's are the owners
in the ENS registry and their job is to
assign names to people with the simplest
possible registrar is me I can actually
own it own a domain using my external
address if you come up to me I can give
you a sub name no contracts need be
involved but for top-level names it's
helpful to have a smart contract because
it's automated and it ensures fairness
and everyone knows what the registration
rules are and more importantly everyone
knows that I won't come along and
Abbot's really decide actually I really
want toaster dotty
I'm gonna take it back off you so the
registrar is similarly simple this is a
really simple registrar that replicates
more or less functionality of the
existing name Ridge the first person to
ask for a name gets it if they already
own the name they can assign it to
someone else and all it does here is it
has the address of the registry and when
it's asked to it updates the name in the
registry so those are the basic
components of ENS and it pretty much
describes the entire technical
implementation the remaining component
the the only remaining component which
you'd think is really quite
straightforward but really really isn't
is governance governance is an ongoing
issue the question is how how should we
administer the domain system who should
we assign names to should they have to
pay who should get the money and so
forth and our conversations around
governance always seem to go like this
so I go I've got this really great idea
on how we can assign names we should do
it like this sorry Nick
this is a terrible idea I have a bunch
of other thing we can do actually both
of you are wrong we should let the
market decide well actually that's a
good idea but then who gets who gets the
top-level nine innings I've got a great
idea on how we should assign names and
so forth so we have come up with what
Alex calls the Macdonald solution and
I'll go into more detail in it shortly
but basically our plan is to deploy an
interim registrar which uses a very
simple registration scheme and people
can then register names and we'll what
we plan on launching this towards the
end of the year about a year from now
we'll starts accepting submissions for a
permanent registrar which we expect will
be more complicated more sophisticated
it will take care of things I could use
and so forth and the reason for the
delay is that we want to get some
experience with operating the name
system we want to learn what the real
practical problems are we want to be
able to use those to build a bit of
registrar and then with a goal of about
a year from there I'm sorry but these
are slightly
date slides please pretend those of Vega
and they're not November we will we
intend to launch the permanent registrar
to replace the into the intermediate one
so what does the temporary registrar
looks like it's an auction only names
and a dot if they're available so we'll
only have one top-level domain with the
goal of preventing collision with exist
the existing domain name system names
are optional fusing a blind second price
option which is also called a Vickrey
auction names shorter than actually that
seven characters are prohibited which
may sound restrictive but our goal is to
save the really high value names for
when we have a system that we will know
we know will fairly hand them out
winning bidders deposits are held in
contract accounts and after six months
you can delete your name and recover
your deposit or once the new read
permanent registrar is available you can
transfer your deposit to the registrar
and keep the name under whatever rules
are established for that eventual
registrar the goal is that switching to
the eventual registrar will be
consensual you if you don't wish to use
the new registrar you can get your money
back if you do then you can pass it on
which means that we hope that whatever
registrar eventuates will be one that
the majority of people think is a good
idea and that's it for the etherium name
service I have about a minute for
questions but I don't think we're taking
them if your interest is more you can
email me in at Nikita theorem dot org
join the conversation at Gator in the
name registry room and the EIP which
officially defines ENS is there please
read and comment we welcome your
feedback thank you very much
you