# EIP-1559 Implementers' Call 9

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2021-10-09
- Duration: 1:12:52
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-KllIW2hqw2I
- YouTube: https://www.youtube.com/watch?v=KllIW2hqw2I

## Description

https://github.com/ethereum/pm/issues/234

## Transcript

okay we are recording um so hey everybody uh this is eip 1559 call number nine uh which feels like a lot um so i shared the agenda in the chat we have a couple of things to go over today a few updates from different folks um and then going over kind of the large state test net testing um and yeah that should uh that should be it um [Music] i know uh ansgar i see you're on the call and i think you had to head out early so do you want to start with your updates wait i'm i i don't think i fit out early i think yeah that must must have been someone else so oh but i'm sure to go first but it sounds like maybe someone else has to to to to leave early or something does anyone else do just go ahead and dan's car um yeah i i mentioned it to tim oh okay oh just okay yeah but go ahead okay okay okay i i think that might have been a scheduling conflict but i kind of moved the other the other thing so but the things okay so sorry and no but but yeah i can i can i can go ahead so um basically uh i i linked like a little document again that's that was kind of the the follow-up of the previous one i had maybe two months ago so i think maybe we are roughly two months ago um exactly that that's that's the new one i think that yesterday i'm not sure maybe it was a little bit late if if people had the chance to to have a look but basically so i've been thinking a little bit more about uh quite a bit more about like specifically the sorting aspect or like the sorting aspect in in clients for 15 59 transactions um and in basically um as it said in the tldr in the beginning so basically when i first started thinking about it it just because i didn't really have a lot of background in 5059 it looked very much just like you now you have two parameters right the the the maximum total vcap and the the maximum minor bribe and and basically now you have to sort like in this two-dimensional space and and with all the complexities that came came from that and kind of re-evaluation every block and everything but the more i kind of uh looked into it to me it seems more like that it's really mostly about understanding kind of the the very specific structure of how of like how 1559 will will affect to transactions and kind of optimizing the client around that so so what i mean by that is basically um if we look at at like the mempool under 1559 in in like a normal situation where it's not not one of these um extreme demand spikes that might might be the rare um kind of um exception to these normal uh situations but but like in any normal situation you usually only have like a handful of includable transactions right includable transaction mean means that the um the fee cap of the transaction is above the current base fee and the reason why you only have a few is basically mostly by definition right because with 59 in the steady state blocks are on average just the the target size so so they they like they might be a little bit over a little bit under but but like on average that they they only target size and miners like always include as many transactions as they can up to like twice the size so so the fact that this blocks in the steady state are only like the the like one time the target size basically already indicates that on average a miner that creates a new block only has enough transactions to fill like one time this the the target size basically and so in in the mempool base of course um that means that usually like the vast majority of transactions are actually like not includable at the current price and and which is probably like a very trivial observation but but it took me a while to to to fully like like um get there and understand implications because um it actually has a couple of implications so so i think the more obvious part is for mining so of course for mining you only care about the currently includable transactions you don't care about what might be in a couple blocks you're mining account block and you need the transactions that are includable at the current block and so basically what that means is that the mempool ideally should have um a way of only giving you the currently includable transactions um and then i initially was concerned with really like designing a a as like a really an optimal algorithm from for managing like a partially sorted structure that gives always gives you the highest paying transactions but um and i i think i outlined um a design for that in the last document and then this i'm not sure if if um he or she or if they are on like um on this call the min me now the the user like they they kind of took this this approach and and um uh kind of uh implemented um like a like an example uh sorting mechanism there um which which was awesome to see yeah exactly this one um but uh basically the i think the main insight though on on that specific topic is that this is probably an optimization that is um not not maybe not necessary at all or at least not necessarily in the beginning because what miners already do today at least uh at least like well on the guest i'm most familiar with the gathminer but but what the gatman already does is they get like a complete list of all pending transactions which and i can't like before 1559 that's that can be thousands of transactions and they sort all like they they basically sort them once per second or like i think the default this one's put three three seconds or something and then they discard that and and completely resort every three seconds so basically um they're doing much more already than they'll have to do under 1559 so under 5059 the kind of the the effort for the miner only goes down and so we can always still kind of optimize but it seems like this is really like a very simple simple thing um and um and then the main change that i think is actually most worth talking about for from for miner then is is not even the sorting itself but actually the how do you handle the stream of incoming transactions because right now what the miners usually do is um they basically create a block and then they well they start mining on an empty block just to be to be able to start hashing immediately but then as soon as they have created a block they start my switch over to that and mine on top of that block and then again with this interval like once every second once i think the default is three seconds but you can you can ramp it up to once every second and they basically create a completely new block right because it might there might have been new transactions coming in since then so they create a completely new block that and once that's done they again switch on to mine on top of that and of course you can do the naive thing and just do the exact same thing under 5059 as well but if you look at what again the specifics of 50 59 you usually like as soon as a blog comes in that from outside that you want to mine on top of or like that you want to mine the next one for for the chain and that that will probably already use up most of your includable transactions so you'll start out as a miner with like only maybe maybe zero maybe like a very small amount of transactions to include in the block immediately and then over time while you're mining and you haven't yet found a block new transactions will come streaming in and so then on average i don't know let's say every 12 seconds or whatever the average for non non-empty blocks will uh the mining effort will be on average it will take you 12 seconds to to to collect enough transactions for one normally full block and then after maybe 24 again if just like very simply spoken but like after 24 seconds you'll finally hit the the cap and you your block is like full actually for twice the size and so basically what you ideally want to do is you will want to just like immediately as soon as a new transaction comes in just append it to the block you're already mining on top of and then maybe still once every second every three seconds or something you can do like a re-org where you resort them in some other like by some other metric which isn't doesn't really matter for the miner but maybe for the network as a whole it's nice if if if they mostly kind of prioritize higher paying transactions even within the block still or something but basically there's a pen there's immediate append action that's not done currently in geth and that's something that i would propose to that that should probably already be done as part of like the the initial 1559 implementation but it's even that even that part of optim optimization there is optional and then again for the broader sorting side for mining it's it's really simple i i would say um before maybe before i go to the other big topic the eviction um does it make sense so far is that do i maybe have something backwards there also uh i think that'll make sense the one thing i would say is i think uh first in first out is actually slightly healthier for the network than um price based if there's no um contention and so my vote would be is until the block is actually full don't bother resorting the transactions like we have if we have no need to to do it like it doesn't help the network really i don't think to sort by guest price because i just think encourages more gas price auction stuff whereas if we're doing fifo most of the time gas price elections become much harder and much less profitable which is kind of good because cash price auctions are not the healthiest thing they're a thing that we deal with because we have to but it'd be nice if they just kind of went away and so um my vote would be if if you don't have a full block just do first and first step and like you said just depend only until your block is full then once the block is full then decide you know okay what am i going to kick out of the block and then i have to rebuild it and then at that point sporting might be the easiest way in which case sure go ahead and sort but my hope is is that if most blocks are not 2x full then we can do basically fifo miners still gets all their payday and we don't uh encourage this behavior of people hammering the network with um gas price wars basically yeah and of course i mean that this is a little bit tricky because um for miners these guest wars might actually be still be prefer like um it's beneficial because that drives up the the mine upright um but i think at least right right right we still need the functionality of the resorting as you were saying as to use as soon as we reach the the actual 22x cap um so i think it probably wouldn't hurt to at least expose it to minor so they can optionally switch and do that immediately or something but but yeah i i i think at least the simplest approach would really just be first in first out until you reach the 2x cup but i i would say this is this can probably be left left to the to the individual client devs to just make the decision on um yeah i think um just to build slightly on that i think that i think most importantly is if we have geth do person first out until two expo and other clients do slightly better sorting it would encourage more client diversity in minors so basically it's kind of like almost make not quite as good as the other miners because and also make it so get doesn't do as much work um to encourage people to switch to another mind open ethereum so like never mind open ethereum go and make a better sorting algorithm gives miners you know slightly better money then um it'll encourage people to switch to another mines off of gas which i think we generally want we want more client diversity and minors i believe yeah i mean i i i can see the point there i just want to be just basically two two to give like the kind of the counter argument that i gave in the discord as well um but but um i'm personally open on this question but but i would just say i'm given that 1559 is already like a somewhat um disruptive well not i think disruptive kind of over over um emphasizes it but like it is at least like a significant change for for minors already um so i think it would probably be best to kind of keep keep the changes or yeah that the changes um um to the minimum necessary to to to support the the the switch to 1559. so so th this is why i might uh think that that maybe change changing this might be something we should rather push than for it on its own instead of as like part of the of the overall 1559 implementation but i'm yeah i don't really personally um have a have a strong opinion there okay but but yeah so i think that this is like a in in general this kind of summarizes the um minor side um of that quite well i also like i i talked with um gary from from the guest team uh yesterday um um who who who does likely get implementation and of the minor as well just to double check my assumptions and it seems like um this is indeed kind of how the concentration is and and they're actually interested in like looking into how they can adapt to 50 59 so so that would probably continue as a conversation um okay and then the other um part again uh probably that also is familiar with people by now uh that's of course the the eviction side that's where you also need sorting to to to now not know on the on the bottom end of transactions uh which ones to to get rid of if you running out of space um and there the id again if you basically look i think think about this situation where in the in and and the normal circumstances most transactions will be like in this non-includable zone and then then you look at those in a little bit more like a little bit more closely and and so so one thing of course is that um i think it's rather likely that clients will do something similar as they do today with this like minimum gas guest price that they enforce right and they just drop transactions um that are below that and i so i can definitely see that happening also with the mine upright where now another 59 if your minor bribe is below some standard i don't know one gray or something the transaction gets even dropped immediately by the mempool i don't know maybe not maybe um but i think that's at least like some something definitely like realistic and so that would basically put like a lower bound on the on the um on the minor bribe that any transaction in your mempool will will end up paying if it ever gets included but then the interesting thing is there's also like some at least some soft um upper bound for for what what like an effective bribe a transaction will will probably end up paying if it's currently not includable so so if the transaction comes in and like the current base fee is 100 let's say and and the transaction comes in it has like a a fee cap of 200 right so it's immediately includable then it could potentially be or pay all the difference there all the 100 extra in as a minor bribe that that's possible but but but on the low side if it's if it's actually in the mempool that's waiting to be includable again or or at all and this will that transaction even if it has like a really high maximum minor bribe it will almost never actually end up paying this whole um big minor bribe because it will be included as soon as the base feed drops low enough that it becomes includable but and this is like a topic we have to talk a little bit about like how how often do we expect like significant drops all of a sudden or something maybe with empty blocks um occasionally or something but but like generally a transaction will be will be most of the time become incredible just barely right where the base features drop just low enough that that it it it became uh includable and maybe includable with this minimum um minor bribe kind of the distance but that means that most transactions even if they potentially are willing to pay 20 10 20 30 gray of of of um minor bribe if they are currently not includable they'll probably in the future if they ever become includable will probably end up only paying a small minor bribe just because they'll only barely become includable and then again the question is how often do we expect like significant shifts in in in the in the base base fee and so this is of course the details like how like how small this kind of the this band of expected minor bribes can be this is like still a little bit unclear or like there are different assumptions to be made there but but the general insight there basically is transactions currently in the country not includable side of things we probably all end up paying like only a small minor bribe and so then kind of getting back to what i was initially in in this first document and the i think we also talked about on the call and maybe like two calls ago or something um what i was initially thinking um about was was kind of really optimizing for this expected minor value of transaction so so that like that that took into account like the minor bribe and the and the chance of inclusion of eventual inclusion basically but but now with kind of the minor bribe kind of looking more more that like it's almost like uniform again within this the small band and it turns out that this kind of mostly reverts really back to the simplest this is the simple approach there that we started out with so it's basically like just sorting making eviction decisions by fee cap um like they're just the total fee cap per gas um this really gets us close very close at least probably to to like to this to this expected value to the miner and so then then then of course the there's still a case to be made to like really optimize to to still kind of go beyond that um but but i think this this this at least kind of makes it like makes it kind of very um very kind of um likely to me that it looks it looks really like um just going with a simple implementation here again is also just really hits this good enough for main at launch threshold so basically like just have notes do the simple thing and then once we actually have good data of like how does the base fee change how often do you actually get these significant drops so basically how much of a difference is there between transactions that are waiting to be included that have like maybe a big smaller or larger maximum minor bribe and can we maybe do some more optimized sorting but it really seems like just the the very basic thing just sort by fee cap or gas they can use all the existing implementations so it's like a very small change it really looks like this might or like this this will be um good enough for for mainland launch basically um so yeah so so that's at least but but but i feel like this is basically the one question where i also feel like and i think barnaby um you you were talking about that in discord as well where we how like this might be like a really good target for for some additional simulation um work just to see like under some assumptions and again of course these these simulations are usually like whatever assumptions you put in you get out but still just yeah and a few different like scenarios how how much of a difference is there that could potentially kind of be optimized for with like an optimal algorithm but but yeah i think this is kind of my my view on the eviction side is there is there a way to like i guess is this spam proof in a way so is there a way where you can constantly raise your fee cap um because like if you say had a fixed minor bribe and you know the base fee changes or whatever is there a way you can spam the transaction pool by just constantly raising your fee cap by like one way and yeah yeah so basically i i didn't put it on this document because i didn't i don't think it's like one of these kind of complex issues where there's a lot of open questions but i think for for transaction replacement right with the same account same ones i think uh this kind of simple heuristic i think that was already that that we also already kind of um talked about like as at least as like a likely um candidate there uh like the simple heuristic of um you have to have at least the same minor bribe and you have to have at least like some like again like a ten percent increase of of maximum fee and if you just have that then you have like a very similar situation as you have today um but it's basically the same okay got it he wrote that in his previous talk as well okay yeah yeah yeah i just wanted to make sure that this kind of still held uh even though this like this sorting is is quite simple um yeah but basically the idea that there's really just make replacement expensive or well so that you could just can't do a lot of replacement before you actually hit the includable zone so it's really like basically the idea is it's really like the the network is mostly just optimized like just looking at fee fee cap per gas for all of these decisions for eviction for replacement for all of that and then the minor bribe that's actually mainly just used then at the point of inclusion at the miner themselves for these decisions but the the network mainly just looks at the the fee cap i have a question yeah yeah i forgot to ask this morning when we talked but basically you are assuming there is there is only a 1559 transaction in the pool but what if there is a mix of legacy transaction and 1559 do you what is the ordering basically you consider the fee cap to be the gas price for a legacy transaction oh yeah yeah just simply okay so yeah i would yeah but basically just just just like convert legacy transactions to this this kind of 5059 format where the maximum minor bribe equals the maximum total fee um yeah and that shouldn't be because again either they just get included immediately in which case again they only have the issue that they might overpay um which is just like the kind of the trade-off there or they end up in this not immediately includable zone where then at the end of the day like that they set this high max mine up right doesn't really matter because most of the time they'll end up only paying a small one anyway so then they they kind of are more similar to the to the native 5059 transactions then then then basically initially okay that makes sense but yeah but what that means basically is i would strongly argue that memphis should immediately just implement full conversion of these legacy transactions and not have like two separate mempools i don't i don't think there's a case to be made yeah like really keeping two separate mentors i agree yeah okay this is great yeah go ahead yeah thanks no no one question that i i was just having was um do we have a uh i'm not that familiar with um where all the participants oh i i guess yeah so the question was just do we do we have someone from like some of the other clients i'm already talked to abdel about the situation in with bezel but i would also be interested in like uh like how about other clients um it's basically like um is the implementation they are also kind of compatible with what i outlined here is like the other aspects that i didn't think of that might might not um kind of need needed adoption there adaptation i mean but i can also like that that was like the one thing that i still wanted to do was just reach out there and see if there's anything i wouldn't expect it because it seems or rather straightforward there but but just just to double check at the moment the implementation is just taking the very very similar behavior as before so sorting the transactions by the value for the miner and so i'm listening here but uh is it is it the final final plan for the sorting and you think that this should be implemented in the clients or because from the very beginning when we were talking about sorting in the transaction poll i'm thinking of um this is not part of the consensus which means that it can always be implemented differently and according to the miners requirements so as long as this is most beneficial for miner i think it makes sense and it'll be stable but if it's not then people start replacing it with whatever is most beneficial for miners right yeah i mean um so i definitely agree that it's not consensus um relevant um and so i think it's really just important that there's like one good enough implementation that that everyone can can basically fall back on if they don't don't want to to do something um of their own um uh i was just would just be curious then um for that if you when you're saying optimizing for what's what's most uh like for the for the value for for the miner um what so so like say any any transaction that you're looking at that's currently not includable how do you calculate the value for the miner there because i'm not when you say not incredible you mean by the fact that the base fee is above the uh above the block level right exactly yeah so it's it's just a question whether you want to keep uh keep some of them in transaction pool while they're waiting for the return on you just keep evicting them so i know that we want to keep the transaction pool minimal and keep evicting the transactions right so i think for us it may be even configurable by the miner so like do you want to be a victim or you want to keep them then the question whether you want to propagate them when normally they would be evictable probably not if other clients would evict them anyway then you just don't propagate them and keep them for the miners so when the base fee goes down they can include them this makes sense from our perspective but i i want to read this much more in details what what you wrote and and like now if with the approach that we have probably will start suggesting the users to to pick the implementation of the transaction pool one of one of a few and a behavior so parameterize it one thing we have to keep in mind is that while not technically part of consensus a the various clients do need to have an agreement on what criteria will cause you to drop up here and so we do need to make sure that we do agree on at least that part so if if you've got some threshold where you're like hey you're spamming me now i'm to drop you we need to make sure we're all kind of all the clients are in agreement that what the threshold is we make sure we don't like have one client that say no this transaction's fine or another client's like no that is spam and i'm going to disconnect from you that's what we do we don't want to not take a consensus but something we do need to agree on before lunch yeah and i think that's almost like more of you know kind of an all core devs conversations in a way like to me that's you know it is a threshold we need to agree on but it's it's not gonna block anything like the you know i don't think we'll ship or not ship 1559 based on the value of that trash holds yeah yeah and also oh no sorry go ahead i was going to say um something to keep in mind is that uh we always talk about how if we if there's a better mining strategy for miners miners will switch to it um we actually have you know many years of evidence that suggests that's not actually true miners seem to be um reluctant for unknown reasons to actually write code that changes their clients significantly and we see that because there has been massive for years now there's a massive opportunity for miners to take extractable value from d5 and no one has until the mbb people basically came in and did it for them and so if we have a transaction sorting algorithm that's good enough and well technically a minor could do something else our evidence suggests most of them will not and going back to the the first and first out sorting if most miners are doing first in first out then it becomes very expensive to do gas price auctions because most miners will just ignore your gas price or and we'll just include person first out you'll waste money so even if some miners defect and write their own clients that are more optimal it won't likely affect like the network and people won't leverage that because you can't leverage it unless all the miners do it so just keep that in mind that like while theoretically game theoretically i 100 agree miners should be optimizing these things um our evidence suggests they don't for whatever reason but i feel like we want to treat monitor miners into using something uh potentially suboptimal and it's it's okay if you do that as a particular client implementer and it's your decision but to try to spec it which is against game theory and say okay so we'll just do that because no one will implement their own solution i would leave it to client implementers saying this is this is some suggestion for eep 1559 but it's not part of consensus you can do that whatever way you want if some other clients will drop you because you propagating transactions that that are not nice for them and obviously will you will adjust because you don't want to be disconnected from the network and and there'll be some clients that will have a bit of more to say depending on their uh on their network participation rate right so the market share well that's the plan all of this is not part of the specification it's a set of guidelines it's a soft agreement but yeah you are not obliged to do so so yeah yeah just just to briefly clarify this this kind of does not propose any any kind of rules that are like purposefully suboptimal for the miners this is all kind of trying to optimize to just just sometimes maybe prioritize simplicity over of optimization but it's at no point again this was just like an additional proposal by mike michael we were talking about how we could maybe get could do some decisions specifically even more simple or something but in general this this kind of no no at no place kind of purposefully chooses the not not optimal um yes i was referring to the mic suggestions and um and some of the trick was also suggesting before but the way like trying to decide for the users how how they should treat the transactions in a transaction poster i i prefer the solution which is based on suggestion where we discuss it but not try to enforce it among the clients um and just say okay so we we discussed it this is how it behaves as that works this is not damaging 40.59 but we don't want to spend too much time on it because it delays us in the actual implementation that's how i see it and it's it's super useful the analysis and something that i read with pleasure i'm just here saying that we won't be necessarily saying that it's exact in the way we implement it and we want to keep that freedom of saying okay transaction policy outside of consensus logic so we want to be able to do something that will decide will be most beneficial for users yeah and to be clear i definitely don't don't think that we should force anyone to do this um the reason i bring it up is just because one of those things where um if we all happen to on our own right clients that do first in first out i believe that will be healthy for users of the network even though it may come at a cost a minor cost to minors and so it's one of those things where we can maybe opportunistically get a free win for users and to me that's something we should you know maybe think about and try for but i definitely don't think that any client should be forced to follow the strategy it is non-consensus just a hey you know if we do this thing maybe we get a free easy win and if we don't then it reverts back to you know what we're gonna do anyways so it's not a big loss although just to mention i i personally i'm not sure i i'm fully about that because i do think that this would then in turn just incentivize like um um um kind of side channel communication with miners directly to basically pay for for positioning in in the blocks directly which ends up being the same thing just with more friction so um but yeah that's a good argument i guess if we take like a step back like i think the reason we wanted uh to do this work is there were concerns that we could not find like a suitable way to sort the transaction pool that would be kind of spam proof um under 1559 i feel like you know we're definitely at that spot now where like you know we have at least a solution that would not make the status quo you know significantly worse or cause like a security issue um like i'm you know i'm pretty satisfied with what we have right now and and uh um like you know if different clients want to do different things or or if we all align like that obviously has all like it's you know own set of trade-offs uh but i feel like with regards to like the risk that having 1559 introduces in the transaction pool for dos vectors and things like that i feel like we're in a pretty good spot with this right um and then if different clients again want to tweak it uh you know i i think that's a that's a separate conversation but yeah i i guess maybe my question is like you know does anyone feel like there's something more that we need to help justify that like 1559 is like sound uh and safe um that's not that's not being presented here i mean sounded safe under this aspect yeah i mean i'm generally convinced that it sounded safe but of course this this only covers the the kind of mempool sorting side of things yes yes yeah yeah and and then you know i think like we mentioned earlier like we'll need to discuss also like how the clients want to do peer management and stuff like that um but i i think to me this was like the biggest uh like potential risk with 15.59 if just like you know can we efficiently sort the mempool um can we like you know can clients kind of manage your transaction pulled without it becoming crazy um and yeah i i feel i feel like i'm much more confident in that now um [Music] yeah and the rest kind of feels like an implementation detail at this point right where you like you know we can have long drawn-out conversations about that but it's not going to be a blocker for the eep yeah yeah that makes a lot of sense to me especially when the block is not full um sorting still has a cost so you know by appending only you you might the miner might already you know find find a block in that time yeah and we see that on mainnet already right like with empty blocks that get mine so i and i'm fine with like you know we don't need to solve all of the inefficiencies of mainnet to deploy 1559 we just ideally have to not make any one aspect significantly worse um yeah yeah i'm with you i was a little bit worried about the sorting algorithm um not not worried like as a blocker just worried it was going to be hard but that this research has convinced me that it's easy yeah same um and yeah again like i think you know thanks a lot and scarf for this like this is this has really benefited from having somebody who's like actually spent time thinking through it uh deeply rather than like as a side thing uh on top of everything else so yeah this this has been really helpful awesome yeah and thanks and that but just briefly by the way to mention because i have it under under further questions um just like a uh one one thing that i realized like dealing with this is just i i think at some point but i think that we don't that it's not necessary before we launch on mainnet but i think at some point it's probably also like a good idea to to to get back to for one to just the aspects of like what are the kind of the the things that might also at some point change with with eth2 right because we'll probably just want to move this 1559 over and also use use on these two but that's of course a little bit further in the future but maybe i don't know that it might just be that 59 only ships half a year before the merge or something so this might become relevant quite soon then um and then also like the there is one specific topic so like how can we maybe long term that doesn't have to be in the first release but long term kind of keep the the base fee a little bit more more smooth and stable even under like the kind of the um this uh distribution of block times right because right now what will happen under 5059 is sometimes you have very quick blocks um and and that means that they are either like the second one is either empty or almost empty and then the base three will drop quite a bit or sometimes you have like very long time periods and then that looks like congestion so basically then the the block will be twice will be double doubly full and so um that there could be arguments to maybe at some point um do like time time adjusted adjustments as well or something that also take into account the time since the last block or something um but again i think all of these are things that definitely not not necessary for the first version um just things to keep in mind yeah i i agree just in general that came out in the timber off garden report that like the base fee update rule was you know simplistic to say the least and like it's probably not a blocker to ship it right now like but there's definitely some room for improvement there and i suspect it would be helpful to have actual magnet data before we were to tweak it because we know like what we have right now probably works but it's not optimal um and it's kind of hard to make assumptions about what the what the usage conditions will be before we we actually deploy it agreed um cool just because we're uh about halfway through already i want to make sure we get to the rest of any final questions on the transaction full sorting okay uh yeah again thanks thanks guys this this is really really good um yeah um abdel do you want to give an update on the large stake test nets and where things are at and how this could work with other clients i see that like you're uh chatting also with on the on on discord yeah yeah i will give some precisions about that okay so uh should i just give my update and the demo later or i'll do both at the same time uh let's just try to focus on okay let's take that for now yeah okay so yeah basically we have a large state test net the idea was to have something comparable to mainnet so we managed to get a test net with 100 million accounts and 100 million entries in the state storage tree and yeah the problem is that uh we use the bezos specific feature which is uh to have a fixed difficulty and uh i forgot to ask if it was supported in get and nettermind and it seems it's not so i was asking basically ramil that uh if he would be okay to hardcode it for the test net and i'm also talking with thomas about that uh in the discord channel but yeah basically that will be the the only uh trick we would have to do in the code base to make it work on the state and again if it was uh if it would easy to to generate the test net again i would restart with different parameters but it will take two weeks to get the same state size so i would rather hardcode the fixed difficulty value in the code rather than delaying the performance tests yeah we are working on it right now and we made some another issue with uh base fee calculation uh so we are trying to investigate it and so it's in progress i will okay i'll write some update today later okay nice and thomas would that work for nethermine the hardcode the difficulty like that or i'm just implementing it now actually so we need to okay thank you thank you father genesis block handling and there are a few questions on this card so i want to clarify of how to get it so to ideally i would start syncing it today and how about how long does it take to sync the test net uh well it took roughly like something like maybe two days with basil uh with a full sink obviously yeah i guess yeah my the reason i'm asking is uh if then we want to do this kind of performance test would it make sense to schedule another call and like do that synchronously with like you know all of us or not necessarily everyone here but just like geth uh nethermine and basu and i don't know it's like a week from now like good enough to fix the bugs and uh and uh yeah be ready for that or yeah because it feels like i don't know it might be easier to do this type of testing if we're all kind of on a call together and uh yeah yeah yes maybe yeah we can just default that uh once the nodes are synced uh just i can submit a single transaction just to verify the consensus rules and then we can plan a call to do the actual performance test if that makes sense yeah that works for me uh thomas ramil do you does that work for you guys yeah sure any time let's say i'll be targeting today for the producing start we'll see how it goes cool yeah so yeah and you know uh so if if say we get them fixed you know today or tomorrow uh they sync over the weekend then you know early next week we can probably have abdel just send a few transactions to make sure it all works and then uh you know schedule something for like maybe the same time next week or something but i'll i'll follow up on discord about the specific times but um yeah uh i i think that to me this is like the last kind of big test thing we need to do on 1559 um and if we can get that done that um that's pretty good um and i have something else that's slightly related but just want to make sure is there any other questions or concerns about the test depth okay uh yeah one thing i'll just share my screen uh vitalik uh i asked him uh to do this a while back and he did this week which was great uh so the main reason for doing this test on the large state is like the fear that you know uh the large blocks cannot be handled on main net and uh vitalik wrote a small explainer like why he thinks this is probably not even a problem um it's quite short i like encourage people to read it but at a high level um you know the the biggest risk is like well you know clients maybe cannot handle 25 million gas blocks um and then if they could you know why wouldn't we just double the block gas limit and have them handle 25 million guest blocks all of the time rather than just doing 1559 um and um and and uh he basically explains why that's the case so there's like three reasons why we can't just increase the gas limit a ton uh the first is obviously the average uh block processing time will increase uh you know if all the blocks are much bigger um the second is that the risk of denial of service attack increases uh if the the biggest block is is much bigger and the third is like this the storage uh size growth rate will also increase uh if all the blocks are bigger um and one thing that's that he notes is that you know these the first and last of these are really only impacted by the long run uh average block size rather than the maximum block size we see on the network um so that means you know even if we can't do those three things given that 1559 doesn't increase the average block size significantly but only kind of sublot from time to time the only issue we have to worry about is the second one um and then uh you know there's a few arguments why the second issue is maybe not that bad at all uh the first being that 29.29 uh which is going live into berlin will help compensate for some of the dial of service risk uh based on on uh storage access um so i think this is you know a very good point and also kind of a reason why it would be pretty complicated to ship 1559 before berlin um so having 29.29 helps uh with denial service protection um and then the second argument is that obviously uh if we have a short-term denial of service it's less worse than if we have a long-term denial of service and 1559 actually helps here given that the the base fee increases when uh the gas uses more than than 100 in the blocks uh this means that the cost to sustain a denial of service attack on the network kind of goes up exponentially with time um so you know realistically uh attacks could not be very long and that means that you know even if you could create a denial of service attack you're almost in a better spot after 1559 than we are today where today the cost to do this is kind of a fixed cost um and then the third argument is uh that the the block creation process itself today is uh poisson distributed and that would lead to uh to having 2x spikes twix bikes happen on the chain uh roughly once a week just by randomness um this one i think is the one that's like the least fleshed out uh and it would be interesting to see data for um but just like with the first two arguments it feels like yeah 1559 is like a net improvement over uh over the status quo and the risks are probably pretty minor um so this is not to say we shouldn't do that you know the performance test i feel like we're we're basically there um but it's you know it's really good data i think uh to show that even if for whatever reason you know we can't sustain like an hour a very high load or whatever um 1559 probably still isn't a major uh denial of service risk for maintenance um generally think that from e1559 perspective the the one thing that we should do now in parallel to the final testing and implementation is just to ensure that there is very very active uh dialogue with miners about when the change will be introduced uh what their current stance is uh do they still have some concerns they would like this to address and some clearly clearly tell the community what the decision is are the court deaths trying to go against any minor concerns is there any compromise so how exactly the transition will look and all the miners the the majority of miners what they say about the transition process it is a giant can of worms yeah if you don't open it now it will open itself uh the moment when yeah it already it already has it's uh i don't know if you you hang out in the east r 1559 those three channels and then also on the youth research if you subscribe to that there's like i don't know three new people a day that show up and complain about their fees going down with one five five nine and we tried to talk to them um so far none of them have been able to formulate like a solid argument besides i want to get paid more like that's the kind of the route that i've derived from most of them it's just like i want more money there are some other arguments that they make that they're worried that or they claim that mining will centralize in china but i think uh that was actually debunked earlier like apparently i learned i didn't know this but apparently mining and ethereum appears to be mostly in europe i love china um which was surprising to me um but yeah that's like the two things one is i'm gonna make less money i don't like that and two is this is going to lead to centralization and the reason the centralization argument is kind of reasonable because the people when the profitability of mining goes away the people that have the finished margins are the ones that are going to get kicked out like the people with big fat margins they're going to stick around and the people with very thin margins are going to get kicked out the belief is this is a reasonable belief that the large mining pools have the biggest margins and the small pools or single miners have the thinnest margins and so if we do something that hurts miners in some way then or decrease their profitability in any way then the people who are going to leave are going to be the thinnest margins therefore the non-pooled people are the non-like farm people and that can lead to centralization um i'm not really worried about that because the ethereum's price volatility i think has a far greater impact on that than 1559 will um that's my suspicion um and we already have to deal with that like that's just the nature of mining is that it tends to centralize over time maybe maybe the last one sorry go ahead so maybe the last three searches we want to have on paper is the analysis of what exactly is the expected um the hash rate drop based on the responses from miners like do we do we lose big miners do we lose lots of small miners um what will be some kind of document that'll tell non-miners this is what you were making before this is what you're going to make now based on all the analysis and then based on that see what responses are and try to judge what the hash rate drop will be and how it will affect the security of the network so i think there's a there's a few challenges with doing such an analysis uh the first is like people are obviously biased in their responses right it's like you know before the change goes live every miner has an incentive to tell you that they're gonna drop if it goes live and then if it does you know they're not like bound to that i think the other challenge is we don't know there's no good way to model how much their revenue will decrease because we don't know the amount of like high tips that people are willing to pay for things like arbitrage and whatnot um so it could very well be that like you know for most transactions the fees go to barely anything but for the highest paying ones um the fees still stay relatively constant and those were a majority of the transaction fee revenue anyways um i think with regards to like the security of the chain a few things worth noting is like one ethereum is still like by far the largest gpu chain and and i think that would probably still be true if we lost even like a a large amount of hash rate uh and it might be worth finding out exactly how much um and that that like is probably the biggest risk like we don't want to be the second largest uh gpu chain because then you you open up a bunch of uh of attack vectors um and uh and then the other challenge is the hash rate is at an all-time high right now which makes it obviously less profitable for for miners given uh the increased competition um and it's hard to predict how the hash rate will evolve uh because there's more than 1559 affecting it right like there's 1559 obviously but then there's the price of ether which is a big factor um and there's also the willingness to pay high transaction fees which is mostly fueled by d5 right now um so i'd personally i would just be very uncomfortable providing like an estimate and having people kind of you know make their decisions based on that because it's such a like dynamic thing um yeah that's i guess that's just my yeah my yeah so for estimate it makes sense but maybe some just this kind of clear communication of this is what we expect uh to be the effect of the change on miners and this is just to inform community and these miners are saying this and this and this and maybe collect like are there any miners that's saying they're going to join because of that change because if the market changes even as those statements might be biased as you say at least informing community what what the collected opinions from minors are and what their stated actions are so the community can prepare uh for uh like to be to know at least whether to expect the turmoil or to expect the smith transition yeah i think that i think that's fair uh i can definitely look at it trying to collect some statements and and just like list the general changes um and i guess you know the the like philosophical argument that you like end up with is like you know should miners be actively part of the ecosystem and like influencing decisions or should they be kind of you know price takers where like the ethereum protocol has certain properties and then they can choose to mine it or mine another chain or you know not mine at all um and and i think that's where like you know most of the disagreements come in yeah i think i think it's tough i'm not having any statement on this one here i'm just saying that we should clearly communicate what they what the process will be uh if the court deaths say for this change we take the stance that uh that even as miners strongly oppose or if they do not strongly oppose the state even as miners and mildly oppose or yeah so do not oppose whatever it is even then we decide to go forward with the change and then the community can expect that there'll be some potential risk around the change because the finders are not aligned with cordov's uh yes historically it has been very difficult to get um feedback from miners like you there's you have like this non-stop stream of people coming into the channels and whatnot complaining and saying what their opinions but when you try to actually reach out to the big pools like f2pool and ethermine and sparkful you get like no response like it's very hard to actually talk to the farms like the farms are non-communicative um i don't know why that is but historically that has been the case like we can get people who say they're minors to show up and talk but no one will admit to being a major farm or like a large scale fact minor i think at least in the past we were saying that uh hudson was uh having a channel to connect to yeah mining and being able to collaborate yes yeah he has a channel to talk to them but uh that channel hasn't historically not my understanding is that his channel has historically not worked for getting feedback from them like if you give them a survey to fill out you can just like one question you just won't get anything back um whereas i can yes i can follow up on that we did things yeah we we did get some feedback from i think i so when we did the the first outreach you know we got some feedback from miners i think generally most of them didn't want to be identified uh with regards to their like entity i i might be wrong like some of them might might have wanted but like the general senses people like you know didn't necessarily want to to be identified but i can yeah i can reach out and see what you know people might be comfortable with and how we could aggregate their people as the names of the mining pools that are mining blocks they are they are publicly known so we can just provide at least a community saying these miners decided not to comment on on the change these ones are for this ones are against and now we're just clear on that there'll be like eight or nine entities of the pools or or big miners than we see um yeah assuming that we can actually identify who is behind the pulse but i think this is not really a secret yeah i i think that's important but i also think uh thomas had a good point in just saying that like this is something we should definitely talk about at some point on the all core devs so so yes because i think yeah that that's a proper place yeah um and i'll try to you know before this gets brought up on all core devs again to to follow up about the minor conversation and both i guess both try to list you know i think we can we can list the objective changes that 1559 will bring to miners you know like you're gonna get the tip but not the base fee and whatnot and and and you know some like hypotheses about how this can affect them um and try to get their feedback um yeah but also just to be clear right the merge is probably coming within i don't know i don't want to be optimistic but like six to 12 months after after 50 59 so this is at the point at which we just sunset mining completely so um yeah i i think it is important to keep that in perspective we're talking about the last six to 12 months of mining yeah yeah but but i think i like thomas's point where like you know we might very well decide to go ahead even if there was say like 100 opposition for mining and just say that you know what people other people will mind the chain and whatnot and that's fine but at least we can kind of be clear with that decision and people can expect you know some sort of potentially turbulent upgrade and that's very helpful for folks like say infra or exchanges or whatever to to know um yeah so i yeah so just i guess to be clear you know i don't think that because we collect negative feedback from minors we should like not do the change uh but we can make a conscious decision to do the change even though there's there's negative feedback because there will like there will always be negative feedback from any stakeholder group on any large change to the network right um yeah i'm not i'm not saying here and like uh withdrawing from something that has quite clearly supported on the cardiff's channels but yeah also not to be quiet about the lack of support from owners and be clear with the community and if we decide to say okay we're going with it even against uh some opposition then we have to be clear and not try to just hide it and uh and be quiet about that so the community needs to know because it may actually lead to uh to some potential problems during the transition right like some miners can be very adamant if they feel uh totally ignored and not even included in the in the communication channel so i'm not saying that there will not be some heavy lobbying and campaign on twitter and so on but yeah you know the more you try to hide it the more of a problem it may become yeah i agree um cool um so the last thing i guess uh there were two more things i had on the agenda so uh abdel put together an eep for the basie opcode and he also had like a quick demo for uh how to join the 1559 testnet um oh 2718 as well i guess yeah is there anything else that people want to discuss just because we only have 20 minutes i would like so i would like to spec out 27-18 sooner rather than later i'm not a huge fan of letting it wait but everybody else wants to continue waiting on that uh i will concede so for 2018 if we have like the test net uh test you know over the next week or two does it make sense to do 2018 right after that we can do that in parallel i think because we have the other test net for to do some changes and doing integration testing so i will not wait for the performance results to start personally well i guess yeah we can do it in pair i guess nethermine and vulcanize can you also do it in parallel or or is it valuable to maybe just start with base u and then add the other clients uh yeah yeah we already have the implementation for 27 19 uh maybe not with the latest changes that are not fully agreed on but we do have an implementation okay we can start yesterday australia and did we [Applause] did we agree on the transaction types we are going to use etc the value of the actual value uh we haven't hasn't respect that at all for like someone needs to submit a flip request probably me two one five five nine that adds in 2718 integration and that's part of that we'll pick um transaction types i'm going to most likely just pick whatever's after uh okay 9 30. i forget which number to use for them but at least okay that makes sense yeah i guess if you can just re-share that pr mika in the dev channel or something just so people can review it that's probably a good way to start i need to write it first i've been waiting to write everything already actually i thought you said you had it yeah no worries cool yeah so yeah if you can get started on that then we'll review it when it's when it's ready and uh we can we can get that all right thank you um cool anything else before we go to the base you up code in the testnet demo okay uh abdel over to you uh yeah so the create basically of code so nothing crazy we just uh want to add a new evm of code to get the value of the the base here of the current block and yeah so i created the pr so basically with the value and the proposed gas price and yeah i i did the nominal case and we decided to uh to do exactly what we do with uh unknown object for example if we originally end up code that has the value of the base your code we just throw an invalid operation error like we currently do so yeah nothing crazy so i created the ipan waiting for review so mika did the first review and merged in leicester but uh yeah so what does the gas price uh return what does the base fee return so gas price will return the the actual price to the transaction right yeah exactly and the base here returns the the the current uh basically in the block header yeah very nice yeah so yeah very simple yeah and yeah that's it about the ip adagio do any client does here think that that eib will be hard in any way or is that something that we can just kind of shoot in i think it'll be super easy to implement at the same time if if it doesn't happen at the beginning it's not a big issues cool and uh yeah i thought you want to share your demo for the for the uh yeah sure yep uh yeah let me show my screen can you see it yes we see the black that it starts page okay nice so basically yeah this is a network status page for the new testnet so currently we have four bezu nodes so we are close to one million blocks and yeah as i said we have uh 100 million accounts on this test net and 1 million 100 million entries in the state storage and basically yeah we implemented the tool to join the test net easily so the idea is to build the client agnostic tool but for the moment i only have a bezu implementation but the idea is that after that i can try to add the determined and get support if you give me just some basic stuff like a binary uh capable to do 1559 stuff as the genesis and the conflict file and then i could try to add the determined and get support and basically you install this command line tool okay and then you simply run e1559 run so it will download the config file templates it will prompt you to for a name to display in the stat so for example implementer course nine and then the text that you don't have bazoo installed on your machine yeah because by default bezoo is the default choice because i don't have the other client support at the moment so i will install bezu automatically okay so it prompts the command line to run the node but if you press enter enter it will run automatically and open the network stages page oh okay well demo effects sorry again okay so now bezel is running and it starts to connect to the the peers okay the synchronization started and yeah basically if i refresh again i have the the new node and it starts to sync so the first block are really big because i generated the tool basically to to fill the network with a lot of accounts and a lot of entries in the smart contract and yes there is another command also in this tool basically it's a simple faucet so for example i want to add some it to this address to play with it so basically yeah basically if 1559 for set with the address and you will get 0.5 it on the test net yeah okay this is a 0.5 it's and yeah so the idea is to have a simple tool to join the test net and to have more users running the node on 1559 we also have a tool to basically submit transaction to to this testnet because there is no implementation yet in the wallet provider so basically if you want to submit a 1559 transaction you have an estimate button that will generate a pickup for you and you can submit the transaction and you have the link to the block explorer and yeah basically you can submit a 1559 transaction and yeah that's pretty much it yeah that's really cool thanks for sharing cool um anything else anybody wanted to share discuss bring up okay well yeah thanks everybody i guess uh we'll follow up on the discord dev channel to set up the the large state test net uh mika will also be waiting for your pr and we'll review that um yeah and then uh i guess we can we can figure out based on the test net test uh when we want to have another another call or follow-up but uh yeah i i think this is this is looking good yeah thanks thank you yeah nice thanks so everybody