 Hi there. My name, as you already know, is Nick Johnson. I work for the foundation on the Go Ethereum team and on Swarm. And I'm here to talk to you about the ENS, the Ethereum name service. Can I have some slides? Excellent. I don't know if I can recite the whole thing from memory. 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. 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 IPFS. And as DNS has demonstrated, there's a vast number of other uses for a good and robust name service. As for why we need another one, if you're familiar with NameRedge, you'll know that this isn't the first name service on Ethereum. The reason is that the existing name services are paradoxically quite centralized. They have a single central contract. There's no facility for upgradeability. There's no facility for adding new record types in the future. So, it's useful to be able to build something that, while 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 in 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. The third one is registrars, so how you actually get the top-level name in the first place, where you would go to GoDaddy or Gandhi or whatever on the DNS system. And existing systems conflate those. There's the matter of distributed authority and implementation, as I already alluded to. It needs to be forward-compatible. 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 DApps, they're 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 upgradability. So, these are the three main components of the ENS. We have the ENS registry, which is a centralized contract, and somebody skipped ahead in my slides, never mind. A 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 resolver. So, the second component is the resolvers. Resolvers can be written by individual users, or you can use a pre-made 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 nick.eth, and then you ask the resolver, what is the address of nick.eth? So, looking at the registry, there we go, conceptually it's structured like a tree. You have the root node, under that you have all the top-level domains, under that you have all the users' domains, like swarm.eth, wallet.eth, 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... Blast, I really have... You might be wondering how you go from a name to a node ID. This is using a system called NameHash. What we do first is you break the name up into components, so you can see there we had nick.wallet.eth has been broken up into three components. You reverse them, so you start with eth, and you char3hash that, and you get that first value here. Then you take that, and you char3 it with 0, which is the root node, and you take that, and you feed that in, and you do the whole operation all over again. You feed it in as the parent node, you char3 wallet, you put it into the next one. You char3 that with nick, you feed it into the next one, and what you get out, if I can make my slides work, is the final node hash. The purpose of all of this, convoluted though it may seem, a name of arbitrary depth, food.bar.baz.quarks.eth, 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. 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. It's adder, 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, it throws 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 adder, which lets 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 registrars. Registrars are the owners in the ENS registry, and their job is to assign names to people. The simplest possible registrar is me. I can actually own a domain using my external address. If you come up to me, I can give you a sub-name. No contracts need to 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 arbitrarily decide, I really want toaster.eth, I'm going to take it back off you. So the registrar is similarly simple. This is a really simple registrar that replicates more or less the functionality of the existing name reg. 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 DNS, and that pretty much describes the entire technical implementation. The remaining component, 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 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 much better 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 the top level names? 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 McDonald's 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 plan on launching this towards the end of the year. About a year from now, we'll start accepting submissions for a permanent registrar, which we expect will be more complicated, more sophisticated. It will take care of things like abuse 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, and we want to be able to use those to build a better registrar. And then with a goal of about a year from there, I'm sorry, but these are slightly out of date slides, please pretend those are Vega and they're not November. We intend to launch the permanent registrar to replace the intermediate one. So what does the temporary registrar look like? It's an auction. Only names under .eth are available, so we'll only have one top-level domain with a goal of preventing collision with the existing domain name system. Names are auction off using a blind second-priced auction, which is also called a vickery 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 know will fairly hand them out. The existing bidder's deposits are held in contract accounts, and after six months you can delete your name and recover your deposit. Or once the new red 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. 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 Ethereum name service. I have about a minute for questions, but I don't think we're taking them. If you're interested in more, you can email me at nick at ethereum.org. Join the conversation at Gitter 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.