PM/AllCoreDevs-EL-Meetings/Meeting 145.md

All Core Devs Meeting 145 Notes

Meeting Date/Time: Thursday August 18, 14:00 UTC

Meeting Duration: 1:16:22 hrs

GitHub Agenda

Audio/Video of the meeting

Moderator: Tim Beiko

Notes: Avishek Kumar

Decisions Made / Action items

Decision Item	Description	Timestamp
145.1	Sepolia ETA to upgrade is till August 21st. Still we have time for 3 days	6:25

—----------------------------------------------------------------

Merge Updates

Sepolia post-merge upgrade

Micah Zoltu 5:28: okay, hello everyone Welcome to All Core Devs 145. Just posted the agenda in the chat. Mostly merge related stuff today.Yeah and then some around Mev boost and the obligations there. I guess to start off the Sepolia post-merge. Upgrade was supposed to happen yesterday but because we've had a lower amount of active validators on the network. It still hasn't hit. So when I checked yesterday the ETA was about August 21st , which is three days. So if you run a Sepolia now, you haven't upgraded. Yet now is the time to do so. Anyone else have any thoughts on this? Any comments.

Mainnet Shadow Fork

Micah Zoltu 6:45: Okay, So next up we had a mainnet shadow fork today. Kerry or Marius, do you either, if you want to give it a quick update.

EF Berlin Office 6:58: Yeah, I can give an update. So we had mainnet Shadow Fork Eleven happen about an hour ago. out of, I think 99.8% participation before we like 96.5% 97%, so that means out of like 35 nodes 34 maybe through. The one node that didn't make you through. Just hadn't finished sinking. So in terms of making it through the transition. I think this is the nicest shadow of what we've seen so far. We did notice some invalid blocks being produced by Erigon. We think it's going to be the same issue that we noticed on Gary. So potentially also the same picks. We'll look into it and check that out and I think the Nethermid team noticed something with Nimbus. But that was already an old issue, and had been, I think It's already in that plan to be fixed. That's about it. Congrats everyone.

Tim Beiko8:01: Yeah, that's very good. I don't know if anyone from Nethermind or Aragon wants to chime in more.

Łukasz Rozmej 8:09: So go ahead.Marek

Marek Moraczyński8:15: Okay. So it's a never ending story with uh block production and giving enough time for uh blood production for the L. But the fix from the team is already in. VR. I think we also notice it for a long time. But maybe Lion could say something more about it.

Lion dapplion8:48: I am sorry I have not been personally following the digital.

Tim Beiko 8:58: Okay, and then on the Aragon side in the paths, comments?

Andrew Ashikhmin9:01: I am on holiday this week. So I haven't looked into it. But I saw the parent posted this question and out, Yeah. So maybe Julia from our team will take a look. But also, Barrington, could you maybe post an example of an invited blog like more more? Me, if you give us more details, we can investigate What's what's happening?

EF Berlin Office9:31: Sure. I can forward the information.

Andrew Ashikhmin 9:36: Thank you.

Tim Beiko 9:45: Anything else on the mainnet shadow fork?

Mainnet 5GB DAG size & hashrate

Tim Beiko 10:00: Okay, next up. So basically we set the Ttd on the Cl call last week, optimistically assuming the hash rate trends would stay stable, and the 5GB dag increase would not massively change hash rate. So we are basically right below 5GB. Now, I believe we're at 5GB dag, if you include the hash of the ah, the block you're mining. We saw a tiny drop in hashrate, but there's a lot of noise in those numbers, so it's quite hard to tell um, And previously we had seen a rise over the past week, so it seems like we're still trending nicely. I am curious to hear from client teams like. If anyone feels like we should change the Ttd value, but from like a high level like it seems like it's. It's probably good to just keep that one. Anyone

Micah Zoltu 11:10: What will be the estimated merge date and time. If Hashtray stays exactly where it's at right now.

Tim Beiko 11:16: September 15th.

Micah Zoltu 11:19: Even with the increase that we saw.

Tim Beiko 11:22: Yeah, it's like back to where it was a couple days ago.

Vitalik 11:32: Yeah, I doubt Del was showing about 1:30 A. M. Utc. At the beginning it was showing about 4:00 A. M. That will link you.

Tim Beiko 11:36: Yeah. And like you can see, like you know, I just shared my screen with like there's a bunch of variations that we went this high and like above one, 950 and as low as 107. So like There will continue to be noise. Yeah, I think we're trending nicely, and I also saw that a bunch of clients have started to like to merge prs with this. So given, there's no massive deviation. It's probably easiest to keep that time.

Tentative mainnet TTD execution-specs#585

Tim Beiko 12:23: Okay, so no disagreement.. So I guess, in that case we can go ahead with this Ttd: I think client teams can put out releases with this ideally today or tomorrow, so we can announce them very early next week. And yeah, those will be the releases for mainnet, and, like we discussed on the last call. If el teams want to, then upgrade those as we approach Bella tricks or write after Bella tricks, we can advertise newer releases because it is kind of along a long stretch before we have. But yeah, this is the number, and there's a couple. There's a couple of questions in the chat about What if there was like a huge hash rate drop? Ah! Because of minor scaling and what not. I think, you know, if we see some massive deviation after Bella tricks has happened, we'd always do A. T. V. Override if we did. Ideally not. But yeah, I think we can. We can go forward with this, Have high confidence. We're not going to hit it before Bellatrix, and pretty good confidence that's like we'll hit it around the 15th. Any other thoughts, comments

Micah Zoltu 13:39: Blog Post is going out on Tuesday. Is that correct?

