Using Forta Firewall to Block Exploit Transactions

Transcript

Carlos salot from the fora team telling us how to secure this space I think it's a wonderful start for this uh conference we're going to have actually uh another webinar next month and hopefully very soon we'll announce the date and the time for the DSs uh physical meeting so Andy and Kos I'm really really curious to hear your your idea how to prevent the defi hex in 2025 so go for thanks mly appreciate it and Nathan thanks for organizing as well um I'm Andy Beal head of ecosystem at the Florida Foundation uh my my partner on

this webinar is going to be Carlos our head of AI we're going to tag team this I'm going to talk um high level about uh what fora firewall is how it works how we integrate it into rollups in particular and then Carlos is going to take over and dive a little bit deeper into um how our Ai and ml Works um in the background because that's what we rely on to identify uh malicious transactions and then at the end um we will do um uh we'll walk through some analysis that we've done on um some existing chains uh like uh Bas and Inc which is kraken's new L2

uh we've got some some screenshots we can show there um and then I'll I'll I'll pull up the firewall dashboard which is what our our users would see and I'll I'll simulate some transactions and kind of show you show you how the how the system works and then we've got some Q&A at the end so with that I will share my screen and we'll kick this off um okay for those not familiar with fora um we spun out of open Zeppelin in 2021 and for the last three and a half years have been focused on real-time monitoring and threat detection and um have really championed the use of machine learning for threat detection and and prevention in this space so

firewall is very much continuation of of the work we've been doing uh since since 2021 um just as a quick intro sort of work with a lot of teams across the space from wallets security teams compliance vendors um uh large D5 protocols and and now in the context of firewall um a lot of large l2s as well like plume so let me introduce for the firewall and I'll kind of walk you through a really simple flow so we want firewall to be the security layer for your rollup we can also integrate directly into D5 protocols and I'll I'll briefly mention that here in a few minutes but I'm going to focus on rollups because the

integration here is really clean so so we position ourselves in a rollups transaction flow we capture all we we we're able to see 100% of transaction activity and the flow works like this firewall uses simulation and AI to screen those transactions this is all happening before that transaction gets included in a block based on the analysis from firewall safe transactions will pass through that firewall into a block processed as normal unsafe transactions are blocked placed in a Timeout for practical

purposes they're essentially getting dropped um so you'll you know I think the analogy here is uh Web Two firewalls um we've had you know 30 plus years of of um you know web traffic screening um in using various models the most recent of which leverages a lot of machine learning um and we think it's a very logical next step to start applying firewalls in the web 3 context to transaction activity because we're now using the internet not just as a messaging layer you know for for financial activity but as a settlement layer um so we have the ability to take all this firewall technology and and

apply it um to transactions and we also have the benefit of of of starting with machine learning so um you know we can be much more uh much more effective real quick I'm sure some folks listening have um are are sort of uh comparing uh firewall to something that exists today which is autop paing this has been sort of historically the mechanism to prevent an attack um relies on being able to front run the exploit so you need to be faster than the attacker and you're front running the transaction with a pause transaction to to to pause those those vulnerable contracts um we've looked at this

mechanism for a while and and and the reason we've invested in and launched firewall is just is because we we think blocking the transaction is far superior to trying to front run and attack and and pause a contract and I'll I'll quickly talk about why so one firewalls are effective against Atomic attacks so attacks carried out in a single block uh whereas with autop pausing it's you're you're much more effective if the if the the attack is sort of carried out over over many transactions many blocks um and we can also stop attack submitted through private men pools we don't need to be able to to to observe it um in the men

poool and then and then and then front run by virtue of sort of positioning ourselves either directly in the transition action flow in the case of a rollup or in embed ourselves into the contracts in the case of a of a D5 protocol integration we don't need to be faster every transaction has to pass through the firewall before it makes it into a block um so it's just much more reliable we're also really effective on l2s um autop pausing is tough on l2s just because block times are faster you a lot of l2s don't really have the concept of a men pool and so you know front running isn't isn't really something you can rely on um and then I think the the big reason why we like the

