Durin: L2 scaling for Ethereum Name Service - Nick Johnson - [Toronto Ethereum Developers Meetup]

Transcript

cool uh so uh yeah i'm nick johnson um founder of the ethereum name service uh and i am uh apparently sorry about that uh going to give a talk about durin our l2 scaling solution both for ens and in general can everyone see my screen yep i can see your screen excellent uh so um i'll give a very brief overview of how ens works since it's necessary to sort of understand uh what we're trying to solve um an overview of the the problem we're trying to solve and then go into the

proposed architecture for jiren no demo today unfortunately and then some information about our next steps so first of all a quick glance at how ens works uh ens's basic job is to translate uh long obscure machine readable identifiers like ethereum addresses into short human readable identifiers like names so instead of having to tell somebody your 40 character ethereum address you can just tell them your 10 character name none of this i mentioned is particularly news to anyone here at this point um ens is hierarchical so it's a tree structured and arbitrary depth so at the

root we have top level domains such as dot eth uh underneath we have second level domains like inigo montoya metamask oracle eyes wallet neck etc and the owner of a second level domain can create sub-domains and they can create sub-domains and so on and so forth without limit the ens architecture is fairly straightforward we have the ens registry which is a single central smart contract that contains a mapping from every single name to the owner of that name and a resolver responsible for that name resolvers are smart contracts that handle the work of translating a name into some other resource like an

ethereum address a text record an ipfs web page and so on and so forth the process of resolving a name in ens is also reasonably straightforward the user first asks the registry which resolver is responsible for the name i care about and it responds with the address of the resolver and then it goes off and asks the resolver what the address of that name is or whatever other record it's trying to resolve and the uh this layer of indirection allows for a lot of flexibility the registry isn't upgradable and it's uh used by everyone but it's also its sole job is to provide a redirection to the resolver resolvers are user specified anyone can design and

deploy a resolver if you want to define a new record type or if you want to find a new way of updating records or a way of returning them and calculating them you can do all of that with a custom resolver without needing any centralized permission to update ens so most of the innovation in ens goes on in resolvers where it goes on in contracts that are responsible for issuing new domains which we call registrars so all of this ens so far is reasonably straightforward but it has the problem that all the ens data both resolve the data and the registry you know resolver addresses and owners has to be stored on ethereum l1

and that means significant expenses in terms of updating records because everything requires an ethereum transaction so we want a way to move all of this to an l2 and an easy sort of cop-out solution would be we pick an l2 like polygon or optimism or something we move the entire registry to it and we say bristow with salt scaling just go use polygon or use optimism or whatever we've picked instead the problem with that is that we think it's much too early to pick one particular l2 is a winner and we also think that like ens is basic infrastructure as far as we're concerned

it's uh designed to work uh for for anyone and we think that picking a single l2 as the sort of solution for all the vns is probably the wrong approach so what we really want is a way to store and query ens data on an l2 uh such that anybody can take their part of the e s tree like if i own nic. i can delegate everything under nic.ed to the l2 of my choice um and so we want we have a few sort of hard requirements for that uh clients uh like ethers.js web3 your wallet can't have to understand every single l2 it's a non-starter if we're going to require every wallet to integrate every

single l2 in order to resolve names or if we're going to have a situation where certain names aren't resolvable to certain people because their wallet doesn't support it so we have to have some way to resolve the name without the client knowing specifically what l2 it's on we don't want to unnecessarily introduce any trust assumptions so where we have an l2 that is trustless in the sense that it is rooted on ethereum and you know uses uh existing uses ethereum for its security the ensl ii solution shouldn't introduce any additional trust assumptions like say a consortium of signers or something like that we don't want to have to have any uh

commits to l1 when updating records because of course that's part of the whole point is to avoid that and we can't have any queries on either l1 or l2 for uh sorry any transactions on l1 or l2 in order to do queries it needs to be all purely costless read-only uh features and finally we don't really want to have any hard requirements on the l2's capabilities like enforcing that it must be an evm based l2 or anything like that we want to be as general as possible um and this seems like kind of a tall order but starting with a sketch that vitalik outlined about six months ago and moving on from there

we have an architecture that we think does this very well before describing exactly how it works it kind of helps to look at how existing l2 integrations work so how is communication handled between say ethereum and optimism or any other l2 mostly they're they're structured around a different interaction model than what we want because they've been mostly been built with things like moving assets in mind rather than just communicating data so at the highest level most of the existing integrations you see either but with l2s or with side chains or anything like that are some form of token bridge you you go to an interface you say

uh you know i want to transfer some tokens from ethereum to polygon or whatever or to optimism um and it does some series of things under the hood to achieve that uh and this doesn't really match what we want to do with resolution at all so we sort of look at the next layer down what a token bridge is built on how do they function and typically they function by message passing so for instance when you want to move some tokens from optimism to ethereum what actually happens uh underlying the bridge is that when you say send the tokens a contract on optimism burns the tokens and it emits an event saying user x burned 100 tokens to to send them to this address on

ethereum and then some process out of band grabs that event and it submits it to the ethereum chain along with the proof of uh what happened uh sorry along with the proof of that event the fact that it was included in the optimism chain and then a contract on ethereum verifies that proof and once it checks it's valid it issues or unlocks the corresponding number of tokens on l1 so this is closer to what we need but we're still talking about sending transactions on l2 and l1 and what we need to do is just extract that proof information without the message passing so underlying the message passing the basic primitives that all of these bridges

build on is basically prove to me that this happened on l2 or vice versa that's happened on our one depending on on the direction and now this is a primitive we can actually use because if we can prove uh the contents of a smart contract on optimism to an ethereum smart contract we have a way for that contract to to verify the data returned as valid without making any transactions on either one and it also allows us to reuse existing message passing bridges and and other technologies uh by taking their libraries and using them for our own purposes so