Tim Beiko 13:42: Yes, So Tuesday, August 23rd morning Pacific. You can expect the blog post, and a couple of clients said that they're going to put out produces on Monday 22nd, so you can. If you want to see your, If you follow your specific clients, you'll probably get their release before, but on Tuesday we'll have all the releases combining a single blog post. Any other comment starts on this. Okay? Well, yeah, we got it mainnet releases. That's pretty exciting. Okay, there are two other things on the agenda

Kiln deprecation

Micah Zoltu 14:38: Do kiln first..

Tim Beiko 14:40: Okay, Yeah, Kiln might be easier to wrap up quickly. Yeah, Pari, you were talking about potentially deprecating kiln further than expected. You want to share a bit more on that.

EF Berlin Office 14:58: Yeah, So we were just looking at the kiln network over the last week, and we don't really see that many transactions on that, and it feels like, since we have merged uh two long-standing test nuts as well as the third test net.There's no real reason to keep killing around um. At this point we're just kind of doing monthly updates, and it's costing us money and time that could be spent otherwise. Um! So i'd like We had already announced that we'd be depicting Kn, but that was after the mean in March. I'm proposing that we deprecated a bit earlier.

Tim Beiko 15:34: Right? So yeah, the the plan, I think, was deprecated like basically around the minute merged like a month, which is now a month from now. Would you do like even quicker of that, or is like, Can we say we just shut it off the day main merges. Is that good enough for you?

EF Berlin Office 15:50: I am fine with either one. I think I have a loose preference for just doing it earlier, because at this point we're not really spending any time updating it, and if no one's using it, and it's un updated and it's costing time and money, there's no real reason for it to be around.

Micah Zoltu 16:11: The transactions you see on it. Do we have any idea what they are?

EF Berlin Office 16:14: No. But I'm assuming they're just some bots that's doing basic value transactions in the hope of some nft.

Tim Beiko 16:22: There were some people who did promise, some kiln.

Micah Zoltu 16:31: So as far as we know, we don't. We don't believe there's any apps that are like using kiln as, or test that, or anything.

EF Berlin Office 16:38: and I think most, if not all, have already moved testing to Gorli or Ropsten or other places. The only other reason to have kept kiln around was that it was fast to sink, but superiors arguably, just as fast.

Tim Beiko 16:55: so I guess just to give people some heads up. Could we deprecate it when Bella tricks hits on like September sixth, and we can announce it as part of the we can share it as part of the blog post, so we'll have the blog posts going out next week, and then we'll give people two weeks if they're using it to move off um, or do you think we should deprecate it like?

EF Berlin Office 17:22: I think that is okay. I think we should just add it in the blog post next week, and then give people another two weeks in case they want to. They want to fight the decision.

Tim Beiko 17:36: Okay, I like that, and I think. And then the worst case. We extended another two weeks beyond that, which is what we'd originally advertised. But yeah, we can. make sure to mention it in the merge blog post. Okay. Anything else on that?

EF Berlin Office 17:58: Nope. That's it. Thanks.

mev-boost relay censorship (& censorship resistance more broadly, see below)

Tim Beiko 18:03: Okay. Thanks. Um. Okay. So next up we have a pretty immediate topic. So I guess two topics Micah put up. So first, basically the challenges with mev boost that relay censorship and then at a higher level, how proof of stake and just a Ethereum generally can address censorship on the network. I think as per discord and twitter this week, people have very strong opinions about this. I think it's also a subject where people have different levels of like degrees, to which they're comfortable, voicing their opinions for a bunch of reasons. So we can try and have this conversation on the call. I just ask that people kind of be respectful and charitable and mindful that not everyone wants to voice their opinion about these complex topics on a live, recorded, synchronous call. So we can try our best.

EF Berlin Office 19:16: I think. Also, it's very much worth separating out the specific concerns around the Mev Boost and the whole kind of architecture there, from the broader, higher, level concerns of just like censorship resistance just to make sure that we can actually ground the like Mev boost conversation and like the software, and like markets that exist today. So with that, said Micah. Do you want to kind of give a quick overview of the situation with regards to Ivy boost, and like the problems as you see them.

Micah Zoltu 19:57: I'm actually surprised we have so much time, I thought, for sure you were going to find a way to pack the agenda to avoid this topic but apparently no one else showed up. So I do agree with Tan, who tries to keep this conversation focused on the technical stuff as much as possible. I know it. This conversation may bleed over into martial cell phones. It's philosophical stuff, but we should really try to avoid that. So the Tlvr. For anyone who's been living under Iraq. The Us. Government recently sanctioned one of the contracts on ethereum. So allegedly how to interpret that us citizens are not allowed to interact with those contracts. And then some people are interpreting this in different ways. Some people believe that means that if you are a relay, you're not allowed to relay transactions. I I would assume that some people also believe this means you can't gossip about such transactions there. Some people believe that you can't interact with any address who has interaction with those sanctioned addresses. There's just a very broad range of beliefs of what this actually means no one's quite sure yet. So people are implementing different solutions all across the world. For the sake of this group and this discussion, I think the one that impacts us the most is the decision of um flash bots to censor transactions that are coming into the flash bots relay. I think they actually do it on their builder side. I don't know the exact. I don't remember the exact technical spot where they do the black listing, but the functional effect is that if you send a sensor transaction to flash bot three-lay, or if it sees one in the membrane, or you send a bundle to them, that has it. They will just lower that one door, that block for that transaction, and they will line up. The problem, of course, is that if we kind of I'm going to be a little vague here. But if you know, launch with mev boost and flashbot relay, or whatever that means, then it means that functionally we're launching with censorship built in from the merch like as soon as the merge lands we've got censorship happening, So we hit the ground. Now there are some caveats here. One, of course, Inner skin or balleters can choose to use whatever software they want. We can stop them, and there is no way for us to functionally stop people from sensory. There are flashbots. Isn't the only relay builder. There's also blocks, for out. It has two relays that will not be asserted and will not be censored, and they have a third relay that they'll be providing that is not live yet, but they plan on building that will be censoring. And then there's a third party um manifold who claims to be building a relay, but they don't have anything to show for it yet.

