ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval by Julien | Devcon SEA

[Music] he sorry about this okay hello everybody thanks for being there I know it's the lunch break so thanks really for for being there so my name is arur I'm a product manager at Linea and so like today I will be talking about YC 30 3668 um so yeah let's get started basically the agenda is quite straightforward I will explain what it is uh why do we need it right um and how does it work the use cases behind it and I will spend some time uh talking about the cool integration that we did at linear to benefit from this standard so maybe to set the context let's just talk about how we can access external data I think most of you knows but natively right a chain cannot access data from the external World whether it's over chains or the web but like over the time we build some other protocols that solve those problems so the the main one are bridges right if you most known to if you want to bridge assets so coins nfts but there are also message bridge that let you send a transaction on chain a and it execute a transaction on chain B um there are also oracles that are well known for like price feed most mostly but most recently they have creating more generalized implementation such as like chain link functions and other and lately we have also uh co-processors that are uh enabling those kind of use cases um so the question you might ask yourself is okay why do we need another solution and basically ERC 3668 uh also known as a CCP read was a standard proposed by the ens team especially Nick because they had like unique use cases where they wanted to um access um the information for L2 especially for managing like domain name in a with cheaper like gas cost but uh the they have some constraint and the design is reflecting that so the first benefit is that it doesn't require any trans transaction to send on chain compared to over all the other solutions that we mentioned um so this is more efficient in a way if you don't need to store the data on chain because you don't have to pay the gas cost you also avoid external depend dependency sorry on external prod protocols because it's an ERC and it's uh like B on top of the protocol but doesn't have those dependency and extern additional trust assumption as well so let me tell you a bit how it works there is three part to it um it starts with the client and here we are not talking about execution client or consensus client but more like the uis or like backends that are calling the the blockchain and uh like the client will uh call a smart contract right standard if call to to get some information uh something that happens quite generally and the main um part of the design from ERC 4668 is this uh allows the contract to revert with an error that's basically tell the client actually you need to give me a bit more data so that I can do my job so uh at this point so the client will uh add the job to fetch the data on a Gateway so a standard HTTP call and uh of course the Gateway will send the result and then you the the client is uh like giving back the information to the contract uh through a callback function and at the end of the day you have an answer so here I talk about call but actually the call back function can be also sent in a transaction so that means that at the end of the day you have some logic that can be executed on Shain in a block um the nice thing about this design is that if you look at the offchain data um error there is all the information store on there there to uh explain to the client what he needs to do so in advance the client doesn't need to have any information about what what are the gateway to call what is the information that I need to send to the Gateway which is the call data uh or what are the Callback function and so on so this mean that the client can have a standard implementation and you don't need to integrate each time like a specific use case so if you want to integrate like a chain like I don't know optimism and a chain like linear you don't have to do it twice um so if you are following like attentively you might ask yourself but okay like it seems that you have to trust the Gateway and like thanks to during the introduction we said it was like a secure and Trust minimize way to um fetch data and actually you don't have to trust the Gateway uh necessarily if the Gateway provide also proof of the information uh that were given and the nice thing about it is that you know that l2s like in the design of rollup are posting their state on the on the layer one and so you can like just fetch a storage proof on the L2 and then like verify it on the layer one uh so that you can be sure that the data is accurate so that's what is uh shown here when you are doing when the Gateway is doing the HTTP request actually the Gateway will uh call L2 RPC will ask for the information for if call and then also like do something like a if get proof to to get the storage proof and then when the contract receive the information it will call the rollup contract which can verify the proof at the high level so I think like the design is quite of cool but uh what can we do with it um as mentioned in the introduction like ens was the one proposing it and actually they have they had a very specific use case in mind which was to enable to manage like domains on L2 for cheaper like gas cost and that's the main use case that we are seeing today uh one example is the linear names that we introduce on linear where you can have like names like brian. linear. if or a.l. if um it's something that uh we built and that can be reused by like the ecosystem to build any uh integration with ens and if it works like everywhere ens is resolved as an example like we have a nft collection on Linea which are called eogs that wanted to give ens domains to all the holders so for instance know if you have a um you type 743 if.

