Securing Ethereum in the age of AI: Challenges & Opportunities

Transcript

[music] Mhm. >> So, thank you all for joining us. Um, GM and welcome to this panel of uh Ethereum security in the age of AI. Um we're really going to be talking about a lot of uh opportunities in the space uh challenges as well. Um and it really sort of combines the trio of what are considered as frontier topics right so we have AI we have crypto and one of the biggest things that's been impacted is cyber cyber security um and we do have OG's in the space we have Joselyn from a

we have from Certo we have Frederick from EF and we have the one and only Vitalik so welcome everybody and uh I would like us to start off with a very quick round of introductions about yourself and maybe sort of the key focus areas these days uh you know that that you guys are paying attention to in the context of uh Ethereum security from an AI perspective. >> Yeah. Hi everyone. So I'm a security researcher. Um I've been in the space for almost 10 years. Uh I used to serve as engineering director at trade of bits. Uh now I am helping a with security. Um these day I spend a lot of time doing both code review and building

a rness for for a uh so yeah AI is definitely you know on top of my mind particular for cyber security. >> Hi I'm Misag originally from Tel Aviv University uh but actually in the last eight years working in Stor about formal verification and now in the age of AI and excited to be here. Hi, I'm Frederick. Um, I do a lot of things I guess at the EF, but I focus primarily on security and especially protocol security where there is a big risk obviously for

Ethereum if there are major security issues. So there's a bunch of work being done using AI and agents um to secure Ethereum and uh I'm Vitalik and uh recently uh I've been trying to take a more broad and full stack approach to security and uh like kind of try to identify and like finds the paths um to deal with security issues that like fall outside of the yeah kind of more narrow range of the Ethereum protocol. So that includes uh access layer security that includes um even dimensions of access layer privacy that we don't normally think about and

it even includes some things that go outside of the Ethereum layer and into like things like oper operating systems and uh even hardware and like basically trying to make sure that like we actually have all of the bases properly covered. >> Great. So u we have about 45 minutes for our panel and uh the format I'm proposing is that we'll have a question a direct question to each one of you and u you know after the person answers others please feel free to chime in we want this to be an engaging discussion on this hot topic and we would like the audience to be involved as well. Um we do have um an online Q&A system called

Mircat. So for people who can scan the QR code u do you know feel free to post your questions there and uh if you can't get the QR then you can use your DevCon app and go you know navigate to this particular session and post your question. you can upvote some of the other questions and you know we should have about five or 10 minutes towards the end to uh to take the most uh upvoted questions and have the panelists answer them. So yeah so let's get started. Um the first question Vitalik uh is is to you.

You've you have expressed a lot of u optimism about AI assisted formal verification >> right? I mean even in the keynote this morning from you from Moly lot of others there's a lot of optimism but there's also a skepticism or sort of a a fear um from AI exhilarated math >> and its impact to uh cryptographic primitives ECDSA and others that you talked about and that's coming faster than expected right I mean we we talked about postquantum now we are talking about post AI so how how do you think Ethereum is addressing these two sort of countering dynamics uh in its road map.

>> Yeah, I think my personal high level view is that I am optimistic about the end state of uh cyber security and cryptography and all of these areas. Uh but uh I am very worried about the uh transition phase, right? So I think uh ultimately at some point all of these math problems have some kind of like some lower bound complexity like that's uh the minimum amount of time you need to break them and uh at some point uh you know you get you get closer and closer to the uh the limits of math and actually figure out what those are and uh any individual program I think has some finite number of uh of of bugs and

and uh vulnerabilities. in it. And uh you know, we've been getting better and better at like specifying our intentions in multiple different ways and then automatically verifying that uh they're compatible with each other, which I think is uh the best you can do, right? And uh the uh theory of kind of what we can uh ultimately accomplish like looks to me kind of pretty bright. But at the same time I think the challenge is that uh basically AI and uh along with AI you know like math and uh the ability to like hack into everything is advancing faster than our ability to update

existing systems and even our ability to m make sure of the uh security of anything new that we create. And so I think like at this rate of speed like basically there's a a very difficult uh transition that's happening. And so I think because of that there's this uh kind of all hands-on deck mentality that Ethereum and uh many parts of the online world need to be in for the next couple of years. And uh like I think it will be rough but I also think it will not last forever.

>> So so yeah. So it's going to be a pretty rough transition phase not just for Ethereum but like you said for >> really the entire internet ecosystem that uh we are seeing you know a lot of signs for right. Uh Frederick would you like to add something from from the Ethereum ecosystem perspective? >> Yeah I mean it's it is a big problem in many ways. I think there are many positive things uh with LLMs that we need to harness and utilize as defenders. Um but as defenders even if we find a lot of vulnerabilities we

