EIP 1559 Implementers' Call #4

oh and james just walked in great um also good morning evening depending where you are uh this is implementers call number four for eip 1559. uh there's a couple things we had on the agenda to cover today first up was just a status update from uh the different implementing and research teams uh then i think the the biggest part uh of of i guess me for the beginning was uh just trying to figure out what are the next steps and uh to get this eventually deployed on main net what do we see as kind of the uh intermediate milestones to get there there was also a discussion of eip2718 which is the type transaction um and finally something that came up on twitter uh around just uh is there ways we can speed up development uh by adding additional resources if people have thoughts comments on that we can kind of finish up with those um so first up let's start with the updates uh yeah i don't know if anyone wants to jump in first otherwise i can call on people i can go first i don't have uh much to update really great um so this is ian from vulcanize working on the go ethereum implementation um so i guess at this point my role is sort of just to keep the implementation up to date with the spec as and if it changes um and then also to you know make any fixes or changes that need to be incorporated based on the results of the test net that the pesso team is running and so there have been some pretty minor uh bug fixes in in those regards but uh aside from that there haven't been any major updates from from my side uh i can go next uh abdel from consensus working on bazel implementation so pretty same as jan said we are still aligned with the latest specifications we did some bug fixes and we restarted the test net including three get nodes and three bezel nodes so we tried to do some performance tests were sending a high throughput of transactions and we found some issues and they are now fixed and yeah that's pretty much it and uh yeah last thing uh we think that there might be an issue on the spec regarding the base fee uh and we believe we should maybe try to define the minimum value otherwise it can be a problem and if we let it go to one or even zero way it can be problematic and it can maybe never go up again so we can discuss about that later that's it yeah let's definitely come back to that uh just i see barnabas also on the call uh do you have an update hi hello um not too much just keep working on the simulations a new notebook soon on strategic users so trying to investigate what happens when you have a sudden spike in demand and users are trying to outbuild each other so trying to add more things to the library to handle this case and that's it and giving a shout out to fred who's also joining the effort maybe i don't know if you want to introduce yourself fred hey i'm fred and i'm going to be helping out a bit with the agent-based model and implementing a bit of the other behaviors i worked a bit with this but in a first price auction and now adapting a bit of my work towards the ip159 nice um great and i see uh thomas and alexa you're also on the car are there any updates from either turbo get or or or nettermind not for me sorry yeah i just it's time i came to the call it's um just to see what's going on because it's um there has been a lot of i suppose misunderstandings um in the you know twitter specifically and so i just wanted to get the just wanted to see if anybody would come here to talk about this okay yeah that was kind of the last bullet on the agenda so hopefully we can we can get to that um thomas and the updates on your end um yeah sure so i was spending time on the research science so like analyzing testing different numbers uh making mistakes and finding some insight and i think that maybe within next two weeks maybe three will have another mind connecting to this uh ideally connecting to this bezier gets uh testnet for eip1559 so catching up with everything um yeah it seems it seems very reasonable prediction [Music] cool um did i forget anyone did anyone else have an update they wanted to share um maybe we should do an update on the funding group uh sure i mean yeah do you want to go ahead james uh yes so we did the bitcoin grant funding round and had a lot of participation which was awesome the funds so far have gone to funding ian's work on maintaining the geth project the rest of the participants have come from the effort oh you we missed the last bit of what you said james oh that the other participants have been funded through efr consensus i got like you and i and barnaby and uh abdul yep is there any sound like information about the how how this some transparency behind how these funds are allocated so for the git coin grant uh we basically the the so it's a public multi-seg right anybody can use it we made it clear we wanted this to pay for research and development of the eep and not go to people employed by the ef or consensus uh that was kind of the high level uh transparency in terms of like the specific transactions i think so far uh the only one has gone to vulcanized um does that make sense yeah thanks the um there was one interesting thing that i've seen someone posting about um some some blockchain like ethereum research foundation or something like this posting information about funding the analysis mathematical and game theoretical analysis of eip1559 with some mathematician from i believe yes uh yes so it's tim ruff garden is the is the uh researcher he's not on the call today um and so this was kind of a single individual who themselves funded kind of this research effort um uh through i think what's called the decentralization foundation uh and basically tim is is uh his background is in uh computer science and game theory and so he's gonna work on on doing a formal analysis of 1559 and and basically comparing it to the current fee model on ethereum today um and uh and hopefully hopefully highlighting you know some potential improvements uh or some some some issues with the eep yeah this is very exciting i've seen it i mean it looks amazing uh didn't does he will he work with barnaby together because i think this uh this work is somehow um maybe like they would probably help each other because on one side we have this mathematical analysis on the other side we have this more of the analysis that is running in the simulations [Music] yeah i don't know yet uh we've been talking in the initial stage uh we've had a chat with team baco and team rovergarden um i mean i'm i try to stay in touch and i think it's very complimentary i know that he's also planning to publish some open source code so i don't know uh how much he will go into the simulations but i i want to maintain the line with him great sorry probably just outside of agenda i'm not talking no no worries yeah yeah and it's worth mentioning like it is a big a big kind of stream of work um good updates yeah um so i think it might be worth just like going back to the the issue uh abdel was mentioning with the base fee on the test net uh just to give kind of more right on that uh yeah adele you want to share more details on this uh i was not there jan can you share more details about that because i if i remember correctly you you work on that yeah um so essentially if the base fee currently the current mechanism if it ever gets down to zero it can never go back above zero um that's the hard cut off there's also a bit of an issue at other low numbers above zero for example at one um the gas usage needs to be nine times higher than the gas limit which increase up to two um from two to three it needs to be five times higher and so so forth there's some sort of function that i haven't actually figured out that's that describes this behavior right that sounds about correct um should we define a safe minimum value then again i think the thing that we did on the e2 implementation of one five five nine is to just set the minimum value to be twice the either equal to the quotient or twice the quotient and i guess twice the question might be a bit safer [Music] because at like i guess at like one where it needs to be nine times higher just because there's not enough block space right that means it's kind of impossible the other alternative to setting a minimum is is um setting it so that the minimum change is a one in either direction so like if it's smaller than the target it always goes down by at least one if it's higher than the target it always goes up by at least one i like that idea more um but just kind of intuitively and so that means in the worst case you kind of go from one to two to three and it takes you a couple blocks until it starts actually going up uh it'll take you i guess a bit less than 10 blocks because then you'll be back to the 12.5 percent right right exactly well it'll take you an extra you know eight blocks but then like going up from my eight to a billion or whatever it is is going to take something like a hundred bucks anyway so i think even longer like 200 bucks uh mika has a question how many blocks between one nano ether and zero assuming 100 empty blocks um so going between one gray and eight way um so that's a factor of 125 million and one over eight um i think that would be about five and a half steps to do a factor of two and then 125 million is about the 27 so 27 multiplied by five and a half 148 vlogs that sound right i'm sure give or take yeah yeah so does anyone disagree with the idea of having like a minimum increment of one that sounds reasonable okay cool so let's uh make an action item to change the spec and the implementations to have a minimum increment or decrement of one and uh was that kind of the only outstanding issue on the test net i know there was like a transaction pool issue as well when we tried to put in a bunch of of transaction um did that get resolved no i i don't think it has oh maybe current can speak to that a bit more there is a branch that i pushed up today that hopefully fixes that issue and okay it's likely just due to uh a bug that i introduced on the last update we will try with this branch and see if the issue is still there okay cool um and those were kind of the two big issues right obviously that we found so far yes yes okay um i think this kind of leads nicely into the next like agenda item which was how do we you know what are like the intermittent steps to get this eventually on mainnet like right now we have this one kind of small private test net which it has i think like six nodes on it it's been really useful to find all these kind of corner cases and small bugs uh but assuming that like you know in the next week or two the spec gets a bit more stable nether mine is going to be ready to join as well um would would the next step be kind of a more public test net um and if so what what do we want to get out of that yeah i mean the on the public testing side it's so that people can begin to experiment on the wallet side is is that something that we want to get out of it or is it more like technical vetting and hoping for more randomness due to user activity i would say the the second uh at least my perspective yeah um cool i mean that that's reasonable i i think that have spinning up and it's gonna be hard to get people to just show up and send transactions that are like semi-meaningful if it's not an existing test map um but someone will probably will yeah and i believe there was a miner on the chat who said they would be willing to supply hash power if it was a proof-of-work test net uh because right now the test net we're running between bayesian geth is a clique test net um so i think also testing the proof of work is a is a important part of this um if you're looking for block variants you can just simulate that with the distribution as well and not have to wait for my name but just as if there was mining yeah that's good i i'm personally concerned that we just test the right code paths so maybe we don't need competitive mining but we we do want to test the actual code paths that would be used in production and you by codepath i guess to be clear referring to the the proof of work the mining ones right yeah okay um and i think because yeah i think that'll if you get like a small proof of work test that you're kind of uh proving correctness uh you know that the e forks is intended which were you know in the process of doing on a non-proof of work one um and i think the step after that is then uh trying to go with a a test net that has a larger existing state uh and seeing you know this performance degrade on that because rick the last time you brought this up on aqua devs i think that was the biggest uh piece of feedback that you got but like it wasn't clear that clients could process these large blocks um especially with like uh state access so i feel like that would kind of be step three so like step one is what we have now step two is having maybe an empty proof of work test net and step three is maybe going to fork something like a rob robsten where uh where we can then get like an existing state and maybe get some tooling uh get some tooling to adapt to the eep does that seem like reasonable to people um can i just ask a good question because i i'm i am i excuse my please excuse my ignorance but did uh does the current implementation imply that the two transaction types will you will coexist or is it is the change to switch to the the new transaction type the 2718 transaction type uh yeah i mean i suppose that um is um when the eip is implemented will all transactions have to have a new format or there will be possibility to to for old type transaction to be sent as well there will be a transition period where both transactions are accepted okay okay seriously yeah during uh a certain number of blocks eight hundred thousand blocks and uh the gas pool available for legacy transactions will decrease uh on each person yeah okay and that's it yeah and one thing that's nice a certain i was just gonna say one thing that's nice about that that took me a while to understand is because you have the 2x block size you know even when it's 50 50 you'll still be able to deploy a contract that would say take up a full block today because you'll just fill half the block uh with like your legacy transaction or your 1559 transaction so we're also even though you split kind of the available block space in half between the types of transactions you're not actually decreasing the uh the max block size that someone can use and so based on your experience with the so far where is the kind of biggest complexity in terms of the code lies in which part of the code personally i would say maybe the handling of different rlp encoding decodings based on the transaction because we don't have the type transaction envelope but if we make it a requirement for this if i think it will become easier but yeah to me it is the pain point of this implementation is about uh encoding decoding of different types of transactions i'm also a big proponent for two seven one eight but uh for the guest implementation i'd say the most complicated area is the mempool uh the transaction pool more accurately are are the rules of the transaction pool very different for this ap than for the existing transactions no not really actually you're just comparing the gas prices between the two types of transactions but the gas prices derived from the base fee and fee cap or gas premium in the case of the eip1559 transaction so it's it's just a different process of arriving at that value yeah the reason i'm asking this question yes sorry going you're good is the complexity in the transaction mempool because you then have two transaction mempools with different logic or just because it's altered in new logic the latter it's actually a single mempool right now um ordering them all based on the gas price and we do need to update uh the implementation to um to to rebase on top of 1.919 which adds the deterministic ordering when two transactions have the same gas price okay so the reason i was asking this question is because my suspicion was that the most complexity would be in the implementation of the transaction pool and therefore when you're previously asked the question like what would be the you know what needs to happen for this to go into the main net i think one of the main things to basically um preempt any possible questions or problems that would arise uh with the um with this particular implementation for example you know is this a code resilient towards any kind of dos attacks and then tick that box yes it is because of such and such and such you know like could we do any stress testing on this and such and such so basically yeah so i think that would help a lot because then you go into the the uh let's say go ethereum developers and you'll say these are the things that we're preempting or the most of the questions you're going to be asking um yeah that makes sense and i think um you know if we roll two seven one eight of which we may be getting ahead of ourselves because i think that's the next item on the agenda um if we decide to implement that first that kind of introduces some uncertainty into the you know unlimited uncertainty into the mempool and that there's no real clear defined way to order transactions between all these arbitrary types interesting so it's like on one hand 27 18 helps with the rlp encoding stuff and makes the trend transactions easier to manage but then uh yeah if it makes a transaction pool which is the other most complicated bit more complicated it's not clear it's a like net win um but we can say that uh maybe the transaction pool is a bigger problem than the european union we can deal with that this is not clean uh but yeah we can deal with that yeah i just think it's a little underspecified uh where it's at right now for what we're trying to do so i think that the spec needs to be cleaned up a little bit in order for us or completed frankly in order for us to really start talking about how it would impact the work that we're doing uh to georgios's point as well yeah there's a couple comments in the chat i'll just uh i'll just read them uh so people not on the zoom call can see but uh georgia says that uh 2718 seems to generalize uh do we really want do we really want oh is it important to bundle this with 1559 you could add an optional version field if present and set it to v2 and decode it as 1559 transaction otherwise it defaults to the current format and mika says 1559 is one of the transaction types that you want uh and there's a question about whether we need a generalized versioning scheme for transaction um and 2017 27 18 isn't just 1559 transaction there's a other a bunch of other transaction types that people are proposing um so given i guess yeah that's like the the transaction pool is kind of the most complicated bit on the get side so far um does it make sense to try and maybe just like specify that somewhere else in the code so that uh i don't know if the eep is the right place for it but uh just so like like i said we can kind of proactively address some of the objections around it but transaction ordering is not a consensus thing so yeah i know but at least just saying this is how we did it and kind of explaining that not as not as like it's something people have to conform just as something people can kind of critique and and uh it should be added to security considerations in the eip yeah that's a good point so yeah maybe just adding something about the transaction pool ordering in the security consideration section and why why like you know the potential issues can be mitigated and although as part of the specification it in in this strict eip sense it isn't as important in the in the inclusion in a hard fork it's really important for that discussion uh that might happen more as those kind of processes are separating in a different place i'm hoping my audio is better than it was it is okay good so i i think it's i'm just start thinking of it as from not just the eip specification but the how do we get this through the hard proposal and another in another comment i wanted to make about this transition period um i you know there is some kind of number was it 800 sort of blocks or something or eight thousand books eight hundred eight hundred thousand eight hundred thousand blocks okay and so where does this number come from uh where is it come coming from four months time for ballots to adapt and change is that it is that you know well this is this is the this is it actually is this going to be okay but or would we need to have another emergency hard fork to postpone this because that's how i think it's going to happen yeah so i think that i mean alexi you bring up a very salient point um yeah i think that we need to be prepared for a series multiple hard forks uh based on what happens when we don't see uh you know a sufficient transition from wallet providers exchanges and what have you and consequently um we don't see the the shift in transaction volume uh i think that's to me that is one of the biggest to me that's the biggest risk because we can all as engineers or you know have these conversations about these engineering problems but we don't have any you know we can find a path to engineering problems what do we do if if like you know omisego just doesn't change their transaction type and they have tether you know i think that's a pretty big issue so originally when i remember in when we met in 2019 i think was it when we discussed this um in the in berlin so i suggested the the the basically the dual transaction types and one of the reasons i did that is because we could monitor the um the uptake of the second transaction type and based on this information to inform when the transition period needs to end because what we really want to see is that the the number of the new type transaction increasing the number of old type transactions decreasing and then when it gets to a certain threshold we just say okay fine now we're going to make that mandatory um i don't know it said do you think it's sensible or some some maybe some fundamental issue that uh makes it a bad idea i i think psycho there's a psychological component i think that there needs to be a hard number and a legitimate threat to motivate people you have to have a carrot and a stick frankly so way back when uh this the stick was were going to hard fork and the carrot was uh lower gas costs and the in the new transaction type um over time that lower gas cost narrative uh you know people didn't like that idea which is fine with me and so this is we're still trying to figure that out but this but this is actually quite interesting point is that let's say that if we had two uh transaction pools i mean basically two spaces inside the block one space dedicated to let's say they're equal in size right or in gas sort of limit and one one part can only take the transaction of the new type and another part you can take the transaction of old type and then if the uh with all being with everything else being equal if we can see that the users of the first type actually have a benefit that was promised by the by this eip then you can say that look these are the transactions in this pool and they are actually benefiting because they have all sorts of benefits that people are promising if that doesn't happen that maybe there is something wrong with it maybe the modeling wasn't correct no but this assumes that the benefits will come even if users have a choice uh between first price auction and eip 1559. like it's not clear that uh given the choice between the old transaction and the new transaction i might want to choose the old transaction sometimes but if i didn't have a choice uh you see what i mean like there's not necessarily like an equilibrium where both transactions are working at the same time there could be interactions between the two no but this is actually going to be a b experiment because essentially you can look at this as a two different block chains running with two different rules but we are basically just combining them in one block chain and then if that's interesting because you're testing both groups on the same blockchain so at the end of the day there's going to be interactions based on the gas price right no that's that's true but you don't don't you think that model should win in even in that case or does it depend on some sort of uh coercion that you have to force everybody to to stick with the with the new rules like it might win but it might not as well it's not clear to me that uh in the presence let's say 1559 the first price auction is an unstable equilibrium where little by little you see people migrating to a different format and you might have interaction between the two and i agree with rick i think unless you have some sort of psychological deadline where okay that's it if you don't have a space to do it then you you avoid being in this equilibrium in the first place but it's an interesting question actually like if there are interactions between the two like what does the film market look like even for the transition period like it could help um sort of anticipate what will happen during these eight hundred thousand blocks or however many yeah just i just saw a question from mika that he said that the issue that is that tool the developers don't have the same incentive as users uh we need metamask tether and etc to update since the users can't update without them so yes that i thought about it just now but the um given the sort of i mean given the fact that this erp has it has such a wide well wide support uh uh you you would think that basically uh support from from the you from the wallets and stuff would actually be a competitive advantage however if uh the if the basically the benefits are so weak that we're not even sure that this this sort of eip is going to win against the status quo then is it really is it really good or i mean um i just even if the first one isn't isn't the benefits being so weak i don't think is the only explanation for what could happen like the interactions of the two uh could be complicated and then also and then also just people not like uh like the stickiness of the of the way that things have been done so i i don't think it's fair to say that because there are there are other reasonable explanations besides they're not seeing the benefit but is it like one of the the carrots here kind of block space inclusion right so if you have this 800 000 uh you know transition period at 400 000 blocks you go 50 50 and then under 400 000 it means you know more than 50 of the block space is uh is for 1559 transactions and at some point you know the the benefit is like well if you want the large number of transactions included in the block without raising the base fee um then you kind of need to support 1559 style transactions and then this is kind of where large applications you know if you're like a coinbase or a teacher or something else and you actually have a significant amount of on-chain volume you have a really strong incentive to to use that block space and then the first person to use like it kind of creates a race like you want to be the first person to to access that log space so you implement it first um yeah because otherwise i guess after you know the 800 000 block period it's like if you didn't implement this change you can't send transactions to the chain um which seems like a pretty big distance i mean one of the kind of ways to probably address this i don't know is this does the erp 1559 fixes the maximum block dust limit or does it not it no longer does it's just using the minor set limit now okay so what if you essentially uh fix the the old style block cast limit like forever and then uh or maybe just make it so that you can only be reduced but you allocate all future gas block increases to the new transaction type and this in this situation whenever there is a increase in block size limit it only increases it for the eip 1559 which means that the people who did not upgrade they still have a functionality but they will have to cram into much smaller space and so the the the that actually probably is going to be enough incentive for people to migrate this this is my original suggestion was that we overt almost exactly verbatim what you just said um and i think the complexity of the conversation uh sort of put people off from that but if we're coming back to it i'm very strongly in favor of it increases or shifts in distribution increase i think we do want to like retire the old version at some points like in general the protocol can't just kind of keep on including increasing complexity by adding new types of things forever without removing old things right so it's just a question of you know is it four months or eight or twelve or whatever amount i mean you can you but what i'm saying is that uh we you could do these decisions with having some data because we what i don't want to do is that make all decisions before we even know what's going to happen so we can first say that yeah we can say that now we're going to fix the the old old block size and then we're going to reserve all future increases for the new ones and then we look back into six months and say okay what happened did everybody did anybody still use the old type and if not then we say okay we're just doing a ditch it or something like that so one i don't know if we're advocating anyone's advocating for block size increases right now and so i don't know if there's like much room to grow there and and two i mean if there's two distinct spaces of block space they both will be used because there's going there will be sufficient demand regardless of the fee structure to use both of them so i don't think you're going to see like the the pre-1559 half or portion just just kind of die because blocks faces block space to a certain extent and uh another another thing to think about it would be nice if the two markets were actually separated but what what will happen in practice is we have the standard market or the legacy market and then we have the 1559 market and if they exist at the same time there's a supermarket that that encompasses both of them of people being able to play against them or not against them but actually this is going to be great because that means that people have implemented the new transaction type the fact that they're going to be arbitraging it yeah but but that will will make the one being adopted versus the other information not as as useful because you're not seeing you're not seeing the adoption you're seeing the result of you of the both markets existing at once and then playing against other no no what i'm saying is that what it is not possible for a third party to modify let's say if i send the old style transaction it's not possible for the third party to trustlessly modify my transactions into the upgraded into eap 1559 it has to be me to create that transaction in the first place so the only per people who can arbitrage this are the people who create transactions and if they do that it means that they've already upgraded they can already send the second transaction type so i don't see it as a bad uh issue yeah so the way that i envisioned it originally was that um one five five nine transactions always happen first so so there's you know you double the total gas limit and then you basically make like a sort of like a special block if you want to think of it like a the block you know that much bigger block that double block is split in whatever ratio and um one five five nine transactions always come in first and then they're ordered uh based on gas price and then the old transactions are ordered after that so if you're if you're in in some sort of auction if you're one of these users that's a you know using so much of the of the gas or what have you um you're going to want to switch to one five five nine because you're you're always going to beat who who's ever in the traditional transaction type so another possible idea would be that um if we want old-style transactions to continue being valid forever then we just make it valid to include them as being part of the one five five nine space and we would just like map the gas price to be that i'm into um to the max gas price and like say just set the bribe to like some standard group five way or whatever like it's a bit ugly but you know like well does anybody do we want to have those transactions valid forever like i think no no no no i don't think yeah and the idea would be that at least we would be able to retire the old like basically everything about the old rules except for the format and like we can retire the format later i think i would suggest that after a certain amount so we um so what i suggest is to basically do at least two hard forks in the first hard fork we um we do what i just suggested and then once we get some more information let's say in six months time we if we see that the adoption is happening like people are really migrating and then we can say okay after that we introduce we introduce the exponential uh not exponential sorry the linear uh sort of shift of the ratio down to zero so over a period of time the ratio is just simply going to drop to zero off the old transaction type so and so i basically suggest not to introduce this uh kind of cliff edge moment right now but introduce it after we've seen what happened uh but i don't know then there's no there's no incentive for people to adopt 15 59 in the first hard fork right well it would only be carrying that like if nobody adopts the 1559 then the base fee on 1559 that'll be tiny and they're all well and there will just be this space ready for people to claim it right like the economic equilibrium is basically that the ratio of adoption is the same as the ratio of the of the gas elements of the two spaces right if you allocate some portion 1559 it will be adopted by somebody because block space is in high demand oh yeah if that is if that is happening then this is a good data to say okay after this we're going to just go do the do the kind of cliffhanger not cliff edge but basically gradual uh reduction of the another another another option is have have the gradual reduction start 400 000 blocks in because at that point you can have an emergency hardport turned off if nobody's been using the other half but otherwise you don't have to schedule a multiple hardboard yes i was going to suggest something similar to that so yeah i agree with that i mean i understand now mika is saying that we consuming too much time on the call but i think it's probably worth talking about it because it will make the rollout easier or harder yeah and i think personally i'm in favor of something that doesn't absolutely require a second hard fork because so this idea of like having the the transition period only kick in halfway through i think it's nice because it gives you know more warning although there will be warning by this being deployed on test nets right like if you look at the the whole process um but what's nice with having this transition period in the first ep it means that at some point it goes to zero worst case we have an emergency hard fork to push it back um but if it does reach kind of zero block space for all transactions then the second hard fork is really optional it's like do we want to do this to clean up the protocol and make it simpler um but if for whatever reason like we don't want to do another hard fork on each one or something like that um we kind of don't have to and i i understand the uh trepidation towards it it looks like someone relying on an emergency we needed it but i i would tend to the if we if we were able to do something and then say hey we can do something if we really need it versus we have to push something we have to push this six months to nine months further back that the preference of the community would be we have and we can uh emergency they would rather it us move forward well this is more uh i think this is i guess a bit more philosophical question about i mean my personal view that they it should be a matter of principle that if you don't do it don't touch it it just keeps working uh you don't have to rely on something happening in the future but you know other people have a different opinions than that and what would be so just to make sure i understand this what would be the advantage of having the kind of transition period only kick in halfway rather than linear over the whole time right are we just saying we give more today because another way to achieve that is like you literally plan the hard forks two months later it's it's psychological i mean you have to we really it's a game of chicken right i mean we have to tell people we're going to drive off the cliff or else they're not going to do anything yeah that's yeah that's what i'm thinking as well so i think i'm kind of in favor of just having the transition period over the whole you know to go from a hundred percent old transaction to 99 98 rather than just giving this kind of i don't know 400 000 blocks of slack which which we can get by just delaying the hard fork 400 000 blocks i i think it's a question of uh we have this evaluation inflection point that i think is very difficult i think alexi is i think it's a good idea that alex is suggesting that we that we have this point where we as a community make a decision and decide which way do we go and i think that again from almost like a game theory perspective what we have to say is okay we've started the car going towards the cliff and now we can like turn the wheel but we have to turn the wheel to like stop from going off the cliff or we do nothing at 400 000 blocks and we continue to go off the cliff so it's like that kind of game yeah yeah okay that makes sense and is there a way we can get you know some preliminary data on that right like obviously if it's live on the network then people can start uh can start kind of playing around with it um yeah i don't know like what's you know is there a way to test this before we get the main net basically um has anybody looked at filecoin yet like the data that we have already well the problem with that is every other example is someone implementing something where they don't they don't have you know billions of dollars literally running on an old transaction type and they need to switch to a new transaction type i mean for us there's two separate problems right there's the mechanism there's the new set of mechanisms of one five five nine which i think can be verified and reasoned about and are not that you know that's a pretty well-defined problem and it looks like other teams have sort of taken this what we've started here and gone off and implemented that and i think that's fine and then and i think that's pretty like well-defined and then there's the fact that we have to have a transition period because we have so many so many existing users that other chains obviously don't have and i think it's that transition period that really changes the conversation and i think is what gets lost on people is that there's there's a social problem that we have that other teams simply don't have yes and also you have to project i mean we could obviously all argue that yeah yes we're gonna just give them uh a big stick at the end and then everybody has to migrate within 800 000 blocks but it's sort of like you have to be a cooperative towards uh basically everybody else um and i think uh it's reasonable uh to introduce this and then they say we're going to do another valuation and decide how um quick the the the remaining of the transition should be because we might find that in four months time everybody migrated and we're just going to say oh let's just turn the old thing off or if we see that the migration happens slower uh you know the the new transaction types is taking on but like there is it takes a bit of time we can say okay let's just do it over next year or something and we're gonna program the linear function to to slope down there there's also a risk of um like i i underst the the idea of getting data to then support the decisions on how to turn off or down is great i i still am not sure that the data that we'll get is going to be very easily digestible or or really really say because it is the the union of two markets there are it will be it will be clearly visible how many transactions of the new type got into the block and how many transactions of the old type go in the block you can chart it and make a little grow a little chart out of it i don't know why why it wouldn't be clear but if both markets end up having the same gas price which they should people are arbitraging you should expect that both would be filled to capacity right like yeah that means that that means it's a great result you mean that the there is adoption of the new type you can also see which let's say that if you think about the um you know with some analysis you can probably identify kind of the where the transactions are coming to and from like what web like at the moment you have like a lot of websites which uh inject transactions for users like all the uh whatever you will have like a you know lending websites and stuff stuff like that so what they do they they can just connect to your ledger wallet or what have you and then create a transaction for you inject them blah blah and so you can see like how many of these actually transitioned uh but then because the you know a lot of transactions will be going into the into this contract and so forth there could be some way of estimating uh you know whether the adoption is going on or is it just arbitraging happening yeah i mean assume that the 1559 pool is empty but then base fish should go towards zero and then i think it will be very quickly like full again at least until the gas price in in both pools are the same right like the problem is that you don't really have a counterfactual if you have both things living at the same time that you'll have uh yeah you were mentioning like a b testing but that's not really what you have because you constantly have this interaction between the markets in the gas price right no but as i said before the the the the uh the arbitraging actually does it require you to upgrade that's what i'm saying yeah but i'm sure people will have good reasons to upgrade the base fees exactly okay so if everybody upload charges that that's already a great result that everybody upgraded to the newton format type but that won't show us who hasn't upgraded well yes it won't show us who hasn't upgraded and i'm and i'd like to point out that given the current realities of the chain you know the users are not the the gas the the end users the actual humans who uh tweet and use discord are not the largest gas consumers right the gas consumption is not really indicative it doesn't map you know there's heavy gas users there's people using a hundred a thousand times as much gas as other people and so those people are obviously going to be optimizing and and arbitraging i mean there are gas arbiters who exist in the market today they will be they will be doing this price manipulation not end users and it doesn't matter if there are these gas manipulators out there manipulating the price even if it's to our mechanistic benefit if metamask doesn't support our change for example yeah i agree with that i think we don't really see like the iceberg of transactions on the on the chain yeah i mean if you if you look at the gas consumption right now so number one is probably unisport right unislope would be one of the first people to upgrade i'm pretty sure yes i think we could get them to upgrade and i think that this is sort of the conversation is well can we get can we get unisoft to upgrade can we get metamasks to upgrade can we get etherscan to upgrade can we get coinbase to upgrade if we can get these different community members to upgrade with a if we have a process for engaging them then we can really lower i mean we can talk about this risk from a mechanism perspective until we're blue in the face but at the end of the day someone has to go talk to someone and make sure that they're switching well actually mita said that the ninety percent of unit surface bots but that's actually it's fine because the bots will also upgrade pretty much and just one thing i'm not sure i understand um so if you don't have a transition period how do you split the block size do you just say you know the gas limit is x and whatever type of transactions go in and there's no there's no carrot or stick it's just you can send either type and one block can be 99 uh 1559 transaction and the other can be you know whatever percent i've never seen that proposal explicitly i think i understand your question but i don't know that anyone has ever proposed what you're describing so i'm not sure what how they imagine it to work yeah but basically what we're talking about right now right if you remove this transition period um to see what happens on the chain how do you actually allow that right you just you just have two buckets and then leave them as buckets and then say have fun yeah exactly but but then for example how do you calculate the base fee um [Music] do you take into account normal transactions to calculate the base fee you obviously can't do that because then you're kind of you know removing this incentive to use 1559 style transactions um i know maybe it's something i'm not understanding well but you know i mean like i think you you just treat them as two different sort of pools and you look at them as a two different book chains i think um yeah in a way yeah i know it seems to me like maybe this actually adds complexity to the eep whereas having like the separate like clean buckets makes it simpler but i'm not sure if that's just from a high level my intuition is that you have to have two very clear buckets and if you don't do that it just doesn't work okay got it yeah that's that's what i'm thinking as well and then in the chat there's a couple comments that say you just leave it 50 50 and defend it like forever but the challenge there is that's actually more aggressive than the current proposal because the current proposal just uh the current proposal starts at like 0 15 59 and then gradually you know gets to 50 50.