And so the question I think we have to answer, and this is again ideally, if we can answer this somehow without getting the philosophy that'd be great, But I don't know that's quite possible. Do we want to launch? Go into the merge with Mev Boost and all the associated software and connections, and, you know, tutorials and documentation, et cetera, when we know that the centralised entities that are going to be in control of this are providing censorship software to their users. I don't think there's an easy answer to this. I mean, I have pretty strong opinions, but even that I recognize is a complex situation. And there's not an easy and obvious answer, especially with blocks throughout. Who the flashbot is is more clear-cut like they're just. They're only offering censorship. That's the only option. A blockchain is a little different, because they are offering the user to choose the caveat. There is that you'd be pointing users say, Hey, go check out Blocks route, and then they go to Blocks route and watch out and tell them. Hey, this is how you undermine censorship resistance of ethereum by running this thing, or if you don't want to undermine it through your own missing. And so there's something I can definitely see. You know some people may feel differently, and you decide the other caveat. I'll say it before we start discussing. Is that. I recognize that this is what the all-core dev's call what I recognized, mostly the execution layer devs, and we kind of handed the keys of the kingdom, so to speak, over to the consensus layer. So the constraint is in a better position to actually do something here, and I think the execution player is the reason I wanted to bring it up just because the merge is so close. I think there's a value in getting the discussion going, and because we do have something, since their clients on this call, and so it's a good opportunity to discuss and I think that covers most of the situation. The one thing I do want to remind anyone who's listening. No clients currently, or have any plans of hard-coding any specific relay into their clients. The clients are only building a client that has a configuration parameter, that you can fill out where you can provide a relay, and then that relay can then do whatever it wants. And so, just to be clear, no one is no one on the ethereum core dev, hard coding censorship in, or anything like that we're just discussing. Should we kindly support and encourage, and these people who are adding building censorship tools? So that's it. For now we can start a discussion.

Tim Beiko 25:03: Yeah, that was a really good overview. Dankard Feist I think you've had your hand up first of them and then Vitalik .

Dankrad Feist 25:11: I think Flash botmight actually be doing something stupid and shooting themselves in the food. By doing this I can understand their behaviour, but it might not be that they don't have to do anything at all, but ignoring that. I would generally agree with you that we shouldn't be going into the node. If there is only a sense of adoption available. I think that would be a terrible signal. That would definitely be a huge problem. Thanks to mev Post. So it's for now open sourcing their relay. And they're being alternative, very likely from the start. I mean, that's definitely something we should ensure. I actually don't think that this is going to be a problem. So I'm actually, in a way this whole situation could have the effect of actually saving us from the huge problem that was very likely to have before that. We will only have a finger relay. And now we'll actually probably have several from the start, and I expect that a substantial majority will actually be using non-censoring relays. So currently I don't think that we will see the situation that you're here, that actually there will only be flashbots, and maybe we stand doing it so. There will be censorship in this area.

Tim Beiko 27:12: Vitalik you had your hand on. Zoom.

Vitalik 27:14: Yeah. So I just wanted to kind of give a brief uh purely technical comments on the different kinds of censorship that might happen right. So I think the one big new one that it's important for people to understand is the difference between two things not to include transactions in blocks you create versus self-working right? So software working basically means that if there is a chain that contains transactions that you want to exclude, then you do not create walks on the chain. You also do not attest to the chain, and you even attest to a competing chain. But you attest to the biggest chain that does not contain the transaction that you want to explore. So softworking censorship is not something that is being facilitated by any software that's being developed that I'm aware of today. But it is something that in order to kind of break if they're an arms transaction, of which a guarantee is only fifty. One percent of the alligators would need to participate right. So that would be a more extreme scenario. But it's one that both require. It only requires a majority. But, on the other hand, that's much further away from happening in terms of just what barbies are being considered and what software is being built.

The other type of censorship is just basically exactly validators as proposers exercising their ability to put whatever contents they want. It's in their own block, right and I think we've even had this discussion about that in the past in the context of some validators choosing to just make completely empty blocks that contain nothing at all right. But this kind of censorship is closer to realistically happening. But it doesn't have a 51% requirement. There is 100%. Right? So if let's say, even 80% of validators run software that creates blocks that exclude some particular transaction then that transaction will, on average, get included after five blocks, because you just have to wait until they get a block created by someone who does not. Yeah, basically all that's needed. So I can really avoid significantly degrading ethereums. I guarantee this is basically for it's a relatively small percentage of the validator to adjust the running, non-censoring software, which is something that if needed we could even rely on some portion of all getters and do it get out drastically right, and then there are also middle grounds. Maybe if you don't even want to attest to the censoring blocks. Then, you know, you just kind of stay silent on that evolution entirely. But then I think those are not really not very realistic right? Because once you start making distinctions, I'm not going to attest to a censor and change. But I'm just going to stay completely silent. Then you basically stop yelling, and you might as well like that. So that's basically what the kind of different scenarios that I see, and I think it's important for us to to just talk about them separately, because they have like. There's a different threat model. There's a different kind of upper bound to the harm that they can cause, and there's different responses that they require.

Micah Zoltu 31:10: A quick follow up on that Isn't. The threshold required for a censorious soft fork to occur significantly below 50% due to proposer. Boost!

Vitalik 31:21: Good question. I thought it actually wasn't. I don't know. I don't know off the top of my head. The exact answer. And then I think once you get into that stuff, there's also all of these subtleties around Are we talking about censoring some of the time, or all of the time. Are we talking about the adversary having an ideal network model? What we're talking about like a realistic network. But yeah, it is like somewhere somewhere between, like twenty percent and fifty percent depending on. I guess that the pacific assumptions that you use, and that number will probably increase because it is fifty percent over time, as some of it. Or if it's the first day come on.