have some new problems now that we didn't really face previously such as in the past you were for example able to kind of hide uh security fixes in uh like commits that didn't really look like security fixes and people would normally not really look at those commits and understand what it was. Today it's quite easy to use an LLM to analyze each commit and figure out this is actually an issue. The same goes for if there's a patch for a closed source application, they can easily reverse engineer the patches and figure out what's wrong. And when you have software which is critical

and you need everyone to update as soon as possible, that becomes a bit of a problem that I don't really feel is fully solved yet. And that's something that, you know, the security community is going to have to work on. >> Essentially, security by obscurity has never been a thing. And it is def everything is open by default or forcefully now, right? >> Yeah. I mean that doesn't work anymore in my opinion. Um yeah there's that's come to an end >> and and and if we think about it there is even like new thread that we were not considering before like for example uh I think within the next 12 months we have some likelihood that we will see uh a

breakdown of internet like uh an attack on BGP or something like that that could cause like a partition of the network and what does it mean for blockchain right like what if we don't have finality for a day on Ethereum uh I don't think we have today like you know enough testing and the infrastructure to support this type of attack but I think this type of attack might happen you know soon so >> agree if I go back to your question yeah >> I think there is uh maybe I'm saying here something which is not so popular but I think in terms of the interium road map I am a bit worried that the this is a community and I've seen it also in academic we are going too broad

instead of like especially in formal verification. One of the things we've seen I I work in forification and I work mainly in US Israel and we have people in Australia and they did much better than us and the reason they did because they had this one project cell for that they focused on and we were just jumping from paper to paper and we publish a lot of papers I think I'm worried that we are I'm repeating my academic experience now in in the industry we need to pick our battles and we need to understand what we want to secure it is the wallet where is the end to end security and then use testing for modification.

Sounds like what we are seeing with the Ethereum road map. We are seeing that we are very broad but maybe we are we have to pick up like how we want to have the the most secure consensus protocol. How we want to have the most secure wallet. It seems like instead of it we are approaching diversity. We want to m handle all the programming languages. We want to handle all the formal verification tool. We want to handle zero knowledge. We we have a lot of things we want we are tackling privacy. We we are taking more and more properties but I think and again here I'm probably getting myself into trouble and with some people here in the room but I'm okay with it at this point. I think we are not focusing enough. We are

and also with formal verifications like we are we are doing one step and it's one it's it's just a small step. We have seen we have seen with formal verification the reason that cell for was successful is that it it went long way and and going long way and and sort of taking end to end security is very important and and with testing but this is actually I think more useful than we have seen all this diversity. >> I think that that's a very interesting point so we'll definitely get back to that. So diversifying maybe we're not going deep enough. We're sort of very uh swimming in the shallow end if you will.

So what you're saying is we need to prioritize pick our battles focus on a few things and do a much better job at that. So we we'll come back to that uh definitely from a FV perspective. Um, but before we jump into that, maybe a question for Frederick is from an EF perspective right? EF has been running bug bounties and related audit competitions for the the core Ethereum infrastructure for uh, you know, forever, right? And obviously one of the biggest challenges from an AI perspective is AI slop, right? just spam in the number of submissions because you

know everyone has access to let's say if you assume that you have an access to an LLM you generate something that looks really valid but it's really on the verification side that you pay a lot of uh cycles to you know not dismiss something that is actually valid right so how is this sort of new dynamic changed uh things like triage the signal to noise ratio program effectiveness and what are are you guys doing? I mean, what is EF and generally the ecosystem doing to handle this?

>> Yeah. So, I think there was some major shift in after Christmas uh last year as around January this year. Before that, we received about maybe five [snorts] external vulnerability reports per week. uh this came from people who had previously submitted issues that had like quite deep understanding about the Ethereum stack and so forth. And in January we started receiving 150 reports per day and to go from five per week and triaging that to 150 per day is was just not

possible. 150x one per day to 150 per day, right? >> Exactly. Yeah. So, this required us to do some changes. Um, the first one because 99.95% of those were zero issues. It was just AI slop as you mentioned. They were sending whatever they their agents said was a severity and just forward it basically ends.

So what we did to begin with was we introduced this system where you actually had to make some kind of a commitment to submit something. >> So in order to submit something you had to burn the equivalence of $10 in ETH to a burn address. And this reduced the amount of vulnerability reports significantly because then people had to be sure that what they submitted was actually an issue otherwise they might just lose $10.