oh the current proposal starts at 50 50 well it doubles the block size and starts at 50 50. garlic yeah so there's basically there's immediate boost in terms of block uh gas limit yeah yeah after the heart yeah yeah i thought i thought it doubled the block size and started at 100 0. sorry that's my bad because if you did that right you could if you if you doubled the block size start at still 100 legacy transaction and over time allow more 1559 transaction uh then you get to this 50 50 spot midway through the transition um right and the the other option i mean i think that there is this sort of desire for engineering parsimony and i'm sorry i can't read the chat and listen at the same time but uh you know i i appreciate the desire for engineering parsimony where you don't increase the block size and then and then what would have to happen is you'd have to ramp in 1559 and then ramp and then ramp down the classic transactions which would basically be throttling potential 1559 adoption which we don't want to do which is why we double the blocks got it yeah yeah so is there so i guess it's kind of circling back to alexis proposal of just leaving it at 50 50 until we get more data you know on the on the chain um is there like like the strongest objection to that is basically that it doesn't create an incentive for people to switch um but if people already kind of want to support this we'll see we'll see how much i guess organic interest there is for it right i think it will it isn't correct to say that there is no incentive to switch because if you do did create this extra new bucket which is the same as the current one anybody who hasn't migrated they are actually um sort of using only half of the space that could be using so like all the the new smart people who are implemented the 1559 will be using the new new bucket while it's still empty yes i also think that making sure that 1559 transactions simply happen first is a huge huge huge incentive that will cause many bots to go to to apply it as well as uh exchanges in any number of people and my objection to alex's proposal is more that the data won't be able to tell us that 1559 was adopted or not because of the lack of counterfactual so we could set up some kind of experiment but i think this is not one that would tell us uh what we want to know like there's no way to interpret the data in a sense of oh people prefer 1559 to the old style transaction so i think that that's super important to keep in mind i i i appreciate the technical point there but i think that the evaluation that has to happen just necessarily because of what you're saying is social you can't there is no data on chain that you're going to look at that's going to answer this question for you which is in part why we need to have this thing that alexi is talking about if we could just use on-chain data then we wouldn't need to uh give this social decision point but because there is this large social component to the problem we have to create this decision point where we where we will not have enough data i mean well where we can't say positively that the experiment will give us sufficient data we have to run the experiment have this inflection point and then see what happens in the community and actually go out and do the analysis by talking to people as opposed to looking at what's going on on chain okay yeah i can agree with this as long as uh yeah yeah this is fine and my my objection is that there there will be people that will adopt 1559 because there will be gps and though and those early adopters will just run for it but we we will there is a large group of people that are slow and won't adapt without some kind of hard limit and in the end if there's an option to keep doing 59 there are people that will just keep doing it i'll keep there if there's the option to do standard transactions there'll be a large long tail of people that don't support it unless there is some kind of heart and then yeah just for i guess completeness mika had a couple comments in the chat saying his objection to an excise proposal is that he doesn't think we'll see we'll get any usable data from that change that there's not a scenario where we don't see both bucket fails under other than ethereum usage going to zero um and then what's the objection to just be willing to hard fork away if we see people not adopting i think we can't oh sorry go ahead i think we just got a time i i don't i'm not sure i mean i'm not sure i understand mika's point completely i i i think that alexi's point sort of encompasses both of the that that response i mean we have to we have to set a time so that we can say okay we should expect a hard fork here um uh to to to you know incentivize people to be prepared and to to just give people notice i mean from my point of view this is the two different i mean it goes back to our disagreements about about let's say difficulty bomb because i see the approach with the difficulty bomb actually mirrors what has been baked into this current eap 5059 proposal is essentially this what i think is kind of insecurity over the developers that you know we have to always kind of in embed some sort of threat or cliff edge just in case that people don't uh you know don't do what we want um instead of saying yeah we have a clear roadmap this is what we're going to do and we are basically secure we say we we know what we're doing and we are going to do what we're going to we're going to do and you just basically if you you know if you're with us you're with us you don't have to threaten you and that's kind of my approach to this and so i don't like creating threats in the future that you know if we you know if you don't do this we this is going to be hard for it and it's going to kill you or something like that i think the difficulty bomb is a great example because i think that what the difficulty bomb has actually demonstrated is that we make empty threats right i mean that that to me is the is the to your point i i personally believe we should be making threats but they should be legitimate threats not empty threats and so if we aren't going to commit to actually doing the thing to your point um and i guess and that's also sort of an interesting again psychological difference like are we threatening people or are we just saying that you know as the operators of some level as the as the architects of the system collectively the architects are telling you this is imperative and it must happen and so the the architects are going to do everything they can to make it happen be prepared or are or are we going to as architects capitulate to people who are i think we all sort of collectively believe are actually making things worse for everyone else out of either uh you know probably out of more incompetence than malice and i think that to you to your opponent lexi that is exactly like there's a deep philosophical discussion that we have to answer here and we and i think that the difficulty bomb has actually set a precedent of uh the ef says that something's gonna happen and then it doesn't happen and that's what i think we have to fight against yeah so it's so to summarize this basically if we say that okay it's gonna happen in four uh whatever eight thousand eight hundred thousand blocks everybody understand that if people didn't have time to upgrade we're just going to emergency hard work everybody knows that and therefore i agree this is a completely empty threat because it doesn't save any purpose it just basically creates more work for us to everybody knows that if somebody puts the pressure said oh we didn't migrate you're going to kill ethereum we're going to do emergency fart fork and it's also going to look quite bad um well when i'm thinking about it this way just so i can clear for myself i the i am i am confident that there are people that will wait for the last one to upgrade you've seen this with every hardware and every every year you just need deployment so there so there will be there and then you can basically get through with it so you have to make sure that your threats are not empty threats that's what rick was saying but like if you know assuming this is not an empty threat what's the worst that happens you know if uh we just put in the transition from the start right we get to the point where there's no more space for old transactions obviously some amount of like i don't know altruistic or smart or like you know incentivized people have upgraded to 1559 there are some people who are kind of stuck at that point and they can't you know do anything until they upgrade how you know how big of a i guess i'm trying to get an intuition for how big of a group that is and and what's the impact on them because yeah sorry to interrupt it depends on who they are if we if we you know if someone on this call just sort of like you know grits their teeth and provides the fork to metamask if someone goes out and talks to uniswap if someone goes out and talks to these important you know these people and make sure that they actually you know basically hands them the patch then you know maybe there are a bunch of scrap stragglers that are irrelevant you know i think it's really hard to say um you know we have to take a strategy that's much softer again to alexis point i think we have to just be willing to go out and talk to people and make the change as opposed to sort of decreeing it from on high and hoping that people then listen to our decree and when you say make the change it's like like i mean i think it's possible to reach out to people right like james has done it for the hard forks the cathedrals have done it i'm happy to help with that as well um it gets obviously harder if you know we have to implement it for coinbase and for metamask or whatnot so i and what do you see as like the best or like most effective path there well yeah i usually stop thinking about this problem at right where you ask this question but i think we will actually have to be providing um forks i mean when i say we i mean i think that anyone who wants to see 1559 implemented and is and has the means and is on this call also needs to be willing to go out and talk to uh implementer you know implementers of auxiliary services um to make sure that they implement it as well you can't just talk to us here and and think that you're gonna accomplish your goal you're not yeah so that's definitely something we can do like before the next call is just like reach out to various you know large users of the chain and or you know both individual large users and like kind of gateways for a lot to small users like folks like metamask and and exchanges and whatnot um and just kind of gauge you know how like where they're at regarding this um and that would give us i think some preliminary data around what they think is the biggest uh hurdle how realistic it is how much advance notice you know they need uh yeah um that might be worth looking at uh funding with the with the uh funding some of that outreach cause it's it's just it's a lot of um it's a lot more work than i think people realize and having done this with harford it is a very high touch to even get a rough spawn got it which translates into that's a lot of man hours to be able to do yeah yeah um and just yet to be mindful of time maybe that's something we can we can take offline and james i'm happy to follow up with you and rick also or anyone who has thoughts about this yeah that's a good call and okay great so just coming back to the actual implementations then what do we see as the biggest blocker now so assume i i don't think we have enough data to make like a a big change you know the [Music] to the spec um if we assume that what we had was good you know was kind of the good uh conceptual thing it seemed like the transaction pool documenting better the transaction pool issues and mitigation was one big action item what are the other things that we can be working on to move this forward uh implementer-wise the only other thing that i've picked up is the to update the spec so that the base fee is only incremented a maximum or sorry a minimum of one and is there value in going and doing test nets uh you know beyond what we have now uh does anyone see value in that or do we think that we kind of need this answer to the to the large users um before we do any of that i see some value in having a more public test net that uh we put a bounty on breaking the member yeah i think we should do both at the same time i think we should continue forward with the test nets until we get up to like a robston level test net because i think that we're going to need that anyway to demonstrate seriousness and commitment and for other reasons as well um yeah so i also wanted to say that um there are you know there there are these test nets which are basically basically tend to be nexus of activity uh like say at the moment that syringe b that was reproposing before where you can actually see serious action going on in terms of like number of transaction people deploying all sorts of stuff there and so it would be good i mean if it's possible to get that kind of network to be running on this change to just show that it's actually working um yeah and i feel like that's that's really valuable but it's maybe like a step ahead like is there i guess that's a question i'm not sure but like is there value to having like a smaller public desktop before using like a you know forking one of the larger ones yeah i think we should have a phased approach okay and then the step after that would be to get it sorry you kind of cut out there uh so the step after rick just said would be to get it into a yolo style test net and then the step after that put it into rom yeah so right now we're kind of like that the pre yolo step i think you know in the over the next couple weeks we can do a sort of 1559 style yolo testnet um and the question there is do we want it to be a proof of work test net it seemed like yes based on testing all the code paths does anyone have like a strong objection to that okay i'd say cool so proof of work kind of early test net um yeah is there anything else and i think you know like it seems like there's definitely like a month or so of work and we can have another call after that but like um you know just reaching out to the large users uh having the spec updates uh and just the clarification for uh the transaction pools and the increments uh setting up a test net and then obviously there's all the research uh barnaby and tim rough garden are working on as well in parallel is anything else missing from this okay i think that's good until next time and then after after that stage then it's been getting more clients yeah but we don't want to do that yet so oh that's good for you uh mika says 2017 27 18 is also like a thing you should be thinking about uh uh this is probably just a throwing out there in the air question does anyone have a sense for how close it would how long it would take to get the transaction envelope vip into a yolo testnet basically i didn't get like the current implementations right yeah i by how how long would it take for us to get implementations or things into the point that we could deploy it as part of a yoga as part of it would it include eip-1559 or would it be on the base no it would just be the transaction that's the that's the uh test pretest that peter good to go oh okay that's what they're that's what they're using for integration testing basically a pre-test i think it would take about a week or two if that was my focus to get that implemented and go ethereum yeah two weeks for bazel i would say okay uh if we do that then it's pretty reasonable to start targeting the target 27-18 or 15-59 27-18 okay um do you think we should do that now like i feel it might be valuable to just set up the test nets with our current implementation because it already took a lot of debugging to get them to work and we might be making some other pretty major changes based on you know feedback from from large users um so given that does it make sense to hold off you know kind of these large spec changes for now except i guess this sort of increment change which uh which is a small one and actually makes things run smoother um but to kind of put 2718 and the potential transition period change on hold until we have more data um i wouldn't put the 2718 into the into the 1559 implementations okay until until that it's 27-18 is on some kind of road test net so it should be a separate it should be a separate uh okay so a separate fork that then is trying to get in at that trying to be included in an upcoming got it and then one once it's that's been accepted then we can go back and do the 1559. but it we start on getting 27 18 into what it will be implemented then the sooner we can have 15 59 also i just want to draw attention to micah's comment um where he mentions that peter from the death team would like to see that implemented with the second transaction type not just the legacy type yeah so we can have 2718 implemented but not like on yolo but not in maintenance and then wait until there is something to include but we can still have it implemented and in the form of what it would be like when it goes to mainnet that the 1559 team can adopt right right what what what um everyone's talking about james is that you can't just put in you know we're being thorough you can't just have 27-18 by itself you need 27-18 or 27-11 in order for 27-18 to actually be work you need the second type yeah and i'm just wondering is that like out of scope for what we're talking about right now well i think it's presumably all the same people so we might as well talk about it got it but it is out of scope yes you have to have a second type be able to even have transaction envelopes be implemented well for this strictly but to demonstrate its purpose to have it to verify that it actually is safe and that it works right if you just deploy uh 2718 by itself you just have this weird sort of vestigial thing you need a 17-18 plus so the actual new transat another you need to have two envelopes and and what i and to because it's relevant now the thing that was confusing to me about uh 2718 was it wasn't clear to me how it treated the transaction pool it just sort of acted like the two envelopes were equivalent which i think more more times than not that's not going to be the case yeah so i want to be clear here that i'm not talking about maintenance where the stuff that you're talking about how 20s type peter and and 2718 and another transaction type going into maintenance all of those things need to be verified but going into yolo which is the pre-test net that is used for testing client integration we could put it just put the transaction envelopes onto that so at least the 1559 implementers can implement it and then test it and then have that what's i i think probably put in a dummy second envelope if for some reason it's too hard to implement my inclination would be to do 27 18 and 27 11 at the same time if there's some reason why we can't do that uh as from an engineering perspective then we should come up with a dummy shim for 27-11 but i can't imagine that's significantly easier from an engineering perspective yeah because that because as a that is a the change is that 1559 is gonna the reason i'm getting into this is the changes that 1559 will need to make in order to adopt 2718 is a future bond so if we can get 2718 to a point where it's uh uh it is moving forward and well specified and the clients all agree and it gets to the it's on yolo's test net stage then the work of redoing 1559 to use that makes sense because we have what it would eventually be here yeah i agree with all that i think that they're two separate i think that 1559 and 27 18 are separate the question is what goes with 2718 since we're basically excluding 1559 from that list yeah and either 27-11 or a dummy a dummy transaction that was only going to work on yolo would also be yeah i think that makes sense yeah and just in terms of priorities due because like rick said it's kind of the same people working on this stuff um should we get the 1559 test net up and running kind of before getting this yodo 2718 assuming there's not teams that can't do it in parallel uh what is the ian and a bill kind of thing because i i i would go with what they would want to tackle first well there's like so first of all just like the increments change to the spec so i think that's probably the the highest priority because it's it's uh it's like a small change that has a big impact but then basically setting up a proof of work test net with uh with 1559 as is specified right now um how long does is that a long process with the minimum changes and i don't want to make the decision for i i don't have the enough i don't have the enough information on implementations and stuff i think to make that decision i'm just bringing the point of there is this future bottleneck that we can get ahead of and so we should right yeah i guess it's not even clear to me if i would be the one doing 2718 um since it is you know a separate eip but yeah i don't know exactly how we should prioritize that the immediate focus would be the changes that just iterated yeah and my bias would also be towards getting the 1559 network up like before and and uh you know getting that to work because if there's bugs found there like i think it's a higher priority at least you know for for us like for the 1559 kind of effort to fix the bugs in the spect um and i don't know and maybe kind of other if other people really want to push 2718 they can start working on the on the test net as well yeah that sounds good i don't know how it's funded amongst the various implementers but i mean we're definitely only at vulcanized we're definitely only working on 1559 just as a as a practical matter so uh wherever however that other teams handle that i mean i think that's on a per team basis but yeah yeah and i think for us at pegasus it's just kind of the same like you know we want to focus on 1559 and and kind of put the bulk of our efforts there and obviously 27 18 ends up being a part of that you know we'll support it and we'll do that but we we definitely can't be like champions for that um yeah and i guess with two minutes to go uh uh the idea of like funding and accelerating development was the last thing on the agenda um i know alexa you you kind of mentioned that at the beginning i don't know if you had some specific thoughts to give some context like it seems like a lot of people would like to see 1559 happen quicker and and and potentially you know provide funding to accelerate that um my biggest question like for the people here is just what do we see as the biggest bottlenecks in terms of like our execution speed um would money actually help there um yeah but i don't know if it's i don't know i can stay on like 10 15 minutes if people want to chat about that but if everyone has to drop in one minute i it's probably too big of a can of worms we could probably make it optional yes if anybody wants to stay on we can discuss this i'll have to go but i'll just make my two cents i think that the way that i mean i don't feel like development in my whole time working on this project i don't think that developers have been or engineering has been what's slow i think it's been communicating to the community that you need to have research like basic research like tim roughgarden type stuff uh and and i'm sorry the other guy's name is french i don't want to mangle it uh stuff going on i think that getting people to understand that that has to be funded and that has to happen is like a huge milestone and then in a similar vein what james was talking about earlier about someone has to like go you know go door-to-door and make sure that integrations happen and funding that and i think that you know those two things getting funded is way more important frankly i mean we'll figure out how to do the engineering but but from a financial standpoint but getting the community to understand that we're not you know we're not incrementing a a variable we're not incrementing a constant here we're really changing a lot of a large swath of what's going on and that requires doing a lot more than just engineering i think paying for that is where the money should go and on that note i have to go so thanks everyone and uh i'll talk to you all later thank you i have to drop as well thank you thank you fine okay let's see who is left hey lexi okay hi let's see who's left yeah i can stay thomas you can stay i'll stick around it's too late anyways so right too late yeah so i just uh kind of wanted to us to discuss a tiny bit because i know that twitter is is basically really bad platform for trying to explain these things and people get offended very quickly like uh yesterday that was you know they started like lashing at each other and it's very bad um you know somebody said the wrong word or like whatever so but i basically what i picked up picked out from the recent conversation is that they seemed to be this sort of expectation that okay now we threw some money in there's bitcoin grand you know you got 60 grand whatever how much i don't remember but where is the where is the result right how when no it's not like that actually they're basically saying like when this is going to happen what is the blockers which is all reasonable questions um and yes but yeah we we need to wait to actually explain as rick said that where what are the expensive bits of it like it reminds me on the on the statement project where eventually the reason why i decided to stop doing it is because i discovered that we would need a lot of this door-to-door people to go doing really unexciting work of just basically just having meetings with people all the time trying to figure out who can migrate how they migrate and all sorts of stuff and obviously i couldn't do that yeah i i i don't think we can sort of address this because we we don't really have a lot of people from the other side of the uh from the other side of the arguments what anybody else thinks i i agree that like there's a lot of uh communications and and outreach that needs to happen i don't think that's an impossible problem um i guess it kind of depends like how you look at it like i'm not an engineer so for me the engineering stuff looks harder than having tons of meetings um and i guess like vice versa um i think with regards to like the community's expectations two things i'm a bit uh i guess anxious about is one explaining the uncertainty of 1559 so you know a lot of people have you know brought up a bunch of issues today with the eep to me it's still not like a done deal and i think there's a perception in the community that you know this is just it's all downhill from here um and and it's really not so i think articulating that and making it clear um and and because that also translates the funding right so like if the people you know funding the bitcoin grant are kind of mad that it's not moving fast enough uh they'll be really mad if you know they find out there's like a fatal flaw and i think it's really important to manage that expectation um but they also uh they they also don't i mean you know you look at the bitcoin grant it's it says 60 or whatever how much did it yeah i think it's i think it's a 80 000 because the price of ether went up okay it's like a thousand yeah okay because somebody gave an issue okay 80 000. sort of okay that's a sort of reasonable amount of money but then how many people can you you know hire with this kind of money how long then when you start thinking of these terms it actually turns out that it's not that much and uh it's it sort of underscores the point that the bitcoin grant is still not capable in in completely funding this project and this is what people need to understand that there's much more if you really want to make it sort of happen at the kind you know at a decent pace uh with people not getting stressed about like doing 10 jobs at the same time yeah you do need to basically splash a little bit more money into this and who is going to splash this money this is the question uh yeah and i think yeah some people have you know brought this up and reached out that i've been trying to to chat with some of them uh and and one thing like you said that i've made here is like this eighty thousand dollar so right now how things are funded right there's this eighty thousand dollar grant which will probably mostly go to vulcanize you know modulo some other some other things um consensus is you know we have me and and abdel and kareem that we can put kind of part-time on this uh but obviously there's an opportunity cost there we have paid customers and you know that's always like a prioritizing prioritization thing the ef has people working on this you know pretty much full-time so barnaby um which is which is great and then tim rough garden has been paid kind of independently by somebody else um but this means that you know the bulk of the work is happening by like one or two people by the ef uh you know and then one or two developers on both the vulcan eyes and and in our side um and and it's you know it will move along but it will be you know i'm not even sure slow is the right word um but you know it'll be like not as quick as it could be um yes and also the there is another issue here is that you know sometimes uh there are certain things that need to happen before you you you reach your kind of full full speed so you need to do sometimes you have to do some rep proprietary work an example is this uh transaction enveloping things right i it probably if it existed before this the things would be a bit easier and so what might be interesting is to have a this understanding that you know kind of you not only have to wait for one year for all the work to happen but for all the people the things to fall into their places all the pieces to fall into the places like uh you know when you launch a test net you cannot uh you know you cannot put let's say extra hundred thousand dollars and make sure that the test net needs to be run for like 10 times shorter than that you actually have to wait yeah yeah and i think i think that's why you know like personally i've been like uh uh reticent about going back on like all core devs and discussing this again because there's just like known issues with the eep that we're still you know addressing and whether you probably need more than one implementation to like start addressing them like i think it's been helpful to have basu and and guest kind of disagree on stuff and fix those but like we definitely don't necessarily need everybody to have this at the top of their priority list uh because we might find some other issues with it so yeah it's like this weird in-between period where and and also what just thomas is asking on the time i know it's a sort of joke but it's actually not a joke but yeah yeah i mean of course uh this this we should not uh undersell ourselves and and then it applies to pretty much everybody in in the core development that our work does cost money and it probably cost a lot of money so it is it is okay to expect to be paid for these things and i i know i don't know how exactly but the expectation is not you know it could it should be there go ahead james i was just gonna say that an opportunity for public to for others to contribute funding in a meaningful way would be to provide a funding to help the other clients implement 1559.

