All Core Devs - Execution #145

Transcript

[Music] [Music] so [Music]

so [Music] [Music] [Music]

[Applause] [Music] [Music] so

[Music] [Music] so [Music] [Music]

[Music] [Music] [Music] [Music]

okay so

Micah Zoltu: uh hello everyone welcome to awkwardevs145 um just posted the agenda in the chat um basically mostly merge uh related uh related stuff today um um yeah we yeah and then uh some around uh mev boost and and the implications there i guess to start off um the sepolia post merge upgrade was supposed to happen um

yesterday but because we've had like a lower uh lower amount of active validators on the network it still hasn't hit um so when i checked yesterday uh the eta was about august 21st which is in like three days so if you run a sapoliano you haven't upgraded yet um now is the time to do so um anyone else have any thoughts on this comments okay so um next up uh we had a mainnet shadow fork uh today

um [Music] perry or marius do you either if you want to give a quick update hey yeah i can give an update um so we had minute shadow fork 11 um happen about an hour ago uh out of i think 99.8 participation before we're at like 96 and a half 97 so that means out of like 35 nodes 34 made it through um the one node that didn't make it through just hadn't finished syncing so in terms of like making it through the transition i think this is the nicest shadow fork we've seen so far um we did notice some invalid blocks being

produced by ericon we think it's going to be the same issue that we noticed on gurley so potentially also the same fix we'll look into it and check that out and i think the netherlands nethermine team noticed something with uh nimbus but that was already an old issue and had been i think it's already in their plan to be fixed uh that's about it congrats everyone

Tim Beiko: yeah that's very good um i don't know if anyone from nether mind or aragon wants to chime in more

so go ahead okay so it is a never-ending

Marek Moraczyński: story with

uh block production and giving enough time for uh block production for el but the fix from nimbus team is already in pr but yeah i think we also notice it for lolstar but maybe that lion could say something more about it

dapplion: sorry i have not been personally following

this issue okay

um and then on the arrogant side any thoughts comments um i'm

Andrew Ashikhmin: on holiday this week so i haven't looked into it but i saw that parenthood posted this this question in our chat so maybe julia from our team will take a look but also parenters could you maybe post an example of an invited blog like more if you give us more details then we can uh we can investigate what's what's happening sure i can follow the information thank you

sweet

Tim Beiko: um anything else on the mainnet shadow fork okay um next up uh so basically we set uh the ttd uh on the cl call last week um kind of optimistically assuming the hash rate uh trends would stay stable um and the five gig dag increase would uh would not like massively change hash rate um so we basically

we're basically right below five gigs now i believe we're like at five gigs dag if you include the hash of the uh the block you're mining um we saw a tiny drop in hashrate but there's a lot of noise in those numbers so it's it's quite hard to tell um and previously we had seen a rise over the past week um so it seems like we're still trending nicely um i'm curious to hear from client teams like if anyone feels like we should change the ttd value but uh from like a high level look it seems like uh it's probably it's probably good to just keep that one anyone

Micah Zoltu: what will be

what's the what's the estimated merge date and time if hash rate stays exactly where it's at right now

Tim Beiko: september 15th

Micah Zoltu: even with the increase that we saw

Tim Beiko: yeah it's like back to where it was like a couple days ago

um yeah and maybe yeah bordeaux was showing about 1 30 a.m utc at the beginning was showing about 4 00 a.m a little bit

Tim Beiko: yeah and like you can see like you know i just shared my screen but like there's a bunch of variations so we went this high like above one 950 and as low as you know under seven seven five so like yeah there will continue to be noise um

but i think we're yeah i think we're trending nicely and um and i also saw that like a bunch of clients have started to like merge pr's with this so um given there's no like massive deviation it's probably easiest to keep that time okay so no disagreement so um i guess in that case we can go ahead with this ttd i think uh client teams can can um can put out releases with this ideally today or tomorrow so we can announce them very early next week

um and yeah those will be the the releases for mainnet um and like we discussed on the last call if el teams want to then upgrade those like as we approach bellatrix or right after bellatrix we can we can advertise uh newer releases because it is kind of a long uh a long stretch before we had made enough um but yeah uh this this is the number and there's a couple there's a couple questions in the chat about like what if there was like a huge hash rate drop uh because of minor selling and whatnot i think you know if we see some massive deviation after bellatrix has happened we could always do a ttd override if needed ideally not um but yeah i think we can we can go forward

with this have high confidence we're not gonna hit it before bellatrix and pretty good confidence that like we'll hit it around the 15th any other thoughts comments

Micah Zoltu: blog post is going out on tuesday is that correct

Tim Beiko: yes um so tuesday august 23rd uh morning pacific you can expect the blog post and a couple clients said that they're gonna put out releases on monday the 22nd so um you can if you want to see your uh if you follow your specific client you'll probably get the release before but on tuesday we'll have all the

