DappCon 2023: EIP-3668: Cross Chain Interoperability Protocol - Muhammed Tanrıkulu

DappCon 2023 · September 2023 · 22:32

ENS's Muhammed Tanrıkulu presents EIP-3668 at DappCon 2023, a cross-chain interoperability protocol, often called CCIP-Read, that lets smart contracts fetch and verify off-chain or cross-chain data on demand. The talk covers how ENS itself uses the standard for cross-chain domain resolution.

Speakers

Topics

From DappCon 2023, hosted by Dappcon Berlin.

Transcript

I was just thinking about like how I'm going to present everything but he just explained everything so I don't know what to say now so uh today I'm going to talk about the CCI period but before that I want to just introduce myself so I'm Muhammad Tulu uh working in ens as a fullstack developer so what I'm doing there is like uh like pretty much everything basically the integration the protocol the the governance tooling and uh infrastru structure and uh this is my the most favorite handles like the T which is my surname and muhamed is my name and these are the cards that we are printing for like

whenever when we go to the events we are just printing this cards these are like a business cards NFC cards so you can just you know like have your own PP inside and just use it as a business card uh and today we're going to talk about like what isnn what ccip read does and the key components and the use cases of the ccip read and uh maybe let's first start with like what is ens uh I don't know like how many people knows about ens how many people have ens here okay like it's quite a lot but still I would love to see more so the the ens is one of the key component on

top of ethereum but it's not only for ethereum uh it's basically uh fixing the the ux problem on etherum because the thing is uh like everybody has like some you know interaction with the wallets and you see that you know like there's this alphatic characters they are like super um how to say confusing and also Hard to Handle because the you know like when you try to send some amount of token you always have to check go back again again again just to be sure that everything is correct so what ens does or how it started as an idea basically it handles these alphan numeric characters for you and you are able to register your uh handle on top of or

like on chain and whenever you do a transaction or you want to do a transaction uh the the wallets that have like in in the current ecosystem though like maybe 90% of the wallets are already resolving those names to those address addresses so you don't have to remember anything about your address and uh which is how the ens started so it's just basically uh as it's written uh is a distributed open and extendable uh naming system based on etherian blockchain and after uh we realize that is is actually has like much more potential because it's just like a DNS and it can not only keep your the wallet

addresses it can only keep some information about you some metadata like it can be your um I don't know like for example uh social media handles email addresses some like information about you like your avatar and everything so ens at some point becomes your web tree profile so whenever you interact with any decentralized application you don't have to provide this information again and again and when you connect your wallets the the all the decentralized applic s integrated with ens retries those informations and creating a profile for you and this is another use case and the third use case is basically it's just like a traditional domains you

are able to put any content under any decentralized uh storage system and then mapping this to your name and any browser which is supporting ens uh going to host your website in a decentralized manner is going to be more censorship resistance and uh today's topic so is a CCI perod cross chain interoperability protocol and the read means secure data retrieval uh so uh this part going to be a little bit different because what what I was thinking and when I'm like how I'm going to tell about going to be like a

little bit how to say like complicated so I I will just try to simplify it uh the the ccip read protocol uh crafted by the uh the founder of the ens n Johnson and uh if you go to the e or ERC uh 3668 you will find all the information about it and why we needed that uh first maybe I should start with that so uh we have this problem that uh like most of the users were complaining especially nowadays uh you know how the gas fees are high when you try to do transaction over ethereum is always a problem uh like

especially when it comes to ens because like you are trying to register your handle and it's just like $5 amount of in ethereum token on top of that you are paying a gas price which is doubles sometimes you know like triples the amount which is not good and it's not only that uh also when you try to put some information on on top of ens this is another transaction so like the people were just basically saying that like okay like it's fine it's cool but at the same time the cost is amazing so we were trying to handle this problem and uh we were like the first thing came to our mind is basically like how can we do that in a efficient way in also trustless way so we were checking

the ecosystem you know like if there's maybe some already you know like someone solve this problem so we can use it and the first thing as a solution came to our mind is maybe like let's move some of the stuff from L1 to L2 so like the gas is cheaper so we don't have to worry and there's also some mechanisms to check all this like uh the verifications like Miracle proofs and this kind of things like the that or the storage proofs let's say uh so yeah the first question was uh without clients having to know how to query every L2 how we going to do that because yeah like there are a lot of l2s but at the same time like we have couple