firewall sort of shape um is that it's a more surgical approach to dealing with an exploit we're only taking action against the attack transaction and dropping that whereas in the case of an autop pause you know there's a much broader impact um and you're impacting a lot of regular users as well so um let's get into some of the meat here so how do we integrate the firewall into a rollup I I mentioned that we we integrate into the transaction flow so how does this how does this work so in the case of most rollups today particularly ones that are relying on like large rollup as a service providers like a conduit or a Cera or gelato or

Alchemy um the RAS provider is running the infrastructure for the rollup so they're running a public RPC they're running the sequencer node um so we rely heavily on um the Raz to to integrate the firewall but what we do is we install a little hook on the public RPC this is often the single entry point for a transaction before it gets to the sequencer so this is what we would refer to as like the narrowest point in the transaction flow and this is where we want to uh position uh the firewall so that we can see 100% of activity what that hook at the RPC does is it routes transaction activity up to to uh firewall we the screening engine in this

diagram uh and that's when the simulation and and um and risk scoring occurs firewall generates a risk score for every transaction Carlos is going to get into to this in a little bit more detail here in a second and and then based on that risk score uh the transaction would either continue to the sequencer if it's below a certain threshold if it's above a certain risk threshold it gets dropped and we've tuned tuned the firewall such that you know um uh only legitimate exploit transactions are receiving uh risk scores above the blocking threshold and everything else normal user Behavior goes through unaffected so this is the way that we

are integrated with rollups like plume and so if anyone's if anyone's listening and you know thinks this would be interesting for your for your roll up we're interested in talking I mentioned that we rely heavily on Raz providers um we've got a relationship with conduit um such that they can they can effectively turn firewall on for a rollup um in sort of a one-click deploy um and we're able to do uh kind of something similar with with the other Ras providers uh as well so for a rollup team there's virtually no Dev work required for you by virtue

of the fact that you you know are are are often relying on a Ras provider to run all your infrastructure for you so the fact that it's more centralized makes it much easier to to integrate the firewall um we have some optional compliance screening as well um and this is this was based on demand from from users uh the original intention of of the firewall was to was to do sort of pure security exploit screening uh but based on user demand um we've we've added a an additional module um screening module that's situated immediately before the security screening so we can do things like um ofac sdn screening prior to the security

screening as well um and we can we can add additional modules as well too if if users have have specific requests okay I'm I'm going to stop sharing Carlos is going to reshare and walk you through kind of how the detection Works how we use ml um and then at the end like I said we'll follow it up with uh with um a few demos great thanks Andy let me find my screen should be great so well and they said Carlos I'm the head of AI at fora and here I

want to explain a little bit how we are actually running this detection and like when are we finding when a transaction is malicious because this blocking system is awesome but again you need to have in an automated way in a fast way and as accurate as possible way to understand that a transaction is actually malicious right because otherwise you are stopping random things and you're annoying people and you are not really providing that much security so the the way it works is if you remember what Andy Show before like this diagram of where we are in we are implemented into the sequencer that we go up what happens is that there is an engine behind it that looks at the transaction and then it runs the AI

system that actually determines whether a transaction is malicious or not now how does that work so at the point that we are so when we are starting a transaction we start with this transaction input right that in the end the input when you are when you have a transaction that is sent to the sequencer you have who is sending that who is sending the transaction where the transaction is sent to and what is the call data so what is that person actually doing and that's all the information that you have right that's definitely not a lot because the only way at this point to actually be able to determine something is just by looking to the past or oh is

this people is is this address involved in other attacks whatever and that's not fast um pront to error hard to update and it's like very much annoying so what we do is like we do a simulation and we have the chain State we have the input so we can simulate what the output is going to be and that gives us a list of information that we can actually model and then pass into our data so on top of like the from to and the C data that I commented before we get um the traces so what is actually happening transaction which um addresses calling where with which type of call

whatever and like what is actually the result of that happening so the logs are the erc20 transfers and so on and so forth so this is the extra information that we are getting from that we already have like a lot of information of the things that are actually going to happen so at this point we are not we are looking into things that are actually going to happen you send this transaction you are expecting this to happen you want this to happen so this is already showing the intent from the person sending it so um from here what we do is we model this data into a way that we can fade into uh machine learning model this machine learning model is something that

