Unruggable Names: Trustless Resolutions of ENS Names | Lightning Talks #1

Transcript

B more history uh about NS Dow it's crazy to call it history because this program just started in January of this year um but uh we started uh in NS down what's called the service provider program where 3.6 million usdc was allocated to nine different teams that provide services for ens St uh in different wayes uh so one of those teams today is uh unrug which has been doing a lot of great work so give it up for a pray from un ruggable [Applause] uh hello can you hear me thank you so much um so yes I'll talk a little bit

about the work that we're doing at the rable I'm PR I'm the uh I'm a co-founder and CEO of mon rugal and um I've been in EN ecosystem since 2021 uh focused on open source uh development of the protocol and uh as L said we were funded this year to um work specifically on L2 stuff so we've been working on that and uh I thought i' also just zoom out a little bit and talk a little bit about my kind of broader vision for U what I'm calling the verified web Gavin wood is credited for web 3 naming web 3 and he said that web 3 is a centralized online ecosystem based on blockchain and when I asked directly

what is web 3 he said um less trust more truth I started to think that maybe there might be a need for a new term that is not so much uh internet based on blockchain but an actual complete end to end uh trustless verified internet and so I had this idea uh uh verified web and I went on to Google to see a little bit if there was anybody else using the term and I couldn't find any uh original sources uh but then I went on to um chat gbt and it also didn't have any um original that I can find but I thought it had a pretty good description of what it is it's pretty interesting that already had

a pretty good idea so I came up with a few principles um what is the verified web it's human readable I think it's important to differentiate it from say something like just blockchain just internet or just a network where proofs are are being generated uh because it should be human readable be something that we can actually use like the web um it should have Universal us profiles and uh everything should be proven end to endend it should of course allow for self custody and I think um the point number five is also interesting we should also try to improve upon the like the web 2 or the old internet where often times as an app developer you

basically have to take on existential risks in order to launch your app uh into obviously onto mobile and these are things that we should continue to strive for in terms of the text stack I like to say that uh ens is one of the four pillars of the foundation of the verified web and also web 3 but um of course we start with with cryptography and then we move with and also centralized storage and then I also like to say that tokenization is the killer app of blockchain but ens is an important piece of puzzle because uh it provides the the user uable part uh ens some people are calling it

now the everything name service because we do have a lot more options we can um put names off chain or we can U put things on l2s but uh e is actually a very unique um TLD in the sense that it is tokenized it will always be tokenized it will be trustless it actually creates a human readable platform for building the ver web in names are growing a lot this might be a bit of an exaggeration but basically we gone through 12 million names now and um if you look at the the list of projects mostly based on large subname projects um and only one of one of the subname projects on this list currently is actually uh using endan proofs so this is something that we hope

will change in the near future and gets into the work that we're doing and rable uh we recently uh released uh unable gateways which is a uh system a generalized system for taking the data from one chain and proving it down to another chain and we're actually using this to build out a network to support the resolution of enss names from l2s and uh we currently are are focused on uh first now name chain which I was when I was preparing this slides I didn't know what it would be called but name chain and building an optimized uh Gateway uh for name chain and also building uh for the uh reverse resolution that going be rolled out onto all the chains

a large task because basically for reverse resolution you do actually need to have a Gateway for every single change we also continue to work on research and development which is one of the things we were funded to do for the NS and I'm uh we've been focused on user data So currently I think there's a simple mental framework that we can use to um kind of just think about what kind of user data there is onchain user data and that is there are things that a user says about themselves and there's things that can be said about the user and if you see um things that users say about themselves are as well satisfied with profile you can put your auditar uh you can have your addresses but in the

category of things that uh can be said about the user it's much more difficult it's not impossible to actually bring currently to bring this data into the ens profile and uh so we working on something I'm calling uh Hooks and hooks is a uh resolution method that actually allows you to go grab this data and bring it into the ens profile uh I also call it resolver specific uh protocols and basically it means that a single uh resolver which could serve many many many names for example in base you have one resolver on L1 but it supports the entire uh Bas subnames and we can start to take uh make special text records for just bass uh in that space uh for

instance Bas has a developer score so you can actually have a developer score as part of a special text record that's just part of the base system and uh yeah this is my [Applause] slides all right any questions for PR and feel free to uh call out a slide number when we go back so for example b. they use like first resolution M2M probably probably because of ux reasons so like the state being cated from L2 to L1 like

takes like some hours um how you see that uh that blocker eving uh well it's not exactly that because basically um what you're talking about is finality and it is important to to think like okay when is particularly an optimistic rollups you know when is the state actually finalized using the the state region but at the same time being able to just prove the resolution um means that you have a verifier on L1 is at least checking the sa so it's not just asking the Gateway and saying hey what is this address you're trying to resolve an address and then the Gateway is just telling you to and you're just trusting it you can actually say okay at least it's public information that there's this state grou on L1 and we're we're verifying against this public

information so it's not exactly the same as finality it's a slightly different issue and I think that they could be upgraded to using um um proofs and and gateways and proofs uh and any actually benefit anybody else speaking about HS what he said it's the different than having a text record resolve right well Hox is a resolution method yeah that actually allows you to resolve text records uh for example you could resolve the uh number of delegated ens tokens on an ens uh profile and you could have text special text record that says uh delegated ens tokens as a

special text record and using hooks you can actually get that information in a verifiable way I got it it's kind of a macro you say like delated uh text for example rather some logic that gives you that number right yeah so the way you do it is it's delegations it's resolver specific so basically if you know the resolver you can say I want to get this text record I know this resolver and I will only receive results from this resolver and if if if if the name changes the resolver you'll be you just will know that you you won't resolve that so it's it's an interesting concept it took me many years to kind of just realize that it was just simple and we didn't have to worry about blocking resolver which is a huge problem and the the second difference is that desp text

record that returns just the storage dat hook can be add can be out right yeah the hook wraps the record so any record that can resolve the content record can resolve the hook it's just basically like saying I want this record from this smart contract and if the EM name happens to be using that resolver then everything is good and if it's not then we're going to uh we're going to like the client will know and it it won't resolve it and it happens to open up this huge world of onchain data because um all this information for ZK so one of the areas is that if you have ZK proof you're going to you're going to store a a record on but it has to pass a check through the ZK proof mechanism and in

that case you can have onto chain computation and you can actually say you know uh imagine you you want to prove that you're over 18 so you can say yes I am over 18 I can prove this and then you can actually resolve this off of the ens profile with a hook around the text Rec and the caller well the the client would be the one that's interested in this data for instance they would display it as some sort of Base uh verification or proof of personhood in your base profile but it just creates a unified W you don't have to actually go off to some other uh random location some new protocol you can just resolve everything through the enss profile but it can actually be on chain data not just uh the things that users say

about question um so the activity with the social gra do you support um can I only well social graphs uh are being built around ens GES so the question is is like I did actually a demo of of like using a follow protocol like Bran's working on to be able to say how do we get this information into the profile now if you want to do that through a onchain mechanism so it's not like oh just trust us you're going to have to

use some method and that that method I'm working on is called Hooks and it allows us to get the information and the reason why is because the ens name can actually change its resolver at any time so let's say you're resolving some information from another protocol you're hooking it in but all of a sudden then the user changes it and then spoofs it so then they can actually change it to whatever they want so that we had to come up with a new mechanism all right give it up for PR a