Live Discord #2 – Ethereum France rencontre les ETHPlorateurs

We have Barnabé and Guillaume here from the Ethereum Foundation, who are also partners on this podcast called The Explorers, which some of you may know. So, perhaps it would be nice to start this live stream if you could introduce yourselves—Barnabé or Guillaume first—and then perhaps you could say a few words about your podcast. Of course, Guillaume will start. Yes, as they say, age is better than beauty. Well, yes, my name is Guillaume.

I've been with the Foundation for, what, 6 or 7 years? No, 6 years, I think. And, well, I started working on the team—well, I'm still on it, actually— on the Go Ethereum team. So, I work on the client, the client, what we call the majority client. I don't know if it's still really...

but anyway, if you need to connect, if you want to run a node on the network, you install what we call a client. So, you have a choice of four... 4 or 5 clients, and until now the most popular was the one I work on. So, when I started working at the Foundation, I was working on a sub-project for this client called Whisper. It's a communication system—how can I put it?

—with what we call... well, it's going to be hard to talk about, it's going to be hard to speak French tonight, Merie in Spain, sorry, it was... no, I... no, TR stands for deniable provability. How could we say that?

Yes, that's it, a bit... no, it's not that, it's ENF. Anyway, basically, if the government or anyone comes after you saying, " You who sent this?" you say, "No, it wasn't me," in any case, you ca n't prove it. And, in some jurisdictions, it passes, in theory, and, well, there you go.

So, the problem is that there were... the idea, the idea wasn't going to work. So, little by little, I found myself working on the client itself and... It's true there's a lot of work, it's fascinating, that's it. And recently—well, I say recently, it's been two years— I've been focusing mainly on what we call stateless Ethereum.

So, basically, the idea, to summarize it very simply, is to make certain changes so that everyone can validate, to have an Ethereum node that follows the network and can potentially validate on their phone. That's the very, very long- term vision. Yeah, that's where your comment in the last podcast about powerful phones comes from. We'll come back to that. Yes, yes, absolutely.

Oh, I remember. Okay, okay, my turn. So, I 'm Barnabé, I've been at the Foundation for three and a half years. I joined the Foundation, I joined a team called the Robust Incentive Group, and so what we work on is really the economic mechanisms that are in the protocol, but also outside the protocol, because we often try to understand what the People are doing Thums with MV with the defi and trying to understand if there are any consequences on the protocol and on the designs we're making. Our team has grown quite a bit; I was one of the first on the team.

It started when I arrived, and now we have 7 full-time researchers, and we have, I would say, a fairly wide range of projects. I can name a few. So, I worked on IP 1559 before it went live; it was one of my first big projects. We looked quite a bit at the incentives of the proof- for-stake model and also some questions that arose with consensus, including bouncing attacks. Don Max Per wrote an article on that.

And yeah, I then became quite interested in MV with other people on my team because it's such a huge and complicated subject that involves so many things that we really needed reinforcements. On that note, and I would say, yeah, my attention has shifted a bit, particularly in the last few weeks and months. There are many more questions about the economic state of staking on Ethereum. So there's the rise of Lido and liquid staking derivatives. There's this new EP that puts a limit on churn for entry into the staking set because we've noticed that there are many people who want to join.

Can the network withstand the pressure? So there are many questions that are being addressed, and it's something we'll be working on quite a bit with our team in the coming months. Great! If you already have any topics you'd like to develop now, or we can come back to them later if you want, but you've mentioned many very interesting projects where we might ask questions for the future, but there are already many topics to discuss. Perhaps before we get into the heart of the matter, would you like to say a few words about the podcast, about what you do with the explorers?

Yeah, well, actually, we also wanted to motivate ourselves to step outside our respective fields. It's true that I'm more focused on development, Barnabé on economic research, so we thought, why not? We also wanted to practice our French because it's true that we don't use it often. When you see a podcast, you can tell. When you see a 30-minute podcast, we actually have two hours of recording, and we're wondering how to pronounce things in French.

So it was particularly funny with Dom, who was from Quebec—well, he still is, anyway— because we were trying to find equivalents. It really made him laugh when we talked about commitments. Polynomials, uh, so yeah, it's true that it allows us to practice, it also allows us to, yeah, to find out more about what's happening around us, and also simply to try to make Ethereum a bit more accessible, at least everything related to development, research, everything that's really technical, more accessible by trying to involve people because there are quite a few, how should I say, French speakers in Ethereum, and it's true that we're all a bit isolated. So, well, it's not that we're necessarily obliged to speak French, you know, we don't particularly speak French in our own lives, so we don't feel lost either, but it's true that it's nicer, it creates a medium of exchange that we were interested in exploring. In fact, I find there's already quite a bit of content in French on Ethereum and on the...