it's custom to what we are doing so we are not using a generic LM that is running we are taking the data we are taking these traces the logs and the input that we have and we are modeling in a way that we can actually fit it into this model that we have strained with thousands and thousands of transactions from the past and that model is in the end what is going to give us a risk score again uh this model it's something that it's created specifically for this model the data that we are using is public data from attacks that have happened beforehand plus like the millions of of transactions that are

not malicious because in the end most of them are not malicious plus we are using the expertise that we got like from working on the network at the beginning when we were doing monitoring to to have like this expertise of like okay this is an attack this is not an attack together with the data set of the public attacks which are like much bigger and so on we end up having a very rich data set which is fundamental for machine learning models work like machine learning when you don't have a good data set to BU it up it doesn't work at all so it's very important that the data set when doing this thing it's solid and and we have achieved like this very good data set that allows us to have

like a model that performs quite well and there is another thing very interesting about how are approaching this machine learning model at this point like when you are running or like when you are expecting like what what has been happening for uh monitoring or like trying to detect attacks is like there are a lot of like hard rules that you need to check and like a lot of those hard rules are coming from the past like for example have you used tornado cash or have you used any of these mixers to fund your account and if you did that then even if your intentions and what you're going to do on chain is completely

benign people are going to put a flag on you and like be much more wary of what you're doing and so on and so forth what we are doing here is like we are only looking at the transaction itself so we are doing this detection in a St in a stateless way and by stateless here I mean that we each transaction it's a world by itself we are not looking into what that the account that is sending the trans action is doing in the past we are not looking at if it has sent 70 contracts and all of the mar issues if what you are doing at that particular point because it's a transaction that we are looking at it's not malicious then we are not going to stop it so we are just looking the point in time of the things that you are committed right now

to doing and not anything that you have done in the past you want to use tornado cash and then you want to use everything legitimately or good this is not going to Anno you and this is a little bit what Andy was commenting before about more surgical that we are just looking at the actual malicious activity and not like all the context around it and yeah um so we have this transaction right runs the simulation we model the data the model runs over dead and what we got in the end it's a risk score the risk score in the end is a number between zero and one and this is like something that can be configured depending on how risk ofs you are like everything over 0.8 which is like what you can see in red in this

graph is most likely to be an attack like there is a very high chance that there's an attack if it's orang we are wrong a little bit more but we also finding some smaller attacks and then if you are okay with having more false positives you can bring down a little bit your risk score but by default what we recommend is to go at 0.8 and then obviously the closer to one the closer the model thinks that it's an exploit and the most like it should definitely be stopped at that point in time but yeah all of this to say that in the end we have this transaction we have this super cool custom AI model and the end is like a number between zero and

one and then it comes back into the the flow that Andy Show before so let say this is the risk score is it over threshold yes no and then it gets a stop so this is very good and I have telling stuff but I also need to show you how it works because if I did all of this and then we would have not stopped any attack then it would be absolutely pointless but that's very much not the case so these are the numbers that we are having when we are running um all the attacks that happen between October and December with a model that was trained before October so the data that we are using

for for showing you this none of the attacks were used in training which would be cheating completely because then the model would knew that those are attacks but we are not doing that we we froze the model with all the data we have up until September and then we run the model over the last three months and when you do that with that version of the model 93% of the funds that were stolen that were like around 20 million between the three months were sto that's around 19 is out of 20 million that could have been protected with this automatic model right this detection and then the other side of the coin because technically if you stop all transactions you would have you would

stop 100% of the stolen funds right but then everyone would be very annoyed because nothing would have happened so we need to make sure that we are not saying that something is an attack when it is not an attack for that number it's what we are explaining that this false positive rate which is like with z two% which translated in a way that it's like much more intuitive that's like one false positive every half a million transactions so to explain it in to explain it a bit more every 500,000 transactions that we analyze if there is no attack among them we are expecting to be wrong once so 500 transactions one mistake if there is an