We still ended up receiving quite a few of them. So we built out this basically triage pipeline um that would analyze all the reports. But this also ended up being a bit tricky because everyone's sent different types of reports in different formats with different PUC's setups etc. So then we standardize that as well. So now when someone submits something it's very clear exactly what they need to provide as proof of their finding. So you know depending on the type of vulnerability that could be a curtosis setup that they need to provide as well as the PC so

that the the agent on our side can execute it and verify that it's an actual issue. Um and with that we're back at a very um at a level which is very manageable I would say but it took quite some time to get all of those things through. uh and at the beginning it was quite a shock to go from five per week to 150 per day. >> So we sort of combined uh staking and proof of work, right? [laughter] >> You have a $10 stake and then you have to show a lot of proof of work to make sure that it's actually a valid submission.

>> Yeah. Yeah. And it also helps the agents because the agents can like you can take your agent, point it to the uh bug bounty page and the bug bounty page explains exactly to the agent what kind of proof it needs and that also reduces the amount of false positives that the people actually get. They can actually verify themselves that this is an actual issue without you know spending maybe a week manually verifying it unless they have deep understanding of the Ethereum stack. How long does it take typically to review uh for >> the pipeline?

>> Yeah. >> Um it's a couple of hours per report. Uh and the reason is that we do this cross hunting as well. So if you submit something that's affecting one client, the agent or triage system will also check every other clients to make sure that you know the same issue doesn't appear in multiple locations and and so forth. I'm curious, do you have a sense of the day? How many pure false positive do you receive?

Um, it's what do you mean that comes into the triage pipeline or just comes from >> after after like all the triging and everything? >> Oh, it's not many at all. I would say the false positive rate is probably well at most in the s single digit percentage probably way less probably below 1% the reason is that it's it has such strict kind of guidelines to produce the what the package so to speak um it's mainly I would say the main issue is that the agents that report to us they tend to overestimate the severity

and the reason is that agents want to please the prompter. So they might tell the prompter that this is a critical severity issue while in fact it's a very low severity issue. Um and then obviously we have to explain why this is the case and that's maybe something I think agents in general can get better at. they need to be more like critics of their own work and like figure out is it actually how severe is it?

>> Interesting. So maybe switching gears and going back to formal verification. So Mully Sera has been working on tools that use LLMs to generate formal spec from informal spec and this morning you said you know the biggest problem is just getting that informal specification where the intent is really in the heads of the developers right how do you actually translate that so you've been Stor has been working on it along with uh other uh projects in the ecosystem but ignoring the hype around formal verification, right? There's obviously a lot of marketing hype as well. Uh, you know, for it's been done for the last

several decades and the thing the hype cycle has gone up and down. What do you think are the realistic nearterm wins for complex D5 protocols let's say a right when it comes to using LLMs and um how do you sort of position that visav the hardest problems that you mentioned right incomplete spec we have soundness you know potentially soundness issues that you said you're not really worried about so you do have um all the benefits But then you have all the challenges. So how should the leading protocols on Ethereum a Moro unis swap all these guys how should they

be uh using LLM's uh informal verification? >> I think it's uh it's an interesting domain and interesting challenge. So my understanding is that the there are two things that can help them beside for modification and they are both equally useful modularity and starting early. uh and basically our our thinking is that and we have seen it with with the because for example a you mentioned that we've been working with them actually since V1 and and the difference if you look into V4 is is a completely different system because actually formal

verification was already in the beginning but before even they talked to us they were thinking of modularity so modularity and for and actually when DeFi was originally plan. I think people were already thinking of modularity but now in the age of formal verification modularity is a key uh and and I don't know again at the moment we are very conservative we work with a client the client working in solidity and and using EVM but maybe we are I don't know if the future will be like this maybe they they will write the code in English and generate code in x86 I do not know >> but at the moment we are very conservative We are working with them.

They are using the existing infrastructure, the EVM. But maybe the future is very different like everything will be written in English. No more solidity, no more I it's hard for me. I I I I was wrong with so many things. But I think it's it's an opportunity and it's specifically opportunity for protocols that especially now in the bare market that they cannot afford audit with teams like trail of beat or us. they they can actually use the LLM and do amazing job with our tool and others lean or or anything they we can do a lot of things now and the opportunity of using formal verification early when we started this I remember

all the competitor was saying get formalification in the end and get PhD is neither are correct you want formalification in the beginning you don't need any PhD >> so maybe uh Vitalik What would your advice be for the top I mean for any protocol launching on Ethereum or some of the oldest ones how should they be thinking of formal verification? Hm. I mean I think the uh and like the yeah I think the first step is just uh understanding what are the properties that you want to formally verify and uh again I think again LMS are going to be