Cryptocurrencies in general, we had the impression that we could contribute something a bit more technical and perhaps a bit closer to the metal, especially the protocol, because there's a lot of content on the application layer of Bitcoin, Ethereum, and other channels, by the way. I'm referring to Ethereum, and it was pointed out to me in YouTube comments on the big crypto forums, and apparently that's not how you say it in French. So I tried to change it. What is it? It's a question I've been asking myself, and actually, I wonder who's right.

I think that actually, "etherium" is a kind of bad anglicism simply translated into French with an English accent, whereas " quetherium" is more the Latin approach to the word. So maybe you're right in the end. I'm asking myself the question. Well, it's decentralized, right? You do what you want, you say you want, yes, it's uh, 6 years of Latin, that's perhaps why...

ah yes, well, I'm not even sure that's how it was. After that, yeah, so yeah, our ambition was to create this content and to provide a bit more of an interface for the people who follow the core development of Thereum. Well, in any case, in decentralized networks, it's good to have consensus, perhaps on words as well, on names. I imagine that these are questions you think about all the time, the names of technical terms and other things. These are key points in the end.

Yeah, yeah, yeah, we need to think about them to also get the attention of Twitter. The more attractive the words are, the more people think about our research topics. So it's a competition on several levels. Yeah, I imagine... I was suggesting that to also start getting into it a bit...

In the topic, we're talking about your latest podcast. It could be the heart of this episode, this live stream, or not. I think it would be interesting to recall the different themes, maybe even do a short summary of what you talked about. So, it was... I can let you prepare it, but it came out a few weeks ago, and it was basically an update on the roadmap with Domoti, who is also a researcher at the foundation, which is super interesting.

If you want more information on the roadmap, would you like to give us a little recap of that podcast? And if some of you in the audience have questions, or if you listened to the podcast, you might have questions about it. I think this is a good opportunity to do that. I already see a question from Max in the chat: should we answer it now, or should we go straight to the podcast? [Music] [ __ ], are you working on Single Secret Leadership SS?

Yeah, well, not me, because, as I was saying, I'm more focused on States, but... Yes, there's work being done. So, I don't know from a research point of view, I imagine there's quite a bit. There are several aspects to this, to this SSL. There are quite a few cryptographies.

So I have a team where there are people on this team who are working on it a bit. Well, I say one person, it's Ignatio, and he worked on the proof system called curdle proof. So there are things in the advanced stages to explain... yes, uh, well, go ahead, I'll let you explain unless you want to. You can do that.

Yeah, so today, Ethereum validators are randomly selected. Every 12 seconds, a new validator is supposed to propose a block, but this randomness is actually more or less decided in advance. So you know, for the next 12 minutes, what the sequence of validators is, who is expected to propose the... Blocks can be dangerous in the sense that if I see, okay, validator number 2000 is supposed to propose a block, and by putting a few nodes on the network, I can detect the IP address of this validator. So, if I can make the association between the validator's index and its IP address, I can attack it just before it's supposed to propose its block, put it in a denial-of-service state, and basically make its node impossible to propose.

And if I can do this continuously, if I deny each time, just-in-time, the validator that's supposed to propose the next block, well, in a way, I can shut down the chain. So, to protect against this attack, the idea of ​​a secret single leader election is to not communicate to everyone what the index of the next validator that's supposed to propose this block is. That was the inonutell, what it says. Yeah, thanks. Well, yeah, that's exactly it.

And so, basically, so that It's done precisely so that it's secret, so that it can't be determined. There are many things, including what we call zero- knowledge. So we might not go into detail about zero-knowledge right away in the first 10 minutes, but the idea is that the next validator to propose the block is revealed at the last moment. And for that, there are quite a few cryptographic methods. You should know that this is still a subject that's still very much in the research phase, so there is n't really any development on it yet.

There's the team lead of STAR who's really pushing the thing, as I was saying. There are people I work with who are working on it from a cryptographic point of view, but the design will undoubtedly evolve quite a bit. We're still at that stage. So, yes, is that what we want? Yes, everything would be pretty good because It's an additional security measure, indeed.

We can finally say that someone could take down the network. Someone had quite a bit of power and could take down the network by dismantling all the servers one after the other. So, we have to address that. But it's not the most likely or imminent attack, so we're taking our time to do it properly. To answer Sun's question about the attack, it's a relatively complicated attack to carry out, especially over time.

