EIP-1559 Implementers' Call 7

um so yeah welcome everybody to 1559 implementers call number seven now uh like i said we have a bunch of things on the agenda um i tried to list them in order uh to go through them uh so maybe we can we can just jump in uh first item uh tim rufgarden who's joining us today uh has put together a pretty extensive economic analysis of 1559 um he published it i think two days ago so uh hopefully people have time to digest it since then um but maybe tim do you want to take a few minutes to just give a kind of short summary of the analysis and then if people have questions or comments we can we can go over those uh sure tim happy too um thanks for the invitation to join the call um i don't want to go on too long because i want to be driven more about people's questions but maybe just sort of i'll just quickly say kind of the structure of the report um so after de describing you know just recapping how 1559 works um so giving a you know fully precisely um detailed definition of exactly how it works um the report talks about uh how to think about um a market of ethereum transactions so you know evm computation is a scarce resource and so ultimately you know users or creators of transactions are vying for that scarce resource um so ultimately that's the point of the transaction mechanism to figure out who gets access to that resource and what the price is and sort of the purpose of that discussion uh around ethereum the market for ethereum transactions is primarily to clarify um you know what 1559 can be expected and cannot be expected to accomplish with respect to the the level of transaction fees because i know there's a lot of concern in the community about high transaction fees um and the main point i wanted to make there is just that you know you know when sort of uh demand for evm computation for iops trips that supply you're going to have high transaction fees it really doesn't matter what mechanism you use 1559 does help with things like absorbing uh short-term demand spikes and so as a result uh you should see uh low or maximum transaction fees you know in periods of high demand but again when you have much more demand than supply no matter what the mechanism is you're going to see persistently high um transaction fees so then with that out of the way then i start to analyze um 1559 in two ways um so the most technical part of the report sections five and six um that's really analyzing the incentives of 1559 at the time scale uh of a single block okay so thinking about say miners who only care about the revenue that they get from that one block and are not thinking about making short-term sacrifices to reap rewards later on similar users who are just focused on getting a transaction in the current block and just trying to figure out how to bid and so sections five and six outline several game throughout guarantees that you might want a mechanism to have so miners should be incentivized to do what you would like them to do users should be incentivized to you know bid in some sort of obvious optimal way and then also you'd like robustness to off-chain agreements so that users and miners can't easily collude for example to sort of basically steal money from the from the protocol uh so those are sections five and six sort of uh listing those three properties first price auctions the status quo has two of those three properties but 1559 has has all of them uh or at least almost so in particular um the those sections include a mathematical definition of what sort of easy fee estimation might mean or what a sort of good ux might mean i mean first price auctions do not satisfy that property and the 1559 mechanism does satisfy that property except during um periods where the base fee is much too low okay which would signify that there's been a very rapid uh increase in demand where the base fee hasn't had a chance to to catch up yet so those are five and six they're the most sort of technical sections in the report section seven um i discuss uh you know attacks or manipulations you'd be worried about that take place over longer time scales um and so for this you're usually thinking about a cartel of miners um because any one or at least mining pools because any one miner is probably mining blocks sufficiently infrequently that you know long-term strategies aren't are not useful but if you have a well-coordinated mining pool or if you have a cartel of miners with a large amount of hash rate all of a sudden you start sort of worrying about what they might do if they strategize over time for example you know could they manipulate the base feed downward to reduce the fee burn um and so section seven i from what i can tell it seems like this was the one that's generated the most kind of discussion on you know say twitter thus far um so maybe let me just sort of say why what i think the sec what i was trying to say with the section um so the first goal was just to sort of revisit first price auctions the status quo um and ask the same question right so like what could miners in principle do by colluding over long time scales and what do they actually seem to do and so there you know we identified collusive strategies that would in fact be in minor's interest if they implemented them and then we observed that miners do not seem to actually do do sustained um long-term collusion and you know i'm not in a position to conclusively say why that is i just sort of listed a whole bunch of reasons that i thought of and the people who told me about here are the reasons why we might not see this kind of sustained collusion with first price auctions um and then i go on to observe that you know that whole list of reasons that apply to first price auctions apply equally well to the 1559 mechanism so there do seem to be impediments to collusion by miners now under first price auctions um and you know and nothing about 1559 makes it easier for miners to collude now 1559 may make miners more motivated to collude because now they sort of have you know there's this additional incentive of evading the fee burn so the point of this section is just to say that in some sense the cost of colluding i don't see any reason why that would go down with 1559 it's as difficult as before however it is true the benefit may go up to minors of pulling off the collusion and i try to be very careful in the report of not predicting whether we'll see significant minor collusion or not i mean the final section of section seven um the caveats explicitly discusses this point you know that they miners may be more motivated than it to collude than they ever have been before and so in particular there may be types of collusion we have not seen under first price auctions which we will see not because they're easier to pull off but just because you know they're motivated they're more motivated to do it um section eight is something i thought would generate a little more uh discussion than it has thus far um so i think so the first part of section eight is just to clarify that you can't really do sort of the fee burn without the base fee or vice versa with an exception and so this is section eight three this is one of the two alternative designs i discussed in the report so the first alternative design is so it's really crucial for the game theory the world of the feeber in plays what's it really important is to withhold base fee revenues from the minor of the block which generates those base fee revenues uh so it has to be withheld from the miner who minds the block the simplest way to do that is with a fee burn and of course there's lots of other reasons why people like a fever as well but section 83 points out that the game theoretic properties are really just as good as long as you pay those base fee revenues to somebody else for example and this is a proposal i've seen by uh vitalik and possibly others for example you could instead pay the base fee revenues to minors of future blocks okay so for example the next thousand blocks you can spread it out equally and then there is no fee burn basically just each block now has kind of a bonus added to its block reward depending on the sort of base fee revenues from the previous say thousand blocks so that's one of the main alternatives suggested which i have not seen discussed um so far uh and then the other one is a version of the 1559 mechanism where instead of the tips being user specified um you hard code them into the mechanism and this has some problems like you would expect um sort of off chain tip markets to emerge um you know i i give no opinion on whether that's a deal breaker problem or not but you would expect that to happen on the other hand it's uh definitely simpler uh to have hard-coded tips uh and it has some nicer game theoretic properties you know which just explaining that we get into the weeds but so there are some nice um nice uh aspects of that second alternative design that i call the tipless mechanism in the support and then the last section of section 8 is i talked about the base of the update rule and this again i sort of seen people coming up with very reasonable um requests that they should be analyzed from a control theoretic perspective i totally agree i think actually it's probably a quite easy control theory problem if you found an expert but in that case you know arguably the most sort of arbitrary feeling uh aspect of the 1559 proposal is the specific way that the base fee evolves over time so the functional form all the choices are sort of natural you can see why one would make them or why they're a natural guess but the functional form is sort of arbitrary you know one plus an adjustment factor you know there's two magic numbers in the rules so the 1 8 which controls how rapidly the base speed can increase or decrease um and then also there's this question you know there's a magic number of exactly how much bigger should the maximum block size be compared to the to the target block size um so in that section section 86 i try to clarify all of the assumptions that are baked into the current update rule um and you know what are the different what are some different dimensions that you know they should be experimented with over time and it may you know it may be hard to iterate on the update rule until there's actual data from a real deployment i'm just from the armchair it's hard to have a compelling case of why something else would be better than the current one but i just wanted to you know a heads up that probably this will want to be revisited over time like the various other parameters that we visited um with every network upgrade uh and then in the last section section nine i talked a little bit about the other benefits of 1559 so the report focuses just on sort of good ux easy fee estimation but of course there's lots of other reasons people are excited about 1559 so i just talked about what those are in section 91 most notably the fee burn but also kind of preventing economic abstraction i'm having a reliable measure of kind of the current gas price that's hard to manipulate for use in smart contracts and then the final section um discusses uh the escalator both kind of as a standalone proposal and also how that might be integrated uh into 1559. um so that's sort of the executive summary of everything discussed in the report and obviously people have specific questions about parts of it i'm very happy to to address those thank you yeah that was great um does anyone on the call have any questions thoughts i have a question which isn't necessarily something explored in the reports but i'm quite curious about your intuition with regards to it the question is uh do you have any thoughts on what you think would happen with if you have two parallel markets running during transitionary periods because one of the suggestions has been to have both the first price auction accepting those kind of transactions with the with the one five five nine in parallel and i'm curious if you might have an intuition about maybe some emergency effects that might happen or i don't know just curious about your thoughts on it yeah that's a good that's a good question so just to clarify um so this sort of transition plan you know i've seen this a few different things discussed my understanding is that plan a is you would have a period you know where legacy transactions we can we would be converted or sort of interpreted automatically in the 1559 format by taking the gas price and interpreting it as sort of both the fee cap and the tip is that is that the is that the specific proposal that you are that you're talking about that one as well but there is another level to this which is the bun wasn't intended but when you talk about layer two systems because many layer two systems that we see think about also having a free market running on top of the base layers flea market so there's the transitional periods where you do this translation but also dual markets when you have second layer markets running on top of it i see so you're saying interactions between this change at layer one for you know versus what happens upstream but also inside the layer one itself i guess these are two separate problems but yeah those are the two that i see okay yeah yeah i agree they're really they're separate things um i mean you know i the discussion i've just seen around i feel like some some some good thought have has gone into a discussion has gone into how to manage the transition you know by the by the by the 1559 team um and i have not seen you know in some ways i mean i'm not i'm not in the trenches with the implementation so i can't comment on that but you know from what i've seen the the plan seems very reasonable um you know to have a to have appear so and one thing that's nice about it potentially one would hope so first of all people don't have to you know wallets don't have to change initially if you have these sort of support for legacy transactions and then you would hope that there would be economic pressure over time um for everyone to switch over to 1559 format right because there's really basically two parameters to play with uh the tip and the fee cap in 1559 and if you don't bother to pay attention to that you're kind of stuck with this much sort of more restrictive way of bidding where you just set the one gas price um so that's that's one thing that i i think is nice about that transaction i mean so first of all it seems clear you don't just want sort of an immediate sort of hard stop where the legacy transactions aren't accepted and so this seems like a really nice way to have them around for a while but at the same time you know there is an economic incentive for them to hopefully go away over time the layer one layer two interaction i mean i i'd probably have to know more details about you know i assume that happens in like you know various ways for various layer twos and so i needed more details to talk about it at length um you know i will say you know i mentioned this briefly that one of the side benefits of having this base fee is it should make it easier to sort of know what is like the typical gas price at any given moment uh namely the base fee unless you're in a period of rapidly increasing demand whereas if you just kind of looked at ether scan right now and you sort of look at a block and you're kind of like well if i wanted to associate a single gas price with this block what would it be i mean you could use the minimum the average the median et cetera there's the statistics you could use um but you know there's worries about you know those could be manipulated if people knew what statistic you were using uh whereas the base fee is hard to manipulate and again outside of um sort of sharply increasing demand you know should give you a reliable uh measure um of the sort of current gas price so my hope would be that that would be a quite useful additional functionality or really an improvement for um interactions with layer two down the line so i think hi tim um i i think the easy way to think of the layer 2 thing is you have the layer 2 chain generates blocks at a higher frequency than the layer 1 chain and it's using within its own domain the exact same algorithm so it takes a bunch of transactions it generates blocks it then publishes those blocks on l1 in an l1 transaction and that's basically all there is to it okay thanks rick um i suspect what fred might be referring to is before the the first version of 1559 we had had um two transaction pools at the same time so within a single block you'd have basically two half the gas was dedicated to one five five nine in transactions half the gas dedicated to legacy transactions and so i suspect the question might have been um what kind of interactions do you expect to see there i see if we did that instead interesting so like would there be perverse incentives to [Music] you know yeah to like you have to because that it gets definitely more complicated for users can i decide you know which is better for you do you want to do one five five nine transact right right i actually do you want to try for a the gamble of legacy transaction or gas price you know right exactly my recollection is this is part of why correct me if i'm wrong but my sense was that this idea was set aside in favor of this kind of default interpretation of legacy transactions in part because that problem goes away is that right yeah that problem goes away and a couple others as well yeah so uh you know i mean it's not something i've thought about deeply but you know the latest transition plans that i've seen to me seem like a pretty smart approach are there any drawbacks with this automatic conversion so i'll have some comments on this transition but perhaps michelle can if i'm pronouncing your name correctly so michelle wrote a notebook on the transition period between 1559 and legacy transactions maybe you can share it now okay yeah sure um i guess sorry just before we go are there just uh like other areas of questions that people had about the report uh because i think yeah the legacy conversion and whatnot is a whole other uh can of worms uh and like yeah i think we can cover it right after but i just wanted to give this basic people have other other questions uh that they wanted to bring up about the uh economic analysis first yeah just one sorry go ahead um so i have one question i think it's particularly i mean slightly outside of the report but still very relevant so if we look only in the transaction market as something that exists by itself and the transaction value is always external there is no other market to to relate to it's all fine but what if we have a decentralized finance market where miners can can hatch the cost of uh of collusion like of the attack if they can actually benefit from the higher fee burning or the fees going down in particular we actually work on the project where miners would be able to make financial transactions where they would benefit if the fees go higher or lower and if they can actually make big bets on these then they can cover the cost of attack did you consider this kind of um correlation like a co coexistence of two markets the decentralized finance market and the transaction fee market yeah so not explicitly i mean what you know i find it quite interesting um and in particular i mean i think where it ties into the report is the discussion around um how to get minor buy-in into the proposal um and you know so you could argue you know to what extent is it necessary and then if you agree that it's necessary you can argue about how you might want to do it and so um you know i think you know having some kind of you know financial instruments so that you can argue that miners are going to win either way especially if it's something where like they're in a particular they're particularly well positioned maybe to make smart bets um on them you know you can imagine that um uh sort of speeding up uh sort of adoption um you know sort of lowering the the you know the the current sort of um pushback that that i i believe the community is seeing from minors great thank you when you were analyzing the uh sorry which is a section i had a question and i just lost it damn it someone else go yeah i would just like to make a brief comment i mean the the as the person who proposed the um two-stage um you know having two transaction types and two transaction pools uh the purpose of that was not game theoretic it was to force the removal of the dead code path of having one transaction type be interpreted two different ways just to clarify yeah there's also something else that may be worth noting uh i'll just brush it over quickly which is you can see the layer two transaction fee market interact in a similar way to this first proposal of two transaction pools because you can see it as part of the layer one gas being used and reserved for a separate transaction fee market so i think the interactions in those might be comparable but not with this new transition period scheme yeah that's an interesting idea i i mean that's a really interesting idea i think the difference is is that the um well i think there's two points and i'll i'll be say the nicer one first the let's say you're using you know the operator of the layer two whether that's a federation or an individual whatever they ultimately have some discretion right so they can they have within their protocol the ability to not participate in the next uh layer one block so i so it is it is a segmentation but the two different pools are under different authorities so that's a pretty big difference and then the sort of corollary to that is um 1559 doesn't stop the layer two operators from bribing miners which is probably what they'd end up doing practically speaking um there's one more question i think you already kind of answered this tim uh but nick johnson who's been one of the i guess friendliest critics of 1559 and really wanted to see a report uh he posted on twitter yesterday i'll share the actual tweet in the in the comments here and i'll try to just uh summarize his question um basically uh in section seven seven four five uh you explained that miners could make uh uh these cartels but it hasn't happened before um and he says uh this is probably not a sound way to think about it um and uh basically that the incentive structure is still the same under 1559 as it is now but it fails to consider the magnitude is very different today cartel benefits from the difference between monopoly monopoly pricing and market carrying price uh but under 1559 it would benefit the tune of the difference between the monopoly price and the cost price which is much larger um yeah so does i guess you mentioned earlier that the cost of collusion kind of stays the same but the benefit goes up uh i assume that would be kind of the same answer here to the next concern right so i tried to be careful on this point in the report maybe i mean maybe there's a way i could have written it that it would have been clearer but i guess i would point to the very first sentence of section seven four is when i start classifying different types of minor collusion the very first sentence of the section is you know i offer no prediction on whether there will be collusion under 1559. um so okay if i don't so then what do i do i just say let's let's sort of make a do an observational study of the status quo under first price auctions brainstorm possible reasons why we're not saying collusion and then assess to what it's you know and then you know for each of these you know apparent impediments to collusion do any of those impediments break down because of something specific to 1559 and i agree to know and you know if sort of in the top 10 takeaways uh you know it's number five right so so so the the assertion is not that collusion is as unlikely under 1559 than first price auctions i didn't say that i very intentionally didn't say that i just said the impediments are as strong okay meaning like the problem is as difficult as far as i can tell uh for miners to collude under 50 59 as it is now now that doesn't again i'm not saying that collusion is less likely for exactly the the reason that nixon mentions um which is that they might see either just because the economic reasons are more at stake or they may feel betrayed you know by the community and therefore sort of um you know less altruistic and so that's that's covered in the section 746. so right after the the or sorry in 76 i guess the caveat section um and you know there again uh there's a sentence that says you know this strong negative reaction i was referring to your your survey your questionnaire by uh tim uh this strong negative reaction may galvanize minors to sustain collusion to agree to a degree not yet seen under the status quo so so i i completely agree with nick's point um i tried to make that explicit in the report perhaps it should have been positioned a little differently so it was more so it sort of stood out more um but i actually don't think there's any disagreement there cool so this gets into this gets into the question i was going to ask which which is and i can just talk about instead um i think the magnitude is off by a pretty large margin here i believe because right now if miners were 251 percent collude they would make double the block reward plus plus transaction fees with one five five nine a fifty one percent collude can still make double the block reward and they get a little bit more transaction fees on top of that and while we have seen some big spikes in transaction fees periodically the baseline is still way below the block reward and so it's like you know if you conclude with 51 and you can make you know 100 million dollars or now with one 559 you include and make 101 million dollars and it's like i feel like that order of magnitude is nowhere near enough to tip the scales um just because like the the gains from including with for for colluding and manipulating one five five nine transactions are just so small compared to colluding just with any type of transaction mining just by censoring 49 of miners you double your money it's easy money right there so if you have if you can collude you can make way more money doing other things and so that's that's where i feel like the real argument here should be is that the order of magnitude is just too small okay yeah so i think you might well be right i guess i in the report i didn't want to presuppose how the base fee revenues would compare to the block reward um i just felt like that's fair unreasonable i thought any prediction i made on that point i might just look quite foolish you know a couple years from now um and right so i guess um maybe that was the main thing i wanted to say you know any other final questions for tim okay yeah thanks a lot tim for for sharing all this this was pretty helpful um and i'll make sure to link the report and and the notes that we have for this call yeah and and um so i'm gonna have to sign off but i mean just sort of a general comment i mean you know this was not like some report i envisioned just like you know issuing into the world and then you know never never discussing with anybody so i mean really a report i made you know the point of it is to be helpful to the ethereum community um and so if there's you know follow-up questions or anything that would that would make it more helpful um i'm obviously very receptive to that to that feedback and in future discussions so and what's the best way maybe for people who are watching the recording to reach out to you uh so email tim.roughgarden to gmail.