super helpful for that. Then I think for anything building on top of Ethereum, you want to understand like what all of your components are and how security critical they are, right? Because uh like one of the big patterns in application layer security for the past 2 years is that smart contract security has already been getting pretty good, right? And uh the the biggest losses and thefts and hacks that we have been seeing are either on the UI layer or on the layer of centralized components or also potentially on the layer of uh like more complicated kind of components like ZK right like we haven't had huge hacks from ZK but you know Nico has uh announced his vision that he wants to

see the amount of private transactions going up a thousandx and so that's uh also going to become more important um And uh you want to like try to prove whatever properties you prove over the whole thing as a holistic system, right? And not just uh look at the different components separately. I mean I always advise as a starting point to like look at the formal verification work that's already been done on all kinds of different components which includes you know like things like the safe wallet. It includes like m many DeFi protocols. include it's going to include soon work that's being done um in the Kohaku project. It's h going to

start including more and more the ZK work. Um I mean also like really take seriously all of this uh UI security related work, right? Because there are a lot of lowhanging fruit that don't even have anything to do with formal verification. like you don't want to just make a UI that's served from your server and if your server gets hacked even once then uh like the users get a button that claims to do one thing and actually sends all of their money to North Korea, right? Like basically, you know, like really like properly look at the things full stack, right? Like it's much better to have a house where every single door is made out of brick than to have a house where three out of four

doors are made of steel and the last and the last door is made of straw, right? Because uh that's the door the attacker is going to go after. >> Sort of goes back to Mully's thing about sort of prioritizing, right? I mean, it's sort of countering that is, you know, we may sort of harden one of the doors, but then we leave all the windows open. Uh but we'll Yeah. So I think great great point. So maybe with all this advice I guess we are curious to know uh from U Jocelyn how is a thinking about this? I mean generally the leading protocols right how is AI making you rethink your threat model and even your internal processes right what are you guys doing what should we be

doing >> yeah so okay there is a lot of things to unpack on how we think about AI within our processes but you know if we think about like the code itself so we can obviously like AI can find vulnerability you know we know about it and it basically lower the cost of finding vulnerability so we can leverage AI in our own internal processes to do that. Uh but I think we have to think a bit beyond that in also how we are building software. I think we can know it's still a bit experimental but there's like this whole um specdriven development approach where instead of writing the code you write a specification like an informal specification not not a formal one and then you use like LLM to to write your code. This is something that I see

people starting to experiment with smart contract. It's not there yet. I would not recommend people to go you know all in on that. Uh but I think it's an example where we can think differently on how we are building software. These type of things will not probably work for any type of application because it's still like really involved with like how you you are building software. Like if you're writing like you know some back end and things like that in practice >> I would hope people will use like specification but they're not going to do it. However, if you are building critical you know code uh I think that's an approach you can take. um formal verification will help but I think it's important to also realize that formal verification will not necessarily prove the absence of bug because it's going to

depend on what specification you actually has. The way I think about this type of technique it's more about increasing the confidence you have in the system instead of proving the absence of bug because for example you can have a correct reasoning over an incorrect specification that will lead to an incorrect conclusion. So thinking about invarian thinking about what your system is supposed to do uh is a way forward. I think >> I think >> to add something is that you're right they start with the informal but with the informal you can automatically even before generate the code generate the spec and we did it actually in V4 and in fact it saves time for the LLM too because the LLM get code which is less

hallucination so you the the fact and also it's easier we found that LLM writes code which is better than developers it's more amenable to formal verification. So the the the fact that you you you before you generate the core generate the spec in in TLA in CVL in lean whatever it will help the LLM I it will help I agree but I think we have to acknowledge that it's not going to be bulletproof in the sense that there are things that you won't be able to easily express like in a formal way when you want to build any complex system. So you know it's going to increase your confidence but it's not going to be the only solution that you can take. uh and

this is where actually AI is really interesting because we can write an informal spec and that's much easier for developer to think about and to read on because if you have to write like a formal specification of something um even with AI it is difficult if you can write an informal specification which is a bit more wavy uh that's a bit more accessible for for like developer I think >> I uh I also think the prioritization part that Muy spoke about is very important Um and this is if you take the protocol Ethereum protocol for example you know there are some priorities that we have there such as postquantum which Justin and Kev have talked about today. There's uh an effort to formally verify more