It's often like that, actually, with Ethereum updates. So it's true that it's still in the research stage, but quite a bit has been written about it. There are designs that are relatively feasible. There's not really any urgency in terms of deployment because we don't get the impression that it's a very real attack compared to other problems that are much more... real and much more urgent, so it's something we also have as ammunition in case something happens or if we feel the tide is turning and the network is becoming more adversarial.

So there are people working on that. There was recently a post from George and his team on Proof Validator, which is also a way to anonymize validators on the DHT, which will be useful for data availability sampling. So there are always people who... well, anyway, any system can be attacked, right? Just because it's possible doesn't mean it's impossible.

Proof, in history, it's already happened. There have been validators, not the DAO, but there have already been three... I don't know if you've heard about them... the DAO, that kind of thing. Oh yes, okay, the Shanghai attack.

Well, technically, the Shanghai attack was still a... it was even a... So, yeah, DDoS is... well, yes, that's still possible, but... well, we're aware of it.

There are attacks that are feasible, and attacks that are probable, and some that are n't. We prioritize, of course, the most probable ones, and well, there you go. You shouldn't worry too much, you know, it can always happen, obviously, but it can happen to anyone, it can happen to Bitcoin, it can happen, yeah, it can happen to Google, right? So, there you go, there's no need to be afraid, but... it's true that there are things we...

well, generally, when we know about them, we don't talk about them. It's not because we're keeping them secret, it's to avoid giving ideas, actually. So, this one, we're quite comfortable talking about because, a priori, you still have to go to great lengths to implement it, but... well, there you go. There are things that, when you're finally discovering something, can really bring the network down quickly.

We do what's called a responsible disclosure, and we avoid publishing it. We communicate with people, we tell them, "You have to... you have to... you have to... you have to...

sorry, you have to..." That's the reason we want to solve this problem. Don't talk about it too much. And then we solve it. Once...

sorry, I'm digressing a bit, but at the same time, I think it's interesting. We found a bug in the Go library that was affecting everyone, and we found it. It was a bug that had been in Go for years and years. Well, we told Google, and they took TR3 or 4 months to fix it. For 3 to 4 months, we really crossed our fingers that nobody would discover this bug because all it took was creating a...

A transaction that's going well, so that all the networks, so that all the neugo and network panic, and so we lose 40, 40, 60% of the network, uh, so there you go. And when there's something really serious, we don't talk about it so freely. B, super interesting. Uh, there are questions, I see, about the research, the MV burn, the MV burn research, which is included in the roadmap and in what you discussed in your last episode. Uh, I'll take this opportunity, just before moving on to a bit of an app from this episode, which will be interesting, I think it will raise quite a few questions, uh, uh, from our listeners.

Uh, if I take this opportunity to remind you, uh, feel free to ask your questions, even to participate as a speaker here to ask your questions directly. The idea is that it should be collaborative, so really, don't hesitate. Uh, and I think that I suggest we do a little recap, if possible, of the last episode, so the Etherium roadmap and Then we already have a question about three little points that will be interesting to answer to begin with. Go ahead, yes. So there's a tradition now that every year Vitali posts a tweet with a diagram of the different Etherium updates he has in mind and that the different teams are working on.

I've put the link to one of these tweets where this roadmap appears. This roadmap is divided into several sections, so there's Merge, Purge, Scorge, Verge, and others. I have it in front of me too because it's hard to remember. And so, yeah, Domotis is a researcher at the foundation who joined not so long ago but has already done quite a lot since. He was very active on Twitter, writing a lot about trying to explain these updates from a technical point of view but also from a fairly accessible point of view.

And recently he posted a rather long post on the annotated world map, so reviewing the points that Vitali has put in his diagram, and with a little more background, a little more context, uh, and so yeah, we were all The three of us met in July, so it was also an opportunity to meet and interview him. We asked him questions about different sections of this roadmap, which he knows quite well. So yes, I'm thinking, but yes, that's exactly it. So, well, maybe if there aren't any other questions, we can finally talk about the roadmap again. Would you like to do a quick overview of the smaller steps, if you have them in front of you like this?

That might raise some questions, and maybe it will be a good intro for the question about the Burn MV. [Music] Yeah, it's definitely very important. There are a lot of things that need to happen before, so maybe we can do a quick overview. There are six sections there on the tweet. We'll do one, you'll each do one, 30 seconds, okay?