release combined in a single blog post um any other comments thoughts on this okay well yeah we got it uh my net releases that's pretty excited um okay there are two other things on the agenda

um kill first

Tim Beiko: okay yeah kiln might be easier to uh wrap up quickly um yeah perry you were talking about

potentially deprecating kiln um earlier than expected um you want to share a bit more on that yeah so we were just looking at the kiln network over the last week and we don't really see that many transactions on there and it feels like since we have merged the two long-standing test nets as well as a third test net there's no real reason to keep killing around 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 deprecating karen but that was after the main net merge i'm proposing that we deprecated a bit

earlier right so yeah the the plan i think was to deprecate it like basically around the main merge like which is now a month from now would you do like even quicker than that or is like can we say we just shut it off the day main net merges is that good enough for you i'm 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 unupdated and it's costing time and money there's no real reason for it to be around

Micah Zoltu: the transactions you see on it do we have any idea what they are

uh no but i'm assuming that just some bots that's doing basic value transaction in the hope of some nft

Tim Beiko: there were some people who did promise some

killed nfts um yeah

Micah Zoltu: so we as far as we know we don't we don't believe there's any apps that are like using killness or testnet or anything that's correct don't think so and i think most if not all have already moved testing to gurley or robston or other places uh the only other reason to have kept karen around was that it was faster sync but support is arguably just as fast

Tim Beiko: so i guess just to give people some

amount of heads up could we deprecate it when bellatrix hits on like september 6th 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 post 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 basically i think replicating in bellatrix is okay i think we should just um 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 okay i like that and i think though and then the worst case we extended another two weeks beyond that which is what we'd originally

advertised but yeah um yeah we can we can make sure to mention it in the merge blog post okay anything else on that nope that's it thanks okay thanks um okay so next up uh we had a pretty meaty topic so i guess two topics um uh micah put up um so first uh basically the uh challenges with nav boost and relay censorship and then kind of at a higher level um how proof of stake

and just ethereum generally can address censorship on the network um i think like as per the discord and twitter this week like people have very strong opinions about this um i think uh it's also a subject where people have different levels of like degrees to which they're comfortable voicing their opinions uh for a bunch of reasons um so we can try and have this conversation on the call uh just ask that people kind of be respectful and charitable and um mindful that like not everyone wants to voice their opinion about like these complex topics on a live recorded

synchronous call um yeah um so you can try our best um and i think also it's very much worth separating out the specific concerns around mev boost and like the whole kind of architecture there from the broader higher level concerns of just like censorship resistance um just to make sure that like we can actually ground the like mev boost conversation and like the software and like markets that exist today um yeah so with that said um micah do you want to kind of give a quick overview of the the

situation with regards to muv boost and like the problems as you see them

sure i

Micah Zoltu: i'm actually surprised we have so much time i thought for sure you were gonna find a way to pack the agenda to avoid this topic uh but apparently no one else showed up um so the i just to preface i do agree with uh tim we try to keep this conversation focused on the technical stuff as much as possible um i know this conversation may bleed over into more philosophical philosophical stuff but we should really try to avoid that um so the the tldr for anyone that's been living under iraq uh the us government recently sanctioned one of the contracts on ethereum so allegedly depending on how i interpret that u.s citizens are not allowed to interact

with those contracts um and then some people are interpreting this in different ways some people believe that means that if you are a um relay you're not allowed to relay transactions i i would assume that some people also believe this means you can't gossip such transactions um there are some people believe that you can't interact with any address who has interacted with those sanctioned addresses um 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 board um for the sake of this group and this discussion i think the one that impacts us the most is the decision of um flashbots to sensor transactions that are coming into

the flashbots relay i think they actually do it on their builder side i don't know exactly i don't remember the exact technical spot where they do the blacklisting but the functional effect is is that if you send a sensor transaction to flashlight relay or if it sees one in the mempool or you send a bundle to them that has it they will just ignore that bundle or that block or that transaction and they won't mind it um the problem of course is that if we kind of i'm going to be a little vague here but if we 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 merge like as soon as the merge lands we've got censorship happening as soon as we hit the ground

now there are some caveats here um one of course finders can or valios can choose from whatever software they want we can't stop them and there is no way for us to functionally stop people from censoring um two there are flashbacks isn't the only relay builder there's also blocks throughout blocks route has um two relays that will not be asserted will not be censoring 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 uh getting into the philosophy that'd be great but i don't know if that's gonna be possible um is do we want to launch go into the merge with me boost and all the associate software and connections and you know tutorials and documentation etc when we know that that the centralized entities that are going to be in control of this are providing censorship software to their users um i don't think there's an easy answer to this i mean i have pretty strong opinions but even that even i recognize this is a complex situation and there's not an easy and obvious answer um especially with blockser out who is so flashbots is a little more clear-cut like they're just they're only offering censorship that's the only option um blockchain is a little different because

