# EIP 1559 Implementers' Call #5

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2021-10-09
- Duration: 56:58
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-SHVfypwL5W8
- YouTube: https://www.youtube.com/watch?v=SHVfypwL5W8

## Description

https://github.com/ethereum/pm/issues/209

## Transcript

so we are recording uh to the cloud thanks everyone for coming to the fifth 1559 implementers call um just shared the agenda in the chat uh basically there were a couple things i wanted to cover today first just to get kind of a status update uh on both the implementers and researchers side uh so i think abdul and barnabas can help cover that um uh we had the merged transaction pool pr to talk about what that got decided async so that's already merged in um and the two other things i guess i'd like to to get people's thoughts here on are uh the survey i just shared uh last night uh which gave a lot of uh i guess projects uh concerns about 1559 uh i'm mostly interested in like the stuff that relates to implementers around json rpcs and opcodes and whatnot and if people have suggestions of how we can uh plan uh to just include that to make it easier for projects to test um and then there was this other document like the mainnet readiness checklist to just kind of walk through what are the things we'd like to see uh from 1559 before it gets ready to bring back the awkward ads for my net considerations i know last time we had talked about uh moving like a proof-of-work test net uh so i'm curious to get everyone's thoughts on that and what the best next step is um from where we are right now um yeah so maybe we can start with updates uh abdel do you want to just give a kind of overview like i think it's been like a month since the last call so what uh you and the other implementers have been working on yeah uh so you we have been working on uh implementing the latest changes from the specification so the computation of the base field has been changed and we updated the implementation accordingly we already deployed the test net from scratch and we were able to sync also with a determined client so which is great and now i'm finalizing the the remaining changes the removal of the transition period and also the use of a single transaction pool so that will be available i hope tomorrow and i will restart the fresh test net with the version aligned with latest specification we are also aligned with uh about the gas price uh behavior so nika submitted the pr and uh i approved it and it has been merged so we decided that the gas price opcode should return the effective price the user will pay actually this is a minimum between fee cap and minor broad minor bribe plus the basic and yeah this is it and yeah i was able to spam the network and reach almost the maximum block elasticity so i was able to to target 38 million gas blocks and yeah everything was fine so this is pretty cool that's it that's great um do you know you mentioned like uh you're working on the latest changes of the spec do you know where uh the go implementation and the nethermine implementation are at with regards to that uh i think uh like client is on the call so maybe he can give an update about netermind but i know that get is get people so vulcanize is still investigating the conservative issue so i'm giving them some help using the transaction sender tool to try to reproduce the consensus issue okay and yeah do you know about nethermine uh yeah i i said that i think that uh there is someone in i don't think so light science is not from nethermine ah oh sorry no okay sorry so yeah um yeah uh netermind so they are also aligned on the basic computation and i saw in the chat that uh i she he already removed the transition period so that should be fine when i will redeploy these nodes we should be able to sync again great uh i know someone kind of jumped in to say something while you were talking no okay um cool barnaby do you want to give a quick update on on the r d side sure yeah yeah thanks tim um so recently i've published a notebook on strategic users that was the latest let's say public release yeah the idea behind it was to kind of look at this idea that well 1559 is useless because anyways users will keep competing on the tip and i think what the notebook really shows is that you can have this sort of strategic behavior but it doesn't last very long when the network is not subject to wide let's say shifts in demand which is most of the time so yeah that was published maybe i can drop the link in the chat after that um we've been working with fred who's on the call looking at the transition period out of the legacy transactions and into 1559 so trying to model it trying to simulate it and even trying to look at an idea that was floated around the discord channel to have some kind of tax on legacy transaction where the tax is increasing over time which is kind of like the let's say the stick to the carrot of making users uh shift out of using the legacy transaction and into 1559 so we we intend to model it and then another notebook on the floating escalator or the combination between 1559 and escalator so trying to understand a bit better like what it looks like i know that vs collector hasn't been like really talked about for some time and i feel the consensus is more like okay we should just go ahead with 1559 and not really bother with escalator but anyways i think it's still interesting in the in terms of like research even as it's an extension to this uh strategic behavior notebook so yeah that's under review and it should be published also fairly soon and the last one that i've been working on and that i think is quite nice so when the let's say strategic user tackles this idea that uh 1559 is just going to degenerate into like a first price auction the learning users i'm trying to tackle the idea that 1559 is a ux improvement so this is i think is not really understood really well by users or by whoever is looking at 1559 like what do we mean by ux improvement exactly and so what this learning agent notebook is trying to show is that over time agents learn to either bid either take the price that 1559 is giving them so basically the base fee or leave not not not even enter the queue and in that sense it's an it's a ux improvement because over time you're learning to just become like a price taker so the market is just coating you okay it's 100 way to get in now take it or leave it and that's it most of the time so and so you see over time with these learning users but after a while like they understand that okay i should i should probably just either take it or leave it and you can really see then like this idea of ux improvement dynamically let's say appearing just from the interactions of the user so i think it's quite quite interesting and then related to that um i think it's something i've discussed maybe in the discord channel but looking at wallet defaults so this idea that most of the time you're a price taker but sometimes the base fee is shifting very rapidly so you have like a uni swap launching their token or something and then you might not want to be a price taker anymore like then you might want to revert back to this strategic behavior which i look at in the first notebook and in that case probably you also want your wallet to kind of shift from this price taker or this price quarter mode to a mode where it gives you more flexibility to say no i really want this transaction to go in quickly so i'm willing to pay a much higher premium so when should that be like when should you switch from one mode to the other and what should the defaults be in the wallet so most likely defaults would look like what you currently have in metamask like free like fast medium slow something like this but uh how should we set these parameters so yeah that's that's kind of where i'm at at the moment yeah that's great um yeah that's a lot uh i had a couple questions um i guess the first one around like the the transition period um do you think are you like that still makes sense if we've like removed it from the eep with the with mika's recent pr ooh i should have specified that the transition period we're looking at is my casper so i'm not looking at the previous model of okay yeah yeah i'm looking at mikas where you cast the legacy transactions into the 1559 phone okay okay yeah okay okay yeah got it um cool um yeah anyone have thoughts comments questions okay um in that case yeah i guess uh i can share my screen real quick um so uh puja myself and a couple other folks from cat harders uh spent the past few weeks reaching out to a bunch of projects to get their thoughts uh on 1559 um so there was a lot of feedback we shared a report uh detailing most of it um i'm not sure most of it is relevant for this call but the bid around implementation really is uh and so i was curious to get people's thoughts about how we can address kind of uh how we could address the things that people mentioned would help them prioritize 1559 support so we asked projects you know what would make your life as easy as possible to support this um and obviously the first thing that came up or the thing that came up the most often was having a public test net um but especially having one that's uh suitable for for like end user applications to use so that has json rpc support for 1559 um and and it was also mentioned that it would be great if this was kind of standardized across clients uh so that uh there's not like any major differences between how a base suit and sorry go ahead yeah i would suggest something about that uh instead of implementing the rpc endpoints in each client i would suggest suggest that we implement only one microservice dedicated to that that will take a 1559 transaction parameters and we'll create and sign the transaction and submit them to uh ethereum client unless we think we will have it in production on mainnet but i'm not sure i think we can leverage that and avoid that every client team implement it so that would work for sending but would it also work for reading transactions because i think that was one of the other concerns that came out like just being able to query you know uh the transactions and and whatnot on the network yeah like how do you expose them right now in the block explorer basically oh yeah maybe we can update the front end actually and implement the decoding logic actually yeah so that will be easier actually to display uh e15 if 1559 transaction parameters directly in the explorer yeah but i guess what i'm wondering is how does the explorer get the data from basic right now like how does it query it oh uh i don't remember the exact end point but okay because there is such i feel like if there's something already in basu that uh at least you know the block explorer we have used maybe that's a good first starting point for something we can like standardize across clients and just make a bit more explicit so it might be worth looking into that okay yeah i will do that um so yeah just taking a quick note um yeah and then uh obviously the other thing people mentioned was like having it be part of a network upgrade i'm not sure we're quite there yet um and then this might be interesting to you uh barnaby but uh the incen like a couple projects mentioned like if there was any incentive uh with regards to gas prices specifically to use 1559 they they they would prioritize it i think mikas pr kind of gets us half of the way there at least right where if you can keep using legacy transactions you'll just pay a higher tip to the miners um so the i guess the converse of that is like if you use 15.59 you'll pay a lower lower price um yeah i know i think that's maybe sufficient to start but i'm curious if other people have thoughts about that do we understand from that that like the project is incentivized to implement 1559 so that it's users get to yes yeah okay yeah yeah yeah and and that was like i guess the common theme for the projects who were most willing to implement 1559 as soon as possible are projects who really cared about like their users gas price experience um so i think that yeah having having their end the end users of you know someone like argent or gitcoin be able to pay a lower gas price was a a good motivation for them okay yeah yeah that makes sense yeah not incentives to to pay them to employment no no no no no yeah it's like the net yeah the transaction isn't all right um yeah and the other thing so the other thing that uh was mentioned is like having obviously like the basic libraries so ethers.js and web3.js support this as soon as possible would help because a lot of projects basically just rely on that um so the ethers.js uh maintainer said it should be pretty easy for for him to add support for it um the other thing that was mentioned is yeah just having like a clear up code definition uh so a lot of projects smart contracts rely on transaction.gas price i think we need to understand what are the implications of changing that uh so right now from what i understand that the change that was made would only affect 1559 style transactions which shouldn't break anything that exists um but i don't know if there's some weird kind of i don't know second order effects for contract developers that the api changes what it returns based on the type of transaction um i don't know if anyone has thoughts on that i believe we're pretty safe on that front the way we ended up setting gas price for 150 1559 transactions makes it so it's basically still the same thing so it means this is the gas price that the user paid the one caveat is previously for legacy transactions the gas price a user paid and the gas price a miner received are the same and one five five nine the gas price a user paid and the gas price a miner received are different and so previously the gas price op code could have been used to identify how much a miner received for the transaction theoretically and also used to identify how much the user paid for the transaction with 150 1559 it only represents how much the user paid for the transaction now i i don't i don't know of any applications that care about how much the miner got paid they there are many that care about how much the user paid and so that's why i went with that is that worth adding to like the security consideration section of the eep i feel like the backwards compatibility section yes okay send me a message after this and i can go at it okay uh i'll write a note for that um yeah i feel like somebody might look at that and find some something with it but uh that makes sense and i guess the other thing we discussed in the past is like the base fee up code that's not part of the epa right it is not and and the there is a push no there's there's a push currently in the from the core devs for various reasons to actually get rid of gas inspectability in general from the evm and so that would probably hurt our chances of inclusion if we're adding things that make it so people can inspect gas stuff okay and i guess so right now the only way to get the opcode is to get the block header right yeah you could so you could prove it on chain so you could get the transaction proof and then uh prove it based on the block cache if you really wanted to but that can only be done afterwards so it'd have to be the next block that you could do that yeah and i think that kind of relates to the to the next point is people would like to see kind of an api that takes you know that tells you what the base fee will be for this block so you take the previous block you calculate how full it was and therefore you estimate what the next block space c will be um i'm not sure this falls like within the like skills of people in this group um but something like that the sort of eat gas station like api that just does that that map for them is something people mentioned that would make it easier for them to uh to add support for 15.59 i don't think that would be particularly difficult yeah yeah and and yeah they want that from the clients no no they want that just like a place they can go on the internet a place they can go on the internet and yeah this call is recorded and will be uploaded to youtube so maybe somebody picks this up eat gas station if you're listening um yeah that was that was brought up um and then yeah obviously the rest was kind of pretty standard but you know just having good documentation like we just mentioned i think around the you know the up codes and explaining what the changes and behaviors are uh communicating changes to the eep and and whatnot and having channels for support and i think with the discord there it's been kind of a decent place so far if if like the volume grows um we can maybe move this to some other place for for support specifically but uh yeah that was kind of the list of what what would help various projects kind of implement the eep one thing that was nice in this survey as well as there was like a pretty uh yeah there was like a pretty smooth distribution of like when projects would like start would want to start working on the eep so i feel like as this develops we'll probably get more and more users who are slowly kind of trickling in and are interested um so it's nice to just start with kind of a smaller batch of people who are like very interested in this and want to see it done asap and then slowly reach out to more projects um yeah so that's basically what i had on that and then the last thing i wanted to to bring you up was just this kind of midnight readiness checklist so i think a lot of people in the community had been asking for a date for 1559 because that's obviously impossible to give to people uh the other approach is to to give them a list of things to do um and and and try to obviously update it as as we learn new information and and we make progress on it um so in short obviously we need all clients to have an implementation uh right now geth base you and nethermind are working on it nethermine i believe is still hiring someone uh as well to do this so if you're watching this and you're interested uh you can you can click the link and uh and uh apply for the job um open ethereum uh and and turboget are fine with joining the implementation later i've talked with with them and um i think you know they don't have as much interest in implementing every incremental version of the eep but uh once it's actually done and settled uh it shouldn't be a major challenge for them to implement it especially with the the recent changes to the transaction pool and whatnot that makes it a bit uh a bit simpler for clients to implement in terms of like the open issues uh i think the biggest one uh we discussed this on the last awkward devs but is the denial of service risk on mainnet um this is something i don't think eip1559 can address head-on and there's a couple efforts that are being done to address this so there's eip 2929 uh geth is working on snapshot sync bayesiu is working on a another flat database uh approach uh that that that makes these uh denial service attacks uh less likely uh turboget from the start is optimized to to deal with that as well um and so i don't think again 1559 can like directly address that when i asked about changing the block slack limit uh people didn't seem to think that would make big enough of a difference so going from you know 1.5 to x instead of 2x didn't seem like it it would uh it would make 1559 much more likely to be adopted sooner uh but it's really more about uh having like client level uh basically databases that store the state uh in a flat format instead of a try and everything that goes around that um i don't think it should have a major impact in terms of timelines if given that there's still work left on 1559 that it won't be in the berlin upgrade it you know i think it should probably land in the upgrade after that um and that also gives time to clients to work on that uh and then the next up the transaction pool management this is basically moot uh due to mikas pr so i'll update that um the transaction encoding decoding was the other big question uh and and i know abdel you've mentioned in the past that eip 2718 would make this easier um i'm not sure what actually is the status on 2718 it's it seems like it's kind of in limbo for berlin i don't know if anyone has kind of a better view on it than me it's uh in limbo for berlin i almost certainly will go in with or prior to one five five nine that i don't see really any reasonable path where it doesn't go in there's enough things depending on it that it's going to go in either berlin or immediately after okay and does it make sense to i guess keep doing what we're doing for now and once it's accepted we adapt 1559 to to support it uh i i don't think so i if it were me i would just switch everything over to 27.18 so we don't have to deal with it later like i think the odds of 2718 not going in are so low that we should just move forward with it personally but i'm not an imp motor so we could do something like if if we don't want to delay security audits and all that stuff validation of the economic model we can deploy public test net with actual implementation because the type transaction envelope will don't change any of those results and on the integration integration test net we could start implementing it maybe we can do this we'll have like two versions of it once yeah so once we have like a more public test net then we get to that yeah i think yeah maybe that makes sense and it also gives us a couple weeks to see what happens on the court f side um and if it gets accepted in the next corners call which is next week i believe then it'll be a bit clearer where things are at um okay and then the last thing was the transition period this is also kind of i guess your pr mika means that there's no more transaction period at all correct it's just we convert legacy transactions to 1559 and we allow that forever or we interpret them sorry as 1569 and we allow that forever yeah where forever means tbd yeah yeah yeah we have no no no currently built mechanism for getting rid of them at least not in 1559 but some future eip probably will maybe yeah yeah yeah cool that makes sense um uh yeah i think there is another thing that came out from the discord channel uh replaced by by fear oh yeah i don't know if we want to talk about that now so i thought uh yeah i think nika has some ideas about how to deal with that adding some transaction parameters can you explain that quickly so there's a few options the i i think i lost track so barnaby may no more but the one i think the first question is we need to establish exactly what everybody expects from the replace by fee protection so if you just do do replace by fee naively and you just say hey as long as he's hired then you can replace it you can replace a transaction with one attach so one one way gas price increase and it's effectively a no op but it will force the whole network to propagate your transaction again such as that nano service attack vector where you can just bump the transaction by insignificant amounts forever and just keep hammering the network and the network will continue to accept your transactions so we want to avoid that the problem is that with 159 if you bump just the minor bribe there's no guarantee that the minor br the whole vine right be taken because you could be hitting the fee cap and in fact it is most likely that if your transaction is pending for more than a block you are blocked by the you're blocked by the fee cap not by your minor bribe and so if you're just about me the binder bribe then we end up with the same situation where someone can just keep up my minor bribe and not actually change their transaction at all they're not paying anymore and so there's some concerns about denial service attack vector the if you just bump the fee cap similarly if your transaction is not pending because you're blocked then that also does nothing like you're you pay the base fee and if the base fee is below your fee cap you can bump that to 40 million and you're still going to pay the base fee yeah so bumping that doesn't actually change anything so the the last option is well what if we bump both and bumping both i think does work in most scenarios i think there's some edge very edgy cases where it's possible to not have your actual fee change when you bump both but arguably we don't care that much about those edge cases because they're not really strong attached service vectors and as long as we have a minimum increase then it also doesn't matter too much the last option is to just say that nodes will not propagate any transaction whose base fee is sorry whose fee cap maybe fee capitalist minor bribe not sure which probably just we get is less than the current base fee this is a novel idea that we think we probably need to spend a little more time thinking about but the in theory if we did this then all transactions that were being propagated should be able to be included in a block almost immediately like the only reason they can't be included in a block is potentially because they're minor bribes too low um what this what this does tell us though that we also need to talk about is if the minor bribe is zero let's say we currently don't have a mechanism for pushing that out of the pending pool like uh like it is possible to set a minor bribe that is below a binder bribe that every binder is accepting but have a fee cap that is higher than the base fee fee cap should that transaction be allowed to propagate and if so how do we define what the minimum minor bribe is to for a transaction to propagate do we do it like we do currently where we just say every every node in the network has a propagation variable where they say that we are willing to propagate any transaction that has a minor drive this or higher um that's my simplest solution and we just hope those are generally set in line with miners these are all things to think about and discuss i'm currently favoring that last option where we say the nodes will not propagate any transaction that it has a base fee lower than the current blocks based paper sorry the fee capital and the current box base fee plus minor bribe set per node at startup so each node define what their minimizer drive is and that's they'll propagate everything else so we don't propagate those transactions on the p2p layer but we we do accept them on the rpc endpoint if the price is below base fee yeah that would be my assumption so that way your local node will always accept your transactions from you oh you're talking directly to your own node it's going to accept everything just like just like it does right now i believe okay it's not the case in bazel implementation so uh i reject this transaction but yeah i will update the implementation okay so i think i believe the other clients at least open ethereum and geth and i'm pretty sure another mine if you're talking directly with rpc it will accept anything because it treats you as kind of a privileged user when it comes to what it accepts and so it will accept it and i think they all actually have a separate pending pool sort of where transactions are protected from being ejected from the bending pool on that node if the node received it over rpc yeah there are some rules there is a minimum gas price and also a minimum bump uh percentage but yeah if the transaction comply with those rules it will be accepted yeah and this is what we do for legacy transaction but we implemented the uh different behavior for the 1559 transaction but uh okay i see what you mean so like i said that's that's my current preference is that we go with the we basically just don't propagate anything that's got a minor bribe that nobody thinks is too low or a base a fee cap that nothing's too low and then we can basically i think we can allow basically almost any strategy for fee bumping um for replace by fee because the things that are being propagated are all things that should really probably be my next block like it is very likely that the thing that's being propagated is going to be mine very soon because the base fee is high enough and the minor bribe is high enough okay that makes sense thank you do other people have thoughts on strategies there wait you could still increase your fee gap in definitely even if it's above a base fee right like i agree that with this idea that you drop transactions where fee cap is lower than base fee but how does that prevent how does that alone prevent me sending a thousand transactions with just a little bump in the fee cap every time like you still need the bribe and yeah so so i think we still do need a minimum percentage just like we have currently on the network which is i think twelve point five percent for guess open ethereum i think um but i think it matters less whether that's a fee cap bump or a base fee bump maybe or both sorry bro bribe bribe bump or fee cap bump or both of them like if we're kicking out transactions that aren't likely to be mined soon and we have something that the user has to keep increasing i guess that does happy minor bribe doesn't it because if it's base feed then they can spam yeah i think you still need yeah okay it's fine to have like the base fee greater lower than your pickup that i think used in some kind of bump uh yeah so yeah so the miner okay so the minor bribe has to be bumped by some percentage say we can keep it the same 12.5 percent if it's easy and then the fee cap can stay the same but if the cap of a transaction is lower than the last blocks base fee then don't propagate it over the network that sounds good yeah [Music] so i suspect as soon as we tell this to the ethereum client developers they're going to tell us that they're going to grumble about the dev p2p layer currently doesn't isn't synced with blocks for lack of better term like they because of rollbacks and whatnot the devtoo plea layer doesn't really know what the current state of the network is and so client implementers historically have been very pretty loads to create a dependency there where the p2p layer needs to understand what the state of network is because you can get out of sync like two two clients can not agree on the current data network so client a will say hey i've got a new transaction it's got a base fee that matches or is higher than sorry it's got a fee cap that is higher than the base fee you know you're sending it to however sees a different view of the network and so they say no it doesn't you're lying to me and you're now a bad peer and so we have the problem now where how do we tell whether appear is bad or appear is just on have a different view of the network and so i think for that reason historically p2p layer has not it's correlated with blocks at all like they they they try really hard to not care about what the current state of network is yeah yeah that feels like it would make things much more complicated if we needed to add a dependent like if we needed to change kind of the statefulness of the devp protocol but i mean there are higher layers you you can do that in the transaction pool or something like that you can flag the transaction as not eligible for inclusion in the peer-to-peer network and you yeah i i think it's manageable okay yeah i think yeah i don't know get enough but yeah yeah i i guess yeah what i'm saying is i would push for the similarly to how mika you mentioned you know like the adding the base fee up code kind of goes against the the current of uh the the core devs uh with regards to gas observability i would try to to keep things somewhat like philosophically compatible with devp2p um but if we can if we can do that verification just at the client level before we propagate it i think that makes sense i think it works as long as as long as we don't it's not a condition for flagging a appear as bad like i believe the clients all have mechanisms for flagging peers as bad peers and eventually disconnect from them we would need to make this a condition where you say thank you for the transaction i still trust you but i reject your transaction and i don't know if we have that concept at the moment anywhere else like it's usually either either you receive something that is very valid and you can assert this is good thank you or your resistance is bad in which case you say you're a liar and i'm kicking you off of the network or i'm disconnecting from you i don't know if someone the client does might know better i don't i don't know if we have anything that's kind of like wishy-washy like that you know this is bad that we don't have gay people on the call we should have some next time yeah we can follow up uh offline uh with with them and and with other client devs to see what they think but clearly the whole i guess replaced by fee is kind of a big open question we still need to figure out okay okay i i want to point out as well that either way it's going to be there's going to be some amount of complexity like even if you don't want to do the statefulness handle when you manage your transaction queue and when you want to check like if you don't have a rule for instance that says refuse any transaction where the fee cap is not high enough uh you still need to look at your transaction queue and update the order based on where the base fee is and how that might change the actual tip that you receive as a miner so at some point in time i think you do need to take into account the fact that base fee is moving and that the transactions the validity is depending on that as well but we can do that at the client level right like we don't need to do that over that pdp and also you can manage the delta between uh because you know that the biasing can go up or down up to one on eight so you can have an idea about how many blocks it would take to in best case uh catch up with the transaction price and you can evict uh or reject transactions that are really far from the basie yeah i guess you can have like many different strategies as a client yeah yeah but so the fp2p is not considered part of the client i understand yeah yeah okay okay yeah that's what i was thanks so it is part of the client but it's a different spec it's it's not uh it's a yeah a different protocol yeah yeah whereas they yeah and whereas the transaction pools is kind of left to there's no rules about what clients have to do with it each client can do whatever they want and they don't need to agree with each other about how they handle it even though even though like you know in practice most of the behavior ends up being the same at least we don't have to write a spec for it that says this is how the transaction pool works uh so so this is what makes it easier to do it there than in devp okay yeah [Music] okay cool so i'll add that and try to summarize uh this conversation here in the open issues um other couple things uh that were just on the list of the testing in general i think we haven't spent much time on i know abdel you mentioned like uh we we should maybe start thinking about like reference tests and whatnot uh i'm not sure if the eep is like stable enough for that yet or um yeah what are your thoughts on that i think the for example the basic computation is stable enough to start some kind of reference test because otherwise each client team will implement yeah we will not leverage the work and that would be good to have this kind of test to ensure that and it will also help other teams when they will want to implement the spec let's say when turbo get and open their open it around on to implement the hip that will help them also so yeah yeah i think we can yeah we can probably start slowly writing you know adding some um and uh yeah like you mentioned i think on the parts that are that are a bit more finalized um okay um and then yeah so we kind of discussed this already so with the community testing um basically the json rpc abdel you said uh in the chat i think that uh right now the block explorer is using get transaction by hash so that already supports 15.59 no so how sorry so i guess i don't understand how does the block explorer get the transaction information uh currently uh the block explorer only display the legacy uh oh okay so for example you have a zero gas price for each okay so yeah we need to update this endpoint to add the minor bribe and probably even the basic that will be so the basic is in the black header though right yeah yeah but we have the block hash as the response of this uh endpoint so we can query to retrieve the block header and i think there what would probably be best is to just come up with a spec that both we vulcanize and nethermine agree on before we implement it because again that came up like i know with a lot of like the tracing apis and whatnot clients have very different behaviors um and and as part of the 1559 conversations that came up like it would be great if the behavior here was pretty was the same um so i think it yeah it might make sense to just see if if if no one has like super strong divergent opinions we should just come up with a spec and so currently for legacy transaction we exactly have the same output so yeah we can okay so the same for the two new parameters just aligned on the names and we can just take the names from the spec that will be the best okay cool um so just just wait for that the idea is get transactions by hash will still work as normal it's just it will also include uh 1559 transactions and they will have a couple of different fields exactly yeah right yeah yeah yeah and yeah i guess yeah let's just ask other clients before we commit to that but that seems reasonable to me and would that also uh east block with the true flag for full block so the one that returns all transactions i think it's get blocked by hash i believe this is the one but that also do it yes okay i believe there's only two that return transactions is that correct uh yeah i believe so yeah on this one okay do we have plans at the moment to introduce or support 1559 transactions for each send transaction so this is what i talked about earlier so my my opinion on that if this is only for test net i would suggest that we implement a common service for that and we just deploy it in the same infrastructure as the testnet so that client client implementer not client but wallet providers and people can start playing with that without waiting for metamask or web3gs to add the new field uh and for yeah i guess if you want to use that on mainnet uh you will have to implement a new endpoint to submit a few 59 transaction unless you use an external signer but yeah would it make sense to have ethan transaction just support either yeah five five nine or like six yeah you make something optional and yeah yeah yeah it would probably be good tim to have make sure someone's tasked to actually writing the specs for those three that'll be three new eps oh you so the change yeah the changes to the json rpc have to be separate eips yeah well they should i mean yeah don't have anything of course but yeah i ideally yes they would be there'd be an aip for each of them that specifies the changes that are being made to the json rpc and then from there clients can implement it and while it's providers can implement it and then imagine when it cures i thought they were um out of scope the eips no there are some oh okay they are not car yeah it is okay okay yeah okay yeah they're not quarrel they'd be interfacing yeah okay okay yeah okay so and so we basically need one eip per json rpc call right yeah and i think there's i believe there's three of them that we need get transaction by hash yeah get blocked by hash and send transaction there might maybe get blocked by number as well yeah because you want to add the basis as well yeah get blocked by hash and get blocked by number as well because you you need to add the base you head there for the 1559 blocks yeah and how about each send raw transaction does that have to change as well no that's i don't know because you're not just sending a byte array it's already signed okay yeah input don't put out the same ignore it yeah okay exactly so there's four of them and we needed e for each of those um ideally yeah okay people in the past have done one monolithic one as an editor i recommend separates they will go through smoother okay um so unless somebody on the call right now wants to commit to it i can follow up on that um i guess yeah i'm just a bit uh cautious of because abdel is a person and he is here uh to throw it on him uh but i can yeah i mean i can take some yeah as it will be the occasion to start my first uh eip so yeah okay i mean sure if you want to do it yeah that okay great sold um so abdel uh we'll have you write those eips okay nice cool um okay so yeah i think this covers jason rpc a public test net we already kind of i i think is dependent on having this json rpc a bit more fleshed out um and the the other bit i guess in terms of testnet is i'm curious right now we have the poa network um it seems like there's some small changes that make to the spec uh before you know everybody's kind of all syncing and happy there is it worth starting to discuss a proof of work network now or do we still need like a couple weeks before that because uh of the changes and and of uh uh i know get is still having like the consensus issue on on the poi network i think it's another mind already done yeah i think nethermine and us are thinking maybe like with some recent changes to the eep there's some small tweaks to do but i suspect like in the next week yeah that the mind at least should be should be on the same network and up and running um i don't know if nethermine supports mining um not yet at all or 1559 mining no not 1559. okay okay so i think that's something we probably want uh at least like yeah having more than one client support mining before we launch a proof of work does not so we can actually try to mine blocks in two different clients and make sure that they all come out the same and work yeah and in parallel maybe we can start uh because we were thinking also about uh launching a single client testnet so that could be a single client proof of our test test net then and that will be the candidate to add other clients next for example the one to validate the economic model and do you think we could do that with baesu already is there anything we need to change would basically do that no that should be fine yeah we could do that okay so maybe it makes sense yeah to just start off as small base super work test net to make sure at least everything works and we can produce blocks and we can run your transaction generation script on it yeah and and in the meantime you know we'll see over the next couple weeks how other clients uh you know get gets ready and and what the extent of their their mining support is um cool and then uh yeah just worth uh mentioning i guess uh nethermine was using uh 1559 as part as i believe like a private network or a network they're working on with one of their clients um so i think they might have some data to share on that in the next few weeks or months um and then falcon and cetlo both have 1559 the falcon devs have joined uh our slack or discord story um so yeah if people have questions for them about how the network has gone uh they're there and they can they can answer those um and i guess yeah in terms of r d the biggest thing that also came out in the survey with the community is kind of the lack of a proper uh not like even economic analysis of the eep but kind of just like a proper description of the mechanism um that people there's a lot of people's concerns when they were opposed to the eep was there's not even like a something to uh to critique right there's just like this eep which specifies the behavior but it doesn't kind of express the intuition behind it and whatnot i'm not sure who could help with that but to me that feels like something that would be valuable having you sort of um i'm not i don't have background in economics so i don't know how this stuff is usually done this sort of like econ spec version of the eep that kind of explains why this will actually be better i know that tim rovgarden is working on a comparison of 1559 versus our current model so i'm not sure how much of it will be covered by that but i don't know if anyone here has thoughts about how that can be done or like yeah ways just those concerns about not having something that specifies the economic properties of the mechanisms that that can be shared broadly um yeah i mean i can say that first like the paper where vitalik introduces 1559 has some motivation some modeling and i think it's been a bit overlooked by people who say there's been no economic analysis that's where it comes from first then vip was written which arguably has less let's say economic or at least microeconomic like motivation for it um and then team rav garden i think is yeah his angle is really much to say well what do we bring like by having eip 1559 like how does it change why is it better than the current model that we have and and how do we even quantify what better means right so yeah i do expect that his report will be very enlightening in terms of framing it but okay as i said before in the discord i don't expect it will be like a yes we should do it or no we shouldn't it's really more like what is even like the correct way to think about this like what are the metrics we care about uh what do we mean when we say it's a ux improvement yeah yeah and i think that's good actually i i don't think people are looking for like a justification as much as a description and and and i think it's probably easiest to describe by contrasting with what we have today um do you have a link to the vitalex paper if you can send it in the chat i'll add it to that list there yeah cool and then the last bit uh i guess barnaby i can link some of your notebooks here but in terms of simulations you mentioned you obviously kind of all the stuff you're working on right now um is there anything you still think like is missing after that is there like other big areas you'd want us to have simulations on that uh yeah you think we haven't um we haven't addressed yet or have had the bandwidth to start working on uh right so i mean there's a few things i discussed at the very beginning of the call which is more what i'm working on so one big chunk that i left out but almost let's say by design is this idea of minor collusion yeah uh it's something that we do plan to literally simulate or at least try to get like a broad understanding of what the behavior is the reason i'm not focusing on this at the moment is because i do think the analysis by team will be at least useful like starting points okay not i mean it's it's kind of trivial to define something where it fails or it succeeds automatically but but i think it's not going to bring much to the discussion so yeah um apart from that yeah i think i should probably help you fill that tba because it looks like there's nothing but yeah yeah i can send you some something okay that's right yeah and i'll add i'll add all the stuff you mentioned at the beginning of the call as well um so uh we'll have at least some some meat there and then the last bit was the community outreach this is still out of date we published a report yesterday um one of the big things uh that we mentioned in the report is there was a very small number of exchanges and wallets that answered so i think if we do more outreach i'd personally like to focus on those two groups um yeah so to just you know get more wallets perspectives i i feel like exchanges are probably less affected by this and they tend to be pretty uh reluctant to share data publicly so i'm i'm not sure how realistic that goal is but i think on the wallet side we can definitely reach out to a few more folks and and get their perspective on it um so we'll keep on doing that and the cathodeers will probably have an updated version of the report i i don't want to give a date but like in you know a few weeks to a month or something um yeah once we've once we've talked to a bit more people on that end um and that's all i had on the agenda i don't know is there anything else people feel we should discuss okay well in that case yeah thanks a lot everybody uh this was really good um and we'll have full notes for the report and all for the meeting and i'll share a summary on twitter in the next hour or so thank you guys awesome thanks everybody you