DeFi Security 101 2025 - Ethereum Protocol Security 101

Transcript

Everybody uh one issue which is uh I think now we understand it more even though it was important uh early in the beginning is that the protocol security itself is getting more interesting and it's uh always the case. So we are fortunate to have actually the Ethereum foundation one of the key researcher Antoan presented issues related to security. How do we deal with security at the protocol level? Okay. Um, thank you. [clears throat] So, I'm just going to start off. Yeah.

Thank you for for being here everyone. Um, this is protocol security. Um, but before starting, I'm just going to introduce myself a bit about my background, who I am, and how I came into the field. So, um, I started in web 2 security about let's say two years ago. Um I did one year doing vulnerability research and um vulner vulnerability analysis, static analysis um and also dynamic analysis. So SAS and DSAT um mostly on docker container and docker images. Then I transitioned doing formal verification uh using the language for about 6 months at a company called formal land. Uh they're based in Paris and they're also blockchain based. There

I did the verification of the sooie type checker. Um and then I started also in parallel doing some web3 security contests on various platforms such as code arena and uh Sherlock uh can contain um and that's pretty much uh what my background is right now. And then after that I joined the Ethereum Foundation about 6 months ago. Uh and now I do just vulnerability research for them. Uh I give talks uh as today. Um, I mostly focus on the execution layer side of things, but I'm starting to pick up the CL side, which is the consensus layer.

So, I'm just going to explain as well who we are as the foundation and what do we do and especially focus on our team. So, we're a team of about 10 people. We have currently eight people full-time and uh we're just on boarding a new uh AI security researcher as well and we have a few people part-time. Some of them are working across different teams. So we have someone working from the GE team but also on the security team. We have someone working on uh cryptography team and also on the security team. And these are yeah basically are just core members of the security team as well. Um what we do we do fuzzing. We have public fuzzing and private fuzzing. I'm going to be explaining a bit uh why we have some private fuzzers as well and uh what

kind of fuzzing do we do. We also um perform manual reviews mostly on the execution layer. the consensus layer and the different EIPs that are uh being included before every Thor. Um and we also review the execution specs and also the consensus specs. And then the team, we have someone who leads the uh consensus uh specifications. We also do uh research on client diversity and ZK. We have a dedicated cryptography team as well and a lot more things. But that's just uh the main thing that we do. Um, so now I'm just going to explain what is protocol security. I'm sure most of you here know about smart contract security. Um, but it's very different from protocol

security. If you look at what do we expect and what do we search for? Uh, in protocol security, we search for network level rules and consensus correctness. Whereas in smart contract security, we look for app level logic and vulnerabilities. Examples that we find in smart contracts would be re-entry um rounding issues, oracle manipulation. It could also be like um broken access control and these kind of things. And these have an impact on uh individual contracts and the users that are using the contracts and the users that are using the platforms um where these contracts uh basically are being interacted with. On the vertical

security side, we have different type of bugs and um some of them are SS and RLP roundtrip errors. So these are um different names for encoding and decoding. Um and we also have invalid state routes and EVM divergence. Um and this really affects the entire network city and not just uh one smart contract or one application. Tools that we use in smart contract would be slither just traditional audits through competitions or just private audits. We could also use formal verification on the protocol security side. Um on at least at the Ethereum Foundation we use Hive. We do also some fuzzing. Um it could also be done for

smart contract security but we also we focus very much on that. We do manual code review. Um and we also try to do audits now on different platforms. um formal verification could also be applied to protocol security and just infrastructure security as general um but this is yeah the main idea so it's it's very different for example the RLP and the S so it's different type of encoding that have uh that are implemented in the different uh clients that have been used for by the um Ethereum so we have the EL sides and the CL side which is the execution layer and the consensus layer on the execution layer uh the RLP uh process the encoding

of blocks of transactions of receipts and state trees and some different things as well but just that's the main things and uh on the CL side it process the encoding of beacon blocks at a station and validates data um and it's also process the decoding part and these issue can arise for example if you have two clients with a different implementation some might be implementing it one way and the other one would be implementing It's another way in different languages and the type of errors that you can get uh on the ES side for example would be leading zeros. Uh there can be some different encodings if you have leading zeros. Also if you process empty strings versus empty lists it's a different uh