Tim Beiko 32:08: Thanks. Yeah, that's a really useful distinction. I see. Yeah, Victor, you have your hand up There's. Yeah. Do you want to just quickly share your thoughts? But I think, yeah, Do you want to, maybe just like quickly against yourself and share your thoughts?

Victor Zhou 32:25: Hi So my name is Victor, and I work mostly on the Crc. Side, as the eip of the eip author, and I also help out at touring. I feel like this problem is softened through a protocol level. It will leave people no choice. They have to either leave the ethereum or they have to have faith with them. But a set of censorship altogether. So in my position it will be solved at the application layer. And so countries where sovereignties can declare that they want something to be under their jurisdiction, and then you have to register to spot contract, and then they can also say that there's a war garden. We either one their jurisdiction or not, and then everything else is for as if it's in a row right now. So that would be my take. So Yeah, I simplify. I object to something in the Protocol lab, and I think it can be solved in the application later.And there, you see, I see you shared an eip in the chat. People can definitely comment there. I do think it's valuable to keep most of the conversation here focus on basically that around the protocol level, because that's the folks we have on the call.

Tim Beiko 33:21: There's definitely nothing that could be done there. On top of the protocol and yeah, I appreciate you sharing the link there. All. of course. Yeah, Mamy, you have your hand up.

Mamy 33:53: Well, I'll skip my difficult position. I've applied for I need to check by Micah. But I want to talk about the incentives. So three days ago, we had no alternative to a relay besides flashboard and many staking pools committed to the users that they will maximise their revenue. And so we run any Mev software which puts us in a delicate position. But now that we have alternatives, what will happen is that we have a choice between running censoring transactions and some sort of transactions with likelihood and sense of being giving most rewards because there are just more transactions to which any censoring software could be exploited by just the thing that was done with a zero point, one. If that were distributed to many addresses you can include any censored address, and just send them to your point one if and then your transactions cannot be sandwiched, attacked by flashbox. So if we have any open relay, I think the censoring will fall flat on space.

Tim Beiko 35:24: Thanks. anyone else.

Danny 35:31: I want to make a quick technical argument just in terms there was an argument to remove. I know the argument is less strong. Given I don't realise, but there's an argument to remove the new boost from clients. Um, I just want to point out that that would likely result in five forks of consensus layer clients in which um, you know, there are Mev Prism MEV Teku, etc. Sorry to remove the builder Api, which would probably result in many forks of software, which is the thing that I think everyone here does not want to see. As it just introduces potential errors down the line. So I think, avoiding that world is also kind of healthy from a consensus standpoint.

Tim Beiko 36:24: Yeah, and just to touch on that, because I think skimming the discord and twitter and whatnot. There's a couple of degrees of separation in the software right There's like the consensus layer client which exposes a builder. Api Mev boost is software developed by flashpots which interacts with this builder Api to provide blocks through it. The consensus clients. Then there's many relays who can integrate with. There's any relays that can be launched to integrate this with this builder? Api. So Yeah, there is a decoupling there that's worth highlighting. Lucas, you have your head up.

Łukasz Rozmej 37:14: I just want to point out that the current implementation of Mev that is running on my network now is a lot less prone to censorship, because, while the nodes that are building the blocks, we'll get the bundles that are censored. They still pick transactions from the sample to fill the block out, so you cannot probably censor it completely and I don't really like that design that the whole block comes from a third party and you cannot add anything to it. It's the root cause of this problem to some extent.

Tim Beiko 37:56: Right? Does anyone from flashpoints actually want to find it ?

Thegostep 38:07: Yeah, I can speak a bit about the technical sort of design goals. It is a sort of software that helps validators outsource block construction. In particular, sort of the difference I have from the way that , I guess, works. Does it enable client diversity? And it also allows solo stakers to participate and outsourcing to walk without sort of reducing. So um, you know that's a reason for having full block proposals or full block submissions as opposed to um Partial block submissions.I think there's some good proposals floating around to be able to augment full block proposals and return them to some partial block. Constructions which allows validators to append those transactions to the end of an outsource block. So you know the goal with introducing those modifications is to provide more granularity to the transaction types that they are posed. So it's not exclusively a full block.

Tim Beiko 39:29: Thanks, Micah. You have your hand up.

Micah Zoltu 39:34: Yeah, The I think for me the thing that I would like to see, the most, especially now that we have a couple of different relays and the flashbacks relays, open source people can run their own. I'm less worried when and when I originally post this, I think The thing I would like to see ideally from the core dev is just social pressure and lobbying from users. Don't run relays at Censor. I think the cord apps have a lot of influence and a lot of power. I think a lot more than they realise they do. And so, just you know, on Twitter, on wherever you go, hang out. If someone asks you, should I run Mev and tell them? Yes, if there's nonsense in relay, and tell them no or not, and encourage them strongly to use non-century ones. And it's especially true for anyone who's working with these big companies like coincidence or whatever. If you're doing community outreach. I think it would go a very long way to just strongly encourage people. You know, don't censor, try to run things that are non-censorious when you're recommending things to people, recommend things that. Don't censor transactions and stuff like that. I think that alone, combined with the fact that we hopefully will have multiple relays should be enough to protect us, at least until we can get Pbs and something more.

TimBeiko 40:54: Ah, Marius,