parts of the protocol. Um, you know, on the user layer, we're thinking about things such as making sure that users are secure in this type of an era where, you know, you can very easily do deep fakes about things and trick people into doing things and like deploying vast amount of fake websites. It's just a click basically. Um, so you know, we are thinking about things such as clear signing so people can understand what they're actually going to sign. uh transaction assertions to allow them to define what the outcome of the transactions must be. Uh there's things like decentralized and verifiable front ends to ensure that you know the websites

cannot be compromised and even if they are there will be a very clear to the user that you know the website has been compromised so that no one goes into a hacked website and interacts with a malicious contract. Uh and I guess the the next step for like for the DAP developers is maybe figuring out what is the priority on their side like what are the most important areas for them to focus on short term as well and not yeah just yeah they also need to do that. I agree and also the I must admit we we work with a very good protocol and there are risks which are very hard to cover

with the formal verification. You are we work with the issue of the Kalpa and others that there are some issues that even do the best formal verification. You list an asset which is bad and then it's tricky. But maybe again it's a it's a opportunity for you. You go into an elevator and in the elevator you know that even if it's break the elevator would just go slow. I'm not going to die. So if you had mechanism to show us that for example there is a limit of how much you can steal. You can if you can show us something with formal reification or with any other method that there is a limit of the loss or something or there is this will be very

useful at the moment. we either work on this optimistic thing and then you see the Binance hack that somebody use a social engineering and all is gone. So the the if we if we have some kind of resiliency you have some things that says look no matter what there's some limit of how things can get bad that's very interesting we are not in this world unfortun >> yeah all great points I mean switching switching gears maybe back to Vitalik >> so we've been talking about sort of challenges and opportunities >> of using Ethereum you know using using it by humans >> and the challenges opportunities from the AI space, right?

>> But switching gears to let's say agents, agentic finance, right? Agents using the blockchain >> like you said and others as well. Most of the recent hacks, the biggest ones have been offchain, >> have been because of operational security failures >> by humans, right? M >> so given all this all these issues already do you think Ethereum or blockchain is even ready for agentic finance right in in some safe or secure way and if not what do you think we should be doing to make agentic finance safe by default. Yeah, I mean I think

when you do um agentic things other than finance, right? If he wants to be safe, then uh you run all of your agents inside of a sandbox, right? And uh like you give it access to any things that you want it to see as an opt-in, right? And you don't just give it access to, you know, your whole file system and like all of your socials and everything, right? And uh I think you wants to try to bring that kind of spirit um to the uh uh to finance, right? Then you want to figure out like what is the natural equivalent of a sandbox, right? And uh I think like my view on sandboxes is that I think there's like basically there's like you could have a hard sandbox and you can have a soft sandbox, right? And

a hard sandbox is basically, you know, you have preset rules where like in the file system world, for example, you know, you run a browser inside a sandbox, you give it access to like a directory with some fonts, you give it access to a directory with your downloads, but you don't give but you don't give it all give it other things. And in the agentic world, you might say, well, you know, this agent can spend up to $1,000 a day, or this agent can modify my D5 positions, but it can't deposit and withdraw. or maybe uh any operation that's like above $100 requires a human confirmation gate and a soft sandbox is uh a different approach where you basically have some different AI itself be the one administering the

boundary right so you know you have one AI that decides what to do and then a different AI that basically flags like is this low risk is this medium risk is this high risk and uh like you want to have like multiple layers of gating you want to probably have some combination of uh softer rules and harder rules, right? And uh you you want to uh like basically try to figure out like what is the combination of those things that maximizes like basically passing legitimate behavior through and uh not inconveniencing you, right? Because uh if you get inconvenience too much, then you are going to just start like saying yes on all the collects without looking at it. But uh at the same time actually

like stopping um any of the risks right and uh when you think of the risks you know we have to remember they can come from uh different places right like they can come from hostile applications that get downloaded they can come from like prompt injection attacks that are in the text they could potentially even come from back doors that come uh inside of the agent itself right like there it's we don't really have good ways to tell whether or not our agents have any kind of back doors right now even if they're open weight models um even if you know you have all the weights downloaded locally um I also think eventually there's uh or even pretty soon there's going to be uh an opportunity to make agents that are like

more specifically security focused and that'll include some share of fine-tuning I think it'll also include some share of like having an open-source and not just um openw weight uh training pipeline uh so you can like what the uh agents were trained from and uh you can have better assurance that the training data doesn't have back doors inside of it. Um I think uh like basically uh it's not going to be any one solution, right? Like it's always going to be a combination of uh a bunch of different uh like mitigations and tricks that stack on top of each other. And I see security in agentic finance as being very similar to uh like security in