attack we are expecting to have two transactions one that is the actual attack and one that would be the fake one so this is a number that um keeps getting better because we keep improving the model and I will also speak a little bit about that um but again like one every 500,000 it's already a very interesting number um I want to show you like for you to see that the numers um are not like completely off like this is the 93% of funds lost between October and December that I commented before is like in October there were like around three million stolen and then we would have definitely 86% of those November it's

around 15 million and we were like at like 14 and a half or so December um 8 around five million is 88.7 per s will be defended with that and something to consider with that is that yeah those are the numbers that we had from the data from the model that was trained up until September but like the model is not trained up up until the end of September and it's frozen and we are going to keep using the same one this is something that we keep training and we keep improving so we have in place like an mlops system that really what it it's it's devops for machine learning it

mostly is a way of being able to make sure that the model is still performing and keep keep running metrics on it and making sure that it the performance is not degrading and whenever this thing happens and for example like in in October there were some attacks that we were not detecting towards the end of October we would take all the data that we had towards the end of September plus the attacks that we wouldn't find in October so that that type of attacks whenever they happen in the future they would also be found and that happens in both ways so it it doesn't happen only for when we don't find an attack it also

happens for when we do a false positive so whenever we are running the system and we see that we raise an alert right and we stop a transaction we then analyze whether that transaction was uh a true positive so was it actually an attack or was it not if it's not attack that transaction goes into the pool of data so that to train it which means that this type of false when there is a false positive that happens a couple of times those couple of data points are going to come into the data set and the next version of the model is not going to be wrong for that type of false positives which means that the model keeps improving as in having better

recall but it also keeps improving as in having a better false positive rate and this is why I was saying before that having this very good data set is extremely important here we are increasing the data set but just by very specific data points that we know are very important because it's where the model actually got it wrong so we keep improving it improving it improving it and this is a system that it's mostly automated and keeps running on the background and it just make sure that it keeps working and the detection is not going to deteriorate and yeah that is like overal idea of how the AI for the system works now I'm going to send it back to to Andy

so that hit us a short um nice um maybe I want to answer one relevant question uh before I jump in uh J Kumar he asked can you tell us which change the particular performance data uh related to yeah so for the recall it's the biggest um VMS so it a lot of the attacks that were happening are in mainnet or PSC like for example for the example that we had in November out of those 15 Millions eight and chain eight and a half or so are

from an attack that was in Phantom so we are looking into this mainly the bigger attacks into the bigger chains the the false positive rate it's an average across chains so there are some chains where the false positive rate is a little bit better there are some there are some things where the false positive rate it's a little bit lower but this is like an average of having um 5 million transactions in main have five million transactions in polygon 5 million transactions in base and then doing the average of how many false positives we are generating in there thanks Carlos if anyone has any questions on the performance stats um feel free to to drop them in um Daniel I

see your question too sorry I didn't want to miss that um if a Dap is on the L2 and doesn't want their transactions to go through the firewall is this an option and if so how would it work so if firewall is integrated into a rollup today we're screening 100% of activity um initially Ju Ju Just for security right I I know I mentioned compliance but um that's that's not sort of turned on by default only if a chain specifically requests it um and that's usually in the case of like more uh rwa focused chains or or when you're dealing with um asset classes that just have more regulatory scrutiny um the so it's on by default for

security screening um we aspire to provide opt-in and opt out um functionality we're not there yet something that we want to work towards um so you know I hope I hope you know hope hope we get there um you know at some point this year yeah but but for the moment it's the it's the it's the l2's um decision and frankly Daniel I guess just to to give you a little bit more context into why they would why they would turn it on you know some of the feedback we've gotten from protocols over the last three and a half years is a we want to Outsource the security function as much as possible we spend too much of our engineering Budget on audits as it is um

and I think um you know rollups um assuming some of that security cost and socializing it across all the all the protocols in their chain makes a lot of sense just economically um and for what we're screening for which is very generic um threats um I think it's Al I think it also makes a lot of sense to apply that um across the board um so so yeah that that's the way it works today uh what's the inte sorry I'll take this other question too since we're talking about um rollups what is the integration effort for

