ENS (Ethereal Namespace)

Transcript

so uh I'm Ryan and I understand this is being live-streamed so if any of you watching at home have any questions or comments feel free to tweet at right pdx and i will get to those as soon as i can so we've decided to be the ethereal namespace maybe someday we'll be the etherium namespace that would be great i'm a dev with nexus and in the process of working on the maker stable coin and crypto currency leverage platform we decided that we needed to make a smart contract package manager we made that we

called a dapple one of the design goals of dapple was to provide a node package manager like experience so people could install and publish packages by their names under username namespaces so to accomplish that goal we came up with the system of smart contracts that we call the ethereal namespace essentially it's a hierarchical permission abal name reg so this is the name reg interface as it stands and it allows you to map addresses to names and names addresses

and it's great for a lot of purposes I use it myself and usually I end up with something like this where I'm just mapping strings to addresses but if you have data that looks kind of like this that's somewhat hierarchical it's not such a great fit now you can naively store data like this in the name reg contract you can do this and just have path strings mapped addresses but there there's a drawback to that which is first of all there's a conceptual gap between users mental model of how things should be working and how it's actually implement it and usually with good design you want to

minimize the gap between what the user hal user thinks the thing works and how it actually works because the greater the gap the greater the abstraction tends to leak so that's one problem with it another problem with this approach is that it kind of becomes messy and difficult to try to set permissions on sub paths right because now you have this this big name reg and you have to parse each sub path and do all this stuff to deal with permissions on sub paths so something like this is a much better fit for hierarchical data I don't think I have to argue that one too hard to this crowd so this is what we basically tried to to make now my initial approach to it was to just

chained together named reg contracts and it technically works but again there are a couple of drawbacks number one is there's a nonlocality of information here if I am just interacting this name right contract here I'm getting addresses but there's no information within this name reg system to indicate which addresses are pointers to name reg contracts which addresses are basically pointers to sub trees and which addresses are dis addresses so that information has to either live within the application that is interacting with the name reg or you have to do some sneaky things to try and divine if this address is pointing to a name wreck the

other problem of course is that there's no standardized way of setting up permissions on these these name break contracts so you end up potentially with a lot of one-offs maybe some things that don't quite separate concerns well enough so to resolve the first problem all of our getters and setters on re NS app interface return and accept a boolean called is linked and that explicitly defines whether the data stored at a particular path should be considered a pointer to another node in the tree and the second problem of not having a standardized permission interface we just solved by making a

standardized permission interface we call a controller contract and you can set those on any node in the tree so this is roughly what our code looks like right now this is just a UML diagram and you can see there are two distinct structures the one on the left is governed by the NS app interface on top and that is what you'll be interacting with most of the time it lets you get and set values in the NS tree using paths and the second structure you only use if you're setting permissions on a node I'll dig into these in more detail

over the next few slides so this is the interface for the ens app contract and you see there's a getness set function you also notice that on every function we have a boolean okay return value we found that was necessary because sometimes functions return knolls if there's a failure mode there are certain failure modes that return null and you need to be able to differentiate between real valid null values and a failure mode right so if the boolean ok returns true or is true then everything went through ok if it's false then any null values gotten back are not valid and you

should figure out what's going on and fail gracefully so get takes a forward slash delimited path and returns a bytes 32 value it returns are is linked boolean that we talked about earlier and returns the evo k boolean set of course takes a path the value in his link returns the ok boolean and those are what you'll be working with most of the time of course claim no you only be working with if you're writing a controller contract controller contracts call this function DNS app sets the controller contract making the call to be the controller for the node that it sets aside in the tree for that controller and that it returns that

nodes ID the controller contract can then build out the sub tree as however it wants and it can set the position the path for that sub tree in the ens tree using the set function it passes in the desired path it passes in the ID of the node as a value and it sets these link function or boolean to true and then we have the node get node set functions which are just ways of saving on look up costs you can look up you can look up values on nodes you can look at values relative to nodes and set values relative to nodes and then finally the get controller function which simply

takes a node ID and returns the controller contract and that was a bit of a data dump so here's a kitten take a take a breather all right we'll jump back into it in three and two and all right and this is the ens controller interface and the only thing that interacts with the NS controllers is the NS app so when you're writing any nest controller you need to make sure that's permission that only the NSF can interact with those two functions it takes a node an address that's the caller of making the request to set or get the key and the value that should be stored as well as the this link boolean and it should return false if the caller either doesn't have the right

permissions or if the requesters doesn't make any sense for the given path so to make your life easier we've implemented a couple of controllers for you guys to look at I'll go over these very quickly because I'm running out of time I this is the standard registry controller and it's simply a first-come first-serve zero fee controller if you look above set and get the new registry function is what you'll be using to set to request some notes from the ens app and get back an idea that you can then set using the set path method that we talked about earlier inset and get of course set and get values and transfer

above the ens set and eunice kit allows people to transfer ownership of nodes between each other nens at indian escape we of course talked about earlier so all of this code is published at github com / nexus development / e and s i don't know if you can see it on the bottom there that's all right cool and we're looking for feedback looking for pull requests obviously with the system like this the more people using it the more valuable it is to everyone if we have a common ens app implementation then it helps with discoverability and we've been trying to figure out how to make it happen so we'd love some feedback get in contact with us some of the things we've

been kicking around if maybe a token system for registering tlds maybe an auction system so if you want to be part of that process please you know talk to us tweet at me email us we have a github we're fairly easel easy to stalk so you know you can get in contact with somehow if you have any questions or comments again do we let me or if I'm eating one of the brakes thank you very much you