com great thank you very much thanks everyone um cool uh yeah so michelle i hope i'm getting your name right uh yeah do you want to go into your report around the legacy transaction simulations yeah sure so maybe i will try to make it uh quick just as i will give you the summary of what i did so maybe to start with what was the goal of this report of this simulation i created i wanted to answer the question uh how um legacy transactions uh will be treated versus 1559 transactions uh by the network uh when 1559 is in use i wanted to answer the question whether maybe the network will give preferential treatment to one type of transactions or other types so i created the simulation that is based on the library abm 5059 that was prepared by barnabe sorry if i also pronounced your name wrong i introduced some changes but i i use it this library heavily so um in my simulation uh i distinguish let's say three types of uh transactions so or maybe three types of users so we have uh pegasi users that for some reasons uh don't use 1559 and when this kind of users submit transactions these transactions have a gas gas premium or tip set to the same value as max fee then we have 1559 users that utilize 1559 but here i decided to distinguish let's say knife a user which always sets um a gas premium to the same value one way so he this kind of users do not analyze transaction pool to figure out what is the optimal the best value of gas premium and and we also have something i call clever 1559 users that look at the transaction pool and try to figure out the gas premium they should use in order to be included in the block as soon as it is possible ah i forgot to say that legacy legacy users also try to analyze a transaction poll in order to figure out the best gas price and in each iteration of the simulation i generate the same number of transact of legacy transactions and live transactions from knife users and transactions from these clever users and um what what is important i have when we look uh not the pairs but at the trio of transactions from each each of these three kinds of users they have the same value i mean a business value business value the user associates associates with given transaction why because we i want to compare let's say apples with apples if i have in the uh and i think that if i have the transaction a poll uh one legacy transaction one clever transaction when knife transaction with the same uh business value then i can i can compare compare them in the reasonable way and as to the conclusions and let's say the most important okay so firstly if you look uh i calculate a lot of statistics and metrics so i will only tell about the the basic ones but if we look at these statistics we can distinguish uh phase one and phase two by the phase one i mean a situation when a base fee uh very very quickly very dynamically grows and phase two when this basically reaches stabilized stabilization so uh in this first phase uh all these statistics i calculate like average gas price per block uh average waiting time and and many different they change uh very very very dynamically and it is quite even quite difficult to to to reason about this phase nonetheless this space is quite quite quite quite short and then we have this second phase when it is much easier to reason about the behavior of the network so uh according to my uh simulation and i think it is good good information when the base reaches reaches stabilization uh transactions from all all these three types of users will be included in the in the blocks so we don't have the situation that for example only legacy transactions are in blocks or only 8 15 59 transactions are in the block however in this first stage when a basically grows quickly here situation is is different because in this stage i observe that mainly or almost only this clever 1559 transactions are included in blocks what it means is that it also means that almost only this clever 1559 users uh will take advantage from the lower values of the base base basically um when it comes to the gas gas gas price uh here let's say um contagions are are not so surprising uh these knife 1559 users will pay the list why because they do not try to be clever they they simply always pay the same the same gas premium uh whereas uh clever 1559 users or legacy users who looks into transaction code who wants to pay more to be included in the blocks they pay as slightly slightly slightly more but if we compare legacy users and 15 59 users they more or less pay pay the same what else uh i implemented very simple uh transaction transaction transactions so i simply assume that i can have some maximum number of transactions in the transaction pool and when there is more more transactions i simply uh removed from the transaction for those uh divorce uh what i mean by by the worst i order i saw transactions based on the grass premium they offer to the to the miner so [Music] and what is important i observe evictions from the transaction pool almost only in this initial uh initial phase then when uh base fee reaches stabilization there are almost no uh there are no there are no evictions and transaction transaction pool is not full at all um what else [Music] one more thing but this is another conclusion let's say that is quite let's say natural not nothing surprising i also calculated a average uh waiting time of the transaction in the transaction pool so of course this knife 1559 transactions which always pay the same gas premium needs to wait uh needs to wait more than uh legacy or clever clever 1559 transactions to be included in the plot in the block however um i spotted one interesting thing uh though i cannot explain that now why it happened sometimes i observe that uh legacy transactions wait longer and sometimes i observe that this clever 1559 transactions waits longer than the transaction transaction transaction pool uh i need to analyze it my worker more carefully to explain why it happened okay so i think that those were the most those were the bullet points the most important conclusions i noticed if you have any questions feel free to ask hey um hi yeah i really enjoyed the notebook mission i think it was a really great use of the library actually and i've been gotten like to play around a bit with it uh since the start of the week so with fred we've been looking at how to let's say look at oracles that give like first price auction legacy users information about the current price that they should pay one piece of code that fred added was decided that users were using so let's say we are after the transition we have 1559 users legacy users and the legacy users are deciding their fees based on the oracles which is also kind of what you are doing in your in your notebook and so when when you have these oracles like the presence of a base fee even though it's implicit for the legacy users it has a sort of stabilizing effect on the oracle so let's say i have 50 of my users who are legacy and 50 of my users who are 15 59 you can think of it as some of the users know the correct price that's the 50 15 59 users and so since they know the correct price and that's the price they're putting in their transactions they're actually tilting the oracles toward giving that price for the legacy users so i think of it as almost like a the first price auction is this boiling pot of water and the 1559 users are just throwing cold water like lowering the temperature so allowing the legacy users to to almost like have a better let's say estimation of the current price in the market although it's a complete it's very implicit like it's not direct but it goes through the oracle and that may explain also why by the end when base fee is stabilizing you find that let's say legacy users and 1559 users are included in the block in almost equal proportion as they are when they join the market so yeah i think the idea that we had in mind was that since legacy transaction users would be overpaying uh they would tend to maybe have some sort of priority but that's no longer true let's say when base fee starts to stabilize because when that happens the oracles will start to sort of align themselves with the basically and provide to the legacy users the actual base fee and so so you should kind of expect this convergence i don't know if it makes sense and if it's maybe something that you you noted as well uh yeah i think that uh my simulation there is us totally confirmed what you just said and maybe just one comment uh what you what you said is uh totally true but if we only if we assume that this legacy legacy users will be will not uh will not overpay too much because uh at least in my simulation yeah uh le gas users uh ask oracle for the for the for for the best uh price but this uh oracle returns uh the minimal uh the the optimal the minimal price however if we have some legacy users who really want to pay a much more to be included in to be included in blocks then then then probably even if basically stabilizes we will see that i think that we will see more legacy users in box yeah actually it's true but it i don't think it's true to the magnitude that we expect so for instance some most of your records are based on some kind of percentile of the past transaction so you look at the it's a 95 percent top paying transaction and and you set the so like metamask when it gives you the fast price it's it's kind of like this very high percentile but if you have like base fee which is kind of stable and most of the transactions even some of the legacy users who are using the slow or medium who might be actually targeting the exact base speed it might start even let's say tilt the fast oracle so the one that would make you overpay uh towards the base fee itself again because it's sort of a distribution thing where because the fee variance is reduced in the block thanks to the basic you also have this effect that propagates to the to the oracle itself unless the oracle is some sort of fixed let's say i make you overpay by five good but i think most oracles are based on this idea of looking at the distribution of transactions and setting the price that means okay so maybe one more one more thing because it seems to me that we will see this uh stabilizing stabilization effect only if we have a big enough number of uh 1559 users uh users using the network so here of course it's only a guessing the question is how it will look in practice if we have uh let's say 80 90 percent of the gas users and only 10 of 1559 users uh i think that it wouldn't look so nice when we have 50 percent of of of the gas users and 50 of uh 5059 users yeah so sorry i would just like to comment on that um yeah i think that's an extremely good point and i think to me i mean i really appreciate all this research and i think it's really interesting fascinating work as a practical matter if collectively the community can do something to ensure that 1559 gets adopted by someone like say metamask then we a lot of this simulation we don't really have to worry about these corner cases right we just know that the majority of people will use 1559. i was just going to add i think uh we had a bunch of discussions about this in the past as well but like we can start with this you know neutral approach of like reaching out to folks there is uh already i think a lot of support for 1559 in the community so you know step one is like you reach out to folks like metamask um like you know coinbase what not ask them to support this um and then step two is like if that doesn't work in the next hard fork do you want to add like a carrot or a stick right with regards to gas prices or whatnot um but i think it's yeah it's it's hard to predict in advance what the adoption rate will be um and therefore to come up with like a good uh a good plan for like how do you get the people who you would have wanted to adopt it that are not adopting it to actually do so also i do think that they are self stabilizing incentives in the sense that the less stable the base fee behaves just because fewer people have adopted one who have nine so far the more incentive there is to actually uh adopt um one for like move to one of nine transactions as an individual user just because like again with one with legacy transactions you tend to overpay or just general it's it's less controllable and so basically like the the few people are using 129 the more like attractive is for individuals to move over to like profit from the like increased stability locally and so i would assume that like it very quickly kind of would converge to a situation where enough people moved over that the overall situation becomes relatively stable at least under most times yeah but but of course that's that's hard to tell that's a really good point and i think what's interesting is a lot of the projects we spoke to as part of the outreach um that were managing transactions on the behalf of their users really care about giving their users the best price and the best ux so if there is kind of an incentive to do so um i suspect we'll see you know a lot of projects wanting to differentiate by adding that um so another consequence with this insight that your records converge is that the more 1559 users you have the easier it is for legacy users to keep using the legacy transaction like the less they would overpay because the better their oracles would kind of tend to become so bouncing on what rick said if you get the 80 users by having metamasks switch to 1559 then this long tail of users who are not switching is actually not that bad for them uh they get a somewhat correct rate still you have like of course it's kind of a gradient between if everybody is using first price auction versus everybody is using 1559 but uh yeah if most users are 15 59 users then i guess from a legacy user perspective you might not be overpaying that much either and i think that's not the end of the world right like the the direction we're going to we're going in at the protocol right now is like if we have support for these 29 30 transaction these 15 transactions the legacy transactions i suspect will have to carry a bunch of different transaction types for a while um so i don't think so i think there's maybe a more meta discussion about like how do we deal with this long tail of like older transaction versions and that's kind of out of scope for 1559 and if we have some reasonable you know intuitions that there are good incentives for a large portion of the network to adopt it um i think that's probably sufficient given uh yeah that we still have to maintain some types of legacy transactions anyways due to other reasons that actually leads me to a question i was having earlier so um in case that that transition like the initial uh the transition to 1559 uh goes smoothly and like there's a lot of adoption early on and a lot of people earlier basically talked about transition periods that would imply that there's like some end of the period but then presumably you would completely phase out legacy transactions i'm just one i mean you you're basically just saying that that might not be like unnecessary at least like immediately or something i was wondering is there even is there any like important reason why you would ever want to fully phase out legacy transactions instead of just continuously converting them forever because i mean there are always these edge cases maybe someone is using some hardware wallet where they really don't have a way of generating transaction types or something the short answer is client code complexity um and and the way i i guess the scenario under which it would be very helpful is if you have clients that don't want to sync for from genesis for a reason um so you know some people have talked about like regenesis things like that but maybe a more possible or concrete thing is like assume there's the e2 merge right maybe people want to write clients to be like an one engine for e2 but not sync everything since it wants genesis just like start processing stuff at the merge block um then if if you got to a point there where say i don't know legacy transactions are not supported anymore they just don't have to implement that and it makes the client much easier to do that so i think that's the main argument in favor but when you talk with teams like guess or you know other client teams that need to support clients from genesis it doesn't really make a big difference that you know say to us on basically if we deprecate 59 transactions or not because we still need to validate all the blocks where there were legacy transactions so that means we need to keep that code in the client as well um but i think that yeah the biggest benefit is you could build a client from the spot where you don't process those transactions anymore yeah i mean at the time my thinking was that um there would just be potentially a lot of complex dynamics by keeping this old by having two transaction types that are possible and i just thought it was really difficult to reason about i was having a very difficult time figuring out which one you know what would happen and so it's better to just like close that that door both from like an engineering perspective but as as tim points out uh that kind of doesn't work because you have to replay from genesis but then also to sort of close that door in terms of like uh you know economic exploitation one can also mention a a client that has so for each time there's a fork block the consensus rules change one can imagine a client architecture where you have a separate engine for each uh fork and so it'd be nice if your new engines don't have to speak but you don't touch them it's like you know your version one you don't touch it you maybe get security updates but that's it whereas you don't want your v1 code sitting in your v7 code code base which may be completely isolated again depending on your architecture i suspect in practice though given the current clients that exist and teams working on them nothing like that will happen before an eth wanted to merge i happy to be proven wrong but yeah my hunch is uh this is the only kind of point at which it makes sense to change the architecture so much to get there um this is a bit of a tangent though um yeah did people have any other questions about the legacy transaction simulations if not um yeah uh andscar i think you had some uh updates you wanted to share about the transaction pool management which we spent a bunch of time talking on uh talking about on the last call sure yeah um and uh uh so so this is just for context i haven't been following so i've been following the one the 1559 efforts like loosely but but not i have i haven't like joined most of the um previous implemented score and everything so so i might not be fully up to speed but um uh basically like to make the quilting we we talked like uh i think two weeks ago or something and and he mentioned this kind of that there were some open implementation questions around mental handling and so we kind of decided to look into that a little bit and so i basically wrote up some of my thoughts around specifically the sorting because i think most of the mempool related um questions um like how to handle what 1559 transactions differently from from mexican sections really boil down to to to um sorting and so so my like basically um initial conclusions and again those those could be off i'm i'm not i would definitely not yet an expert or anything but but it appears to me that there's really basically two different types of sorting that usually happens in memphis the first one is just for miners that's like basically they're on the high end of transactions choosing having an efficient way of finding the currently like highest paying transactions and of course highest paying meaning like at those that that basically had the highest effective tip um um and and currently of course you just use the gas price for that um and so currently for example in in in depth the way that's implemented is with like a max heap where you basically have like a partially sorted list but by maximum gas price and you just traverse that to find the highest paying transactions um and that doesn't quite work for 1559 because um unfortunately like uh like of course um i had these little diagrams and of course the observation i think is an old one that was 1559 the relative order transaction came can change when the base fee changes because because of this these two parameters so sometimes so basically like um for for low base base fees usually transactions are the static period where they they basically pay their maximum tip that they they're willing to pay but then at some point they reach this this kind of inflection point where where the base basically becomes so high that they that it starts eating into the tip they are still willing to pay and so and so for different transactions that point is at a different location and so when um it can be that that the transaction that was willing to pay to have to pay to pay a higher tip that that now goes down and now basically all of a sudden is willing to pay less than another transaction and so so the right of other kinds can switch and so you can't have like a static um sorted uh data structure anymore and however like i think specifically for for the for the question of of mining it it seems to me that you can you can kind of find a somewhat more clever but but not all that much more complex way of going about it so so the main observation that i had was basically that within this kind of what i'm called it's called a static state where like you're you're able to pay your full tip right and transactions that are all currently willing to able to pay their full tip those those could continue to have a static order because while they are in this static range of course that's a static amount so that's a that's that the ordering stays constant and then within the like the declining phase where your tip is being eaten into by the base you basically transactions within that also because because it's like a linear one to one relationship like basically one walkway in the base piece one less way in your tip and so that also basically means that they all shift in the same speed and so so they never intersect so so transactions in that state also never kind of switch order and so it's really just about transaction square where they basically switch between those two two two states and so i think what you can do is basically just have a somewhat a little bit basically you can you can have like a once partially sorted heap for for the static transactions one for the for the dynamic transactions there are a few questions though that i haven't really that don't i don't think i have quite the answers yet so basically what you'd have to do every time a new block comes in that changes basically you have to kind of process the ones that that now pass they are like inflection point there and now switch between the two states and it's not quite clear how you could effectively remove them from because because you you don't actually want to to do a lot of of removal from these heaps so there are a few intricacies but i think generally directionally this is like a really solvable problem and then and interestingly though like the other sorting problem in mempool is on the other side right not the height page transactions and that's only for a minor problem but like for eviction right and then there you need you want to find the the the basically bottom tier transactions to to get rid of um and this is it like it seems to me to be a little bit more complicated because um on our legacy transactions you again just use the the guest price but what you're kind of optimizing for is you want to get rid of the transactions that have the lowest chance of being included right because those are the ones you you want to drop and previously with the like static order and everything that is a very simple decision to make you just look at the guest price now with 1559 again with like the the the dynamic order they can they can shift over time it's not clear anymore right just because the transaction right now would be willing to would have like a lower effective tip than another one doesn't mean that it has like a lower chance of inclusion because maybe as soon as the best base fee goes a little bit higher than the transaction all of a sudden is is willing to pay more or something so so you kind of have to have like as implicit assumptions about base fee behaviors so basically what you the the metric you would want to use is like the like the the uh average uh base or like the the the average base the average effective tip um uh that that you expect like the expected expected value of of of the of the um effective tip that of the transaction over like all over like a probability distribution of of future base fees and of course you don't want to do it are they complicated so the question is just um can you find like a simple heuristic that that does something of that sort that is good enough i mean you don't for eviction you don't really care if it's like an intellectually completely perfect solution it really just has to be practical enough but it has to be practical enough under like a lot of different paradigms so slowly changing base fee like quickly quickly increasing one quickly falling highly volatile low volatility all of these different paradigms so basically the goal just is fine find a heuristic that is like really robust and all these paradigms um but then also you can implement with some efficient data structure where you don't like not you what you don't want to do is basically every single time a new blog comes in you don't want to go through your whole mempool recalculate this effect this is expected value for every single transaction and completely resourcement that that is too much i think at least that is too much housekeeping effort uh after every single block and so basically finding some heuristic that you can you can find some order that you only have to update slightly every single block or something i don't know i i have like i don't really have good good like concrete ideas around that yet i think it's it seems like that should also be kind of solvable though um but it's it's a little bit more of a complex issue so so these are basically like my my thoughts on sorting so there's maybe one more special case of like transaction replacement but i think transaction replacement really is not all that complex because they are you really only want it to be predictable by the user because transaction replacement where you just replace the transaction pending transaction because it's you you want to bump it basically uh i think you can just have very simple rules that protect you against doors um um issues but also kind of keep this this the structure something but but yeah basically so so i don't know maybe i'm not sure if it was clear or something and again i might have been missing things or just previous write-ups or whatever on that topic but that's my rough outline so like high-end for minor is low and for for eviction for all nodes and high end you want an explicit solution low end just some heuristic that's good enough that's kind of where i'm at right now i i like that analysis uh thanks a lot i i just i do have one question which maybe i also not being in every meeting missed something but um when you're talking about re evicting transactions isn't there a velocity like isn't there a maximum rate of change of the base fee such that you could say like it would be a week before this transaction could be included or a day or there's some uh longer bound where you know that the velocity of uh base fee changes would certainly exclude a transaction from a reasonable amount of time yes there is i personally advocate for using a strategy like that the caveat you have we have to remember though is that in a time of rapidly increasing base fee it is possible to see the transaction pool filled entirely with transactions that meet that criteria so even if you say that evict any transaction that cannot be included in the next block it is still possible to have a transaction pool that is entirely filled with transactions that meet that criteria and you still need to evict so you still need a secondary eviction strategy in that case um to deal with that situation at the least yeah so so i would would agree that basically like a simple yes no rule always runs into these edge cases where you can construct a situation where it's basically very close but but you still just be below whatever base fee they need or something and um so some some just some some relative metric where you have like one value per transaction that you can assign and then just compare and and they and evict those with with the lowest value um i think i think that is uh preferable but i do think that it it illustrates how while there is like again there's some uncertainty where transaction order can flip there's still a lot of structure in that like it can only flip to a limited extent because the base fee can only change at a certain rate and all of these things so i think you still have you can still come up with sorting that is mostly stable but they kind of when once the base which starts to change it only changes a little bit and so you you can you basically only have to to do a little bit of kind of updating of your sorting there um but yeah but yeah the goal really should just be to be able to to to identify the worst transactions no matter like how close they are to being includable or how how far away or of that so another thing that light client brought up last week or week before is that if we can get if we change the the minor bribe or tip or whatever one of the client this week to be static not that i'm willing to pay this much base fee up to this much base fee and i'm willing to pay this much to the minor and those two are separate values and so the total you pay is the sum of the base fee plus the miner um that greatly simplifies the transaction sorting problem but it introduces a new problem that it greatly increases the complexity of upgrading legacy transactions to this new transaction type so if when people are thinking about this problem if you can solve that problem the upgrade how do we upgrade legacy transactions when the the tip or the minor bribe or gas premium whatever you call it is static then this whole problem of transaction sorting goes away and we're back to basically legacy style very simple sort i do have to say though um because because lifetime and i we we talked about that um quite a bit after that and the impression that i got and and of course um if it could correct me there but the impression that i got there is that that is not indeed actually correct because it turns out you still you you because like for with these decisions you still want to do this kind of things like that the chance of inclusion or something and just because now it's a cliff so basically you have a hard drop off that still kind of gives you the property that there's like a non-static order but basically because because there can be transactions that is um like more more easy it's basically higher paying for a long time and then it just instead of gradually dropping off it just immediately just drops off to like a inclusion chance of zero basically but but it still has this this property that you can have in intersections between the the kind of the the relative value of two transactions and so it's not in fact that it now all of a sudden basically it's a static order again uh you still have the property that that basically order all this dynamic and flips and so you kind of have to do this expected value thing so i personally don't actually think that this is that that this is that that basically gets rid of the of the problem so micah you were saying that uh the problem is the promotion yeah that's fair i do think you are correct can you guys hear me can you guys hear me yeah go ahead um micah you were saying that the problem of promoting the legacy transaction types under that suggestion that you had is because there's now just this static fee that does it there's no basically item that depends on a per gas basis right it just doesn't fit with the model we have for upgrades so for upgrades the the model we have right now of course is we just say the legacy transaction gas price is both the base fee and the minor bribe both values are the same thing and everything kind of just works out magically if the these two values were if sorry the fee cap and the minor bribe if the minor bribe and fee cap are now separate and so they're additive onto each other so the the thing you pay is now base fee plus minor bribe we can no longer just set the fee cap and the miner bribe to the legacy transactions uh gas price that doesn't work i've forgotten but um i would also argue that it the one other major drawback that that solution has um is basically that you have this um just the like the the behavior again of like basically your transaction is willing to pay a certain tip and then as soon as what under like the dynamic approach uh basically usually you would have this this inflection point and then you the tip you're willing to pay it slowly degrades but you can still be included in the blog whereas under the new proposal basically you could at that point you could just not no longer be included and so from you like from a ux um point of view i think it is also a little bit problematic that now you could have transactions that are like like price-wise perfectly able to get included but they can't because of this this rule so so sorry so i'm personally a little bit skeptical of this approach sorry something my thoughts are [Music] so i guess just to make sure i'll go ahead no no i didn't want to say it but it is like a very interesting like alternative approach to think about because i think i think if i remember correctly that was actually the one that kind of when when like client and i were talking about it it's um that was the one that that kind of led us to realize that um basically within these different stages uh you still have the the the static order so so that definitely like a very interesting kind of um thought experiment but it i don't personally like it as an actual design and so just so i understand it seems like the next step here on the eviction side is finding is there a good enough heuristic that we could use which might have some failure modes but uh that should should work most of the time is that right uh yeah that's how i would at least see it got it i think the most important thing is that we do not have a failure mode that results in a dos factor against clients for the eviction strategy pretty much anything else is almost anything else is optional um that being said there are like if you are the worst case eviction strategy is you're evicting from the the most likely transactions to be included right it's like the pathological failure mode um if you imagine that then that can become a dos vector because now clients are constantly dropping transactions that then they'd have to get fetch again as soon as they get included into the next block and so we do have to be careful about that but that's really the the core is don't allow eos attacks um any of this get easier to solve i remember hearing forgive me because it's my first 1559 call but i remember hearing rumblings about um potentially enforcing at the protocol level that blocks are filled first at eip 1559 transactions does that solve any of this because you only have to relatively order them like only order 1559 transactions among themselves and then legacy among themselves the problem is that even within 1559 transactions if you don't don't like uh have any of these of these legacy converter transactions in there i think within that block you still have similar issues at least maybe it's easier when like most of the tip is some somewhat in like a similar range or something but i think so like of course for the legacy side of things it would make things easier because then you have the same properties again but i don't i i don't see at least why that would um solve the the issue on the 159 side um maybe it would make it a little bit easier i'm not sure so what if you add also the static miner fee instead of the per gas miner fee and now can you deterministically sort those the 1559 pool you're saying have two transaction pools one that is legacy transactions that are that once they're included in a block they look like one five five nine transactions but um the second pool is actual one five five turns nine transactions but they have the static gas price is that gas premium is that correct i understand uh no i was suggesting or well maybe but uh so i was suggesting that we have the 1559 transactions with you know the fixed uh the fixed tip and then you we just have legacy transactions as they always were in a different transaction pool except they can only be included in a block after a 1559 transaction oh they can only fill up empty space basically yeah and so there and so there like you can evict them however however you want if there's or you can evict all of them if there's only 15 59 transactions and then the 1559 transactions as they are now also would have the sorting problem i think because of the per gas so i don't know that we can have we can have the elastic because i don't know if we can have them be a la that's the second pool be elastic because we don't know if we should like as long as you send out a block that has 1559 transactions first that is that is valid don't know if we should yeah expand the block so if the block is under full like less than it's you're really breaking up nika yeah i think you would in effect just expand the block one block late and i i think um expanding the uh i think having the 1559 take up all of the um block and then have the uh uh original transaction type take up the remainder and then if that was full expand the block um that i think is a really weird game where it makes sense to like do all sorts of weird stuffing and price manipulation because now you can control the size of the block in this kind of counter-intuitive way it i don't know that that all of all those games are worth the the algorithm uh benefit that you're aiming for okay cool yeah i just remember hearing this as a suggestion but i never heard kind of the counter argument to why it wouldn't work but that makes sense um yeah just because we're running low on time and we still have a couple other things to cover is there anything else uh regarding this that people really wanted to bring up now okay if not i think yeah the last big thing we had uh is abdel has made some progress on generating uh test nets with a large state um adult you want to take a few minutes to kind of share that yes sure so we want to see how the network would work with the high block elasticity like can the network handle twice the block size as now and uh to that the first approach was to kind of fork mainnet but we don't really like this approach because it implies to do some tricky things in the code of the ethereum clients and we don't want to merge that code because we don't want to introduce new attack vector so we wanted to explore another approach uh which is to have uh basically to not touch uh at all uh ethereum clients and to have uh another standalone service that interacts with the clients and to see how quickly we could generate a state comparable to mainnet so we implemented the proof of concept for this service so i will show you so can you see my screen yeah yes okay so basically we have a standalone service that will interact with the theorem client using the rpc endpoint and we have a few rest api so basically api to handle tasks because it is all long running processes so we need a way to on the client side to to see if the task is completed and the duration of the time of the task etc and then basically we only require to have two deployed smart contracts so one to create accounts and one to fill the storage basically uh so the first version we were to create account we were only doing uh basic transfers so without using a smart contract but it requires to handle a large tps and this is more efficient to to create a bunch of accounts per transaction so this is why we create the account directly in the smart contract and also you can monitor the number of accounts created and also yeah we have the other contract that is responsible to fill the state storage and yeah basically i will show you a quick demo so first i i start one ethereum client with a very low difficulty to quickly produce blocks okay and then i start my standalone service that has the rpc endpoint of my ethereum client and we have a web application so uh yeah basically it connects to the ethereum client and it retrieves some configuration parameter so for the moment i don't have anything deployed because i just deployed the network from scratch so the first thing will be to deploy the two contracts required okay the second one and now if i go to the configuration i can see the addresses of the deployed contract and uh some parameters directly queried from the smart contract so i have not created anything from the moment so i will start let's say by creating 10 000 accounts and 15 000 entries in the smart contract okay so task out pending let's wait few seconds okay the configuration is done and the state storage is done as well and if i clear again my smart contract i can see that 10 000 accounts have been created and 15 000 entries have been created in the smart contract and i also have the address the last created address and to show you some results so basically we tried several iterations we started from 10k accounts and 10k entries into the smart contract and between each iteration we multiply it by 10 and we have measured as the time needed to uh build the state and so the last iteration was 100 100 million so this is something comparable to mainnet and it took basically four days to to build this large state so they the two processes have been done sequentially uh next step will be to try uh that in parallel and obviously we did some tests with a single node network and if the approach sounds reasonable for you guys one next step will be to set up a new 1559 test net and to kind of build a large state comparable to mainnet and i think so we'll have to deploy multiple clients on each type bezou netermind get and uh i think we should try to run this service on all clients directly rather than building the state and then sync with the other clients that will be more efficient to make sure we all deploy our clients to the infrastructure and then we start to generate the state and with hopefully within four days or so we could be able to have something comparable to mainnet and then we could start to uh play with the the high block elasticity because we did some tests with the high block elasticity on the current test net but the state is very small so we don't see the impact on the large state and we started to measure the evolution of the block production time versus the number of accounts so it does have a significant impact actually so it will be interesting to see how it will work with a large block elasticity and yeah that's pretty much it that's really impressive i just have a quick question after you've generated that spent the four days to compute that state let's see i'm sorry it doesn't seem to say the size uh the size of the db yeah it's something like i will show you 237 gigs so does it make sense to create a backup of that for the respective clients so you can run more tests or do you just want to destroy it my plan was to destroy it and origin regenerate something from scratch using the tool because the time needed is quite reasonable i guess less than a week is i don't know and these didn't use 1559 transactions no right yeah exactly so we should probably have one yeah yeah i think we just did it with a legacy but we should probably have i agree with you rick that like once we do it with 15 59 star transactions yeah we should keep that and not have everybody else need to run a four day process every time it it does not really matter i mean to fill the network we don't need to use 1559 transactions because most of the work is done in the smart contract anyway so that won't affect the results yeah oh i guess yeah what we want is we want the network once we have the large state we want whatever network to be able yeah so yeah okay so we could use that yeah yeah put that in like a set of clients that support 1559 and then run the transaction generator tool right yeah okay so i guess in that case we probably should not delete it now we probably should okay okay okay so yeah first i wanted to see if the approach makes sense for you and then we can see the next steps so this is uh this is to check if the if the clients can handle the the load at the level of the maintenance right yeah yeah yeah so with the two uh yeah with twice the block size uh of the main net yeah so you um to generate like 100 million accounts because mainnet is 100 million accounts yeah yeah and then there's also a smart contract which has 100 million storage slots yeah with 20 bytes per slot yeah um we're almost out of time i know right you had uh you wanted to bring up 27 18. do you think you can do that in like one minute or two yeah i think if someone has arguments against it then we won't and it'll go somewhere else but i'm hoping that it will just push through quickly so essentially since the writing is on the wall 2718 is going to be in berlin and the whole point is to introduce transaction types is everyone good with um having eip 1559 transactions be a 2017-18 transaction and we can just you know temporarily pick a value of like 15 for it and then pick a um what's it called like an incremental value once it's actually about to go into a hard fork i guess my question would be yeah this no good how much time like does it slow down people right now to add 2718 support or or not because we're already doing it as part of berlin right um yeah i was gonna say that i think all the clients have it now and so it would actually just simplify the encoding decoding code paths to just have that be a type rami can you say yes if you have merged the master branch because i think so i'm not sure the the merge the master brush yeah so actually we almost completed uh so we just need a couple of more hours so today we are going to create pull request on the uh original kf repo and would you be confident to use 2718 type transaction envelope for a 1559 transaction have you looked at it or uh no not yet so we are basing on top of master so that uh transaction type request is not merged yet right okay so maybe it makes sense you have to wait until it's part of the get code base like it's actually merged into get uh i don't know what the stylus is um and and then set a transaction type and i assume we can kind of figure out async what we want the transaction number to be um yeah because i guess i wouldn't want to slow down the stuff on like the large state test net if like it'll take a while to get it merged and get and and uh um and to then be yeah then we need to update the 59 implementation of death and what not uh does that make sense sure makes sense one get once get goes in then we can switch it to 2017-18 yeah and i guess we're kind of out of time but the final thing i wanted to see is like when does it make sense to have a follow-up call it feels like we have a lot of like parallel threads um so should we have like you know breakout rooms for any of them does it make sense to just have maybe a call in two weeks instead of a month so that we can follow up async and kind of share updates in two weeks um what do people feel will be like the most productive i think i think generally we should actually start planning the roads to road to testnets and to release like so we should actually transition to the stage when we plan how to how to move it to mainnet instead of just uh analyzing it anymore it's like overwhelming proof lots of different research cases that show that it's very solid probably like this few slightly risky points that were mentioned in uh yeah in the recent report but apart from that it would be great to start planning how to go to mainnet all the way so have the roadmap what's the first target date that we have for the release and how we get there uh when the clients join what are the acceptance points like hours from our perspective from all the clients when we say okay we are ready and that would be great yeah i agree with you it seems to me like from a research slide it's pretty de-risked the only two outstanding issues seem to be um figuring out this transaction pool sorting which is not uh you know it's not rocket science it just has to be done and then maybe looking at the update rule um but that's also pretty minor um i think with regards to awkward devs wailing until like berlin is out or at least you know kind of finalized probably makes sense before bringing it up there um so maybe i i can definitely work on putting together a roadmap over the next two weeks um maybe it just makes sense yeah to follow up then to see how the work on the test net is progressing and if we have a solution for the for the transaction pool stuff um and then how do we want to bring it the awkward abs basically after the holidays yeah i generally think that we we should totally decouple it from the berlin conversation it will be much much better for the working group because uh i i still make this bad that is like 10 chance that this will happen before berlin oh got it okay one last maybe a little aspect that i wanted to mention there is i think it might also make sense to start talking a little bit about like general timeline for for for like ethereum mainnet because i i think like starting maybe a year from now or something there'll be like a lot of these big changes with like the merge and maybe statelessness and so on and you get like a sun feeling right because i would really hope that 159 might might be able to just go in maybe like summer slash autumn or something so so that we can steer clear of all of those because otherwise it might be a delay of over here additionally just because why are these yeah higher priority things i agree that was always my goal is to get 15 59 chip before stateless because otherwise having the two kind of come in at the same time is is is pretty bad um yeah but then now also with the accelerated merge time that might also yeah yeah yeah yeah i agree so i guess yeah sorry we're already a bit over time this are people fine having another call in two weeks and doing stuff async until then and using that call maybe to do a bit more of the planning at least i can share a first draft of the planning of like what i think makes sense to bring to all core devs and uh and we can also follow up on the various kind of transaction pool and other issues okay i'll thanks i'll take uh this as a yes um thanks a lot everybody this this was great uh i'll try to upload it to youtube later today thanks bye thanks thank you thank you thank you everyone so so much bye