if it's it resol to the owner of this nft and if the nft is transfer like the the name is transferred with it as well so this is kind of cool but it's just a first size and it doesn't stop there like um it can be used for any type of um use cases where basically you want to either compute or store data on the layer two or even of chain and access it on on layer one so some example include like Dow governance where with solution like um sorry we with like governance solution like snapshot X that are providing like voting on chain you can vote on linear or other L tools that are much Sher in gas and then you can just take the result and use this call this result to execute transaction on the layer one one other interesting use case for instance is to like gate access to Smart contracts so for instance like if you are doing an airdrop or nft mins you can require people to have specific credentials that are minted on Layer Two for in attestation for instance um so okay you might ask your question how how do I need to implement that it seems really complicated you're talking about proof and so on um the nice thing is that we already implemented all the smart contracts uh so so like all this complicated logic or not so complicated but all this logic is already taken care of we have a Gateway that is running we have all the smart contracts the one that are verifying the proof which for Z kol up is esec especially difficult because uh the the ZK layer 2 usually have a different way to uh store data uh because like um the standard Ash function can be a bit complicated for ZK so for instance on linear we have like Spar Vel tree instead of merel tree but basically all of that is to say that uh we have contracts that are open source and that can be called to verify the the data to also fetch the data directly so basically uh on the smart contract level it's much more simpler and uh on top of that there have been team like the unrug team that have built additional layer of abstraction that simplify it even more and Abstract the chain so it can seamlessly like work on different chain so to summarize the benefits uh like ERC 3668 is efficient because you don't have to send a transaction on L1 when you don't need to it's secure especially when you are working like on a layer two with like zero knowledge proof like like Linea you don't introduce additional dependency to over protocol and like the development uh overhead is minimal because all the contracts the Gateway everything is already for you to to build on um and so if you want to get started uh those are some links to our doc documentation open source Trio uh but most importantly we are doing a a workshop just after the lunch break where we will Deep dive into really code example and you will be able to have a live version running on on your laptop at the end of the session so yeah that's it thanks a lot just a reminder guys uh if you guys have any questions you can ask them through mircat scan the QR code um looks like we already have some more coming in uh the first question is it possible to read L1 data from L2 and so yeah in theory it's POS it's totally possible like RC 3668 allows to fetch any data the only thing is that you you need to have like the state of the blockchain that you want to to query onor on the Chain where you want to from which you want to sorry I will go go again uh but you you need to on the blockchain that is quaring the information you need to have the the state of the blockchain that is being queried and so like it's not most collup doesn't have that at the moment maybe at some point we will see like Oracle fun Oracle that are uh streaming this kind of data on Shain um but it's it would be something really cool to build uh the last question we have doesn't it make the process more centralized so indeed like the point of centralization here is the Gateway uh but uh if we come back to okay um actually like the smart contract can like pass multiple URLs so you have a kind of redundancy here because you can have multiple different Gateway not to rely on a single point of failure but since the Gateway is passing a proof like it cannot be tempered with uh so there is no additional trans assumption regarding like the um accuracy of the data we have uh another question keep them coming guys we we still have time um does it open up to a temporal attack if the L2 storage proof is not posted on L1 yet yeah that that's a very good good question so you are aware that like l2s are not finalizing like like every second or minutes on on L1 and so basically you don't have the the state of L2 uh like before is getting finalized so on the like Z rollup can be uh from a few minutes to to hours depending on the layer tools on optimistic rollup it's like the seven days so this means that you need to to wait this period in order to fetch the data so there is this latency uh but like as the space evolve and we are going to faster finality uh hopefully this will get better I don't think there is an attack uh it's just that like the client and smart contract need to be aware of this limitation and like work with it at the moment what libraries already implement this behavior um if if that GS for sure uh wag me as well uh unrug is creating a like higher level abstraction to work across chain so you don't even have to worry about like uh the specific of the um each gateways and so on as a builder that wants to to rely on your own Gateway um those are the libraries I know is there any L work latency when reading data um so yeah the it's the finalization latent latency so as I mentioned like from a few minutes to seven days if you're on optimistic rollup but like from the network latency really like it's really uh quick like usually less than a second or even less so you you can test it and like type for instance like arur do.if on the on your metamask or on the ens website and you you will see like the answer is almost uh