# EIP-1559 Implementers' Call 8

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

## Description

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

## Transcript

and we are recording um so welcome everyone to 1559 call number eight um yeah we have probably a lighter agenda than last time uh so there's only been two weeks between the calls rather than a month so we might not last the whole time but uh yeah first thing on the agenda was just status updates from the different research and implementer teams um and first one there was transaction pool management uh i don't know asgard did you have any updates you wanted to share yeah i mean i can give like a very brief update um so basically after after the kind of this preliminary write-up uh from from last time um we kind of took a step back i mean of course i'm i'm the main one in the team currently working on this but then we also we for example we had a call with um martin from geth earlier this week and we went through some of the details of the current gut implementation just to check if our like um well i think i have some camera issues whatever um uh if if um some our assumptions were basically um good and and it seems like we actually kind of were a little bit off on on some of the small details for example turns out for the miner there's actually like some uh significant rebuilding of the sorting already ongoing after every single block and so seems like that that's less of an issue now for one five nine to just basically also use the use similar mechanism so so it seems like basically it's a little bit probably a little bit more optimistic or a little bit simpler than it looked two weeks ago but but yeah uh going forward so the idea is if the next call is only is it ends up being in a month or so i would hope to basically have a full write-up including some maybe some some simulation work and so on done on like a proposal for for how to do the sorting and and i think last time you were saying um that it all looks like this should be very doable and i i would like to preliminarily agree that seems like some details are still to be determined but it should all should not be like sorting should not be an issue going forward that's really good news um yeah thanks yeah and it's great that like yeah the get team is our or the get code base already resorts every block for miners that's that's really good news yeah um so what are your current thoughts their ends are oh yeah sure so so i mentioned the kind of the um the mining um because that's where we're there seems like we were a little bit off on on the exact um details of get although to be fair like we again we talked with martin he's more of an expert on the memphis side of things we uh also like when we want to reach out to the uh the people within the guest team who are more like um responsible for the mining site so so so but but but i i am reasonably confident that this is actually now now not very um correct um yeah on the eviction side i think like basically the only change for now like that i'm that i had so far was that i think i'm a little bit um like more optimistic on just basically using a very simple heuristic that might be very inaccurate but like just precise enough so we like because again for mining it's really just important that the top end of the memphis stays like stays very precise and then if at the low end there's like some some eviction that's not like not not ideal ordering wise that doesn't really matter so you can get away with like very very efficient implementations like only resorting once every so often and so on so so i think uh the only the i think the main focus on the victim side really will be testing it like under a huge variety of different uh different base fee behaviors just to make sure that under all of those it hits some some minimum stability basically this this yeah what's the accuracy what are some heuristics that you're thinking of um well again something basically where it's like a very simple way of calculating some some expected um future um and effective minor mining tips so for example you take the current base fee and then you take um for example historically you you always maybe the mempool always keeps track of the of the uh variability there with within the last i don't know 24 hours or something or it could be different approach but then then you just do like a very simple for example you just do like 50 of the current basically plus like 25 percent of one sigma above and one sigma below basically just just just just to give you some some idea right again that that might be as simple as that sounds like that might already be good enough that you have like it's not just the count base fee but you also like take into account like a the higher one and the lower one or something and then you just update that maybe even just once every so many blocks um and and as long as you can do that efficiently and as long as basically that is good enough that that like on the high end your sorting is never is still absolutely like perfectly precise um but again i'm right now i'm not confident enough that this this would work already but but that's basically that's that's that would be like currently like one of my candidates for like a very simple heuristic that might be efficient but still good enough yeah if that makes sense thanks yeah that does make sense yeah um cool anything else on the transaction pool management okay um next up uh abdel do you want to give a quick update on the large state testnet generator and where we're at okay yes so we currently um have set up the new test net so this will be a profound test net and the goal is to have a state comparable to mainnet so so far we have generated 100 million accounts and we are now using a smart contract and we aim to generate 100 million entries in this smart contract and yeah when this will be ready we will share the url of the different nodes and the block explorer and the headset so that other clients can think of this new testnet and yeah that's pretty much it so we have four nodes running and the generator is still running and i will share everything when it will be ready that's it cool yeah and i think for that once we have it up and uh once we have you know the test net up and running on bay zoo and then we get nethermine and get syncing to it i think we should probably just like schedule a time to then spam it with a kind of transaction and gather metrics from all three clients um hopefully we can gather metrics and it doesn't you know just fall over uh but if it falls we fix it try again uh but i think yeah if if we have at least one or a few shots of like saying look we spammed the test net for you know two hours with transactions and like the node stood up i think that's like more than the worst case we'd see on main net because in two hours the base you would probably go up like you know a hundred thousand x or a million x and it's just not realistic to even do such an attack um yeah hi it's ramil i just don't join it sorry for being late no worries um any thoughts comments on the testnet no i think it would be important to make sure that every single node is publishing transaction from their own respective transaction pools so we know that we cannot not only consume the transaction load but also that every single one can generate them yeah so we have we set a very low difficulty so everyone can be a miner on this test net so oh no not even uh it's a minor one thing but also that uh okay the client can be a source of broadcast for this yeah yeah yeah that makes sense yeah and i think i think the tool about i hope again yeah yeah you can use it on every client so cool so yeah so maybe when we schedule the things like every client can kind of spam the network you know yeah yeah we've been using your tool already for uh for spamming the network when we were working with bazoo network on this current solution so we were pushing transactions to test that problem that was reported before and it's all fine and we can broadcast nice nice nice and yeah i will update also the the web front end to add the list of the different nodes and the the type of the node and i will add uh if you give me some url of network nodes i will add them to the front end so that the user can choose to which node to send the transaction yeah perfect yeah cool so yeah i suspect yeah i guess i suspect we'll probably have the test net filled up you know sometime over the holidays so early january we should be able to you know share the information and then it might take you know a week or something for people to sync to the test net because um it's big uh and then yeah sometime in january we can probably run this kind of spamming test um cool any other thoughts questions on that um next thing on the agenda i think i just copied this over by mistake but like eip2718 i think we should wait until after this testnet thing is done uh and and then add 2718 support to all the specs uh it won't change anything for performance but at least like we'll get the actual uh test net data before we we have everybody changing their specs does that still make sense for people yeah sure we still want to run some transactions spamming after adding it but yeah yeah just a formality yeah cool um do people in here have a preference for feelings about ssz versus rlp since that's almost certainly going to come up again no preference oh sorry i couldn't find the mute button the only thing i guess uh is on the last of course we talked about maybe doing ssd as the dev p2p layer first and then bringing it to consensus so i don't have like a strong opinion but i i wouldn't want to like uh go against you know the rest of like all core devs on like having ssc in 1559 um yeah if that's gonna be a blocker yeah oh actually sorry as for s3p1559 obviously i would like to keep it as separated from other things that we are adding as possible so i'm generally adding to 718 and adding a z i think it's a z itself may add something like two months delay 3.59 sir so maybe for that reason i have strong preference for rlp i thought that you were talking about 2718 in general but uh yeah f2718 is bundled with one five five nine like it has to be with one five five nine then i have strong preference for lp i generally have a preference not to bundle eep one five five nine with two seven eighteen wait you you want uh one five five five nine without 2017-18 ideally yes even though 2017-18 was going in berlin as i say i would like to keep uh ip1559 separate from the berlin discussion building discussion can be delayed massively i mean it's it keeps being delayed i want to keep ip1559 totally separate if possible i mean uh obviously if you have 19 already deployed then it will be yeah okay okay okay yeah so it's i'm like 98 sure uh 2017-18 is going to make it into berlin um and so which means that we'll want uh 1.59 to be 27 18. and if 155 27 18 then we have to decide whether we're going to do what we said in court devs which is talk about ssc again after berlin and it's gonna that means that discussion is going to be around one five generally target a1559 before berlin and this conversation i would keep it like we don't have to think about berlin because berlin might be delayed i mean i i see what's happening there and there is uh every chord of call we are adding one or two issues that are highly contentious recently like as a zero p is uh it will take time the a2718 it will take time and people are not on board and they don't feel like there is so much of a push on berlin so i would just uh keep it separate i mean uh on the burning calls like all core devs i'll be pushing for berlin to happen as fast as possible on the ip1559 calls i would aim at pushing for ip1559 to happen as fast as possible um and if both of those attempts are successful who can come very happily together with everything in place but i wouldn't like them to wait for each other oh i think i see yeah i think that that makes sense i i suspect that like we're we're coming towards the end of berlin and there's like a very high probability that it's ready to ship you know before 1559. that might be wrong but assuming assuming it's not i think then the like path of least resistance is adding 27.18 for 1559 because we'll already have 27.18 in the code bases to handle 29.30 uh and not doing ssz because i think for ssz like peter from get's point last call was we should probably do it on devp2p we're gonna find bugs if we do it at the you know networking layer we're gonna fix those bugs that'll take six months nine months and then you know maybe like once that is done we're ready to actually move it into the protocol or consensus layer um and i think that's i think that's fine uh so i yeah and if for some reason you know there is a decision made on all core devs that we switch everything to sse now then like you know we'll have to do it for 15.59 but i wouldn't want i don't want to take like the path that's like opposed to all core devs like if everybody's switching to ssz you don't want to be like rlp and then slow things down and vice versa i don't want to slowly run down because we want to do it yeah yeah i mean when i say there is no preference for us as zrlp it's because i know that we already have it right but also know that uh implementing ssd and understanding it and testing it took me proper time and it was not a trivial task and i think that there is no chance it will be faster than like a few weeks on on guest site to properly test it and implement it into the code base even if you have libraries for it i mean okay unless unless you i'm maybe i'm not thinking about the fact that prism has the go library for ssd and it might be more general like because our approach was a bit more like optimize and make it not so reusable so it might be that the prison library is very reusable um matt i was under the impression that you were currently working like with the guest team together on 27 18 could you maybe give like a very brief summary of what your take day is what what do you think what's what's the timeline there what how does that side look i mean i feel like berlin is locked in it's just a matter of getting the client test that's tested and decide on a fork block i really think this is going to happen in the next three months which i believe is still going to be far ahead of 15.59 i think the original point for the question though was just discussing like we decided to go with rop over sse for the berlin hard fork and this is a discussion that is going to come back up after berlin because it is a desirable thing uh to have ssc of the protocol and unfortunately the more things that we add in that relies on rlp the more complicated it may be to do sse at some point how how like how much of luck inward would a decision for one for on the 159 side for rlp but as a cb so let's say we go with rp for now but then it turns out that maynard will already like we'll will basically want us to or will one one five nine two to arrive with ssc instead like how how how much per delay would that cause on the one four man side uh yeah i don't really have a good feel for what and like what it would take to like you know transition 1559 time from rlp to ssc i think that generally we have complete control over these things in the protocol the one thing that we are introducing as like an external api is how we sign 1559 transactions so if we sign those with rlp and and by switched ssd that means we also want to change how we sign then that's something that would be very difficult to change because we would already start having wallets and external providers adopting that exciting mechanism so when you when you say ssz you mean even serializing transaction objects with versus z but it's interesting yeah serializing transaction objects and using the verticalization functionality to create the roots in the block that's a very big change it's a big change because it is affects the like all the web free components all the smart contracts that's this will be like a massive delay if we if we go for it and they you know now we already have a method of expressing keep one five five nine transactions in a traditional sense with just like two additional fields and i feel like this change is far far from being significant for adapting the current processes so yeah yeah like ssc would be one thing that would probably delay e1559 the most from the current state of things yeah so i think i would very much agree in the sense that i think 159 should not try to to basically be be taken as an opportunity to also push ahead other changes with together with it so there's no reason why 159 should also try to push ahead as i see right if it's ready and um as the z is not then yeah of course we that shouldn't be part of it we are in the unfortunate kind of position of course to to have to make basically like preliminary decisions on what we assume mean it will expect from one five nine once it's ready um and so i don't know i think i think we basically have to try to to keep like the effort minimal but it would kind of take either way to to to to walk back on this decision if it turns out that we made incorrect assumptions so i don't know for example for me right now seems like the max the maximum likelihood situation would be that we arrive after 2017-18 but before ssc but of course could be could be either way it could be like that we arrived before even 27-18 i don't know seems unlikely but but possible or even after ssc again and and and in all cases of course if that delays 159 by months that's not a good place to be so yeah i i unfortunately don't really have have a good solution but but yeah that is important to kind of keep them so the reason this keeps coming up is because while i agree with uh i forget who just said it that it's better to not bundle things like get ssd in first and then switch transactions over to it um historically that has never worked with ethereum that i know of the problem is is there is a a subset of the coordinates who do not like including changes unless they are needed for something and so adding ssz before ssd is needed there's a good chance that means we will never get ssc in and sse is by itself gives us a lot of big wins down the road which we would like to have but we can't get that in until we have something to put it in with and so no matter what i think that if we want ssa to go in eventually it has to bundle with something and to stress the point that my client made the longer we wait the more painful it will be to to do that because we'll have more and more stuff uh particularly more and more things that are being signed by third party tools and i guess before that's kind of a core devs discussion though because there's not just 1559 involved here right like for example there's account obstructions is the other one right like so so there's like this meta problem of like yeah where's the line for ssd where do we want it to be and for sure wherever we draw that line is gonna slow down every other feature by like i don't know call it three months optimistically right and and but but yeah i i don't think like we can do much at the 1559 level to change that right like we can say you know on the core devs called this is the stuff we maybe want before or this is the stuff we absolutely don't want before because you know it'll be such a big piece of technical depth to to deal with that it's not worth it um yeah but because it yeah it just feels like there's there's so many things that are coming in that might touch that that we we probably want a higher levels solution than just do we do 1559 or this with sse or not yeah that's sir i'm okay with not not discussing here it sounds the gist i got is that people are very hesitant on anything that will delay one five five nine and i generally share that sentiment and definitely appreciate it yeah um just my perspective from trying to deal with some of these things and i know this is just coming from an opinion place nothing like a knowledge or a fake place but that there probably will be something that needs to do what you're saying micah but it probably shouldn't be 1559 to do what exactly uh to put the we need ssc for this they'll probably be something where we kind of have to decide that we need it even though technically we could maybe not need it the e2 verge yeah but then about 1559 would it shouldn't be the one to do that but we it is a good idea to be thinking about what should be in the down the line yeah but let's let's keep it then on the old core devs like yeah yeah our goal should be to deliver ip1559 and i think the best thing that we can do is to ensure that it's ready and tested for any of those scenarios like whether it's with 2718 or without whether it's with ssd or without and we have one solution that we're testing without those changes and it means that we can move it all the way to the end where we have already tested with all the clients saying we are capable of handling keep one five five nine and this is the spec that we are working with so the um people who build tools can already start adjusting their tools and we can we can show them also like two alternative paths that uh here is the simple path now this is how you have to adjust the tools and these are the alternative paths uh pay attention to what happens to 2718 pay attention to what happens to ssz because maybe you'll have to adjust those tools a bit a bit more depending on whether those go before but people will be more prepared they will already start looking at it implementing first version and i think overall everything will go together faster yeah that makes sense so tabling the encoding discussion for now um was there uh i guess barnaby uh thomas uh and anyone else or ramil do any of you have updates you wanted to share so they for because i think that we're planning the next call for 14th of january so i spoke to mikhail a lot recently and he was working on this analysis of the potential attack scenarios when you like not really attack on the network in general but just the attacks where you uh slightly modify the base fee and this is because we are exploring like the the cost of manipulating the markets if you introduce the gas markets to the equation and here's the lot of results already calculated with various different network parameters but was not ready yet to share it today but he's very confident about sharing it on the 14th so so be able to look at this jupyter notebook numbers and all these charts and and show you actually how it behaves when you want to push the prices down or push the prices up that's really cool yeah looking forward to seeing that i would like to share update about pull request uh in the guest so we review with the comments uh and um yeah from abdel hamid and uh we are going to start working on the on it on monday cool that's great um and i think yeah once uh uh i guess once those are addressed it might make sense to get like a more you know thorough review from the get team i know that like uh basically the quilt team has has shared it with them and but i think once we have the code in a spot where like it's up to date with the latest spec um yeah it'll be valuable to get their their thoughts and i think one one thing uh i believe joseph you shared this with me uh was that the get team would like to see it kind of split up between the consensus changes and everything else was that right yeah yeah yeah to if 1559 could be um yes um phased in two phases yeah one with consensus just the consensus changes and then the second one where the mempool changes and you know other non-consensus changes would be that was a suggestion from martin yeah just just to clarify of course and and and of course that that's what what you were saying as well just but just to clarify so so it's not not of course about like like an actual two-phase approach um but it really just is like a logical structure split into two pr's so they still would have to arrive at the same time and are dependent on each other but but um but yeah [Music] i guess remember what's like the best you know does it make sense for you to do that now do you want to rebate do you want to like address all of like the spec level comments first um yeah i think whatever you think is best to get to that spot yeah so i think uh yeah so we will uh update to the uh lattice spec uh version again yeah and uh yeah okay and then yeah we can look at splitting yet yet into gprs yeah actually it's not clear for me for now 100 how to implement that splitting but i think we can discuss it later on the chat cool yeah that makes sense um anyone else had updates they wanted to share i just shared on the chat paper that my co-author has presented in a workshop recently it's uh it's very preliminary work but it's kind of looking at 1559 as a dynamical system so trying to get some ideas on how fast it converges what are the let's say guarantees that we can find and uh perhaps using that as a springboard to look at the more controlled theoretic questions of uh well how fast should the updates happen i know tim you've sent out a call to people who might be interested and i think this work might be interesting to them as well and what i discussed also two weeks ago is a follow-up to michelle's notebook on the transition i have a pretty final draft just getting it the last review and i'll be ready to share it either end of this week or next next week nice cool anyone else have updates um if not i'll just kind of share my screen real quick to go over to check this but i think we've covered a lot of it uh already um so just at a high level in terms of implementations uh you know same teams are working on it uh open ethereum worth noting that they have a job posting out to hire somebody full-time to work on 1559 so if you're a russ developer and you're interested in working on 1559 please apply uh to it's opposing through gnosis but to work directly on open ethereum um aside from that uh so just in terms of the open issues uh denial of service risk uh actually i've been thinking about the dos risk more and i suspect that 1559 might make things better and not worse and one of the reasons for this is that today on the network um if you if you just spam the network your cost is constant for doing so like you and if you're like a miner deciding to dos the network you know you can include your transactions kind of for free in your blocks um whereas under 1559 what's nice is like even if you were to spam the network and aim to not increase the base fee to keep blocks just 100 full um the rest of the demand for the network will will mean the base fee increases and that means your attack will get more expensive over time um which is a property we don't have today and also it kind of blocks that hole of like miners being able to dust the network for free um so coupled with like stuff like 2929 and you know just clients being generally more resilient towards uh like the large states i think like it's not as big of a risk as as as it might have been uh um thought to be um so yeah let's just quick update there it's not formalized at all but it's just like my intuition of how it would play out yeah so team it's exactly what what mikhail was working on he was analyzing the cost of attack when you want to spam and uh make the network make the blocks uh field by just publishing transactions with very expensive transactions and obviously very quickly all the rest of the network stops including their transactions and you're the only one who has to pay for that like today just just to share some of the results that we've seen like the raising base fee from 50 to 500 um required some like um pretty solid uh participation of the miners like at levels of around 40 to 48 percent of total mining capacity and it was with some some ranges of success ratio like between zero one and zero two so twenty percent of success with cost of around half a million dollars for 10 times increase in gas prices so yeah the pushing pushing it up was quite inefficient quite expensive but also like it would be great to see how the network behaves if miners actually do not participate in this kind of attack but people actually push the transactions yeah looking forward to seeing that but yeah i think i think this was like i guess for me the biggest showstopper potentially for 1559 and and i feel like we're heading to a spot where it's it's not a major issue anymore which is great um so transaction pool management we already covered this uh so i you know we're working on the solution i think we should be good there the base fee update rule uh so like barnaby just said i've been reaching out to different people to see if we can improve on it i don't think this is a blocker for 1559 so worst case we just ship it with the current update rule and if somebody takes a year for somebody to spend time to come up with something better we'll update it in a future hard fork or when we go on e2 but it's not a blocker um in terms of testing we haven't made a ton of progress there but i think it'll kind of resume once 1559 kind of visit more of the all core devs process rather than this this side track uh but and and we wrote abdel i say we but abdel wrote a couple of heaps for the json rpc spec and you know there's more to do it's not rocket science it's just work we have to do but i don't think there's a ton of value in doing it now because of uh yeah just how early it is um and in terms of test nets uh basically i think we're combining these last two into one and that were the last two things we haven't tested so just like a multi-client proof-of-work test net and then a large state test net so if we can we can get the two of these done that'll be great um and it feels like in terms of r d you know there's a lot more stuff that's going to be coming but i i feel like tim roughgarden's analysis was like the last big blocker that we had um and now you know i'm pretty confident we've we've done more analysis of 1559 than probably any change that's you know gone on to the network um and they all you know modular some small issues everything seems pretty positive um and finally just in terms of community outreach uh we've been a bit slow of doing another kind of round of feedback i think personally i would do like maybe a more aggressive round of like reaching out to projects once we have another test nets that's like more usable and that we can point people to and and have some documentation for it um yeah because in the meantime it feels like the main thing people were asking us on these calls was like when can i try it out how can i try it out so um i would just wait uh another few months until we uh we have something a bit more uh stable that we can share and uh yeah that was the last thing on the agenda um the next call i had temptatively put january 14th because i think it's yeah we have an all-core devs call on the week of the eighth so it's it's the off week from that um does that generally make sense for people yes cool anything else anyone wanted to discuss or bring up okay well yeah thanks for making the time everybody thanks bye thank you cheers