agents doing other things with uh like sensitive personal stuff that you already have. So maybe uh Frederick as a related question right agentic finance on on Ethereum right specifically we have had the trillion dollar security initiative uh from EF where the goal was really to um make Ethereum scale but safely scale uh not just for you know for for people for individuals but also for institutions and now we are talking about agents right uh so there's not really a finite number it could be an infinite number uh so in this in this

context and in this sort of era of uh AI amplified threads is it I mean what changes are you thinking in your mind from a trillion dollar security I mean is it still trillion dollars or is it is it like a billion agents and uh trillions of dollars so how are we thinking about this. >> Yeah, I mean a lot changed in the past year and a half since Trillion Dollar security started for sure. Um, I think the way people will interact with Ethereum in general or the web in general as well as Ethereum and other things will change quite dramatically in the next years.

I am not super confident that the majority of people will be using a browser extension in order to interact with Ethereum for example. I am believing more and more that people will be using agents to interact with it probably not realizing that they might be interacting with Ethereum. And right now I think that feels a bit odd like unreal to think about but it doesn't take that much for that to happen. I think um if for example Apple or Google were to release their

next phone which had a more agentic approach in how to interact with the phone then I think the shift would be very quick. Um you can just look at how fast it went from people using Nokia phones to using smartphones basically. Yeah, exactly. So >> I think it will come sooner than we think and you know some of the stuff that we're doing now such as verifiable front ends they might be completely useless in this time because the agents are most likely not going to interact with a website in order to do what they want to do. they will probably interact directly with the smart contracts. Um, but obviously we need to do things and

fix things until then. But I do think we're going to see a big shift in how we're using um the internet and Ethereum as a whole. I agree actually we I mean we look into from I'm I'm a security provider but we look into things like poly market uh prediction market getting very interesting now because the AI agent is just getting you will use directly the smart contract and it's right so maybe you are saying the trillion dollar security I remember you said it's the wallet now you're going uh below you're going to So in for your point >> uh no I don't think it changed at all. I

think uh we're just talking about different I think the the the way people use it is just different. I think the I mean if anything it's going to vastly increase the usage in my opinion because it's going to become a commodity and people doesn't need to have the expertise that in my opinion is required today to utilize a browser wallet or other things like there's a big technical step required today that prevents I would say nontechnical people to utilize Ethereum. Uh and I think that step will be taken away and it will become much more um utilized by a much

broader global um amount of people. >> A great point. So just in the interest of time um this is I'll just open it up to any you know all of you. Um let's security is all about thinking of you know thinking of and preparing for the worst case scenarios right so cyber armageddon right or p cyber doom right probability of like a catastrophic thing a black swan-l like event uh let's say uh think of ethereum or the general blockchain ecosystem [clears throat]

what is your What is your view on the current state of affairs? Right? are we as an ecosystem from an Ethereum ecosystem perspective and you know maybe Vitali can start uh you know telling us about it and uh Frederick and others do you think the the ecosystem is is prepared um and what are the biggest gaps and and to Mul's point how should we be prioritizing um if we are not already Vitalik would you like to take a stab at Cyber Armageddon.

>> Cyber Cyber Armageddon in general. >> Yeah, in general. And maybe, you know, from an Ethereum perspective, what are we doing and what should we be doing as a community to not let it happen? >> Yeah. I mean, I think uh from an Ethereum perspective, first of all, as a community, we should be uh I mean, doing I think roughly the kinds of things we've been thinking about and starting to plan already, right? which is basically looking at the full stack including protocol, including application layer, including how people's coins are stored when they're when they're fixed, including how people send coins when they're in transit, including our dependencies, including the peer-to-peer layer, even including operating systems, and uh like having a proper understanding of what our biggest

vulnerabilities are on on uh each layer including to quantum, including to AI breaking cryptography, including to AI finding bugs in code and you know including to AI doing social engineering right and uh like basically just do our best to move forward on all of those in terms of the uh wider internet I think uh you know we uh you know we are only uh a community and um you know we cannot fix the world ourselves right and I think it's uh importance to like know what what our limits are but at the same time also know that uh there are many uh things that we depend on and many things that we are contributing to that are also of value in many other places. I

think there are many uh opportunities for this uh community to lead by example. Um I think there are uh many community opportunities for this community to build solutions that work both for ourselves and for many other people in u many other contexts. Um and uh I think ultimately yeah I mean like both through our own work and our contribution to kind of broader cryptography including like for example I think zero knowledge proofs which were really heavily incubated within the Ethereum man's blockchain community which are increasingly being used in uh totally different contexts. um and [snorts] uh like continue to build more

