ENS Building the Verified Web - Prem Makeig

Transcript

[Music] good morning everyone yes so I'll be talking about ens um I am the uh a co-founder and the CEO of unrug and uh I'll be talking about building the verified web uh the term uh Gavin uh term web 3 was um coined by Gavin wood and uh he said web 3 is a decentralized online ecosystem based on blockchain and when I asked exactly what is web 3 he said less

trust more truth and uh I started to think that it might be necessary to have a new term uh to describe uh a slightly different internet uh and the reason why is because the inter interet is about to go undergo a uh a shift from largely user generated content to more so AI generated content and AI agents and this will probably take place in the next couple of years we'll actually have more agents more AI generated content than human generated content and uh I think many people have uh predicted that there will be a major problem and that is we won't really even know who the users are on

the internet anymore we won't know what the content is on the internet anymore and so uh started to think that it might actually be necessary to have a verification or a proof on every single interaction and uh I looked a little bit at uh this idea of what it's called the the internet of proofs or also the verifiable web Sergey of chainlink talks about the verifiable web he also talks about this problem of uh AI agents and synthetic content and uh just thought I would uh see what chat GPT said and I thought it actually came up with a pretty good definition says the verified web is an evolving internet Paradigm where trust is built into digital

interactions through verifiable cryptographic proofs allowing users to engage securely and confidently with authenticated content and services the verified web is an evolution of uh every web that's come before it and uh it it's not internet that is say you could imagine a uh agent to agent internet where everything happens opaquely I think it's very important that we maintain the uh human readable quality of the web I started to think about the uh principles that might build this type of new web and I think the uh first one

that's very important is that it's human readable we we don't want to have an internet like I said that's opaque to the humans even as agents start to take on more agency and more of the line share of of the traffic and I think uh for instance in open I came out recently with their their operator and you have this interaction where you can see what the agent is doing and I think this is very important to be able to observe what the agents are doing actually start to be able to learn and the internet should still be human Centric uh with the verified web uh the core idea is that there should be verifiability uh in all the interactions that take place so we need to have verified users we need to have verified online

content self- custody must always be possible and I think the distinction here is because I think a lot of users are not just going to always use self- custody but it should be possible for instance within coinbase you can move your funds in and out and I think that should be dis be a distinction in the verif web uh then in terms of just centralization I think it should be uh continuously moving forward uh I think we can see that basically web one was more decentralized than web 2 so I think we need to try to avoid that and always move decentralization forward uh largely in uh step with the decentralization of blockchains and the space generally and then we have to uh worry about platform risk I think this is

something that just should be improved about the internet in general uh when thinking about the uh verified web I thought okay what is the core technologies that go into the verified web and I would start with cryptography uh it it plays much more emphasis on the idea of cryptography and uh particularly I think that ZK proofs are going to play a much bigger role um moving forward with a verified web and then uh we have tokenization tokenization uh I think a lot of times you'll see people they talk about uh you know where are the apps with blockchain and I think the answer is that we we have a killer app and that's tokenization sort of like email like it was invented it works it still works

today and I think is true with with tokenization as well it's just going to continue growing uh tokenizing everything is is uh say killer app of blockchain and then of course cryptography is uh one of the pillars and then we also have decentralized storage uh basically it's kind of like data liveness if we're going to be able to uh prove uh our content we're going to have to have access to it and the question is do we want to move away from centralized uh actors to more decentralized and then we have ens ens uh sometimes is thought of more of as a project it's a way to uh take your wallet address and be able to um have a userfriendly

name but I think of En more as a platform and it's actually been uh growing a lot recently uh We've looking at uh particularly through name services like lanaa and uni and base these are all added uh hundreds of thousands of names to ens and actually you can see that it's in the last two years all this growth has happened uh largely because of a of a technology that was introduced called ccip read or 3668 uh ERC 3668 which allows for the idea of starting on layer one and then going to Layer Two or to uh say offchain and uh the only issue with that

is that in this uh list of names there's only one that's actually still on blockchain and also fully Pro and that's lanaa they've actually created a system where you go from layer one to Layer Two and and they have a fully proven endtoend system whereas Bas and uni are still offchain or uh Bas is actually onchain but it's uh used as a trusted Gateway U this gets into a little bit of the work that we've been doing at un ruggable uh we built un ruggable gateways last year and this complement ccip read and the way that it works is ccip read is basically the uh protocol or or the standard that allows you to go from uh main net to layer two but the

