# Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1 | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 57:09
- Watch: https://streameth.org/watch/yt-L1pwtkKSTvs
- YouTube: https://www.youtube.com/watch?v=L1pwtkKSTvs

## Description

In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!

Speaker(s): Julien, Grant Southey, gregskril.eth, Thomas Clowes
Skill level: Expert
Track: Layer 2

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

I think we're going to get started here okay cool hey everyone uh this Workshop is going to be about ccip read maybe I'll hold this oh or maybe not okay also known as ERC 3668 I'm Greg devell at in labs and going to be splitting this up uh with some friends from Linea and unrug B who you'll be hearing from a little bit later uh so just agenda I know this is Workshop so we're going to try and limit the slides but uh to keep it interesting we're going to give you three different perspectives I'm going to give a brief overview uh Julian and Grant from Linea are going to share their perspective as kind of the first layer two team that really built and uses trust list ccip read infrastructure in production and then Thomas from unrug is going to share a more generalized framework around how you can use uh trust list ccip read infrastructure in production as well so if you haven't seen it um this is ccip read or ERC 3668 it was authored by Nick Johnson founder and lead developer of ens and you'll hear why that's relevant in a second and uh before we dive in we just want to answer two questions today why was it created and how is it used and I guess before I do that has anybody uh kind of written a contract that uses ccip read before just to figure out the audience okay so not very many cool this is going to be useful introduction then so ccip read was written with in in mind but written as an EIP so that it can be used for other things as well um and the reason it was written with 's in mind is because we have fairly unique needs um ens is rooted in L1 which obviously is decentralized but expensive and so we wanted to have a flexible system to where you can also uh basically fetch data from other places um and the first solution that people might think about is why not just like deploy to a bunch of chains and the reason we're unique is because we kind of can't do that uh there has to be one central registry for where you have eth names which is only a part of ens but an important one uh and so we can't just kind of deploy to different chains there can't be a world in which a eth name is registered on multiple chains and different owners is just messy so we have to have a central chain and we it's important for us to stay on Main net for that Central chain uh or for that central registry because of decentralization and stuff like that so an ideal solution to these kind of set of problems would be supporting reading data from any offchain data source and we really say offchain but it's like off L1 to be a little more explicit so that could be uh a database any generic API or a layer two and at the initial level kind of like the first level defense both of these look the same like offchain is just off L1 um but we'll kind of talk about how that difference comes into play in a minute um and similar to 0.1 based on where you read from you'll have different sorts of verification logic um and so if you're reading from an offchain data source it will be a basic verification logic if you're reading from an L2 you want something a little bit more complex and more kind of provable and ultimately you don't want to add an extra burden on app developers that have to like do a bunch of whole custom stuff and you also don't want um a whole bunch of burden on Gateway operators that might like push data to L1 by making a transaction and BAS basically trying to mirror other chains because that's just expensive and not really sustainable so the solution is this kind of diagram I think you can see it pretty well uh it's small on my screen so I'll try and explain it basically there are three parties you have a client you have a contract and you have a Gateway or in other words it's like an application um a smart contract and then an API you know the spec is that a client will call a function on a smart contract as you do on any contract and instead of returning data directly from you know internal storage or something it will actually return an error if you're implementing ccip read and that error has a specific signature basically it's it's this offchain data error and this indicates to the client that it should send the call data that it gets back from that error to some URL which is also defined in the error and this kind of sounds complim complicated but it's handled transparently under the hood uh by a bunch of popular libraries probably the ones that we all love and use today like VM ethers wag me and so on um but basically VM ethers wagm they know how to handle this response and it's deferring a request to an API a Gateway that Gateway will return some response and then again the client basically submits that response to the originating smart contract asking it to verify the result and so that verification is where the cool stuff happens but just to give a more ens Centric view of this we have a client which you could also call like a wallet in this case you know say you're trying to send assets to example. eth the resolver is a smart contract um in ens resolvers are what's responsible for storing all the data associated with a name and then again Gateway and you have implementation specific logic so I want to look up example. eth on the resolver smart contract it reverts with an offchain lookup saying I don't have that data but actually go get it from this offchain Gateway it asks the Gateway it reads it from whatever logic that Gateway implements Returns the data verifies it and ultimately you get your result so the two kind of like cool pieces here are the Gateway can do anything and the Callback verification can do anything so the two most common implementations are like on the Gateway side you can either fetch data from a database or you can fetch it from a layer two and then the corresponding verification would be like signature verific so does the private key of my gateway kind of approve this message very basic very trusted and then if you're reading from Layer Two it's really does the has the layer two posted its state root domain net you know the way rollups are supposed to work and does the L1 kind of verify that data that it's received and so we're just going to go through two quick examples and show like a before and after of what this enables not actually going to run through both but I'll just do one very quickly so you can kind of feel the difference um I have this offchain demo here I'm going to say hi Devcon offchain demo. e this name does not exist on Main ethereum obviously I'm just going to Press Register and oh that makes sense okay give me one second okay I didn't think that there yeah um okay if I can't do this in a second then that's fine all right I can't do it but anyways I'll if you want to scan this QR code and do it yourself what's happening is I'm signing a message and that gets saved to a database and once it's saved in a database then you can go and use this as an ens name because it's just like uh signing my my Gateway signs a message kind of like saying that it's correct and then if you go to the name. offchain demo. eth in the ens manager app or any wallet or block Explorer anything like that it will work for free and um I wanted to show you that so it's a little hard to explain but hopefully you understood um and while you guys might be playing around with that I'm just going to talk about the kind of like better approach which is the trustless trustless example and this is what Linea does so you'll hear more about it in a but instead of storing the data in a database and instead of the call back function verifying you know a generic signature it's stored on a layer two on Linea and the Callback function verifies linea's State proof that is or state route that is posted to layer one as normal rollups do and in this case the Gateway can actually never lie uh because it's verified on the layer one smart contract so this is like the best way to do ccip read and what you'll be hearing more about how to do in a little bit from from both of the teams so the before and after From ness's perspective is like creating an L1 subname which I tried to do this morning subname dog test. eth metamask was telling me it would cost $15 to do that whereas also this morning if I wanted to register greg. line. eth which the screenshot is from a little while ago so might be slightly different but it costs 10 cents and both of these work the same way across any ens integration one is $15 one is 10 and so this is is really what we wanted to solve when creating ccip read and how it's being used in public is pretty cool um you know Linea has almost 500,000 names base. eth has 500,000 names and these other two offchain implementations have millions as well and so basically ccip read was created to solve flexible data for ens and also the ethereum ecosystem at large reading layer 2 Data from layer one and now I'll hand it off to the Linea team to go a little bit deeper uh we haven't practiced the computer switch so might have to give us a minute but let's see how this [Applause] goes mirring bya this is yeah that's good afternoon everybody uh my name is Grant I'm one of the lead smart contract engineers at Linea as part of the core team if you want to scan that QR code that's going to take you to the link for this repository where it'll contain the code samples with everything that we're going to be working through today so I'll just give you guys a minute to grab that and then I'll take you through some put some pieces about the linear implementation with enss and then once I'm done Julian is going to take you through an actual practical example so if you're wanting to code along that's the repository to get the data from you may need to install a couple packages that are in there first as with good security practice just make sure those are the packages that you want to install cool hopefully that's big enough to see let me just make it a bit bigger there we go so looking at the ens implementation that we've done on the left hand side you can see the user icon that user is going to then call a smart contract on L1 as Greg was explaining earlier in this case it's the on the bottom that's the L1 resolver what that implements and inherits from is the base fetcher contract which is an abstract contract package that we've written and that anybody is able to use to call and do all the reverting that was mentioned earlier and that follows the ccip Gateway well CCI um EIP that then returns back and then goes to the gate that you can see on the bottom over there which then goes and calls some data on linear what is what it's doing in our implementation it goes and gets a storage proof and data at a specific storage slot that you've specified in our example today we're going to be calling a single storage slot just to get some data out of there and returning it to L1 it's fairly simple in what it's doing but some of the partners like un ruggable you will see they've done some examples around retrieving more complex data such as structs and various other things so the example here that we're doing is quite simple but you can build on it and do pretty much any data that you want there what that does is it gets the current storage route and comes back to L1 and because as part of our linear finalization process when we roll up we've taken the storage route we've stored it on L1 at a particular block height and then when you come back to L1 back to the resolver or in this case it'll just be our verax fetcher verax is our proof of humanity Gateway well Solution on linear so for example if you want to use proof of Humanity on L1 you can jump straight into our linear implementation or the verx implementation and then use that so there's something for you to think about using in the future if you're doing some things on L1 so we then call back to the resolver on L1 once we hit L1 we then take the storage proof check that it matches against the state that has been stored from the finalization process and then you can do with with the data whatever you want to know one so it's like you've proven Humanity in our case we've going to pull out an attestation to prove that that attestation on verax exists and I think that's up to you you want to go through the code repo there are some other links in here through our ens implementation that's in the repository so at your leisure have a look see through the implementation if you want to go and get a deeper understanding of what we've done and obviously this has all been very well audited cool hello everyone um so yeah we we will uh go through an example um as Grant was saying um an example that is going to uh read data uh on Linea in um the verax registry um so I'll I'll do it uh live right now um but you guys can follow the quick start that we have here and you can redo everything that we'll be doing uh right now um so first uh we're going to go through a a little bit of code I don't know if you okay you think it's think it's good enough can everybody see the screen is this good um so what we have is um uh the fetcher contract so here the this this fetcher contract um has to match your uh your needs uh so you're going to have to write a custom fetcher contract for um what you going what you are going to read on the the uh destination chain so here we want to we want to read the data from verax contract so that's why we call it we call it the verx fetcher and this uh contract is going to inherit from um uh this evm fetch Target contract where all the U verification of um the data that's going to be U uh that will that will be sent by the Gateway along with the proof um all this verification process will happen in in this evm fetch Target contract but this um uh is in in I mean we made an npm package of it so you can you can just um uh use it uh from there and so all you have to do uh is a couple a couple sorry a couple um um uh uh you have a couple um arguments to enter here uh so this will be uh the verifier and the and the Target contract so the verifier will be the uh um contract that does the verification and um but this is already deployed so you can use the same for all your uh custom Fetchers and uh the address Target uh this is the uh address contract on uh uh on L2 um then we have this uh um we have to uh also uh implement this uh function here um this is because there's a delay in the finalization um of the from linear to L1 uh that can be from 8 to 32 hours before the the state of linear posted on on on one so we um so we give the uh verification process uh an accepted block range length um so uh because we can uh we cannot uh directly um uh get the the data on the latest block on linear um if it if it hasn't been um posted on L1 uh so that that's why we have this uh L accepted length here uh um and so F and finally this is the our function where we're going to uh trigger the ccip flow CCI per flow um so what matters here is the what we call the slot that we going to we that we are going to query uh on the on the linear contract um sorry so we'll we'll get the slot 102 in the verx in registry contract um and uh I won't go too much into detail of how we uh build this Square here uh but this is um this is mainly the ens uh implementation of evm gate Gateway that they they did this way so I'll I'll let you go check the more in details um and uh and yeah this and finally this is the uh function that's going to be called um once the um the data has been sent from the Gateway and uh and uh after the verification uh we'll just uh call this call back function to return the the final result um so I'm going to deploy this contract right now I'll just do this hopefully it will work uh obviously obviously the U verx registry on line that we are going to query uh it's already deployed uh and also for the purpose of this demo we we had to have a already deployed contract we cannot deploy a new contract because otherwise we would have to wait between 8 to 32 hours that the state is posted on their one so so that's why we are quiring um a contract that already exist it's taking a bit of time so this is on seia by the way uh we're doing this on okay I mean if I can use it doesn't work yeah um I'll just shoot I mean okay finally done so uh I'm going to get my deployed address here um and I'm going to show you a little UI very simple that we made uh to call this contract that we just deployed so I'm going to paste uh the address the deployment address here and what I'm going to do is um I'm going to check if uh an attestation ID stored on U on the uh verx registry exists um so on linear so I'll just do uh so the idea is this this one I'm going to just call the uh the contract like this and uh what it does it Returns the same ID so that means that it does exist if I put another let's say uh this ID here um it will tell me that this um ID this attestation ID does not exist um and what we can also uh see is when uh when I call the uh the contract I can see here that uh we have a call I don't know I don't know if I can see I guess it's too small but I can yeah um we can see that the so the linear ccip Gateway is being called uh in the background when we uh click this button um part part of the process of the CCI period um and it returns so a bunch of uh data so it's it's the it's the value that we are um trying to retrieve plus the proofs and all this um all this data here is sent is a scent sorry why can I okay okay um is sent to uh this function here this call back function here um where uh it's going to decode all the all this data and uh is going to uh proof the to is going to uh prove that this this data is this data is valid and then uh and then send it back to uh this callback function here and return the value um so yeah this is all the uh uh all the CCI perod flow um and uh and yeah that's and so the other thing like that I wanted to show you um is uh how oh sorry this is not it um how easy it is to um uh for the client to do the ccip read call um just going to show you uh so this is by using U um ether JS for examp for example uh you can simply do this uh uh call here uh where you're going to uh so you're calling the method that's uh to get attestation method you pass it the attestation ID and you just add this little parameter here enable ccip read and in the background third in the background thir JS going is going to um do all the CC read flow so uh so rever uh so it's going to catch the revert the revert from uh um from the contract then will take uh this uh uh then he will call the Gateway that need he needs to call to fetch the data and then send and then uh take the take the data data back from the Gateway and do all the and recall the uh um call the call back function to verify the data and and then and return the result so this is uh yeah uh this is all that's happening in the background um and yeah I think uh that's uh what else did you you want to show um I so I was also um telling you at the beginning that uh uh you're going to need well here we already have the the slot that we are interested in when I talk when I talk about slots uh it's um so the the storage on evm there there's a storage index index for every uh variable that is that is stored so for example if we took a look at the uh attestation registry that we are querying um what we are interested about uh in is is uh uh back here it's this uh variable here so we need to uh we need to get the the slot index of this variable here um you uh you can do it uh you can calculate it uh yeah you can calculate it manually but uh you Al you also have a for example with hard that you have a uh you have a a plugin that allows you to do this uh easily um you can do uh NP npx hard check so this is going this this command here is going to use a um hard hard that storage layout plugin uh and when I do this it's going to display all the uh slot index for all the variables and the contract that we are interested in and so you can just uh uh get the the index that uh is um uh interesting for you and uh and uh use it in your fetcher contract um so yeah I think that's a cool plugin um and uh yeah I think that's uh that's about it for um this work through um so yeah you can reproduce everything following the uh um the quick start here uh on your machines and uh yeah I think uh do we do questions uh no or question I don't know okay yeah we do questions at the end or okay at the end all right well I give we'll give [Applause] a we'll be around I'm just telling that we'll be around to answer questions and also like the system having issues getting yeah perfect okay just I've given you a teaser already accidentally okay uh perfect I am Thomas from unable uh we are ens service providers uh we are building unrug gateways which is a more generic uh system for doing essentially what the guys from Linea have just demonstrated so unrug gateways is a full solution for allowing trusted dat trusted data resolution from L2 blockchains just quickly if I'm here can everyone hear me yeah perfect so this is a QR code that links through to our GitHub repo uh I would recommend clicking on that at this point I will do it just for the purposes of demonstration um but at the top of here we also have a link through to our Gateway documentation which is also good supplementary material for this presentation and I've specifically set up uh Devcon links section which links to everything that I'm going to kind of mention here so you can kind of follow along as we go or you can uh jump ahead if you wish and just click on everything and see what happens so a bit of background and context to why we have built unloggable gateways so unrug is an ens service provider and we are building on top of ens we are building a solution that allows for reading data from L2 chains the usage of that in the context of ens is of course uh for allowing data to be stored on cheaper chains that make it easier and more accessible for users we also want to make Building Solutions simple and accessible to everybody so that Builders such as some of you in here are easily able to kind of on board and build smart contracts that integrate um with the Gateway solution to to read data from other chains we yeah we want to abstract away complexity and avoid duplication of effort for some additional background the code that the linear guys just ran through is uh a fork I believe of the EV M Gateway codebase which was kind of the initial version of this solution that was built by Nick Johnson I think Greg mentioned that um from within ens Labs that kind of worked with arbitrum and optimism I believe and then Linea kind of got in contact and wanted to build a verifier solution for their chain and there was a lot of back and forth and a lot of kind of uh hard work on both ends to get that working so I guess in many respects this is to kind of uh take out some of that boilerplate leg work in terms of other chains getting on boarded and making it easier for uh chains to work with the solution but also implementers to use the solution so as you can see in this screenshot and if you click on this link this is the ens app um this is the profile for arbitrum verifier unreal. this data is all metadata that is being resolved from arbitrum trustless uh so this data is returned from the gateways that we operate uh alongside proofs which are then verified on layer one so this data is quick and easy to update it's cheap to update uh and it's trustless the worst thing that anybody can do in terms of a Gateway operator is that they could censor data so they could stop any proofs being returned but they could never return anything that's invalid or incorrect so that should give confidence to users that if someone is inputting an ens name into a a transaction uh input the name that it resolves to is in fact the name that's set and as long as they trust their uh client metamask for example which one probably does at this point um then yeah you're you're you're all good so I mentioned EVN Gateway uh the code base that Nick originally wrote what is new in terms of what the unrug Gateway solution offers firstly uh NX solution only allowed for uh single targets so you could only fetch data from an individual smart contract this uh solution allows for you to work with as many many contracts as you want there is a constraint but it's not a constraint that in practice anyone's ever going to reach so what that means is you could in principle query a contract read data from that contract that is an address of another contract use that and Target that and then fetch data from there in the context of ens this is particularly useful because the current architecture of ens has a registry which has a resolver set for each name and clients that implement the ens standards have to fetch that resolver for that name then query that resolver to resolve an address this allows for you to use this solution to get that data from layer twos and still kind of maintain all the benefits that I mentioned before with trustless this solution is also heavily optimized we spent a lot of time implementing in caching at all layers uh We've uh optimized on request size I'll come back to a reason the reason why that's important later uh we have RPC D duplication so in terms of getting proof data from the various chains rather than having many many calls to e get proof and Linea get proof and ZK sync get proof which are the respective proofing methods implemented by those chains we can kind of group together requests and uh min minimize kind of data that's going over the wire we also use assembly wherever appropriate to optimize uh and make everything efficient in terms of operation flexible data manipulation you can do everything in line you can write a request and uh you can c that cash you can use bitwise operations you can slice you can do maths operations this means that you can kind of do incredibly complicated things if anyone's looked at the ens architecture in its current form it uses name hashes which uh are KAC concatenate kak hashes of concatenated label hashes um and you can now produce a name hash inline in your request and then query data from a slot using that you can also use nested requests so you could build a request pass that into another request Loop over it etc etc and for incredibly large data values stored on chain there's also uh a big unlock with hashed bytes storage I will escape I'll escape this just quickly to link through to this documentation page in the solidity documentation this refers to how storage is laid out in solidity and the guys at Lena mentioned this there's some kind of incredibly complicated rules about how different storage types are stored on chain and what unrug gateways seeks to do is essentially abstract that complexity away from you so you can write a very simple request and request data and have it come back without having to understand all of the intricacies of how everything is laid out behind the scenes so chain support in principle we support all orbit chains all super chain chains Linea scroll bass I've put Bas on there separately but bass is in fact a super chain chain and of course the recently announced name chain so this slide is intentionally verbose and complex Tri structures vult prooof finalization it's all fairly complicated stuff and again we want to make ccip read and reading data from other chains as accessible and as simple as possible so we kind of try and Abstract away the fact that all of these chains use different triy structures different fault proof mechanisms obviously optimism arbitrum are optimistic rollups scroll and Linea ZK rollups scroll uses Poseidon hash for it try Keys Linea uses a sparse Merkel try etc etc we want to create a simple Builder interface that allows you to write one data smart contract that you can deploy on any of these chains and then use a simple Builder interface to build a request to fetch that data on any chain without having to understand any of these intricacies I do make note of the finalization periods op optimism main net actually this is not true for all op stack chains cuz it's configurable configurable but optimism main net has a 3.5 day finalization period orbit Chains It's seven days scroll is an hour and as the L Linea team mentioned it's currently 8 to 32 hours although I do believe that they're seeking to reduce that over time another area of complexity is rollup architecture on layer one all of the these chains have incredibly complicated rollup contracts that kind of intertwine with one another the fault prooof uh chains inherently have more complicated architectures where lots of contracts interact with one another and scroll for example uses batches of blocks uh that is to say the data that they commit to layer one is contained within contains batches um which is kind of a range of blocks whereas most of the other chains submit State roots that align specifically with an individual block so again we want to kind of abstract this away so people don't need to work out exactly how to prove against State Roots post on posted on L1 by a particular chain instead they can just use the standardized interface and it will just work so a bit more Hands-On the core components of the solution essentially if you're writing a smart contract for example nens resolver whereby you want to resolve data from another chain you need to write a request you'd write that request using our Builder interface which I'll come on to shortly that request will then be sent off to a Gateway we operate gateways for example randomly selected arbitrum Gateway arbit room. gateway. unrug bl.com so if go onto these gateways on the landing pages it just gives you some configuration information which will probably mean nothing to you and that is fine but the Gateway solution will abstract everything away and these gateways will return responses which contain proofs that it will then verify in the third part which is the verifiers that are deployed on layer one if I click on this documentation link this the documentation uses the solution itself and it resolves all of these metadata addresses from the respective chains so this address here is resolved from arbitrum this is resolved from bass this is resolved from optimism linear and scroll we also have spolia deployments which hopefully will also work they do um so these are the addresses that you need to use if you want to write a a smart contract that utilizes this solution similarly we've set up verifier D metadata. unrug doe which when it loads contains the addresses of the metadata contracts on these respective l2s so these are the contracts where this data is actually being the data that you see here is being fetched from these contracts so if we click through to one of these we we can have a look on the optimism ephas scan this is a fairly simple contract whereby you configure it with a verifier address and an array of key value text records but if we go to here and read the contract we can see that the verifier address for this one is rx 61 text record if we type in avatar for example yeah oh no is that better yeah so this is the Avatar that is being resolved when you visit that um address on here which was arbitrum do verifier un ruggable I no maybe it was the optimism one yeah so R x61 and that's the Avatar so this is probably the bit that's of more interest in terms of if you want to actually build something using this solution so this is the Builder interface that's made available to users of the codebase I'll just run through it quickly so this is essentially stating that you want to build a request that's requesting one output so one piece of data we're setting the address of the contract which we want to resolve data from which is the metadata contract that we have deployed on the layer two we're then saying that we want to get the data that's in slot one and we're reading that data we're then setting it into output index index Z so similarly to the previous uh example by the linear team if you go over here what's happened there in slot zero we have the owner because this is an notable contract in slot one we have the verifier address so that is why we're fetching from slot one that is the actual code that is utilized by if you just bear with me the unrug unrug verifier resolver which is the resolver that we've set on verifier do unrug doe so if you're aware of the various ens IPS and the ens uh protocol standards there's ens IP 10 and ens IP 5sp 10 is for wildcard resolution so we set this resolver on verifier unrug and then all subnames of that get passed through to this resolver if we look here the code that I had in my presentation is is listed here in the adder gter and we pass through this request to the fetch method it comes comes back to this call back and we return the value and that's it so hopefully people are in agreement that this is somewhat more simple although I appreciate that it's still inherently complex than kind of having to discern exactly how storage slots are laid out for a particular contract or the fact that kind of a long string spans multiple slots or that if you're trying to read from a mapping you have to work out the hash of the key etc etc behind the scenes this request is converted to these bytes which represent the request and are interpreted by our virtual machine hopefully again everyone's in agreement that the former Builder um syntax is more easily more easy to read and more semantically clear than a long heximal string in the same way that an ens name is a lot easier to use than a heximal address so the virtual machine behind the scenes you kind of don't actually need to be concerned with this because this is what abstracts away the complexity for you but just as a matter of interest it's a stack based virtual machine machine it's written in both typescript and solidity so if you want to develop quickly you can write code in typescript and then the same syntax will work in solidity so you can build tests and examples using node for example run them make sure they work then just copy and paste them into your solidity deploy off you go essentially when it comes down to it it is just uh multiple if statements um but if you do look through the code base you'll see that kind of behind the scenes there is a lot of complexity to it the majority of the Builder interface methods are essentially for Discerning the appropriate storage slots from which to read data and then behind the scenes the virtual machine generates those storage slots and reads the data that is all that I have for you um this is the QR code for GitHub again and uh if you do work with this codebase and if you have a look through it and you like it and you want any help we're more than happy to help a star would be appreciated thank you any happy to answer any questions or fill in any blanks um yeah just wanted to kind of focus it down a bit and uh if there's any additional understanding that you'd like I'm happy to elaborate and similarly I'm sure Greg and uh Arthur and Julian would be happy to answer any questions directed their way oh oh okay while there is a need could the person that submitted that question add any color to what exactly they mean I'm not sure quite follow was was it you Greg um so I don't know who asked it I I did not um and I don't fully understand but I think the question is basically asked is like uh was interpreting what we were saying as this has to be implemented into an ethereum node uh because it says something about adding this implementation to an ethereum node but really uh the whole point of this is that you don't have to modify ethereum nodes uh this is a client level spec and so wag me ethers VM uh and all the other kind of ethereum libraries know how to interpret that offchain lookup error and we'll do it on the front end the request that is or like the URL that's sent from smart contract back to the client uh is is a frontend level thing and the the front end or like let's say the client because it could be on a back end um we'll basically make that HTTP request there are no changes to ethereum nodes there's no special node or like RPC that you need to use in order to support this it's all client level implementation so I think that was the question and this one might be more specific perfect so a hank you uh is it possible to create a proof um the owner transfer ownership and submit the proof uh I'm assuming this is being asked in the context of an ens name um so these Solutions are kind of read Solutions so they're read operations so you can't actually kind of modify any storage state or anything like that in relation to um the the proofs that are returned you could kind of read from in for example the case of name chain once it's released you could read from name chain to discern who the owner of a name is and you could prove that on layer one you wouldn't be able to then modify that or transfer the name in any capacity no I believe that's all of the questions unless there's any others the only other thing I would add to that is in addition the documentation for unrug gateways is fairly fleshed out so we do have an example section which um has a examples utilizing our typescript virtual machine so you can kind of check out that repo and get things running immediately similarly there's solidity examples that do specific examples with ens name resolution and as demoed if you go onto the ens app and look up any of the names if you go to the root name verifier unrug e for example and have a look at the resolver you can see how that works um by looking there and uh yeah there's there's contact details details on how to run a gateway etc etc um a more kind of in-depth overview of the fundamentals and the concepts that uh I've spoken about today um yeah perfect oh thank you I just want to ask question was aide you different kind Windows each of CH days hours or whatever does that mean in practice if you're trying to stay on the L1 mean there's a delay before the that state can be read or does it mean that the state hasn't been finalized so that's actually a really good question um and given how much time I spent working on this it's unbelievable that I forgot to mention this um so yes in terms of uh orbit chains for example there's a 7day um finalization period whereby uh any ongoing dispute and the dispute resolution process means that you can't really truly believe that state stored on arbitrum is finalized until 7 days has passed in the context of ens if you had your data on arbitrum you updated the address that it resolves to that wouldn't be particularly useful or functional if you had to wait s days and if for that 7-Day period people sending e for example to that address we're still sending it to the old address in inverted commas what the Gateway solution allows for is for you to configure things such that you can um change the uh the sort of time period over which you consider something trustable so in practice for a low stake value potentially like the description field on a an ens name for example there isn't really an attack Vector there and there's certainly not an issue with kind of loss of funds so you could potentially run a Gateway that says that stuff that's submitted to arbitrum is instantly accepted and then once you update it the verifiers will verify those proofs and it will work that's kind of a configuration option and in the context of ens related Solutions it's still kind of an ongoing debate because in practice uh after a certain period of time 95% of time I just made that stat up by the way everything is okay nothing ever gets reorganized there aren't any attacks etc etc um so Discerning what the appropriate way of doing that uh and the time periods for a chain uh and the gateways that you operate is kind of one of those discussions we're also cognizant of the fact that most people don't want to run their own gateways and that is kind of exactly one of as well as building this we operate Gateway ways with specific configurations to make it easier for people to use and I guess our hope is that this is one of these things that kind of pushes uh chain operators in the direction of kind of optimizing their solutions to minimize finalization times as listed here scroll for example with an hour finalization that's kind of makes scroll and attractive option Linea 8 to 32 hours I know that they're reducing that over time which which will make them an even more attractive option op stack and orbit chains I know that there's a lot of research going on about adding in ZK stuff to make it such that you don't need to rely on their proof systems and there's potential for multi- proofs um and yeah all all of these kind of chains the hope is that they will work to reduce these times essentially any more I just I just want to add one thing to your question so it really does depend a lot on your use case so if you're doing something like proof of humanity that's based on an address like we have with our verx Solution that's not going to change so if you're looking for data that you know is potentially mutable then you know you'll have to adjust your you know what conditions you care about but for things that will never change like oh this happened this was an event that existed there's something that you know was you know you have proof of humanity those things will never change so it really does depend a lot on your use case cool um we'll be around here for the next like half an hour or so so if you are working on trying to get your Solutions working and you have any other questions we'll be over here happy to help you out if you have any problems cool [Applause] you