things that that uh benefit people on the outside and then just uh like basically show our own ecosystem as uh an example of uh like things things being done well and uh sec and security problems being solved and and things improving, right? Because I think uh ultimately if people uh do not see the the crypto world doing cryptography well then uh many people will not trust that anyone can do cryptography well and that anything in the uh internet can be uh can be secure. So I hope that we uh take take on that responsibility as well as we can.

>> Do do you have uh uh personal peace cyber doom by 2030 for the broader internet? This is a hard one, right? Because it all depends on like how you define cyber doom, right? I think uh like >> catastrophic breakdown because of cryptographic perimeters, you know, breakdown of SSL and >> yeah, let me think. I mean like like I think there's an interesting question here of like what benchmarks do you choose, right? I think one benchmark would be for example that banks stop offering online services or at least they demand in-person confirmation of highv value transactions right like that's uh it's like a pretty extreme but also pretty realistic in like extreme

worlds milestone if I had to like put a probability right now on that happening um at least for some period of time good question what would I even say 10% % um >> 10% >> 10% yeah >> okay by 2030 >> by I mean or by uh let's say in the next decade um if I had to say yeah like some major h like major hack happening that caused like more damage than all of the hacks so far either inside or outside the crypto world um 20 to 40% Um possibly more. Um

if I uh had to say uh like probability of uh another interesting I think uh kind of cyber armageddon is what I call Epstein files times 50, right? Which is basically like a whole bunch of people's private commercial political everything secrets just being leaked at the same time because of uh either software bugs or quantum or AI algorithmic breaks. I think my probability of that happening to some extent. Let's say that is uh bigger than the Epstein files is uh probably over over 50%, I'm trying to say whether or not over 70%, I don't know yet. Um so that's uh you know going to be uh one

of these you know transition period interesting kind interesting and difficult rides that we have to make it through. Um the Ethereum blockchain um not going offline by yeah 2030 if that's a tricky one. Um [snorts] over 75% I'm trying to figure out whether or not whether or not over 90% um it's hard to say. I mean I think because we have very we have very hardworking teams but but also like something like that can can even happen just because of the internet breaking which uh we don't even control at all. So no that's hard for me to say >> what about others would you like to

chime in? Yeah. >> Yeah. More like as a as a kind of conclusion, I think one thing I would recommend for a leader is that right now what I'm seeing is that everyone focus on AI on how to ship faster, right? Like how much code can we produce now? How much feature we can we can produce. I think we have a chance and an opportunity with AI that we have extra capacity. So I would recommend founder to think of how can we use that extra capacity to increase security instead of focusing on how much can we ship. Yes. So I I agree. I also repeat what Joseline said that even now at the age of AI ownership is very important. Who owns the security especially for small

teams? Uh of course you use tools. I also think of course we know that operational security is a huge thing but I also think from the ecosystem we need to secure and I think we the term is doing great job but the consensus layer is still very tricky and need to we work on and the protocol level I think front end is something that we really want to to strengthen that's my one sent >> uh yeah I know we're short on time so I'll just say something super quick but basically I would advise to just plan for the worst and hope for the best. Um, think about what is the worst thing that can possibly happen and start to plan

what you would do in case that were to happen, no matter the risk being fairly low. >> Agree. Agree. >> Fantastic. So, we do we do have some questions uh from the audience that we'll be taking. We have about 5 minutes left. Um but before that maybe this is related to one of the questions over there. Um Jocelyn maybe you can start with this >> the human factor right so the security community right you know the question um but broadly what skills what judgment what workflows do you think will AI not replace immediately and how should you

know how how is awe the security team at awe planning the processes or your hiring all this stuff Right. So >> that's a good question and I think it's on every security researcher mind, right? Like how how can I stay revivalent in the age of AI? How can I still have skills and and you know competency when like AI can find bug really really fast what I have found is that there is a current challenge for security researcher when you want to do an AI assisted review in the sense that you're going to use AI to go faster. You can ask question, you can prompt it. But it come at a cost of building your own understanding of a codebase and uh I have seen for myself for example I've

missed bug uh in a codebase because I was overrelying on the AI during my review and that's really scary because at the same time I want to be faster. I want to be more more efficient in my my review. So I'm using AI but at the same point I am delegating my understanding. So I think one of the most valuable skill for security researcher is to build a process for yourself where you can use AI in an efficient way while still building a deep understanding of the codebase. And there are a couple of techniques that can help with that. For example, instead of asking how does this component works, explain how you think the component works to the AI and ask it to challenge it. Because when you do like this type of approach and you don't

