EIP-1559 Implementers' Call #2

we're recording to the cloud yes so thanks everybody for showing up second 1559 implementers call I'll share the agenda and the chocolate was pretty lightweight so if there's other stuff that people want to cover we definitely have the time for but on a high level wanted to start with just some status updates from implementers then there was a PR that Mika zolto how I'm pronouncing is write his name right put that basically that basically changes 1559 to not set a fixed block size but instead still leave the miners the ability to decide that and just still aim for a 50% 50% full blocks I forgot to have Dan your mock-ups then abdel had some questions around consortium networks and then anything else if people want to chat about it yeah so I guess for first status updates ian abdel I know Barnaby you had also some stuff you were working on so feel free to yeah I can start talking about Bezos so last time we said we will implement the possibility to make all those parameter configurator so we did that we tested also we get implementation in this world local test net and we are aligned with the spec for the moment and we are waiting to see about remove riders proposal well yeah that pretty much covers my update I thought all I've done since the last meeting was introduced those config options for the different parameters yes besides that there hasn't been much I still need to do a rebase but at this point I'm kind of putting that off as long as possible because I know they'll be more read ace is going forward I can go next hi everyone I've been working on like let's say three different things the first thing is one open question we had in the last meeting was if we really wanted to combine the elevator escalator algorithm with VIP one five five nine how would we do that so I've tried to explore this question a bit I've put a link in the discount or note that is on github we've liked a few designs some of them not very good I think but one of them seems to be capturing let's say the idea of a IP one five five nine of having this base fee but also like the idea of the escalator at UK and sort of climb above oh okay yes I can I'll do it yeah but you can climb above over people fees so that you have priority one open question I have that I don't have a good idea for at the moment actually is whatever kind of default values we expect for users who are signing their transactions so maybe Dan is going to talk about this when he shows some of the designs for the UX but I I was trying to reason from a place of let's say economics or game theory like what do we expect users should be given let's say their value for the transaction or given a value for time that's not clear to me and I think it's a fairly difficult problem that could use that more eyes on and the third thing I wanted to do was more of like a data analysis of current and past transactions I wanted to try and get an idea of the regimes that we see currently on the chain and even though we can't necessarily transpose that directly to what we should expect under VIP one five five nine I think we can still get some ideas about the Preferences currently of users for instance I was planning to look at how people may be replacing the transactions on the mempool so that gives you like an idea of who they want this to go faster so they have a higher preference for time like I want you to use these kinds of natural experiments to get like understanding of this and I don't think it has been done before but I'm also not like fully aware of everything so yeah that was kind of my my three three things I try to tackle oh thanks for the update and I see we have Thomas and Artem on the call so is there any update from another mind or open a theorem oh yes sure sir so far I made a lot of research I read every single post that all of you guys ever produced and so you were quite talkative so it was not an easy task the Safari I really liked what Barnaby was creating with his like agent agent modeling the simulation so I think this is the way to go and I'm analyzing all the different approaches and so far we haven't started implementation but we'll be ready to get all the code if needed we definitely won't happen but the last break for now since we don't really do the proof-of-work mining so we don't really have to worry that much about miners one thing that I've never seen being mentioned in your discussions maybe once shortly mentioned by better was they how we will decide to introduce this new transaction models into the Kliq networks like rinkeby and girlie but it will just stay with the old transactions forever or move them all to the new model which maybe not ously has the same meaning for the network's where you don't have miners so be great to have the decision here how we how we handle those other networks yeah I think that was Adele's point as law on the agenda around like IBF t4 base you as well but you had one group of work networks so yeah we can definitely dig into that a bit more today and art them anything from you know we are currently focused on Berlin artwork so 1559 is not on our immediate agenda right now okay so yeah next up there was this PR I'll post it in the chat that basically tried to disassociate 1559 from having a fixed block size and leaving basically still leaving that the miners like-like-like is currently the case mica could not make it to the call but yeah he was curious to get people's thoughts on this our um I don't know if anyone has strong opinions on this I think it's a fair point and just to change that was not really the main focus of the AP 155 5 9 so I'm in favor of because PR as long as my nails are not moving the block size as fast as let's say the base piece moving like if they are moving on two different time scales economically speaking there shouldn't be like too many issues okay I can't be two strategic if I can only move the block limit by let's say 1% every block or less than that the base fee I think is allowed to change by over 12.5% each block block to block so as long as these two are not too close to each other it should be okay but I bet we could use like some more modeling on this you know what is the the max that miners can push a block units per block right now it's either one over a thousand twenty-four one or one over 2048 every block I forget that's definitely on one of the two which is way way less than twelve percent red yeah so okay so I guess yeah there's any one thing that is PR is a bad idea um I would hmm so I I think it's a good idea in the sense that I like having it be an explicit decision that's that's noted elsewhere because I've noticed in our in the earlier days that people were still confused whether or not Oh are we changing that the miners are deciding things so I think it would be nice and I can help anybody who would be willing to do this to write an EIP that does change the thing to being protocol-specific the the thing to being protocol-specific and then we can have 1559 require that and then it just seems like there's that's something to really think about the consequences of so we should have like both options one is this CI this version that doesn't have it and then we can have an EIP that changes it to a fixed and then have 1559 require it and then kind of further just figure it out like I like the idea of removing the writer is what I'm saying but I'm not necessarily sure that that means we should not do it yeah I tend to agree of James here and if you look at my comments that it's obvious that I'm playing devil's advocate I'm actually super passionate about about this choice I'd be fine either way I think in general though the state of the EIP you should be determined by what is best for the EIP not you know what is best for the perception of governance but that's just a personal opinion and how how realistic would it be to say add you know the fixed block size or like the block size determined by the EEP in the future say we wanted to separate those two proposals how like modular are they I don't think it'd be very difficult it's not exactly modular because these changes are spread throughout a bunch of different packages and but it I think it would take you know one or two days work to shift in one direction or the other you so I know and I know in the past we thought like will want to have test networks up to simulate this and make sure that things actually work in practice would it make sense then to accept Micah's PR to kind of reduce the scope of the EIP try to get that live on a test net and working and see if there are actually any security or performance issues from having from keeping the blocks as is and if so we can like you said um just added that and it's a very small change yeah I think that is the best approach is to test both cases and actually figure out which one is the most sound implementation so to picture you at test Belford parallel well I guess at this point we already have tests underway for the complement ation yep so yeah I guess we could add it on in parallel all those I should defer to Abdel here because he's the one actually doing the testing yeah if we want to test post in parallel I would advise to make this a configurable as well to have a flag to enable on that the riders yeah because we already have the implementations I would not remove it too soon I would say and maybe it was testing with large-scale simulation and sees impacts of both approaches is there is there any timeline on when tests will start by in terms of networks team not yet I think yeah we wanted so now we're at a spot where you know the guests PR and base you PR work together and we've run small local networks but we don't have anything like a public network yep and I think the the main kind of blockers were Dan's proposal so trying to analyze you know Dan's versus 1559 and how they work together and now there's maybe this other one around you know fixed block size versus minor decided block size so but it but I think yeah those are definitely things we could try out on the test network but no one has like volunteered to set one up yet so in terms of next steps for Micah's PR should this be merged in then or should like that yeah I'm not sure how we keep both in parallel and and yeah it almost feels like each other I guess what I have a question what was the initial idea behind having this rider because I don't have this context because I guess it was intentional to exist um it was mainly a simplifying measure it was basically that there was like one a field in a block and then that was used for the Gasol a bit and we need to have a field to store the base fee so I might as well just repurpose an existing one because that's easier than changing data structures hmm okay so it was not correlated to any economic concern all right yeah okay okay so in that case when it makes sense that just merge Mika's PR assume we're still keeping the minor decided block size to reduce the scope and if there's an issue with that you know we can we can come back to the fix block size if that's a solution but it feels like right now it's it's probably going to end up being simpler just like politically to have this be a smaller change then then to have it also take like change this other thing with minors if there's no strong need for it yeah that makes sense to me yeah that seems reasonable to me it would be great to have the the the other PR open other AIP also open before we merge one of the writers what do you mean by the other IP so it's a the PR right now is that PR to EIP 1559 right and somebody brought up making it an alternative PR all the block size change so basically like the reverse diff of this PR it will be a bit fully to tell it out but just having it open the track it would be great uh yeah I think I think the way to do that would be to propose an EIP to change the the minor to being decided on the protocol level or not and like removing that part and then tagging 1559 saying that this is an option that it might require so if you choose to do it then you require the the EIP that fixes the minor gas limit it removes that the minor control like right an EIP that removes minor control of the gas limit and then have and then have that be an option mol requirement for 1559 so it's easier that discuss the - do you think do you think this change alone will have sense without the IEP 1559 i mean if we create a separate IP for the rider could we let's say we don't implement ap 59 could this one be implemented without in 1559 it certainly could I don't see why we would yeah I guess what what you're saying by that is you you make it require a consensus fork to change the bus gas limit which I know from my perspective seems like it's probably not the best idea but that the use cases for apt I like the idea of like just separating the concerns of making you kind of clean that you know e IP 1559 does not require that but then but then there is this other e IP that we could add 59 um does anyone want to kind of open that that a I and and and then we can merge peek SPR I can do it okay thanks um so um yeah thank you yeah once you have that then we can merge because PR and I guess we kind of have consensus that like if if like the client teams want to keep working on on 1559 we can implement it in the way that's described in the PR for Mika that makes sense yes yeah that makes sense to me we will have to make changes to order it to that yeah yeah yeah cool um anything else on that if not then you want to walk us through your work yeah sure so at the last meeting you know I was raising some you know wallet perspective concerns and thoughts about the experience of this and the escalator algorithm and I agreed to prepare some designs to share and so I went through with some of our designers down at meta masks and we did we did an exercise and we you know we sketched up a whole bunch of ideas a bullet for 1559 and escalator algorithm and I don't know if for sorry I do think there's a some possibility for composability in retrospect having now gone through more of the exercise but let's say let's dive in 1559 first so I think my favorite one for 1559 is probably like this one this one's very different yeah I think maybe we can do something incredibly simple yes so maybe this is like an example of what we're saying so 15:59 I think the happy path I think everybody knows it's it's got some really great promises right we should be able to expect a nice low cost you should be able to expect a nice little time and the user is only primary expected parameter is the feet and we think that we can make it very simple to you know represent different orders of magnitude for the feet and and that's all fine and that's nice and you know under Advanced it's possible we could show like a graph representing the recent prices the thickness of these lines was intended to represent maybe the the tips that were included on those given blocks moving over time the blue line representing what you are current max feet or how far it is over the recent block average that's that's also pretty alright and pretty easy to do and then yeah I think this is this is kind of an unlikely worst case I so if there was a spike in congestion which I don't know if we can realistically expect like like if we're trying to say you should pay more I think we would have to see like you know see really more expensive blocks and in theory you're gonna approach a block that is not including transactions but we could we could anticipate a curtain a current ascent of blocks and we could maybe estimate higher also to address a Barnaby he was asking what we might suggest in terms of defaults we discussed that a bit and we were thinking uh initially probably a multiple of the current base fee so if the current base fee is you know if the last blocks base she was 21 cents then we might suggest double it or something as a as a max fee and then suggest increments over that that way it's more dynamic I don't think we would want to try to hard code the that fee this this should be user defined parameter something that's maybe not oh it's just that's sorry different design okay something that's maybe not represented there was there's a question of oh the tip parameters like hardly represented here at all yeah oh you can see it on the edge here we were thinking make sure to be tucked below or the EIP suggests the tip could be hard coded by wallet I think this is a really important question and it's maybe you know so if we if we hard-coded as a wallet I just want to ask him I'm like what should we set it to should we said it's in 2g way my impression is that this could create a bidding war between wallets like no wallet wants to be the wallet that's paying the least for a tip and then getting excluded and so that kind of seems like and there's not like a I don't see it equilibrium for like capping out exactly and and that's actually one of the reasons why I kind of have come to agree with Myka that the tip parameter may actually be eligible for if you were going to compose with desk later algorithm in terms of waste escalator algorithm could work oh yeah so in the basic fee we should be able to provide an experience that's very familiar to users where we've got half fast and low prices and and so these defaults would represent like slopes that are kind of invisible to the user but for advanced users they could define their they're men and their max and their time preference and possibly even see a visualization of it over a plot of recent transactions which is a pretty cool way to do it and the reason I think that this can compose with with 1559 is because both both algorithms use a a max bit parameter so both since both have a max price and the gas price paid is the lower of the two between the max price and the base P plus tip we can set the yeah we can we can use it for both so this escalation may happen faster if if the base view moves higher you may get your higher prices faster but you'll still be within this range at least and it solves the problem with that hard-coding a tip I'm definitely a bit nervous about what it means for a wallet to hard-code this tip parameter when it dictates the ordering of transactions within a given block but other than that I think that's a decent summary of kind of what we were seeing yeah it was this these aren't like designs that were necessarily committing to or saying are definitely the best these are just kind of what we came up with after a couple sessions and you know can serve as a starting point for you know community discussion about how this would at best be represented to users looks great thank you so much yeah yeah yeah thank you this is great work yeah thanks yeah I shout out to our designers we hope for three designers here so Rachel Cooke Jake Hogan and Christian Jerry oh yeah this is awesome so then she said you're a little bit nervous about hard-coding them the tip in the in the wallet can you just say more about that so I can understand the concerns there better yes so there's really there's two parameters on each transaction that are related to 1559 the max network feet and and here you can see us representing it as the users own preferred currency so you could say we can say maybe I don't want to pay more than fifteen dollars and then we can divide that by they estimated gas limit and the gas price and then and we're able to give you a max B and that's that's some nice user experience however there is a second parameter the tip and and that one is it's it's supposed to be like kind of tribute I don't know if somebody else wants to take a swing at the role it's it's to include to preserve minor incentive is my understanding because if you didn't have the tip at all then the entire transaction fee would get burned and but but it is the the remaining minor incentive and so within a block it's the only thing to miners getting and so there is a sense of preserves for miners to order by tip within a block so it may be doesn't matter if everything's moving up and down you'll if you're not in the first block because you tipped is low you'll be in the next block but but as a wallet I don't if if if the price jumps up I don't want my users to be the ones that are waiting an extra block is that is that a I don't know if I'm doing a great job of explaining that but uh so if there is a sudden surge where a block is full then the miners are gonna pick the highest tips and wallets are currently advised by the EIP anyways so hard code the tip this puts wallets in a weird rival risk position to make their users pay more could you possibly hard-coded as a function instead of as like a static value yeah I mean we could we could do everything that we do today because you know as some of the criticisms have suggested the tip becomes at another single price auction like like 1555 is trying to avoid so we can do all this stuff that we're doing today and you know the good news is it only applies within that and so and and you're still subject to the max fee so that's that's nice but but yeah it doesn't mean that we we might have to preserve for example or current bidding logic under the hood and just apply it to this smaller within the block auction yeah and the other thing you can do is you can use a kniv algorithms that look at kind of what happens to previous transactions to adjust the chain like you could do something that says they the tip keeps on decreasing by 10% every time you send the transaction until you notice your boat your transaction not getting included within a block and then it jumps up again um yeah yeah we could do that we might want to look at what other transactions are doing too but but yeah like seeking the minimum tip definitely seems like there like a component of the right strategy designs I really could learn things one thing if all the tips are set to the same value I think ideally I want to give priority to the users who are putting a higher max fee because they expose themselves to more risk and if I put a high max fee it also means I really want my transaction to get in that regardless of the price I have a very high value for it so how does setting like a uniform tip it's not about like to discriminate between let's say users who have high value and users who have low value so perhaps like also a tip which is a function of the max feel like if you set a high max fee you tip a little epsilon extra and I think something like that maybe possibly I mean one of the goals I think of both 1559 and escalators to avoid and minimize overpayment and so I'm just a little apprehensive about any strategy that basically adds a fixed cost because you know some some users may just steadily have more they're willing to spend and now they're permanently paying or maybe that's not the worst yeah it's worth considering in the just some context for the the theory behind the fee being fixed not in the wallet but having like approaching this fixed value is that it there is a risk of it the uncle risk for including a transaction it's pretty similar for whatever that's right so that is theoretically where the it could be the same and it could always be the same in miners would accept it if it approaches that about value well I I mean you guys are the wallet people saw it but as far as choice and suggestion versus baked in that I mean I don't want to decide for anybody but it's I would lean with wallets on deciding what they are most comfortable with well if there aren't any other questions I could good wrap-up um yeah yeah I think this is I think I covered everything I was hoping to about this so thank you so in terms of next steps here what do you think is the best way to get like more community feedback unlike the tip vs. escalator and and if and how they work together yeah I I'm wondering how we can kind of get to a point where we we have like a decision on that they're like a consortium of wallets we could consult yeah I think that would be valuable to have like a thread on each Magicians sharing kind of these high-level markups and and we can I don't think there's a consortium of wallet but like we can probably reach out to you know different different people in the space build buildin wallets um and get their feedback that's great so there was one other point just just worth highlighting through there was the the concerned raise just if in the scenario that miners colluded to include under half full blocks ie eliminating the base fee as much as possible and the tip does become the primary bidding parameter and and so it might be valuable for us to incorporate escalator like interface even in the case where where we are trying to uphold the 1559 type max feet interface yeah I mean I'm just like partly strategizing right guys a wallet developer I'm not sure what miners are going to do so just being defensive for users we it like we are weighing like is it necessary for us to pre strategize for that happening there is one minor idea that I had yesterday and maybe it requires some validation but if we think of the half-full blocks at our goal then can we actually incentivize miners to come back to that base fee and a half block by burning some of the miner reward for the unused gas both below the half so if you have a block that's 60 million or 20 million however calculate that so if the gas is not used up to ten million then smaller for the block I understand bad implications that a security of such a block falls down in the case of network under utilization so if you can have multiple amount for the network you actually will just decrease security at same time it acts as a mechanism of prevent owners from going below the minimum just to decrease the base fee because it will hurt their rewards hmm I mean I guess the challenge is kind of designing that kind of mechanism correctly because like the thing that we're targeting is not a like every block being in 50 percents right the thing that we're targeting is a kind of medium run average of 50% so Uno would need a lot more thinking in this idea is kind of very in a paper by Basu like you only give a full reward to the miner if block is full enough but it's with a different mechanism so I don't know if it would work yeah probably yes but then you would have a lot of I guess stuffing like the 900 might be incentivized to put his own transactions so you might have more heavy blocks even though the transactions are kind of know like just less so I just clarify here this is the idea that if we're over the target gas limit that the portion of the base fee would be burned or as a year under it it would be rewarded to the miner so normally they called base fees being burned but we could change the amount of the burned fee to be like split between the miner reward and just lost forever depending on how how much the block is filled with day transactions there you still would prevent this incentivization of the miners to include more transactions because they would still burn some of those fees and only some of them would come back to them so there would be in loss if they just generated fake transactions but at the same time there would be incentivized to include the actual transactions from the network I just think that's like this ability to burn some part of the fee gives us a lot of opportunities in the future so I just just give it as a idea for future I would like to make the ERP one fifty five nine nine at this time to be too complicated so maybe just something to think of for the future I think we'll have a lot of opportunities to introduce more things later thanks the having the minor tip be an escalator is actually like it more I thought about it is the best defense against minors like pushing down that value too much because there's a natural pressure to push it back up if there's an escalator telling them they're gonna whoever whoever is the one that breaks gets paid more like whichever miner and like they just will because the escalator can do it that the simplicity of that I really like so I've actually really liked the combination of those proposals thinking back for Dan to your designs the when you're like I I'm no I'm not a wallet designer and things so I but I'm wondering the choice that abstracting out like base fee and the minor tip and versus like having them have to set them the choosing max fee or you could you could choose base fee and then the minor tip which ends up being max fee or like what was your thought process when or design goals when you're going going into that I'd like to kind of hear more from the wallet maker point of view yes can you restate the question so yeah the part of abstracting out the base fee that's happening yeah oh so like so let's say for the happy path like where we're trying to make it as simple as possible because I think one of the goals is giving the simplest possible experience especially for next block inclusion so we aren't showing the base fee here but we are actually kind of hiding and representing it as an expected for you to be honest so this actually is the base fee we're not calling it the expected feed of the user the reason for that is just because we're trying to convey to the user what what is really relevant to them and so in terms of what it means to the user is it's kind of the top of the bell curve right is it it's a likely amount that they do Hey and then that really isolates it and separates it from what they're adjusting because if we put this number up front it looks more like it's the actual number they're gonna pay and could make somebody feel very uncomfortable if we're like suggesting a default like a ten dollar transaction or something yeah realistically it's gonna be less than half of that or something probably so we wanted to emphasize the expected fee without having to make every user understand the algorithm so then in this case the minor tip is kind of hidden in the 0.42 yeah in this one this is kind of assuming the the happy path where maybe the minor tip is hard-coded or you know insignificant enough in most of the cases that we can just leave it alone so so I wanted to represent that even though even though my greatest fears are that that's not the case I wanted to reflect that and and show how nice it could be okay so then in the case that you would add something under here so if if we did have minor tip be a choice in there would you have them like to say so the expected fee is being bad and then the max fee is the escalator top and the expected fee is the beginning of the escalator and then there would be an option for a minor tip yes we were composing them yes sorry we should have a third batch it was near the end of this process that we realized they'd actually couldn't compose I I think that when composing them it ends up looking a lot more like the escalator because it tends to have the more complicated inputs you've got like four well yeah you've got you've got two starting them out and you've got a an ending amount and you've got a range so you've got like three parameters that's a lot to put in front of a user we were kind of trying to simplify it here in this case you know we can say what the range will be and we can could even say what it will probably cost and but yeah it's it's likely that if we want to combine the two that it'll it'll inherit the complexity of the more complex over them I like having the expected fee in there as a ab stress like letting them know base fee that just sounds nice to have them have the information and then having the the like fast medium or slow be representative of the tip that they're going to be putting in and have that be like an escalator so I'm probably expected at the top of this and then that just be so so we can separate the expected fee and even the max from the time preference so that'd be like a another way of combining very cool I like how this is making my mind like like puttin in thoughts that I hadn't thought before yeah yeah yeah that's definitely the goal feel free to clip around and rearrange we'll we'll make these designs available after the call and feel free to make franking designs and see just other things cool okay the next thing on the agenda was talking about non proof of work networks so basically what would happened the public networks running click as well as private networks so that run different consensus algorithm do you want to have 1559 it for all types of consensus mechanisms or is it just a proof-of-work vania yeah so my concern about it was you know usually when you use private networks you set on all four blocks to zero and because this EPC is designed to be a transition from legacy transactions to new transactions and also new block header fields for example let's say do we want to allow to start directly with only 1559 transactions and it that in that case we will have a part of the gas food available for legacy transactions that will never be used actually so yeah and also maybe that would mean that we we should make the transition period configurable I don't know but yeah you know because if we applied directly each 1559 rules we might have some issues on private networks yeah it was my concern is there value to have in 1559 in a case where you don't have miners and on most networks that are not main net you don't have this like congestion / first price auction problem but then the problem is you have test ads that don't reflect you know main that ya to click networks have transact to have congestion problems like they or is it just that they don't because they're not maintenance they're not made net and because the blocks can be produced quite rapidly right like you can set the block time on a kick networks to whatever you want yeah it's a combination of post factors the network is armed generally and in the block size - yeah yeah yeah maybe we can say it does not bring value and consumption network so for me I think we should bring it up at an awkward s call yeah so other clients can chime in yeah make sense like here I think Peter or some of the other guys who wrote the click spec yeah and I think also it might might be just like a separate EEP like maybe you know there's a there's like a 1559 equivalent for non proof of work that works but because there's like all these particularities you maybe want just like a different spec for it or and maybe that could be done in the future as well like it doesn't necessarily have to haul all be done at the same time yeah doesn't make sense that would fit with the existing there's an EIP for click network for that define kind of click networks so you could that's like a good pattern for what's happened previously ok good anything else on that last thing so this wasn't on originally but I kind of got brought up in terms of having more test nets and stuff like that like what do we think are doing next steps here it feels like there's a lot of just community consultation to do around both the UX of it the click network stuff we talked about and just getting some some tidying up to do in the EEP with regards to the block size so does it make sense to start taking talking about like more public test notes now or should we just kind of get all those things done and maybe you have another meeting in a couple weeks to discuss that specifically I I may have unpopular opinion that the test nurse will bring us barely any benefit in simulating the behavior of VAP one five five nine because we will take from Jeson would need users I think simulations would be better yes for Gaston's I think one test that can be enough to move Roxton half half to create 15.9 and the standards transaction processing and see accounting remaining wallet developers and users feel about the change we had well earlier we talked about rolling out a new proof of wear test net and so it made you to be good to start it with this on this way I guess and if you think about moving something instead of Wroxton because it's nice to be ignored a cycle so what about deploying called the contracts and the new network as well but I think everyone will welcome so basically you start a new proof-of-work Network and I guess you started in kind of the legacy mode you that everybody deployed their own contracts for I don't know if say the first million blocks or whatever and then and then you add the IP 1559 you basically hard 40 IP 1559 pretty early on correct no maybe started straight away with 50 50 because if people have to do a lot of actions need to deploy things and we'll have a great testing ground because oh yeah that's true yeah yeah yeah that's what I was thinking too yeah that's a really good idea and how I guess before we set that up we probably need resolution on both the escalator fee and and the fixed versus variable block size correct or do we just set it up with 1559 as is today and we basically hard fork it as we make changes in in the each specification I think we should have a pretty stable spec before we okay to New Testament yeah I agree and I think you know everyone here also has like a job like nobody I think is working full time on this deep and it feels like we do have a couple things to figure out over the next few weeks so then maybe on our next call once we have better visibility on respect we can discuss just the kind of how we how we go about launching that's not it seems it seems like it would be nice to launch something that we could destroy easily and then iterate on that and then say this will be the the real one and then have and then have that be part of sunsetting robson there is one thing like I feel that many users are waiting for some replacement for robson which would be still prefer Florrick but would be much smaller and easier to sing and since give me is already like nearly three million blocks and in the past we are spawning new test nuts every two three four million blocks there's only great incentive to people start deploying things if we tell them that this is something that will destroy later nobody will move their contracts there do you mean and I feel like oh my god well you're you're suggesting building earlier ones that we are going to destroy and then and then telling everyone this is the one to migrate to later was that what you're suggesting or I mean if you think about death only test nuts maybe we can but so I don't think they'll be that important as the actual new proof-of-work Tesla that would have VIP 159 that everyone would feel invited to and see as an opportunity to replace Ralston we yeah I I think that makes sense and we that's also something we should probably bring up on the Chordettes call tomorrow I'm to get other people's thoughts but like it gives us the time to get to a stable spec you know not necessarily fully stable but say 80% of the way there we can also like have more of a like better communications to the community like hey this is the test net you can join it today you know it's gonna be a bit rough but it should be mostly there and and similarly at the same time say we're kind of phasing out Rob's tin as this other test net becomes more and more battle-tested the just thinking about how we're using the the ephemeral test net or basically testing consensus between client implementations is there value in doing that kind of a thing first as part of just making sure clients are agreeing on what the specification is before we do that so I think this is what the base you and get team already have kind of it's not a public that's net but it's like a local test net on our machines yeah but I agree having something more repeatable and with you know because it's a test net on the local machine with no automation etc so it's not really repeatable so and it's only get invisible and I get from the sauce PR so we should maybe use some release Briand or something like that I don't know but I agree we should it will be nice to to have a test net easy to deploy and easy to destroy him with all client implementations so then should we do an ephemeral test snip for 1559 where that kind of involved and that week you could roll that out earlier before things kids fully specified even yeah is that something you could lead yeah we know what that means so what guess does they use like like I don't think I'm basically spent much time looking into how it actually works we can probably look into it and and we will be kind of anyways for Berlin that week so we could have a gift for thrown puffeth and then you in and base you sink to that yeah something like that yeah yeah we can do that I guess the short answer is we don't know yet in the end so the only thing that we need for spawning ephemeral test and if we decide to have one is just sharing the chains back Genesis violin and that's enough and it will be more important to have a speck of the ap1 five five nine to be finalized rather than just prepare infrastructure infrastructure everyone will be able to spawn their notes and connect whoever starts it it's super nice you know it might be more complicated than than that because we decided you know we said we don't know the optimal numbers for the parameters for of this EEP and we decided to make those configurable so that we don't have to rebuild every time we want to test with different parameters so that means is that we will have to launch multiple ephemeral test nets with different configurations to find to find the human numbers this is what we said but I don't know if we still want to do that this is a nice add that I think simulations would be better than spawning those chestnuts but how big will be the effort to build asthma laters it will be lowered and analyzing the data from the testers and less expensive I think spawning that many gas plants will be quite expensive yeah previously looking at simulations it's very expensive I get like doing robust simulations is one of the hardest things have been tried that has been that to get done for this because the Costas ends up being really really high like it's kind of separating concerns I see value in or and clarify if I'm off on this that having having all of those different variables making sure that clients come to consensus between the different variables being different is is valuable to have and then the layer on top of that is what is the optimal version of those configurations yeah okay so two different concepts yeah yeah so like the the ephemeral Testament I think would solve the are all the clients agreeing on what yeah here Google things do and you could you can test stuff that wouldn't necessarily get you to the ideal configuration but even the next step would then be identifying the ideal configuration the or iterating on it but yeah you kinda need both is that does that fit Thomas or does that uh makes most definitely I'm not against it it's just I was weighing this to disabilities I'm thinking of what is more useful but I think every team and we together we should supports the effort so if you if you consider this as the idea that would help a lot on some field then I definitely would joined other effort sir yeah and I think that that's probably one of the concerns as well right where it's just like the skill sets we need to do simulations or kind of different from doing the test nuts and and I think if if neither mine can help other simulation slides there's a lot of value there I'm not sure on the basic team we can help much yeah I'm happy to like simulations have been trying to do some but I think it'd be good like to also have like good client perspective on what to simulate exactly like how do we make it robust the taxon I use that kind of match reality as well so I think that's kind of the expectation from having a test net that we can add like real data but it's a yeah it's not incentive I so if it's not congested it's not clear what we get so I do agree that simulations can be we were blessed to have Barnaby's thank you yeah yeah and I think we can look at help I guess when I say we I mean I'm Dylan Ian can probably help fear of those like use cases or scenarios are you're on the discussion that BA maybe I will be happy to have a chat with you yeah yeah I am happy to chat with you okay nice I don't know what is your handle that yeah I can find you I don't know okay okay sounds good also was there anything else anyone wanted to discuss I had a question on Twitter that I didn't know how to answer Alfred let y'all put in it came from Alexi and I what happens to the the pool I like I'm not sure yet if the transaction pool behavior is clarified in the EIP or whether all transactions can be readmitted to the transaction proof once base fee goes down its congestion eases like actually they'll will like will they be kicked out of the pool or if you have like a I guess base fee goes down are things included like men pool holds on to those or do they get rid of them good question yes what would be the right way to speak to think about this I guess the right way to think about it would be that there's some fixed amount of memory that each client has in their pool and so the clients would just keep kicking out the transactions that are leased for like we'd ever be included I think we can leave the mental behavior exactly the way it is because at the moment what we do is I think in most of the clients and if not all of the clients the member just holds the best ex transaction sorted by gas price taking into account also if they nonces aligned with the nonces in the state which means it doesn't change even if the basically is there is just the block producers will not be including the transactions that are not meeting the basic criteria but still the transactions will be ordered by the gas pricing in all in both cases there's IPS in behavior and there is no need to drop them because you have expectation the device we can go down and you don't have any better transactions anyway so your mam pool will be limited by the limited mental as it is now I think they can stay there and wait for the better times and from a wallet perspective we of course remember the transactions you've sent and we periodically resend and if you are blocked for a very long time provide speed up or cancel options so yeah it's very similar to today in that scenario okay and as from like a mechanism perspective as if I had a low base fee with a high minor tip then theoretically it would take longer to get to my base fee even if my minor tip was larger I guess depending on how we like if I had a dollar base fee and a 50-cent minor tip versus having a $0.

