EIP-4396 Time-Aware Base Fee (Breakout #14)

Transcript

okay yeah let's just um start then um so basically um i so so the way i basically see the situation is that um we have um the marshall coming and then afterwards we like i i personally see us going down four different paths we just basically if you choose which of the four we wanted to go down uh the first one would just be no change so we don't uh include any erp uh into the merge that would alter the the basic calculation um and then we'd probably do something in shanghai but we have more time to actually properly work work on something and the second alternative that i see is what i kind of

like to maybe call um mikhail's proposal although as miguel was pointing out he was only kind of like bringing it up as like an orthotic experiment but i actually think it's it's worth thinking through because it has interesting trailers as well that is basically like the this uh basically acting as if there would have been some like empty blocks in the mist slots during the race recalculation so you don't actually insert empty blocks with all the complexity that would entail but just doing the calculation you just basically just act as if there would have been empty slots basically the base fee goes down um even before and the the block you're you're building now um as if there would have been empty empty box in between which has interesting trade-offs and

then the other two alternatives would be the ones like the one that kind of like the ap proposal so i would call that time aware um basically calculation and then the fourth one i would say time to a time aware plus um this buffer which would um make make the timer much more smooth um right is it generally like just briefly before we then dive into like the pros and cons and dive into the individual ones like is there are there any ones i don't know people have thought about over the weekend or something any any any other alternatives that people have come up with that they would want to include in this list of possible options are we specifically focusing on things that would be reasonable for the merge

yes so that would be the threshold basically what can we like because like this is what things we can do during the match okay i don't have anything else something has to be done for the merge is that like the consensus mainly no no that's why i would say like the first option would be do nothing and then do something during shanghai so unless you kind of want to propose to just do nothing out of the list of considerations but i i do think that do nothing is definitely up there as things to do i feel like we should decide for certain whether we want to do something before we start to restricting this

space of solutions right but i think it kind of makes sense to know what we could do because okay i mean i guess the first question is would you want to do something right like because if we already say that we don't want to do anything even if we have good uh options then we don't even have to look at more into the options if we say we want to do something we can always like fall back to doing nothing if if it turns out that all the options we have are not nice enough or something so yes as a proxy for that you could ask yourself if we just had to change a constant would we do it like a constant change is basically the

simplest change we can possibly have and so if we're willing to do a constant change or if we're unwilling to do a constant change then we're definitely unwilling to do any other solution right so marius is saying i think he's on on the train so it's like a spotty connection probably not good enough for boys but he's saying that uh he's not not a fan of doing anything because it's like it introduces extra complexity it's a change and it is not convinced that there's a need for it as i understand it the problem we're trying to solve is that as the

number of the if the if not all blocks get proposed each block that doesn't get proposed just takes away one block's worth of capacity from the system because the way the difficulty adjusts the base of the adjustment algorithm works is there any other problem we are trying to fix or is it just that one uh i think it's mainly so there's this one additional small one that like after missed slot there's this small spike of the base b before it then settles settles back at like uh basically the the same level so so this is like but this is the small one so basically just it's a little bit unsmooth unfortunately

um ux-wise that's not ideal but i think the main ones are indeed missed throughput and then the true consequence of this one the um the the kind of the how it incentivizes it potentially in incentivizes those attacks to for individual validators and two that it can make the whole system um react even worse unless in times of consensus issues and i guess the third one of just in general that we don't like uh reduces throughput although that we can just correct by increasing the gas limit so i would say it's mainly mainly the dos incentive and the

decreased robustness in the face of consensus issues i'm curious yeah marius like i guess if you can speak why you feel like these are not like big enough okay so i'm i'm currently in the train station so i can speak a bit maybe um i don't know i wouldn't say that robustness actually decreases because that like in the in the in the case of a the chain would keep on going the chain would keep going but the

throughput would be reduced yeah but isn't that something that we actually want in the case of uh terrible like i'm not convinced that the dos attack is like actually um really dealt with by that change because the most promising time to do a dos attack is if you notice that there is a massive mev opportunity and that you are the next but one block proposer you are very strongly

incentivized to dos the next proposal um and then you can exploit the mbv opportunity yeah but i think like that that's i mean like we talked about it on all codes basically that that reduces the attacker set from everyone who potentially could benefit from ethereum having degraded performance to only the immediately next block proposal and like because it does it like something like this attack is not something you can just spin spin up willy-nilly where like if when you see something like it you'd have to prepare it for like very thoroughly in advance you'd have to map out the whole network and de-anonymize individual validators um all for the off of chance that like once a month you produce a block and like you

have this it may be opportunity immediately in front of you so basically like i just don't think that we have to worry at all about individual volatility just about crossing each other and i think way more quickly than once a month yeah and it doesn't have to be a mbv opportunity you can you can just if the mechanism allows you to create a bigger block the second block after after missed block you can do this every time you will just do this every time whenever you propose a block you will dust the guy be for you right so this is basically an intent yeah that that's true that there will be an incentive that uh

exists under all different scenarios so like if we don't know change at all then there's already an incentive because if you just does the person in front of you their transactions just pass through to you if uh but but any of the um proposed adjustments kind of like leave leave that situation as is and even the uh the the the synthetic empty box um as a solution would even make it worse because you could extract more value like i said immediately following a block you can extract more even from base fees but i mean even email from tips so so like um yeah so so all of these proposals none

of these none of these people would address that particular issue but it the thing is that these proposals do kind of address the issue of people who are not in ecosystem who are trying to attack ethereum like most of the ways people benefit of dosing people in these scenarios are if you are actually a staker and you're actually producing blocks what this is kind of trying to avoid is the scenario where you are just an outside participant of the network you're just watching and you just want to see ethereum degrade right similar tradition higher tanks just with a different mechanism here you don't you're not dosing by creating like especially um hostile blocks or anything

you're just trying to kick down individual data so i do think even though basically there's another set of incentivized parties naming the valid meaning the biologists themselves i still think that like getting rid of this other set of potential incentivized attackers would be helpful yes matt was saying but of course i don't know i think it's hard to grasp right it would be like a extra consensus change for like a very hard to assess risk right it could just be that this is completely theoretical and no one will ever bother trying to do spell data so it could also be that like people just invalidators would just do it in order to

cause chaos and they would even do it if it doesn't hurt the throughput of the chain it's hard to assess like how much reducing the input on throughput would alter the incentives if they even are there at all i i agree i think the incentive is already there it's already there's already a big incentive to just toss the validators and you're not really fixing that with anything because if you like if you propose a mechanism that increases the block size for the next block or whatever then you you've just increased the incentive to also does the next the next guy

right but of course i mean this this all is under the assumption that like even a motivated and kind of not a skillful attacker kind is unable to dos like the majority of validates right because if they're able to do that then like i mean we should just not just prove like the merge at all so like all of this is based on the assumption that like even a motivated attacker can only occasionally does a valid data successfully and so if that is the case then basically with making sure that like the average throughput remains the same like for that you could basically kick down five percent ten percent of all that doesn't you would have no impact on the throughput um so

i do think that it helps there and just the question is does this doesn't matter enough like is it is it really about throughput when people say i mean i think i think it's about throughput but like would they even bother if they can't if they can only reduce the throughput by five or ten percent right because if we have sustained the tax and they does 10 percent evaluators we can also just manually increase the gas limit by 10 percent to offset this and so i think that the more important part of of does it takes against validate is probably just to i don't know make validators unhappy and cause internal conflict on ethereum i guess

yeah i i'm wondering what what what what would be incentives for external parties to dos validators and i'm just not that convinced that uh reducing throughput is all that um valuable for an attacker um because it only reduces throughput by a couple percent and um we can correct that manually anyway with the gas limit so it's still nice if it was unable to even even do this couple percent effect but like i just don't think attackers would be motivated by this couple percent in the first place i think it's more likely that they're just motivated by trying to generally degrade and just like

yeah cause conflict within ethereum and if i as a hobby validator regularly have my blog proposals prevented by some dos attack but coinbase taking because they have a beef firewall they can just chug along and produce bugs then i might be really annoyed and i might stop staking and that decreases the decentralization so i think that's like the implications like the the the motivations for dosing validators are probably more of this long-term making staking worse kind of um motivation i mean i don't know i i'm personally

like my motivation for this erp was definitely more more on the uh keeping throughput up during times of consensus issues because during the during the interop event we talked a whole lot about scenarios where all the prison notes go offline or all the get notes go offline or all the lighthouse notes go offline and i'm just i personally very much expect this to happen within the first year after the merge at least one event where where one of the client combinations can't keep up with the network and that would that would kick a significant amount of validators offline and i personally really really really want the chain to just not lose any throughput during that time that is my main motivation but like this does attack came up and so i also brought it up in vip

yeah i i guess if if the concern is with one specific combo that seems less of a problem because you can swap out like if it's i don't know like prism and base u right like you can swap out basu for death or something like that that seems like an easier fix that like if it's an issue with like prism itself right um so i yeah and i don't know it seems like the odds of an issue with just a single client are kind of lower just given that like we've had the beacon chain live for a year we've had maintenance live for five years and you know they both they both work and haven't had these these kind of major

issues um and and recovering from like uh uh like compatibility issues uh yeah and yeah yeah oh sorry go ahead no i just wanted to say that like i i'm i don't follow the beacon chain as much as i follow the execution chain but like on on eth1 i mean we had two consensus issues over the last two years right um which was like only made minor um impact but one of them kicked to kick all the open ethereum nodes of the network for a while and um so so these things do happen and i think i think there was something on the beacon as well where like one client for

a while couldn't keep up or something i'm i'm not quite sure but okay right yeah that makes sense yeah but i mean these things do happen yeah and and the the nice thing right now in ethereum and we're really about to lose this it's like in proof of work i mean for one uh miners are relatively centralized for better or worse and so like they are relatively good at directing quickly if they're on the wrong chain or something but also with the difficulty adjustments we have this really quick self-healing property we're sure we have a little bit of reduced throughput for a short amount of time and but then we usually back up and running and given that almost all miners run the same led guest anyway they kind of like

usually like it it's rare that like a small like a 20 portion or something splits off so it's really like usually just all works and in proof of stake this will just no longer be the case it can it's it's much more likely that we have like 20 drop off or like a 30 drop off and there's no out like no cell feeling on any reasonable timeline it just stays this way and it's just basically like from one second to another we just have sustained 30 percent throughput loss on on the chain i think that's really unfortunate yeah i agree um and i guess if this does happen

um we want to be in a spot where like we're also not making things worse with 1559 right like where we're actually you know keeping like and well actually even with your proposal though if this happens and we're losing like 30 percent the best we can get because of like the the slack factor the blocks is like twice as i guess that can bring us all the way up to like say we lost 50 percent and we'd have like 200 percent full blocks every other block okay yeah so your proposal would help i mean yeah i mean if you remember this kind of this slope yeah the graph yeah yeah right because if we do the simplest thing where we don't have a buffer or

anything we would only recover like parts of of the lost throughput um that's why i yeah i really think some something like this buffer would be nice because then you would actually could lose all the way up to 50 without any throughput losses or even considering the like the mikhail proposal of the synthetic empty box the nice thing of the synthetic empty book is that they also completely avoid throughput losses all the way up to 50 offline the disadvantage is that the synthetic empty blocks have other un undesirable side effects that that i think the the the time aware proposal does not or we can dive into them but um

so there are ways of of trying to really not lose any throughput all the way up to 50 offline blog proposals and if i understand like uh is still here yeah i'm not sure if you can answer if you're in the train but like um is the main concern like just that we're adding additional complexity that were like changing this thing which already kind of works um yeah i i i guess i'm curious like what's the you know what's the like i have implementing this i i have multiple concerns um we're changing changing something that

kind of works already and that has been like proven to work so there was like a lot of work done in getting this mechanism to where it is [Music] from uh barnaby and others i think and um i don't know i i i really don't like changing this uh this uh thing at hog um and uh yeah it also it just introduces another change um into the merge and the merge is going to be the

the like the most insecure point in in ethereum history um the point where like uh most thing can go wrong ever and i would like to have as little changes as possible there i don't actually think that's unreasonable um i think i think it's definitely something where we could step back and talk about like yes even if say under a consensus issue which i think it's not unrealistic that we'll have one hopefully minor consensus issue between the emerge and shanghai but if we say we really have we will have some version of this in shanghai and with more time to

work on the best version of the proposal and really properly analyze all the edge cases say um then it's really only about for like about the time between the merchant shanghai and like i mean we always have some delays in minutes i assume that the time won't be like three or four months i assume it's more likely to be like six to eight months between the merchant shanghai but even that is like a limited amount of time and during that time it's not like it's it's a huge vulnerability it's like um it is a [Music] like basically a non-insignificant degradation of surface during consensus issue but we can react by increasing the gas gas limit right so basically days

while there is no self-healing abilities if we react relatively quickly and increase the gas limit it kind of counters the throughput loss as well it of course it's something we could probably take a couple of hours at least it's not like we have to live with a couple of weeks of reduced throughput and and if we really think that the dos attacks are not that severe again that's just not my my area of expertise too much and then i i i think marius's proposal of saying like let's do this properly and only do it in shanghai and keep too much minimal i don't i don't think it's necessarily a bad idea um i don't know to me it seems it seems to be kind of like in the in the a little bit yeah right at the border of like it's

small enough that it might be good to still do it now but it also like maybe not maybe we should wait can i also point out that like there's enough like talk and ideas about how the fee market works that like definitely aren't appropriate to do at the merge but it's reasonably likely that regardless of whether we do this change that we're likely to do something more substantial in shanghai anyway um i would agree with you if there weren't already like 40 000 things that we're saying you're gonna be in shanghai um so i you know i like my personal read right now is like something like i don't know say like the

amm fee market like proposal like i see that very unlikely in shanghai just because we have a bunch of vips that are like already much more specked out than that have been waiting you know for like probably close to a year already so more realistically like maybe something small like this gets done in shanghai because it's small and like it's easy to articulate the value and and whatnot um but i think like if we if we need to do withdrawals in shanghai if we have like four or five evm related eips that we want to all do or do a subset of um if we have to do like you know a small fix with 1559 that seems reasonable but i like i yeah i

i'm very skeptical that we do like introduce withdrawals plus like a massive change to how the free market works um yeah yeah no it was just for the record i i think and that was part of the design choice of this eap that it's mostly orthogonal to all these other base fee changes where i mean i initially went into this and also had some more interesting ideas around how to make the base fee calculation more elegant but i abstained from putting anything any of that into the cip because basically the way to think about it i think is that like there's the signal for the base fee update that comes out of the fullness of the block and right now we're debating how to modify

the signal right by also taking the block time into account um potentially but then there's the question of once you have the signal like of that the base we should go up or down like how do you calculate the new base fee like do you do this one eighth rule that we have right now do you do some maybe additive rule instead do you do some exponential rule instead do you do like an amm rule instead but all of this is basically just taking the existing signal like that this tells you whether you should go up or down and how much you just leave this like a strength of how much you should go up and down and then just calculating the actual new base fee out of it and so basically like all of these other proposals are kind of like on the how to calculate side where

this is on the what should the signal be to look at side and so i think it's mostly orthogonal so it's not something where like we do we change it now and then we probably completely change it again and in chennai i think it would be mostly i don't know right and and i think yeah like barnaby's also looking right now at ways that we could improve this signal um so like yeah i suspect it's it's possible that that's another big thing that gets discussed for i'm not sure if we could put it in shanghai but either shanghai or one after right so that seems like

oh sorry i was just gonna say it seems like people are leaning towards doing nothing it seems that way um i mean also it seems at least to me like no one is so so just really like how concerned are we about the external dos like again external meaning like we ignore for a second the validators does see each other like how concerned are we about external dos how concerned are we about

throughput reductions during consensus issues um it sounded like we people are barely concerned at all about external dos attacks on validators and only a little bit concerned about the throughput loss as well is that a good assessment i am more concerned about the throughput loss than the external dos attack on the time horizon that we're discussing like post merge there is a sufficiently high chance that there will be a outage of some kind and consent on one of the clients or one of the execution clients and during that time it would be nice if we didn't have throughput loss i agree with end score on that and i think

that the chances of that are fairly likely whereas the chance of some person who is not intimately familiar with ethereum and working on it every day decides they want to show up and just stick around and beat be trolls to ethereum it seems unlikely they're going to do that you know within six months after the merge especially given the amount of work it would take to build such a thing yeah that sounds reasonable actually and like how would you say than looking focusing on the under throughput last time how okay would you be with a solution of just saying we just basically have to manually well i mean okay first question with the gas limit right

because the the way to manually react at least would be by pushing up the gas limit we do not expect to have the eap um met your erp um that that removes this ability from the individual stakers and gives it into consensus control i don't expect i don't think we want this included is that right there's no plans to include it before shanghai okay so then during this time period we would still have the gas limit control in the hands of the stakers and so we could what we can always do is like if we see a 30 throughput bus because some client combination or combinations making up 30 of purposes go offline we could just basically tell people to

manually increase push the gas limit up 30 percent of course that disadvantage is twofold one it takes a while um i guess it takes at least several hours probably more like a day or so before this information reaches enough stakes that we can actually move with the gas limit and then also secondly once the participants come back online there's a risk that because there's like some amount of people who want a higher gasoline anyway that the gas limit is just sticky at the higher value and doesn't come back down and then we have the problems of like a too high throughput and then you can hard fork the limit in

the next upgrade in a convenience way but yeah uh that that is uh but but i i think you're right that that's a a risk right like we we've raised the gas like a 30 and it gets stuck there and like it becomes contentious to bring it back down um right i mean this doesn't doesn't sound like too bad right i mean oh this is only in the scenario that we do have an issue which is not like yeah it's not guaranteed to happen um and i mean like do did how well are people doing because i always hear these these these kind of things that like with the difficulty

bomb even a few percent percent of slaw blocks would be terrible for d4 or something i never believe this i always feel like that's hot but um how bad would it do we have like a good feeling for like how bad it would be for the change or just to have like a day of 30 to reduce throughput or something is it like just like an inconvenience and or is it like really bad or to take the d5 perspective right like it's probably millions of dollars in like economic inefficiencies right like and and like you imagine just like ripple effects it's like if your theorem gets tossed and like it slows down then like

it it starts uh you know people are upset about it and it starts being like negative coverage and whatnot like i think it will be a bad thing but it'll be a bad thing kind of because ethereum is getting dosed um so well no i mean this that but this would be in the case of like nonsense issue but but but yeah same same thing it would be like it would be narrative of like yeah we have like a specific issue with the client or something and like yeah and i think what's happening yeah yeah what's bad with the narrative in a way is like if you have a narrative and like say that the price starts going down then that actually creates demand for

on-chain activity because everybody is then trying to get like their you know their collateralized positions not liquidated so everybody wants to use the chain at the same time um but then we already have you know less throughput so it makes it it's just like a compounding bad problem um but like and so i mean like what it would feel like is of course just like higher base feed right because then at that level we would still yeah and so yeah and also to be fair like um this is not like the only case in which these things can happen and applications

i think are like starting to work to improve like their resiliency towards that so like there was obviously like the black tuesday thing or thursday like when cobit hit and a bunch of people got liquidated and and maker had had a bunch of issues and i think you know applications are starting to do things like having longer time windows to uh to to put collateral and stuff like that so like this an issue on mainnet is not the only case where like the the performance can be degraded for some of these applications if like there's a massive drop in price for something external to the chain like everybody's gonna want to rush and you

know do stuff so um so these applications kind of need to be robust to that as well and it's obviously not a good thing and you don't want to like have it happen but i i don't think the case we're describing is like beyond the sort of scope of negative events that like robust applications have to have to think about and i mean especially right because if we're saying that because it would just basically mean the higher base fee and so i don't know say right 2x the basic would would result in like a 30 reduced demand or something i don't know something like that seems realistic and so i mean we already have inter week variability of base fees of more than 50 right like

it's not it wouldn't be super unheard of if we have like twice as high base fee for a week right we already have that yeah and i think the concern is not as much to twice as much basis for a week but it's like the 10 to 100 x as much base fee for 30 to you know 300 minutes right like if there's like this hours long period of time where everybody is trying to use the chain asap um that prices a lot of people out obviously and then if some actions need to be taken within that period and for some reason you can't get in or the reason being like you're not bidding high enough um that can be kind of really negative but i don't think a weak of twice as high the base

he is like i mean it's bad but it's not like catastrophic in any use case so the thing to keep in mind is that for the last what two years there have been some non-trivial percentage of users that would like to use ethereum that cannot that percentage will go up if we have 30 of empty blocks but fundamentally there will still be a class who can use ethereum in a class who cannot and that like fundamental aspect won't change just the size of each pool will change a little bit right but we are talking about during times of like unusual like basically like shortly after a sharp drop of of of proposals so like for a couple of days after

consensus issue it's not like a um persistent situation yes so i mean you could i think you're making there you're making percent quickly is basically that the sudden change this can be unexpected and so while users pre you know one minute they're able to participate and use ethereum and then the next minute they're not and they can't for a day um and that's ordinary but even that isn't unheard of like we've seen that behavior just due to something hits the news or some new product comes out or whatever and you see you know the set of users that can afford to use ethereum just went up by huge margin and one could argue that is functionally the same so whether we have an increase in supply or sorry a

decrease in supply or an increase in demand they're functionally the same overall and so we have seen times where the increase in demand suddenly appeared out of nowhere and lasted for an extended period of time and we have also seen and so i don't think that's very different like in terms of broad economics game theory etc than what we're talking about which is that we have a sudden decrease in supply that lasts for a while not not only have we seen this i mean i don't know we've seen i think there was in the news literally yesterday that we have the first full week of ethereum being deflationary which is is because we had a week of really high base fees and i don't know right now the base fee

is at 230 and we've had weeks where the base fee on average was at 30. so that's like almost a 10x increase and um we while it's not nice kind of like people are able to adapt and absorb this and so like a 2x two tweaks difference in a situation in a very exceptional situation that we don't expect to ever arise but like it could arise like once during six months or so for two three days it really doesn't sound too bad putting it in those terms to be honest right so all of this does kind of point

slightly towards us giving in to marius and but like um is is anyone would does anyone still feel strongly that we should do this nah like for the merge already and would want to try and bring us back on like point us back towards that direction or is everyone either ambivalent or convinced that we shouldn't do it because i'm definitely ambivalent and i'm fine with not doing it i'd just like to understand oh go ahead i was gonna say i'm pretty empathetic to the concerns that 1559 has been vetted by many different people and it's concerning to like change these

mechanics but i i think we still have enough time to have the proper people vet these things and i find it pretty concerning that people who are not part of the ethereum ecosystem can attack the network for a relatively cheap amount just for the record by the way i do think that we've had been we've been hugely paranoid as an ecosystem about 1559 where we consider really treated as like this super black magic voodoo thing with super complicated impact and similarly after the change i like every negative aspect thing that ever happened on ethereum afterwards was playing with 1559 without ever

anyone bothering to try and even point out how a plausible mechanism could have worked like like oh yeah basically it went up like this has to be 39 and everything and like in reality i really think that 50 59 is quite a simple mechanism and it's not all that hard to reason these things through but i mean again this is out outside of this discussion it's more like a for the racket thing so matt what you're saying though is that you you're concerned about the external dust issue and like for that reason you would still

prefer us to do something uh for the merge already to disincentivize this further what i'm hearing is that the thing that people are afraid of is that we are going to do something that's going to break 1559 and or increase the surface area of the merge and i think that there's still time to have people like barnabas people like tim gruffguard review a change to 1559 and i think that that's going to make the network safer and i think that we should try to make it happen so i'm not worried about that part like the i think that the changes suppose are pretty tiny and they did a pretty easy

review and like i said we can get them reviewed in time then what's then what is the main concern for not doing things because my understanding was that it had to do with that the it's it is another change that is just one more thing that can have a consensus failure or a bug and so when you're you know going through and dealing with consensus failure after consensus failure after consistent failure um well we're like leading up to merge and working on it and all this stuff because it's really complicated adding one more thing to that just is yet another thing that can fail and delay and um cause distractions stuff like that and so i think the idea is just literally anything would meet that bar of

it's a change things will change tests will break stuff is going to go wrong because that's what happens when you change things i guess the way the world works when you change things things break is there so is there value in maybe like trying to do kind of the the review of this in parallel to the merge work and we can kind of see because like if we if we do nothing now obviously we're not going to do this for the merch right um maybe it's it's uh it's it's valuable to take enzgar's proposal have it reviewed by barnabay and potentially tim roughgarden if he he still has the bandwidth for this stuff

um and you know in parallel obviously the client teams are going to be working on the merge and and once you know once we have this kind of thoroughly reviewed um we can see is this something we want to add like you know based on how complex the client code is um yeah what's the timeline here so i would rather spend barnabay and tim rough gardens i would rather spend their time on something more long-term personally like unless there's a good chance this will actually go into the merge i'd rather them spend that same time like working on the am fee market for example or changing it so we do rate based throughput instead of block based throughput like those are chains i think are way more valuable but not

definitely out of the scope for the merge and i'd rather if we're going to throw brains at this class of problems particularly brains that could be doing something else in this class i would rather do other things in this class i don't think oh yeah go ahead i was just going to say i generally prefer to like softly accept things and then based on the like output of the research or development uh remove them rather than like quote-unquote work on parallel because i feel like it's just a stronger signal that this is something that might happen it's not really that relevant um but i

also don't understand marius's point that there needs to be a change to the transaction envelope i think this is only a change in the state transition in the verification logic of 1559 i saying in the transaction early transaction processing period so like before you're in the evm before you're um like we have to do the individual transaction level isn't it on the block validation level i think it's point i think his point is just that like this particular area of code where this change would live is an area of code that will not be touched otherwise by the merge and so now there's like a whole section of code that's well i mean it will be

touched by previously going untouched because the consensus are being modified i mean there's a fully consensus module now and so yeah i guess the piece of code is all changing yes i guess depends on how your specific client i think that's just uh that's dependent on the architecture client i can imagine my client design where the consensus module is pluggable and they assume most clients are like that because they all have multiple consensus engines already in which case it's just like you know you you instantiate a different class or something very early on otherwise no code is touched like instantiate a instead of b

but don't we already changed some of it again block header validation logic and reinforce difficulty has to be one right like this is a change in the validation inside the execution point is that a is that validation occurring in the execution engine not a consensus another then because the consensus client is doing some block validation themselves i believe yeah but the execution client still is verifying different portions of the header okay and and so it will validate the difficulty is in fact zero or or sorry and on definition so difficulty they can't validate because it's random

so but you're needing to remove the difficulty check at least so there you're right there will be a change in the block validation because we have to remove the difficulty check at the very least right and there will be also a change in the block validation because we need to remove rewards we need to um deprecate some fields right so these are also changes and my main question here is what kind of work should we do before we can accept this eap i mean do we need to do some analysis i guess yes do we need to and what kind of like engineering work uh like testing um

observing this new behavior in in the test net um artificially making mis slots and see how it progress or what else could be in this list yeah i think that kind of depends oh i mean not depends but maybe it's related to the general question of time right here right like what is because i think the goal was to have the the spec freeze more or less for the merge by the end of october we have like first of november now is it first yes first um so i i mean i guess spec freeze in general is kind of like a week's victories where

we like there might still be changes afterwards and this i guess could come in later but what's what's the time that by what time would we have to make a final call on this being part of not being part of the merch uh in 11 minutes that's a good question but this this freeze for the end of the october that we are working currently at is not the last one so this is to initiate the next wave of engineering efforts around the merge uh it's not like the like you know the final set of things uh that will go into the match

so um for yeah for like the last um for for when the last like for free spec freeze it should be expected it's like a really difficult question depends on on what we'll see in november yeah but i do think we probably don't want any new features like this seems like it's maybe the last feature that we want in the merge right like obviously the spec freeze like if we find bugs and whatnot we need to change the specs but like the general mechanism i don't think is going to change and and you know the like the block header and whatnot is not going to change but this seems like it's maybe the last

feature change we want to bring into the merge and that being said it's like we you know then it becomes a a trade-off like if we really want this then obviously we'll add it in i think we do need if we wanted to get this done we should start researching and you know testing things kind of now at least from like an eip level and expect that like once clients have implemented this latest spec freeze which i don't know say it takes like a month then this would be like the next thing they implement so either very late this year or early next year um but i suspect and i i guess for the

people here like what this means is like we probably need to get this into a spot where it's like spec frozen for the eip uh before kind of the holidays right and then what i'm just wondering is because i'm personally kind of optimistic that kind of working on this in parallel like we will probably kind of get to some finalized version of the erp that everyone thinks is the the best thing we can do for the merge and that it's incentive compatible with 59 and everything but the question then is at that point we would come back to say oh cortez or something and discuss this again and then i feel like we kind of fall back to the same discussion we had here over the last 45

minutes of like but do we really need this in there and if the answer then will be no the question is why even put all the effort in right like is there is a reasonable chance that people will actually want to include it when if it is ready in time and if the arguments don't change to what we discussed here today is basically my question because i mean i would be more than happy to just continue working on this and working with barnaby and whatever and like making sure it is ready in some form but all this only makes sense if there's a reasonable chance people then want it in and i'm just not not sure right um

i'm not sure what's the best way to get to that conclusion without basically we having this conversation again in you know two weeks um i do wonder i guess maybe it's worth spending like a bit more time like spending like say until the next awkward devs to like get i don't think we can get like tim rothbard in the next two weeks to like comment on this i mean we can try shooting him an email but we can probably get barnaby um i guess there's not a lot of people from the e2 side here as well and like getting also kind of their input um just to see like

oh it's like with regards to how just like the spec works and whatnot you know the the benefits of this um yeah i i don't know it feels like maybe there's value in spending like the next two weeks trying to get more eyes on this and more feedback uh and making kind of a call on our core devs like in in two weeks whether this is something we want to like weekly include potentially i don't think there's significant pushback on the implementation itself i think the pushback is on just the general premise of can should we change anything and and or is the

uh the threat significant enough that we need to care like even if we had you know 100 buy-in from barnaby and tim rough garden and they were like yeah this is amazing this is will be great this will fix all of our problems i don't think that would change the outcome in any way and so i'm hesitant to devote resources to getting that if it's not going to actually impact the outcome for me it would change the equation a bit so i'm uh for me it's not only the um i'm probably i'm in the tunnel right now so you can probably not hear me we can hear you perfectly well okay actually nice

um for me it's probably it's it's a combination of both um it's a it's a change in the algorithm that we don't really know if it like makes sense or if it even breaks something or what whatever it does and um it's it's a change so if like one of those would get resolved i will probably and there's sufficient buy-in from from others to say okay this is actually an issue that we need to solve um then i i wouldn't anymore so one thing

sorry one thing uh i i'm talking with danny also he couldn't make the call uh send me a couple messages about this um one thing danny ryan kind of feels about strongly about is um right now there's no incentive in the e2 protocol to there's no disincentive to not produce a block so there's obviously an incentive to produce a block you get the transaction fees but you're not penalized in any way if you don't produce a block so because of that he would like to see something that takes into account missed proposals um generally uh when you know uh when calculating 1559 because it's like if you can

if people decide they want to agree by not proposing blocks then you can make it easier for the next proposer you know to like if the next proposal basically has to raise their base fee um because of that um then you're you're just including less transactions and and that's not great so i think it might be worth also talking with him in the next two weeks to see like what's uh is there a change that we can do or does this current change basically help with the fact that we don't have a specific penalty for not producing blocks beyond the opportunity cost um and that might actually help in a world of spherical cows the

opportunity cost is the penalty it's equivalent to slashing in the real world i understand psychology is different around opportunity cost versus actual cost right um but like mathematically which is what we usually try to model things on even though it doesn't match reality um they are being slashed functionally right but if there's a way where like them not producing blocks is either neutral or positive for the next validator you can kind of increase that you you're basically distributing that penalty in a way over two valid letters right that's kind of a bonus to the other person which is which is a nice property right although of course i mean

we it also says dangerous drawback of this at the same time incentivizes people to try and open their ancestor blocks and right right so i don't think yeah we can we probably can't solve this in three minutes but i think given mary's comments and like the general feeling it's probably reasonable to spend a bit more time here and to maybe talk with like danny and barnabe and and and see if there's like a proposal that we can come up with that's simple kind of helps with the spec and and is not like uh yeah obviously doesn't have like a huge engineering overhead um and then we can kind of make a soft call about that in

like two weeks on our core devs does that seem reasonable i is it is there anyone oh sorry go ahead i was just gonna say i thought that we were already under the assumption that we were doing the most minimal change that's possible and so we're trying to determine like is that acceptable right and i guess that yeah i was just understanding like what you're saying as um like exploring if there are minimal changes and then trying to figure out if people are i think it's less about the exploring it's more about the understanding the post one better or something yeah that and like if there's a tweak you know i think we need like a

generally minimal change like i don't think you know and so anything that's like a overall like overhaul of the mechanism is kind of out of the question within the kind of universe of minimal changes you know making sure that folks like i think danny and barnabay at the verities like are on board and think it's like generally a good idea um or you know if there's tweaks to the current proposal that don't add a ton of engineering complexity but you know make it like more robust i think exploring those in the next two weeks makes sense um so i i haven't heard anyone here really indicate that they are strongly in favor

of this i think matt is probably the most strongly in favor from just the sentiment analysis i've done in my head meanwhile i think every single one of the core devs is going to push back on this i suspect that unless we have someone who is really passionate about pushing this through it is not going to go through just due to inertia alone even if we do solve and address all the problems i don't see it going through without a strong champion um so i guess the question i would like to answer before we walk away is is anyone in this room passionate enough that they really want to fight and die on a hill in court death calls i think that's what's going to be required and i mean this isn't a hill that you guaranteed are going to die on but there's a very good chance you'll

die on and so we need someone who's passionate enough that they're willing to take that risk and i really don't want to die soon but then you should not take this battle i am willing to try and make a stronger case during all core devs but right and then maybe like the last last point here is that just like because i'm super willing to spend a little bit more time over the next two weeks a week and a half even i i don't think it's lost time anyway because it helps understand 59 better and so it would also even if we don't go ahead with it for the merge i think the the kind of effort wouldn't be lost for them working on something similar for

shanghai so i think it's reasonable and then make a call if we want to move ahead or just stop um on aquadevs i think it would be helpful if maybe someone else or maybe also myself i don't know um could also spend some time doing doing during the next two weeks kind of like working a little bit working out a little bit clearer these the specific reasons for why to do it right basically like this thus concern and the throughput reduction concern just basically kind of like exploring this a bit further and just just so we have something of saying that should clearly answer like why would we even want to do this right because i do feel like we're kind of like a little bit like yeah maybe that was concerned like who is even the party that would be

right like these kind of things and are you guys uh do do the two of you care enough about this project to work on it in lieu of working on any of the other thousand projects you could work on on ethereum i think that's the other question for the champions i i'd be super happy to like spend some of my time over the next two weeks on it if if for not no other reason than the vanity of having an erp with my name on it be a little bit more likely to move forward and that if your name is on an eip it will not go through like that's just how the world works yeah you gotta have mike as a co-author yeah yeah

this needs to be merged yet uh i see that it is it is approved but still to be married yeah mike i met what's that what's going on with this it's been ready since friday what's what's the delay no no no she's broken censorship is the real reason the reason i'm going to tell you is that the bot is broken right now micah broke the butt yeah just just to censor your eip yeah your attention is not being sent that the bot is just broken yeah that's just uh i guess just because we're uh we're coming up on time um i think the people it makes sense to speak uh for you to speak with enzgar are at the very like first i would say

barnaby and danny um i think they can provide like good feedback the the problem with the dos concerns so unless like marist is on the call here and i you know don't want to volunteer it but like my my feeling is like all of the client devs who are most qualified to speak about that are going to be working on the merge implementation in the next few weeks so it might be hard to get kind of somebody um yeah if marius wants to volunteer himself he can um but like yeah i think that's the that's kind of the the main thing um yeah i know maybe asking uh maybe asking in in awkward abs or

something if somebody on the client side is interested in kind of working on that um right but isn't it because it's it's it's thoughts of the issue of the proposal right so it's more oh i'm sorry yeah right yeah because it's a different dose right you want the consensus side of things oh yeah they just shift their hard forks they have plenty of time on their head um so i think yeah uh yeah i think then just asking in the consensus dev or like asking danny who's like the right person um so i think that still makes danny and barnaby the two first stops and uh i'm sure danny can find somebody on the the consensus side who can who can look into that more sounds good and that's probably good

good point to stop any or anything else anyone wanted to really bring up in the last seconds of this call okay so then uh thank you thanks everyone for coming yeah just a couple of announcements before i let everyone go there are two meetings coming up uh for that may be irrelevant for people here one is the ethereum execution layer of the state of ethereum execution layer specification with sam wilson that is scheduled tomorrow it's a penny meeting but it could be a very good discussion to know where the ethereum execution aspects are right now and the meeting is scheduled at 1830 utc the another meeting is the merch

community call one uh that is planned on november 5 at 1400 utc thank you thanks thanks for organizing this and i second the recommendation for the call tomorrow sam's walkthrough of the spec work if you hate the yellow paper with if anything resembling the passion i do then you're that would be the call for you to be on send me a link i do have great passion against the yellow paper all right thank you everyone for joining today i'm gonna share the recording very soon and um i hope the next meeting is an all coder meeting so let's see if there is any decision of having any

further call related to this particular proposal like the breakout room call i'll be happy to schedule one thank you everyone awesome thanks future and thanks everybody thank you everyone bye