# EIP 1559 Implementer's Call ### May 28 2020 _pre-meeting chatter_ 02:55 Recording to the cloud yes, so thanks everybody for showing up second 1559 implementers call. I'll show you agenda int the chat; it’s pretty lightweight so there's other stuff that people want to cover because if you have time for but a high level wanted to start with just some status update from implementers. 03:13 Then there will was a PR that Micah Zoltu hope I’m pronouncing His name right I put that basically the basically changes 1559 to not set a fixed block size, but instead still leaves the miners the ability to decide that and just still aim for 50% 50% full blocks. After that, we'll have Dan your mockups then Abdel had some questions around consortium networks and then anything else people want to chat about. Yeah, so I guess for for status updates Ian, Abdel I know Barnaby you had also some stuff you were working on so feel free to go. Yeah, I can start talking about besu... so last time we said we will implement the possibility to make all those parameters configurable. 04:09 So we did that. we tested the also we get implementation into a small local test net and we are aligned with the spec for the moment and, We are waiting to see about the remove for riders proposal. Yeah. 04:34 Ian: Well that's pretty much covered with my update. the only thing I've done since the last meeting was introduced as can take options for the different parameters. Yeah, as I said, there hasn't been much. I still need to do rebates but at this point I'm kind of putting that off as long as possible because I know they'll be more rebases going forward. 04:58 Abdel: I can go next and hi everyone. I've been working on like it's a free 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 EIP1559, how would we do that? So try to explore this question a bit. 05:20 I've put a link in the discord to note up to like 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 EIP 1559 of having this base fee. But also like the idea or the escalator of that we can solve the climbable. 05:40 So yes, I can I'll do that. 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 what time the kind of default values we expect for users who are signing their transactions. 06:04 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 bid given let's say their value for the transaction or different value from time. 06:22 That's not clear to me and I think it's a fairly difficult problem that could use like more eyes on. The third thing I wanted to do was more of like a data analysis of current and past transactions 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 on the EIP 1559. 06:49 I think we can still get some ideas about the preferences currently of users for instance. I was planning to look at how people maybe are replacing the transactions on the mempool, so that gives you like an id of they want this to go faster, so They have a higher preference of time like I wanted to use these kinds of natural experiments to get like a better understanding of this and I don't think it has been done before but I'm also not fully aware of everything so yeah if I was kind of my my three things. 07:24 Oh thanks for the update and I see we have Tomasz and Artem on the call, so is there any update from Nethermind or Open Ethereum? Tomasz: Oh yes sure so far. I've made a lot of research so I've read every single post that's all of you guys ever produced and you were quite talkative so it was not an easy task :) So far I really liked what Barnaby was creating with his like agents agent modeling this simulations I think this is the way to go and I'm analyzing all the different approaches and so for me. I've been studying implementation but will be ready to all the code if needed we definitely will have the last work for now. 08:09 Since we don't really do the proof of work mining so initially have to worry that much about miners one thing that I've never seen being mentioned in your discussions, maybe once shortly mentioned by [name] was they how we'll decide to introduce this new transaction models into the test networks like rinkeby and gorli but it will just stay with the old transactions forever or will move them all to the new model which may be not necessarily has the same meaning for the networks where you don't have miners. 08:44 So be great to have the decision here how we how we handle those other networks yeah. Tim: I think that was Abdel's point as well on the agenda around like for besu as well but yeah not group of work networks, so yeah, we can definitely dig into that a bit more today Art then anything from you? 09:04 Art: No, we're currently focused on Berlin hard fork, so 15-59 is not on our immediate agenda right now. Tim: Okay. I'm. 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 me. Basically still living that to minors like like is currently the case. 09:40 Michah could not make it to the call but yeah, he was curious to get people's thoughts on this DR so I don't know if anyone has strong opinions on this. 09:56 Unknown: I think it's fair point and introduce the change that is not really the main focus of the EIP15559, so I'm in favor of because PR. 10:13 Artem: it seems to me that as long as the miners are not moving the block size as fast as let's say the base fees 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 too strategic if I can only move the block unit by let's say one percent of the block or less than that the base fee I think is allowed to change by over 12.5 percent each 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 modelling on this. 10:55 Tim: Yeah, what is the the max that miners can push a block limits for block right now? Vitalik: It's either one over a thousand twenty four one or one over two thousand fourty eight every block, I forget but its definitely one or one of the two. Unknown: Which is way way less than twelve percent Tim: yeah so that okay does any so I guess yeah, does anyone think that is PR is a bad idea? 11:20 James: Um, I would. Hmm so 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 noticed in the are 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 the thing to being protocol specific and then 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 isthis version that doesn't have it and we can have an EIP that changes it to a fixed and then have 50 59 require it and then kind of further just figure it out like I like the idea of removing the rider is what I when I'm saying but I'm not necessarily sure that that means we should not do it. 12:27 Ian: 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 not super passionate about um about this choice. I'd be fine either way. I think in general, though. The state of the EIP should be determined by what is best for the EIP. 12:45 Not you know, what is best for the perception of governance? That's just a personal opinion. 12:59 Tim: How realistic would it be to say add, you know the fixed block size or like the block size determined by the EIP in the future? 13:12 Say we wanted to separate those two proposals, how like modular are they? Ian: 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 it one direction or the other. 13:40 Tim: So I know and I know in the past we talk like we're all want to have test networks up at the 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 the testnet 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 Ian just add it back and it's a very small change. 14:12 Ian: Yeah, I think that is the best approach is to test both cases and actually figure out which one is the most sound implementation. 14:25 Tim: So to be fair you'd test both in parallel? Ian: Well, I guess at this point we already have tests underway for the current limitation. Yeah. So. Yeah, I guess to people we can add it on in parallel but it's I should defer to Abdel here because he's the one actually doing the testing. 14:44 Abdel: Yeah, if we want to test both in parallel, I would advise to make this configurable as well to have a flag to enable or not the riders. Yeah. Because we already have the implementations so I would not remove it too soon. I would say. and maybe it was testing with large case simulation. 15:14 And see the impacts impacts of both approaches. Unknown: Is there is there any timeline and when a test will start by in terms of networks? Tim what was done? Tim: Not yet. I think yeah, we wanted so now we're at a spot where you know, the geth PR and the besu PR work together, and we've run small local networks, but we don't have anything like a public network yet. 15:40 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 I think yeah, those are definitely things we could try on the test network, but no one has like volunteered to step one up yet, okay, thank you. 16:16 Tim: So in terms of next steps for Micah's PR. Should this be merged in then or should like yeah. I'm not sure how we keep both in parallel and and. Yeah. It almost feels like that you like it was very good. Abdel: 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 I'm able to mainly a simplifying measure. 16:51 Vitalik: I mean, it was basically there was like a field in a block and then that was used for the gas limit and we need to have a field to store the base fee so we may as well just repurpose an existing one because that's easier than changing data structures Abdel: hmm, okay, so it was not correlated to any economic concern or --right yeah, okay. Tim: So in that case what it makes sense to just merge Micah's PR assume we're still keeping the miner 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 fixed block size that that's a solution. but it feels like right now it's it's probably gonna end up being simpler just like politically to have this be a smaller change than than to have it also takes like change the other thing with miners if there's no strong need for it. 17:44 *general agreement* Get that makes sense to me yeah that seems reasonable to me. Unknown: would be great to have the the other PR open other EIP also open before we merge when the writers. Tim: What you mean by the other EIP so it's a the PR right now is that PR *to* EIP 1559 --right and somebody brought up making an alternative PR oh my block size change so basically like the reverse diff of this PR exactly yeah, okay. 18:18 I'm much you know, so it'll be a bit to fully detail it out but just having it open to track it would be great. James: I think that's I think the way to do that would be to propose an EIP to change the the minor to being a decided on the protocol level and not I'm like removing that part and then tagging 1559 saying that this is an option that at my require it. 18:48 So if you choose to do it, then you will require that the EIP that fixes the miner gas limit. that removes that the minor control like right in the IP that removes my miner control of the gas limit and then have and then have that be an option will requirement for 1559, so it's easier to discuss the two. 19:09 Abdel: Do you think do we think this change alone will have sense without the EIP 1559? I mean, if we create a separate EIP for the writer, could we let's say we don't implement the could this one be implemented without in 1559. Tim: I guess what what you're saying by that is you you make it require a consensus fork to change your block gas limit which for my perspective seems like it's probably not the best idea but yeah, I'd be use cases for that well. 19:47 I like the idea of like just separating the concerns of making it kind of clean that you know, EIP 1559 does not require that but then but then there is this other EIP that we could add to 1559 and, Does anyone want to to kind of open that that the EIP and and and and then we can merge Micah's PR? 20:14 Ian: I can do it okay thanks again, so yeah. 20:24 Tim: Once you have that then we can merge Micah's PR and I guess we kind of have consensus that like it's it's like the client teams want to keep working on 1559, we can implement it in the way that's described in the PR for Micah that makes sense. 20:40 Yes, yeah that makes sense to me, we will have to make changes to refer to that. Yeah, yeah, yeah, that makes sense. 20:52 Tim: Cool. Anything else on that? If not, Dan you want to walk us through your work? Dan: 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 Metamask and we did a good exercise and we you know, we sketched up a whole bunch of ideas both for 1559 and escalator algorithm and I don't know before I start I do think there's some possibility for. 21:38 Composability and in retrospect having now come through more of a exercise but let's dive in 1559 first so I think my favorite one for 1559 is probably like this one is let me see if this was very different yeah. I mean, maybe we can do something yeah incredibly simple yes, so so maybe this is like an example of what we're saying so 1559.  22:04 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 to be able to expect a nice low time. And the users only primary expected parameter is the fee and we think that we can make it very simple to you know, represent different orders of magnitude for the fee 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 tips that were included on those given blocks moving over time the blue line representing what you are current max or how far it is over the recent block average that's that's also alright and pretty easy to do and then yeah, I think this is this is kind of an unlikely worst case.  22:58 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, seriously more expensive blocks and interior you're gonna approach a block that is not including transactions, but we could we could anticipate a curtain a current assent of lots and we could maybe estimate higher. 23:23 Oh also to address a barnabe he was asking what we might suggest in terms of defaults, we discussed that a bit and we were thinking a initially probably a multiple of the current base fee so if the current base fee is you know, if the last block space fee was 21 cents, then we might see just double it or something as a as a max fee and then suggest increments over that that way it's more dynamic. 23:50 I don't think we would want to try to hard code the that fee. this should be user defined parameter. Something that's maybe not that's a sorry different design okay something that's maybe not represented there was a there's a question of oh that the tip parameters like hardly represented here at all yeah, oh you can see it on the edge here we're thinking maybe it should be set below or the EIP suggests the tip could be hard coded by wallet. 24:21 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 everyone like what should we set it to? should we set it to 2 gwei? My impression is that this could create a bidding war between wallets, like no wallet wants to be the 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 it like tapping out exactly and and that's actually one of the reasons why I kind of have come to agree with Micah that the tip parameter may actually be eligible for if you're going to compose with the escalator algorithm. 25:00 In terms of ways escalator algorithm could work. Yes, so in the basic fee we should be able to provide an experience that's very familiar to users where we've got fast and low prices and And so these defaults would represent like slopes that are kind of invisible to the user.  25:22 But for advanced users, they could define their their men and their max and their time preference and possibly even see a visualization of it over a lot of recent transactions, which is a pretty cool way to do it. And the reason I think that this can compose with a with 1559 is because both both algorithms use a max bid parameter. 25:45 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 fee 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 to your higher prices faster, but you'll still be within this range at least. 26:07 And it solves the problem of 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. 26:28 Yeah, anyways this these aren't like designs that we're necessarily committing to or saying are definitely the best these are just kind of what we came up with after a couple of questions and you know can service a starting point for you know, community discussion about how this would invest your representative to users. **Appreciation for Dan's work all around** 26:48 First grade, thank you so much. Yeah, yeah, thank you. This is great work. Yeah, thanks yeah. Shout out to our designers. I hope the three designers hear. So Rachel code, Jake Hogan and Christian Jerry. Yeah, this is awesome. 27:12 James: So you 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 they're better. Dan: Yes, so so there's really there's two parameters on each transaction that are related to 1559 the max network fee and here you can see us representing it as the user's own preferred currency so you could say we can say maybe I don't want to pay more than 15 dollars and then we can divide that by the estimated gas limit and the gas price and then and we're able to give you. 27:49 A max fee and that's that's some nice user experience However there is a second parameter that's a tip and and that one is it's it's supposed to be like kind of trivial I don't know if somebody else wants to take a swing at the role it's to include to preserve miner incentive is my understanding because if he didn't have the tip at all, then the entire transaction fee would get burned. 28:11 And but but it is the the remaining minor incentive. And so within a block it's the only thing the miners getting and so there is a in incentive preserved 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 your tip is low you'll be in the next block but but as a wallet I don't if if the 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 explaining that but um, So if there is a sudden search where a block is full then the my enters are gonna pick the highest tips and wallets are currently advised by the EIP anyways, to hard code to tip. This puts wallets in a weird rival risk position to make their users pay more. 29:04 Ian: Could you possibly um hardcode it as a function instead of as like a static value? Dan: yeah, I mean we could we could do everything that we do today because you know as some of the criticisms suggested a tip becomes another single price auction, like in 1559 is trying to avoid so we could do all this stuff that we're doing today and you know, the good news is it only applies within that band so and into you're still a subject to the max fee, so that's that's nice but yeah, it doesn't mean that we we might have to preserve for example our current bidding logic under the hood and just apply it to this smaller within the block auction. V: The other thing you can do as you can use algorithms that look at kind of what happens to previous transactions to adjust the chain like you could do something that says a the tip keeps on decreasing by 10% every time you send the transaction until you notice you're your transaction not getting included within a block and then it jumps up again. 30:05 Dan: Yeah yeah, we could do that we might want to look at what other transactions are doing too but yeah like seeking the minimum tip definitely seems like they're like a component of the right strategy. Abdel: The designs are really cool Dan, thanks. one thing if all the tips are set to the same value. 30:24 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 like regardless of the price. I have a very high value for it, so how does setting like a uniform tip is not able to discriminate between let's say the users who have high value and users for a low value, so. 30:52 Perhaps like also a tip which is a function of the max fee like if you set a high max fee you tip a little epsilon extra. I think something like that might be reasonable. 31:05 Dan: Yeah, 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 user may just steadily have more they're willing to spend and now they're permanently paying more maybe that's not the worst thing yeah, it's worth considering. 31:33 James: From 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 the risk of it the uncle risk for including a transaction is pretty similar. For whatever that is so that is theoretically where the it could be the same and it could always be the same in minors would accept it if it approaches that about value. 32:03 But I mean you guys are the wallet people so I got as far as choice and suggestion versus baked in I mean, I don't want to decided for anybody but it's I would lean with wallets on deciding what they are most comfortable with. 32:31 Dan: If there are any other questions. I could wrap up. Yeah, yeah. I think this is a I think I covered everything. I was hoping to about this, so thank you. 32:49 Tim: So in terms of next steps here, what do you think is the best way to get like more community feedback on like the tip versus escalator and and if and how they work together? 33:04 Yeah, I am wondering how we can kind of get to a point where we we have like a decision on that. 33:13 James: is there like a consortium of wallets we could consult? Dan: there's the Ethereum magicians it's pretty much the closest thing using the wallets tag. 33:26 Tim: Yeah, I think that would be valuable to have like a thread on each magicians sharing kind of these these high level mockups and and we can I don't think there's a consortium of wallet but like we can probably reach out, you know different different people in the space building wallets and and get their feedback. 33:46 That sounds great. Dan: So there was one other point just just worth highlighting through there was the the concerned raised just if in the scenario that miners colluded to include under half full blocks. I 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 doing incorporate escalator like interface even in the case where where we are trying to uphold the 1559 type max fee interface. 34:23 Yeah, I mean, I'm just like partly strategizing like as a wall of developer. I'm not sure what miners are going to do, so just being defensive for users we it like we we are weighing like is a necessary person pre strategized for that happening. 34:47 Tomasz: there is one minor idea that I had yesterday and maybe require some validation, but if we think of the half full blocks as our goal then can we actually incentivize miners to come back to that base fee and the half block by burning some of the minor reward for the unused gas both below the half so if you have a blog that has 16 million or 20 million however calculated. So if the gas is not used up to 10 million, then there's more for the block. I think or something that implications that are security of such a block falls down in the case of network under utilization, so if you have much demand for the network, you can actually just decrease security. 35:37 I think I'm it acts as a mechanism of prevent miners from going below the minimum just to decrease the base fee because it will hurt their rewards. 35:54 V: Hmm. I mean, I guess that challenge is I know designing that kind of mechanism correctly because like the thing that we're targeting is not a like every block being at this percent. 36:12 The thing that we're targeting is a kind of medium-right average of 50% so. IDK would need a lot more thinking... Abdel: This idea is kind of very in a paper by Besu of like you only give a full reward to the miner if the block is full enough but it's with a different mechanism so I don't know if you would work with yeah it probably yes. 36:36 But then you would have a lot of I guess stuffing like the minor might be incentivized to put his own transactions. So you might have more heavy blocks, even though the transactions are kind of not like just fluff. Ian: So I just took clarified here, so it's the idea that if we're over the target gas limit that the apportion of the base fee would be burned or as if you're under it. 37:03 It would be rewarded to the miner. Tomasz: So normally they call 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 include more transactions because. 37:31 It would still burn some of those fees and only some of them would come back to them so they would be in loss if they just generated fake transactions. But at the same time, they 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 fake gives us a lot of opportunities in the future so I just just give it as a idea for future. 37:54 I would like to make EIP 1559 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. 38:12 James: The having the minor tip being escalator is actually my little more I thought about it is the best defense against miners by 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 even like whoever whoever is the one that breaks gets paid more. 38:34 Like whichever miner and like they just move because the escalator can do it that the simplicity that I really like. So I I've actually really liked the combination of those proposals... Thinking back for Dan to your designs the, When you're. Like I'm no I'm not a wallet designer and things so I I'm wondering the choice at abstracting out like base fee and the miner tip and versus like having them have to set the like choosing max fee where you 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 or design goals when you're going into that? I'd like to kind of hear more. From the wallet maker point of view yeah Dan: sure sure and and don't need to apologize that we're all users of this so you've got as much insights as any of us could you reset the question --sorry yeah the part of abstracting out the base fee that's happening --yeah, I don't know for it oh so like so let's say for the happy path but if we're we're trying to make it as simple as possible because I think one of the goals is getting them simplest possible experience, especially for next block inclusion. 40:01  So we aren't showing the base fee here but we are actually kind of hiding and representing it as an expected fee to be honest, so this actually is the base fee we're not calling it the expected fee to the user the reason for that is just because we're trying to convey 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's it's a likely amount that they do pay 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 going to pay and it makes somebody feel very uncomfortable if we're like suggesting a default it's like a $10 transaction or something when 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. 40:56 James: So then in this case the minor tip is kind of hidden in the 0.42. Dan: Yeah and this one this is kind of assuming that the happy path where maybe the minor tip is hard coated 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. 41:19 I wanted to reflect that and and show how nice it could be, okay. James: 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 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 miner tip. 41:49 Dan: Yes so if you were composing that yes sorry we should probably should have a third be at batch it was near the end of this process that we realized they actually could compose. I think that when composing them it ends up looking a lot more like escalator because it tends to have the more complicated inputs you've got like four, well yeah you've got you've got a starting amount and you've got a ending amount and you've got a range so you've got like three parameters that's a lot to 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 algorithm. 42:39 James: I like having the expected fee in there as a abstract as like letting them know basically that just sounds nice to have them have the information and then having the, The like fast medium or slow be representative of the type the tip that they're going to be putting in and have that be like an escalator so or I don't know. 43:01 Dan: Yeah, it's like I'm driving we can probably expect it 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 it that would be very reasonable. 43:17 James: Cool. I like how this is making my mind like like put in in thoughts that I hadn't thought before --yeah yeah that's definitely the goal I feel free to clip around and rearrange we'll make these designs available after the call and for free to make designs and suggest other things cool. 43:47 Tim: Okay at the next season on the agenda was talking about a proof-of-work network so basically what would happen the the public networks running click as well as private networks so that from different consensus algorithm, do you want to have 1559 for all types of consensus mechanisms or is it just a proof of work thing? 44:11 Abdel: Yeah, so my concern about it was you know, usually when you use private networks you set all fork blocks to zero and because this 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 EIP 1559 transactions and if that in that case we will have a part of the, Gas pool available for legacy transactions that will never be used actually so yeah and also maybe that would mean that we should make the transition period configurable. 45:03 I don't know but yeah, you know because if we apply directly if EIP1559, we might have some issues on private networks yeah, it was my concern. 45:25 Tim: Is there a value to having 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 sets that don't reflect, you know, James: Do click networks have transect to have congestion problems. Like they or is it just that they don't because they're not made it. Or Tim: I think they don't they're not main net and because the blocks can be produced quite rapidly, right? Like you can set the block time on a click network to whatever you want yeah, it's a combination of both factors yeah the network is our generally and and the block size too yeah, yeah. 46:23 Abdel: Maybe we can say it this this EIP does not brings value on consortium network, so non-profit networks, maybe. James: I think we should bring it up at an all core devs call yeah a good next step so our other clients can chime in. Yeah make sense like here. I think Peter or some of the other guys who wrote the click spec. 46:52 Tim: Yeah and I think also it might it might be just like a separate EIP like maybe you know, there's a there's like a 15-59 equivalent for nonproof-of-work that works but because there's like all these particularities you maybe want just like a different spec for it. Or and and maybe that could be done in the future as well, like it doesn't necessarily have to all be done at the same time. 47:22 James: Yeah, that makes us. That would fit with the existing there's an EIP for click network for the defined kind of click networks, so you could that's like a good pattern for what's happened previously. Okay good to know. 47:42 Um anything else on that. 47:48 Tim: Last thing so this wasn't on the agenda 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 the next steps here it feels like there's a lot of just community consultation to do around both the UX of it the the click network stuff we talked about and and just getting some some ideaing you have to do in the eip with regards to the block size, so. 48:16 Does it make sense to start thinking talking about like more public testaments now or should we just kind of get all those things done and if you have another meeting in a couple weeks to the the discuss thought specifically. Tomasz: I may have unpopular opinions that they fasten us will bring us barely any benefit in simulating the behavior of the EIP1559 because we would need congestion, we would need to users there. 48:40 I think simulations will be better yes for testnets I think one test that could be enough to move ropsten half half to to create 1559 and the standards transaction processing can see how the mainly how developers and users feel about the change. 49:00 James: We have well earlier we talked about rolling out a new proof of work test net and so it may just be good to start with this. Tomasz: so if you think about moving something instead of ropsten because ropsten is to beg nowadays. I feel. It's all about deploying all the contracts on the new network as well, but I think everyone will welcome that. 49:32 Tim: So basically you started a new proof of work network and I guess you started in kind of the legacy mode you let everybody deploy their own contracts right and I'll say the first million blocks or whatever and then. And then you add the EIP 1559 you basically hard forked EIP 1559 pretty early on correct? Tomasz: No maybe started straight away with 50 50 because if people have to do a lot of actions you need to deploy things then we'll have a great testing ground because oh yeah, yeah, that's true yeah, yeah. 50:01 That's what I was thinking too. Yeah, that's a really good idea. Um, 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 EIP specification. 50:40 Tomasz: I think we should have a pretty stable spec before we okay long junior testament yeah. Tim: I agree and I think you know everyone here also has like a job like nobody I think is working full-time on this eip and it feels like we do have a couple things to figure out over the next few weeks. 51:00 So then maybe on our next call once we have better visibility on the spec we can discuss just the the the kind of how we how we go about launching the test net. James: Yeah, it seems it seems like you'd 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 the and then have that be part of sun setting routes and. 51:26 Tomasz: There's one thing like I feel that many users are waiting for some replacement for ropsten which would be still preferable for it but would be much smaller and easier to sing and since goerli is already like nearly three million blocks and in the past we are spawning new testnets every two three four million blocks is always great incentive to people start deploying things if we tell them that this is something that we'll destroy later, nobody will move their contracts there. 51:58 James: You mean anything 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? 52:17 if you think about geth only testnets... But maybe we can but so I don't think they'll be that important as the actual new proof-of-work testnet that would have the EIP 1559 that everyone would feel invited to and see as an opportunity to replace ropsten with Tim: yeah, I think that makes sense and we that's also something we should probably bring up on the core devs call tomorrow to get other people's thoughts but. 52:43 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 a test net you can join it today, you know, it's gonna be a bit trust but it should be mostly there and and similarly at the same time say we're kind of phasing out ropsten as this other testnet becomes more and more battle tested. 53:13 James: The just thinking about how we're using the the ephemeral testnet for 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? Tim: So I think this is what the Besu and geth team already have kind of it's not a public that's not but it's like a local test net on our machines. 53:46 Abdel: 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 a repeatable. So and it's only geth and Besu and I build geth from the source PR we should maybe use some release build or something like that. 54:16 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 and with all client implementations. 54:33 James: So then should we do an ephemeral testnet for 1559 with that kind of involved and that we could roll that are out earlier before things gets fully specified even. Yeah. 54:50 Is that something you could lead? 54:56 Abdel: I don't know. We live like that man. I don't know what that means. Tim: So what geth does they use like a puppy? I don't know how to pronounce it anyways, but 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. 55:23 So we. So we could have a get fourth run puppet and then you and then base you sing to that. Yeah, something like that. Yeah. Yeah, we can do that. Tim: I guess that the short answer is we don't know but we can definitely learn that in the answer. Tomasz: the only thing that we need for spawning ephemeral tests that if we decide to have one it's just sharing the chainspec by genesis file, and that's enough. 55:48 And we'll be more important to have a spec of the EIP1559 to be finalized rather than just to prepare infrastructure infrastructure everyone will be able to spawn their nodes and to connect. Whoever starts it it's you better like, Abdel: you know, it might be more complicated than that because we decided you know, we said we don't know optimal numbers or the parameters or of this eip and we decided to make those configurable so that we don't have to repeat time we want to test with different parameters. 56:24 So that means that we would have to launch multiple a ephemeral testnet with different configurations to find to find the optimum numbers. This is what we said. I don't know if we still want to do that Tomasz: This is where I said I think simulations would be better than spawning those test nets Abdel: hmm. But how big would be the effort to build this simulators? Tomasz: It'll be lowered and analyzing the data from the tests and the less expensive. I think spawning that many testnets will be quite expensive. --Yeah James: looking at simulations it's very expensive. I get like doing robust simulations is one of the hardest things I've been that is the to get done for this because the cost is sensitive but being really really high like so to kind of separate and 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, -yeah so like the ephemeral testament I think would solve the "are all the clients agreeing on what the variable things do" and you can you can test stuff and that wouldn't necessarily get you to the ideal configuration but the next step would then be identifying the ideal configuration or iterating on it. 58:09 Yeah, you kind of need both. 58:16 James: That does that fit Thomas or does that a make Tomasz: no definitely I'm not against it it's just I was weighing this to possibility of something of what is more useful that I think every team and we together we should support the efforts so if you if you consider this as the idea that could help a lot on some field then I definitely will join that effort and Tim: 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 are kind of different from doing the test and and I think if Nethermind can help on the simulation slides that there's a lot of value there. 58:51 I'm not sure on the Besu team we we can help much yeah. Barnabe: I'm happy to give you a hand, okay like simulations I've been trying to do some but I think it'd be good like to also have a client perspective on what to stimulate exactly like how do we make it robust that have scenarios that kind of match the reality as well, so I think that's kind of we expectation from having a test that we can have like real data, but it's a yeah, it's not incentivized so like it's not congested it's not clear what we get so I do agree that simulations can be helpful. 59:30 James: We're blessed to have Barnaby's thank you yeah yeah, , Tim: And I think we can probably help. Or I guess when I say we I mean Abdel and Ian can probably help those like use cases or scenarios and environment. Abdel/Barnabe: I will be happy to have a chat with you yeah yeah. I am happy to chat with you okay nice. Yeah, I can find you. I don't know okay. Okay sounds good. 1:00:11 Is there anything else anyone wanted to discuss? 1:00:18 James: I had a question on Twitter that I didn't know how to answer. It. Like I'll put in came from Alexi. [tweet](https://twitter.com/realLedgerwatch/status/1265934357753139200?s=20) what happens to the the pool I as. I got I'm not sure yet if the transaction pool behavior is clarified in the EIP or whether old transactions can be re-admitted to the transaction pool one space we go down it's congestion eases. I actually will like will they be kicked out of the pool or if you have like a gas-based fee goes down are things included? By men pool holds on to those or do they get rid of them V: hmm that's a good question. I guess. What would be the right way to pick 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 kicking out the transactions that are least likely to ever be included. 1:01:29 Tomasz: I think we can leave them mempool behavior exactly the way it is so because at the moment what we do is I think in most of the clients and if not all of the clients the mempool just holds the best x transactions sorted by gas price taking into account also if the nonce is aligned with the nonce in the state, which means it doesn't change even in the base fee... there is just the block producers from being including the transactions that are not hitting the base fee criteria, but still the transactions will be ordered by the gas price in all in both cases exactly the same behavior. 1:02:04 And there is no need to drop them because you have expectation the base fee will go down and you don't have any better transactions anyway, so your mempool will be limited by the limit of mempool as it is now. I think they can stay there and wait for the better times. 1:02:20 Dan: And from a wallet perspective we of course remember the transactions you 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, James: okay And as from like a mechanism perspective as if I had a low base fee with a high miner tip. 1:02:46 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. I if I had a dollar base fee and a 50 cent miner tip versus having a 50 cent base fee and a dollar minor tip. 1:03:03 then theoretically the the larger base he would be included first. Dan: I think you mean max fee but yes, it's going to come down into the max fee is going to it applies to the tip. James: 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. 1:03:27 Is it worth like specifying kind of that we're keeping it the same as far as men pool and things go or or? Like making that more clear from the specification perspective the mempool is not really specified in any description of the consensus or papers every client manages the mempool they're own way they happen to be doing that similarly there. 1:03:51 Tomasz: 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 and developers perspective. I think it means that it's fine. Cool. And Alex: I guess at one point one question. I just came up with when you were talking about the max tip... wouldn't it theoretically make sense to switch to specifying just the max tip and the max total? that way you could never end up in a situation where basically your max tip plus max base fee would have been sufficient but just because you specified a high tip but not a high base fee your transaction can't end up being included. 1:04:44 James: I'm liking it...describe it again. Alex: Yeah and maybe as I'm just kind of getting us that certain might might just over be overlooking something but the idea like basically the example there where they like 50 cent base fee and one one dollar and tip was the other way around there could be situation where you would be willing to pay a high tip but just because your base fee your max base fees a little bit below whatever what the current base is which is actually just kind of ever make it in. but obviously that's not like you intend because you don't really care if whatever you're paying ends up with the miner you only want like to have a maximum tip to so the miner can't just take. 1:05:22 Whatever your your maximum willingness to pay is and it just take that so but if you specify like the maximum tip you'll want 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 is not basically going to over. 1:05:45 Barnabe: You think it's how the proposal is at the moment if I understood what you were saying correctly. What you're specifying is not the maximum base fee but you are willing to pay but its the maximum of the sum of base fee plus your tip. but if if the total of the two goes above your max what you're paying as a user is capped to the maximum. 1:06:08 Okay. One of the difficulties in having like let's say EIP 1559 and the escalator together is that the base fee might be increasing at the same time your tip is increasing, So in the escalator you have some certainty let's say the plain escalator no EIP 1559, you have some certainty that you're going to reach your max fee after the number of blocks that you specified but when you combine the two together, you can have kind of like an additive effect and you end up like topping out at your max fee much earlier than you when you put So yeah, that's one of the difficulties that I see. James: So would the solution to that being having one of them being as clear and one of them not being so that there isn't that race condition. Barnabe: So in this link that I shared, when I share the I kind of look at two things so you start like the escalator 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 maybe the base fee gets way over what your tip currently is in which case you're pumping through. https://notes.ethereum.org/Wjr1SnW-QaST7phX9C5wkg?view#Won%E2%80%99t-miners-have-the-incentive-to-collude-to-push-down-the-BASEFEE-by-making-all-their-blocks-less-than-half-full 1:07:26 So the better idea and one in which you can also reduce it to plain EIP 1559 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. 1:07:47 But when you have this additive effect where the base fee is increasing and your fees or so increasing your tip is increasing. You can reach your max fee yeah quite fast, but so I don't know. I I don't know if any of these designs are reasonable. I think the floating escalator is the most reasonable... 1:08:04 I don't know that it solves the issues we want to solve so maybe that's something would be nice to simulate actually. 1:08:24 James: So thinking about it from the user perspective. I've I wouldn't mind if it escalates to my max fee quickly if that means it gets in. 1:08:35 Barnabe: Yeah, it's reasonable. I think yeah. Thank you from how to how do you analyze it like pass which makes it a bit like a more trickier thing that maybe maybe it works in practice. 1:08:55 Like the escalating fee anyways is it's really to give information that you want to go above everyone else faster. So where is everyone else the kind of like intuition is that everyone is at the base fee or just like the an epsilon above. And so escalating the tip means you want to get like ahead of the crowd. 1:09:17 So yeah, in case your max fee is reached earlier then I guess you should have paid more if you wanted to be faster. So, I don't know. 1:09:34 Alex: Ah so 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. 1:09:48 Barnabe: You could still order by tip or by max fee minus the remaining tip in case you are topping out. I think you ordering would still be okay, but I do think you need to keep around the to answer Alex's questions. I think you need to keep around the transactions even if the base fee currently too high. 1:10:09 Like I can think of an edge case where it's only too high for one period and then it goes down and somebody resumed the same transaction as mine and gets faster. Like I've waited all this time and I only got kicked out of a map room because of this one block deviation. I don't know if it's really fair like it's a good idea. 1:10:32 But I also don't know really how the transaction pools are managed right now, so maybe it doesn't work as an a Ian: 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 1559 gas price. And so if there's a 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. 1:11:00 Barnabe: Oh no, more operations, but it escalates but it's also it's just the escalator it's kind of linear, so you have some expectation on the. On the price but yeah, maybe it was some issues. I'm not sure. 1:11:28 Ian: In any case, I don't think that's a good enough reason to dismiss it as an option. 1:11:48 Tim: Anything else people wanted to discuss? 1:11:58 Okay, so I guess in terms of next steps there's a couple things that are working to bring up on the core devs call tomorrow. Dan said he'll put his markups on an ETHMagicians thread somewhere so we can try and get more attention from the community on them. In terms of simulations, I guess Barnaby and Abdel you can have a chat and see how to get started there. 1:12:25 Is there anything else? James: Talking about click networks in the all core devs call... and then splitting the EIPs adding in a fix the miner the gas like change minor gas consensus decisions EIP, yeah. And. 1:12:56 James: I guess it's not necessarily just something to figure out is how to get more feedback on some of these design things yes. Tim: I think once we have them up on like ETH magicians and and Dan has has his has has kind of his how you call that anyways the link where you can see the design setup then we can reach out, you know that people like mycrypto at coinbase wallet and and under wallets in the space and try to get their inputs. 1:13:24 Tim: I'm happy to take the lead on that. James: Cool and then there was getting the if we are gonna do an ephemeral testnet that uses pupETH or is that something out how to approach that and who's gonna do it Tim: yeah we should ask on our core devs and see you know, what's the what's the overhead of doing that and and the yeah, what's with the value, okay? 1:13:52 Excellence. I'm remembering. 1:13:57 Cool anything else. Oh and yeah I'll ask so because several people ask for the recording I'll see what Hudson if we can maybe just straight up upload this the ethereum YouTube because especially Dan's presentation was was just pretty great and and I feel like you know, the the transcript will never do it justice so yeah, I'll see what happens if that's possible. 1:14:23 Otherwise if anybody on here wants to zoom link just in me and I'll send it to you. 1:14:33 Yeah actually transcript will be great by the way, but yeah, the the presentation was really good. 1:14:43 Okay. I thanks on everybody here's thank you bye, thanks for hosting this Tim this is awesome.