they are offering the user to choose um the caveat there is that we'd be pointing users say hey go check out blocks route and then they go to blocks route and watch out i was telling them hey this is how you undermine the censorship resistance of ethereum by running this thing or if you don't want to undermine a theory on this thing and so there's i can definitely see you know some people may feel differently on either side um the other caveat i'll say before we start discussing is that um i recognize that this is the well this is an all core devs call what i recognize is mostly execution layer devs and we've kind of handed the keys of the kingdom so to speak over to the consensus layer so the kinslayer is in a better position to actually do something here than i think the execution player

is um the reason i wanted to bring it up is just because the merge is so close i think there's value in getting the discussion going and because uh we do have some consistent clients on this call and so it's a good opportunity just to discuss and and talk about it i think that covers most of the situation the one thing that i do want to remind anyone who's listening um no clients currently or have any plans of hard coding any specific relay into their client the clients are only building a client that has a and like a configuration parameter you can fill out or you can provide a relay and then that relay can do whatever it wants and so just to be clear no one is no one on the ethereum core devs is hard

coding censorship in or anything like that we're just discussing should we kind of support and encourage and these people who are adding building censorship tools so that's it for now we can start discussion

thanks

Tim Beiko: yeah that was a really good overview um then crowd i think you've had your hand up first and then vitalik

um yeah i think like first one small comments like the sanctions are nothing new right like we had functioned addresses before so like i think like um this is like an important mark because i think like uh trashbots might

Dankrad Feist: actually be doing something stupid including themselves in

the food by doing this i can understand their their behavior but uh it might not be that they don't have to do anything at all because miners have gotten away with so far including selection transactions and nothing has happened um but ignoring that like i would generally agree with you that we shouldn't be going into the merge if there's only um a standard option available like i think that would be a terrible signal and uh that like that would definitely be a huge problem um but i think like uh thanks to like uh mav booth sorry flashbot now open sourcing their relay and

uh yeah being alternative very likely from the start um i mean that's definitely something we should ensure uh like i actually don't think that this is going to be a problem so i'm actually in a way uh this whole situation could have could have the effect of actually saving us of the huge problem that was very likely to happen before that we will only have a single 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 uh relays so i i think like uh currently i i think um i i i don't i don't think that we will see the

situation that uh that you fear that actually there will only be dashboards and they will be censoring it uh so so like there will be censorship

Vitalik Buterin: uh yeah uh so i just wanted to kind of give a brief uh purely technical uh comments on the yeah just a different kinds of like censorship that might happen right so i think the like one big nuance that it's important for people to understand is the difference between um choose like choosing not to include transactions in blocks you create uh versus softworking right so softworking

basically means that like if there is a chain that contains transactions that you want to exclude then you do not create blocks on the chain you also do not attest to the chain and you even attach to a complete uh computing chain so you attach to the biggest chain that does not contain the transaction that you want to exclude so soft working censorship is uh not something that is uh being facilitated by any software that's being developed that i'm aware of today um but it is something that in order to kind of break the um ethereum transaction guarantees only 51 of alligators would need to participate right so it's a yeah like

it so that would be the more the more extreme scenario um but it's one that like both require like it it only requires a majority but on the other hand it's much further away from happening in terms of just like what dorms are being considered and what software is being built the other type of uh censorship is just basically the validators as proposers exercising their ability to put whatever contents they want into their own block right and like i think we've even had this discussions about that in the past in the context of like some uh validators choosing to just make completely empty blocks that contain nothing at all right but

this kind of uh censorship is uh like more closer to uh realistically happening um but it doesn't have a yeah like a 51 requirement it has a 100 requirement right so if let's say even 80 of uh run a 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 you get a block created by yes by someone who does not right uh so um and if that percentage goes up to 95 percent uh then instead of waiting five blocks on average you'll have to wait

wait 20 bucks right so the uh like basically all that's needed to like really avoid significantly degrading ethereums i guarantee this is basically for if what is a relatively small percentage of alligators to adjust that the running non-censoring software which is uh something that like if uh like it seemed if needed would could even could even rely on some portion of alligators do we get altruistically right and then like there are also middle grounds like oh maybe if you don't even want to attest to censoring watch then you know you just kind of

stay silent on that on that epoch entirely but then i think those are not real not very realistic right because uh once you start making distinctions like that then like once you say oh like i'm not going to attest up to a center and chain but i'm just going to stay completely silent then you basically stop validating him and you might as well like this so that's like basically the kind of the different scenarios that i see and i think it's like it is important for us to just talk about them separately because they have there's a different threat model there's a difference kind of upper bound to the harm that they can cause with these different responses that they require