type of thing. So this could cause issues and uh consensus divergence basically on the CL side would mainly be uh miracleization which is it could be like yeah using the wrong number of leaves. could be using um hashing in a different order than what is expected by all clients. And so yeah, if you do not uh respect these rules uh across all client, you could cause um yeah, a client uh split. Basically, these rules are defined in the specifications on the EL side but also for the CL side.

Now I'm just going to explain what is the uh Ethereum architecture uh as of today. So as of today um this is basically the workflow that happens when uh you interact with an app or you want to send a transaction through a wallet. Let's say you're a wallet you spend uh you want to send some money to uh another wallet. What would happen behind the hood is you would make a JSON RPC call to one of the um RPC providers like Infura or Alchemy or whatever it is that would go on the execution layer uh and it would process your contract uh write a new payload and um just give you like a new state route and then every 12

seconds the consensus layer would ask the execution layer uh do you have like some data to provide to me. So it would it would give it uh a new for choice. So a new uh head to follow and uh it would ask for the payload that has been built that has been built. Yeah. And uh the interaction through these two is basically using the engine API. So this is how the execution layer and the consensus layer communicates and then it's just being propagated and validated through all the different uh CL nodes and it processes the block and then you have the finals chain and then it goes on again with the new transactions and new um basically interactions with the blockchain

Ethereum. Uh one thing to note is especially for Ethereum uh and is very important in this client diversity. So these are the different clients and the major clients that have been um basically implemented for Ethereum. So on the execution layer we have about 40% being used by GU about 40% as well for nethermind about 15% for bezu and then some of the clients which total about 10%. And for the CL side we have Lighthouse um which is uh the client that uh Sigma Prime is developing for now a few years, Prism, Teu uh Nimbus and some others.

And um internally we use different type of security. So I mentioned fuzzers, we have tools from ETH Panda Ops which is our DevOps team. Uh we used antithesis for the merge and um that has been very helpful to um basically do some testing which is which would be very hard to trigger by normal fuzzing and you can deterministly deterministically fuzz and just reproduce hard cases. Uh curtis as well we use it and uh we use also hive. I'm just going to give a few examples of that.

This is a list of some of the fuzzers that are public and some is still private. Uh I think nosy is is private. Um on the execution layer we have fuzzyvm and tx fuzz which are tool that have been uh developed by someone of our team called Marius. He's also a core maintainer of uh go ethereum. And we have govm lab which is uh been developed by someone called Martin which has since then left the EF. We also have private fuzzers. For the cryptography side, we have a KZG fuzzer written by Justin, which is the um senior member of the team and also he is the lead of the consensus specifications. We also have private faces on that and on the consensus layer then it's mostly private

fuzzers. Now you might be wondering uh why are these fuzzers private? And so the reason behind that is just security. We want to be battle testing and uh using our fuzzers before state actors or malicious actors would use them. And we have specific techniques that we don't want to uh reveal to the public. This is one of the tool uh that eth panda ops has created which is called the lab and um every node can willingly uh use zatu which is a data collection framework that has been also developed by pennet ops and then all the nodes would then just appear on the on the map and you could see in real time what slot

we are what um what step basically are we are the in the whole Ethereum cycle. another tool which is Dora the explorer um it's a it's a a blockchain explorer basically but um with a specific design that is very simple to use and we mostly use it to monitor our validators performance um that you could just check anything uh on the network health uh we have it for every test net that we have but also for mainet if I'm not wrong >> [snorts] >> uh and we also do devets uh before every fork. So for each dev net that we have we can use the blockchain explorer to just monitor how things are going.

The last tool is hive which is a regression uh framework and also um an integration testing uh security tool. So we have it uses the execution layer spec specification and it checks across all clients if these specifications are still passing after updates or anything to detect bugs in in clients. And this is like some one of one of the example for Faka but we have like many of them I think across the old testing repository we have about 46,000 uh tests.