this is the the high level sketch of how our uh how during our l2 query functionality works first off the the client starts by querying uh the contracts that they originally want to query and normally that would just return the data directly but in this case it's going to revert within an error that includes a gateway url which we'll describe in a second and a prefix and so rather than getting a return value they get if what effectively is a revert message and thanks to solidity's recent upgrades this is a machine readable thing rather than a human readable string their client then gets this revert

message which it was expecting it might and it extracts the gateway url and it goes off and it queries the gateway url using json rpc over https or a websocket or whatever suits and the gateway here is a process that was set up in conjunction with contract and its job is to query whatever the l2 in question is so this could be uh optimism it could be actually something that isn't even an l2 like a merkle tree for instance uh in any case what it then it then gets queried by the client with the exact same query that is originally sent to the contract uh and it decodes this call and interprets it according to its own

logic so for instance if it's a gateway to optimism it goes off and it queries optimism and it gets the data back and it also generates a proof so in this in the case of optimism for instance it gets the data and it also gets a miracle proof that this data was part of the state of optimism at blockx and so then it returns to the client their data and proof and this is entirely opaque to the client they don't have to know what the proof looks like they don't even have to know how it's structured all they know is this was returned by the gateway and i should pass it back to the original contract that started this whole process and before doing that though they check

that the return data starts with the prefix that the contract said it would and this is for basically it prevents gateways from giving honest answers to the wrong questions if they could return anything they like they could return a response that is is valid but is actually an answer to a different question than when you asked so you could ask uh what does nick. resolve to and it could return with a response that resolves uh fubar.eth and the contract would not knowing any better say yes this is valid but this prefix allows us to ensure that it can only answer the question you asked and so finally the client has this data returned by the gateway and it passes it back to the original contract that started the whole

thing and that contract implements a verification function of some kind so again in the case of optimism what it does is it unpacks these merkle proofs uh it goes off and it calls the optimism contracts on l1 and checks the uh the recent state routes for that and check that the proof is rooted at one of those state routes and if everything verifies correctly it finally it returns the result uh to the original client and so this little three-step process is actually extremely generic like it's useful for ens but it's also useful for anyone who wants to be able to do queries to l2s or to external systems as part of a smart contracts call either just for a

call or for a transaction and fetch additional data in order to validate or produce that call so examples of other places you might use this include things like token airdrops where you want to go off and consult a merkle tree and generate a miracle proof for your individual part of the airdrop or token bridges to l2s so for instance in principle with this you could make a call to unlock a token from an l2 just using a single transaction on your ethereum l1 contract with no need to connect to an alternate network and so forth um so does it solve our problem uh

there's no additional trust assumptions uh or at least they don't have to be so if you can if you have an l2 that can verify itself using smart contracts on ethereum you can also use that same infrastructure to verify the messages returned from the gateway in your smart contract but also if you want to build something simpler you don't want to deploy a whole l2 you can introduce trust assumptions that's entirely up to the client so for instance suppose you just want to be able to update your own name without lots of extra overhead you could deploy a custom resolver that uses jiren and just signs any messages with its private key and then your resolver your custom

contract there would just check that the message was correctly signed before telling the the client that yes this is the correct resolution um the system doesn't require any commits to l1 on update because uh commits go to the the l2 which then uh updates the state route on on ethereum as part of its normal process uh there's no transactions for queries uh clients don't have to know how to query every l2 all they need to know is the protocol for interacting with the gateway and the gateway has the same protocol regardless of which l2 it's speaking to and there are no hard requirements on the l2's capabilities so if you're interacting with something like optimism your

resolver on optimism for ens for instance could be very sophisticated and it could have all manner of application logic but you could also store your resolver data on a simple sort of dumb data storage chain as long as you have some way to prove its state back to ethereum l1 then that's all you really need and as i've already alluded to this this works for more than just dns you can use it with any external data system all you really have to do is build a primitive that provides a way to fetch the data and then verify it inside a smart contract so it can be used in any application that needs read access to l2s i suggested a couple of examples earlier

another example is that with this you could have an erc20 token that reports balances that match whatever they currently are on another system and you'll be able to fetch that data transparently um it can be used to even build custom l2 to l1 bridges so there's the possibility here that as long as your web3 library such as ethers supports durin you can transparently query and fetch data from from other systems and include them in ethereum transactions without uh your wallet or anything having to be aware of which l2 it is and yes so that can be extracted away by web3 libraries so that the coder doesn't even have to be aware

whether the contract they're interacting with employs this patent so our next steps first we have to standardize the query protocol i described and we've just started on work for that uh with e3668 uh which is a system for uh sorry which specifies the the basic query protocol and how that functions uh second we need to specify how ens uses jiren and then includes some other changes that i haven't really described here like wild card resolutions so that you can delegate not just one specific name to ens but actually the entire sub the entire subtree so you can delegate nick.eth and every sub-domain

will also be looked up on that system uh we need to start building libraries and tools for implementers to use so we don't want different have to write a gateway from scratch we're building a gateway construction framework so to speak and updating the ens libraries to use it and rolling that out to as many wallets as possible so if you're interested you can join us we have a twitter uh we do a lot of discussion or intend to do a lot of discussion over the solution at discuss.eds.domains and on our discord which you can find a link to it ens.domains there's the two eaps that i alluded to in the previous uh page 3668 and 3672

which we would very much uh value your feedback on uh and also if you're interested enduring for your own applications that are non-ens related uh we would love to hear from you as to whether it solves your requirements and whether there's any changes we should make in order to uh to better to support it so that's all i have for you today does anyone have any questions