Micah Zoltu: a quick uh follow-up on that isn't the threshold required for a

censorious soft fork to occur significantly below 50 due to proposer boost

Vitalik Buterin: good question i uh i thought it was yeah i actually i don't yeah 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 like subtleties around like 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 or are we talking about like ahm or a more realistic network but yeah it is like somewhere a bit somewhere between like 20 and uh 50 uh depending on i guess uh specific

assumptions that you use and like the no that number will probably increase maybe closer to 50 over time that's something if it's the birthday come on

Tim Beiko: thanks yeah that's that's a really useful distinction um i see yeah victor you have your hand up uh there's yeah do you want to just quickly share your thoughts but i think yeah do you want to maybe just like quickly introduce yourself and share your thoughts

Zainan Victor Zhou: hi uh so uh my name is victor and i work mostly on uh erc side as a eip uh erp author and i also help out editoring i feel like this problem is solved at a protocol level would leave people no

choice to they have to either leave ethereum or they have to stay at epm but uh like accept the censorship altogether so my take and my position would be solve it at the application layer and so countries or sovereignty if they can declare that they want something to be under their jurisdiction and then you have to register to stop contract and then they can also say that it's a war garden you either follow their jurisdiction or not and then everything else just fall as if it's in the real world right now um so that would be my take so i yeah i simplify i object to uh solve it in a protocol level and i think it can be solved in application layer thanks and then you see i see you shared

an eip in the chat uh people can definitely like comment there um i do think it's valuable to keep most of the conversation here focus on like basically the around the protocol level because that's the the folks we have uh on the call

um but yeah people who want to there's definitely a lot that can be done at

Tim Beiko: on top of the protocol and um yeah i appreciate you sharing the links uh there thank you of course yeah uh manny you have your hand up

yeah

Mamy Ratsimbazafy: uh well i'll skip my uh philosophical position uh i've replied evolves uh in the thread by mika but

um i want to talk about the incentives so like three days ago we had no iss we had no alternatives to [Music] a relay besides flashbot and many staking pool committed to their users that they will maximize their revenue and so will run any mev software which put us in a delicate position but now that we have alternatives what will likely happen is that we will have a choice between running censoring transaction and and some sort transactions with likelies and sensors be in uh giving most rewards because there are just more transactions to um mev

and lastly the other thing is that any sensoring software could be exploited by uh just like the dusting that was done with a 0.1 if that were distributed to many addresses you can include um any sensors address and just send them 0.01 if and then your transactions cannot be sandwiched attacked by flashbacks so if we have any open relay i think the sensoring will fall flat on

it on its face

Tim Beiko: thanks um anyone else

lucas

Danny Ryan: i wanted to make a quick

technical argument just in terms of the um there was an argument to remove i know the argument is less strong given realize but there's an argument to remove mvv boost from consistently 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 etcetera sorry to remove the builder api hemip boost is a separate piece of software i i misspoke uh let's remove the builder api uh which would probably result in many forks of software um which is something that i think everyone here does not want to see um

as it just introduces potential errors down the line so i think avoiding that world is is also kind of healthy from consensus standpoint

Tim Beiko: yeah and just to touch on that because i think from skimming the discord and twitter and whatnot there's like a couple degrees of separation in the software right there's like the consensus slayer client which exposes a builder api mev boost is software developed by flash bots which interacts with this builder ipi to provide basically blocks through it to the consensus client and then there's many relays you can integrate with uh

or there's many relays you can be launched to integrate with this uh with this builder api so it's it's it's yeah there is like a decoupling there um that's worth like highlighting um lucas you have your hand up

oh

Łukasz Rozmej: i just want to point out that the current implementation of mev that is running on main network now is a lot less prone to censorship because while the nodes that are building the blocks will get bundles that are censored they still pick transactions from the mempool to fill the block out so it's like you cannot probably censor it

completely and i don't really like that design that the whole block comes from third party and you cannot add anything to it it's like the root cause of this problem to some extent

Tim Beiko: right does anyone from flashbacks actually want to

chime in on that

Stephane Gosselin: yeah i can speak a bit uh about the the technical sort of design goals of um of mev boost so um it is sort of software that helps validators outsource

block construction um in particular sort of the difference that it has from the way that um mavgeth works is it enables client diversity and it also allows solo stakers to participate um and outsourcing their block without sort of introducing um a trust sector so um you know that's the reason for having full block proposals or full block submissions as opposed to partial block submissions um i think there's some good proposals floating around to be able to augment sort of full block proposals and return them to some partial block

constructions which allows validators to append those transactions to the end of an outsourced block so you know the goal with introducing those modifications is provide more granularity to the transaction types that are proposed so it's not exclusively a full block

outsourcing thanks uh mika you have your hand up