One other approach that we have is differential fuzzing. Um we have the IPs that are included in um every fork and the specifications linked to them and for each of the major clients. So Lighthouse which is in Rust, Prism in Golang, Teu in Java and Nimbus in Nim and the other ones in various languages um each have their own implementation of this EIP and they they do things very differently which can make it hard to manual review because you might see one code performing such a thing but on the other hand on another client you might be seeing a completely different thing that is supposed to do the same thing.

So one way to easily process that is uh we would target a specific function and just look at the results of each client produce and for for example lighthouse will produce a result tech will produce another one and then we will look at the different results of each and every client and if they have the same results then everything is good all clients agree and all clients will process it the same way so we can keep on fuzzing. If we have different results, it might crash or just log it that we have some kind of differences. And then we also want to log the seed uh for the input gen that has been used for the input generation. It's either fully random or semi- random. We can define strrus and then use uh crates like uh I mean in

rust like you can use create like arbitrary which allows you to uh build arbitrary stocks and then we would log the seed to allow reproducibility. So we can just reproduce the case a lot of time to make sure that it's not just a one-time issue in our fuzzer but that it's an actual issue in one of the clients or multiple clients. What is the next thing that we do when we have uh found a bug then? So you might be wondering if we receive a bug on the bug bounty program or if one of our members discover a bug in one of the clients what do we do? We have dedicated client team chats and um one thing we would do is easily if it's sent uh from the bug bounty program we would discuss

it internally usually uh and then just make some kind of triaging um if it's a false positive or not. uh our team lead Frederick is usually the only one who received the submissions from the book bounty program but we also have someone from the cryptography team who has access to it and then he would share that within our uh own chat and we would discuss it um if it's a bug found by one of the members of our team we would directly send it to the dedicated uh team chats and we use uh signal for that to ensure uh the highest level of privacy on uh messaging applications.

What would then happen is that we have either the E or the CL clients and they would see the report that we have that have uh that has been sent to them and then we would be discussing it if the report is valid to them or invalid. They might have made a specific choice in their code for either performance reasons or security reasons. Um they might be implementing it this way for a specific reason or not. And so they will decide if they want to [snorts] implement a fix uh if they want to make a new release or just deny it. We as the Ethereum Foundation we do not own any of the clients. We are just supporting them um and just yeah giving if we have any bug giving them the insight that this

bug could be in their client during uh the fix. It can either be public if it's a small thing. If it's uh quite a impactful bug, like a high or medium vulnerability, depending on the impact that it could have on the network, it will usually be uh hidden in what in various different ways. Um so you won't probably know like if there's a new release, they would not say, "Oh, there's a bug in the other uh previous versions." Otherwise, malicious actors could just start targeting the the mainet network. And we do not want that.

Um regarding that actually um GE at some point disclosed early on one of the vulnerabilities and 12 12 hour 12 hours later some malicious actors started um impacting the main nets. They've done some reverse engineering for the past 12 hours trying to find uh what was the bug uh and then how to craft a specific transaction to impact the network. As a result, the Ethereum security uh overall is improved and then we can repeat on reviewing fuzzing or just receiving continuous uh reports on the bug bounty program.

Nowadays, G um now day nowadays GU I think does disclose their um release if there was any bug after 5 to 8 weeks to avoid these kind of issues to let them anyone um take the time to upgrade their node and just change it to the latest versions. We also discuss with uh major providers um just taking providers for example if there's been any bug found uh we wouldn't give them more information than we give to the public we would just send them a reminder like oh there's a new release you should update to that uh we also collaborate with others um other blockchains basically there are uh

GU forks for example so we have the Binance chain we have the base op polygon Gun and Mantle. Uh these are uh big chains that are all a fork of GU um except for Binance which is a fork of Opie which is inherently a fork of GU but we do also communicate with them uh just to upgrade the release or just make some changes um in any case just like we would do with our own uh client teams. And the reason we do that is just we want um overall blockchain security and not just Ethereum security. We want to do this for the whole ecosystem.

We have some kind of uh external security as well. So I mentioned the bug bounty program. Uh currently it's capped at 250k for a critical um but it's being looked at by the Ethereum Foundation. We might want to bump that number up uh in the future. Uh we think that having some kind of security uh maybe some pledge from uh different uh layer ones or anything that is building on Ethereum's layer twos uh to just pledge some kind of money to the Ethereum Foundation for a critical.