50 base fee and a dollar minor tip then theoretically the the larger base fee would be included first I think you mean max feed but yes it's gonna come down the max fee is gonna it applies to the tip okay so then we we don't we the transaction sets the max fee and then as things go down alright that helps thank you is it worth like specifying kind of that we're keeping it the same as far as mempool and things go or or like making that more clear from the specification perspective the mantle is not really specified in any description of the consensus or papers every client manages demand for their own way they happen to be doing that similarly but I don't think we need to add these into consensus or this discussion as long as we don't raise concerns from the client a developer's perspective I think it means that as fine cool I guess one question I just I came up with me when you were talking about like max tip where is this max base fee owning theoretically make sense to switch to specifying just a max tip and the max total by the way you could never end up in a situation where basically a max tip plus max base we would have been sufficient but just because you specify the high tip but not a high base fee your transaction can't end up being included you I'm liking it I describe it again yeah yeah maybe as I'm just came up with the no so it might just we'll be overlooking something but the idea like basically the example there but they like 50 cent and base fee and one one dollar and tip was the other way around there could be a situation where you would be willing to pay a high tip but just because your base fee your max base fee is a little bit below whatever was the current base fee is your transaction just cannot ever make it in but obviously that's not like your intent because you don't really care if whatever your pain ends up with a minor you only want like to have a maximum tip - so the minor conscious tech always take whatever your your maximum willing mr. pace and they just take that so but if you specify like the maximum tip you're willing to pay and then the maximum total you're willing to pay I think that would basically cover the situation where like like the you're basically willing to pay any base fee that as long as like the total you're willing to pay it's not basically gonna open at the moment if I understood what you were saying correctly what your space thing is not the maximum base fee but you are willing to pay but it's the maximum of the sum of base fee plus your tip so the typical said but if total of the two goes above your max P what you're paying as a user is kept to the to the next V okay one of the difficulties in having like let's say e IP one five five nine and B escalator together is that you the base fee might be increasing at the same time your tip is increasing so the escalator you have some certainty let's see the plain vanilla escalator no VIP one five five nine you have some certainty that you're going to reach your max fee if the number of loads that you specified but when you combine with two together you can have kind of like an additive effect and you end up like topping out at your max fee much earlier when you when you thought you would so yeah that's one of the difficulties I see okay I'm sorry for the confusion so with this look what the solution to that being having one of them being escalier and one of them not being so that there isn't that race condition I so in this limb but I shall die I kind of look at him so you start like the escalator or at the current level of the base fee but then either your escalator is fixed in which case you have certainty on how your tip is evolving but you run the risk that may be the base figure it's way over what your tip current please in which case you come into it so the better idea and one in which you can also reduce it to plane EAP one five five nine is to have like a floating escalator where you you like on the base fee but the tip is increasing as well so what you pay is the current base fee plus the escalating tip but then you have this additive effect where if base B is increasing and your fees also increasing your tip is increasing you can reach your max P yeah quite fast but so I don't know I I don't know if any of these designs are reasonable I think floating escalator is the most reasonable I don't know where it solves like the issues we want to so maybe that's something which will be nice to simulate action so thinking about it from the user perspective I've I wouldn't mind if it escalates to my max V quickly if that means it gets in thank you this from how to how do you analyze it like impasse which makes it a bit like no trickier thing but maybe maybe it works in practice like Miss Canadian feeling with ease it's really to give the information that you want to go above everyone else faster so where is everyone else kind of like intuition is that everyone is at the base fee or just like an episode on the book and so escalating the tip means you want to get like ahead of the crowd so yeah in case you're mad max fees which earlier then I guess you should have trained well if you want a bit faster so also assume the version with the escalator would be more complicated from a mental perspective as well because like ordering then all of a sudden isn't straightforward anymore you could still order by tip or by max fee - the remaining tip in case you are not I think the ordering would still be ok but I do think you need to keep around to answer Alex's questions I think you need to keep around the transactions even if the base fee currently too high I can't think of an edge case where it's only too high for one period and then it goes down and somebody will submit to the same transaction as mine and gets faster like I've waited all this time and I only got kicked out of the metal because of this one block deviation I don't know if it's really fair like it's a good idea but I also don't know really how the transaction pulls out - right now so it doesn't work Adam I think it does complicate it a little bit because right now it's ordered based on the gas price whether or not that's the legacy gas price or the EIP one five nine gas price and so if there's this escalation occurring from block to block then the mempool will essentially have to refactor that price that each block could reorder based on the new price also more more operations but it is collects but it's also it's just be esqueleto it's kind of Union so you have some expectation on the price but yeah maybe it were some issues I'm not sure in any case I don't think that's a good enough reason to dismiss it as an option anything else people want to discuss okay so I guess in terms of next steps there's a couple things that we're gonna bring up on the courthouse call tomorrow put his mock-ups on tradition thread somewhere so we can try and get more attention from the community on them in terms of simulations I guess Barnaby and a bell you can have a chat and see how to get started there is there anything else talking about all this networks yeah yeah awkward yeah and then splitting the eeap's or a ding in a fix the minor the gas like change minor guest consensus decisions VIP yeah and [Music] getting fevering I guess it's not nest at which is something to figure out is how to get more feedback on some of these design things yeah so I think once we have them up on like eath magicians and and dan has has his has has kind of is how you call that anyways the link where you can see the design set up then we can reach out you know the people are like my crypto at coinbase wallet and and under wallets in the space and try to get their inputs I'm happy to take the meat on that coop and then there was getting the if we are gonna do an ephemeral net that uses puppet or they said something how do you approach that and who's gonna do think we should yeah we should ask on our core devs and see you know what's the what's the overhead of doing that and and yeah what's with the value okay that's the ones I'm remembering cool they failed oh and yeah I'll ask so because several people asked for the recording I'll see with Hudson if we can maybe just straight-up upload this the etherium YouTube because especially Dan's presentation was was just pretty great and I feel like you know the the transcript will never do it justice so yeah I'll see what Hudson if that's possible otherwise if anybody on here once the zoom link just pay me and I'll send it to you yeah I'm sure the transcript will be great by the way but yeah the presentation okay uh yeah thanks on everybody yours thank you thanks for hosting this too this is of course thank you so much