 We're recording to the cloud. Yeah, so thanks everybody for showing up. Second 1559 implementers call. I'll share the agenda in the chat. It was pretty lightweight. So if there's other stuff that people wanna cover, we definitely have the time for. But at a high level, wanted to start with just some status updates from implementers. Then there was a PR that Mika Zoltu, how I'm pronouncing his name right, 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% for blocks. After that, we'll have Dan, your mockups. Then Abdel had some questions around consortium networks and then anything else if people wanna chat about it. Yeah, so I guess for status updates, Ian, Abdel, I know Barnabé, you had also some stuff you were working on, so feel free to go. Yeah, I can start talking about Bezu. So last time we said we would implement the possibility to make all those parameters configurable. So we did that. We tested also, we get implementation in the small local test net and we are aligned with the spec for the moment and we are waiting to see about remove riders proposal. Yeah. Cool, that pretty much covers my update. Not all I've done since the last meeting was introduce those kind of big options for the different parameters. Yeah, 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 there'll be more rebases 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 1559, how would we do that? So I've tried to explore this question a bit. I've put a link in the discord to a note that is on GitHub with 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 VIP 1559 of having this base fee, but also like the idea of the escalator that you can sort of climb above. Oh, okay, yes, I can, I'll do that. Yeah, that 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 are the 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 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 their value for time. That's not clear to me. And I think it's a fairly difficult problem that could use like 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 EIP 1559, 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 their transactions on the mem pool. So that gives you like an idea of, oh, they want this to go faster. So they have a higher preference for 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 like fully aware of everything. So yeah, that was kind of my three things I tried to tackle. Cool, thanks for the update. And I see we have Thomas and Artem on the call. So is there any update from that or mind or open a theorem? Hi, sure. So for me, I made a lot of research. So I read every single post that all of you guys have reproduced and so you were quite talkative. So it was not an easy task. So far, I really liked what Barnaby was creating with his agent modeling assimilation. So I think this was 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 will have the last work 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 Petter, was how we will decide to introduce these new transaction models into the clique networks, like Rinka B and Gurley, but it will just stay with the old transactions forever or we'll move them all to the new model, which maybe not necessarily has the same meaning for the networks where you don't have miners. So it'll be great to have the decision here how we handle those other networks. Yeah, I think that was Adele's point as well on the agenda around like IBFT for Basu as well, but yeah, non-group of work networks. So yeah, we can definitely dig into that a bit more today. Artem, anything from you? No, we are currently focused on Berlin hard work. So 1559 is not on our immediate agenda. I don't know. 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 still leaving that to miners like is currently the case. Mika could not make it to the call, but yeah, he was curious to get people's thoughts on this PR, so I don't know if anyone has strong opinions on this. I think it's a fair point and just to change that is not really the main focus of the IP 155559. So I'm in favor of Mika's PR. 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, I can't be too 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 to block. So as long as these two are not too close to each other, it should be okay, but it could use like some more modeling on this. Yeah, what is the max that miners can push the block limits per block right now? It's either one over 1,024 or one over 2048, every block, I forget, that's definitely one of the two. Which is way, way less than 12%. Right. Yeah, so that, okay, so I guess, yeah, does anyone think that this PR is a bad idea? I would, so I think it's a good idea in the sense that I like having it be an explicit decision that's noted elsewhere, because I've noticed 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, like the thing to being protocol specific, and then we can have 1559 require that. And then it just seems like that's something to really think about the consequences of, so we should have both options. One is 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 with James here, and if you look at my comments, it's obvious that I'm playing devil's advocate, and I'm actually not super passionate 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, not what is best for the perception of governance, but that's just a personal opinion. And how re... Sorry, I was just gonna say, how realistic would it be to say, add the fixed block size, or the block size determined by the EIP in the future? Say we wanted to separate those two proposals, how 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, but I think it would take one or two days' work to shift it one direction or the other. So I know in the past, we talked like we all 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 Mika's PR to kind of reduce the scope of the EIP, try to get that live on the test net and working and see if there are actually any security or performance issues from keeping the blocks as is. And if so, we can, like you said, you can just add it back and it's a fairly 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 be clear, you would test both in parallel? Well, I guess at this point, we already have tests underway for the current implementation. Yeah. So yeah, I guess we can add it on in parallel, although I should defer to Abdel here because he's the one actually doing the testing. 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-scale simulation and see the impacts of both approaches. Is there any timeline on when tests will start in terms of networks? Tim, what was the... Not yet. I think, yeah, we wanted... So now we're at a spot where, you know, the geth PR and the basic PR work together and we've run small local networks, but we don't have anything like a public network yet. And I think 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 out on the test network, but no one has volunteered to set one up yet. Okay, thank you. So in terms of next steps for Mika's PR, should this be merged in then? Or should... Like, yeah, I'm not sure how we keep both in parallel and yeah, it almost feels like it should be, I guess. What's your question? 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 add this. It was mainly a simplifying measure. It was basically that there was a field and a block and then that was used for the gas a little bit and we need to have a field to store the base fee. So we might as well just re-purpose an existing one because that's easier than changing data structures. Okay, so it was not correlated to any economic concern or... Right. Yeah, okay, okay. So in that case, when it makes sense to 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, we can come back to the fixed block size if that's a solution. But it feels like right now it's probably gonna end up being simpler just like politically to have this be a smaller change than to have it also take like change this other thing with miners 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 other PR open, the other EIP also open before we merge the riders. What do you mean by the other EIP? So the PR right now is a PR to EIP 1559. Right, and somebody brought up making an alternative PR for the block size change. So basically like the reverse diff of this PR. Exactly, yeah, exactly. Okay. It doesn't seem too much. I know it would be a bit to fully detail it out but just having it open to track it would be great. Yeah, I think that sounds... I think the way to do that would be to propose an EIP to change the miner to being like decided on the protocol level and like removing that part and then tagging 1559 and saying that this is an option that it might require it. So if you choose to do it, then you require the EIP that fixes the miner gas limit. It removes the miner control. Write an EIP that removes miner control of the gas limit and then have that be an optional requirement for 1559. So it's easier to discuss the two. But do you think this change alone would have sense without EIP 1559? I mean, if we create a separate EIP for the rider, could we... Let's say we don't implement EIP 1559. Could this one be implemented without EIP 1559? It's certainly good, I don't see why we would. Yeah, and I guess what you're saying by that is you make it require a consensus fork to change the block gas limit, which from my perspective, seems like it's probably not the best idea, but there might be use cases for that. But I like the idea of just separating the concerns of making it kind of clean that EIP 1559 does not require that, but then there is this other EIP that we could add to 1559. Does anyone want to kind of open that EIP and then we can merge because PR? I can do it. Okay, thanks, Ian. So yeah, so I guess once you... Thanks, James. Yeah, once you have that, then you can merge because PR. And I guess we kind of have consensus that like if the client teams want to keep working 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 revert to that. Yeah, yeah, yeah, that makes sense. Cool. Anything else on that? If not, Dan, you want to walk us through your work? Yeah, sure. So at the last meeting, I was raising some 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 an exercise and we sketched up a whole bunch of ideas both for 1559 and the escalator algorithm. And I don't know, I do think there's some possibility for composability in retrospect, having now gone through more of the exercise, but let's dive in 1559 first. So I think my favorite one for 1559 is probably like this one. Let me see if this one's very different. Yeah, I mean, maybe we can do something, yeah, incredibly simple. Yeah, so maybe this is like an example of what we're saying. So 1559, I think the happy path, I think everybody knows, it's got some really great promises, right? We should be able to expect a nice low cost. We should be able to expect a nice low time. And the user's only primary expected parameter is the fee. And we think that we can make it very simple to represent different orders of magnitude for the fee. And that's all fine, and that's nice. And 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 your current max fee, or how far it is over the recent block average. That's also pretty all right, and pretty easy to do. And then, yeah, I think this is kind of an unlikely worst case, so if there was a spike in congestion, which I don't know if we can realistically expect, like if we're trying to say you should pay more, I think we would have to see like, serially more expensive blocks, and in theory, you're gonna approach a block bit is not including transactions. But we could anticipate a current ascent of blocks, and we could maybe estimate higher. Oh, also to address Barnaby, he was asking what we might suggest in terms of defaults, we discussed that a bit. And we were thinking initially probably a multiple of the current base fee. So if the current base fee is, if the last block's base fee was 21 cents, then we might suggest double it or something 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 that fee. This should be user defined parameter. Something that's maybe not, oh, what's this, 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, so we can see it on the edge here. We were thinking it should be tucked below or the EIP suggests the tip could be hard coded by wallet. And I think this is a really important question. And it's maybe, you know, so 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 two G 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 an equilibrium for it like capping out exactly. 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 were going to compose with the escalator algorithm. In terms of ways the escalator algorithm could work. 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 so these defaults would represent like slopes that are kind of invisible to the user. But for advanced users, they could define their min and their max and their time preference and possibly even see a visualization of it over a quad of recent transactions, which is a pretty cool way to do it. And the reason I think that this can compose with 1559 is because both algorithms use a max bid 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 fee plus tip, we can set the, yeah, we can use it for both. So this escalation may happen faster. If the base fee moves higher, you may get to your higher prices faster, but you'll still be within this range at least. 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. Yeah, anyways, 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 sessions and can serve as a starting point for community discussion about how this would, if that's your representative users. This looks great. Thank you so much. Yeah. Yeah, thank you. This is great work. Yeah, thanks. Yeah, shout out to our designers. I have a couple of three designers here. So Rachel Koch, Jake Halkin and Christian Jarier. Yeah, this is awesome. So the... Go ahead, James. You said you're a little bit nervous about hard coding the tip in the wallet. Can you just say more about that so I can understand the concerns there better? Yeah, 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. And then we can divide that by the estimated gas limit and the gas price. And then we're able to give you a max fee. And that's some nice user experience. However, there is a second parameter, the tip. And that one is it's supposed to be like kind of trivial. I don't know if somebody else wants to take a swing at the roll, 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. But it is the remaining minor incentive. And so within a block, it's the only thing the miner's getting. And so there is a incentive preserved for miners to order by tip within a block. So it maybe doesn't matter if everything's moving up and down, if you're not in the first block because your tip is low, you'll be in the next block. But as a wallet, I don't, 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 so if there is a sudden search where a block is full, then the miners are gonna pick the highest tips. And wallets are currently advised by the EIP anyways, to hard code the tip. This puts wallets in a weird rival risk position to make their users pay more. Could you possibly hard code it as a function instead of as like a static value? Yeah, I mean, we could do everything that we do today because as some of the criticisms have suggested, the tip becomes another single price option like 1555 is trying to avoid. So we could do all the stuff that we're doing today. And the good news is it only applies within that band. So, and you're still a subject to the max fee. So that's nice. But yeah, it doesn't mean that we might have to preserve for example, our current bidding logic under the hood and just apply it to this smaller within the block option. The other thing you can do is you can use some of algorithms that look at kind of what happens to previous transactions to adjust the chain. Like you could do something that says the tip keeps on decreasing by 10% every time you send the transaction until you notice your transaction not getting included within a block and then it jumps up again. Yeah, yeah, we could do that. We might wanna look at what other transactions we're doing too, but yeah, like seeking the minimum tip definitely seems like a component of the right strategy. The designs are really cool then, thanks. One thing, if all the tips are set to the same value, I think ideally I wanna 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, like 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 users who have high value and users who have low value. So perhaps like also a tip, which is a function of a max fee, like if you set a high max fee, you tip a little epsilon extra. I think something like that might be reasonable. 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 fixed costs. Because 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, yeah, it's worth considering. Just some context for the theory behind the fee being fixed, not in the wallet, but having like approaching this fixed value is that there is a risk of it, the uncle risk for including a transaction is pretty similar for whatever. That is correct. So that is theoretically where it could be the same and it could always be the same and miners would accept it if it approaches that value. But I mean, you guys are the wallet people. So as far as choice and suggestion versus baked in, I mean, I don't wanna decide for anybody, but I would lean with wallets on deciding what they are most comfortable with. Yeah, so it's worth having in the next, thanks. If there are any other questions I could wrap up. 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 on like the tip versus escalator and if and how they work together? Yeah, I'm wondering how we can kind of get to a point where we have like a decision on that. So you're like a consortium of wallets we could consult? There's the theory of magicians is pretty much the closest thing using the wallets tag that. Yeah, I think that would be valuable to have like a thread on these magicians sharing kind of these high level mockups and we can, I don't think there's a consortium of wallets but like we can probably reach out to different people in the space building wallets and get their feedback. That sounds great. So there was one other point just worth highlighting there was the concern raise just if in the scenario that miners colluded to include under half full blocks i.e. eliminating the base fee as much as possible and the tip does become the primary bidding parameter and so it might be valuable for us to incorporate escalator like interface even in the case where we are trying to uphold the 1559 type max fee interface. Yeah, I mean, I'm just like partly strategizing like as a wallet developer, I'm not sure what miners are going to do. So just being defensive for users, like we are weighing like is it necessary for us to pre-strategize for that happening? There was one minor idea that I had yesterday and maybe it requires some validation but if we think of the half full blocked 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 below the half. So if you have a block that has 16 million or 20 million, how are we calculating that? So if the gas is not used up to 10 million then it was more for the block. I think there are some bad implications that a security of such a block falls down in the case of network underutilization. So if we don't have much of a demand for the network then actually it just decreased security. But at the same time it acts as a mechanism of preventing miners from going below the minimum just to decrease the base fee because it will hurt their rewards. 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 like every block being at 50%, right? The thing that we're targeting is a kind of medium run average of 50%. So I don't know, we need a lot more thinking. This idea is kind of there in a paper by Basu 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 it would work with EIT probably, yes. But then you would have a lot of, I guess, stuffing like the miner might be incentivized to put these own transactions. So you might have more heavy blocks even though the transactions are kind of not like just fluff. So just to 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 if you're under it it would be rewarded to the miner. So normally the whole base fee is 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 much the block is filled with the transactions. So 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 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 fee gives us a lot of opportunities in the future. So I just give it as a idea for future. I would like to make the ERP 1559 at this time to be too complicated. So maybe it's just something to think of for the future. I think we'll have a lot of opportunities to introduce more things later. The having the miner tip be an escalator is actually like the 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 gonna like whoever is the one that breaks gets paid more like whichever miner and like they just will because the escalator can do it. That's 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, I know I'm not a wallet designer and things so I'm wondering the choice at abstracting out like base fee and the miner tip versus like having them have to set the like choosing max fee where you could choose base fee and then the miner tip which ends up being max fee or like what was your thought process 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, sure. And no need to apologize. We're all users of this so you've got as much insights as any of us. Could you restate the question, sir? Yeah, the part of abstracting out the base fee that's happening? Yeah, I don't know for, 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 them 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 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 to the user 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 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 upfront it looks more like it's the actual number they're gonna pay and it could make somebody feel very uncomfortable if we're like suggesting a default to like a $10 transaction or something. And 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 that the happy path where maybe the minor tip is hard-coded or insignificant enough in most of the cases that we can just leave it alone. So I wanted to represent that even though my greatest fears are that that's not the case. I wanted to reflect that and show how nice it could be. Okay. So then in the case you would add something under here. So if we did have minor tip be a choice in there would you have them like say, so the expected fee as being that 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. Yeah, so if we were composing them, yeah, sorry, we probably should have a third 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 the escalator because it tends to have the more complicated inputs. You've got like four. Well, yeah, you've got a starting amount and you've got 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, we can say what the range will be and we can even say what it will probably cost. And but yeah, it's likely that if we wanna combine it to that it'll inherit the complexity of the more complex algorithm. I like having the expected fee in there as like letting them know base fee that just sounds nice to have them have the information. And then having the fast, medium, or slow be representative of the tip that they're gonna be putting in and have that be like an escalator or, I don't know. Yeah, we could probably stay expected at the top of this. And then that just be, so we can separate the expected fee and even the max from the time preference. So that'd be like another way of combining these that would be very reasonable. Cool. I like how this is making my mind like put 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 make these designs available after the call and feel free to make Franken designs and suggest other things. Cool. Okay, the next thing on the agenda was talking about non-proof of work network. So basically what would happen to the public networks running clique as well as private networks so that run different consensus algorithm. Do you want to have 1559 for all types of consensus mechanisms or is it just a proof of work thing? Yeah, so my concern about it was, usually when you use private networks you set all four 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 1559 transactions and 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. I don't know, but yeah, you know, because if we apply directly 1559 rules we might have some issues on private networks. Yeah, it was my concern. I guess my question 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 slash first price auction problem. But then the problem is you have test sets that don't reflect, you know, main net. Yeah. Do click-nickwards have transact to have congestion problems? Like they, or is it just that they don't because they're not main net? Or... I think they don't because 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. The network is generally... And the block size too. Yeah, yeah, yeah. Yeah, maybe we can say it does not bring value on consortium networks or non-pro-pro-fork networks, maybe. I think we should bring it up in an all-core Devs call. Yeah. It could be a good next step. So other clients can chime in. Yeah, makes sense. Like hearing from Peter or some of the other guys who wrote the click spec. Yeah, and I think also it might be just like a separate heap. Like maybe there's like a 1559 equivalent for non-proof-of-work networks, 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 all be done at the same time. Yeah, that makes sense. That would fit with the existing, there's an EIP four click network, four that define kind of click networks. So you could, that's like a good pattern for what's happened previously. Okay, good to know. Anything else on that? Last thing, so this wasn't on the agenda originally, but 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 click network stuff we talked about, and just getting some tidying up to do in the EIP with regards to the block size. So does it make sense to start talking about like more public test nets now, or should we just kind of get all those things done and maybe have another meeting in a couple of weeks to discuss that specifically? I may have unpopular opinion that the test nets will bring us any benefit in simulating the behavior of EIP 1559, because we would need congestion, we would need users, so I think simulations would be better. Yes, for test nets, I think one test net will be enough to move drops to EIP 1559 and the standard transaction processing and see how the mainly wallet developers and users feel about the change. Well, earlier we talked about rolling out a new proof-of-work test net, and so it may just be good to start it with this. This way, yes. So if you think about moving something instead of Roxton, because Roxton is too big nowadays, I feel, it's all about deploying all the contracts on the new network as well, but I think everyone will welcome that. 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 for, I don't know, say, the first million blocks or whatever, and then you add EIP 1559, you're basically a hard fork to EIP 1559 pretty early on, correct? No, maybe started straight away with 50-50 because if people have to do a lot of actions specifically to deploy things, then we'll have a great testing ground. Oh, yeah, that's true. 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 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 the EIP specification? I think we should have a pretty stable spec before we continue testing it. Yeah, I agree. And I think everyone here also has 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. So then maybe on our next call, once we have better visibility on the spec, we can discuss just the kind of how we go about launching the testnet. Yeah, it seems like it'd be nice to launch something that we could destroy easily. And then iterate on that and then say, this will be the real one, and then have that be part of Sunsetting Robston. There's one thing like, I feel that many users are waiting for some replacement for Robston, which would be still proof of work, but would be much smaller and easier to sing. And since Gevni is already like nearly 3 million blocks, and in the past, we were spawning new testnets every two, three, four million blocks, because it would be a great incentive to people start deploying things. If we tell them that this is something that would destroy later, nobody will move their contracts there. Do you mean... And I feel like... Oh, sorry, go ahead. You're suggesting building earlier ones that we are going to destroy, and then telling everyone, this is the one to migrate to later. Is that what you're suggesting? Or... I mean, if you think about def-only testnets, then maybe we can. But so I don't think there'll be that important as the actual new proof of work testnet that would have EIP 1559 that everyone would feel invited to and see as an opportunity to replace Robston with. Yeah, I think that makes sense. And that's also something we should probably bring up on the Core Devs call tomorrow to get other people's thoughts. But 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 have more of a... like better communications to the community, like, hey, this is a testnet, you can join it today. You know, it's going to be a bit rough, but it should be mostly there. And similarly, at the same time, say we're kind of phasing out Robston as this other testnet becomes more and more battle-tested. The... Just thinking about how we're using 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? So I think this is what the BASU and GET team already have. Kind of it's not a public testnet, but it's like a local testnet on our machines. But yeah, but I agree. Having something more repeatable because it's a testnet on a local machine with no automation, et cetera, so it's not really repeatable. And it's only GET and BASU and I build GET from the source PR. So we should maybe use some release build or something like that. I don't know, but I agree we should... It will be nice to have a testnet easy to deploy and easy to destroy with all client implementations. So then should we do an ephemeral testnet for 1559 with that kind of involved and that you could roll that out earlier before things get fully specified even? Yeah. Is that something you could lead? Um, I don't know. I don't know what that meant. I don't even know what that means. So what GET does, they use like a piece, a piece, I don't know how to pronounce it anyways. But like, I don't think at BASU we spent much time looking into how it actually works. We can probably look into it and we will be kind of anyways for Berlin. So we could have a GET forth run Puffeth and then BASU sync to that. Yeah, something like that. Yeah, yeah. We can do that. I guess the short answer is we don't know yet, but we can definitely... I think it's much simpler than that in the end. So the only thing that we need for spawning ephemeral testnet if we decide to have one is just sharing the chain spec genesis file and that's enough. And it will be more important to have a spec of the AP1559 to be finalized rather than just to 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 that because we decided... You know, we said we don't know the optimal numbers for the parameters of this heap 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 that we would have to launch multiple ephemeral testnets with different configurations to find the optimal numbers. This is what we said, but I don't know if we still want to do that. This is where I said that I think simulations would be better than spawning those testnets. Hmm, but how big will be the effort to build the simulators? It will be lower than analyzing the data from the testnets and less expensive, I think spawning that many testnets will be quite expensive. Yeah, previously looking at simulations, it's very expensive. Like doing robust simulations is one of the hardest things that has been to get done for this because the cost of sense of being really, really high. To kind of separate in concerns, I see value in or clarify if I'm off on this that having all of those different variables, making sure that clients come to consensus between the different variables being different is valuable to have. And then the layer on top of that is what is the optimal version of those configurations? Yeah, okay. So that's two different concerns. Yeah. So like the ephemeral testnet I think would solve the are all the clients agreeing on what the configurable things do and you can test stuff. That wouldn't necessarily get you to the ideal configuration, but the next step would then be if identifying the ideal configuration or iterating on it. But you kind of need both. Does that fit Thomas or does that make sense? Definitely I'm not against it. It's just I was weighing these two possibilities and thinking of what is more useful. But I think every team and we together, we should support the effort. So if you should consider this as an idea that could help a lot on some field, then I definitely would join that effort. Yeah, and I think 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 testnets. And I think if Nethermine can help on the simulation sides, that there's a lot of value there. I'm not sure on the basic team, we can help much. Yeah. I'm happy to give a hand. Like I like simulations. I've been trying to do some, but I think it'd be good to also have like the client perspective on what to simulate exactly. Like how do we make it robust but have scenarios that kind of match the reality as well. So I think that's kind of the expectation from having a testnet that we can have like real data, but it's yeah, it's not incentivized or if it's not congested, it's not clear what we'll get. So I do agree that simulations can be helpful. We're blessed to have Barnaby's. Thank you. Yeah. Yeah. And I think we can probably help. I guess when I say we, I mean Abdel and Ian can probably help feed some of those like use cases or scenarios. Are you on the Discord channel Barnaby? I would 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, but Yeah, I can find you. I don't know. Okay. Okay. Sounds good. Cool. So was there anything else anyone wanted to discuss? I had a question on Twitter that I didn't know how to answer. All right. Which I'll put in came from Alexi. And what happens to the pool? As 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 one space fee goes down, it's congestion eases. Like actually they'll will like, will they be kicked out of the pool? Or if you have like a, like as base fee goes down, are things included like mem pool holds on to those or do they get rid of them? Yeah, that's a good question. I guess, what would be the right way to think to think about this? I guess the right way to think about it would be that make 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 least likely to ever be included. I think we can leave the mem pool behavior exactly the way it is. So because at the moment, what we do is, I think in most of the clients, if not all of the clients, the mem pool just holds the best X transactions sorted by gas price, taking into account also if the nonces align with the nonces in the state. Which means it doesn't change even if the base fee is there, it's just the block producers will not be including the transactions that are not meeting the base fee criteria. But still the transactions will be ordered by the gas price in all in both cases is exactly the same behavior. And there is no need to drop them because you have expectation that the base fee can go down and you don't have any better transactions anyway. So your mem pool will be limited by the limit of mem pool 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 if I had a dollar base fee and a 50 cent minor tip versus having a 50 cent base fee and a dollar minor tip, then theoretically the larger base fee would be included first. I think you mean max fee, but yes. It's going to come down and the max fee is going to it applies to the tip. Okay. So then we don't we the transaction sets the max fee and then as things go down. All right, 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 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 their own way. They happen to be doing that similarly. But I don't think we need to add this into consensus or discussion as long as we don't raise concerns from the client and developers perspective. I think it means that it's fine. Cool. Hi guys, one question I just came up with when you were talking about like max tip versus max base fee. Wouldn't 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 the high tip, but not the high base fee, your transaction can't end up being included. I'm liking it. But to describe it again. Yeah. Yeah, maybe I just came up with no, so it might just overlooking something. But the idea, like basically the example there with the like 50 cent base fee and one dollar 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 the count 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 you're paying ends up with a minor. You only want to have a maximum tip so the minor can't just always take whatever your maximum willingness to pay is and then 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 you're basically willing to pay any base fee that as long as like the total you're willing to pay is not basically gone over. This is how the proposal is at the moment. If I understood what you were saying correctly, what your space thing is not the maximum base fee that you are willing to pay but it's the maximum of the sum of base fee plus your tip. So the tip is fixed. Okay. But if the total of the two goes above your max fee, what you're paying as a user is capped to the to the max fee. Okay. Okay. One of the difficulties in having like let's say EIP 1559 and the escalator together is that your 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 vanilla 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 thought you would. So yeah, that's one of the difficulties I see. Okay. Then sorry for the confusion. So with this with the solution to that being having one of them being escalator and one of them not being so that there isn't that race condition. I've so in this link that I showed 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 can't be included. 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're 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 fee is increasing and your fees also increasing your tip is increasing you can reach your max fee. Yeah, quite fast. So I don't know. I don't know if any of these designs are reasonable. I think the floating escalator is the most reasonable. I don't know that it solves like the issues we want to solve. Maybe that's something which would be nice to simulate actually. 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. Yeah, that's reasonable. I think, yeah. Thank you. Did you come up from a how to how do you analyze it? Like it's wing parts which makes it a bit like a more tricky thing but maybe maybe it works in practice. Like the escalating fee anyways is it's really to give the 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 an epsilon above. And so escalating the tip means you want to get like a head of a crowd. So yeah, in case your max fee is reached earlier then I guess you should have paid more if you wanted it faster. So I don't know. Maybe it's reasonable. Also I assume the version with the escalator would be more complicated from a mempool perspective as well because like ordering then all of a sudden isn't straightforward anymore. You could still order by tip or by the max fee minus the remaining tip in case you are top paying out. I think your 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. Like I can think of an edge case where it's only too high for one period and then it goes down and somebody resubmits the same transaction as mine and gets faster. Like I've waited all this time and I only got kicked out of a mempool because of this one block deviation. I don't know if it's really fair or if it's a good idea. But I also don't know really how the transaction pools are managed right now. So maybe it doesn't work. I don't know. 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 this escalation occurring from block to block then the mempool will essentially have to refactor that price that each block can reorder based on the new price. Also more operations is it. But it escalates but it's also if it's just the escalator it's kind of linear. So you have some expectation on the on the price. But yeah, maybe there's 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 of things that we're going to bring up on the Core Devs call tomorrow. Dan said he'll put his mock-ups on an e-magician thread somewhere so we can try and get more attention from the community on them. In terms of simulations, I guess Barnabay and Abel you can have a chat and see how to get started there. Is there anything else? Talking about the networks. Yeah, on all Core Devs. Yeah, on all Core Devs. The EPs, yeah. And then splitting the EPs or adding in a fix the minor the gas, like change minor gas consensus decisions, VIP. Yeah. And getting, figuring, I guess it's not a nest step but just 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 e-magicians and Dan has kind of his, I forget how you call that. Anyways, the link where you can see the design set up. Then we can reach out, you know, that people are like my crypto at Coinbase Wallet and under wallets in the space and try to get their inputs. I'm happy to take the lead on that. Cool. And then there was getting the, if we are going to do an ephemeral net that uses puppets or is that something, how to approach that and who's going to do it? I think we should, yeah, we should ask on all Core Devs and see, you know, what's the overhead of doing that and yeah, what's the value? Okay, that's the ones I'm remembering. Cool. Anything else? 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 to the Ethereum YouTube because especially Dan's presentation was just pretty great and I feel like, you know, the transcript will never do with justice. So yeah, I'll see with Hudson if that's possible. Otherwise, if anybody on here wants the Zoom link, just ping me and I'll send it to you. Yeah, good. I'm sure the transcript will be great, by the way, but yeah, the presentation was really good. Okay, then. Yeah, thanks a lot, everybody. Cheers. Thank you. Thanks for hosting this. Thank you. This is, of course. Thank you so much. Awesome. Bye everyone.