So the first one is the easiest, it's the one people know best, so it's the merch. So, let's move on. Well, and then make this consensus mechanism as robust as possible. So we're already using proof of stake, we already have the withdras, so that's done. We're starting to get the distribution validators, but as the post on the bouncing attack shows, there are still some small bugs that are actually part of the design of this mechanism.

There are quite a few people working on it. So the key word here is single-slot finality. So it's about moving towards a system where each block can be finalized if there's enough participation. So yeah, today we don't know, that's not what's happening. We wait about ten minutes to finalize a block.

Yeah, so that's it. So well, that's already done, but we'd like to make it more robust in the future. Uh, yeah, thank you. The next one is the search, so it's the one that everyone's talking about right now, at least among the Cordèves, it's IP 48 44. So the idea...

This is the beginning. The idea is really to work on scalability, so everything related to r, up, and down. Ultimately, we want the CH (Cash Flow), we want everything related to data availability. After that, well, it's, once again, the roadmap. It changes every year, you know.

Well, it's updated every year. The general principles remain the same, but they're updated annually. But we can imagine completely crazy futures, or for example, Ethereum availability, its ability to extend the availability of data to other blockchains, like Cash or even Bitcoin. Let's be crazy! Okay, that remains extremely theoretical, but there you have it.

So that's what the search is about. It starts with 4844, which basically consists of offering a new dimension for gas. Instead of paying for a somewhat generic gas, we pay for a specific gas for the data. And so, since we have this additional granularity, we can afford to... how to say...

I'm getting a little tangled up in that, but we... So, we can simply say that all the costs associated with data storage are separated from the costs associated with execution. Therefore, it's true that a rollup that's more interested in data storage isn't going to pay for a gas, which is essentially an aggregate of something that is both data and execution. So, this reduces the cost for rollups. Using Ethereum as a security layer, to clarify, it's not exactly storage, it's more publication.

It's not storage over time; we just want rollups to publish their data so that it's available to everyone, but we don't keep it in storage indefinitely. It's cheaper, by the way. That's why, yes, that's why we can have this efficiency. Yes, because... well, I'm going to digress for a bit, but the idea is that precisely, since the promise made with Ethereum was initially something we need to change little by little, is that when you store data on the blockchain...

It was stored indefinitely and so it moves forward, or that's true, okay, I'll keep it for later, very good, that's true, okay, okay, so then, uh, V-scorge, so eliminating, uh, the games that happen between the application layer and the consensus layer, so the MeV, so MV is this phenomenon where the block producer has control over the transactions it includes in its blocks, it has control over the order of the transactions and it can also insert its own transactions, so it allows it to extract this value which is known as MV, a keyword here is PBS, propose Builder Separation, so as a block, uh, as a block producer, for example, let's say I'm running my validator in my living room, I'm not able to make a hyper-optimized block that extracts the maximum MV, so what I do as a block producer is I can connect to a network where builders produce the block, uh, in my place, that's it, it's something This occurs due to rational incentives. After the MV, it's a subject that is, once again, extremely multidimensional, and there's a lot to say about it. But the main idea is to ensure that the decentralization of validators isn't just technical, but also economic. So, if there are validators who have access to higher rewards (V) than other validators because they manage to extract the MV more optimally, this can gradually reduce the influence of less sophisticated valuators on the network and centralize the network towards valuators who are very capable of extracting this MV. And that can be really very damaging to the network.

So SCOR is really about designing mechanisms that allow us to prevent this economic centralization. The verge... yeah, not doing the next two like that. You were going to talk about the story, yes, well, okay, I'll do the next one. Yes, so the verge.

It's B, that's exactly it, that's exactly it, that is to say the ENF statement, that's exactly what I described at the beginning and what I'm working on, it's, uh, it's the, it's Ethereum, so the idea, well, I said Ethereum, this time I didn't say Ethereum, well, uh, the tree, yes, so basically, well, it starts with what we call the change, we're going to change the structure of the tree, uh, so in fact, well, okay, I should start with that, all of Thum's data is stored in a tree, uh, that we call a Merkel tree, it's a structure in cryptography that allows us to make proofs, the problem is that since this Merkel tree was invented in the 80s, we've made quite a bit of progress, uh, and especially in recent years, in fact, so, so we now propose to use another structure called a Merkel tree, so it's basically the same thing, but we use No longer the same cryptographic technique for storing this, we use a new technique called polynomial commitments, and it allows us to do several things. Well, first of all, the proofs are smaller. We'll probably do an episode on that in more detail because, yes, on the subject for 3 hours. So, uh, and the other aspect, the other advantage of this is that we can update this tree without having a complete view of it, which wasn't possible with the current technique, but we're talking about blocks of 1m, 3m, maybe 10m if we're dealing with a particularly pathological block. A 10m block doesn't move around the network that easily, certainly not in 12 seconds.