rollups so like I mentioned um before most rollups rely on a rollup as a service provider to run their rpcs and sequencers and so the easiest integration is actually to work directly with the the Raz provider and they can turn on firewall uh at the RPC level for you so from a Deb team standpoint the rollup doesn't need to do anything uh other than sort of just give the thumbs up you know to a team like conduit or Caldera or gelato and then we'll work with them we'll work with them to to turn it on okay all right keep the questions coming

um we'll we'll we'll pick up the Q&A uh at the end here all right okay I'm going to walk through a couple of examples um so Carlos explained kind of how the the screening Works behind the scenes I wanted to show you what the output is uh from some of the testing that we do we're constantly testing and tuning the model against um different different chains recently we were running tests for Inc which is the L2 from from

Kraken um and this is this represents two weeks of transaction activity that we ran through the firewall so you can see the risk score distribution for these transactions now now we didn't get into this earlier but um 08 is the typical blocking threshold above which the firewall would drop a transaction and the model's been tuned to that number um firewall users can sort of you can move it up and down if you want um but but the like I said the model's been sort of optimized for that for that 08 threshold so assuming in that two weeks there were no attacks you would expect

to see every transaction with a risk score below that that blocking threshold and when you look at the slide you see all transactions in green so they were all actually below 04 so you know this is this is representative of you know every transaction sort of looking like normal user behavior um it's also representative of probably didn't have too many high dollar transactions um in this sample either and the vast majority received Z 0.0 so very very benign transactions um there were no public exploits during this twoe period that we know of so from our standpoint this is what this is perfect

detection I'll show you another example for base um this one does have an exploit in it um so this is a test we ran back in April um we looked at 87,000 base transactions this is this represented a block range that we knew had an exploit in it this was the summer money attack from earlier uh last year um and so you'll see again vast majority of transactions receive a 0.0 risk score you see a much smaller percentage um with risk scores between zero and 08 and then you see one uh you know up there uh on the on the far right which probably received a 0.9 or 0.95 um so that was the exploit transaction so again from our standpoint this is this is perfect

detection we we would have blocked the only exploit we would have we would have um you know uh cleared every other legitimate transaction and no no false positives okay all right I'm going to share it uh I'm going to go to our dashboard and I'm going to kind of show you in real time what some of the checks look like give me one sec to switch here okay so this is our firewall dashboard

um if you were a user of um of fora you would see um this is this is the dashboard that you would you would see I'm going to switch to one of our demo accounts here and um we've got some transactions preloaded up here and I'll also I'll also grab a random transaction from from uh ether scan 2 so this is an exploit transaction we're obviously running these checks um sort of postprocessing um but this is what is again is happening in real time on the back end um so this was an exploit transaction it was just scored at 100 um which is great

because it was an actual exploit this was the loss amount involved and you know you'd see some um some of the balance Chang stages and Trace data here too so you can um you can triage it in real time um now I'm going to take a benign Transaction what what I assume is a benign transaction from ether scan uh and scan this one um yeah okay so this was a simple eth transfer from one wallet to another risk score of seven um so this is what the vast majority of transactions are going to look like uh on our on our back end okay all right well Carlos and I covered

the material we wanted to walk through um we can now open it up for more questions from the group um jaar you asked why is it scored seven for a eth transfer um Carlos do you want to answer that one yeah because when the risk is like very small as in like an transfer the model itself is actually going to give us zero but if the model is zero then it goes according to how much um what is the value that it's being transferred so for example since it that was around I think it was $700 or so so it would go around

that but like the model itself is going to give you zero risk and that's it like it's just like the the risk is not exactly the result of the model there's like some tweaking over there to make it more intuitive great question J if you have any other um questions related to screening and performance let us know um Daniel I see your next question is fortifier wall available for l1s and if so how does it work um given the way given the architecture of most l1s they have you know decentralized or RPC and and and um and

block building um it makes it challenging to actually plug it into an L1 like like ethereum um and so to the extent that you've you're you're a team building on an L1 um we can integrate directly into your contracts um we're working with teams like baly and Oiler to do this as well they're deployed on Main net base Etc um and so um in that case we're we're essentially you know embedding a little bit of logic into your contracts um that that require these these Security checks to occur um before the transaction um gets gets processed so it is possible on