Let's say uh you have a critical and let's say we use $50 million as a bounty for a critical that could destroy Ethereum like a black swan event. Um, one thing we could do is we could ask major protocols to pledge $3 million for example, if they have like one billion, it's not that much, uh, to basically just protect Ethereum because we are a foundation. We do not have um, we do not own clients. We do not own Ethereum. We're just doing this for public good. [snorts] Um, also we go through different platforms. So we've gone through Immunifi for one of competition. We gone through Cantina for the Pekra upgrade and through Sherlock

for the Fusaka upgrade. Uh now Glam Amsterdam will be coming in the next year and we will probably choose another platform. We want to have some kind of diversity uh across different uh platforms for competitions and then ideally in the end we'll just stick to one that have been the most uh easy to work with. We also have grants. Uh we um do some part of funding to the seal 911 initiative. Um we do not fund the whole thing but we have made some funding to them. They do incident respond. So I don't know if you're aware of what they are and who they are but if secured more than 75 millions uh on chain uh if you have any hack or anything going on when

we when we've if you lose funds or something like that you should contact them. They have a telegram. uh they respond pretty quickly to big incidents. For example, for the balancer hack that happened like a few week ago. Um I'm pretty sure that we're reached out to for that uh kind of case. We have we fund some fuzzing grants. We currently have someone in South Korea working on some fuzzing projects that we uh sponsor and we also have been uh funding some formal verification projects and uh some more things as well like the Ethereum protocol fellowships.

I'll move on to some kind of bugs that have been found in uh different clients. Um I've mainly used GE as an example because they have a public advisories on on GitHub. So it's easily to just uh go there and uh find some bugs to present, but we also have a public disclosure repository. uh it wasn't really maintained in the past year but uh I'm I've picked up that task and I'm constantly updating it whenever we have a a report on the bug bounty program or if for competitions for example I'll just make a new a new report this is a DOS uh that has been found uh so it's a high vulnerability it's in go ethereum and so it would make the node crash or shut down immediately uh

whenever a peer would maliciously uh send some public key which is was invalid basically. Uh the reason for that is GU did not make a check a check on uh the elliptic curve. So um the math that is being used behind this elliptic curve is just this equation and it should be only valid if uh only pawns satisfying this equation make it valid. What happened is that an attacker could send a completely null public key uh using full zeros and this point would not be on the curve. So when we try to compute the slope of of that curve uh we end up with dividing by zero which is uh completely impossible and

this would cause a panic in the program. So the program crashes and as a result the node goes down. This is the fix comets for this bug. So it's uh just a simple one but we want to check that the point is on curve whenever we uh initiate the handshake the decryption and this is an example of how uh an EL could be represented. So you have um multiple EL clients connected together uh via peer-to-peer and we have one malicious client let's say Nethermind and they are connected to uh three G instances and they could just send some malicious uh public key to these GE

instances and automatically just crashed the nodes. So all these red nodes would just go down uh and that would be instantly. Um if you have something else like you're spamming a node for example or it's not instant uh it could have some kind of protections and just disconnect appear. What is the impact of GE dos? So GE is still as of today one of the uh most major clients that we have. It has a 41% share. So by that it means that anyone if they were running a mass attack on Ethereum 41% of the network would be at risk. We could have slower transaction and slower block processing and some RPC

endpoints wouldn't be available. Like let's say you want to send a transaction via MetaMask. if they're using a GU uh node behind their RPC endpoint then uh it would basically just crash or stall or um overall these kind of attacks just leads to uh network instability. Another example of a bug that has been also found in G is also a peer-to-peer bug. Uh and this one was pretty critical almost. Uh you could just by sending a ping uh down a client as well. Um it will also crash and the reason for that is uh whenever um G received uh a ping the peer-to-peer handler would spawn a

go routine. A go routine is basically go's way of >> [snorts] >> uh creating a thread um in in the code. And so spamming these ping requests would just create an infinite amount of threads and overall cause uh an hour which is an out of memory issue. And here's a little example of what this could look like. The c the attack node just spam pings the victim node every time it spawns a go routine uh which leads to resource exhaustion and eventually uh the crash of the node.

