 Okay, hi everybody, welcome to first infrastructure call we have. Yeah, this is the first time we do that's the try and align basically the different tooling layers and infrastructure layers with the work that we're doing at the protocol level. Yeah, that has said this up. I don't know if you want to give a quick overview trend of like, yeah. Yeah, sure. Sure, so we wanted to just start early and we know there's a lot of complexities with ecosystem tooling and libraries that need to adapt for 1559 so we just wanted to start this process early instead of having everybody, you know, try to figure it out on their own so it will be like Tim said an experiment we're trying to get people to just have a quick synchronous discussion, and hopefully we'll iron out some issues together and come to consensus on what things should be. I know I think I spoke to almost everybody who's on the call so hopefully my intro to what this project is is sufficient but if you have any questions feel free to reach out. They're on discord or Twitter telegram whatever works and I can answer any questions but yeah so we're, this is the one offer now. We're not planning to have this every two weeks or anything, but we'll see, you know what the need is going forward after this call. We'll talk about the agenda in the chat so if you'd like to see that it's pretty short. So we have a lot of leeway and what we can actually discuss main topics are going to be Jason RPC. And I think there was another one that I added recently but yeah. If there's any initial questions otherwise we can probably just get started with discussion on Jason RPC. Yeah, actually, I, I guess, just, there were like yeah three things on the agenda. So there's just my PC just getting general updates from the projects which we can probably do at the end and then also the change between gas target and gas limit. It might make sense to start by the last one, just because this is one that'll change kind of the consensus rules and we want to make sure. Yeah, that's kind of agreed upon. Yeah, I was just going to say you reminded me I should probably mention the tracker so the the other component to this in addition to the call to this London readiness London info readiness initiative is that there's a tracker that we put together. So similar to how Tim tracks the clients to see where they are at with implementing each of the EIPs we're also experimenting with this tracker for libraries and tooling. So, if you go to that, that link I just put in the chat, your project should be listed somewhere there and then the intent is, you know when you have something in project and progress, either DM me or make the PR to that. That document and then update saying oh this is in progress or we're done with it and then it'll just give us an idea of where we sat. So yeah, check out that link. And then Tim, you can just take it away with whatever you'd like to start with. Thanks. Yeah, I think starting with the with the block header is probably the most important because, yeah, as I said that will change like the consensus, and to give just a quick background. The original spec 1559 would change gas limit in the block header to gas target, the way 1559 works is we want to target a certain amount of gas, but we're fine going up to two X above that so using numbers from the network you know we want to target having 15 million gas but we're actually going to enable having up to 30 million gas and this is the way that we can kind of gauge supply and demand for the network. So the original basically split proposal in the EEP was to change gas limit for gas limit to gas target in the block header. But as we were implementing that and testing it, we realized that breaks a bunch of things. And so there was a proposal this week to kind of switch that to instead use still the gas limit in the header. On the fourth block we would have to bump the gas limit to X, so it would basically go from, you know, 15 million to 30 million, if that's the numbers we're at. But then at least the field in the header would still return the maximum amount of gas that a block can consume. I think Martin or Peter had written kind of the formal proposal for that light client wrote a PR to the to the EIP. So I don't know if any of you have thoughts on it or anything you wanted to add. So I think the one question that's outstanding for that is minors when they set up to configure their nodes they configure what gas limit they're going to target and so every time they produce block they bump up or down towards their gas target. If a minor has the gas limit set via command line to 15 million, all of a sudden as soon as the IP 1559 lands, they will start pushing the gas limit down because the block will have 30 million and their minors configured to try to target 15 million. So we have a couple options to address that we can try to just communicate with minors and tell them hey you know right at the fork block you need to reconfigure your client. That kind of sucks because reconfiguring your client right at the fork block is dangerous and hard and whatnot. We just accept the block gas limit is going to be volatile for a bit around the fork and that also kind of sucks. The other option is to include like a second option that you can add which says, you know, while this option is present gas limit is actually 2x what I said, after the 1559 fork block. And the last one is we can make it so that command line option does something different than it says so it says gas gas limit but really it's the gas target. All these have disadvantages of course I'm personally partial to the second option that says hey just temporarily 2x this after the 1559 block and then the user can remove that and it can be deleted from gas later. But that's that's the current thing that we need to address to move forward with this I think. And I guess technically we don't have to address it so each client can address it separately. Since I think almost all minors running guess really this is a guest problem. Yeah, does anyone from the guest team have thoughts on that. Yeah, so personally, I think I would prefer just asking minors to please bump. After the fork press is just bump the gas limits up a bit. And if we have a few blocks where the gas limit is going fluctuating a bit up and down. I mean that's fine even if they even if it's hot today weren't fluctuating up and down. I don't think it's a problem. I personally don't really like these magical flags because first up we need to implement them and we need to convince everyone to use them and then when we delete them. So I think to convince everybody to meaningfully. So it's, I mean, we, we either way need minors to do something so might as well keep it simple and have them do the right thing. For example, if, if we want to be nice, and we don't want them to just cool with the gas limit during the fork, we can also tell them to hey just start start targeting 30 million. Two hours before the fork and then yeah that's going to go up a bit and then it will come down. So I think it's I will personally just rely on minors to sort this out. So I can definitely try and communicate with minors and, and, and like, see, see if they the thing that makes sense. I guess, assuming, so my fear is not that minors say that this doesn't make sense but it's that there's not really an answer. So we don't kind of hear back from them, assuming we didn't hear back from minors, and we kind of don't know what they'll do. Would it be possible to add this. Yeah, I guess what's the latest we could add kind of a flag like this latest would be the fork release. So yeah, I'll follow up, I'll send an email and But I so at least we do keep in touch with two mining pools or I wouldn't say keep in touch with me every couple months we maybe just exchange a message, and they are generally. I mean, if we contact them that hey, there's something screwing it, but there's something that you need to take care of the you should respond. The problem that they won't get. So, as long as you can get the few larger pools to play nicely with the gas target, I mean, properly set the stuff up. The rest, even if somebody misses it they won't negatively influence the network. So as a minor if you're a small minor and you just miscomfigured your note, you don't have an absolute no negative impact on you so it's not like we're being actively harmful to small minors who don't know about this. Okay, so we can do that. So I know I think like client had a PR against the 1559 spec to make this change. Anyone object this change as chance. Okay, so I guess we can go ahead and merge your commit into the spec like client, and I'll update the London spec to reference that latest commit for 1559. And that's probably what we'll use for the next test nets of our dev net for a bike off. And the way just to clarify the way it is written. Now, it means that the at the fourth block. The previous blocks gas limit will be used as the as if it were the target of the parent block. So the new gas limit will immediately double is that correct. Or will it be gradual. Yes, I think that is good and expected behavior. Yeah, that's essentially that if the whole point of 1559 to allow crisis much gas. Yeah, that's kind of correct behavior in my opinion. Yeah. Okay, great. And yeah, I'll make sure that we get an author of the e to approve the PR so it gets merged in. I'll try and ping them today. Anything else on the gas target versus gas limit. Okay, so the next big topic was basically the renaming of the Jason RPC fields. I know there were a lot of different threads on that so there was the eighth research thread originally than the get team put out a proposal this week to have the shorter names and try to match the current terminology with gas gas limit gas use and whatnot. I'm not sure exactly where to start. But this one it feels like there were various different threads on it. Yeah, maybe I guess because it's the most recent one. I don't know if Martin or Peter you want to walk us through what you had as a proposal and I think Micah and like client also had that comments on that for the Jason RPC naming. Right now. Yeah, I think the fields were like max priority fee per gas max fee per gas. And I think get wanted to expose those as gas tip cap and gas fee cap, respectively. I think that I think, yeah, Peter can expand on it, but one thing that I really think we reacted on is that it needs to be very clear for the user that something is per per unit of gas and not just some accumulated. So if you set 20,000 you should know that this is 20 times 20,000 times whatever gas you can have it's not like. So we want to, and I think that's the, that's a root thing that's been want to be clear about Peter do you want to expand. Sure. So, essentially, the small confusion came from from the implementation that such a lifetime implemented the IP 1559 for us. And we didn't really like and I can share that sentiment that's really long max priority fee per gas naming. And then he was suggesting to just go with dip and gas cap. And essentially, this is where this whole misunderstanding stemmed from and we can't realize that this from a user's perspective is super important to signal this that some field is per gas and not not at all. And the interesting thing was that the spec didn't mention that all the are the jigs and RPC aspects. So the, the 1559 the IP focuses fully on the consensus things and defining the variables and constants and algorithm and whatnot. And we didn't know mention on whatsoever on how these things will be named for the user. And essentially that's that was the reason why I wanted to bring it up because when implementing it, it needs to be surfaced up to the user obviously across different clients because every wallet and everything needs to implement this. And, and then the question is, how do we name these fields. If we were to go with just inherently what's in the ID, then these fields will be named max fee per gas and max priority fee per gas. These two names. I mean, they are, they are correct description of what the fields that my problem is that currently Jason RPC but sending a transaction there is a naming style. And we have gas limit gas start, sorry, we have gas gas limit gas price gas use these are fields that currently the API sends and receives. And then it will be weird that okay we have gas price and we have max priority fee per gas, which is essentially the same thing. So our suggestion was to simply call the tip, I mean called this priority fee, we can call it gas tip cap or anything if somebody has a better idea and for the, for the base fee, which is actually paid by having the total that the gas price that the protection papers would previously was gas price. And that would be kind of innate to gas be kept. So it's a, it's just a slightly shorter version you could also call it max fee per gas, or that doesn't really fit in with the rest of the variable meaning and that is why we kind of suggested gas be kept and the tip was just something similar to gas be kept. But only know the reason why you kind of brought it up. I don't really want to go to bike shopping because everybody has their feelings. And the most important things for me is that the spec actually states what the name of these API fields should be, because that's, that's the thing that we agree on. What is the status of the EAPs for the Jason RPC or for the Jason RPC spec for the stuff. Yeah, that's what I was going to say we had a list of separate EAPs for the different are Jason RPC calls. Let me try and pull it up. It's possible things got lost because Jason RPC spec is moving over to a different location. And so it's possible that just is there's confusion around that. Yeah, so we have like EIP, EIP 3041. And I think there's like 3044. Well, these are all about the block. Let me see if there's some about. Yeah, so these are all about the block. So I don't think we ever had an EIP. Jason RPC EIP for the transaction fields. So basically get transaction by block number index get transaction by hash and all that. We never drafted EIPs for those. So I don't know would that be the better spots to actually agree on those terms like creating separate EIPs for the various Jason RPC calls or do we want that in 1559 itself. It's kind of overkill to create the separate EIP just to name the fields. I mean, in 1559, it's obvious that there are two fields that need to be exposed. We might as well just add them in 1559. So the, we do need to specify, I think the Jason RPC calls like there's a ongoing effort to specify all of the Jason RPC and get it's an agreement between the clients. And so, for me that feels like the right place to specify what the fields are. So we're seeing there that we are kind of in a limbo for Jason RPC and we don't currently have anything like officially or formally specified for Jason RPC. And so there's a good chance that such a specification, you know, might be a long poll here. And so I think I can kind of appreciate where Peter's coming from that if we don't end up actually finishing a Jason RPC spec before London, then people will gravitate towards using the names that are in the 1559 EIP, just as like a reasonable default. And so if you don't like those names, then that's need to be fixed there. I agree with what Peter's saying. London. I think that will be in a better place. Sorry, apologies, Mika. Yeah, I think from our perspective in terms of when it comes to implementing the Jason RPC calls, it's certainly easier if everything's in one place. I, you know, we didn't save the original EIP you have an explicit clause that calls out the Jason RPC changes the risk of course with having separate Jason RPC. EIPs is that then you've got to link from the ones that affect the clients back to them and then they might not be staying sync whereas if someone's updating like a single IEP then you know you can just search for all occurrences of that word there to make sure you're hitting all of them. So I'd say it's going to keep things simpler as well in terms of keeping them in sync. So would it be. So I guess, would you expect 1559 to have just the name of the fields as they will be returned in Jason RPC or like a full spec of the diff for every single RPC call that's changed by 1559, you know, like, you know, so personally, I would be happy if there was a single paragraph saying that these two fields should be exposed as such and such on the API. Okay, so basically, so it doesn't need to be some conclusive spec of the ideas to just give a hint on so that every client is on the same page on the naming convention. So we say we're adding base fee into the block we're adding, I forget what the agreed upon naming but we're adding gas fee cap to the transaction and gas tip cap into the transaction basically. Yeah, that would be I think if somebody feels very strongly about the front name, again, we can backshot the soft line. I was just the whole point is to just have the information. One other question that was being discussed, I think, which was, so you do have these two fields of the gas cap and the tip that the sender specifies. And there's a question of whether the Jason RPCs would expose the actual values chosen, like the actual fee paid, and the, the actual tip paid or whether it would be up to clients to calculate them themselves. This is similar to to the gas use used and gas limit for transactions. So for example, if you retrieve a transaction, then the gas limit is not the amount of gas that was actually used but it's the amount of gas the user specified. And I think you need to actually retrieve the receipts to get the true gas usage. Maybe we could extend the receipt to include these fields. So, the 1559 actually originally had receipt changes very correctly and then I think we took them out, because we didn't want to include derived data in the receipt. That being said, we can return additional information in the Jason RPC receipt request beyond what's actually in the receipt and I think we already do that. Yeah, I mean, of course, that's I didn't mean to change the consensus field because these obviously can be just calculated. So when you receive the receipt, you know which block it was in. So you have the base fee. And then if you have the base fee and have the, the, the limits set by the transaction, you can just specify the fee that was used. So you don't need to store anything. It's just about exposing it. I think the only argument against exposing it is that it would require two database reads one for the transaction one for the block to calculate. I have to read upon this a bit. I mean, I'm technical, but I think to get the ready does quite a number of database reads one for some of you to the receipt, because we don't store the receipts one by one rather we store them through five blocks. I don't know, it's a question, but I think this. So the reason that question is, are coolers expected to have access to this. I would say probably yes, because for example if you just look up your transactional interest can you probably want to know how much you paid for it. I think people would expect this to be available somewhere. Yeah, and I guess I don't know we have a ton of projects here so is it quite valuable for you all to have just the total fee paid right there and adjacent RPC. Like, I see some people nodding. I would say so. Yeah, yeah, it's definitely simple code quite a bit. So I think if we can expose it. We should have a client level. And so, okay, then there's a couple comments in the spec about that where the section is saying, you know, having a full this would be good. Maybe if that's something we want to start the new kind of just an IPC repo with that that would be valuable. So, I think for sure we can commit, you know, adding the fields, the actual new fields in the 1559 specs, so at least people know how to name them. So this gets into, I'm trying to avoid bringing this up but this conversation is rapidly driving us towards this. There's currently a disagreement on what should be in the IP is repo and it's kind of coming to a head of notice in the last couple of weeks. We're in a lot more clashing between the editors and authors. I'm hoping we don't need to resolve that before London. And so it'd be nice if we can find a solution that doesn't require us solving that problem. Yeah, I think it's going to be a big, big debate. But just adding basically the name of the shields and the specters that make sense. So the, the thing that I'm against is having the 1559 court EIP court EIP, the thing that defines the consensus changes also include specifications related to interface changes which is a whole another class of the IPs. Like, we're bleeding very rapidly bleeding away from here's the consensus changes everything you need to know for a consensus client is right here into. Oh, and also you know this is the command line parameters that we use and get and here's what parody does and then, like, this is a big can of worms that we need to solve. I just, I don't want to get too distracted by that if we can avoid it at all. So I think, does it make sense to like Peter was suggesting we add a single parameter in just in 59 that says you know this is what the fields are called. And then we add the full diff of Jason RPC somewhere else. I see Peter you have your hand up. Yeah, so I just want to say that from my perspective it's totally fine to just have a link that 1559 link to the IP, whatever which defines all this information but my point really is that we're currently entering a point where we want to have a test that clients talk to each other. And I mean if you want to test that it would be nice if clients would also share the same API. So I mean if somebody wants to do it over the weekend great but if we have to wait for that one more month that it kind of beat the purpose. It will be way too late. And actually do agree with Peter on this like we need a solution we something relatively quickly. And I mean what may end up happening is just I back down and kind of give up for now and then re approach the bigger fight later, just so we can move forward like I don't want to hold up London or anything on trying to figure out what isn't the IP. Yeah, at least if the fields are there then we know all the clients will return like yeah, you know the same value in their, in their implementation and that's probably pretty valuable with regard to like the full Jason RPC diffs. You know that's something we, we definitely should not put all in 1559. And we can either open, you know, new eaps like we had already done for the base fee diffs on the blocks, or we can add that directly in the each one specs repo if, if you know people prefer that. I don't have a strong opinion there but it feels like yeah that's probably too much of a 1559. I don't Peter is your hand up again or did you forget to lower it. Oh, no worries. And I saw somebody else put their hand up what I was speaking. Yeah, yeah, yeah, I wanted to ask if we are talking only about adding your fields or is it an option to remove a field. For example, we talked about the gas price for the transaction. So, if someone requires the transaction legacy transaction, then he gets back like a five fields, for example. And if that transaction is now 1559 transaction does it need to get to receive sorry additional fields. But without the gas price. Is it something that will break clients. What's the issue of a problem is it actually actually I think you made just a brilliant point there. So, when we're turning the receipts, previously mentioned that it might make sense to return the fees, the tip and the basic thing, but we might make sense to actually not return these to simply use the gas price which will be the actual fee in total. And if clients want to break it down, or for example, it comes down they can retrieve the base fee. But if they don't want to break it down and the gas price will mean the same thing as it meant previously in the receipt just the amount of money the user paid for it. And then know that infrastructure needs to be changed because you will receive the exact same field, which would make me in the exact same thing. It might not. So the transaction gas price and the receipts gas price must not. I mean, there is the transaction wouldn't have a gas price anymore on the receipt. Martin, did you want to say something. No, I just wanted to say exactly that, because I interpreted the question being, if these new dynamic types do not have gas price, which you just said they won't. And will that break tooling. So it was tangential to what you said, but I don't think you answered the question. I guess tooling wise, there's a bad work compatibility thing. So, if you so any tool that currently exists cannot can still send transactions using the gas price. And if you specify the gas price that it will be the legacy transaction where the gas price will be used as both the maximum fee permitted to be paid by transaction and also the maximum tip. So it's essentially there's a little trick in 1559 so that all all all currency distinct tooling will continue to function perfectly without needing an upgrade whatsoever. Well, not for something that's not for something that relies on fetching transactions over RPC and parsing the gas price and doing something clever with it. Those will not work. Yeah, so if so the only thing that would change if you were to retrieve a new type of transaction so if you retrieve a 1559 transaction and yes, that one will have the feet and feet and separate fields and won't have a gas price. So that is slightly breaking change, but apart from that I think most other API points would remain stable or at least that was compatible. So the question since we are introducing different types, well it was introduced in the previous release different types of transactions, and we is putting now transaction to type two. Are there any plans or we thinking it's a good time to put, you know, to enable having the capability to have transaction type three. And so, mainly, we all the Jason RPCs should be able to be able to return the transaction type and all the information in a generic way. And so, when we decide to change something else, will it make it much easier so that way all the tooling that we're creating, maybe like recovering signatures or whatever, building RLPs and so on, using the Jason RPC will allow us to just plug in other types of transactions as well. Yeah, but in the chat, I think they are the RPC returns transaction type. Yeah, but as we're going to introduce more fields and more information, if we can think about a way to do these. Yeah, from Mike as well. Yeah, he doesn't envelope it. Exactly. So if we create some kind of a genetic abstract wrapper for this for the Jason RPC, maybe it will be a good time to do so. Yeah, he is from agreeing to Mike in the chat. Mike, I don't know if you want to just chip in the conversation, please, because I'm going to be reading your answers. So I think what Juan is getting out here is the, we have a new transaction type and it looks very similar to the previous transactions type similar to access list looked very similar to legacy transactions. And so so far we've been able to get away with just kind of adding fields here and there. But as we get more transaction types in the future it's very likely they're going to diverge more and more. And so rather than trying to just kind of keep hacking little bits and pieces on at some point we're going to need to make a transition to, you know, transactions can be very different. And we need like an envelope or some some mechanism for dealing with transactions that are widely divergent like maybe using different signature types, different encoding types stuff like that. And so is now the right time to make that cut over to having some sort of enveloping system or some sort of typing system, or do we want to for now continue to just add on a couple of fields because we can and then we'll kick that count down the road and solve the enveloping later. My personal preference is to keep the can, but not because I don't really want to solve this problem rather. I don't think we know what we want to handle the property. So, as long as the transactions are kind of almost the same. So I would suggest that wait until we have a transaction type that that really needs it and then we can figure out some envelope in where it's actually suitable for for those needs. Also we can't delay London so that's a big one. So I think that's like mostly what we had already on the agenda. I guess the one thing we still haven't figured out is where did we track the full Jason RPC diffs. That is kind of a can of worms so yeah I want to see is there anything else that like, especially from the tool in your infrastructure side, you all wanted to bring up. I think that's kind of higher priority to discuss on the call, and we can figure out the, yeah, the Jason RPC diff elsewhere. So, how does that backwards compatibility supposed to work if we like a certain blog transaction format changes so what happens when the all the absence transactions in the old format is that specified the old transactions so legacy transactions will still be accepted by the network, even after the hard fork so from that point of view you can still send them you can still gossip them etc. The only thing that will change like if a tool doesn't do anything. Then it just means you will not be able to properly kind of parse and handle new transactions that show up in a block. So, otherwise you can still function fully so you can send them the legacy transaction you can get it it's get it by transaction hash you can get its receipt and all those things will look the same for you. So, so really, from a tooling standpoint, I don't think there's anything that absolutely must be changed with London. Someone correct me if I'm wrong there, but I think it should be fully backwards compatible. And that's the old gas calculation translate somehow to any model them. So the way it translates is just we take the gas price you supply supply and the legacy transaction, and we use that both as the priority fee cap and the backscap. So, which the way it works is basically kind of a sum of the two or I'm sorry max of the two. And so we can kind of transform it and you won't benefit from any of the benefits of the 1559. It's the nice new auction format. But it will work like it will still be mind you'll basically function just like a legacy transaction in that situation. So you use don't benefit, but it still works. And then about the envelope and gas do you perceive that there might be in the future different transaction types with different kind of gas configurations so there would be like legacy gas. And then something even different to that is that so far we've been able to always maintain like legacy transactions continue to work and I don't think we have anything on the docket for the future that will cause legacy transactions to stop working. And all the new transaction types that have been talked about and proposed are additive so it'll be a new type of transaction, which you will be able to send in addition, like or alternatively to the legacy transactions but legacy transactions will still work. Does that answer your question, or do they misunderstand. So maybe, let me refresh it a little bit. Is there a chance that there's going to be a does the gas parameters should go into envelope or into transaction itself. So I think this is what Peter was getting at is that we're not quite sure enough on what future transactions will look like to know whether they're all going to have the same, like gas limit mechanics or not. Like for example, account abstraction changes a lot of assumptions and some of those assumptions may change kind of how gas works maybe in a future transaction. So I think that's why Peter was arguing for good reason that we should be careful about building an envelope today, because we don't yet know what the right bounds of that envelope are. Makes sense. Thank you very helpful. Yeah, just wanted to add one thing that alone. I think we do. There's no immediate rush to get without legacy transactions, meaning that probably in the foreseeable few years legacy transactions will continue to work, but I do think long term. There will be a push to phase out these legacy transactions and by this legacy transaction, meaning that from 1559 onward, both the current legacy transactions and also not 1559 accesses transactions will probably be based out to mention. So there's no really no reason to keep that complexity forever. But yeah, that's probably not in the next couple of years. I see a Yokem you had a comment in the chat about send sign transaction and discuss problems on the previous dev nets. So basically how do we specify it and legacy transactions were sent as serialized transactions but for 2930 slash 1559 you had the RLP encode the serialized transaction. I think that's something we discussed when we were planning Berlin that we would just do that and it was not great, but after long debates we kind of agreed to that but I don't know somebody has like a better memory of this than I do. So currently B2 and nevermind that actually changed that they are not LB encoding these transactions and more. So I think it will be very nice to just get some consensus on this because otherwise you can send these transactions. Yeah, on basically we're actually handling both or we're accepting both, at least from the central transaction endpoint so we didn't you know we don't know what side defense this is going to land on so we're, we're properly handling both. Okay, great. Thank you. What do you do to detect which one it is. We get the first bite to see if it is seven or less. And if it is then we try to decode it as a type transaction and otherwise we go back to the legacy parsing. So was the issue would like a specific client them like what. So if base you, and that the mind seemed to support both formats, was it just because you tried to like send transaction through get them get this implementing it direct differently or I just contacted them like okay can send these transactions and then they said you should probably RP encode it and then I send it but I was here. We should get a bit of consensus on this, because otherwise, if you use this web three stuff, and you want to send these transactions, they can do it because some clients might force you to send RP encoded. And basically doubly, I'll be encoded for sections of RPC and other clients will not. But I think, like how big be so soft at this point is like very nice, and we can agree later, like what the actual consensus should be. So that's, that's fine too. I think that kind of really doesn't make sense to. But this is again, I would say this is a nice little bit for Micah, just stating that some rock protection and point must accept this and this and this transaction in these and these formats. I think if, for example, if there's a try them working way to do it and sometimes don't support it. I don't know whether that supports it or not. I think it's going to be fine to open a feature request. Anyone here strongly wants to RLP encode that an extra time, or is everybody either in vigilant or in favor of not RLP encoding it will be nice to be specific that way, you know it's not ambiguous in the future. Yeah, I'm just wondering if there's anyone arguing on the other side of the fence or not. I would argue that send raw should take the binary form of the transaction, whatever that may be which indicates new transactions is not RLP. Anyone disagree with that. I agree with Martin. Sounds like consensus. This is me consensus of your silence. Tim stepped away for a second but I just want to give a quick plug for ETH R&D discord if you haven't joined there that's where a lot of this discussion is happening through a couple different channels there's one specifically related to 1559. This is, you know, the general alternatives channel so if you're not already in there, I would strongly encourage you to at least check it once a week and get up to speed on where discussions are heading. It's definitely going to going to help us move towards London in these next few weeks, you know getting block numbers out and stuff like that will just help you stay in touch with where things are headed. Yes, apologies about that. So where's the best place to document the RLP decision. Yeah, the non existent Jason spec. Okay. We really need to get Jason specs. Yes. So that's one thing. If somebody on this call wants to help with a Jason spec and has the bandwidth. We definitely have funds to pay for that. If somebody wants to help, you know, from the, like, yeah, so if it feels like for a lot of people on this call time is the bigger issue than money. But if you do have the skills. And, you know, money is the bigger issue. Please pay me. And we can definitely get this going. And ideally, if it was somebody that's kind of adjacent to the time devs, I think that would help because there's a ton of work to do on the actual consensus bits before London. So I suspect if we rely on like get there. Never mind or base you. We might not get the specs in time so I'll be both reaching out to folks and accepting inbound for anyone who wants to help try to spec the Jason RPC diff. We can probably get somebody, you know, one of the courteves to just add the quick paragraph 1559 about the para parameter naming, and then whoever works on the diff can, you know, use that as a reference. I'll be, I'll be, I'll be following up on that right after this call. So we only have eight minutes left. Was there any other topic that anyone on the infrastructure side wanted to bring up fork timelines comment from EG at the challenge just time around is the difficulty bomber. So we don't really have a ton of leeway with regards to the fork timeline at least remain net. So that's can come basically whenever before main net but mid July is kind of when we have to fork on main net. So this is kind of the main constraint here. And realistically we probably want you know the last kind of test that fork to be at least two three weeks before that. So if you have like late June for the last test that fork. Yeah, I have an actual doctor with dates. But I think it was like yeah July 14 was made net. July. Let me let me try to find the timing doc July 14 was made net. June 30 was the last test net. Oh sorry no June 23 was the last test net, and then the first test that would be June 9, which is kind of a month from now. So I had I see EG has put a spreadsheet. There. Oh yeah so that's basically my spreadsheet. So I'm yeah the blocks. Yeah the blocks may or may not be accurate but I think this is basically a, you know, at least at the week level accurate for if we did want to. If we want to have a main network on July 13 and have a fair amount of testing of time on the test that's before that. If the first fork date is the biggest issue. You know, we can either have like less time between the last test network and main net. We can maybe have more of the test that's working at the same time which is not great. So it's kind of where we're at. I don't know if anyone else has thoughts comments on this aside that it's a very tight timeline. Yeah, I don't have comments on that specifically but regarding Michael. Yes. I don't know how the other clients. How close they are. As for guess. I think the week could basically spin up by call. Immediately. If we really don't want to. And so maybe we can get it started during the weekend. Basically as close we have, we have the configs the four configs in there but I think we still have one, at least one of the necessary EPS still outstanding so we're close but not there yet. Yeah, did. Oh, we didn't really mention it but so we thought I just merged the light lines change to 1559 and I merged like science PR to modify 1559 so the gas bicycle implementation on 1559 is the new one with the unambiguous header gas limit. Does that have behavior at the transition already or is that just something that would happen when we're doing subsequent testing. Sorry what the baby. The, the 2x at the transition. Like client correct me if I'm wrong but I would say yes. I need to look and add it again hold on. If I recall correctly, we just take the previous guest and interpret the targets, as if it were the target. That's what the spec says. I thought there was that there was still some conversation about that earlier about whether that was going to be a sorry I was dealing with the kid in the morning so I was mostly only auditing earlier but I was talking about whether it was going to be option one two three or four about how we're going to treat this target at the transition. I believe everybody we came to consensus that we will have a on the fork block, you will be parent gas target will be equal to the parent gas limit. Okay, and for everything else. It's as it was before basically. And for everything for every block after that, the parent gas limit is the parent gas limit. So, the target is half of that. There is one issue that sorry I didn't get on the agenda I forgot. Currently, all clients implemented something differently than the spec so either we need to fix the spec or we need to fix all the clients. Does anyone remember like land you remember what that was. I think everybody right now is is setting the default initial base fee at the fork block and I think the spec technically says that you should treat blocks before the fork block to have the initial base fee. So technically on the fork block we should have calculated a base fee but at the moment all clients just use default base fee. So, so right now, we need to either fix the spec or need to fix the clients. I'm weekly in favor of fixing the clients because I think the code complexity to do with the spec says is lower. But I will acknowledge that the code complexity difference is fairly mild. I would rather keep it as is. I don't think it's functionally any different. And I don't think that it is going to simplify things much. So it means that the clients would set a base fee in the block before the fork on the spec. And so what this is what the spec says is that when you are on the EP 1559 fork block. You treat the parent block as though it had a base of x, we're going to the clients what they implemented is is when you're on the fork block, you just set the base fee to some hard coded value. I mean, I think they're both basically the same. It's just, do you set the base fee one block before or the fork block. And I think the fork block is actually a little bit simpler. I kind of agree because if you set the base on the parent block, while the base fee of the fork will depend on how full the parent block is, but the parent level doesn't yet have this gas target gas limit differentiation. So it's a bit weird. Yeah, I agree. And let's do 1559 one that for kids and that's the backboard some concepts in the parent. So that means we need a PR to this back to also change that but that would change anything in the client implementations right because anyone want to volunteer a PR to the spec that updates this sounds like you have to pick somebody. I can do it. Okay, thanks out. Cool. And we're at time but I just had a final question about Michael. It seemed in the chat that base you had wanted missing open Ethereum was missing refunds that their mind was missing refunds. Does that mean people have the other eep, which was 3541 like the basically disabling the contracts being deployed with the starting by code. Yes, yes. I see the inverse for basically I believe I think we have the refunds disabled and don't like. And then also the changes for 1559. Got it. Sorry, I didn't fully understand. Yeah, so do you open a theorem in that their mind have EIP 3541 for Michael or not. Yeah, I just want to make sure. We don't have a reduction in refunds refunds reduction sorry. But we start work on it. Okay, got it. I don't want to keep people too long. Yeah, I just wanted wanted to say really quick. So this this call itself was seemed it was pretty in depth or in the weeds on Jason RPC stuff. So thank you for, you know, libraries who libraries and tooling that joined and maybe didn't have a direct contribution but it's probably still valuable to listen in and see where the changes are headed. In the future, we'll probably have more of a stand up type thing where clients and libraries can just give their brief updates. We didn't get to that part but in the future we can probably arrange something more like that and then at least the next question which is when or if should, should, should we have a next call. I, we hadn't assumed this would be a recurring thing but it seems like this was a really productive discussion so I'm curious, Tim what do you think in two weeks three weeks after the four block is set what is your intuition. It feels like we have a lot of stuff to do. You know, both on the client implementation side, the Jason RPC spec side. Yeah, I don't know. I'm cautious of like imposing another meeting. Yeah, I should have also said like we don't need to set it right now as well. So let's see. Yeah, I guess my preferred option would be to see on all quarters next week where we're at and if we feel like this is necessary. I think in the meantime, you know if folks have like specific issues or concerns that come up, raising them either on the discord or on each magicians is really good and we can kind of, you know, it'll help get a feel for how many issues we actually have and and whether we need a separate, a separate call for them, or if we can deal with some of them in all quarters next week. Yeah, and then I'll just point everybody back to that tracker. So if, if you do have an update or work that started, I know things are a little still up in the air but once you do start that work, like the JavaScript team has, I know they've started some things. Just put PR to that and or DM me and I can update it for you. That would be a great help. Any, any final things. Was this helpful for folks on the non-corded slide? Yeah, we do have a lot of things to go research after the call. So yeah. That's a good outcome. Everyone brought together for this. The client library teams don't tend to speak that much to one another. I think it's definitely helpful. Awesome. Okay, well yeah, thanks everybody. See you. Thanks for attending. Bye.