l1s but we just need to move the firewall um up to the up to the to the D5 protocol layer good [Music] question Nathan what chains are we supporting so um we can we can support um any L2 um that has you know um uh it's easiest like I said to integrate if there are some centralized components either the RPC or or sequencer it makes it easier for us to plug in if not then it starts to look

more like an L1 you know where everything's distributed and it's it's harder to it's harder to capture 100% of the transaction flow um so I would generally say any any any roll up you know you know we can um we can support um so l2s l3s app chains Etc um and then to the extent that a a D5 protocol is deployed on a major chain like ethereum main net or a basee or an arbitrum or optimism chains that are un that are just not not not going to embed something like a firewall natively um we can do it directly into the protocol then Nathan you also asked um you had ven Network um on the webinar

last time can you explain sort of how for's approach differs from from theirs specifically yeah so I think the big difference uh is that VIN is taking a um a sort of decentralized approach to um to uh the the firewall Network and and relying on other entities to do the to do the screening um Florida is a we're taking a much more centralized approach um to the firewall um today and we think the advantage to that is that um we don't have we don't have as many thirdparty dependencies um and uh Carlos sort of explained you know how the how the

screening works I think our our our screening relies heavily on AI and and machine learning which is it learns much faster it's much more scalable um and I don't know how I'm sorry I don't know how how Vin sort of I don't know what logic they they rely on um but ours is very AI ml ml based and so I think we can adapt really quickly to to market trends um and we've got a lot of control over you know making small tweaks and performance um so I think I think particularly with respect to like the screening logic that's used doing that in a more in a more centralized way is just is just much much more uh effective and and scalable if you're relying on a

a network of teams to sort of improve things on their own I I just think it gets really messy and it's it's you know you have to then worry about are you properly incentivizing all the participants to to do the right thing and so it's just a it's a it introduces a whole set of different problems we just want to focus on you know um building the best detection tools that we can and then making the integration as easy as possible for teams jar you asked another another good question is it possible to detect uh pump and dump token scams uh or does the model require actual exploits like loss of token for scoring Carlos can you talk about the coverage today yeah this is a very fun question

because some of the false positives that we consider false positives are actually this type of scam tokens that we are detecting it it's just that we are in our numbers considering them false positive because we are since we are focusing on detecting actual attacks and hacks we consider this scams to be like a semi different category right but there are some of these type of attacks that not attacks sorry scams in this case that would we also are stopping or we would be stopping it's just like we are considering them for positives it's not in general because like it doesn't work for all the types of this pump and dum and we are not optimizing towards that so the model is not specializing to

doing that it's just that they from like a transaction itself perspective some of these type of scams look similar to an actual attack and since they look like an actual attack the model thinks it's an attack and stops it but we are counting them as false positives they are scam so it's still like happy like happy mistake I guess like I wish all the false positive were scams because that would be very good so yeah we find them we are specializing towards them it's something that we are it's one of the potential research lines that we might consider into the future but like it's not our Focus for now

yeah Jack I think it's interesting to to think about what some of the other um categories of risks or threats might be um we obviously started with exploits that's kind of the first module I think that's if you want to think about it that way we've had teams specifically request you know basic compliance checks and so we've introduced the compliance module I think um we expect to add you know a much longer list of different modules that are security Andor you know compliance related um but it's just going to be based on on user demand good question okay Nathan you posted a question here from YouTube live um looks

like someone was interested in just getting involved um as an ambassador and expanding visibility and um yeah so uh if you go to for.org um there's an intake form for U anyone who's interested in firewall either as a you know becoming a user uh becoming a partner uh Etc so I would just I would I would um I would pass the the for.org link along to them and just have them go through the fill out that that simple form the Google form on the website and then someone from the team will get back to them okay Carlos next question

does it detect approved type of scams where loss of tokens is in another transaction so this would this is be more like a fishing yeah yeah it in that case what it would detect is not the approve but the loss of tokens know if you have a scam that it's dividing those two things the model since again the model is thought to be looking at attx so it's looking at like transfers of movements uh like transfers of token and so on approvals when they are done by separated don't necessarily do anything for the token but like even if you do it in two steps where you first approve and then you move everything this is going to get allowed but this is not because it is still