actual standard for the proving is unrug gateways and un ruggable gateways basically takes the um data you get from nl2 and brings it back to L1 and actually verifies the data in a standard way that that works across many blockchains uh here's basically how it works uh the client uh which is a wallet would initiate a uh uh a resolution request it would go to layer one and then it would check and if if it doesn't exist the name doesn't exist on layer one then it would uh redirect to a Gateway which would check the layer two and then the layer two uh would actually uh the the client would actually

retrieve the data from the layer two ens uh generally works it's sort of killer use case in the last few years has been uh to created a onchain profile and this idea of having a universal profile is also sort of an important idea uh in the verified web because we know that currently with uh profiles we have the idea that you set one up on every single service or every single app like you have your Gmail and you have your yaho and then the question is how do you connect all these together and it's a big mess so I think most people think that you should have one profile it should be cryptographic it should be onchain and ens actually works pretty well for that but I think there's a

mental framework that we can have and the mental framework basically is things a user says about themselves and things that can be said about the user and right now ens is pretty good at creating a profile about things that a user says about themselves and that is like their Avatar record it's their um their addresses their wallet addresses they can also have text records and these are all records that they can change at any time but if we focus more just so on the uh things that a user can things that can be said about a user we have a whole world of data that starts to uh come about associated with the user and those are things like

credentials so if we imagine that you uh get a University degree and when you get the University degree the institution signs your your transcript so you have all this information about yourself from the University and then let's say you also have a passport which has all the information about where you've traveled about your uh residency and then let's say you want to create add something to your uh credential your profile and that is basically to say I would like to tell people that I have a University degree and that I've lived outside the country in a foreign country for more than a month and this is something that you would actually like to communicate about yourself and have as a proven credential and then that's where ZK comes in

because ZK basically you can think of it as a way to uh do compute over signed data and also has this privacy preserving uh property uh base names have a similar system where they have this like badge system and I think this is maybe a way that people could imagine building these uh Rich data credentials uh profiles and in this case they have this idea of an online Builder score well it's it's a builder score that actually can be put on chain this is the talent protocol that they work with and it sort of looks at the uh history of your wallet activity and uh starts to build

this score uh currently this protocol exists within Bas or within Bas nam's website and it's not it doesn't actually travel with the ens name so one of the big challenges we have with ens profiles is the idea of having a universal profile that travels anywhere across any chain and is is UN uniform so basically what is possible is this idea of having specific protocol level uh features for each of the different profiles so this is the base uh names and it could have its own let's say base IPS base name IPS that could say okay we have this Builder score and we'll

include this as a text record in this case it's e.b. Builder score and this would be able to be embedded directly into the ens name and travel when person uses their base name on a different chain say optimism um but what this really uh necessitates is well let me me just go back for that sort of thing to happen it's actually currently not sort of possible or very difficult at the moment and the reason why is a few things so so number one we have the problem of a uneven security prop uh security

property for all of the different types of ens names so originally we had uh L1 names on for ens and L1 names have a uniform security pro property and that is basically vitalic it's on L1 we know where it's being resolved from but as soon as we bring in all these other name Services we actually have this uh uh unequal security property for instance uni. e names their subnames they're actually just running off of a server I assume they'll move it to UNI chain uh in the future but right now it's just a trusted server that allows you to resolve the name so we don't have a good sense of of what are all these names their security properties are the other problem we have is the fact that every ens name has a

resolver and that resolver can be changed by the user at any time so if there are these onchain records that are that are wired up to check an onchain record or check an attestation uh on the ens name if the user is able to change the the resolver at any time they can actually spoof the record so that's another issue and then I think the final issue which is another big issue is that because you have this direct wiring between the client and the layer one you often have clients that are either out of sync you have libraries that are out of sync and you have le uneven uh U implementations of ens and and as an person in the enss community I often find it frustrating that every single dap I go to or wallet actually implements ens

differently so what we're currently working on at unrug is building this new layer uh calling the metadata layer and that would basically help the client say the wallet to uh understand the security properties of each of the ens name services and it would also provide this kind of locking functionality the Locking functionality uh basically is a heads up to the client that would say this resolver has been changed in the last 30 days this resolver has no audits but if it's a service that the the client is happy with that the wallet is happy with it would kind of say the opposite it would say this this resolver is you know lasted a long time it has Audits and then the clients really get to decide how they uh which names they resolve and

which names they don't resolve or they could show warnings there's just a lot more um that they can do and it provides this ability to provide zkb test stations and ZK uh and just onchain data in general as part of the traveling ens records okay ended a little early but um anyhow so let's I guess we can open up for questions [Music]