MariusVanDerWijden 40:56: Yeah, I'm always trying to convince people to run their stock, get their stock. Never mind, or the stock configuration of the client that will give you enough transaction fees, and you don't need to extract them. Maybe I think if you are a benevolent user of the network, then it's fine to take a one percent or 2% cut a year too. Yeah in order to be like a good person in the network. So just run your normal client, Don't, extract them, maybe, and you won't have this problem, anyway. Tim Beiko 41:37: Right? Yeah, it is worth noting like Mev. Boost is not like something that's included by default. When you set up your note. It's like an addition that you need to run um, and it's not required for no operators. Ahmad can you introduce yourself and I mean, share your points.

Ahmad Bitar 42:08: Hi! It's Ahmad from the Nethermind team. Uh, I just have a question if someone from Rocket pool is here like is Rocket pool planning to keep running. It may be boost if it kept censoring or not

Danny 42:24: We can really get into what particular operators are going to do here.

Tim Beiko [42:29](https://www.youtube.com/watch?v=jJaCaS0WbIw&t=25 49s): Yeah, I think I would rather push that to mev Boost. As forums and other operators, As forums, we don't usually have those full of them. First and second, I don't want to set the precedent that we solve all the community level issues on this mining, and it's called every two weeks. But yeah, I'm sure they have a discord or Telegram.

Terence 42:58: Yeah, I just want to add on top. Stephanie would have an issue encouraged user using the 19th century option. But it's also important to um recommend users, because by using methods or using the regular network, to also sport to instruction, it's also not risk-free in terms of getting a blog as safe as possible, because from our primary bench. We're seeing it's actually adding two to three times more latency. So that means there's a higher chance your block could get reordered right. So we also need to educate that part. Also optimise that part as well.

Danny 43:45: Yeah. I mean it just to reiterate, like running mev Boost out the gate at merge. You're introducing additional technical risk into your setup, and you need to make sure that you're okay with those risks, you know you're not necessarily introducing risk of slashing or anything like that. But,you're definitely just at risk that that block is not going to make it, or communication is going to fail, or you know it's just another piece of software that's in this mix. So you know, even if you are going to do this. Think about it. Ramp up over time, maybe.

Tim Beiko 44:19: Yeah. And just to make sure we have time to move on as well. And don't kind of burn around in circles too much, and we can definitely get to you. But quickly, Micah, you're asked is you know, can kind teams advertise. You know the users that they should run other things, and you know Mev Boost with some potential sensors and relays. It seems some kind things you'd have already, with some degrees for different reasons. Also that obviously a Mev boost is not shipped by default with the clients. So I feel like we've mostly addressed that. But happy to take your comment as well, and after that we can probably move on to like the second part of the conversation.

Ansgar Dietrichs 45:10: Yeah, which I think is good fit, because I just wanted to briefly rewrite for people listening to this on Youtube, and whatnot, just because a lot of this was relatively technical and easy to kind of misunderstand. So just to be perfectly explicit, After the merge we will still be in a situation where the networks will not be censored. If you don't know in North Korea or something when you use ethereum , or your Iran, or like I don't know. Sorry. These may be extreme examples, but like in the network as a whole, it's not sensory. It's all this just as being attractive, but making for this. It's true for our future. So, even though there were a lot of maybe concerned voices on here right now, and after the merge the network will not be sensitive. So just refrigerate that.

Tim Beiko 46:08: Thanks, yeah

Micah Zoltu 46:12: A good Segue into the other half of this topic, also, on top of censorship, shows a very brief background for those listening. All one of the major advantages for a mistake provides us. Come over before is the ability to punish bad actors after the fact, the human coordination. And so this ability of us to see that, hey? Someone did something wrong. Protocol was unable to handle it. But everybody knows that they did something wrong. They treated whatever they could. their steak is locked up for quite a while, and so we can then do something. We can do what's called the x rac-to-based. Software we're using activates hard to address that and take their money. And this provides us with a mechanism to give financial disincentive for anyone doing something that is against the protocol, and this is a very powerful tool that we have at our disposal. Throughout the history of development of proof stake there have been blog posts and articles and specifications, and whatnot and papers that have all discussed this and so it's kind of a well-known thing for those that are deep into the technical details, the proof,and I understand this is part of the design. My concern is that I think a lot of users like end users and stakers in particular, are not aware that this is actually part of the design of a mistake. This is a really strong point. His disability for the community to for someone. I think that one of the things in order to make this make this work so like. If everybody knows that if you know you will be punished severely if you do bad being X, and you're less likely to do a bad thing with X, and if that punishment is strong enough, and the benefits you gain when you're not saying that X are low enough, you may. No one may ever bet X, and so one our hope is that if everybody knows that this threat is there, and a threat is very credible, then no one will do the bad thing. We never actually have to do this. Take this intervention or take this action. So the thing that I would like to see. And again, this is not something that anyone will write in code. This is just a social thing I would like to see as the court of a community, and this is going to be Iran's consensus layer both, since later again we pan ahead of the keys over to them. So they have a stronger role here, but I think all of us having a voice in unison is powerful. I think we need to let people know that if we do see reorgan-style censorship where there are some that are reorganised blocks that contain certain transactions that we will write the code for and release software that slashes or penalises, or takes away a steak, or does something yours out of those stakers. Whatever we do, we will do something to push back on that. Now. Of course, we cannot force people to run software, and everybody will have their choice of what software they want to run. But ultimately, I think we really do need to make a very strong, credible threat that is public and well known to the community that you know the core devs are going to be on the side of the nonsense range train, and they will take. I put forth effort to write the code that is necessary to do that. One of the things we can do to be even more proactive about this. Besides, just, you know, making a statement, we could in theory write the code in advance, so that we're ready to do that and all we have to do should this time come. It is basically fill in the list of addresses, and we're done, and that would be a very, very strong, credible threat if we're not willing to go that far. I'm just, you know, publicly stating, and this doesn't have to be like official statements from teams or anything. I think this just has to be us all of us, Gordon, as being more vocal to the broader community and letting them know. Hey, you know, if someone starts reorganing, if a cartel starts recording blocks and sensory and things so that certain transactions cannot get into the blockchain. We will take action within the scope. What we're able to do, which is, we can write code. We can release code that's the action we will take. And I think, having that commitment out, there is a very powerful tool for deterring any kind of future attacker.

Tim Beiko 50:11: Thanks. yeah. Already Some hands up. So, Lucas.

Lukash Rozmej 50:15: Yeah, but it's not now. We are trading ground that we are the sensors right, and it's giving some moral implications right? If we should have to do it. Okay, it's something different when it's something built into protocol and something different when we are doing something on the web, on our like beliefs, or even live visits like a community, agreed. Then it still can be corrupted easier.

Micah Zoltu 50:46: yeah, I think i'll. I'll hand over a score in a second, because I suspect his response has been as bad as the standing car many times is going to answer this, but the argument there is that if we're afraid of having something fuzzy like, we'll do something. Then we should make a very clear statement in advance what exactly we'll do, and under what conditions we're going to do. I'm assuming that. So you're going to stay in scars. So I'll let you know.

Ansgar Dietrichs 51:11: Yeah, I basically just want to talk about generally agreeing with nethermind. I think threatening manuals, intervention, you know, social sessions, or what people call this is a really dangerous tool. So I think we have to be very careful with committing to doing something like this. It has to be very explicit, under which circumstances, so that there's no kind of arbitrary. Not doing the barbecue punishment. And I think the outline microscope was exactly right. It's basically as I was saying earlier, as long as there's only some subset of everyone that can include transactions like student sections in their own blocks and what you're not allowed to do is free of other people. And so in general, I think the framework to use this. We have all these misbehaviors that we can catch automatically in software, and we already slash you for that Today. There's one. This category of misbehaviour. We unfortunately cannot detect automatically, and that is just not following the fault. Choice right? We have very specific progress rules, and like what you're supposed to be, you as the current head of the chain, and you're supposed to build on top of the chain you're supposed to to to a test to that head, if you will fully deviate from these rules, and that could also be just for personal profit. So that, for example, this time limited its text. And this is basically there are a bunch of attacks where you just basically you willfully fork out blocks before you. and censorship is just one upshot of this and all of these attacks, we would like to automate this session, but the only issue is that we just cannot detect this automatically, because it's indistinguishable on an individual basis from just latency in the network. So we can only take this on a statistical level. So once you do this multiple times or you'll make two or Something. Then we can detect it. And so, unfortunately, that's required to be on the menu. We go in and slash tubes, but it is just an extension of global rules. And so this is a very I think it's not really a slippery slope argument here. It's a very distinct taste, and I think it would be very valuable. What we could do is to just pre announce.This is what we were doing. If I think about it, in terms of implementation. By the way, I would prefer that by the time the withdrawals are life we have at least implementations ready to have a hard and manual hard for free with fraud. So if anything went wrong, I think it would be really good if we could have within a few weeks just have a small fault that just freezes withdrawals until we can go in, and because otherwise people could just withdraw on time. Right? So basically I think, having a mutation like that, ready to go just the case, and we ever need it. I think we go a long way in terms of deterrence. But yeah, I think that's all. And again, like the point is just. It is a very specific category. And so there's no surgery slope. It's just one thing we just don't allow you to do as about.

Tim Beiko 54:03: I saw Dankard. You had your hand up, but you put it down. I don't know if your comment is just addressed.

Dankrad Feist54:10: I think Anskar has already put it very well.

Tim Beiko 54:14: Okay, Any thoughts on this.

Danny 54:18: It's a technical note on withdrawals. So there's a cute exit. This exit queue can take quite a long time if a lot of capital is tempting to exit. So in the event that you do something slashable, and you're not caught yet. Or if one of these more social manoeuvres like it's very, It's actually hard to get a lot of capital out of the system quickly. So I don't think halting withdrawals is necessary actually because of the execution just in most scenarios.

Micah Zoltu 54:50: What is the timeframe to? Let's say, let's say, I think, for most of the attacks you need about thirty, three percent at least to do something meaningful. What is the timeframe to the exodus, and getting a portion of that,

Vitalik 55:05: I think at this point we're at three or four months.

Tim Beiko 55:18: Yeah. It's like three or four months to get a third of the capital out or something.

Micah Zoltu 55:30: I'd be curious. I noticed a couple of people on Chat sounded like they were maybe against this general theme. I don't know if you guys want to speak out. But Thomas and Martin, maybe you're making a joke. I'm not sure.

Tomasz Stańczak 55:46: Sorry, Micah. Can you repeat?

Micah Zoltu 55:52: It sounded like a couple People in chat were opposed to this kind of social, slashing sort of thing.

Tomasz Stańczak 56:00: I was wondering. Yeah, I mean. But but book I was expressing a similar similar feeling that I think that the protocol level solutions should be very strong, and you have the social consensus still as the final process to say, Okay, rejecting what's happening, reject the attacks, and and that's what Pita I was describing uh on Twitter as well, and that's what I mean. Okay, I want to have some kind of social, not consensus like a last resort to action. But let's start to say, Okay, this is what we do, and we start to promote some behaviours. I think we should be able to do that properly for the protocol, for the encryption of transactions. Looking at this I may be able to boost infrastructure and understand how we can promote decentralisation and realise how we can follow the examples that we see already here, just like openings or small players coming to the market. And So far the chain was reacting to the events like this by bringing the eighty players that say, Oh, this is an opportunity for me to show that there is an alternative that I can play here, and if we've seen so many players jumping to social media and the last three or four days. I think we'll run nonsensoring, and realise we'll propose alternatives. It means that's too far. Things are breaking. I was a bit more worried about the questions of the large volatile operator since I'm or not, but they will also be looking at like, okay, like. So if the community expects this, then the operators will appear. That will say that they play other rules, and one hundred and one should all play. For if the community is still all clicking on me to still be fine with it. Then there'll be nobody offering the nonsense ring. Realise, and then, if you start the vocal about it and then fight against it suddenly. You're both against the community, and I guess the chronicle participants, and only means that you are finding your bottle for some reasons whether I deliver. This is a valid approach or not. But then you actually centre outside the protocol.Ah, so yeah,

Micah Zoltu 58:23: And just for a little bit of clarity I didn't mean for this to be related to the may be relaying. I think the relays, while the relays do have the ability to kind of help facilitate a coordination of a State censorship. I was more concerned with the large validated rules, particularly several pools in the same legal jurisdiction that may come under pressure to attack the network from their governments. I feel like we should have some plausible defence against that, because Those people may not have a choice to attack the network like they may be rent attacked, so to speak, to a tech network, and I think we need a way to make sure that we're resilient against that class of attacks.

Tomasz Stańczak 59:08: So what we've seen in the past we had the entire huge i'm sorry Oscar was before. What is the entire category of players proof of approval? Right players, the miners moving to other countries because they were banned in China. Right? So I think the same thing may happen here, and there is enough of the push for moving somewhere else. Then they realise that the data operators will appear in other countries. In the end the network will be representing its community. Will. Do you expect that the community will be hard? Ah! Located in the Western countries and operated in the Western countries. If seldom, it means that actually that community wants to follow these rules. If it's a proper global network, then you'll see representation of all those needs from different regions.

Ansgar Dietrichs 59:58: All right, I just want to say, in terms of how I see the kind of the interplay between the say, the social way of the community and and problems is that, of course, I think there's this layer, zero or criteria that miss the community. And if there is some disagreement about rules, then the community is to choose. Ultimately, I think our role is basically just to set some T falls and basically recommend a way. And you know, people are really violent and disagree. They can focus on it. But you know the control of the network. But I think, given that we are in the position to set defaults, I think it would still be very valuable here to just set the default of saying that specifically York any real connectivity, any work for real activities just against the rules rules set that we recommend as a deproton to the Ethereum community. And I personally think right now at this that seems to be very much in line with what the community generally, and also once it's need to check that the properties they want to do on time, of course, that I'm a changed friendly way in the future that we see about that. But I think we also still need to set sensible defaults. And I think having a zero tolerance policy on real behaviour is the right thing to do. And I would also just briefly say there because it's such a dangerous tool, so sort of stashing, and being kind of the threat of it. I personally would not want it. I would like you to be limited to this case. So you know, if it's your block if you want to censor, I said, it's still. Maybe you should strongly discourage this right on all the other avenues that we have written, and we're on, and every weapon I don't think the threat of social should be on the table for that specific kind of misbehaviour. Really just the real, because as long as we don't have this reog style attack the network as a whole will still include the transactions of everyone. So I think that's important. a It's a it,

Łukasz Rozmej 1:02:19: so the things from me. so one of the things from Tomasz, for example, of mining in some places I would expect that the regulation that would come from the west would be more sophisticated and more in the boiling the frog strategy. So they would go each. Each next regulation won't be enough to justify. Then l leaving that jurisdiction, but they would uh compound more and more. So that's the there is. I see that's how I see the governments operate in general in those terms, And the second thing again I would say, the problem for me is that we are getting the whole blocks from mev Boost. I would rather prefer getting the transactions. Ah, for the and similar proposal, the builder operation. Okay, this is maybe a little bit better. But I would again rather get a list of transactions, and then each note doing something with it. But okay, this doesn't really solve the real part where they have the majority. So I don't have the solution. But I think that there should be something built into the protocol that could allow us to detect this behaviour, and then slash it, and then it's fine. But I wouldn't like to do it manually because of. We believe that this particular case is that so? It's like I don't. I don't like this solution. Those three things for me.

Tim Beiko 1:03:52: Anyone has More thoughts, comments?

Victor Zhou 1:03:59: Can I propose some local level of counter-censorship algorithm.Yeah, one of the parts you have a subset of our transactions, and then being proposed as a fake block, and if it turns out that some of the validators,the slash is denying the validity of the transaction. In this way you can detect whether it's because of some address that they're interacting with or not. Then it can be found into the purple layer as an algorithm to slash them that's one of the idea I have.

Tim Beiko 1:04:47: So Yeah, I think you know, for any new designs or whatnot, this is probably just not the best forum to like. Exploring them like these things have a ton of implications and implementation concerns. So Yeah, I am and not not to say like that. This is not worth exploring. But I just think it's probably better to like. Write this proposal down, and have people chime in on it rather than trying to come up with a new design on the fly here. The topic. Yeah, Vitalik

Vitalik 1:05:26: Yeah, I should mention that I've written about this topic of what I call censorship directors orwill check I made a couple of good research books on this. The basic idea would be that clients would run software that automatically detects when censorship may be happening, and what so? By which you specifically mean, like what the orcs may be happening, and you can't give like you can't guarantee it one hundred percent ingredients, because one hundred percent agreements would like and wise consensus which in which you, by definition or like, we know, we can't deal with. I'm more than fifty percent dishonest.

But the idea would be that, like clients, they would have a kind of either. Things would show, you know, either things look fine or things don't look fine, and I mean, like maybe the user. Should do something. And then, you know, you're gonna have a social norm that if the client says things work fine, then like the users wouldn't definitely should not do something in any other case.

Tim Beiko 1:06:30: Thanks, I guess. Yeah, just because I want to avoid us also going in circles on this topic like bringing it back to your original kind of? Asked Micah, which was around like. You know, camp clients commit that we would punish the sort of not protocol, the sort of delicious behaviour that's not visible within the protocol, but that's clearly attributable when observing it. you know it seems at least some There's some amount of disagreement at the very least level at which that would be. Yeah, that would be necessary. And also What's the best way to make that commitment? So yeah, I'm not super convinced. We can get like a very keen answer out of this on this call. Marius:

MariusVanDerWijden 1:07:39: Yeah. So I think it's very important for each and everyone to form their own opinion and say, Okay, this is what I want ethereum to be like. And so my personal opinion is if we allow censorship of user transactions on the network, we basically failed. And this is what I'm willing to die on. And if we start allowing users to be censored on ethereum. Then this whole thing doesn't make sense, and I will be leaving the I myself, will be leaving the ecosystem, and maybe start something different that provides these guarantees. And I think there are a lot of people that think the same thing, and I think censorship. Resistance is the highest goal of ethereum and blockchain space in general. So if we compromise on that, there's not much else to do in my opinion. That it

Łukasz Rozmej 1:09:10: Just one comment for that. I agree with Marius. I just want There's so sensor resistance from the All core resistance.

Tim Beiko 1:09:18: What did you mean? Sorry about that.

Łukasz Rozmej 1:09:22: Yeah, No. So it's a resistance from us, like, if right. So it's not being able to alter the transaction.Yeah, or the state.

Tim Beiko 1:09:27: Okay, I see. So you could do, Martin. And then Vitalik.

Martin Holst Swende 1:09:37: I just also wanted to echo that I agree with Marius, and I think it's a lot more feasible to get individuals to state their preference, or what do I call it? The Official opinion is this. what we have our personal views. And I agree with Marius

Micah Zoltu 1:10:02: And to be clear that that was all I was asking for here. I definitely don't expect, like all core devs, to make some formal statement, or the guesting, to make a formal statement, but I just wanted to say that I think there is significant value in making sure that the community knows where the court deps individually stands. If they see ninety percent of the court downs will walk away if censorship occurs and they can't stop it. Then that tells the community that if you want to fork off and do that, you can. But you're going to lose all your money again. It doesn't have an official statement. I think just a lot of the community doesn't understand that many of us build this for censorship resistance. Specifically, I think a lot of them think we're building it because we want, you know, on these schemes or whatever. And I think just getting that word out there that you know the people who are building this the thing they're trying to build is this? And if you go and try to subvert that, and you're successful, then we're either going to you know. Take your money, or we're going to walk away.

Tim Beiko 1:11:00: And just for clarity. I assume, Micah, your personal opinion is that you would not endorse the censorship at the protocol level, an evil super villain, and burn the world down. But yeah, I think I do also part of the reasons why I think this conversation is hard. It's like all I go with. Martin said that having the official thickness doesn't work for many reasons, because we have a very fluid governance process, because the get team today might not be the guest team. Five years from now, when we actually have to resolve those issues in one hundred and one.So yeah, I do think, like an individual, staying in your preferences is the best you can help. I'm happy for other people who want to do that here to do it. But I also don't want to feel like people are forced to do this. I very much recognize it as like doing it on a live recorded call. Like not the way. If many people want to share their like opinions about contentious topics, if anyone else has comments or they can share like, Yeah, we can definitely do it here. But somebody not sharing here should be seen as like some like support, or like disapproval or like their position on this. Arnetheduck

Arnetheduck 1:12:44: So I think One one thing to remember as well is that there are many theoretical problems in the Ethereum that aren't being addressed because they aren't the biggest problem right now. But I think we can rest assured that should this start happening on the systemic level, it would also be created much more seriously, I mean for the governance and the open source process that we have, we tend to scratch the hitch that a noise us the most, and this could quickly become one.

Tim Beiko 1:13:27: Yeah, I would tend to agree there and also change the problems that end up showing up like for real tend to be a bit different than like the imagined model that you have of a problem. And so, you want to make sure you're not like overfitting some particular imaginary case early on, and you can be open to deal with whatever the issue, whatever the attraction he is. Once it shows up, anyone else has thoughts, comments they want to share before we wrap this up. Okay? Well, yeah, thanks a lot. Everyone, I really appreciate the kind of discussion we've been able to have, and that everyone is very respectful and level headed. last, I guess. Announcement: Ah! Before we head out I will not be running the next of these calls, not because of today, but I had a planned trip for a long time. Danny will be running the next of these calls, and I'll see your two calls from now. He and Mikhail has his hand up before we head out.

Mikhail Kalinin 1:14:46: Yes, a small announcement on the eip 3675 and 4399. They have been moved recently to the last call within the two weeks of the periods, where you make any last call, if you've only had one have it.

Tim Beiko 1:15:04: Nice This is a great note to end on. Yeah, thanks again, Everyone and yeah, see you the next one of these.

Attendees

• Tim Beiko (host)
• Gary Schute
• Enrico
• Tomasz Stańczak
• Andrian
• Oxcasey
• Leo Arias
• Zuerlein
• Potus
• Terence
• Kenway Wang
• Roberto
• Mario Havel
• Paul Hauner
• Vitalik
• Ruben
• Mario Vega
• Kamil Chodola
• Trenton Van Epps
• Afr Schoe
• Alex B.
• Alex Stokes
• Pari
• Tukasz Rozmej
• Andrew Ashikhmin
• Ben Edgington
• Daniel Lerhner
• Danny
• Micah Zoltu
• Marius VanDerWijden
• Pooja Ranjan
• Marek Moraczynski
• Rai
• Greg Colvin
• Lightclient
• Justin Florentine
• Danno Ferrin
• Marcin Sobczak
• Mikhail Kalinin
• Karim T.
• Martin Holst Swende
• Fabio de Fabio
• Pawel Bylica
• Sam Wilson
• Jamie Lokier
• Dankrad Feist