tricky even if there is not an approval on the same transaction so it finds it just in the other way as what would be um the first thing that you would think like okay the app this approval is weird we stop it it's not how it works it's like this token transfer is very weird and that's what it gets stuff I think scams is is probably another category of threats which impacts end users more so than you know protocols um but it's it's something that we've worked on a lot historically

I don't know if anyone's familiar but um but we have an API currently that we sell called the scam detector and it's used by a lot of different compliance teams and and wallets um so they take all that labeled data and they you know they they use it to warn users about um um interacting with malicious addresses and so you know in theory you know it could be you know it's possible to extend our screening to include you know a much broader set of of of of things okay thanks for the heads up Nathan all right so we we've got 15 more minutes um technically but uh you know if there aren't any more questions U Can can I

ask a quick question uh sure maybe it's too technical of my ignorance sounds like a big part of it is remote procedure call is that the issue that you have sort of the ability to do things remotely about the the monitoring framework itself or is it not so so why is it uh why is where where do the cost of the monitoring stand for it's the is the AI logic or it's the is is the going outside is that what what are the where do the major cost happen of the monitoring does my question make sense well is is the question around where's

the where's the the the cost or the bulk of the effort amount of the effort happening yeah yeah like why is like you are you are like you I want you to be 10 times faster where so you could obviously buy more fancy Hardware but I think the issues I'm trying to understand why is it you you you even mentioned that speed is an issue right for you yeah let me okay let me Carlos before we we answer let me pull the slides back up just for yeah reference here okay so M let me let me say one thing

first um so in terms of latency the round trip from RPC up to the firewall and then the firewall back to the RPC with the risk score is between 50 and 80 milliseconds on average that's our P95 metric um so it happens so that that screening happens fairly fast one of the reasons why we can do screening so fast is because as Carlos mentioned in his uh AI section we're we're doing State we're doing sort of

stateless uh analysis so we're not we don't need to query to get your to get you know an addresses full transaction history we're not looking at a bunch of external data sources we're just looking at the the the transaction or simulating that transaction extracting logs and traces running that through the email engine generating a risk score so it's fairly contained which means we can do it fast if we had to if we had to do um if we had to look at a bunch of external things now we're dependent on the performance of those things and and it it it would likely slow things down um so that's I guess that's that's one sort

of um one way to answer your question and then I you know we can um we can set up as many you know engines as we need to to sort of scale screening based on transaction volume so we can sort of throttle up and Throttle Down the same way would with like Cloud you know um Services um if we have a you know we're seeing a ton of we're just getting a ton of transaction volume on the on the rollups that we're screening for example so so we can do some stuff on our end to um to improve performance Carlos you want to go yeah that's a

byproduct of since it's stateless it's transaction by is something that just runs by itself right so like simulation and then the the screening on the transaction itself it's something that just go each one of them is completely independent from the others so we have complete horizont it's like embarrassingly parallel right so we have like this complete horizontal scaling possible that if we need to do a lot transaction a lot more transactions we can just put like a lot resources in horizontal and we don't need a bigger machine we need more machines which makes it much easier and that it it allows us to auto scale and so on then time wise there are like two parts right like you have like we

have simulation and we have inference simulation I mean both as expected if the longer transaction it is the most complicated it gets and that's that think that it's slower but it's still around again as commented like P95 is 80 milliseconds I think we were testing the last time so it is going very fast and there is still like we can improve the gpus that we are using for inference and like there are like several things that when each one of them individually needs to be faster there's still like some performance that can be squeezed out in case where actually shaping 50 milliseconds is relevant oh we we have question from the audience but before that the follow on

question you're saying you are stat less so uh this actually are there some limitation are the things that will be hard for you to detect because there's some C between different events or you don't see that as an issue um it is uh something that potentially becomes more difficult and now I'm coming back to one of the questions from the audience before about like going back to scams where you separated scams into first having the approval and then a different transaction having the transfer of tokens or something like that when you start separating things into different transactions it looks like would be easy to bypass right like