Another bug which is also in G. Um, so this is a consensus vulnerability. It's not just a DOS. This is the to me at least the most critical kind of bugs that you can have in in a client because this means that the chain is forking away. Um, basically it's like you have one client saying X and the other client saying Y. And so they disagree on on the results and eventually they start creating their own chain because they're not following what every other clients are saying.

So let's say you have a bug in a dominant client like GU, the attacker sends a TX, GE processes it the wrong way and uh because it is a high majority client, it wins. Uh in the past, GE used to have more than 70% of the network. So obviously now um it's helpful that we have more client diversity because you need to have bugs in multiple clients at the same time to have a real risk on Ethereum. But let's say just GE has the majority and the rest of the clients doesn't have even though the rest of the clients are right uh the minority is going to lose and GE is going to pick up the new canonical chain which is the chain that everyone should use. Uh and

then as a result we are following the wrong chain. Um what's that mean is that we mean is that we have potentially invalid balances uh potentially invalid state roots. Uh this could cause a lot of issues in in just Ethereum in general. Just as an example of what a fork choice is. So you have the chain of block which is the canonical chain. So all clients agree to that one. Sometimes two blocks are proposed at the same time. So you would have a kind of reorg which is you follow a different chain for just like two seconds and then you reorg back to the canonical chain and then you have the minority chain which is valid which are followed by other clients but because the majority chain uh wins with

the bug uh it's the one that is followed by um everyone and so the validators running on the wrong chain essentially will get slashed for processing the right chain information. So the purpose behind client diversity is uh that we have 66% to reach finality. So in a network if you have more than 33% of the validators that are down it prevents uh finalization and finalization is um when the block is fully produced fully tested and then you can't just go back back in time. So it just follows the chain and if you start

having some bugs it forks to its own chain and you can't return without slashing your uh validators. If you have any questions uh please do let me know. Uh it's been a bit short. I think I've gone a bit too far uh on my speaking but if you have any questions please do let me know. I've linked some links uh for the bug bounty program for our team and the responsibilities of the protocol security. I've linked the uh go ethereum advisories if you want to have a look at the bugs that are uh shown there and also the public disclosure which contains all the bugs basically that have been found from Ethereum day one and if you have any kind of urgencies you can always contact seal 911 or um just use the telegram I think

is the easiest way to reach out to them and they would be uh pretty happy to help. They're doing this for free basically in their free time. They've just they're just funded by a lot of different uh organization including the Ethereum Foundation. Thank you for attending this and here are my socials. [applause] >> Yeah. [clears throat] Hello. Thank you very much for your speech. Uh you mentioned in the first part that you were working with formal lens and using

coke and formal verification. Uh what do you think about the future of this technique currently? Are they applicable in your work and what kinds of formal verification technique are using now? Thank you. >> Um thank you for your question. Uh at the Ethereum Foundation, I'm not using any kind of formal verification techniques. uh but we funded a grant uh actually for formal land as well to for them to formally verify the revm which is the EVM implementation written in rust. I think formal verification is extremely useful. However, it's only useful if the specification is correct.

So if you have the wrong specification, you can still verify that it's um basically following the specification, but uh if your specification has a bug, it won't find it. Um I think formal verification has its advantages. Um however it's pretty complex and it's super lengthy to uh put in place at least uh using Um for example the number that I had in mind is if we had a thousand lines to verify we would have to write about five times that to um basically just formally verify it. So if you have 1,000 lines of Rust, you would have to write about 5,000 lines of of to formally verify it. So let's say the project took um I don't know 2

years to do it. To formally ver verify it, it would take you about 10 years considering like you're an expert in and you don't have any issues with translating things. Um also it can be pretty complex if you start having some um very difficult types and not just you you know just an integer or a list or something like that. If you have custom types you want to basically just define them in and it can be pretty difficult. So I think formal verication has its future. Um but it's a different business than just fuzzing or manual reviews. Thank you for your question.

Does anyone else have another question? >> Um, what policies does EF EF have if some critical uh bug is found so that it is deployed before it gets exploited? Does it have anything in place? >> You mean like if we get a critical report through the bug bounty program? >> Yes. Um so we would obviously just assess that uh within our team and then if uh deemed valid we would uh start communicating with client teams communicating with as I mentioned all the legos that are uh using Ethereum as well and we would um have like a instant response internally. We would contact CL 911 to have some kind of guidance from

