New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

ENS Ethereum Domain Name System

DevconMon, Oct 9, 2017, 12:00 AM

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/2/ens-ethereum-domain-name-system ENS: Ethereum (Domain) Name System The talk covers three aspects of a proposed Ethereum domain name system: the technical implementation of the recursive and modular lookup protocol (https://github.com/Arachnid/EIPs/blob...), the auction aspects for domain registration and reselling (https://github.com/ethereum/EIPs/issu...) and the possible attack vectors along with the suggestion solution and future expansion. Speaker(s): Nick Johnson Skill level: Advanced Track: Developer Infrastructure Keywords: swarm, ipfs, authority, implementation, resolution, registry, resolvers, node, namehash, governance, auction Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 2 was held in Shanghai, China on Sep 19 - 21, 2016. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

Transcript

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

Automatic transcript — names and jargon may be misspelled.