delegate everything and all your reasoning to the AI and you try to build your own things uh this is how you are going to stay relevant in the of in the age of AI and why you're still going to be able to find the bug. So finding how to use AI in an efficient way while still building your expertise is is going to be key with a key um component for for your career. >> Yes. So I agree and maybe one way to look at it at least this is what people in our team is you look at it as a game in some sense you against this agent the agent is trying to write a spec you write a spec you're trying and it's interesting the agent is is actually improving and you're improving and and and you have to have some sense because

in fact you see the agent is missing a bug you're missing a bug you are writing a rule the agent is writing a rule and and and and if you are doing it Well, uh the the security is improving over time. Uh if you are relying on the agent, if the agent is relying on you, it's not a great idea. But together somehow it's it's some kind of a game. >> I think the main challenge is in my opinion, no one has figured out yet the right way to do it. And >> totally agree totally agree. And also the the biggest thing we see it with client they they want us to work half of the time while of course they want to charge half of the price and we tell them no we don't work half of the time

>> but at the same time whoever figure this out >> will be successful so you have a lot of challenge but opportunity there >> right um so we have a few more minutes so maybe uh Frederick and Vitalik from again from an Ethereum perspective Ive we know that AI I mean in general um helps both it's dual use it helps both attackers and defenders right so what's the one thing you think can sort of tip that balance towards the defenders towards the good guys and are we are we headed in that direction or like Vitarak

mentioned during his keynote are we really going towards dominance or heading towards doom. Thoughts on this? How do we tip it towards the good guys? >> Uh, >> and this could be in, you know, in the sense of the frontier models, open models, >> access, all that stuff. >> Yeah. Yeah, I mean I think if we're looking at it from a defender point of view, I think there is an advantage being that the defenders in general are way more uh collaborative compared to the attackers. um the defenders are trying to do good stuff and they are coming together at events like this or DSS or other things to collaborate and

advance and um I mean this is the case in uh open source in general as well and uh you know we're seeing this with the open weight models they're advancing very quickly and they're becoming accessible to people um which is really really good um you know you can say that There are concerns about having openweight models because attackers can use them, but defenders can also use them. And I think this is um the amount of value that this brings when it comes to a security uh point of view is invaluable.

We have you know increased the capability of finding security issues uh by at least 50x in the security team within the EF. So it's helped a lot and it's been um massively valuable when it comes to securing um you know the protocol. >> Great. Vitalik, any uh final thoughts before we wrap up this panel? H yeah I mean I think uh the way that I personally see security uh progressing realistically is uh I do think we'll see a a continuation of trends that we've already seen which is that we are going to see a growing uh uh secure core in the sense of a growing set of programs

parts of the parts of the chain software applications uh interfaces that uh continue to have fewer and fewer bugs and uh that continue to approach higher and higher levels of security. um especially because it it is ultimately like a thing of a fixed size that on which there is a growing amount of attention. um especially now because of AI and at the same time we will continue to see the crazy perimeter right and we we basically there will be people who will take the dividend of uh growing ability to code and cash it out not in the form of making the same behavior more secure but in the form of let like doing more and more crazy things with

less and less human effort right and so there will continue to be a crazy perimeter and uh that crazy perimeter will continue to get hacked. there will continue to be uh multi-billion dollar splats and uh you will continue to see them in the media and uh to some extent we will continue to get blamed for them right and uh I think uh like I think that duality right and that's the duality that we actually have seen ongoing for the past 5 years right I mean 10 years ago it was the Dow that got hacked right and uh I think these days like that divergence is continuing to happen and uh I expect it will grow Um and uh I I do expect that uh at some point uh things will stabilize but I

also think you know the future of security will be uneven in that way right and I think even to be fair there are situations where spending extra effort on functionality rather than on uh on security is justified right like uh if you have a uh you know like personal note takingaking app then uh making sure that your data does not get leaked is something you absolutely wants to guarantee. But then making sure that someone can't like come up with an some kind of uh adversarial attack where you know like if you paste it like the interface starts looking in the wrong way then like that starts becoming lower priority, right? And uh you know like

there are kind of deviations from your attention that are from your intention that are critical and there are deviations that are lower and lower priority, right? And uh there there are categories of uh applications for which like that deviation does start mattering less, right? But uh in general like I do hope that uh like that this kind of like shift continues to increase and I hope that uh like we can actually from here start to get uh like anything that is high value anything that is you know like high cat high catastrophic risk kind of fully into the uh into the secure core and uh continue expanding the [music]