them as well. uh their experience in these kind of critical cases. So they're always like could be helpful for their insights. Um then we would proceed to the fix and then just make a release. I don't know if in that case we would disclose it because it's super critical. Um I don't think we would but there might be a specific uh protocol. I'm not aware of that. Uh I'm sure if if this were to happen, our team lead would just put up uh like a crisis like war room and just let us know what is the protocol to follow. And then in regards to the bounty, uh at the moment it's only 250k, but if it was a super critical bug, I'm sure they would be making an exception.

But as I said, we're uh looking to bump that number up. uh we have other protocols that have much bigger bounties for critical and we think that Ethereum should also have a big bounty not just 250k especially if you consider just destroying Ethereum as a whole. Um so yeah this would be uh what we would do. Um and then after that uh I don't know we would just probably make some kind of um postmortem investigation uh how we missed that what we could learn from that mistake and communicate on X or different various uh social networks. Um but would you be able to um disseminate the code to

enough nodes without uh I don't know some attacker finding out uh too soon? >> Sorry, could you repeat your question? >> Would you be able to disseminate the code to enough nodes without uh disclosing what the issue is? >> So we would have to make a new release in every client. Um but obviously like having a critical means we have a bug in each every client. So it is pretty tough now that we have some kind of good client diversity. I think we it could still be improved. Um but yeah we could definitely just reach all the all the bugs in all the clients. So the client teams know their codes like the back of

their mind. Um, so if we find the issue and if it's been disclosed to us for the bug bounty program with a easily like code path to follow, we could just send that to the different teams. They would investigate, make a fix pretty quickly and then just make a release. Um then they would advise everyone to bump to that release and a few weeks later they would announce though there's been a critical in you know X release and then hopefully by the time enough nodes would have been uh upgraded to the new version.

>> Thank you. >> So thank you very much. My my question is more high level. I work in this field uh before actually starting set I worked very much I don't know if you know about the consensus formal verification and actually the it's actually one of the problem that in computer science we we have a good uh understanding including system that I put but others for formal verification of consensus and also in the in the practical side in the system community people have identified the bugs in the consensus and what you are doing is actually interesting because

there's staking there's actually things that make it more amenable to bug. So can you comment why why these methods are not useful for you or is it just a matter of priority? >> I think these methods are useful. Um we have some kind of uh track which is the formal verification ZKVM project. Um I think we're also funding a part of that. I'm not 100% certain but we want to move >> but ZKVM is proving things which is great on the implementation level. Yeah. >> But we have been seeing in the are you familiar with Ziza?

>> No I'm not familiar. Could you so is a very interesting I didn't know but it's the last word in the Brit in the in the English alphabet. Okay. and the issue that somebody actually said that he has this protocol which is right and actually so I'm talking about there are different level of bugs that bugs in the implementation that you can use tools including ZKVM and and others but bugs at the conceptual level at the design people have had and there actually it's a bit simpler because you're not reasoning about implementation you're reasoning about the design >> okay >> and it's actually related we working with the with with our client and sometimes We see that part of the problem is that people mis it's not even

a bug that people misunderstand the the the the behavior of the consensus and therefore when they are writing for example you mentioned this beautiful separation between bucks in smart contract and bugs in but we have bugs that are crossing >> you you seen them bug that are between the smart contract and the consensus >> no I haven't seen uh such type of bugs but uh >> in the pepe in yeah others Yeah. Um yeah, we have it could be a bug in the specification as you mentioned not directly in the implementation but then how would uh I mean could you give him the b the mic please? I want to give ask him a question. Um how would formal verification help in uh finding bugs in

the specifications? It's it's not finding a bug in the specification finding bug in the in the model in the design like you have you have a a design of the algorithm you write a design of the algorithm in in our system IV or in TLA or in some other system and then you reason about the design not the implementation so you are you have some kind of high level description of the algorithm okay and you are finding a bug in of course once this high level is correct there's still another question which is hard is that you can have imple implement mentation bug. But we have seen uh in the literature and also even Google reported that there were bugs in the design of the of the algorithms which were usually identified something between uh five to

