# Hunting and Monitoring for On-Chain Attacks | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 1:41:14
- Watch: https://streameth.org/watch/yt-G4esm_AQOOc
- YouTube: https://www.youtube.com/watch?v=G4esm_AQOOc

## Description

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.
https://archive.devcon.org/archive/watch/6/hunting-and-monitoring-for-on-chain-attacks/

Web3 security requires a comprehensive security approach from reuse of secure, audited libraries, audits, threat modeling and security assessments to bug bounties, monitoring, and incident response.
In this workshop, we will dissect a real world on-chain attack, categorize each step the attacker took into four distinct stages (funding, preparation, exploitation, and money laundering) and walk through the development of a heuristic/ ML approach to identify these attacks using the Forta Network.

Speaker(s): Christian Seifert, Dmitry Gusakov
Track: Security
Keywords: security,monitoring,incidentresponse

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

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] thanks for coming to the workshop on hunting and monitoring for on-chain attacks I'm uh Christian Seifert I'm a researcher in Residence at the Florida Foundation I primarily work with the Florida Community to analyze attacks as well as develop strategies to strengthen the detection and protection value of the Florida Network prior to coming to uh the Florida Foundation I worked for many years in the web 2 security space on anti-malware anti-fission and intrusion detection systems both on the brief reach and the post breach side hey and I'm Dmitry I'm from lidar and I'm the leader of the automation team and this weird name is hiding a lot of things that we are working on security on monitoring on protection on code analysis that's all what we are doing in Lida and prior to lighter I've been working as the quality automation engineer for a lot of years and got a lot of experience in both security and quality and I will join this Workshop after the part of the Christian so yeah so the the way the workshop is structured there's there's two parts so the first part is really around a more kind of security research focused um on how you can use monitoring to identify attacks on chain and so we'll dive into some attacks and then the second part Dimitri will uh more work look at kind of how protocols can use monitoring to secure that protocol um the Wi-Fi gods were not with us so there's not going to be any kind of like online exercises uh during the workshop but we've set up a GitHub repo with some exercises and what we'll do here is uh kind of work through uh an example that hopefully gives you an idea on how you can put monitoring in place so we all know that web free is is getting hacked uh chain analysis last year estimated that it was uh 2 billion dollars uh this year we already far exceeded that that number now that does not mean that all hope is lost now one thing um that is maybe a little bit of a misconception is that on-chain attacks are Atomic and that once the transaction is mined there's nothing you can do about it but that is really not the case with the majority of the attacks that we observed um really what happens is an attacker goes to uh these four attack stages so the first stage um they need to have some funding in order to um you know pay for gas and execute the attack uh then they um often prepare the attack that could include like deployment of a smart contract then they exploit the protocols steal the funds and then once they have the funds they really proceed to money laundering and even in the money laundering stage as we've seen last week with the finance hack there's still some actions that can be performed in finance usct uh blacklisted the the attacker essentially freezing the funds um so let's look at one particular example of an attack on kind of how these uh stages manifest themselves on change on chain uh so we'll look at the inverse Finance attack that was an attack a little earlier this year uh 1.2 million dollars were lost uh inverts Finance is a a lending protocol a collateralized lending protocol and so the attack was essentially a price manipulation attack that allowed the attacker uh to um a lend uh or a bar essentially in an uncollateralized fashion so let's look at each of the stages so first of all uh tornado cash funding um so what we see here is essentially that the first transaction to that the attacker account um so we're looking at ether scan here uh one thing to keep in mind is that tornado cash funding is an internal transaction so you don't see it on the main transaction tab so that's kind of the first um First Signal now obviously tornado cash is utilized um you know for privacy reasons um so that in itself is probably not sufficient evidence for an attack but it is a signal so next um a few blocks later uh well actually let me see here time stamps yeah a few a few blocks later um sorry a few blocks later um uh the attacker uh deployed a contract uh that then was utilized to execute uh the attack um of course the contract on etherscan was not verified and so that is again another uh suspicious signal here so this is uh this is essentially the action that they took in the preparation stage again it's it's it's um several blocks before actual funds are getting exploited uh then here what you see is the um the transaction where the uh tokens are actually stolen um and if you look uh in the top left here uh what the attacker uses is flashbots so the transaction was not um in the mempool uh so it was it was directly picked up from from the flashbot network by the miners um so it was essentially a private transaction until it was mined and then you also see that flash loan was used uh in in the transaction uh to essentially obtain a large amount of wrapped uh Bitcoin in order to then manipulate the price um that the inverse Finance protocol relied on uh then here you see uh this is the block SEC the new block SEC Explorer I like this very much uh because they really uh nicely visualize the balance changes that are happening with a particular transaction whereas you know on etherscan you kind of have to understand uh the storage slots in order to understand how much is moved where but essentially what you're seeing here is uh um the receiver that the address on the top that's essentially the uh account of the inverse Finance exploiter they're receiving a lot of rap Bitcoin and usdd and additional tokens and then further down you see kind of where those funds are coming from so large large amounts of a token movable uh movement as as a result of this particular transaction uh and then um lastly in the money laundering stage um what the uh attacker did here again several blocks after the exploitation is to convert essentially all the ERC 20 tokens that they have into native tokens and that is probably a step that is being taken uh because erc20 depending on the implementation can be blocked I've mentioned usdt as an example they have a a block list mechanism uh in in the contract whereas if you have native tokens ether that possibility does not exist and then once uh they have uh essentially native tokens and they use uh in this particular example tornado cash uh to launder the funds and at that point in time the attack is over um and as I mentioned there's these four stages funding preparation exploitation and money laundering for this particular attack it took about eight minutes end to end now that is very quick so a manual incident response is probably not sufficient but if you're thinking about automated incident response now it comes into the realm of possibility to mitigate this particular attack yes please they could certainly do that but they often don't now I suppose there are certain certain attacks there may be some gas limitations that they've run into and let's please make this interactive so there's there's additional questions please please just shout out yes sir yes so the the smart contract it's the attacker smart contract was just deployed using you know regular mempool um and then the the exploit transaction where the smart contract was invoked uh was submitted to the flashbot network I think a lot of times outside so a lot of times with the the like exploit transaction itself it opens up like Arbitrage so the um the Mev Bots like pick it up and then back run it as part of a bundle like how is there a way to tell if it's being submitted itself via flashbots I.E like not showing up in the mempool at all or if it's being in the mempool and then a bot picks it up and puts that I see what you're saying um well you can you can basically look at the you know the flashbot has kind of like a um a UI that allows you to identify the bundles that are being submitted uh so you're able to monitor it that way yes sir hey um has the tornado caches um gotten so good that attackers are not really using peel chains as much as they used to to launder the funds or they it seems like they're doing it kind of just in one one big go here most of the attacks that I have analyzed it's tornado cash Usage Now given that now tornado caches and on the ofax sanctioned sanctions list I don't know whether that's going to change anything it certainly will reduce overall liquidity in in the tornado cache protocol which may make tracing uh a little bit easier so we'll have to see what happens over the next few months thanks thanks so much is it more common patterns and people deploy these smart contracts and do they use address obsfocating because if we can monitor that someone deploys this contract and this contract was funded from tornado cash and it has our addresses it's red flag and we should at least be warning about or there are some tactics when they use some optification I have not seen obfuscation so they get funded by tornado cash and then they just deploy the contract and and kind of this detection logic that you're just talking about where you're saying oh did the tornado cash funded account deploy a smart contract that is actually uh something that we monitor for but now I I seen like for instance uh Ronan attacker um what they did in the in the money laundering stage uh they had you know the exploit account that again was put on the sanctions list so they couldn't go through tornado cash because that honors it they just transferred it to a different account and then laundered the money through tornado cash so there's a little bit of kind of like hopping across accounts that happens at times to kind of break the link yeah but majority use Smart contracts not just direct intervention for eui address say that again so the major case is when people at first deploy a smart contract and then interacts through smart contracts and it's direct interaction with your smart contracts it's a question I have seen that the attackers deploy the smart contract and then directly invoke the smart content okay uh yeah related questions do uh active actively continuously monitor like for such cases like when uh like new account is just funded with turn education deploys deploys uh smart contract right away uh and yeah and again and do you somehow like make it public or like great question I'll talk about that in the next week uh so this might be covering your next two slides on the same realm what is the how much time is passing between this right between the preparation execution and finding laundering is this all done in a couple of hours is this weeks what are we looking at here it was eight minutes okay in this particular case but you know you you see see a broad range now in yeah so just a second one last question uh what percent of attacks are solved and solvable because you know it's blockchains can be the worst place to do anything criminal if we're thinking about uh defy protocol attacks about over half are not atomic uh whereas you know about 45 percent are Atomic I think in the 45 case at this point in time that would be very difficult to solve in terms of being having some time to respond to it but I think there are some things that Protocols are able to do such that the attacker is no longer able to execute an atomic transaction so think of the binance hack last week so basically there the attacker was able to Mint uh one one billion tokens or 1 million tokens right should you be able to Mint 1 million tokens in in one transaction could there be a time lock that kind of delays it where maybe hey you meant 10 000 that goes instantaneous whereas if it's a large amount you time lock it so you're kind of forcing the attacker to span their attack over multiple transactions and then that potentially brings those attacks into scope for mitigation sure sorry no I love the questions that's great um have you seen like an increase in attacks that end up uh in a different type of money laundering schemes like I've seen stuff like since uh what happened with tornado cash I've seen some some of the hacks end up in depositing to curve pools and stuff like that yes yes we certainly have observed that there's still some centralized exchanges that are being utilized as well um but tornado cash is still heavily used but again that that's something that we have to kind of see how that develops it has kind of liquidity potentially goes down in that protocol all right well let me let me talk a little bit about then how we monitor for for these attacks now monitoring we feel like is part of a comprehensive security strategy for protocols um so if you're thinking about a protocol um protocol security strategy there's uh activity that that needs to happen in the pre-deployment stage that many of you uh probably are familiar with like utilizing template contracts like the open sepulene Library uh conducting smart contract audits but but that is not not enough you also need to think about what happens after you deploy your protocol um and as it attracts more tvl and becomes more attractive for uh attackers to attack uh so in the post-deployment stage uh think about bug bounties uh fortnite network is is uh has their Buck bounty on immunify very effective program um real-time monitoring and alerting and that's really where the fortnite network comes in and then kind of relate it to monitoring of course you also have to think about incident response and Dimitri will will talk about incident response um on the Lido protocol and how they uh managing that because if you are getting alerted uh about an attack and don't take any action well the attack will just proceed so forta is is a decentralized think of it as a security and alarm system for web free so it's a decentralized network um that allows you to monitor on-chain activity in a decentralized way and it consists of of Florida scan nodes and these scan nodes run Community developed detection Bots um and I'll talk about detection Bots here in a second and the scan notes they are hooked up to a a chain either through a node or an infrastructure provider and they forward uh transactions and blocks to these detection Bots these detection Bots Implement um rules heuristics machine learning models where they're analyzing a transaction and if they identify something suspicious they raise an alert um the nice thing about this this decentralized architecture is that you get a lot of redundancy right like as as I develop a detection bot and deploy that onto the foreign Network it gets automatically deployed on multiple scan nodes at the same time such that if one scale node goes down you still have plenty of coverage and so it creates some redundancy and reliability um so the fortnite network um you anybody can develop a detection bot and we'll go through an example on how that looks like uh we'll also go through some some existing bot examples so you get an idea of kind of the capabilities that you have as a bot developer and as these Bots uh raise uh alerts they can be viewed through the photo Explorer so think of the photo Explorer as a you know block block Explorer for the 4D Network so you're able to explore all the various alerts that are being raised you're able to examine the network um you're able to search for Bots that are already deployed on the network and let me see whether this this works and I can show you some examples all right so this is the the four let me sit down uh this is the Florida app um app.forter.network and up here you have the link that takes you to the Ford Explorer uh and this is how the fortnite Explorer looks like so you basically able to see all the alerts that were erased uh you know in the last hour or so um for that support supports um uh seven evm compatible chains I'll see my network is not not good um I'm sorry separate Network for oh seven seven Wi-Fi yeah it's okay I have some screenshots so I can show you but thanks for for the tip um so so as you click on an alert you get uh alert detail so here we have uh tornado cash withdrawal alert um you're able to um see information like the transaction that is associated with this alert uh the bot that is associated with the alert and then a whole bunch of metadata uh which essentially contains all the addresses that were touched in the transaction and then down here you see all the nodes uh that um run this bot at this time and so as you see here there's currently six scan nodes that have that particular bot deployed um on the bot search page you're able to kind of search for the the Bots that are deployed so let's assume you want to create a bot um that monitors a flatbot attacks um well before you dive into the developing a bot take a look at what's already deployed on the network um there's there's hundreds of bots deployed on the network today um then from there you're able to jump into the bot stats page again that gives you information around how many nodes is it's deployed um historical information about how many transactions had it has it processed you see the link to the source code the documentation and then if the the bot generates some log data that's also available on this page and let me see here so here we have another alert flashbot transactions you can then jump directly into etherscan to examine the transaction so here you see that it's a private transactions with flashbots um here's the network activity page so this gives you uh essentially information about all the networks that we the 4D Network supports as well as how many node operators um are tied to that particular chain all right let me jump back any any questions do you have any statistics of how many real attacks you you know really captured well um that depends a little bit so so there is there's a concept of precision and recall uh with with Bots right um Precision is essentially of all the alerts that are being raised what is the percentage of of two positives like hey it identified an attack um and then no that's that's recall sorry and then uh a position is how many of those are are false positives right and so you could have a bot that is extremely noisy but has high recall right and so you could say hey it identified that particular attack but that bot is not really useful because it contains so much noise that um it's very difficult to consume it makes sense and so I'll talk a little bit about um a layered approach to a monitoring that builds on top of noisy Bots and then combines the alerts into highly precise alerts uh in terms of statistics I want to say that um that that kind of combiner Bot that I'm mentioning I think it had a Precision of 80 some percent and a recall of maybe 50 but don't quote me on that that's great can I ask one more uh so are the node operators trusted or just so anybody can can run a node now however the the four day network is secured by the fourth token so as you are um if you want to set up a scan node you have to stake for token and if you misbehave uh then your your fort gets slashed but also keep in mind that there's some redundancy in the network and so you could have let's say six nodes that run your your Bot one behaves maliciously and just outputs garbage you still have kind of five that you're then able to utilize to kind of build consensus in a way yeah and one more question suppose I developed a bot that I really you know put some certain blood into and I don't want to publish it publicly but I want to contribute could I either somehow run it here or not so there's a variety of options that you have you can either obfuscate your code and encrypt your alert and deploy it on the for that Network now obfuscation is you know security by obfuscation is is probably not not the best approach um you can also run a private scale node and deploy your Bot just on that note but but then you kind of trading off the redundancy that the network provides uh couples can you hear me through here yes a couple slides back there there was a part of the website that said um something about pausing when an attack is detected and pausing on chain so two related questions um how many roughly people protocols do you have doing that and then also how kind of open to that sort of automated third-party pausing our protocols I don't know of any protocol that hooks up to an alerting system and automatically posits their entire protocol I think there is we need to continue to work on the Precision of the underlying alerts because if if there's a false positive essentially your protocol is is halted and that's not good either um now pausing also I look at pausing as a big hammer are there more nuanced mitigation techniques that you can Implement that again kind of slow down the attacker or mitigates the attack while at the same time leaving your users still being faced with a usable protocol in like time locks could be an Avenue there but I think that is something that that still needs to be better defined and so you know we have a large audience here if you have ideas we'd love to hear hi I have a question is it possible to monitor um governance attacks like you know voting power that changes are there boats for that yes we have we have um on the photo Network there is this concept of threat detection kits which are a combination of bots that detect generic attacks for um a particular protocol type so there is a threat detection kit for D5 for nft for bridges for stablecoin and for governance thanks dimitriat Ely but can you tell me more about timing for example you detect some malicious activity basically we have some developed system monitoring system but we definitely consider that if you find something you should action maybe next block so you should be pretty fast in terms you have a decentralized network it means that you need some consensus between notes and so on so what's your common scenarios of using forta should we manually check what's going on so hire some guys like it exists of monitoring hard technical system like nuclear power stations or a sample check all day is a monitor or we can write Bots but in terms of bots how much blocks it takes to be executed before you found something to really make an action so it takes about 40 seconds from mind block or mind transaction to alert being um consume uh essentially um so there is some some delay uh in terms of your other part of your question should there be a person that monitors I I believe no uh but because just because the attacks are too fast you need to have some automated uh incident response now does that um make your incident Response Team obsolete absolutely not right like even if there is an automated incident response you still need to have a team that then kind of analyzes that and basically it says is was that the appropriate action should we do something else um a counter was another example that I have the Ronin Bridge uh the hack that happened earlier this year that took a week to discover yeah so let me add something on this side uh so first of all uh yeah so speaking about detecting something and reacting on the next block is usually not the case the case is detecting something not in a week like Christian said and the second thing is that we will talk about the how to react on alerts what to do and how to make it really fast and yes you need people here for sure and the details about it will be at the second part of the workshop perfect let um I I plan to Monitor and uh and run photo on mempool level where where are you I'm here us sorry um uh mempool uh currently not however is the bot um um framework the bot development framework is very powerful it's essentially think of it as you know a Docker container that either runs a JavaScript typescript or python so there's a lot of things that you are able to do so your Bot is certainly able to inspect the mempool and generate alerts based on the mempool but it is not a native interface um two Bots I have a question about uh configurability uh the Bots are deployed by the bot Builders are there parameters can they accept parameters from the consumer excellent question so some some Bots um yes are are developed by um uh Builders and then deployed on the on the network but you can also create templates that provide uh you know parameters that you can configure and on the Ford app there is a bot wizard that allows you then to essentially instantiate and deploy about with your specific parameters is there a way to specify the bot um so that you don't have to redeploy so say you want to have a signal at 80 threat versus sixty percent absolutely I like you can you can within the bot have different thresholds and emit different types of alerts it's not a one-to-one mapping where one bot is only able to emit one type of alert able it is or after deployment well after deployment no then you kind of have one snapshot of the bot so you would have to you can upgrade your Bot um or deploy a second instance with other parameters yeah so really it's that's not a big deal we've been doing it for a while in Lido so yeah that if you want to update the values the constants you need to do a redeploy but it is done in such a simple way so you don't need to worry about it on one hand and on the other hand you are 100 sure that the bot is running on the actual values and there can be no changes made by either the photo Network or the malicious software or something like that there's one more question over here yeah sure uh very fast one maybe and maybe I'm running ahead but do you have uh any examples when when this kind of analysis helped prevent or at least minimize damage um requires that the the protocol teams consume Zoom the alerts now um and and then kind of take actions uh quick enough and I think that is still still a problem but we certainly have many examples where an attack occurred and the fortnite network emitted a highly confident alert and so I I would uh reference kind of our blog or or uh Twitter handle uh not prevent no okay not yet but hopefully I come back next year and I can talk about some prevention stories okay good thing here yes sir um how is Ford decentralized how do you manage to to have a decentralized because it says there that the centralized but to detect uh attacks the first second is that why is important to take an attack after it happens if it already happened and in blockchain you don't have a way to revert anything awesome so first of all it's decentralized because because there's thousands of scale nodes that that run these detection Bots right does that answer your question no um well you you have independent uh node operators right that that set up a scan node right so so some of the security Auditors some of the infrastructure providers are running scan notes and so then your Bot is essentially deployed on multiple scale nodes at the same time so it's decentralized that way who's running those notes well as I said like smart contract Auditors infrastructure providers you can run a scale node if you want to uh and then your second question is like why would you want to monitor uh if you can't prevent the the case that I'm making is that attacks are not Atomic and we are able to detect attacks before exploitation occurs and so there is a short time window that allows you to take mitigative action now has that happened yet no I think we we still need to to work on that in terms of identifying what are good mitigative actions and then so that's one part and then the second part is to create alerts that are highly precise so that the number of false positives are low in order to increase the confidence of protocols to then essentially hook up automated actions foreign so I talked about the attack stages and what you see on this slide is essentially a set of generic Bots that are deployed uh to identify activity for each of these stages um so you know tornado cash funding Bridge funding um sleep minting attack contract creation um also looking at whether the eoa that created the contract was funded by tornado cash the fortnite network is not only looking at protocol attacks but also looking at end user attacks so there's a few Bots that are deployed that identify activity like ice fishing or somebody deploying a token impersonation contracts then a whole slew of of bots around exploitation uh and then money laundering but as I mentioned earlier if let's say the tornado cash funding bot emits an alert that is not sufficient evidence to call this an attack right and many of the the individual Bots that um I have listed here have the same problem by themselves they nearly give you a signal but it is not sufficient um to then raise essentially saying that that this is an attack and so as I mentioned uh earlier what we do we have kind of like a hierarchical system so think of all these Bots here are kind of Base Bots that uh generate signal that say Hey something suspicious is going on but then what we uh essentially uh do is we combine the alerts from these base Bots such that they are consistent with attacker Behavior and so essentially uh we will raise there's a bot deploy that will raise a high confidence alert if it sees um a baseball uh firing in the funding stage in the preparation stage in the exploitation stage in the money laundering stage so that is one flow and and basically it combines them based on a common eoa or a common eoa cluster so if if the attacker um you know executes an attack from multiple accounts um and we cluster those accounts together then we're still able to to generate that that chain um now obviously if we combine alerts all the way across the chain then it's kind of too late right like then the funds are already laundered and so what we're really trying to do is push more and more alerting into the earlier stages of the attack chain and so the community is heavily investing in detection bots in the preparation stage and I'll go through some examples of of those Bots that in combination with funding uh generate essentially a high confidence alert and and in the inverse uh Finance attack that that happened there were essentially two alerts fired uh one after the preparation stage and one after the money laundering stage they were both uh highly confident and so inverse could have if they would have hooked up uh to the Ford assistant could have taken some mitigative action um so this is kind of encoded in a bot now for security researchers that want to hunt for attacks um there is actually a um discover new attack Explorer um that a Community member has uh created um that is deployed on on this link right here uh that basically allows you to explore um attacks that are happening on chain that may not have resulted in an alert and let me see oh dang it I don't have it oh there it is um so this is how that looks like so basically it says hey give me all the alerts over the last couple of weeks and then it essentially ranks it based on the confidence that we have on on some heuristic or some some anomaly model that then allows you to explore those so this uh for instance um four stages fired so this was the the winter mute attack and an alert was emitted but as you kind of scroll to the right here then you basically see um attacks where maybe that threshold wasn't met of of four stages being triggered but maybe only three so that Bob did not raise an alert but now you have essentially security researchers that are able to analyze that group of alerts and manually determine whether an attack has occurred so that that is available on on that URL I think it's it's very neat okay it will take some time just leave it as is and it went out any questions yeah um it's on the slide uh hi is there any metrics for the performance of the scanning node because uh if we're talking about the real times monitoring and we may have a very complicated rules to scan also uh you should email reference the historical data as well so how do we know whether a node is uh the hardware is compatible for such a complicated task well there's um there's certain so the the scanners they have certain capabilities right and your Bot May kind of have requirements that exceed those capabilities right um and so then as a bot developer you you need to kind of incorporate logging that allows you to identify whether um whether the scandals have have issues processing what what you're trying to do so is there any uh Matrix that can be Quantified so there's metrics on the bot uh stats page in terms of kind of transactions that are processed or whether you're falling behind in errors uh that would help you to identify issues like that thanks Dimitri it's going to be questioned there and question there yeah yeah no problem is there a some way uh to acknowledge make a in case bot fires so it will make also transaction and update some smart contract that it fired so I wouldn't so I can create my smart contract which will depend on this on this happening so the photo network does not not natively provide that but as you subscribe to a bot there is a variety of mechanisms that you you can kind of hook up webhook is one of it the open Zeppelin Defender product integrates with photo so kind of the logic that you're describing alert was raised take some action on chain is supported by open Zeppelin's Defender um I was just curious if you're aware of any uh contract reputation systems because we talked about like there's the attack of what's actually happening but also something suspicious we've talked about if it's funded by tornado is there anything out there that's actually tracking that that you know of no I mean the block Explorer have some tagging and source code uh verification that's kind of the only mechanism that that I know about now before the community is working on machine learning models to essentially predict whether a contract is malicious or not um so that would be kind of a way of reputation system for contracts but there's probably more you can do if you think about kind of the deployer who is the deployer right you could assign reputation to that and kind of propagate that to the contract yeah so are there any network economics at play here I mean the node operators and bar providers are they paid who pays them how Andy you want to take that question so as Christian mentioned um to secure the network we have node operators are required to stake so you have to stake uh 2500 for minimum and if you do something bad at the node level you can get slashed um the Florida Foundation is subsidizing node Runner rewards so if you meet a certain SLA every week at this point um across the seven networks that we monitor there's different sort of reward um allocations for each uh each of the seven networks but um if you hit a certain SLA so let's say like you're 95 uptime you're going to earn the maximum rewards that week so those are coming from the Florida Foundation right now um it is free to publish a bot it is free to subscribe to that bot right now as well um we are introducing bot staking as well as a lever to reduce spam um we don't have two we haven't experienced too much spam on the network but it is a it's a risk um so that that will that will happen soon um in terms of paying to actually get the alerts it is something we will Implement uh it'll likely be some sort of subscription model so if you wanna so for example like the the uh attack detector feed that Christian was talking about right that Aggregates a bunch of these other alerts there's a lot of effort that a lot of people put into that so that one would probably be more expensive to subscribe to than like if you were just monitoring for like high gas transactions right that bot maybe took 30 minutes to build right so uh eventually yes um and uh right now the Florida Foundation is uh sort of coordinating a lot of this what I'll call like more advanced spot development that uses data science and machine learning but there are other like there are other audit teams that have approached us and want to put really valuable IP on the network but they need to be incentivized to do that right um so yes so we need to we need to enable that and we will it's probably more of a q1 2023 thing yep okay let me let me uh talk a little bit about the capabilities that Bots have and then walk you through a bot development real quick um so as I said Bots are essentially a piece of typescript JavaScript the python code that runs within a Docker container so they're extremely powerful uh you're able to maintain State you're able to reach out to external uh apis um and so let me let me walk through a few examples so this is The Flash loan uh bot so uh flash loan right you can kind of temporarily get some tokens as long as you pay them back in the same transaction primarily used for Arbitrage but also used for Price manipulation attacks so there is a attack a bot right now that is deployed on the network that monitors for Flash loans but then has some additional heuristics that basically say well how much is the profit of uh of that particular transaction in order to differentiate Arbitrage from from potential attacks so it's a simple heuristic um this one is is a rock pull um a bot that basically monitors uh token prices over time uh and this is actually about that um utilizes uh time series analysis um using uh metas uh profit Library uh where it essentially learns based on historical price information to alert on deviations from normal behavior uh the time series essentially is able to take into account volatility as well as seasonality um of um any sort of Time series data so this is an example where you do maintain State and build a model you update the model uh in memory and then able to to alert when when deviations occur uh this one is the exploit simulation and I think this is a really super cool bot uh basically what happens is when a um a smart contract gets deployed the bot monitors for that action and then essentially locally at that point in time Forks the chain locally using ganache and then it invokes all the functions that are exposed by that potential attacker smart contract and monitors whether there is large token movements into either the contract or the deployer's wallet and so that essentially allows you at the preparation stage to generate a high confidence alert that an attack is about to occur before even before the attacker uh submits the transaction on chain um now it is utilizing very simple fuzzing it's basically just looking at you know the functions that are exposed and kind of guesses parameters if any of you work on a fast Black Box fuzzer I would love to talk to you after uh this this presentation uh because I think that would be extremely valuable because then you're able to um you know exhibit um the attack behavior um probably with higher recall all right so uh custom bot development so uh down here is essentially the quick start um um URL anybody can develop a button it is uh extremely easy and I will walk through um using some screenshots to kind of show you how that looks like as I said Bots can develop in Python JavaScript and typescript my background is data science so I'm partial to python so all the examples that you see here are python um so you need to set up your Dev environment so obviously not something that we're able to do here right now but if you go to the quick start page uh it gives you instructions on what you need uh so you need node.js uh if you use Python conda and and Python and then docker um once you have set up your Dev environment then you're able to initialize a bot using the the CLI uh the the for the CLI and basically what that will do is will it will generate a stub of a functioning bot that at that point in time you could theoretically deploy uh to the fortnite network um and let me kind of outline important files that are being dropped uh into your environment uh when you initialize the bot so there is Agent um dot Pi for python don't get confused by the term agent we used to call Bots agents and so you see the term uh interchangeably so agent uh Pi contains the main bot logic and we'll go into that uh in more detail uh agent test contains the unit tests um Docker file contains the docker build file so when you deploy a bot basically what happens is the bot gets packaged into a Docker container it gets uploaded to ipfs and then it gets registered within for that Network and then the scan note basically monitor these registration events and then pick up the Bots from ipfs deploy them and and run them and so the docker file contains essentially um the build instruction for for your image and so if you need anything in your Bot that is not covered by the Python language you can customize uh the the docker file to pull that into uh bot into your Bot and then that obviously is available um readme contains the documentation this is essentially the documentation that is exposed on the bot stats page um I personally when I develop a bot I start with a documentation um because it creates a lot of clarity for me in terms of what what do I need to do in in the bot code uh what chains are supported uh what sort of alerts am I planning to emit under what condition so I start with the documentation also at the bottom here you see test data what is really neat about the the development framework uh um the SDK is that you're always able to back test your Bot so you may have encountered an attack let's say you know that the binance attack last week you identify a technique that's not covered by a bot you develop the bot and then you can basically just back test and make sure hey it actually detects that particular attack which is super powerful um in the agent uh uh code there is the main function which is essentially the handle transaction function that passes in the transaction event and that is well essentially the transaction object all the the usual properties of a transaction are contained in that object and your job as a bot developer is to essentially analyze the transaction event and then emit a list of findings AKA alerts so basically this function gets invoked and you return a list of alerts based on your logic so the the logic that I quickly walk through is a bot that basically alerts on large ustd usdt transfer events um and this is essentially the the stuff that gets created so in the bot you basically have handled transactions and then you admit an alert so here's the alert it's basically a findings append uh creating a findings object with information about the alert like the name description severity type and any metadata that you want to provide in this case the to and from now of course that does not um have the logic yet so let me go through the logic um so as you um as the handle transaction um function gets invoked uh first what you want to do is filter for events that are of interest to you and so here in this particular example we are interested in the ustt transfer events so you're able to essentially Implement a filter that basically says only uh you know kind of parse the transaction event and only kind of give me a list of uh transaction events where kind of your filter logic matches um and so that's kind of the the loop down here that basically then can be assured that you're dealing with ustt transfer events from that event you're able to extract information to from and value you normalize that value and then you essentially um just have a conditional based on on your logic hey if it's over ten thousand dollars now I want to emit an alert so super simple but I know I've been speeding up a little bit I want to make sure that we're not running out of time for the second part um and then you append the finding now when you develop a bot there is a variety of ways you can test it unit tests I love unit tests back tests I love back tests and then live tests you should do just because there's a lot of you know crazy transactions on chain and you want to make sure that your Bot doesn't error out um so best to do a live test locally and then you you deploy um and deploy a deployment of the bot is permissionless so you basically just run in npm run publish um you need to have somatic because basically what you're doing is you're signing a transaction that registers the bot um on the Ford F smart contracts essentially that then the scale notes Monitor and pick up on um it takes a minute or two it basically builds the docker container uploads it to ipfs signs the transaction to register your Bot um and then a minute later then the scale notes that are running on the photo Network pick up that bot and start sending transactions to it and then within five minutes you see um essentially your new bot on the bot stats page and you see it starting processing transactions you see it uh generating alerts and then at that point in time you can start subscribing uh to your Bot and there's a variety of mechanisms telegram email slack and Discord and webhook um that then get invoked whenever you bought raises an alert and that's how that that looks like um as I said for this Workshop we're not we don't have exercises that we do live here but we have set up a few exercises on on this GitHub right here um that get you familiar with the general bot development um uh process and so one is is kind of similar large USD C transfers uh the other is detecting load balances uh and the last one is is more security focused around flashlight uh flash loan resulting in losses of the urine die vault uh and then lastly what I want to call out we currently are running a contest uh bot development contest we've been running over the last you know a year and a half um these are contests that we uh put out for the community uh you can develop a bot and uh earn up to uh 3 000 uh US Dollars and this particular bot um is asking to develop logic to identify the attacked protocol let me give you some context here um often the the Bots basically just say hey this transaction is an attack but it does not necessarily give you context around which protocol was attacked it contains all the addresses but it would be nice if it could say hey inverse Finance was attacked and so this particular bot contest is all about uh analyzing the transaction in more detail so we're able to identify what protocol specifically got attacked yeah thank you Christian uh folks just let me leave all the questions to the end we will have enough time and we will answer them all so just to make sure that the core features that we want to describe here will be covered so first of all haven't depart that Christian just talked about was really excited are you excited so like you can create a detection bot a decentralized detection bond with a really limited skills in coding and that's great and that's really cool and that's what I like about the Florida and that's what we like in lighter about the Ford and Christian tell us a lot about generic attacks detection so like with the all the steps this attack oh yeah I guess there you go oh everything was such so fragile so yeah the Christian told us about the generic attacks about steps of the generic attack about the early stages of detection and it is really cool that everything that is developed in forta is available on public so having this bots on Fort each one of you can subscribe select addresses of your protocol and give get the alerts about like some kind of this attacks related to your protocol and that's really cool but what about the protocol alerts so what I mean speaking the protocol alerts let's do a quick comparison so the generic alerting will allow you to detect any attack that will somehow fit into your Bots logic while the protocol alerting wouldn't allow you to do that but it will allow several other features and we'll discuss it next is the confidence of your prodigal security so like let's say you have a number of generic Bots that are precisely tailored for well-known attacks are you sure that your protocol is secured so like let's imagine we have tons of histories about attacks and if we cover them all with the Bots are we sure that our protocol is safe no not at all uh why because new attack can appear and it can be some modifications inside the attack so that we are not 100 secure and actually we cannot be 100 confident about the security but we can increase this level and we can increase this with the protocol Bots and why we will discuss it just a bit later but since the protocol Bots will be tailored around our protocol it will watch over the everything happening with our protocol okay let's move on so what is the main vectors of the attacks that can be detected by the by the generic Bots the generic Bots detect attacks they are tailored to detect while the protocol Bots are not detecting attacks itself they are detecting some strange changes or some critical events inside your protocol so you might not know about the this Vector of attack but you will definitely know that something is going wrong with your protocol and you can react and that's cool about the protocol bus and the last thing is setup so again what is cool about the generic Bots is that you basically do not need to write them if you are satisfied with the Bots exists that already exist on the for the network while with the protocol Bots unfortunately you should do it by yourself but it's it's very very interesting and you will definitely do it after the workshop I 100 sure so uh we have the generic Bots we have product robots do we need to choose between them no we don't we need them all because in combination protocol Bots and generic Bots will increase our level of confidence so let's discuss the typical protocol alerts and we will start with the things not related to our Tech to any attacks directly we will start with really boring operational stuff but which is also very useful for us so first of all is the repetitive events what repetitive events do we have in protocols like in light or protocol we have Oracle reports we have rewards distributions we have funds deposits from the uh let's say the lighter contract to the if 2.0 deposit contract we have Dow votings and some others can you spot some examples from your Protocols of the repetitive events of things that are frequently happening any okay okay check checking prices from the org okay cool anything else sorry almost zero percent almost is it so it is a now when I speak about uh here about the repetitive events I speak about the things that should definitely happen let's say once a day or once a week okay let's keep this things here so what do we want to know about these repetitive events is it is that if we know that they should happen we should monitor that they are happening and if they are not happening it means that there are some problems or maybe even an attack so we can watch over the Oracle reports and so on and so forth but the one thing that we can do on top of just watching over the events and alerting you oh no there's no Oracle report here that's a problem we can also make a predictions on if there will be a problems with the let's say Oracle reports so we can watch over the Quorum of the oracles and identify which one of the participants are really sloppy and miss the participation or misparticipate we can do these same things with the other words so with the operational stuff we are watching over the repetitive events and trying to predict issues with them but that's not about the attacks yes and our Workshop is about attacks so let's start speaking about the security and from the security point of view uh the first thing that we definitely should watch over is the protocol invariants we will talk about uh executive invariance in details a bit later but what I want to say right now is that there are there can be like multiple invariants in protocol that should be always met and if they are not met it means that something goes wrong and it can indicate that there is an attack so simple examples here is Bridge balance difference so any hack of the bridge will will broke this invariance so some tokens will be minted on one side or too much tokens will be withdrawn on the other side okay we can watch over it uh the issuing of the tokens without actual backup is also the cool example of the invariant also minting nfts unexpected transfers and so on the second thing about the security is first of all the events that should never happened at all yeah so can you spot something except for one on the slide so roles and ownerships transfers to the eoa so you have a huge protocol with a large tvl and then you see that okay the ownership of the main contract was transferred to some unknown eoa don't you think that that's a problem yeah that definitely is and so self-destruct of the protocol contracts also the thing that should never happen and you will see okay so there's there's a really weird things why we do even want to have alerts about it and the cool thing is that on chain you have all the history and you can spot every event but why we want to have alerts here is that because we want to know about such events happening as soon as possible and do not sit here on the S and after that like okay one week ago one of our main contracts was self-destructed so we want to know about it as soon as possible to have the ability to take some actions can you spot some other events that should definitely never happen with the protocol any token transfers in the functions yeah that should not transfer tokens okay yeah for sure anything else so like let's say yeah yeah and that's even can be a protocol invariant you know and yeah changing value from positive to negative where it should never happen also can be the case okay except for the events that should never happen at all there are some events that might happen but should never happen silently let's say yo you have some protocol that that the part of this protocol is depositing funds so folks again deposit funds and withdraw them and again you're a happy guy sitting on a beach and after that you understand that oh my God my prodigal tvl got down by 50 and I didn't notice it so that's the example of the huge withdrawals and that's the event that could happen that's not a problem that's probably even not an attack that can happen but it definitely shouldn't happen silently and you can also have the alerting setup for it also a huge balance challenge changes and the other thing is the ACL changes so if we have a truly decentralized protocol and we control it's not by only one person or like even a multi-seek so we have the precisely designed ACL system we also need to know about each change in the ACL let's move on and since we've already already discussed the main ideas and the main types of the protocol orders we can move to the Practical parts and dive into the examples and we start with the idea of overall bot development so since I'm a former quality engineer in traditional software development there is a term called shift left the idea of the term is that you should start testing as soon as possible like on on the stage of the requirements so no actual software is provided and you also already start testing the same goes for the alerting so if you are one who is responsible for the alerting in your company in your team or just just want to make cool alerts you should start at the very first stage so they ate the ADR at the architecture description record and first of all do a review of the overall architecture of the of the overall idea and identify like some issues maybe known hacks and so on after that on the development stage you should be also involved to make sure that all the events view functions and other stuff is in the protocol so once you will start building the alerting system you will not get into the situation when okay I got this invariant I get it in mind but I have no way or like a weird way of getting it okay cool on the review stage you should confirm that everything described on the previous stages is in the protocol and on the deployment stage it is time for you to either start or even finalize the development of the alerting and once the contracts are deployed on chain the alerting for them should be deployed as soon as possible okay now let's talk about the critical Advance about the things like we mentioned in the things that should never happen or the things that are really really important for us so the first thing is the ACL changes we've talked about it a bit late earlier and the first thing that I want to say here is each ACL change should be alerted even though you can might think that okay that's not a critical thing or that would that would that ACL would never change you should definitely have alerts for it because you never know the exact Vector of the attack and the ACL changes are usually involved in attacks so all all and also granting and revoking permissions for some critical stuff should be alerted with the critical alerts and we will talk about the alert severity in just a few minutes the second thing is ownership transfers and it's basically the simplified version of the ACL when you do not have a separate ACLS you just have the owner and for sure the ownership of your protocol should be never transferred to eoa it should never be transferred to the unknown address and it should be never transferred to the null address and the last thing is this stage changes so it is it's common practice for the protocols to have functions that changes the state and does not emit event but that's a critical change or the changes that just might happen so like let's say you're the commission of your protocol is set on one of the contracts and it somehow gets changed you definitely want to have alert about it so if it is the case when it was done by intent it is your team it is was it was done over the voting that's okay so you just see the alert and say yeah I know that that should happen but if it happens without any contest you you should definitely react on it okay and so some examples of the ACL contracts have no idea where I've put it on the slide so let's speak about the protocol invariance in bit more details I have three basic examples here and I think that we can spot several others so first of all yeah if we speak about the protocols that are about depositing funds then for sure the amount of the tokens of something minted should be equal to the amount of the dep to the amount of the funds deposited for sure the bridge balance the source Bridge balance should be always higher or equal than the target Bridge balance and uh you know the difference here so in the first invariant we have the equality and in the second we have not the not the equality but inequality and invariance of both types why with the bridges we are using not as strict equality because in most cases the funds can move from one part of the bridge to another and it might take time and the movement like on one side and on the other side can take different time but you definitely should keep in mind that if you deposit funds on one part of the bridge the amount of the funds here should always be higher than amount of the ones printed on the other side and the third example is the collateral value so collateral always should be larger than law Can you spot any other examples maybe something is in your mind right now so yeah in my protocol that's the thing that should never be changed or like that's the equation that should be always true for my protocol any ideas but you definitely know oh you I I I'm quite sure that you know okay let's leave it as this I think that in course of time you will have some ideas about it and let's say let's begin the details about the repetitive events so as we've talked earlier there are several repetitive events and there are ways to there are possible issues with this so for the Oracle report it can be Quorum not reached or something like that that's why the Oracle report is not in time and we can predict it by monitoring the Quorum with the rewards distribution again rewards are not distributed in time and how can we predict it we cannot predict it on chain unfortunately but we can predict it with the off chain executor monitoring so let's say we have sum of chain tooling that is calling it function once in 24 hours and over the next 24 hours there were no rewards distribution then we should definitely have the monitoring for the off chain executor here and possibly some other things so there are the examples I think we can skip it for now as we discussed uh at the very beginning that we should start working on alerts at the ADR stage so at the architecture decision record at the development stage we should identify that in our protocol there is no things that are well known in the attacks in the hacks or a well-known vulnerabilities where to search for these things so first of all if you are working in the web 3 for a while you like you you live in the space and you you you definitely heard about some hacks but you most likely you heard only about the the hugest hex so uh do like to to make a created database in your mind of the hacks and of the things that you should watch over you should definitely follow Twitter of the main Protocols of the main like folks tweeting about some security issues and you should redirect uh you can do it in the two ways so the first way is on the design steps of the protocol you confirm that there is no hacks in the protocol there is no vulnerabilities and the second thing is once the new report fires you should do a quick tour of this report and ask yourself can my protocol be also affected by it and do a review over the existing protocol so it might save you time and money okay so as Christian said no alert should be left unacted why so because if you create an alert it means that something bad had happened and you should definitely take the action and if you create the alert that does not require an action then such alert should never exist and speaking about forta all for sure everything that is produced by the Bots is called alerts but there is different alert severities so in my mind I separate two things so like high and critical stuff that's the alert and that's the things that should be acted while the law and info stuff it's kind of feed news feed that you should not for sure take actions but you want to be aware of So speaking about the critical alerts uh once the critical or high alert is fired as we as we said there should be some actions but how you can be sure that these actions will be taken so this is the simplest option here is to set up the on-call system that will ensure that either the the person on duty or the other folks in the team or even the CTO of the company will eventually know about the alert and we'll take some actions in so there's basically two examples of the most famous Ops uh give me a second of the uncle systems that you can use but if your protocol is not that large or you're just a part of a small team you should you you there might be a situation when you will first start with the simple chats so like we did previously before we got the on-call system and the the interesting thing about the chats is that you should also separate the critical feed into the chat that should definitely should never be muted that should be accessible for all the folks and the development team and that they should know that if there is a message in the alerts chat you should definitely do something while all the other stuff can be put into another chart that possibly even can be muted so that you can read at the evening like okay several events had happened So speaking about the actions on the alerts the alert has filed the critical alert has fired and there's a person on duty but it is not him who created this alert and you see the text okay there's something really bad happen but what what gonna what what I gonna do in this case do avoid such situations you can have the thing called runbook so basically round book will consider can should contain sorry several parts the description of the alert itself so the person who is not aware of the alert can dive into the details the definition of the severity so if it is a critical alert or high alert it's for sure it will be in the alert itself but there can be some modifications and some conditions the confirmation of the alert because there is a chance that this alert was was just a fluke and you shouldn't take any actions on it also the resolution the escalation process and some notes and links and if you really wanted to use run books in your company go check out the light example I think that it will give you more details on how it should work and how you can create run books of your own so each critical alert that should be acted should have the round book for this alert the actions on alerts one more time as Christian mentioned and I think that someone from the audience asked this question is okay there is a critical hack in the protocol we got the alert about it we know that the hack is happening and we don't want to be like a ronin Bridge hack no not like our own Enbridge but winter me and Tech where the folks detected the hack and they sit and look the on the attack happening and basically have no ability to pre to stop it why because there were no emergency brakes in their protocol so if you are designing a smart contract and you sh like you care about the security and you assume that there might be there is a little chance but there is a chance that there will be an attack on your protocol please at least add the ability to pause your protocol yes it's not that good for for the people for the users but it might save you tons of money and be a like an the factor that will save your protocol okay and the last thing speaking about the alerts is that one alert is good one alerting system is good and Forte is amazing alerting system but for the critical alerts I'm highly recommending to have a redundancy so if you let's say have the own the alert for the ownership changes in your protocol then take your time and not only implement the photo bot but also consider some other alerting system it might be self-tailored by you or some other solution but having a redundancy for the critical alerts also helps you increase the confidence and uh yeah so if we will have the good internet and so on it will be time to create our own Bots and it is but we'll keep it as the home task so from my part there are two basic tasks so the first one is to create the bot with the operation alerting and it's rather simple as you might see and also following the QR code you will find the activity for example and I collected there the most useful code that can be used for both operational yeah mostly operational alerting and the second thing is to develop a security bot and that's a more complicated task it will require you to get a deep dive into your product or to determine the protocol invariance to determine what ACL changes might be and so on and so forth and since um we want you to like to give you assistance to help you and to uh to be sure that after the workshop you will come back home or come back to the hotel and will deploy your Bot uh there is a there's a chat the telegram chat that you can join and in this chat me Christian and other guys from forta will help you will give you the consultations about okay I cannot deploy the bot please can you help me or how can I detect this particular case or anything like that and for the tasks about the protocol Bots maybe someone of you are does not have a protocol yet then you can take the lighter uh ah no you can look first at the existing light of lighter Bots and also here's the alerting checklist that's the important thing and it follows the idea of the early stages of alert creation so I think that's all from my side that's all about the protocol alerts and now we can move to the questions okay uh so yeah probably I will move with the mic yeah I just want to add something about the photobots configuration so isn't that the person that made the question related to that already left but I think that is worth sharing with everyone so let me start by introducing myself I am Lazaro from nevermind and I have been working with vorta for a long time so I have been facing this configuration let's say problem that once your Bot is deployed and you cannot configure your Bot anymore so you cannot change anything and you will need to pre-deploy your Bot to do some changes but this is only true it's your Bot is the one that knows the the configuration details you can have and your configuration in a deployed smart contract on the blockchain so you can you can change any value on the blockchain and you will notice that so you will be able to change the configuration maybe this is not worth on the ethereum maintenance because changing that values and will be more costly than replaying your Bot but probably on polyun this is fine for you and this can also allow you to do interesting stuff like for example I don't know if there is something already on there someone already on the photo network doing this but you can create a community but something like you have your project and your community is interested in monitoring something so you can create a bot the body is consuming the configuration from the blockchain and you can let the community change the the configuration by governance or whatever else so this is one of the approach I want to share like having your configuration on the blockchain and the other one is like if what you are looking for is Simply Having different configurations in different networks like if your Bot is meant to be around on ethereum maintenance on polygon on BSC and things like that you can have an approach the initialize function of the Bots was not covered in this Workshop but you can check the photo augmentation for that and you can use the initialize function to detect in one blockchain in what network your Bot is being executed and given that you can use a different configuration for you but by only checking what network your Bot is being executed so this is our these are the two approaches that it was I want to share yeah thank you so much really good idea about starting configuration on chain probably not that cheap on the ethereum mainnet but yeah so that's one of the options thank you so much yeah like keep keep your hands so that I can detect who to transfer Mike uh is there any configuration in the bot like I can tell them to start from particular block number or something like that uh yeah sure it is so in the example of the in the fourth example in the example wrapper and you know the lighter Bots you will see that uh there like give me a second yeah for sure you can um when you run the boat on life on notes it will start from the latest block but if you want to test your Bot against the given block against the given transaction against the given block range you should you you can do it simply by using Forte SDK and it is mentioned in the readme's of all Bots although you have the transaction and the block that gets passed into the handle transaction and block function and so you can evaluate what what block is being passed and change you can do it you can do it locally however you have to keep in mind it's a long time right and so it's it's going to be challenging to backfill uh completely hi yeah I have two questions one one is um that handle transaction function that will be executed on every transaction of the future is applied before that and the bot will only look for transactions are ready for some addresses that I it's every transaction okay and then your filter gets applied I filter it with inside them okay and the other question is in our protocol we we're sort of a factory thing so we instantiate a bunch of contracts I'm not sure if templates is a solution but is it possible to create Bots that people can then when they deploy their own instance of all these contracts to just reuse it easily like without needing to rewrite it uh you know like because the addresses will change imagine like instantiation multiple instances of a I mean I suppose that the pattern that you described could be utilized there right where you now kind of Monitor and what what is getting deployed and then uh potentially kind of change the addresses that way okay does that you think that would work yeah but in this case I don't want to change the address I want to like basically set up like a parallel because the owner of that new instance is somebody else the creator of this uh you know it's intended to be used by people that you know are are creating safes right and so but you'll have to like you'll have to configure it for your you're multisig right right um but yeah but the template exists so if you have a similar product or protocol where your users are just taking like a template contract yeah sorry yep yep what project are you working with by the way okay all right I'll I'll connect with you uh hi thank you for the workshop uh just quick question are you planning to expand Beyond evm do like some other l2s or different chains altogether whether we have any specific plans at this point in time but I mean we've been adding uh chain support and so if there's a particular chain that you're interested in talk to us and we'll see whether we can actually there is a small hack that you can apply you can go to the Forte examples and find the bot that is actually monitoring salana it is done like in a pretty strange way but you can do it so right now photo does not support any anything except for the evm chains but in the 40 examples you might find the interesting example on how to monitor the let's say Solana chain or any other chain with the RPC available foreign new boat I need the the nodes some some of the nodes to pick it up and start executing it right or or they pick up it automatically and they kind of because you're saying that uh nodes can select which Bots they're executing so if I create a new one it's automatic so so basically what happens is you when you deploy your Bot you create the the docker container it uploads to ipfs and then you register your Bot with the for the network and then the scale nodes automatically pick that up but can I if I run the node can I refuse I I can say no I don't want to run this boat I don't think so okay so all notes run all the Bots not all the Bots like think of like you know um Bots get deployed on scan uh six or seven scare notes at the same time and then that is satisfied right so these seven scale notes run these sort of parts and these seven scanners run different types of bots uh thanks for this great and interesting Workshop My question is related about some fundamental question about disclosing information how our bot works because if the hacker is not very stupid it's pretty cool to go to Fourth check how it works test this unit tests that no Bots even meant an alert because I can absolute my addresses I can really make some pretty complex logic not to be detected and after that I run the hack and I could be succeed without zero alerting as opposite if you have some hidden Bots which developed by YouTube but nobody knows or limited comment people it could create some surprise for people who do not really expect what happens so what the policy and what's the possible solution just let me start and then Christian will add his thoughts so that's a great question and this idea on the first glance sounds like yeah why the hell do we make these Bots public but on the other hand since the all the photo network is public and since there are many numbers of the bot developers as much as like the more for the developers and the more Bots we have the less the ability to even try to execute your attack against all these Bots since the network is watching over the mainnet and you have no ability like let's say to run all the bots in the photo Network at home I don't think that any hacker would ever do it due to the fact that the amount of the Bots watching over the mainnet on the photo Network right now is really huge and it will increase in time so that's my point here Christian yeah I mean I think it's it's it's a strategy right you could say hey private and I developed them in house and you got coverage contests at the Florida which which I'm personally super excited about is that that it is a Community Driven project right and so you have hundreds of developers security researchers data scientists that basically look at attacks and then essentially develop Bots that identify this attack from different approaches different angles so you get a lot of diversity in the detection approach that makes it harder and harder for an attacker to evade and so I personally think that that is the better approach but I I can see that that there are maybe instances where you're not comfortable to have the bot public and the alert public and there's options on the photo Network that would allow you to do that either through obfuscation and encryption of the alerts or running your private scanner foreign Aggregates some other alerts how so how exactly that can be done are you talking about the hierarchical nature of the alerts like we have some basic colors and then we have like more like a kind of on top an umbrella world that's right so so today uh the the the logic there is is fairly simple it is basically saying if you have about firing in each of these stages then emit an alert and we're grouping together alerts together based on a common eoa or a common eoa cluster but that is very rudimentary I think the next step is really to use anomaly detection to combine alerts together where you're basically looking at each of the stage and say how anomalous is this particular alert and then you combine essentially anomaly scores together to create one overarching anomaly score that you can then rank um in the Middle Road yeah and uh probably I will ask you a question from the technical point of view uh there is a graphql API a wonderful API so that you the the combiner bot is actually not watching over the chain it is fetching the graphql API and consumes the alerts from other Bots and after that creates a decision so as we speaked about the salon example so on the photo Bots you should not you you cannot only watch over the things happening on chain but you should do some other stuff so like fetching external apis or fetching defort API itself and as far as I remember there's even an example of the combiner bots so that you can do it pretty easy so let's say you have developed several Bots and then you want to have a combiner on top on the fourth examples you you can find the example of how to do it really simple yeah and currently it answers your question let me add one more comment there uh So currently the two main interfaces on the bot is handled transaction and handle a block uh there is going to be a new uh handle alert that allows you to build hierarchical alerts currently the way it's implemented in the bot it basically Triggers on handle block and then queries all the past alerts and then kind of Aggregates and combines them but handle alert would be a cleaner way to do it so we're moving into that direction all right um are you aware of any uh potentially big hacks that have been prevented by using the photo alerts no I mean I um there was a question earlier I don't know whether you came in um afterwards so so there are certainly alerts um that the fora Network emitted for for many of the attacks that happened over the last few months but in order to prevent it you need to have kind of these alerts hooked up to then take action um and and we have not seen any sort of automated actions being hooked up to photo alerts yet I think there needs to be kind of two things that happen the Precision of the alerts need to be increased such that you know this this mitigation mechanism doesn't fire on false positives um and then also the mitigative actions currently it's pause a big hammer there needs to be more nuanced actions that that mitigate the attack while not negatively impacting the users of the protocol I'm sorry big protocols no no because not to kind of afford an automated actions but there certainly have been um attacks where and you know Jonathan was saying this earlier where you know not just the protocol got passed but the entire chain got passed right that's last week right yeah so if you want your protocol to be protected and not to get in the situation when it was hacked and then you go to the foreign so what you should do right now is go to the photo app And subscribe to the threat detection kits and then you can you will have time to take actions gay folks any other questions [Applause]