So, the idea is to have smaller blocks that They contain just the necessary information, and the idea is actually good, well, the idea is to attach this proof to the block so we can just download a block and execute it without needing to do a synchronization. You probably know that synchronizing an Ethereum node takes several days, or at least quite a few hours, and well, thanks to the worm, that would be over. So there you go. After that, there are plenty of things—it's not just the worms, there's using quite a lot of Zero Knowledge behind it to make it even more efficient, even faster to prove, sorry, or at least even faster to verify. No Zero Knowledge, sorry, yes, because anyway, we don't need the ZGE aspect yet, that's a detail.

So the idea is really to have an Ethereum, to be able to participate in the Ethereum network without having a very powerful machine. So, as I was saying... Ideally, a phone—well, maybe we're not quite there yet, but it's still going to become much more practical and cheaper to run a node thanks to this. Do you have any idea of ​​the space needed to host a node after Verge? Well, there are several things, yes, because that's it.

There's also purging, that's true. So, purging... before answering that question, I'm going to talk about purging. Well, it's the idea of ​​deleting all this data that is... that is...

So, as I was saying, the implicit promise that has been made so far is that when you put something on the blockchain, well, it's there forever. So, even if gas is very expensive, it's extremely inexpensive; it's practically free, virtually free, since you pay—well, you rent—space for an infinite duration at a finite price. So, naturally, it's not expensive. And so, well, there you go, we want to come back A little bit about this promise, uh, so we want this, the purge, that's all that corresponds to the State Expiry. So there would be a hypothetical mechanism—no one's working on it yet—where the data, when it's written, is only kept for a certain time and then it's deleted from the memory of all the nodes.

And if you want to keep it longer-term, you have to re- enter that data with proof that it was indeed in that state at a certain time. And then there's also everything historical, so in fact the whole list of blocks. Well, let's say in a century, for example, uh, the first Thom blocks won't interest anyone. They don't interest many people already; they only interest developers like me, but a priori, I don't think they interest many more people than that. Maybe, in quotes, archaeologists or police officers, but that's all.

So these people can keep the entire blockchain, but we can say that in a century, when Ethereum is a century old, there's little... There's a chance that there's a reorganization of the chain going back 10, 20, or even 100 years. So if we have 100 years' worth of blocks, we might be able to delete them. That doesn't mean we make them disappear; we store them outside the chain. But most people wouldn't actually store them.

And the consequence of that is that, to answer Barnabé's question, how long would it take, or rather, how much space would it take to run a node? Well, let's say the two biggest things in the database, if I'm not mistaken, are the blocks. That's for sure; the blocks are the biggest thing. So if we manage to delete them, or delete the history, we easily save 200 GB, I think, from memory. And then the state itself is also 200 GB.

So if we manage to delete part of this state, or at least keep only a view of it, we can save a significant amount of space. From a subset of this state that interests us, well, we can gain, yes, we can gain 400 GB easily, and the other thing, especially, is that the necessary storage no longer grows; we can target constant storage. So, it's true that, well, I'm going to throw out a figure, I'm not committing to this, a date, January 3, 2020, uh, yes, well, I think that with TER, which in a few years shouldn't be a problem anymore, with TER, we'll be fine, even, a priori, we could even think of a TER, maybe 500 GB, but well, it depends, we have to implement these things. Verculation is, well, Verculation is the first step. With Verculation, we'll already be able to gain 200 GB, so on a classic node, well, I'm thinking of mine, which is about 800 GB on average, you already remove 200 GB, you arrive to stay under the tuarve tu V s terrain it's not bad super well hats off on the in any case the synthesis and popularization of these of all these steps it was it was super clear and it's not an easy exercise especially pardon excuse me but in fact there remains there remains one item on the well there remains one the splurge indeed yeah but okay yeah ok it's less no it's not less interesting but it's the bonuses or it's bonus abstraction that kind of thing we don't have but we can talk about it if you want we can talk about it maybe at the end if we already have some questions I suggest we answer that in particular Pai's question on the MV burn in all this where does it fit at what stage yeah uh so MV burn that's part of scorge so I talked about PBS rather uh and I said in fact that the idea of ​​PBS is to have a market that allows validators to source their block uh The idea behind MVBurn is to bring this market under the control of the protocol because today it is completely outside the protocol; it is operated by software called MBoost that valuators can run alongside their node.