so netherline uh they're in ethereum if there was a the sooner those happen the sooner it can happen and those teams are already over right all of client teams are busy so to get resources to build to implement them in all the clients would necessarily make that the time yeah because basically what happens is that every all the development teams at the moment they have their own priorities they have own agenda because partly some of them basically are thinking about how they're gonna you know get some money to pay their people right like it was rico saying it on on on twitter is that okay some of them actually have to pay out of their own pocket to to to make things happen because they actually sort of like because they have a bit of money or because they they hope that they're gonna make something out of it in the future uh but just basically piling on to that and expecting things to go faster that's the you know that's not gonna happen i think uh that has to be sort of appreciation and respect for uh for people and you know expect him to slow in 30 grand and things happening in a month it's not realistic so if you have if you basically throw in half a million then you probably have can have these much much bigger expectations but yeah uh uh does that so if if someone came in and did a did an implementation into nethermind uh separate from the from the team i got to give to another mine team does that fit what you're saying or not what you're saying alexi i mean it depends on i mean i obviously i don't want to talk for uh for too much but it depends on the ability to do that also depends on the code structure and how it's structured it's like sometimes in some of the implementations it has to be pretty much the people who are owning that to be made to making changes in some implementations it's easier to just come from the side and propose the implementation for example what we are trying to do in our implementation we're trying to split everything as much as possible so that to allow people to come and do things on the side uh but yeah i don't know about the others and i guess it's also worth noting like this is kind of a weird eip because you know like for normal eips client you know there's some team that's usually not a client developer that kind of does a poc implementation and then they bring it to all core devs and then the clients all kind of implement it you know quote-unquote for free um and and it gets kind of moved up um and this one is kind of weird because it's like applied rnd in a way so uh the there needs to be like more early implementation and it's also a much larger change than other eips and it's not clear where like the boundary is from like yeah paying like a third party to provide a reference implementation and then paying all the clients to prioritize that on the roadmaps um and and the level of like alignment you need right like um how do we get funds for like all the clients to prioritize this um and is that like the model we want we're like uh if there's like this huge change that happens then we basically need to pay for and implementations and by we i guess like the community needs to find a way to pay for these and implementations um i mean if if we wanted to eventually come to a much healthier kind of model of development so that goes back to what we'll be discussing again in july as well if we want to come to a much healthier model with a better development then there has to be expectation that any work which is which needs to be done done the money has to come from somewhere so far i as far as i know that the the core developers haven't figured out the way to finance their development completely without some kind of subsidies and therefore for now the subsidies have to be applied so i think like we already know we have a couple of milestones to hit and the first one is like freezing the specs then we know that we have a yellow test net we know that after this we want to have a proof of work test net or something and then we know that other clients will need to implement so a good way also to manage the expectation of a community would be to have like a reasonable let's say roadmap with some some kind of timeline because it's currently like there's a lot of momentum around eip1559 like a lot of people even on twitter i've said oh if money is the issue we can always like throw more but like a good way to say okay you can give us now but we might we don't we don't really need to throw like a half a million dollar on it currently is to have this sort of timeline and to say this will be useful later on uh once we yeah i guess after four months if people don't really see improvement or for the community improvement anyways is is very binary like either it's on the main net or not whatever is happening in between like they they don't really see as improvement so yeah having like yeah the the thing about this uh kind of drip drip uh fine financing is also problematic as i think tim mentioned on twitter is that the reason i'm talking about throwing in for half a million dollars is because uh in if you if you know that the money is there then you can actually really hire somebody to do the work for a reasonable time you don't have to keep everybody on sort of zero hour contracts and stuff like that and yeah we're just saying that every any time when the money runs out you're fired yeah and i think that's that's exactly the situation we're kind of in with the bitcoin grant to be sure right like we have you know like a not insignificant amount of money but you don't know if it's going to last you three months six months 12 months right and and obviously the rate at which you spend you know you kind of want to be conservative on it so yeah yeah that's why i mean that's why sort of the model where which works the best is either you have a very reliable counterparty like let's say if you foundation uh that basically has a contract with you or something like this that they give you money as long as you don't do anything really stupid and or you have a pool of money in front of you and and i think yeah back to barnabas points just what i find i think the hardest is like yeah how do you you know for those intermediate milestones like setting up a proof of work test net and whatnot like what's what's the right amount of funding and of you know like should we fund client implementations for all the clients to join the test net which might not work right and if not how how money do we fund and how do we choose it like i mean you don't you don't need to be so fine-grained i mean this project is not so huge that you have to be like obsessing about fine-grained details so what you could do simply is that uh let's say that you say okay for for this to happen we need uh you choose the implementation let's say we need to go ethereum nether mine whatever open ethereum and what else i mean choose them and let's say everybody should get one developer on each team implementing this and get to make sure that everything kind of works uh for how many months whatever and that's basically it i mean really rough uh idea uh so but you then you know that in each team there is one person doing this job and of course they can do some other things at the same time you cannot stop that but at least the money is allocated you know that it's there uh that's so that's we'll say i mean if this project was for five million dollars then of course you have to have extra scrutiny about you know where exactly this money is going but for i mean even like if it's half a million i don't see the point of obsessing over the details yeah and i guess justin has a comment around like you know the precise funding needs for fast tracking this like i i'm not sure is there like a way to fast track it like it seems i guess i don't know past like one developer per team i think there might be like diminishing returns and i'm not sure if like the funding actually fast tracks things or just puts them at like a normal pace like we yeah the the things that would uh fast track would be funding the community outreach stuff so that there is a group of people that are ready to go out and make sure people are adopting uh other things would be having bounties for 14 minute masks and put in and implementing 1559 action support so you just put up a list of major wallets and major things and say hey anyone that does anyone that that implements 1559 into it gets this bounty um and then the last one would be after this kind of round of of r d that's happening for the next month or so when it turns into all the clients need to implement giving them support through whatever however it is for each client team is the kind of the last i mean i don't know i don't know if it's the the issue with the um kind of the bounties or something like this but i i just like to simplify this um to because essentially if you say that there is a money to pay let's say one developer in each team for six months right that's it you know and they suppose this developer is supposed to be doing the ip16 1569 they can do basically if they if they're not coding all the time they can do other things testing right more testing doing spinning out test nets talking to each other whatever i mean whatever they could be whatever they can do to make this to make sure that it happens really and if they're doing something else as i said it's fine as well you know you know would you be like really upset if they spend some money on improving performance of their client as well and i think i i at least from our perspective like there's value and saying one developer is like you know paid to do this and and it can help just like prioritize 1559 about other stuff on a day-to-day thing um obviously like i'd be curious to chat with other client teams um to see that but um and and i'm happy to take that action item to like reach out like thomas i know you have a bunch of comments in the chat and i know you can't talk right now but i can set up a call maybe with like nevermind uh i don't know alexa if you want turbo gets to be part of this but to just yeah talk with the different client teams see what's like a reasonable amount of engineering work and um and uh and uh yeah can we just get like one one client one person on each client team to put this at the top of their priority list and then the other kind of more ops worked uh as well um and what would be just like a rough amount for that okay somebody needs to save the chat uh before we go it will save it'll save uh i'm recording on zoom so it'll save i'll make sure i'll send it to the griffin so griffin does a transcript uh based on the zoom recording so i'll send them the chat as well okay cool so i think i've yeah i'm also doing the notes for detailed notes for it and i have the chat saved with me awesome yeah so i'm happy to take that as an action item to follow up with the different client teams next week and see what are the you know possible uh like what what we think makes sense okay yeah um um anything else anyone wanted to discuss i think that's pretty good yeah um yes oh sorry go ahead yep just one last thing i want i wanted to throw out uh in the beginning of the call we were discussing about having the transparency on the funds so um i have just created this sheet uh for reference and we would be like sharing it with people who are interested it will include all kind of outgoing transactions will be recorded here okay let me just share my screen so it's in the recording okay so we can see here um yeah like we said the two only transactions so far have been for vulcanize um yeah cool anything else okay then uh yeah so i think there's a pretty huge amount of work to get done in the next couple weeks uh so some changes on the spec um trying to get a test net uh which would work out um following up the conversations around that 27-18 uh there's some r d work and then the whole funding discussion um yeah that's a lot uh and i think it makes sense to probably have another one of these calls in like a month to give an update on on all those things okay thank you very much bye of course thanks everybody thank you thanks out