Micah Zoltu: uh yeah the i think for me the thing that i would like to see the most especially now that we have a couple different uh relays and the uh flashbacks relay is open source people can run their own i'm less worried when

than when i originally posted this i think the thing i would like to see ideally from core devs is just social pressure and um lobbying to users to don't run relays at sensor i think the the core does have a lot of influence and a lot of power i think a lot more than they realize they do and so just you know on twitter on reddit on wherever you go hang out um you know just if someone asks you you know should i run mev tell them yes if there's a non-sensory relay and tell them no if there's not and encourage them strongly to go use non-century ones and this is especially true for anyone who's working with these big companies like coinbase or lido 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 you know try to run things that are non-sensorious when you're recommending things to people recommend things that don't censor transactions stuff like that um i think that alone combined with the fact that hopefully we'll have multiple relays should be enough um to protect us at least until we can get pbs and something more

solid in uh marius yeah i'm i'm

Marius van der Wijden: i'm always trying to convince people to run their stock gath their stock nether mind or like the the stock configuration of the client um that would give you enough transaction fees and um you don't need to extract mav

i think if you are benevolent user of the network then it's fine to take a one percent or two percent cut a year um to uh 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: right yeah it is worth noting like mev boost is not like something that's included by default when you set up your node it's like an addition that you need to run um and it's it's not required for node operators um uh ahmad can you introduce yourself and

yeah share your comments yeah hi uh it's ahmed from nethermine team uh i just have a question if someone from rocketpool is here like is pool planning to keep running mav boost if it kept censoring or not i think

Danny Ryan: we can really get into what particular operators are going to do here

yeah i think i i would rather like push that to mev boost his forums and like other operators forums um yeah we don't usually have those folks attend first and like second i don't want to set the precedence that we solve

all the community level issues on this 90-minute call every two weeks um but yeah uh i'm sure they have a discord or like parents

Terence Tsao: yeah um i just want to add on top like um stephanie would definitely should encourage user using the non-sensory um option but it's also important to um recommend user because by using macbooks or using the relay network to also spot construction it's also not risk free in terms of like get in terms of like getting your blog um as uh safely out as possible because from our preliminary

benchmark right we're seeing um it's actually adding like two to three times more latency so that means there's higher chance of your blog to get like reorder right so we also need to educate that part also like optimize that part as well

Danny Ryan: yeah i mean 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 like you're definitely there's risk that that blocks not gonna make it or communication is gonna fail or you know it's just another piece of

software that's in this in this mix so you know even if you are going to do this think about it ramp up over time maybe

thanks

Tim Beiko: yeah and um just to make sure like we have time to move on as well and um don't kind of run around in circles too much um enzgar we could can definitely get to you uh but quickly like micah your ass was like you know can client teams like advertise you know the to users that they should run other things then you know mev boost would uh yeah with some potential censoring relays i it seems like some client teams do that already to different degrees for different reasons um

and also that obviously mbv boost is not shipped like by default with uh the clients um so i feel like we've mostly addressed that um enzgar yeah 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: yeah which i think is good because i just wanted to briefly reiterate uh for people listening to this like on youtube and and whatnot just because a lot of this was relatively technical and easy to kind of misunderstand so just to to be perfectly explicit like uh after the merge we will still be in a situation where the network will not be censored so like if you're in north korea or something or want to use ethereum or you're in iran or like i

don't know sorry this may be extreme examples but like the network will not uh censor you uh right like we as long as some proposals don't run some like censorship software uh the network as a whole is not sensing it's all this just us being proactive about making sure this remains true for long uh our future so um even though there were a lot of many concern voices on here right now and after the merge then it will not be sensor so just just to refrigerate that

Tim Beiko: thanks yeah

Micah Zoltu: good segue into uh the other half of this topic also on topic censorship show a

very brief background for those listening the all one of the major advantages proof of stake provides us over proof of work is the ability to punish bad actors after the fact via human coordination and so this this ability of us to see that hey someone is something wrong the protocol was unable to handle it but everybody knows that they did something wrong they cheated whatever we can their stake is locked up for quite a while and so we can then do something we can do what's called the user activate software or user activate hard fork 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 developmental proof of stake there have been a number of 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 of stake and unders i understand this is part of the design my concern is 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 proof of stake like this is the its really strong point is this ability for the community to fork someone i think that one of the things in order to make this make this work so like if everybody knows that i will be if you

know you will be punished severely if you do bad thing x then you're less likely to do bad thing than x and if that punishment is strong enough and the benefits you gain from doing bad thing that x are low enough you may nev no one may ever do bad thing x and so our hope is is that if everybody knows that this threat is there and the 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 and 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 core dev community um and this is going to be executioner and consensus they are both consent later again we

