# Discovery - the tool at the core of L2BEAT by Mateusz Radomski | Devcon SEA

- Speakers: [Mateusz Radomski](https://streameth.org/speakers/mateusz-radomski)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 1:19:59
- Watch: https://streameth.org/watch/yt-azowA66W5UY
- YouTube: https://www.youtube.com/watch?v=azowA66W5UY

## Description

Hands on workshop about how to use an L2BEAT tool called discovery for mapping, researching and monitoring all the contracts involved in a project. We'll start by introducing the problem that discovery tries to solve and after that we'll get into trying to understand the architecture of a real world project by using the avenues this tool gives us. After this session the participant should feel empowered to use discovery to deepen his knowledge about all on-chain deployments.

Speaker(s): Mateusz Radomski
Skill level: Intermediate
Track: Developer Experience
Keywords: Architecture, Tooling, DevEx, Event monitoring, research

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

[Music] hi hello um so I'm M or you can call me Matt like the short for Matthew uh I'm from Al to beat I'm half of the tooling team in the AL to beat um and my workshop is on the Discovery it's the Tool uh we use we built um to help us research uh projects and it turned out that it is really useful at uh solving all of our problems I mean not all but like majority of uh problems I'm going to later talk about um so a funny story is that I almost lost the demo part of this presentation and the only surviving copy of it was like some random VM buffer so I just wanted to point it out um okay so there is a lot of projects on L2 be um you know the the amount of project is growing and we internally expect there to be at least a th000 l2s uh So currently you can see that there is uh 51 rollups and um 66 validum and optimums um so around let's call it uh 110 projects um of only l2s we also track Bridges um not to the same standard but um for all of those l2s we have uh a minimum bar of data we want to show and that would be uh the risk croset um we want the risk croset to be obviously correct and the standard for this data is actually quite High we want um to show data that is correct so you know you don't lose your funds you don't make a decision based on our data that is incorrect um so how how to even maintain all of this right uh so just like a quick um a quick um math lesson right so imagine that we have 110 projects and every project has a single update uh every two months right so it's actually quite um sparse we see projects that are updating way more often um and even if every project had a single update every two months we would have an 84% chance of seeing at least a single update in a day right so it's basic basically guaranteed that every single day something new will change on chain we need to be able to detect it see it see what's changed and act upon it and also like even if we assume that um an update happens every six months the chance is still 45% right so it's like a Coos basically um and these chances are basically always working against us the more and more projects are going to be added uh the higher those chances are basically to be 100% so what is our needs right so like I like I said there is a high chance of an update happening and we need to be able to fastly see that it happened and we need to be fast in reacting to it if for example arbitrum or optimism right any of the top docks has an update and we take like three weeks to process that update or to even like see that an update happened then we are showing incorrect data for 3 weeks which is actually a quite long amount of time when it comes to web 3 um when an update happens we need to know what changed so it's not enough to see that something has changed we also need to know what has changed right so did any of the risks assumption that we had before are now different um so also we need to be able to look inside the project and compare to the previous version um and as always we want to automate as much as possible you cannot get to 110 projects listed on a website and do all of them manually like um it is possible with human effort but we don't have the amount of resources to do it so right now we have four researchers and we maintain all of the 100 projects with only four people and we also manage to do stuff uh that's you know additional um so Discovery essentially like I think is at the core of solving all of those problems of course Discovery is not a Panacea it does not solve all of the problems by itself um but of the problems that I listed um the discovery is always at the core of um of the solution um so the mental model of Discovery is um like this like I like to think about uh Discovery this way and also I like um understanding things from the low level so let's try to understand the inputs and outputs of discovery the input of course is the ethereum state we want to see uh what is the state of each project on a given uh let's say block number um so the input to Discovery is that ethereum State uh of course we are not sending like an snapshot. zip to Discovery we are doing something like uh I mean we we use RPC providers which is essentially uh having the entire assum State at your fingertips you can do uh any call you would like um and to facilitate the like querying uh the data from uh the state we have a config Json which uh instructs the uh Discovery program which data we are interested in and um how to process it um and after passing those two inputs to Discovery uh an output is generated which is a discover Json file uh of course it's all a simplification uh the more like the actual mental model which I don't even think is correct and there's missing some parts is more something like this um so that's what I mean when I say like the discovery is at the core right uh like all all roads lead back to Discovery um I'll try to during this workshop I'll try to um touch upon all of the things that are listed here um so you'll be able to understand at least how this flowchart uh happened okay so since um I myself am a visual person I want to create I want to show you a uh demo of um of something nice to look at so this is something we have been working on uh which will um enable us to move from um command line to a uh graphical user interface um so right now we call it we are calling it Discovery why and um let's uh see like all of the projects that are listed here are projects that we are uh tracking with uh Discovery so I have picked uh Zora for the project we are going to be using D this during this Workshop um so let's see what kind of data we can expect to see in in this tool for Zora um so of course there is like a lot of things to take in um but let's start from the left and keep going right um there are uh on the left the things the thing is that they look like files but they are actually contracts uh they are kind of inspired by uh the file view in visual studio and um you can see maybe I don't know the contrast is not the best but I hope you'll see that uh we have two contract contracts with which are the initial contracts and by initial I mean the contracts from which we are going to be starting and all of the contracts that are on the left have been found uh based on uh those two initial contracts so it is as you can see like it is quite um useful to be able to find two contracts used in uh in a project and then basically find all other contracts used by that project um and also this updates automatically so if anything new happens um new is added or is removed um they are automatically updated um each of those contracts uh has some values right so uh each contract has uh an address a name a description given uh by a researcher and uh let's focus on the fields uh for now so fields are um um State variables that we have found in the ABI which are um either public variables or um functions which which don't take any arguments and just return something so we are trying to build the uh state of the contract through the E there is also one more part which will be important later during the demo uh I mean doing like the workshop part which is that we try to build uh arrays from um functions which take a single argument which is of type integer so we just assume that this function is like get something by index and we try to get all of those things um and um you can see that there are actually uh addresses inside of those values uh and those addresses lead to other addresses um and this is how Discovery works it gets all of those State variables and if it finds a address it assumes that this address is also connected and just uh keeps discovering uh on those addresses um and the third view here is like a graph view so all of those projects here um are used uh in in Zora and uh the way that um it works is for example let's focus on the security Council maybe not that that's not the best but the system config right uh so you can see that there are some um State variables and they point to um other contracts through the through this view it is really easy to understand how the project is built what contracts reference each other um and how the data flow inside the project happens um of course this is not the default view kind of like the view allows you to select them move it around you can color these um whatever your heart desires to make it easier for you to understand we have two layout algorithms since it's a graph view you can use like D3 uh we called it slow because it is not that fast it uses for Force um Force simulation to lay out the graph we also have more like a high hierarchical uh view which just lays the uh graph from left to right and the third thing is um the code so um all contracts have um source code and uh let's go back to the L1 standard Bridge example and we want to show the code to the researchers because to understand what a contract actually does you need to look at the source code um and you might be weirded out by the fact that there are only two files um I'm going to touch uh upon this a little bit later because it is actually quite important uh why there is only two files and not like more um so yeah you can just view the code in here um the part that I want to also show is that we see that it is important to be able to switch between views right so I can click L2 output Oracle on the left in the list View and it is selected in the values and the nodes panel uh vice versa I can select something in the values and it is selected in the list and the noes View and I can select something in the nodes View and it is selected on uh every single audit view um so this is something which is like um really graphical and nice to show and it basically is only the look inside the discovery Json this is just a nice way to visualize what's inside the Discover Json um but it doesn't touch upon the way of how uh we even got that Discovery Jason right so uh it is something we are working towards it's not yet ready you can only view thing it's basically read only at this time uh but in the future we hope um to make Discovery this uh so you'll be able to do your research in a nice uh graphical environment um and do anything you need um so yeah let's get back to yeah go ahead so you you were showing the source code but the source code is not right yeah yeah so the question is how do I get the source code since it's not on chain so um I kind of skipped uh one assumption is that from by the etherum state we also kind of consider um The Ether scan s c database um even if you go to L2 beat and look um into the products that we list if a project does not verify their source code on eisan we give them like a big red warning uh so we expect you to verify your source code to show transparency to uh the users and to the researchers so they can do their stuff so it is something that I omitted but we do use ether scan or like ether scan derivatives like block Scout or stuff like that to get the source code and uh we heavily rely on the source code because if we didn't get the source code we wouldn't be able to call anything because we don't know what the adbi is right um so yeah if you have any questions do please shut them up during the workshop um but I'll get back to the presentation yeah if you run into uh we don't try it end you don't try it um no I mean there was one case where we knew what the source was it just wasn't verified so we like forcefully like we verified the source code for the project because they didn't want to do it for some reason so we just did it um and we are not trying to decompile the um the bite code in any way I mean if it's something that we can't get the project to verify and we need to look inside we might decompile it but Discovery does not try to do anything uh like that it just assumes the happy case where the the source is on uh Ean or whatever Explorer the chain is using um and just go from there but yeah if we hit a snag like there is no Source we just either accept it as we cannot look inside or or we talk with the team to verify this ccod okay if there are no more questions I'm going to uh keep moving forward so um going back to the mental model because I think it is really important like the if you um leave this place with a single thing it's just that Discovery is just a program it has some input it has some output right so the output is this discovery Json and the input is the config J C and the way you can think about Discovery if it like makes easier uh makes thinking about it uh easier for you is that it's like a scraper for a website um so scraping a website looks like uh you put some address of a website it downloads the the content of that website it tries to find any links and it follows those links recursively Discovery essentially does the same thing but it doesn't download websites It downloads the state of contracts and it's and doesn't follow links but follows addresses to other um contracts um and of course Discovery is not just like a simple thing that is like a black box there are things happening inside uh that we are going to be talking about a little bit so Discovery is able to detect uh whether a contract is appr proxy uh it does the source code flattening I'm going to be talking about it later like I said um it does template matching it is something that also we are going to be touching upon uh during the demo part uh it has custom honders which it executes we are also going to be doing that during the demo and it has Type casting I left type casting out because it is really it would take like 20 minutes or 25 minutes to explain all of it uh so I just left it out if we have time or you were interested you can hit me up after the workshop and I'll be glad to talk it talk about it with you and of course there's like an engine engine that orchestrates everything but yeah it's like there are things inside that blackbox um so I have a demo prepared um there's a QR code if you want to follow along with me please do um and if you get stuck I'll be able to help you gladly uh I'll be going over the same thing personally so if you just want to sit and just listen no problem the website has instructions so you can do it now or later whatever um and also I really hope that the website is is works for you because like it's self-hosted so if it doesn't work try it disabling your VPN try a different country uh I tried it like five times it worked uh without any vpns so I'm going to give you like a minute to uh get to the website if you want to follow along and yeah okay I expect everybody to be on the website right now um if you didn't manage to uh scan the QR code or type it through just ask your neighbor for uh a nice deed so they'll be able to show you the URL okay so uh like I said I'll be going over the same thing uh personally I have it um on my iPad so I'll be going over all of the things that are written in here and also I'll be like uh adding some additional context for it um and ALS also this is an important part um I for Discovery uh from the l2b repository just for the purposes of this demonstration uh if you actually want to uh use Discovery yourself please use the original repository because I'm not going to be maintaining this Fork uh and this could get really stle really quick um and why did I fork it it's just because we are not no it's an internal tool tool we will try to make it more available to the public it's just it is in a rough stage right now but it is still cool to uh show what is what this tool is able do okay so um is this visible like the contrast is okay okay um so I have downloaded the uh the only thing that I have done is just npm install uh and if you if it worked you should be able to just do npx Discovery um and something along the lines of this should appear uh so there are two sub commands you don't really need to worry about them so there is the single Discovery it's it's just for convenience if you really need to discover something like a single address um you put it there but if you want to build like a project uh you'll be writing a config Json either way so there is also invert invert is like we used it to build those graphs you saw we used mermaid before before we got uh the protocol bit I was showing um so yeah don't worry about those the only thing that you're interested in is this discover um so the most boring part of doing anything fun is setting it up and configuring it um unfortunately I'll have to leave uh the part of configuration to you um you need to configure two things uh you need to configure The Ether scan API key so you can actually call Ether scan and you need to configure an RPC URL and the sad part is that um only few uh rpcs work that well with Discovery um I'll say that the fre tier of alchemy worked for me without problems uh so if you have Alchemy do use it there is like an asterisk where rpcs that only support uh block ranges of 10,000 uh when you're cing for logs uh do not work with Discovery for Simplicity we are essentially like expecting you to have an RPC where the block range uh for log squaring is basically infinite um so yeah the you'll have to set this all up I'll just copy my uh n from um uh from the previous tries of that uh so I have an n and you should probably do the same you can always like export the same variables if you want um so now we can get to the actual fun part um and before we actually configure anything uh you know we need an initial address uh the address in the website is already there but like this is also a good question like how do you actually get a hold of like any address that belongs to a project and I'm going to show you like a simple example that you can uh find addresses belonging to a contract uh to a project um so we are going to be doing it this way so like I said I chose Zora for this presentation um so let's just go to the best website and find Zora um and how I do it is just go to their website of any project and try to bridge something and also it is important there are multiple Bridges um for Zora for example but what you want is the official bridge I know it's touch it's a touy subject but in L2 beat we assume that the official bridge is part of the rollup um I don't want to get into it but make sure you have the official official canonical Bridge uh to um to use and uh we just want to bridge uh like the smallest amount of if and do please don't Bridge anything uh we just want to get to the part where it says sign and don't sign please uh we just want to get to the part where it shows us the address we are going to be interacting with so let me just uh Bridge some East yeah whatever okay so this is the address of the uh contract we are interested in and we can just copy it and uh store it for later um so now how do we configure the uh Discovery to start um at that address so um we need to create a um folder structure um that Discovery is able to understand so this folder structure looks like this so just uh I'll type it out here so Discovery is the folder where all of the projects that you will use live basically uh and there're like configurations uh results flat files source code anything that uh pertains to particular project lives in uh Discovery um and the actual project is like that so anything related to Zora lives in there but there's also one more level which is uh ethereum this is the actual chain you're going to be doing discovery on um because we have the ability to do discovery on multiple chains like I showed maybe I'll go back um and the discovery why so if you look here most of these projects say ethereum but for example zik Ling NOA says 10 chains that's because um a project can have contracts on multiple chains and the way that Discovery works is any evm chain just works it just you don't really need to think about it you just say that you want to use uh that chain of course you need to conf configure the rpcs for it and the Explorer for it but otherwise it just works so yeah this is the uh path we want so Discovery /s/ ethereum and in that path uh we want to create a config Json C file the C is for comments it is also there is many parts where you can see that it's not that ready for public release um I think Discovery will fail if you don't provide like if you just do Json it will fail so it is touchy um okay so what are we going to put into uh the config Json so it is an object where you have to Define two uh redundant Keys which is uh chain and that's ethereum uh and also name of the project um so why do we have to type the name uh twice um since it's already in like the uh folder structure it's just for um Simplicity if you want to uh read this config Json in a different tool you'll still know for which project it is uh and now we get to the simple part there is also one more key which just says like what is the initial addresses you can have multiple where is going to put the single one um no so the way we do it uh in this in L2 be is that we have a bunch of tests that just validate if the config uh you have created is of what we expect we also have like a bunch of assumptions where the name of the chain in the config is the same as the slag on the website but but we have tests for all of that but you can put anything like you could put your name inside and it will just work it's just like um there is some schema that they that the discovery needs to see uh and it's just like fing it out but yeah it's just a string like as as um Discovery is concerned okay so we have put the L1 standard Bridge uh as the initial address and since this is a Json C file you can put comments so L1 standard uh Bridge we are trying to uh I know that half of the research team is trying to enforce this standard and the other half doesn't really try but um yeah um so now what we need to do is we we need to run it um and this is another part which is like uh not the best which is um the way that the ordering is done in the folder structure is Project chain but on the CLI it's the other way around so you need to do eum Zora um and if you did everything correctly it should start spinning out logs um the first run takes a little while um and if it fails you'll probably know it failed um but um this the interesting part is here that we have gone to this um address through the source code we have found that it's named L1 standard bridge and we have found four relatives uh that four relative contracts or um entities like also EAS um referenced by um this contract and as you can see like we are putting those relative back onto the stack and we are rediscovering them all um and ideally at the end we have 61 uh contracts or EAS uh and the discovery is done um we have like limits so there is like a depth limit uh of I think seven and there is also a Max address limit so for certain projects that we don't really know uh or for like big Bridges the amount of contract is really big um the biggest um project we have is transporter uh which has 350 contracts and is really like it is mostly just a stress test voice Discovery um so also Pro tip um since like I showed you before the mental model of Discovery is this input output like a functional programming Paradigm or whatever is that you'll need to be rerunning Discovery a lot so um like you saw it takes some time but uh if you look there is a handy d cache so Discovery caches all of the calls you have made to a file so if you need to rerun the same Discovery um it already has all of the RPC and E cter responses so if you just pass Das D Dev I know the name is not the best um it'll just reuse um the block number uh of the previous Discovery and if you look at the speed difference it's night and day so uh please use D Dev on uh any uh call any reruns which are not the first uh run um so let's is to of logs blocks yeah blogs but uh by blocks what do you mean by RPC yeah that's that's the problem that I was referring to are you using Alchemy yeah so quick note is something that we don't so we are using quick node for everything except Discovery because it has this problem of only 10,000 blocks um we had uh code uh that managed the thing that you referring to which is like we did download by uh thousand block batches it's just it's really stupid like we had more time spent on trying to make it work than just like paying for a high Alchemy tier and just like like doing whatever so like I said try to make a free Alchemy account uh you can put Gavin bellson at gmail or whatever it'll just it'll be easier I know that there are also like some public rpcs uh that support like infinite block range for example envio um it's so N.D but they only support logs they're like really like a static indexer um but if you look into the readmy of this covery you'll be able to set it up you can put like two rpcs one is for everything except logs and the second one is for only logs okay so uh let's look uh we have run uh the discovery so let's look what it created um so we have two uh new entries one is a discover adjacent file and the other is a DOT flat directory uh I'm saying this I think for like a millionth time I'm going get I'm I'm going to talk about flat files uh but let's focus on the Discover adjacent for now so in this uh file are basically all the things we have found during Discovery uh and we just like uh put every single thing into this file to try it make to try and make it as redundant as possible um if you look through uh the things um we have of course repeated Zora ethereum the block number at which we um have run this discovery uh the config hash so if the config changes we of course need to rerun the uh discover Json um and the contract list so the contract list is the thing that you're most interested in but there is also the an EA list so all of the EAS that we have found and an API list so the list of all apis uh attached to uh any implementation that we have found and use templates I'm going to talk about templates later um so each contract is an object it has a name it has an address it has Source hashes um not really that useful to talk about it right now during the workshop if you want to know approach me later um since St stamp it's like when was this contract deployed um and values values is the thing that we are after basically it's the state uh of the contract at a given block number so the state of it like do dollar sign something is like a virtual field we have created it ourself based on some other values um but anything else is a state that we have been able to get just by um calling the methods provided by this contract um as you can see there are you know addresses like this and uh some version stuff whatever whatever uh there are things that are really useful in here and stuff that is completely not useful in here so you'll have to you know uh go through it and see uh if anything you would want to use is here um so um as you can see like looking at all of this is not that uh you know Pleasant um so we have also made um I mean this was like before anything else um I mean before this uh thing this is the OG way to view the Discover Jason so um if I just oh my God like I should find the guy who made the decision to make finder like this okay so we can pull this uh into the protocol beat Tool uh protocol beat is the same thing as node View and here so this View and protocol beat is the same it's just uh it is easier you can just drag and drop your discover Json into here uh if you want to use protocol beat uh I didn't think about it but I don't have a QR code you can just protocol beat dol2 be.com uh and it should just should just work for you uh you can do all the things that I showed in the discovery y um but yeah let's go get back to um to here so there are a lot of errors and what we want to do is get rid of them and the thing that I was talking about maybe you remember is the errors are here because uh of the way that we build some of the state like I said we do some assumptions during the initial Discovery so we made some assumptions that were faulty um one of the assumptions was that you know there is some finite amount of uh elements in an array turns out maybe it's not an array maybe the amount of elements is bigger so if we look so let's try to find this is finalized in the discovery Json okay so we have is finalized and we can see that there is an error um and here it is um sanitized because we had problems committing our API keys to GitHub um but in the API if we look for the same thing we can see that we put an L2 output index and it index and it just says to us whether this index is a finalize there is like too many indexes uh to contain and also it is not that important um if we are really interested in what we much rather see is like the count of indexes uh that are own this um project I mean L2 output uh how many of these are there but we are not really interested in any single one so we can just like tell Discovery Hey listen don't call this function ignore it um because it's giving me errors right now so I'm going to show you how to um tell Discovery just to ignore uh this method when um doing Discovery so what we need to do is we need to find uh the contract on which this error happened so as it happens in the error output we get the address right here so so we can copy that address and get to the config so let's go to the config and now we need to um do some configuration per contract so to do that you need to create a new key which is called overrides and now we need to specify that you want to overwrite some things inside this contract um and now you need to say what you want to uh over right so for this contract we want to say hey ignore methods and we are going to supply the methods we want Discovery to ignore so just copy paste uh and rerun Discovery okay we are down to six errors um if you want you can try to ignore more errors yourself um I'll give you like a minute to see if you uh got the hang of it I'll leave you with the config so you have a cheat [Music] sheet yeah so the biggest herle we have is mappings like you say um if um there is some mapping and there are basically no Getters for it it is really hard so we what we usually do is that if the source code is sensible it'll basically always emit an event when it inserts something into that mapping on or when it overrides it we then build that the value of that mapping based on the events so we query for all of the events and we rebuild the mapping State based on those events but there is like no automatic way to do it you have to look at the source code you see which events are there and um rebuild it yourself we have I'm going to talk about handlers later but we have handlers for that uh so we can do just that so while we're sorry uh while we're waiting um you have a long list of l2s and youve said said that you expect you know a thousand or or more that's probably right so how do you get started with this like how do you find all the l2s how do you find new l2s that pop up um that's a question that is asked really often I mean and this Defcon at least to me um and the um the answer I think is way less interesting than it appears like I think that half of el2 be is just chronically online so we are on Twitter and we just know what is new um also projects just come to us and ask uh to add them also projects just make a PR to our repository to add an their L2 uh so right now we have um also we have public Discord so like there are many ways to basically message us about like hey can you review us um and right now we have around like 100 upcoming projects so anytime this project will go into uh into the main net will you know move it from upcoming to um to the main page but yeah like I don't think there is any way we don't have like a discovery for l2s it's just like seeing what happens in the space and that's it so how do you prioritize that how do we prioritize um if so the thing is that certain uh projects if a project is an offshoot of an OP stack it is comically easy for us to find it it's like less than an hour um if a project is more complex so the prioritization always depends on how big the project is how easy it is for us to add it and also uh you know how many times they message us on telegram per day uh so yeah there were Cent projects for example I know that ziky link uh Nova has been in the waiting CBE for a long time they had a maget and they were waiting for a really long time because we just you know we never saw this project before so yeah like we have to prioritize as anything else so the funny thing yeah so the funny thing is that certain so I'll tell you that so certain projects come to our GitHub make a PR and they have you know their config jsonc ready they discovered all of this they made the they made the uh config file in in typescript and I don't think we had uh a single instance of an external team getting this right so I mean they do try but uh maybe it's you know a fault on our part because we are not we don't have the best um tutorials on it because like we didn't expect anybody to be using it uh and we are expecting only us to be using it of course this could change in the future and we could say like you need to uh provide a config Jon C file but at the same time if if they provide a config Jon C file and it's small like I said it takes less than an hour for us to do um and if they provide a config jnc file and huge then we still need to look into it either way so it's just yeah okay I hope that for people that are uh way too ambitious they manage to do it I'm just going to like flash things on your screen to go through it for okay if your config looks something like this and you have no errors except the X domain messenger uh then good job um so uh the X domain messenger error is also a fairy tale to be told I guess um it's just it doesn't provide anything useful and we ignore it it reverse if you do a delegate call to it you need to call the implementation we always do calls uh through the proxy um but the output of it is not useful it like returns I think some chain ID which we already know so we just ignore it also uh for any op stack okay so we don't have any errors um and we can now move on to handlers so uh handlers are a way to get more State um like there was this great question about like how do you um how do you find the state in the mappings uh because mappings don't have a good way to um see what's inside so we have handlers for a lot of things so there are handlers like um this is the uh event count how many times it has appeared uh and put the number as uh the state variable um but these are really complex handers and I think like it will only confuse uh most of the people if I just start uh using handlers that are way too in-depth uh to be honest some of these are really really complex just because we try to know cram as much things into a single Handler as possible so to be honest some of these handlers I don't even know what they do so a simple Handler that I can show is if we go back to Discovery Jason and you know let's look for example let's say I'm interest interested in nosis saves right so um I find me nosis save and I see that there are members of this nosis safe the which are the same as owners and you know I'm just thinking okay so these are some raw addresses but the thing is what I'm interested in is like is a given address an admin right so let's say there's some actor with a known address and you just want to know whether he is an owner or not of course you could do like contrl f and find it but there's like an a better way to do it so um if we look in the API of any um of any nois save so we you need to to get the API you need to copy the implementation um if you look into the implementation of any nosis safe there is a function like this is owner you give it an address and it returns you whether this address is an owner or not so we'll try to see if vitalic is an owner of some random multis right so let's copy the name of the function and let's go back to the config and um oh maybe yeah we also need the address of a no say we want to do it on um so first let's get the address so this is the address we are going to be checking for is vitalic and owner maybe this one I don't want to break my presentation because I know there is one address which is different but okay so we are going to check is V alic an owner on this uh NOS save so it's the same as anything else you just go to the config and you um do some additional configuration for this contract so now you need to say that what you actually want to configure is the fields part so Fields um and in the fields you want to create a new field right so the name of that field is like is vitalic and owner and the value of that field will be generated by a hler so to say that we are saying hler the type of the Handler is a call Handler because we are going to be calling some function uh to get the value of it and there are two additional arguments which is like what is the method you want to call want to call is owner and also want to pass in that address uh as an argument right so we say ARS um and you know now we need to get the address of italic so let's just go to E scan copy the address and add it um the args is an array because you know functions can take arbitrary amount of aray uh args so for this example it's only a single argument function so if you do it like this and then rerun it uh it should okay maybe that did not work let me see okay I guess I didn't uh save the file um so you saw this little hiccup that was there like um most of those uh reruns are like really quick it hiccuped because it was actually doing that call it didn't reuse it from uh the cach because it didn't cash that call because we never did it before right so now is vitalic an owner false right so good job so now um I'm actually going to get to the uh flat files uh because it's going to uh you know move us nicely to uh the last part which are the uh templates so flat files um I have some slides for that um so we have uh buil a custom flattener for the discovery um and I'm just going to try to convince you maybe I don't to you know why we need this so we are working on this L1 standard Bridge contract and as you can see there are 33 files um which is the result of you know teams reusing code uh open Zepp link being the standard Library they are trying to make the module smaller and smaller there is a lot of in inheritance implementation of uh stuff there's just also one thing I'll talk about which is you know ballooning the amount of files in each contract and if you try to visualize like it's a single contract like do you know what's happening like imagine you're a researcher and you like expected like yeah good luck um and the funny thing is that if you look really closely we are only interested in basically the blue contracts and anything else we are not interested in so if you look on the right hand side there is super chain config it doesn't do anything with the implementation of the super chain config but the thing is that teams more and more are basically reusing contract implementations as if they were interfaces so when you do that every single thing that this implementation uses is now also pulled in um and it doesn't have to be this way right so if super chain config changes their source code it doesn't it doesn't affect the bite code generated by the solidity compiler for the L1 standard bridge in any way right so if you cut all of this out if you only leave contract libraries stuff like that that will affect the um the bite code produced uh you'll get something like this right which is way more uh manageable you have like eight contracts I think um and um if you take all of those contracts and like concatenate them together you have like one big L1 standard Bridge so this is the reason uh why when we were looking at the code we only saw a single file that's because all of the files that um we do write out from Discovery are flattened by default so um it's really useful because we rely on those flat files a lot because if you know that the source code in that file when changed will affect the bite code you can just focus on um that source code and um the way we do it is we have uh we are using [Music] a uh a parser for solidity it parses the solidity all of the the files uh coming from is scan uh then we get an ASD we interpret the ASD to find all of the contracts starting from the L1 standard Bridge which uh do actually affect uh the bite code so let's look at those uh flat files they are here and they are um in folders if um they are behind a proxy so for example address manager is not behind the proxy it is immutable but the L1 standard bridge that we are focusing on is behind a proxy so the proxy get proxies get also uh flattened and uh this is the entire uh thing you would want so uh what I'm talking why I'm talking about this is that b if you flatten the sour code of every single uh contract of every single project you have you get some Nifty uh bonuses basically for free right so um since I see that we have a lot of time I'll so uh show you something that we have in L2 be and that we use sometimes so um or maybe I'll not be able to show that yeah but the initial idea is that we have built a script uh that will take all of the flat sources and then compare the similarity between those flat sources to each other so then you get um like a big um list which tells you okay so this project has this percentage of similarity this to this difference Project based on the sour code uh let me just try to see if it may be will work okay if the internet Gods will bless us we'll get it unfortunately so uh if you really want to see this I'll try to get it working and I can show you this after the workshop we are able to basically cluster projects together based on their source code and we get autom IC uh clustering of um let's say op stack uh projects and uh it works really well you actually get like different clusters for projects which use um fraud proofs and for projects who doesn't you use fraud proofs um so it works uh surprisingly well okay but let's get back to the workshop so um let's see uh the confli so let's see let's say that you are not you know you're not so certain about the single no safe and um you think that maybe they'll try to sneak vitalic as the owner into some different uh no safe so what do you do if you want to um manage this Handler into two different um in two different no saes so the first instinct is just to uh copy this entry and just repeat it just change the address so let's just do it okay so we are going to be checking for balic in this um in this not safe so now in this Jason is italic and owner is in two places right so it's here and here right on line 45 and 174 but if you look like it's not really the amount of things that we have changed it's only the address so um just as with code like there's some duplication right and if some duplication happens in your source code what you do is you create some abstraction that says uh that all of this functionality or behavior can be encapsulated to a single function a single class whatever right so how can we uh do the same how can we pull out this configuration call it something and and reuse this across uh contracts across components so this is where the templates uh come in so in Discovery I'll have to show you this this way so in Discovery we have uh Discovery here and if we do uh if we list we only have Zora but we have to create a direct tree um underscore it's temp it's templates yeah underscore templates uh in Discovery and it will just as Discovery houses all of the projects that we have uh templates will house all of the templates that we have uh inside right so let's create that and let's create our template with some something that's weird is that templates are not files by themselves they are uh folders um what why this is the way that it is it will appear it will you know explain itself in a second so I'm just creating in the templates I'm creating a single template called my template I mean the and the directory for it so we are creating this directory for the my template and let's create a new file inside which is template jsonc and uh we can just as with um code refactorings we can just take out in the config the far the thing that we need to uh pull out pull this out into a separate file and that's it basically all we need to do right now is say extends and we say the temp the name of the template and we can do it here also um if we rerun and check the discovery Json it is still in two places right so what this gives you is a lot of Leverage so let's say that you know I don't I want to see if maybe somebody is also uh an owner in NOS safe so let's see if uh a different address is an owner so um since I don't know any addresses I'm just going to use donor. eth and it's the same thing as before we are creating new field we are going to call it is donor and owner and pass in uh the argument and let's rerun every single thing okay and now in two places there is is is vitalic and is Dono right so is Dono is Dono um as you saw we only had to change a single file and in the case where there's only a single project it's maybe not that useful but like imagine that we have thousands of l2s and we want to check something across those thousands of l2s uh changing only a single file um instead of all of the configs for different projects is way more useful um and the way that we use this template is um we um said manually that okay use this template um and this can also get pretty boring and let's say how many nosis saves are here uh there are nine nosis saves inside of this discover Json so I could either repeat myself nine times in um the config or I could you know allow Discovery to somehow automatically uh associate this template with any um contracts that you know look a certain way so this look a certain way is where flat files again come back into the picture so what we can do is like I said like if we flatten a file and we know that this uh the code inside that file when changed will change the bite code and if we say Okay so the source code of of this thing is something so for example here we'll be saying the source code of this is a nois save so um we can in the my template this is why it's a uh it's a folder we can say okay we have some shape files which essentially means if anything looks like this shape um m match that template automatically so to uh do that let's just go to the flat files and pick the implementation the only thing I have to do is uh copy the implementation and paste it here and now when I rerun uh the discovery you can see in the logs that there are logs about uh certain nois saves being uh associated with a template and the reason being by shape match so essentially like what what has happened is we have downloaded the source code for this contract we have flattened that source code and what we did is we found that the shape in this contract uh in this template looks like the uh source code for this contract so we have automatically assigned this to um this contract and this going to get pretty powerful this is why I'm saying that for certain op Stacks like it's less than an hour so the only thing that we have to do is just like input a single address and the Discover adjacent like the output looks the way that we want right so if the team did not do anything fancy did not do anything to custom it just it just works right so if we now look into the discovery Json there are seven instances of uh is vitalic an owner the reason being like I said um some teams change the implementation of certain things just a little bit and if if it's not even uh even if it's like a little close we still don't do it it has to be 100% the same we also have run into problems where um the source code is the same but for example one team uses a certain style of indenting or one style of formatting their comments so we also have a format like a really um maybe not human friendly but really computer friendly form that takes uh the source and formats it into the same Umi like minified yeah yeah yeah um and then it can compare ac across uh across files and since this works so well we can also remove uh these two don't forget the comma at the end and we run we also have uh seven entries um so I see that I'm way uh doing it way too fast like I still 40 minutes so um like it's basically this is the end of what I wanted to show um I can try to show you some of the things that we have in L2 be uh that make um researching uh the things simpler so maybe let's start with uh going back to this um diagram so we have talked about if you look on the left side on the inputs um templates are also inputs to the Discovery we also have talked about flat flat sources um and flat sources like I said are used uh to compare project similarity uh we talked about uh protocol be the only thing that we didn't talk about is update monitor so I said that our uh needs uh are that to have the ability to react quickly to changes inside the projects and update monitor does that um like solves this problem so what update monitor is maybe I can show it I hope I don't have anything onar iing have embarrassing internet I don't know do I have an embarrassing internet or is this going is Discord embarrassing yay okay um so uh this is our update monor so what update monitor is uh is a bat or like a program that takes uh each project reruns the discovery on it every single hour and then does a diff on the Discover adjacent to see if uh anything has changed um and this way we can get like the maximum uh amount amount of time for which the update can be stale or the data can be stale for on our website is 1 hour um um and you know even here in the Discord Channel you have uh quite a good understanding of what has changed for example yeah so this is oh this is an amazing example so Molton has done a upgrade uh of their ARB to a new version and like we have uh descriptions and severities to help us understand um what has actually changed right because somebody has um put the time and effort to understand what is a wasm modu root what is an Aros from uh okay uh this is basically the same but it's like translated um so somebody has put in the time and effort to understand all of this and we add like additional descriptions uh to the um config Json so you can know uh after the fact what has changed to be able to understand the change even quicker um and we do something like this where uh every single day we have a um like a summary of all the changes we need to look at so as you can see for example this is actually a lot of changes we need to look at um and um the way that it connects to our website is that if um any project has an implementation change so you can see for example that Tao is right here in the waiting queue um and the way that it works if uh a project has um an implementation change it's automatically moved to uh in review on our website so if you go to L2 beat and check out Tao it is in review right here and nobody has moved it to be in review it was automatically moved to in review uh and we want to show to our users that look this implementation has change some of the things that we are saying might not be correct and we even I think showed the user um um which implementations have been changed in the smart contract section yeah so now you know that the implementation of these two contracts is different so know be careful uh either you can wait for us to take a look at it or you can just accept the um risk that comes with it uh and yeah um so that's update Monitor and uh I think I'll end it at that unless you have any questions um so we were really ambitious to categorize every single field inside the Discover Json uh and assign it a severity right so for example let's imagine um there is vitalic an owner right or like we have that somebody cannot become an owner because the world will explode or something like that right um then we would assign this field a high severity so anytime this would change we would sort this project to be higher because something with high severity has changed um as you can see there is also this fourth column which is nobody has assigned any sity to it uh and most of the projects don't have any severities uh I mean most of the fields don't have any s is assigned to them um because just a lot of work um to do so but um M does that answer your questions are yeah yeah yeah um we associate templates with a given contract I mean of with a given implementation of a contract um maybe I can show how templates look in L2 Beats um because the all the things that I showed are not uh maybe amazing um leave me alone um okay so this is the uh can you see it right here it's good okay so um we have uh the templates uh that are in L2 be and what you can do you can uh create uh directories inside the templates and then try to categorize um each template for like a given stack so for example we do associate templates not maybe with l2s but like the stacks that they use so we do have an OP stack template like there are a lot of templates so for example the L1 standard Bridge has its own uh template right here it looks like okay that's what I expect um okay yeah uh no I mean all of this is like every single thing um so for example let's go go back to the UI so this is Zora right so every single thing that we are showing for Zora is um on my laptop and would be the same result uh if we were to uh run it for on the data that we have found in the workshop session right so we are not making any additional calls to anywhere else it's all local basically oh yeah so there are two tools I know it's um maybe confusing so this is Discovery Y and it has protocol beat in it uh but to load something into the discovery it shouldn't sa discover UI at the top but uh to load something you just take the Discover Json and uh drag it on the website okay any more questions um so I specifically chose Zed for this presentation because any single time I try to share uh my terminal and because I use Vim uh so it would be just way too distracting to like try and show you know uh Workshop stuff um on the terminal but this is Zed with uh V bindings okay thank you [Applause] great job thank [Applause]