Bringing the market under the protocol's control means that the protocol has a view of what is happening in this market, and in particular, it is able to say, "Well, the maximum value that has been offered by the builders is, for example, 't'." So it can see the offers that the builders are making and it can understand the value of the MV in the block that the validator will produce, or that the validator is the source of the builders' value. So if the protocol manages to retrieve this signal, and if it manages to retrieve it credibly, then the signal is a true signal of the value of the block. This allows the protocol to capture this value and tell the validator, "Well, I know the market is offering you 10 ether, so you give it to me." Well, that's already what's happening with IP 1559, so we have a credible signal, uh, congestion on the network, therefore demand for the inclusion of transactions in the network, it's a project to retrieve the MV value proposed by the builders and ahce.

We have a disconnection, the most [Music] bad, yeah, I can give a brief overview of the BN status. There's still some research to do because there are questions about whether the signal is credible, whether it's possible to deploy MBN in the protocol without making too many changes. The answer seems to be no, we probably need to do PBS in protocol before we can do mburn, and more and more we get the impression that to do PBS in protocol properly, we need to do single finality, so there's no dependency before Emily burn. So yeah, it's still under study. Great, uh, there's something Go ahead, yeah Guillaume, no, if you wanted to add something, no, I meant, yeah, I meant, Thom's problem is, why is it so slow?

Well, it's because there are a lot of people using it. I mean, if nobody left the chain, we'd say, "Okay, it's not a big deal, while nobody's watching, we unplug everything, we unplug everything, we ask people to unplug everything, we try something, and if it breaks, well, it's not a big deal, maybe three users put €3 into it." When it's a system that's already much more, that has many more users and also has a monetary value in the hundreds of millions, yes, billions, that's the image, anyway, no, no, but it's true, I don't know how much, but it doesn't matter, uh, when you have this kind of thing, well, you have to take your time and make sure We don't add any boxes, and that's precisely what we were saying. Sometimes we discover them, we accept living with them because we think these bugs are n't a big danger, but they're not really bugs, they're more like design problems that can lead to theoretical attacks. If there's really an attack we know of that's practiced, we don't obviously use something like that, but precisely because we discover these kinds of things, that's why we don't release them immediately, we come back to the table.

Yes, on the other hand, I was going to speak English again, we're putting some questions back on the table. Before we get back to the chat questions, there was a small question I'd like to ask you about the article we published in France on Baling attacks, the author of which is Maxper. And I know you worked on it, Bernab, so I think it's interesting. To get to the point quickly, I think we have about fifteen minutes left if we want to finish within the hour, so we don't have to go into too much detail, but it's interesting to discuss it. I think we can elaborate on it later, and I also plan to send additional information, remind you of the article link, and so on.

So if you have any further information to add, we can send it. But overall, regarding the article on the B-series attack, are there still risks? Is it considered by external developers? Yeah, I can give some context. In consensus mechanisms, there are two properties that really interest us.

I'll give them in English; I 'm not sure of the French word. The first is safety, which means bad things can't happen. So what we're trying to avoid is having two blocks that are finalized. And which are on different forums, so that would be the worst-case scenario: no one would know which is the real chain because there are two versions that are equally legitimate, so potentially not socially legitimate, but at least technically legitimate. So that's safety.

There's the other property that we want from the consensus, which is liveness. So good things happen eventually, so we manage to finalize at the... It's a time-traveling attack, and it's a bouncing attack. It's really an attack on liveness, so basically the idea is to perpetrate two forks that never truly resolve themselves because honest validators are constantly being moved from one fork to the other. They're told, "Okay, fork A is the legitimate one for now, the one with the most weight.

We can't finalize it because we split the validator committee in two, so we don't have a final decision. We also don't risk safety, but we can't finalize it because we keep sending them back and forth between the two forks. One moment they vote at the top, the next they vote at the bottom, and so ultimately we never have enough votes to reach an agreement." So, a bit of history on this: there was a patch for this known bouncing attack. There was a patch that was implemented, I think, before...

Even if the good chain is launched or shortly after, it has been shown that this patch wasn't very useful, that other attacks could occur, notably an attack called splitting. So, the new paper that came out at the beginning of the year by this French research group showed that, in fact, the patch can be attacked even without splitting. So we already knew that the patch wasn't very useful, that it did n't solve everything. What they showed was that it was even worse. In the meantime, the patch has even been removed, so it's no longer part of the Ethereum consensus because it was complicated.