kind of hand 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 is some cartel that is reorganized blocks that contain certain transactions that we will write the code for and release software that slashes or penalizes or you know takes away a stake or does something like re-orders out those those takers whatever we do we'll do something to push back on that now of course we cannot force people to run software and everybody will have their choice 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 not censoring train and they will take like put forth effort to write the code that is necessary to do that one of the things we can do to be more even more proactive about this besides just you know making a statement um we could in theory uh write the code in advance so that we're ready to do that and all we have to do should this time come is basically fill in the list of addresses and we're done um and that would be a very very strong credible threat whereas 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 core devs being more

vocal to the broader community and letting them know hey you know if someone starts reorganizing if a cartel starts reordering blocks and censoring 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 um 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: thanks um yeah already some hands up so lucas

Łukasz Rozmej: uh yeah but not now we are treading ground that we are the sensors right and it's like uh give some moral implications right if we

should have to do it okay it's something different but it's something built into protocol and something different when we are doing something on the whim and then on our like beliefs or even even if it's like community agreed then it still can be corrupted easier

oh that's exactly sure yeah i think i'll hand over dan score in a second because i suspect his response because his vedas said so many times is going to answer this but the 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'll do it um i'm assuming that so you're going to say ask her so i'll let you

know take it yeah i i

Ansgar Dietrichs: i basically just wanted my other this um i i generally agree with micah i think um threatening manual uh intervention when you know social slashing however people call this is a really dangerous tool so i think we have to be very careful with um committing on doing something like this uh it has to be very explicit under which circumstances so that there's no kind of arbitrary uh no no no no feelings of punishment and i think kind of the the outline michael gabe was exactly right it's basically as i was saying earlier like as long as that only some subset of of proposes everyone can include transactions like

still transactions in their own blocks and what you're not allowed to do is through other people and so in general um i think the framework to use this is that like we have all these misbehaviors that we can catch automatically in software and we already selected for that today there's one just category of misbehavior we unfortunately cannot detect automatically and that is just not following the fog choice right we have very specific focus 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 attest to that head if you willfully deviate from these rules and that could also be just for personal profit so therefore example these time-handed um

attacks and this is basically there are a bunch of attacks where you just basically you willfully uh fork out blocks before you and censorship's just one subset of this and all of these attacks we would like to automatically be essentially for that the only issue is that it just cannot detect this automatically because it's undistinguishable on an individual basis from just latency in the network so we can only take this on a statistical level so like once you do this multiple times or like your big pool or something then we can detect it and so unfortunately that's requires to manually go in and slash tube but it is just an extension of the over rules and so like this is a very i think it's not really slippery slope argument here it's like a very distinct taste and i think it would be very valuable if

we could basically just pre-announced um that this is what we were doing i think in terms of in implementation by the way i would prefer that either time withdrawals alive we have at least implementations ready to to have a hard manual hardware to freeze with all so if ever anything went wrong i think it would be really good if we could have within a few weeks just have a small fork that just freezes withdrawals until we can go in and because otherwise people could just withdraw on time right so basically i think having an implementation that like that ready to go just in case we ever need it i think would go a long way in terms of deterrence um but yeah i think that that's all and again like the point is just it is a very specific category and so there's no slippery slopey it's just one thing we

just don't allow you to do

us

Tim Beiko: um i saw dan crowd you had your hand up but you put it down i don't know if your comment was just addressed

Dankrad Feist: i i think and sky has already put it very well

here thank you any thoughts on this

Danny Ryan: it's a technical note on um withdrawals so there's an exit queue this exit queue can take quite a long time if a lot of capital is attempting to exit so i don't you know in the event that like you do something slashable and you're not caught yet or if one of these more social maneuvers like it's very

it's actually hard to get a lot of capital out of the system quickly so i don't think like a halting withdrawals is necessary actually because of the execute just in most scenarios

Micah Zoltu: what is the time frame to let's say let's say i think for most of the attacking about 33 at least to do something meaningful what is the time frame to exit a significant portion of that

Vitalik Buterin: i think at this point we're at

the executive maximum so it would probably or grab me you know like points at which it stops but never thought you'd be single should be out like a few months okay

Tim Beiko: yeah it's like three or four months to get a

third of the capital out or something

okay

Micah Zoltu: i'd be curious i noticed a couple people in chat were sounded like they were maybe against this uh general theme i don't know if you guys want to speak out thomas and martin maybe you're making joke i'm not sure

Tomasz Stańczak: sorry micah can you repeat

i think he was asking i just it sounded

Micah Zoltu: it sounded like a couple people in chat were opposed to this kind of social slashing sort of thing

um and

Tomasz Stańczak: i was wondering oh yeah i mean that's butch was expressing a similar uh

similar feeling that i think that the protocol level solutions should be very strong and you have the social consensus still as they um as the final process to say okay rejecting what's happening reject the attacks and and that's what vitalik was describing uh on twitter as well and that's what i mean like i i want to have some kind of social not consensus like a lost uh last resort action but let's start to say okay this is what we do and we we start to promote some behaviors i think we should be able to do that properly through the protocol through the

