London Infrastructure Readiness (Breakout #8)

okay hi everybody uh welcome to uh first infrastructure call we have um yeah this is the first time we do this to try and align basically uh the different tooling layers and infrastructure layers uh with the work that we're doing at the protocol level um yeah trent has some set this up i don't know if you want to give a quick overview trend of likes yeah how sure yeah sure so um we wanted to just start early and we know that there's a lot of complexities with um 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 this call will be like tim said in experiment we're trying to get people to just have a quick synchronous discussion um and hopefully we'll iron out some issues uh together and come to consensus on what things should be um i know i've i think i spoke to almost everybody who's on the call so hopefully my intro to what this project is is um sufficient but if you have any questions feel free to reach out um either on discord or twitter telegram whatever works and i can answer any questions but yeah so we're uh this is the a one-off for now um we're not planning to have this every two weeks or anything um but we'll see you know what the need is going forward after this call um i dropped the agenda in the chat so if you'd like to see that it's pretty short uh so we have a lot of leeway on what we can actually discuss main topics are going to be json rpc and um i think there was another one that i added recently but yeah uh if there's any initial questions otherwise we can probably just get started with discussion on json rpc um yeah actually i i guess uh just there were like yeah three things on the agenda so there's just an ipc 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 um 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 uh yeah that's kind of agreed upon uh yeah and i think yeah i was just gonna say you reminded me i should probably mention the tracker so the the other component to this in addition to the call to this uh london readiness the london infraredist initiative uh is that there's a tracker that we put together um so similar to how tim tracks the clients to see where they are at with um implementing each of the eips we're also experimenting with this tracker for libraries and tooling so uh if you go to that um 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 uh that document and then update saying oh this is in progress or uh we're done with it and then it'll just give us an idea of where everybody's at um so yeah check out that link and then to you can just take it away with whatever you'd like to start with cool thanks yeah i think starting with the with the block header is probably the most important because yeah as i said that'll change like the consensus and to give just a quick background uh the original spec 1559 would change gas limit in the block header to gas target and the way 1559 works is we want to target a certain amount of gas but we're fine going uh up to 2x above that so using numbers from the network today uh 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 get kind of gauge uh supply and demand for for the network um and uh so the original uh basically sp proposal in the eve was to change gas limit for gas limit the gas target in the block header um but as we were implementing that and testing it we realized that breaks a bunch of things um and so there was a proposal this week to kind of switch that uh to instead use still the gas limit in the header um but that means that on the fork block we would have to bump the gas limit 2x so it would basically go from you know 50 million to 30 million if that's the numbers were at um but then at least the uh the field in the header would still return the maximum amount of gas that a block can can consume um i think martin or peter had written kind of the formal proposal for that light client wrote the pr to the to the eip um 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 miners when they set up to configure their nodes they can figure 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 miner has the gas limit set via command line to 15 million all of a sudden as soon as the ip1559 lands they will start pushing the gas limit down because the block will have 30 million and their miner is configured to try to target 15 million so we have a couple options to address that we can um try to just communicate with miners 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 a fork block is dangerous and hard and whatnot we can just accept the block gas limit is going to be volatile for a bit around the fork and it 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 set um 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 one five five nine block and then the user can remove that and it can be deleted from guess later um but that's that's the current thing that we need to address to move forward i think and i guess technically we don't have to address those so each client can address it separately since i think almost all minors run guess really this is a guess problem yeah does anyone from the guest team have thoughts on that yeah so personally i think i would prefer just asking miners to please bump so after the fork presses just bump the gas limits up a bit and if 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 even if it's half a day worth of 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 then we need to convince everybody to use them and then when we delete them we again need to convince everybody to meaningfully reconfigure so it's uh i mean we we either way need miners to do something so might as well keep it simple and have them do the right thing from the get-go for example if if we want to be nice and we don't want them to to screw with the estimate during the fork we can also tell them to hey just start start targeting 30 million two hours before the fork and then yeah guess when it will go up a bit and then it will come down so i think it's i would personally just rely on miners to to sort this out so i can definitely try and communicate with miners and and and like see see if if they think that makes sense um how i guess assuming so my fear is not that minor 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 um assuming we didn't hear back from miners and we kind of don't know what they'll do um would it be possible to add this yeah i guess what's the latest we could add kind of a flag like this how latest would be the fourth release okay so yeah i'll follow up i'll send an email and uh but also at least we do keep in touch with two mining pools or i will discuss say keep in touch what we every couple months we maybe just exchange a message and they are generally i mean if we contact them that hey there's something screwy and get or there's something that you need to take care of that you should respond i don't think it's a problem that they won't care so as long as you can get the few larger pools to play nicely with the gas target i mean to properly set the stuff up the rest even if somebody misses it they won't negatively influence the network i got it and you as a miner if you're a small miner and you just misconfigured your note you don't have that so there's absolutely no negative impact on you so it's not like we're being actively harmful to small miners who don't know about this okay cool so we can do that um so i know i think light client had a pr against the 1559 spec to uh to make this change um does anyone object this change last chance okay so i guess we can go ahead and merge your commit into the spec uh light client and um i'll update the london spec to reference that latest commit for 1559 um and that's probably what we'll use for the next uh test nets of or the devnet for baiko and the way uh just to clarify um 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 as far as i know currently aspects starting from yes i think that is good and expected behavior well that's essentially 59 is to allow twice as much gas yeah that's kind of i mean that's the correct behavior in my opinion okay great and uh yeah i'll make sure that we get an author of the eep 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 json rpc fields i know there were a lot of different threads on that so there was the eat research uh thread originally uh then the get team put out a proposal this week um to have basically shorter names and and try to match the current uh terminology with gas gas limit gas used and what not um 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 uh yeah i don't know if martin or peter you want to walk us through what you had as a proposal and i think uh micah and my client also had uh yeah comments on that uh sorry for the json rpc naming so basically right now yeah i think the the fields were like max priority fee for gas micros um and uh i think guest wanted to expose those as gas tip cat and gas fee cap respectively yeah one thing that i think yeah 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 a lump sum accumulated so if you set uh 20 000 you should know that this is 20 times 20 000 times whatever gas you're gonna have it's not like so we wanna and i think that's the that's the root thing that we want to be clear about peter do you want to expand sure so essentially the small confusion came from from the implementation that uh essentially i think implemented the ib 1559 for us and uh we didn't really like and i can share that sentiment that really long next priority fee per gas naming and then he was suggesting to just go with a tip and gas cap yeah no sorry tip and pecan and essentially this is where this whole misunderstanding stemmed from and we can't realize that it is from a user's perspective it is super important to signal this that some field is per gas and not not a total and the interesting thing was that the spec didn't mention at all there are the json rpc aspects so the the 1559 vip focuses fully on the consensus things and defining the variables and constants and algorithms and whatnot but it absolutely no mention on whatsoever on how these things will be named for the user and and essentially that's that was the reason why we wanted to bring it up because when implementing it it needs to be surfaced out of the user obviously it needs to be in consensus across different clients because every wallet and everything needs to implement this and and then the question is how do we name these fields um if we were to go with just inherently what's in the eip then these fields would be named max fee per gas and max priority fifa gas these two names i mean they are they are a correct description of what the fields is that my problem is that currently the jason received by sending a transaction there is a naming style for example we have gas limit gas star sorry we have gas gas limit gas price gas use these are fields that the currently the api sends and receives and then it will be weird that okay we have gas price and we have max priority fee for gas which is essentially almost the same thing and then our suggestion was to simply call the tip i mean call it this priority fee we can call it uh gas tip cap or anything if somebody has a better idea and for the for the base fee which is actually paid by i mean the total that the gas uh that the transaction campus who previously got gas priced and that would be kind of renamed to gas fee cap so it's um it's just a slightly shorter version you could also call it max paper gas or but that doesn't really fit in with the rest of the variable naming and that is why we kind of suggested gas speaker and yeah the tip was just something similar to the gas sticker but uh all in all the reason why you kind of brought it up i don't really want to go into bike chatting because everybody has their feelings and the most important things for me is that the spec actually states what the name of this fields should be because that's that's the thing that we need to agree on what is the status of the eips for the json rp or for the json rpc spec for this stuff yeah that's what i was going to say we had a list of separate eips for the different rp json rpc calls um 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 there's there's confusion around that yeah so we have like eip uh eip31 and i think there's like 30 44. um 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 a json rpc eip for the transaction fields um so basically get transaction by block number and index get transaction by hash and all that uh we we never drafted eips for those um so i i don't know would that be the better spots to actually agree on those terms like creating separate eips for the various gesture rpc calls or do we want that in 1559 itself i think it's kind of overkill to create a separate yet we just to name the fields i mean in 1559 it's obvious that there are two fields that needs to be exposed we might as well just add them in 1559 so the um we do need to specify i think the json rpc calls like there's a ongoing effort to specify all of json rpc and get it um agreement between the clients and so for me that feels like the right place to specify what the fields are um the caveat being there that we are kind of in a in 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 pole here and so i think uh i can kind of appreciate where peter's coming from that if we don't end up actually finishing at jason rpc spec before london then um we're gonna 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 uh needs to be fixed there i i i agree with them what peter's saying london i think that we'll be in a better place sorry apologies um mika um yeah i i think um from our perspective in terms of when it comes to implementing the json rpc uh calls it's it's certainly easier if everything's in one place i you know we didn't say um the the original eip you have an explicit clause that calls out the json rpc changes the risk of course with having separate json rpc um eips is that then you've got to link from the ones that affect the clients back to them and then they might not stay in sync whereas if someone's updating like a single i eip then you know you can just search for all occurrences of that 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 json 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 as such on the apis and that's fine okay so basically so it doesn't need to be some conclusive spread the idea is to just give a hint on so that every client is on the same page on the naming convention got it so we say we're adding base fee into the block we're adding uh i forget what the agreed upon naming but we're adding gas fee cap into the transaction and gas tip cap into the transaction basically yeah that would be i think if somebody feels very strong about a different name again we can backshot this offline i was just the whole point is to just have the information somewhere there was um one other uh question that was being discussed i think which was so you 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 json rpcs would expose the actual values chosen like the actual fee paid and the um the actual tip paid or whether it would be up to clients to calculate them themselves so i guess 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 so maybe we could extend the receipt to to include these fields so the five 1559 actually originally had uh receipt changes if i remember correctly and then i think we took them out because we didn't want to include derived data in the receipt um that being said we can return additional information in the json 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 i didn't mean to change the consensus field because these obviously can be just calculated so when you retrieve the receipt you know which block it was in so you have the base key and then if you have the base key and have the the these limits set by the transaction you can just specify the bit 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 databases one for the transaction one for the block to calculate i have to read upon this a bit i mean let me check the code but i think uh get already does uh quite a number of database reads when for example you retrieve a receipt because we don't store the receipts one by one rather we store them grouped by but i think this so the legitimate question is are callers expected to have access to this i would say probably yes because for example if you just look up your transactional interest and you probably want to know how much you paid for it so yeah 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 the total fee paid right there in the json rpc like yeah i see some people nodding i would say so yeah yeah it definitely simplifies the code quite a bit okay so i think if we can expose it uh we should at the client level um and so okay and then there's a couple comments in the spec uh about that where the spec should live uh saying you know having a full diff would be good maybe if that's something we want to start the new kind of json rpc repo with uh that that would be valuable um so i think for sure we can commit you know to adding the the fields uh the the actual new fields in the 1559 specs so at least people know how to name them um this gets into i'm trying to avoid bringing this up but this conversation is rapidly driving us towards this uh there's currently a dis disagreement on what should be in the ips repo and it's kind of coming to a head of notice in the last couple of weeks we're seeing a lot more clashing between the editors and authors um i'm hoping we don't need to resolve that before london and so uh it'd be nice if we can find a solution that doesn't require us solving that problem yep because i think it's going to be a big a big debate but just adding basically the name of the shields and the spec does that make sense so the the thing that i'm against is having the 1559 core eip core eip the thing that defines the consensus changes also include specifications related to interface changes which is a whole other class of vips like we're blocking the standard is 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 in geth and here's what parity does and then like this is a big can of worms that we need to solve um i just i i don't want to get too distracted by that if we can avoid it as all so i think does it make sense to like peter was suggesting we add a single parameter in 1559 that says you know this is what the fields are called and then we add the full diff of json 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 from 1559 link to eipd whatever which defines all this information but my point really is that we are currently entering the point where we want to have a test that's where all 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 apis so i mean if somebody wants to do it over the weekend great but uh if we have to wait for that spec one more month then it kind of beats the purpose so it will be way too late and i actually do agree with peter on this like we need a solution we need something relatively quickly um and i mean what may end up happening is just i back down and kind of give up for now and then reapproach the bigger fight later um just so we can move forward like i don't want to hold up london or anything um on trying to figure out what is in the ip so i think yeah at least if the fields are there then we know all the clients will return like yeah you know the same value uh in in their in their implementation and that's probably pretty valuable with regards to like the full json rpc diffs um you know that's something we we definitely should not put all in 1559 um and we can either open you know new weeps like we had already done for the base fee diffs on the blocks or we can add that directly in the eth1 specs repo if if you know people prefer that um i don't have a strong opinion there but it feels like yeah that's probably too much of brilliant 1559 i know peter is your hand up again or did you forget to lower it no worries um and i saw somebody else put their hand up while i was speaking uh yeah yeah yeah i wanted to ask if we were talking only about adding new 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 a transaction legacy transaction then he gets back like five fields for example and if that transaction is now a 5059 transaction does it need to get to receive sorry uh additional fields but without the gas price is it something that will break clients how much of a problem is it actually actually i think you made just a brilliant point there uh so while returning the receipts uh previously you mentioned that it might make sense to return that piece the tip and the base keeping but it might make sense to actually not return these to simply use the gas price which will be the actual fee paid in total and if clients want to break it down or for example ether scan they can retrieve the base fee but if they don't want to break it down then 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 no that infrastructure needs to be changed because you would receive the exact same field which would mean the exact same thing just it might not so the transaction gas price and the receipts gets priced messed up 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 then will that break tooling so it was tangential to what you said but i don't think you answered the question [Music] so i guess too ling wise there's a backward compatibility thing so um if you so any tool that currently exists can can still send transactions using the gas price and if you specify the gas price then it will be interpreted as a legacy transaction where the gas price will be used as both the maximum fee primitives to be paid by transaction and also the maximum tip so it's uh essentially there's a little trick in 1559 so that all all currently existing tooling will continue to function perfectly without needing an upgrade whatsoever and of course if you want to well no not for something that not for something that relies on fetching transactions over rpc and parsing the the gas price and doing something clever with it those will not work yeah 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 1569 transaction then yes that one will have the fee at fika and separate fields and won't have a gas price so that is a slightly breaking change but apart from that i think most other api endpoints would remain stable or at least backwards compatible quick 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 uh are there any plans or are we thinking this is a good time to put you know to enable having the capability to have transaction type three and so mainly we all the json rpcs to be able to uh be able to return the transaction type and all the information in a generic way so later on when we decide to change something else and will it make it much easier so that way all the tooling that we are creating maybe like recovering signatures or whatever building rlps and and and so on using the uh json rpc information what allows us to uh yeah just plug in other types of transactions as well and yeah but the in the chats i think they are the rpc returns transaction type yeah but we're going to introduce more fields and more information if we can think about a way to do this uh yeah from micah as well yeah he doesn't envelope it exactly so if we create some kind of a genetic abstract wrapper for these for the adjacent rpc maybe it would be a good time to to do so um yeah yeah yes from yeah agreeing to mike in the chat if you were you mikey i don't know if you want to just chip in in the conversation please because i'm going to be reading your answers but so i think what juan is getting at here is the we have a new transaction type and it looks very similar to the previous transaction types mode 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 gonna need to make a transition to you know transactions can be very different and we need like an envelope or some uh 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 uh 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 envelope properly so as long as the transactions are kind of almost the same it's super hard to create an abstract envelope that will properly really be useful so i would suggest let's wait until we have a transaction type that's that really needs it and then we can figure out some enveloping where it's actually suitable for for those needs also it won't delay london so that's a big plus get through so i think that's like mostly what we had already on the agenda um i guess the one thing we still haven't figured out is where do we track the full json rpc diffs um that is kind of a can of worms so um yeah i i want to see is there anything else that like especially from the tool in your infrastructure side you all wanted to bring up uh and i think that's kind of higher priority to discuss on the call and we can figure out the yeah the json rpc elsewhere yeah so how does that backward compatibility supposed to work if we uh like at certain block the transaction uh format changes so what happens when the all the app sends transactions in the old format is that specified uh the old transactions so legacy transactions will still be accepted by the network um even after the london hard fork so from that point of view you can still send them you can still gossip to them etc the only thing 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 in 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 um 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 does the old gas calculation translate somehow to a new model then yeah so the way it translates is just we take the gas price you surprise supply in the legacy transaction and we use that both as the priority fee cap and the max cap so um which the way it works is basically kind of a a sum of the two or i'm sorry max of the two and so um we can kind of transform it and you won't benefit from any of the benefits of eip1559 so you won't get that the nice new auction format but it will work like it will still be mined you'll basically function just like a legacy transaction in that situation so users 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 new gas and then something even different than 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 um all the new transaction types that have been talked about and proposed are additives 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 the legacy transactions will still work does that answer your question or do they misunderstand so maybe let me rephrase it a little bit is there a chance that there's going to be a does the gas parameter should go into envelope or into transaction itself i see so i think this is what peter is 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 make sense thank you very helpful just wanted to add one thing that although i think we do there's no immediate rush to get rid of 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 fantastic transactions and by these legacy transactions meaning that from 1559 onward both the current privacy transactions and also non-1559 access transactions would probably be phased out eventually so there's not really no reason to keep that complexity forever but yeah that's probably not in the next couple years cool uh i see uh joachim you had a comment in the chat about send signed transaction and this caused problems on the previous devnets um so basically how do we specify it uh and legacy transactions were sent to serialize transactions but for 29 30 1559 you had the rlp encode the serialized transaction um i think that's something we discussed when we were planning berlin that we would just do that and it was not great but uh after long debates we kind of agreed to that but i don't know if somebody has like a better memory of this than i i do well currently b2 and nevermind have actually changed uh that they are not uh encoding these transactions anymore so i think it would be very nice to just get some consensus on this because otherwise you can't send these transactions very far yeah on on basically we're actually handling both or we're accepting both uh at least from the send raw transaction endpoint so we didn't know we don't know what side defense this is going to land on so we're we're uh properly handling both okay great nice out of curiosity what do you do to detect which one it is we look at the first byte to see if it is uh 7f 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 with like a specific client then like what so if basu and nethermine seem to support both formats was it just because you tried to like send a transaction through get and get is implementing it directly differently or no i just contacted uh i'm like okay you can send these transactions and then they said they said you should probably rp encode it and then i send it but i thought here we should get a bit of consensus on this because otherwise if you use this web 3 stuff and you want to send these transactions that you can do with because some clients might uh force you to send rop encoded so dope basically doubly rp encoded transactions over rpc and other clients would not but i think like how bisho solved it at this point is like very nice and they can agree later like what the actual consensus should be so that's that's fine too yeah yeah kind of agree does it make sense to but this is again i would say this is a nice little vip for micah just stating that the central transaction endpoint must accept this and this transaction in these and these formats but i think if uh for example if there's a uh tried and working way to do it and the some clients don't support it no idea whether it supports it or not i think it's gonna be fine to open a feature request and add added because it's completely reasonable is anyone here um strongly wants to rlp encode that an extra time or is everybody either ambivalent or in favor of not rlp encoding it would 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 yeah i would argue that sandra should take the binary form of the transaction whatever that may be which indicates new transactions is not repeat anyone disagree with it i agree with martin sounds like consensus yeah it sounds like it says to me consensus via silence uh tim stepped away for a second but i just want to give a quick plug for the ether 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 and then there's you know the general awkwardness channel so if you're not already in there uh i would strongly encourage you to at least check it once a week and get up to speed on on where discussions are heading um it's definitely gonna going to help you as we move towards london in these next few weeks you know getting block numbers out and stuff like that it'll just help you stay in touch with where things are headed oh tim's back yes apologies about that so where's the best place to document the rlp decision uh yeah the non-existent json spec okay we really need to get json specs yes afterwards so that's one thing uh if anybody on this call wants to help with a json spec and has the bandwidth we definitely have funds to pay for that um 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 uh and you know money is the bigger issue uh please pay me and we can definitely uh get this going um yeah and and ideally if it was somebody that's kind of adjacent to the client devs i think that would help because there's a ton of work to do on the actual consensus bits before london uh so i suspect if we rely on like geth or uh nethermind or baysu uh we might not get the specs in time so i'll be both reaching out to folks and accepting inbound uh for anyone who wants to help try to inspect the json rpc diff uh we can probably get somebody you know one of the core devs to just add the quick paragraph to 1559 about the parameter naming and then whoever works on the diff can uh you know use that as a reference um yeah but i'll be i'll be i'll be uh following you 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 uh fork timelines uh comment from eg uh the challenge this time around is the difficulty bomb uh so we don't really have a ton of leeway with regards to the fork timeline at least for mainnet um you know test nets can come basically whenever before maintenance but mid-july is kind of when we have to fork on mainnet um so this is kind of the main constraint here um and realistically we probably want you know the last kind of tested fork to be at least two three weeks before that so if you have like late june for the last test net fork um yeah i have an actual dock with with dates uh but i think it was like yeah july 14th was mainnet uh july let me let me try to find the timing dot july 14th was main net um june 30th was the last test net uh also you know june 23rd was the last test net and then the first test net would be june 9th which is kind of a month from now uh this is what i had i see eg has put a spreadsheet there oh yeah so that's basically my spreadsheet so i'm yeah the blocks uh yeah the blocks may or may not be accurate but i think this is basically uh you know at least at the weak level accurate for if we did want to if we want to have a main network on july 13th and have a fair amount of testing earth time on the test nets before that um if the first fork date is the biggest issue um you know we can either have like less time between the last test network and main net uh we can maybe have more of the test networking at the same time which is not great um yeah that's kind of where we're at yeah 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 baikal yes um i don't know how the other clients how close they are as for gif i think the we could basically spin up by call [Music] immediately if we really wanted to and so maybe we can get it started during the weekend basically is close we have we have the the configs the four configs in there but i think we still have one at least one of the necessary eeps still outstanding so we're close but not there yet yeah did uh oh and we didn't really mention it but so vitalik just merged the light lines uh changed to 1559 um and i merged light lines pr to modify 1559 so the gas bike implementation on 1559 is the the new one with the the unambiguous header gas limit and 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 behavior the the 2x at the transition like client correct me if i'm wrong but i would say yes i need to look at it again hold on if i recall correctly we just take the previous gas limit and interpret it as the target as if it were the target there was still some conversation about that earlier about whether that was going to be i'm sorry i was dealing with a kid in the morning so i was mostly only auditing earlier but um we're still talking about whether it was going to be option one two three or four about how we're going to treat let's limit yes target at the transition i believe everybody we came to consensus that we will have a on the fork block you will the parent gas target will be equal to the parent gas limit okay and for everything else um it's as it was before basically ah sorry not not as it was before 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 uh implemented something differently than the spec so either we need to fix the spec or we need to fix all the clients um does anyone remember lakeland do you remember what that was i think everybody right now is is setting the bait the default the 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 for that so yeah so so right now we need to either fix the spec or need to fix the clients i'm weakly in favor of fixing the clients because i think the code complexity to doing what 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 functional any different and i don't think that it is going to simplify things much it does feel so it means that the client would set a base fee in the block before the forge on the spec and no so this what the spec says is that when you are on the eip1559 fork block you treat the parent block as though it had a base value of x where x 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 so i would kind of agree because if you set the basic and the parent block well the the base view of the fourth program would depend on how full the parent block is but the current level doesn't yet have this gas target gas limit differentiation so it's it's a bit weird so yeah agreed so i kind of convenience let's do 15 59 when the four kids and let's try to backport some concepts into the parent so that means we need a pr to the spec to also change that but that would change anything in the client implementations right does anyone want to volunteer a pr to the spec that updates this sounds like you have to pick somebody um i can do it okay thanks um [Music] cool and uh we're at time but i just had a final question about baikal um it seemed in the chat that uh basu uh had one eight missing open ethereum was missing refunds that their mind was missing refunds does that mean people have the utter eep which was 3541 like the uh basically disabling uh the contracts being deployed with the starting byte code um death yes i see the inverse for basic i believe i think we have uh the refunds disabled and don't uh fight and then also we need to implement the uh the changes for uh 1559 got it uh open ethereum that's reminded yeah so do open ethereum and nethermine have eip 3541 for bicycle or not just yeah i just want to make sure um uh we don't have a reduction in refunds refunds reductions are already but we start work it work on it okay got it uh i don't wanna i don't wanna keep people too long yeah i just wanted wanted to say really quick um so this this call itself was um seems it was pretty in-depth or in the weeds on jason rpc stuff um 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 these changes are headed um in the future we'll probably have more of a stand-up type thing where clients and and libraries can just give their brief updates um so apologies if we didn't get to that part but in the future we could probably arrange something more like that and then that leads to the next question which is uh when or if should should should we have a next call um i i we hadn't assumed this would be a recurring thing but it seems like this was a really productive discussion so um i'm curious tim what do you think in two weeks three weeks after the fourth block is set what is your intuition so it feels like we have a lot of stuff to do you know both on the client implementation side the json rpc spec side um yeah i i don't know i i i'm cautious of like imposing another meeting so yeah yeah i should have also said like we don't need to set it right now as well that's yeah so let's see yeah i guess my preferred option would be see on all core devs next week where we're at and if we feel like this is necessary um i think in the meantime you know if folks have like specific issues or concerns that come up uh raising them either on the discord or on each magicians is pretty good and we can kind of uh 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 core devs next week awesome yeah and then i'll just point everybody back to that tracker um so if if you do have an update or work that started um 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 um just pull a 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-cordial side came away with a lot of things to go research after the call so yeah that's a good outcome brought together for this i think uh yeah the the live decline library teams don't tend to speak that much to one another i think this is definitely helpful awesome um okay well yeah thanks everybody see ya thanks for attending thanks bye