of clients like for example in JavaScript like ejs WM or wagi or some others and for each of them either you have to go and you know like learn about all these l2s and just try to create some implementation and you know like contribute to them which going to be super super uh complicated so uh the second question is we shouldn't create any other additional trust trust assumptions because we already have a lot of problem with the trust you know like the trust environments and stuff so if you put something more on top of that it's not going to be easy uh and the another thing is uh without any L1 comments on update so yes

we want to have l2s we want to scale we want to give a better option cheap option to the users but at the same time uh we want to have like some like one source of Truth so it's not that just easy to just put your information in L2 and just retrieve it and everything is perfect because this is how our protocol works it's just going like in both ways basically and we said that okay we shouldn't do any update on L1 because otherwise people going to pay pay gas is nonsense and without any transactions on query so it's more or less the same same like the ens as a protocol is more rely on reading not writing so you are

writing once maybe but then when you retrieve your data or some other decentralized application retrieves your data they are literally just going to the blockchain and querying about the things and it's more about reading so we shouldn't have any transactional query and without hard requirements on the L2 capabilities so the the this actually connected with the trust thrust assumption so or maybe a little broader uh we didn't want to add any additional requirement to any L2 to to provide all these things so this is our problem it seems not that easy and uh we start to check the uh ecosystem and we were like okay like

what we can do about that and first thing we found is uh okay like there are bridges already between the L1 and L2 so you can just you know like move move the assets from one to another or if I simplify how it works basically you have a token in L1 and you go to L2 and tell that you know like I want to just switch my tokens here and your token is locked in L1 and you get a NE clone minted in the L2 and using it and if you want if you want to go back the same proceder reversed so you are burning your to clone token and your token in L1 is unlocked and you using it so is this useful for ens absolutely no because as

I said like we are more like relying on the read in the protocol level so which means that we cannot just clone things and just assume that everything going to be fine we should be available in everywhere at the same time so we should have some sort of solution for sying between the chains and then we start to Deep dive into this uh solution like okay there are Bridges maybe let's see how they are working maybe we can find some part of it you know going to help us and the we came to conclusion that okay there is this message passing now we are in somewhere like the message passing is

basically the how the token like when you have the the breaching basically all this communication going through the message passing between the L1 and L2 and this is basically either uh the like SED messages or attestations uh yeah attestation is a better word I guess so uh we thought that okay like maybe we can use that but it's still not really solving our problem so we deep di a little bit more and uh we like one of the Primitive part of the the message passing was basically uh the verif verification of the uh data availability in the the chain stor

so basically uh when you try to retrieve some information from L2 uh you use this you know the bridges to basically just go from one to another and in there there is something happening basically L2 tells that hey I have this you know like information like I have this token here and I can prove that it's here and if I show the proof and if you are able to verify you can just let user to use inl1 so you can unlock the token so we thought that okay this is a good great idea we should start with that and uh in here I will just quickly just if you don't look I'll just quickly pass

everything because I realized that I did a mistake putting uh my slide in a way I just wanted to show this first so uh what we came up as a solution is this and what is this so this is CCI period and how it works what it does so there are three components you see here and one of them is the client is basically the the the libraries that you are using like SGS wagi and others and there is a smart contract that we want to interact and we created a specialized server which we call as Gateway it's a Gateway because anyone can just run it it's a

it's a kind of trustless and uh what we do in instead of the regular bridging or message passing we do this or like anybody who can use the CCI read can do this so you are just like or your client just calls the smart contract just like any other smart contract call so it's just some function and in the regular uh etherium applications what happens if the the chain has this information it's just returns to return data but in our case we are returning a specialized error instead of like just a rever because we don't have this data in L1 what we do we

are returning an offchain data and this offchain data has some information which is uh like sender uh at this point is not really necessary the Gateway URL which is super important so uh let's maybe put into a word like sentence so you are asking contract that do you have this information and the contract says hm I don't have this information but I have information that you where you can find this information and then it sends you this offchain lookup error or to the client and client understands that gets the URL asking to the Gateway okay like I need this information the contract told me that you have this information and then