Since we didn't really have a complete study on its consequences, we knew that it solved one problem, but perhaps there were 10 others because of this patch. This is often the case; these consensus models are really very sophisticated, and you can't make a change without producing effects that are very difficult to anticipate. So now this patch no longer exists. Does that mean it's not safe? I don't think so, because these Bing attacks, again, are n't easy to launch.

You have to control a certain level of stake and have a certain precision on the peer-to-peer network as well. The ultimate fix, in fact, is to switch to single finality, so to completely change the consensus model and solve all these problems we have at once. There could potentially be intermediate fixes; again, we have them in hand if something happens. We can release them relatively quickly. I don't work much on consensus anymore.

We worked on it a bit because we detected a bug while doing our research on MeV. We realized that the consensus had some problems, so we spent some time on it. Now there's a consensus team that's really dedicated to it, with experts. So yeah, I'd say it's in good hands. That's all for now.

Thanks for the clarification, Max. Do you have any additional questions on this? Don't hesitate, I'll go back to the questions. Let's change the subject a bit, and at the same time, I'm trying to move forward in time, partly. But so, this is S's question for the Cancon update: which EPs are most likely to be chosen alongside Leip 48 44?

Yes, I had the list there. Yeah, well, I think they're not even likely, it seems to me they've already been chosen. Yeah, okay, thanks Barnabé for the list. Hi. Okay, so yeah, I'm looking at them because I don't have them memorized, but indeed, well, there's an added instruction.

After that, there's... what? Oh yes, well, yes, so if that one is still quite good, it's the removal of self-destruct. Well, it's not quite total removal, it's the removal... there are a lot of contracts for reasons of...

in fact gas-saving measures create temporary contracts, and what's more, they always create them at the same address. So, if we want to remove ` selfdestruct`, and we do remove it because there are many of these, it creates many problems. Well, even the basic ` daorac` instruction is complex and quite tricky. So, we wanted to remove it, but it's true that some people still need it. Removing it, even if we know that's what we'd like, will still break quite a few use cases.

It will simply break quite a few contracts. So, we use this somewhat intermediate solution, which is to say, well, if it's in the same transaction that creates the contract, we keep the old way of working. If it's a new one, well, if it's a contract that created a transaction, then the transaction that created it was created in one transaction and then in another transaction, the contract calls `selfdestruct`. Here, on the other hand, uh, it's more ENF, it's the, the, the, the, how, the behavior is to say, well, now the contract, in fact, we remove all your funds and then the contract, we leave it as it was, so, so you don't want to recreate another contract at this address, there you go, so that's it, that's the thing, it's a bit big, otherwise there are codes for the, a bit big, it's the biggest, it's really the IP 48 44, add the BLs, indeed, you have to understand that indeed the IP 48 44 is so big that all the things we put next to it, it's still a simplicity, a relative simplicity, but it's another, it's another order of simplicity, that's for sure, uh, so, yes, well, there's a mcopy, well, that's a standard instruction that we find on all, on all real processors, so why not in the VM, and then, uh, make the, yeah, the, the, how to say, the roots of all the Bicon blocks accessible From the VM, well, this is for proofs, it's simple, so it's for verifying proofs. So this is so that applications can retrieve the, how to say, the, the H of the block, and if we pass them a proof, well, they can verify that such and such a value was indeed present in the block state at such and such a block height.

Then I'll perhaps note one last thing: the IP 7514, which was added relatively late in the process, yes, a week ago. The idea is to make the queue for accessing the Validator set slower. In fact, it was programmed to let in more and more people as the number of validators in the set increases. So basically, it amplifies the speed to join this set. It's not a bad thing; again, the more validators there are, the more secure the network is.

But it's true that with the consensus model, which sometimes raises limits, there was a box Regarding clients, quite recently with the dominance of Lido and Quing derivatives, there have been questions about whether a more profound reform of certain aspects of the consensus mechanism is needed. And therefore, could we give ourselves a little more time by limiting the queue? It was done quite conservatively, so it's not really a limit. Well, yeah, I think that's half of what we expected. But there you have it.

So, it's something that's being discussed quite a bit right now, and I think there will be even more discussion because it ultimately changes quite a few things from an economic point of view. And so, this is even... these latest updates on LSD will potentially be released at the same time as 48, 84, and at the same time as BL. Yeah, that's right, 75, 14. So, there you have it.

It's true, it's the most controversial, but at the same time, it's not here to stay. It's true that if you're in the queue waiting to be promoted to validator, well, that's a shame, you'll have to be a little more patient. But at the same time, there are side effects that will start, or have already started, to cause bugs. So, to save time, we're going to implement this. It's just slowing down the number of people joining the network, so it's annoying for them, but it's not a big deal.