um for the encryption of transactions through looking at the map boost uh infrastructure and understanding like how we can promote the decentralization relays how we can follow the examples that we see already here just like opening source more players coming to the market and so far the chain was reacting to the events like this by bringing the 80 players that say oh this is 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 in the last three four days saying we'll run non-censoring relays we'll propose the alternatives it means that so far

things are working um i was a bit more worried about the questions of the large validator operators censoring or not but they will also be looking at like okay like so so if the community expects this then the operators will appear that will say that they play other rules and it should all play fair if the community is still all the community is totally fine with it then there'll be nobody offering the non-censoring relays and then if you start be vocal about it and fight against it then suddenly you buff against the community and i guess the prodigal participants and then it means that you are fighting your battle for

some reasons whether i believe this is a valid approach or not but but then you actually censoring outside the protocol so yeah

Micah Zoltu: just for a little bit of clarity um i i didn't mean for this to be related to the uh maybe relay thing i think the the relays well the relays do have the ability to kind of help facilitate coordination of this type censorship i was more concerned with the large validator pools 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 defense against that because those people may not have a choice to to attack the network like they may be wrench attacks so to speak um to attack network and i think we need a way to make sure that we're resilient against that class of

attack

Tomasz Stańczak: so what we've seen in the past we had the entire huge oh sorry oscar was before me yeah was the entire entire category of players proof of approval work players the miners moving to other countries because they were bound in china right so i think the same thing may happen here and there is enough of the push for for moving somewhere else then they realize

the validator operators will appear in other countries um in the end the network will be representing its community like will they will you expect that the community will be are located in the western countries and operated in the western countries uh if so then it means that actually that community want to follow this rules if it's a proper global network then you'll see representation of all those needs from different regions

Ansgar Dietrichs: right i just referred to say in terms of how i see the kind of the interplay between say the social layer the community and and whatevs is that of course at the end

of the day i think is this layer 0 for ethereum is the community and if there is some disagreement about rules then the community has to choose ultimately i think our role is basically just to set some defaults and basically recommend the way and um and of course you know people have it really violently disagree they can't walk off um or you know take 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 um specifically reorg um any real activity uh any wealth for real activities just against the rules rule set that and we recommend as a default to the ethereum

community um and i personally think right now at least that seems to be very much in line with what the community generally um also wants ethereum that the property it wants to hear on track of course that ever changes radically in the future then we have to see about that but i think again our role should still be to set sensible defaults and i think uh having like a zero tolerance policy on on on on real behavior uh is the right path to go and i will also just briefly say that that because it's such a dangerous tool sort of slashing and the kind of the threat of it i personally would not want it i would want it to be limited to this case so any you know if it's your block and you want censor i still think we should strongly discourage this right on

all the other um avenues that we have on twitter and whatnot and everywhere but i don't think the threat of social slashing should be on the table for that specific type of misbehavior really just the real because as long as we don't have this rio style attack the network as a whole will still include the transactions of everyone so i think that's the important

part

Łukasz Rozmej: so um two things from me so one thing from thomas was that like example of planning 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 and each each regular each next regulation won't be enough to justify um then like leaving that jurisdiction but they would uh compound more and more so that's that's the reason i see that's how i see the governments operate in general uh in those terms and the second thing uh again i would say the problem for me is that we are getting the whole blocks from from mi v boost and whatever um i i would rather prefer getting the transactions uh for the

and similar for proposal builder separation okay this is maybe a little bit better but i would again rather get a list of transactions and then each uh each node's doing something with it but okay this doesn't solve really the rear parts if we they have the majority so i don't have the solution but i think there should be something built into the protocol that could allow us to detect this behavior and then slash it and then it's fine but i wouldn't like to do it like manually because of uh we believe that this a particular case is that so it's like i don't i don't like this solution

those three things for me

thanks anyone have more thoughts comments okay

Zainan Victor Zhou: can i propose some of the critical level of counter-censorship algorithm so i think i mean i mean sure yeah if you want to take a minute uh yeah please yeah one of the possibilities you have a subset of transactions and then being proposed as fake block and if it turns out that some of the validators this slash is denying the validity of the transaction

because of like in this way you can if you can detect whether it's because of some address that they're interacting with or not then it can be bound into the purple layer as an algorithm to slash them that's one of the idea i have

Tim Beiko: so yeah i think you know for any like new designs or whatnot this is probably just not the best forum to like explore them like these things have a ton of of like implications and and implementation uh concerns so like um yeah i i and not not to say like that this is like not worth exploring but i just think it's probably better to like write a proposal down and have people like chime

in on it than trying to come up with a new design on the fly here