uh later the Gateway just checks this sources it can be either offchain or onchain and in our cas case it's L2 and it goes to LS2 and says hey do you have this information yeah I have okay I will get this information from you and then I will get also the Merkle proof of that and then it gets the Merkle proof and it gets the uh the information and in offchain data uh error we have one other parameter which is called cback function it tells that I mean the contract tells that hey you're going to go this Gateway you're going to get the information but later you're going to come back to me with that information I will resolve it

for you and then we are getting the information in the Callback function we are just checking the Merkle proof if everything is correct and then if it's correct we are just returning the result from the contract in L1 and you didn't do any right operation in L1 so there's no gas cost and later you are just using the answer so this is the like most basic version of how I can tell how ccip read works and I want to go back just a little [Music] and just how it helped us I just want to show it so in our case uh the ens works just like this you have an enss name and

then when you query the name it tells you about yeah like I know this name it is registered and this ens name has a Reas resolver and resolver is a contract like specialized contract basically keeping all the key value about you whatever you want and then uh what it does basically uh which like which field you ask is just retrieves so if it's if you are asking about the address of this name it it retrieves the address if you are asking about the Avatar URL it retries that and now I'll just show you like how we how did how we did use uh in our case so this is you this is our contract and you are asking hey I want

you to resol one address because I want to send some nft because I'm a nice guy I just want to you know like I love gifting so you just asking about tacle do.com doeth and in the regular contract uh scenario it just says nope I don't have it and in the CCI IP read scenario nope I don't have it but I know I know where it is and then later it goes to client client ask the ccip read Gateway and based on the scenario either offchain or on chain it's just you know like it just does the thing basically retrieves the

information from wherever it is and then retries back the proof and the information to the result call back function and the result call back function tells you yes this is the address and you get the information in the L1 level uh so CCI period and uh this Gateway is a little bit different uh I just want to quickly mention about that so there are two types of uh Gateway interaction at the moment you are able to do and those interactions has some limitations uh the offchain interaction it may require an additional verification mechanism which you can verify on

chain uh and it's not that easy to find the use cases but they are definitely there and we are using it actively and the second thing is data may not be publicly available if it's off chain so if any company using that that they can just you know like have some sort of like private database and keep all the information there so you will not be able to uh the query all this information uh and in the onchain interaction way it's not free in in offchain it is for sure free it's just some infrastructure some you know like company keeping um so these are the disadvantages

and yeah this goes Super complicated I will just briefly tell about what it is basically the recently the wiik uh posted one blog post about all this uh the C CP read and how ens can scale and this is basically italic stake from how we can implement the uh the L2 resolver on top of enss so it's when you see the pattern in is like more or less the same it's just uh like bunch of interaction with the contract and then going back to the L2 and retrieving the information and getting the meracle proof as I

mentioned and if you need to like if you want to to read it's just Q code is there for it and so something more familiar uh like if you ever interacted with the coinbase or lens or Argent before you are already familiar with the subdomains or how they provide handles to their users and uh our ultimate goal is basically scaling to l2s and providing those uh projects to keep all the records in other other layers basically and uh the Argent was the one of the first company the the providing

the handles for the ens users or the to users as a is an ens name and but they were doing one chain and right after the the gas prices went high they just had to stop giving the handles so it was super hard for them and for coinbase it's completely different if you ever interacted with their wallets they are just offering free subnames for you you are just getting a handle so in their case they are actively using the ccip read of chain and basically the keeping all the data for you and for the future they are probably going to use their base layer and I think I am out of time so I

just wanted to mention that uh we are using activ lean in other places like the DNS and some other uh technologies that we have to cause uh like reduce the gas cast for pretty much anything in ens so soon you will have more options to uh interact with ens without dealing with the gas prices that's it thanks very much we've got some time now for question questions and if there aren't any maybe I'll say I hope that this CIP oh and

there are some yeah in the example you shown before with Bas and lens Etc um uh subdomains were given all chains and the main domain was on eth mhm is it also possible with that that you have subdomains spread across multiple um l2s and L1 so you have one subdomain on L1 and another one on L2 so uh this is right now like in the debate phase I would say because uh like where we are at the stage of you know like scaling we are right now developing the L2 resolvers to see how we're going to incorporate with this all the sying and the things so uh either we will give an option to

users to move their names from one to another or or you will be available in everywhere so this is still not yet decided uh but definitely in the scope okay thanks do we have any other questions okay well I hope this means my ens name will become available on more than one network yeah we're hoping to nice let's thank thank the speaker again and