15 years after that. So you want to find these bugs before the the implementation. >> Yeah, definitely. So what was the original question? Sorry, I didn't >> Why is it not used? But you're saying it's >> Oh, it's not used because it's a lengthy process. I would say I would also say it's a very niche field. So we have um not not that much experts in formal verification. Um Storra is definitely um amplifying that and you have a lot of very good formal verification engineers but usually to do formal verification requires an immense amount of knowledge and uh specialization. So it's a very lengthy process. is very cost uh costful um and talents are very niche to find

and I don't I do not think that this is the priority of the EF at the moment. >> Makes sense. Thank you. The next question is about testing. So you have a beautiful uh system that you have sort of different level of consensus and you are doing fing which is great. Are you are you actually and maybe I didn't understand your talk are you comparing the the different implementation because this way you can you are doing it. So in the fuzzing are you running uh I forgot how it's called lighthouse against prism are you doing this in >> yes we are we are doing this via fuzzing this is called uh differential fuzzing actually Justin uh wrote a differential fuzzing framework which allows to fuz different implementations in Java nim uh

rust and then other languages and so as I said we are comparing the results of um an execution in Java for for the same function for the same implementation in another language and then comparing those two results to see if there's any discrepancies and then we would find a bug that would mean that one of the implementation is wrong and we would have to investigate what is wrong in the function what is wrong is there something wrong in the specification or something wrong elsewhere in general >> and and did you already fi find such >> I haven't personally found bugs uh but uh I know that the EF house find some bugs yeah >> okay thank you more questions Hello. So like I heard Vitalik talking

about ZK and ZK being the new stuff. So what is EF doing about the upcoming push of zero knowledge being used by top protocols in the space even by Ethereum Foundation? So it's not my uh scope of work but uh what I know is that yeah we're pushing towards uh ZKVM. We think that is very important for uh proving time. We want to just reduce um and improve Ethereum performance overall. We want to scale Ethereum. Um and this is also part of the one trillion security project. Uh we want to have a lot of funds on chain and to do that we need to make Ethereum faster. Um

we also are fuzzing uh funding we are we're making some kind of donations to the ZK uh EVM formal verification track. So this is uh designed to formally verify uh ZKVM implementations such as uh risk zero for example or risk 5 I forgot. Um and then we have some specialists of ZK within our cryptography team which are constantly working on that. We also have researchers uh trying to um just write papers work on new EIPs um to push towards yeah ZK for Ethereum.

Does anybody else has another question? >> You were talking a lot about uh fuzzing. What about non-fality? For example, um I know it is tested during the dev nets and test nets. Uh but um when the clients go to mainet and they release updates um can it can can it happen like for example non-fality do you monitor it? Um is it possible vector of attack? >> You mean that the Ethereum chain doesn't reach uh finality? >> Yes. Well, finality um at least to my knowledge, I'm not a CL expert, but to finality um to reach finality, we need uh more than 66% of the network uh like

validators being up. Uh we of course test it on devets and we try to recover uh if we are not reaching finality uh and this we have always been able to recover to my knowledge but this hasn't happened on mainet yet. No. Do you monitor um clients updates as well? For example, like a red flag client update or not? >> Um could you be more specific as to what do we what what should we monitor? >> I mean uh can it cause any issues when the client releases new update?

>> What issues do you have in mind that it could cause? uh >> let's say two clients, two majority clients um released a malicious update and it's like already majority like 66% for example and >> well thanks to client diversity we don't have uh like a a client being big enough to have this kind of issue happen um >> hleski in >> sorry >> hollleski in >> hollleski uh hleski has been uh downed now I think like last months but I wouldn't know the the specifics of that. Sorry.

>> Okay. Thanks. >> Does anybody else have another question? >> Okay. Well, thank you all for for attending. Uh I'll just give back the mic to Molly. >> Thank you very much Antoan for for the presentation. Uh maybe you can also share with us information here if you have like but we want to learn more. We want to learn more. I think the Antoine actually mentioned that the zero knowledge. So we have a little break but after that uh Jeffrey from the rare skills will actually sorry you he's going to do the presentation of