Vitalik Buterin: um yeah i should uh i i should bet that i've like written about this a topic of like what i call accessory detectors or uh timeliness detectors i've made a couple of uh research posts on this the basic idea would be that uh clients would run software that automatically detects like when censorship may be happening um and well so by which you specifically mean like fun block new york's may be happening and you can't give uh like you can't guarantee it a hundred percent

agreement because 100 agreements would like implies consensus which it would be by definition or like we know we can't deal with i'm more than 50 percent dishonest but the idea would be that like clients would have a kind of either things would show you know either things look fine or things don't look fine and uh maybe like maybe the user should do something and then you know you could have a social norm that if the client says things will find them like the users definitely should not do something in any other case

Tim Beiko: thanks um i guess yeah just because i want to avoid us also

going in circles on this topic like bringing it back to like your original kind of ask micah which was around like you know cam clients commits that like we would punish uh this sort of not protocol uh the sort of malicious behavior that's not visible within the protocol but that's like clearly attributable when observing it uh you know it seems like at least some there's like some amount of like disagreement of like at the very least to like the level at which that would be um yeah that that would be necessary and also like um

what's the best way to make that commitment um so yeah i'm not super convinced we can get like a very clean answer out of this on this call

yeah maris

Marius van der Wijden: yeah so uh i think it's very important for each and everyone um 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

then we basically failed um and this is this is the hill that i'm willing to die on and if we start allowing users to be censored on ethereum um then this whole thing doesn't make sense and i will be leaving the uh 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 of uh blockchain space in general so uh if we compromise on that um there's not much else to do in my opinion

that's it thanks um i see lucas had his hand up in martin uh just one comment for that i uh agree with marcus i just want sensual resistance uh from occult devs too what do you mean sorry by that you mean like no yeah

Łukasz Rozmej: so it's a resistance from us like if right now to alter the transactions yeah the state

okay i see yeah

yeah uh martin yeah

Martin Holst Swende: i just also wanted to echo that i agree with marius and i think it's a lot more feasible to get individuals to to state their preference or what you want to call it then to have like the get official opinion is this and another mind official opinion this is yeah what we have are our personal views and i agree with

nourish yeah

Micah Zoltu: and to be clear though that was all i was asking for here i definitely don't expect uh like all core devs to make some formal statement or the guest theme to make a formal statement but i just wanted to say that like i think there is

significant value in making sure that the community knows where the core devs individually stand like if they see 90 of the core devs will walk away if censorship occurs um and if they can't stop it then that tells the community that hey you know if you want to fork off and do that you can but you're going to lose all your developers again doesn't have the official statement i think just a lot of the community doesn't understand that many of us build this for censorship resistance specifically um like a lot of them think we're building it because we want you know policy schemes or whatever um 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 subvert 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: and just for clarity i assume micah your your personal opinion is that you would not endorse the censorship at the protocol level an evil supervillain and burn the world down um but yeah i think i do also part of the reasons why i think this conversation is hard it's like i like what martin said that like having official statements like doesn't work for many reasons because we have like a very fluid governance process because the get team today might not be the get team five years from now when we actually have to like resolve those

issues and so yeah i do think like individual stay in your preferences is the best you can hope for 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 like i very much recognize that like doing it on a live recorded call is like not the way many people want to share their like opinions about contentious topics um yeah yeah if anyone else have comments or talk they can share like yeah we can definitely do it here but um yeah somebody not sharing here shouldn't be seen as like some like

support or like disapproval of like their position on this

um aren't the dutch oh uh i think you went back on a mute um oh there we go oh yeah yeah we got you now hey yeah it's like from nimbus here

Jacek Sieka: so i think one one one thing to remember as well is that there are many like theoretical problems in in 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 um we tend to scratch the itch that annoys us the most and and this could quickly become one

right

Tim Beiko: yeah i i i would tend to agree there and i also think 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 the problem and so

yeah you want to make sure you're not like overfitting some particular imaginary case um early on and you can be open to deal with whatever the issue but whatever the issue actually is once it shows up anyone else have thoughts comments they want to share before we wrap this up okay um well yeah thanks a lot everyone i really appreciate kind of the discussion we've been able to have and that everyone is very respectful and level-headed um last i guess announcement uh before we

head out i will not be running the next of these calls not because of today but i had a planned uh trip for a long time danny will be running the next alcor devs uh and i'll see you all at two calls from now um oh and mikhail has his hand up before we head out

yes a small announcement on the eips 36 75 and 43.99 they have been moved recently to the last goal um like yeah with the two weeks of the period for making anyone's call if anyone have it nice this is a great note to end on yeah uh last chance the larger complaint with

the el merge eips if you have one sweet yeah thanks again everyone and yeah see you at the next one of these thanks all thanks everyone thank you thank you thank you thank you thank you [Music] [Music]

so [Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.