Okay, maybe the last question, question S, I think it's related to the B attack. When you find potential theoretical vulnerabilities, how do you manage discussions on the subject? You mentioned a kind of NDA, but with whom does the Foundation establish it? Is it only between people who have found the potential vulnerability? Do you have an answer to that?

Uh, I don't, I missed something in the question. Could you repeat the question? You have some questions, yeah, we don't have the same ones. How do you manage the discussion internally? I imagine what the process is.

Uh, we ask if you have some kind of non-disclosure agreement, a non- disclosure agreement, to put it in French, uh, and if so, well, yeah, how do you manage these potential vulnerabilities? Uh, go ahead, start. Yeah, I think it's quite different actually between research and development. When we found the vulnerability in the consensus mechanism, I mentioned it briefly, it was the ex- ROR. We talked about it with the development teams to see if it was something that was potentially directly attackable.

We made the decision to publish quite quickly. We wrote a paper about it, which appeared in the weeks or months following our discovery. Often we try to highlight theoretical bugs to say, "Okay, this is something we need a little more attention on and potentially people who are interested in working on it." Yeah, again, insofar as it doesn't give a An extremely specific recipe for bringing down the network, so yeah, that's my answer as a researcher, but I think Guillaume has a slightly different perspective. Yes, well, it's true that when we consider a bug, it's because it's quite realistic, or critical, you know?

So what do we do? Well, actually, we have a series of... no, no, well, clearly there's no... there's no approval, there's no support, it's very decentralized. We look at who it affects, we try to...

there's a security team within the Foundation, so we talk to them all the time. Generally, they're the ones who bring us bugs, by the way, because when someone finds a bug, they contact them. So, they come to us. It doesn't go through, it doesn't go through like other problems, through GitHub for example. So when we find something, well, we generally go and see...

either it's directly with us, or it's, for example, as I was saying, it could be... At Google, well, we go to Google, and when we find something, before delivering a fix, or rather a solution, what we do is contact people—I'm talking about Guess because Guess has been cloned many times to make roll-up banners, to make things— so we look at it, we discuss it with roll-up banner teams, for example, or other chains. We tell them—well, not all at once, because there are some people we trust more than others—so, for example, the main roll-up banner teams, we tell them right away, if it's them, if it's people who are a team we don't trust, quite simply, well, we're not going to hide it, I'm not going to give names, but there are clearly some teams we don't really trust, like Cuxa, we tell them last, and then when we make a fix, because the problem is Because it's open source, there are people monitoring what we do, and we can't just make a GitHub commit and say, "Okay, I've fixed this bug." So we try to hide them in other things, actually. But for example, I was talking about the vulnerability in Go.

When we found it, we released it. In that case, there was no need to hide anything in our code; it was up to Google to do it. We just had to recompile. But a week later, not even three days later, someone found it—read everything, looked at the changelog, checked what happened in Go, and created a transaction that would have broken everything if it had been sent three days earlier. So, we have to be careful.

Yeah, we can't hear you anymore. Nathan, I was transferred, sorry, uh, I was saying it was great to have this information that we do n't often hear about what goes on behind the scenes, and well, it was great to have your comments on that. I see there are a few questions we haven't had time to answer yet, it's already been an hour, so I suggest we kindly release you from these questions. Sorry, we can answer them later by text, maybe. Perfect.

I suggest we continue, it only takes 2 seconds. Okay, but people want to eat. Yes, people, oh yes, people, if it's people who eat, leave your questions and we'll answer them. Okay, yeah, on the disc, very good, well perfect, I'll try to save them so they don't get lost in the dust. But anyway, it was great to have you.

I hope we'll have you again. wo n't hesitate to invite you to present your new podcasts. Uh, a big thank you. I think on behalf of everyone who was there, and I hope we will publish the recording on our YouTube channel and send it to our members. We'll see it in the newsletters.

So, we already had a small community, and it was great. I think it's really rare to have you. I'm so grateful to have had you live and for you taking the time. So, a big thank you. And there you go.

I'm sending everyone the link to their latest podcast. It's true we didn't send it, so to the latest Explorers Podcast that we mentioned with Domoti from the foundation. And there you go. Finally, if those who listen to us aren't yet members, you can become Ethereum France members via our blog, the website etherum-france.com, and we'll send you, as I mentioned, a newsletter with a short recap.

And then... Then the recording, there you go, thank you, thank you again Guillaume Barnabé for coming today, it was really great, wow, thank you, bye, thank you, have [Music]