it's like ah okay if I just have an attack and I just divide it in two then the model is not going to find it but in the end you're still going to do the weird part or like the suspicious part where you are having all this Weir transfer of tokens between different ways and all that movement and all the calls that are going to happen and up until now there are there have been a couple of attacks that actually follow this part of first having some approvals or like doing some transaction that was like a preparation step and then a transaction where things were moved and what has happened in all the cases that have happened since we have this model is that the first part was not detected because it didn't have this type of anomalous pattern that the model

is looking for but the second part where the tokens were actually moved actually was detected and would have been stop it so in the end even if things are approved they cannot Mo move afterwards and there is like security just by stopping the second part even if things are divided into sepal Parts yeah this was like a very good question that we definitely had when we started doing like H how is this going to work there are some questions here um yeah yeah I'm going to go to the Dumar one um how does he identify the

marici intent in the second transaction where the message sender is not required to be involved in that transaction the answer to that is that it's not really that it's looking for the intent it's looking at what it's actually happening and what is what ends up happening is that these tokens are like moving from places where they are not moving usually from to worse places where they are moving usly from or in a pattern that it's like a bit weird or like there are like a lot of calls that are not happening often with normal behavior and then that is the thing that it's detecting so it's not looking into any part any one particular Behavior it's just like okay the combination of the things that are H actually happening

in this transaction is in in the end it's similar to previous attacks that we have seen because that's how supervis Learning Works in the end um another one that what are the biggest threats that AI agents bring to ethereum and how is fora helping to face them H it's interesting question um the second one because it's a little bit more straightforward the way that we are helping them is like if it's in the end since we are running stateless we don't care whether the

entity any a transaction is a human it's a robot it's an AI agent if they are doing something weird on chain we are going to detect it and then or like and we are going to stop it right so the fact that it's an a an AI agent doesn't make any difference for us from the detection perspective the what are the biggest threats is I think it's a very general philosophical question of like how AI is going to affect things and so on my personal opinion is that right now the main thing that AI is going to do is make things a little bit easier

easier for users who are not so knowledgeable about technology and things like that because it's very easy to interact with current AI with just speaking with language right and that's something that it resonates a lot with us as humans because at how we communicate and it's a little bit easier than having to program or anything like that the threats themselves are going to be automations that are a bit more clever than just following rules but like that's to be the point of Al of of of this chain in general right like to be able to have like program programmable stuff this is just like an extra step towards just like normal heris sixs programmable because it can

learn some patterns and it can do some things that are a little bit more abstract to us but in the end it's not going to be so much different than anything else before okay there's another question um can there be a decentralized version of fora firewall that works only on either execution consensus clients for modelar blockchains yeah I think um we anticipate block building decentralizing on l2s and l3s um and so we're already starting to work with teams like flash

spots and others on kind of how to embed um firewall features into either the you know into Builders um or other or other places where you know it makes sense prior to prior to to processing um so I think I think the think the answer the the easy answer is yes um I think the the key component to the firewall though is the is the screening engine um and we're constantly Carlos talked a little bit about this when he was talking about the ml Ops function where we're the model's constantly getting

retrained uh based on uh false positives that are detected and also exploits that are observed and so that Ops you know sort of motion needs to be there so that we're constantly learning and adjusting uh to the market and so I think from a from sort of an infra standpoint you can probably yet there are there are obvious ways that we can we can decentralize uh the firewall but I think to if you're optimizing for performance uh on the detection side having some team responsible you know like like like us like Carlos respons responsible for you know making sure that that engine is

performant and that it's constantly updating uh in real time I think is really important Dr um if you have any other I guess would love to to brainstorm with this uh this with you so um if you want to if you want to ping one of us I'll just uh I'll drop my telegram handle here um anyone who was on the call feel free to reach out to me directly and and we can we can continue the conversation okay so I think we uh Andy and caros do you see more question I think we are we

are good actually it sounds like you are a very good audience and you actually kept the the conversation very interesting thank you and it seems like you're building something really substantial so thank you good luck uh Happy New Year and we the the recording will be available soon and I'm sure you you'll hear about it and thank you for the beautiful presentation thank you a lot and looking forward for the next DSS webinar and looking forward to for you to contribute thanks a lot thank you mly thanks all for joining Carlos thanks Andy bye thanks a lot