| Item | Action / Decision |
|---|---|
| 9.1 | Schedule another call in a week from now to do a performance test with Geth Nethermind and Basu to fix the bugs. |
| 9.2 | Tim will engage in active dialogue with miners. |
| 9.3 | Be clear with that decision and set expectations with the community. List objectives, hypothesis, changes brought and get feedback from the miners. |
| 9.4 | Micah will be creating a PR |
Tim Beiko: Okay we are recording, so hey everybody this is EIP 1559 call # 9 Which feels like a lot. So I shared the agenda in the chat. We have a couple of things to go over today, a few updates from different folks and then going over kind of the large state testnet, testing and yeah that should be it. Ansgar I see you are on the call and I think you had to head out early so do you want to start with your updates
Ansgar Dietrichs: I do not think I fit out early. I think that must have been someone else so. But I am sure to go first but it sounds like maybe someone else has to leave early or something.
Tim Beiko: Does anyone else do.
JosephC: Just go ahead.I may have mentioned it to Tim.
Ansgar Dietrichs: okay I think that might have been a scheduling conflict but I kind of moved the other thing. But things are okay. So sorry and no but Ii can go ahead. So basically I linked like a little document. Again that was kind of the follow-up of the previous one. I had maybe two months ago, exactly that's the new one. I think that yesterday I am not sure it was a little bit late if people had the chance to to have a look. So I have been thinking a little bit more about like specifically the sorting aspect or like the sorting aspect in in clients for 1559 transactions and in basically as it said in the TLDR in the beginning, so basically when I first started thinking about it just because I didn't really have a lot of background in 5059. It looked very much just like now you have two parameters right, the maximum total VCAP and the maximum minor Price and and basically now you have to sort like in this two-dimensional space and with all the complexities that came from that. And kind of re-evaluation every block and everything but the more I kind of looked into it. To me it seems more like that it's really mostly about understanding kind of the very specific structure of how 1559 will affect to transactions and kind of optimizing the client around that so, what I mean by that is basically if we look at like the mempool under 1559 in like a normal situation where it is not one of these extreme demand spikes that might be the rare kind of um exception to these normal situation. But like in any normal situation you usually only have a handful of includable transactions right? Includable transactions mean that the fee cap of the transaction is above the current base fee. The reason why you only have a few is basically mostly by definition right because 1559 in the steady state blocks are on average just the target size. So,they might be a little bit over a little bit under but on average that they only target size and miners always include as many transactions as they can upto twice the size. So the fact that this blocks in the steady state are only like one time the target size. Basically already indicates that on average a miner that creates a new block only has enough transactions to fill one time. This target size basically and so in the mempool base of course that means that usually the vast majority of transactions are actually not includable at the current price and which is probably a very trivial observation. But it took me a while to fully get there and understand the implications because it actually has a couple of implications. So I think the more obvious part is for mining so of course for mining you only care about the currently includable transactions. You do not care about what might be in a couple blocks. You are mining account blocks and you need the transactions that are includable at the current block and so basically what that means is that the mempool ideally should have a way of giving you currently the includable transactions.And then I initially was concerned with really liking designing. An optimal algorithm for managing a partially sorted structure that always gives you the highest paying transactions. I think I outlined a design for that in the last document and then this. I am not sure if he or she or if they are on this call me now. The user kind of took this approach and kind of implemented it. Like an example sorting mechanism there which was awesome to see. Yeah. exactly this one but basically I think the main insight though on that specific topic is that this is probably an optimization that maybe not necessary at all or at least not necessarily in the beginning because what miners already do today. At least like well on the guest I am most familiar with the githminer but what the githminer already does is they get like a complete list of all pending transactions which I can't like before 1559 that can be thousands of transactions and they sort all. They basically sort them once per second or I think the default. This one's put three seconds or something and then they discard that and completely resort every three seconds. So basically they are doing much more already than they will have to do under 1559. So under 1559 the kind of effort for the miner only goes down and so we can always still kind of optimize but it seems like this is really like a very simple thing and then the main change that I think is actually most worth talking about for miner then is is not even the sorting itself but actually how do you handle the stream of incoming transactions because right now what the miners usually do is they basically create a block and then they start mining on an empty block. Just to be able to start hashing immediately but then as soon as they have created a block they start my switch over to that and mine on top of that block and then again with this interval like once every second. I think the default is three seconds but you can ramp it up to once every second. They basically create a completely new block right because it might have been new transactions coming in since then. So they create a completely new block , once that's done they again switch on to mine on top of that and of course you can do then a ive thing and just do the exact same thing under 1559 as well. But if you look at the specifics of 1559. You usually as soon as a blog comes in that from outside that you want to mine on top of or like that you want to mine the next one for the chain and that will probably already use up most of your includable transactions. so you'll start out as a miner with like only maybe zero maybe like a very small amount of transactions to include in the block immediately and then over time while you are mining and you have not yet found a block. New transactions will come streaming in and so then on average I do not know. Let's say every 12 seconds or whatever the average for non-empty blocks. The mining effort will be on average it will take you 12 seconds to collect enough transactions for one normally full block and then after maybe 24 again if just very simply spoken but after 24 seconds you'll finally hit the cap and your block is full actually for twice the size and so basically what you ideally want to do is you will want to just like immediately as soon as a new transaction comes in just append it to the block. You are already mining on top of and then maybe still once every second every three seconds or something you can do like a reorg where you resort them in some other like by some other metric which doesn't really matter for the miner but maybe for the network as a whole it's nice if they mostly kind of prioritize higher paying transactions even within the block still or something but basically there is a pen, there is immediate append action that's not done currently in geth and that is something that I would propose to that should probably already be done as part of like the initial 1559 implementation. It is even that part of optim optimization. There is optional and then again for the broader sorting side for mining. It's really simple. I would say maybe before I go to the other big topic the eviction. Does it make sense? So far is that done? I may have something backwards there also.
Micah: I think that will make sense. One thing I would say is I think first in first out is actually slightly healthier for the network than price based. If there is no contention and so my vote would be until the block is actually full don't bother resorting the transactions. If we have no need to do it. It doesn't help the network really. I do not think to sort by guest price because I just think it encourages more gas price auction stuff whereas if we are doing FIFO most of the time gas price elections become much harder and much less profitable which is kind of good because cash price auctions are not the healthiest thing. They are a thing that we deal with because we have to but it would be nice if they just kind of went away and so my vote would be if you do not have a full block just do first. First step like you said just depend only until your block is full. Then once the block is full then decide what am i going to kick out of the block and then I have to rebuild it and then at that point sporting might be the easiest way in which case sure go ahead and sort but my hope is that if most blocks are not 2x full then we can do basically FIFO miners still gets all their payday. We do not encourage this behavior of people hammering the network with gas price wars basically.
Ansgar Dietrichs: Yeah and of course I mean that this is a little bit tricky because for miners these guest wars might actually still be preferred. It is beneficial because that drives up the mine upright but I think at least right .We still need the functionality of the resorting as you were saying to use as soon as we reach the actual 22x cap.So I think it probably would not hurt to at least expose it to minor so they can optionally switch and do that immediately or something. But yeah I think at least the simplest approach would really just be first in first out until you reach the 2x cup but Ii would say this can probably be left to the individual client devs to just make the decision on.
Micah: Yeah I think just to build slightly on that I think most importantly is if we have geth do person first out until two expo and other clients do slightly better sorting. It would encourage more client diversity in minors so basically it is kind of like almost not quite as good as the other miner. Also make it so geth does not do as much work to encourage people to switch to another mind open ethereum so never mind open ethereum go and make a better sorting algorithm gives miners. You know slightly better money then it will encourage people to switch to other mines of gas which I think we generally want more client diversity and minors I believe.
Ansgar Dietrichs: Yeah I mean I can see the point there. I just want to basically give the kind of counter argument that I gave in the discord as well. I am personally open on this question but I would just say I am given that 1559 is already somewhat disruptive. I think the disruptive kind of over emphasizes it but it is at least a significant change for minors already. So I think it would probably be best to kind of keep the changes or yeah that the changes to the minimum necessary to support the switch to 1559. So this is why I might think that may be changing. This might be something we should rather push than for it on its own instead of as like part of the of the overall 1559 implementation. Yeah I do not really personally have a strong opinion there. Okay but yeah So I think that this is like a general. This kind of summarizes the minor side of that quite well. I also talked with Gary from the guest team yesterday who does likely get implementation of the minor as well. Just to double check my assumptions and it seems like this is indeed kind of how the concentration is and they are actually interested in looking into how they can adapt to 1559 so that would probably continue as a conversation.
Okay then the other part again probably that also is familiar with people by now. That is of course the eviction side that is where you also need sorting to know on the bottom end of transactions which ones to get rid of. If you running out of space and there the id again if you basically look I think about this situation where in the normal circumstances most transactions will be like in this non-includable zone and then you look at those in a little bit more more closely and so one thing of course is that I think it is rather likely that clients will do something similar as they do today, with this minimum gas guest price that they enforce right and they just drop transactions that are below .So I can definitely see that happening also with the mine upright where now another 1559. If your minor bribe is below some standard. I don't know one gray or something and the transaction gets even dropped immediately by the mempool. I don't know, maybe not maybe but I think that is at least something definitely realistic and so that would basically put a lower bound on the minor bribe that any transaction in your mempool will end up paying. If it ever gets included but then the interesting thing is there's also at least some soft upper bound for what an effective bribe a transaction will probably end up paying. If it's currently not includable, if the transaction comes in and the current base fee is 100. Let us say the transaction comes in it has a fee cap of 200 right, so it's immediately includable then it could potentially be or pay all the difference there all the 100 extra in as a minor bribe that is possible. But on the low side if it's actually in the mempool that is waiting to be includable again or at all and this will that transaction even if it has like really high maximum minor bribe it will almost never actually end up paying this whole big minor bribe because it will be included as soon as the base fee drops low enough that it becomes includable. This is a topic we have to talk a little bit about how often do we expect significant drops, all of a sudden or something maybe with empty blocks? Occasionally or generally a transaction will be most of the time become incredible just barely right where the base features drop just low enough that it became includable and maybe includable with this minimum minor bribe kind of the distance but that means that most transactions even if they potentially are willing to pay 20 10 20 30 gray of minor bribe. If they are currently not includable they will probably be in the future. If they ever become includable will probably end up only paying a small minor bribe just because they will only barely become includable. Then again the question is how often do we expect significant shifts in the base fee and so this is of course the details like how small this kind of this band of expected minor bribes can be. This is still a a little bit unclear or like there are different assumptions to be made there but the general insight there basically is transactions currently in the country are not includable side of things. We probably all end up paying only a small minor bribe and so then kind of getting back to what I was initially in this first document and I think we also talked about on the call and maybe like two calls ago or something what I was initially thinking about was kind of really optimizing for this expected minor value of transaction so that took into account. The minor bribe and the chance of eventual inclusion basically but now with kind of the minor bribe kind of looking more that it's almost uniform again within this small band and it turns out that this kind of mostly reverts really back to the simplest. This is the simple approach there that we started out with. So it is basically like just sorting eviction decisions by fee cap.They're just the total fee cap per gas. This really gets us close very close at least probably to this expected value to the miner. Then of course there is still a case to be made to really optimize to go beyond that. It looks just going with a simple implementation.Here again is also just really hits this good enough for main at launch threshold so basically just have notes do the simple thing and then once we actually have good data of how does the base fee change, how often do you actually get these significant drops so basically how much of a difference is there between transactions that are waiting to be included that have like maybe a big smaller or larger maximum minor bribe. Can we maybe do some more optimized sorting but it really seems just the very basic thing. Just sort by fee cap or gas they can use all the existing implementations. so it is like a very small change it really looks like this might or this will be good enough for mainland launch basically. So that at least I feel like this is basically the one question where I also feel like and I think Barnaby you were talking about that in discord as well where we might be a really good target for some additional simulation work. Just to see under some assumptions and again of course these simulations are usually like whatever assumptions you put in you get out but still just yeah and a few different scenarios like how much of a difference is there that could potentially kind of be optimized for with an optimal Algorithm but yeah I think this is kind of my view on the eviction side.
Tim: Is there a way to like this spam proof in a way so is there a way where you can constantly raise your fee cap because if you say you had a fixed minor bribe. You know the base fee changes or whatever is there a way you can spam the transaction pool by just constantly raising your fee cap by one way.
Ansgar Dietrichs: Yeah so basically I did not put it on this document because I do not think it is like one of these kind of complex issues where there's a lot of open questions but I think for transaction replacement right with the same account same ones I think this kind of simple heuristic. I think we also already kind of talked about candidates there like the simple heuristic of. You have at least the same minor bribe and you have at least some a ten percent increase of maximum fee and if you just have that then you have a very similar situation as you have today but it's basically the same.
Tim Beiko: Okay got it.
JosephC: He wrote that in his previous doc as well.
Tim Beiko: okay yeah I just wanted to make sure that this kind of thing still holds even though this sorting is quite simple.
Ansgar Dietrichs: yeah but basically the idea that there's really just make replacement expensive or well so that you could just can't do a lot of replacement before you actually hit the includable zone. So it's basically the idea is he network is mostly just optimized like just looking at fee cap per gas for all of these decisions for eviction for replacement for all of that and then the minor bribe that's actually mainly just used then at the point of inclusion at the miner themselves for these decisions but the network mainly just looks at the the fee cap.
Abdelhamid Bakhta: I have a question. Yeah I forgot to ask this morning when we talked but basically you are assuming there is only a 1559 transaction in the pool but what if there is a mix of legacy transactions and 1559 do you what is the ordering basically you consider the fee cap to be the gas price for a legacy transaction.
Ansgar Dietrichs: I would yeah but basically just like converting legacy transactions to this kind of 1559 format where the maximum minor bribe equals the maximum total fee and that shouldn't be because again either they just get included immediately in which case again they only have the issue that they might overpay. Which is just like the kind of the trade-off there or they end up in this not immediately includable zone where then at the end of the day. They set this high max mine up right doesn't really matter because most of the time they will end up only paying a small one . Anyway so then they kind of more similar to the to the native 1559 transactions then basically initially.
Abdelhamid Bakhta: Okay that make sense.
Ansgar Dietrichs: But yeah what that means basically is I would strongly argue that memphis should immediately just implement full conversion of these legacy transactions and not have like two separate mempools I don't think there's a case to be made yeah like really keeping two separate mentors. one question that I was just having was do we have I am not that familiar with where all the participants.I guess so the question was just do we have someone from like some of the other clients. I have already talked to Abdel about the situation with Besu but I would also be interested in how about other clients. It is basically the implementation they are also kind of compatible with what I outlined here. The other aspects that I did not think of that might not need adoption. There adaptation I mean but I can also like that was like the one thing that I still wanted to do was just reach out there and see if there's anything i wouldn't expect. It seems or rather straightforward there but just to double check.
Tomasz: At the moment the implementation is just taking very similar behavior as before, sorting the transactions by the value for the miner and so I am listening here but it is the final plan for the sorting. You think that this should be implemented in the clients or from the very beginning when we were talking about sorting in the transaction poll. I am thinking this is not part of the consensus which means that it can always be implemented differently and according to the miners requirements so long as this is most beneficial for miners. I think it makes sense and it'll be stable but if it's not then people start replacing it with whatever is most beneficial for miners. Right?
Ansgar Dietrichs: yeah i mean um so i definitely agree that it's not consensus relevant and so i think it's really just important that there's one good enough implementation that everyone can basically fall back on. If they do not want to do something of their own. I was just curious then. If you when you're saying optimizing for what's most the value for the miner. what so like to say any transaction that you're looking at that's currently not includable. How do you calculate the value for the miner there because I am not.
Tomasz: When you say not includable you mean by the fact that the base fee is above the block level right?
Ansgar Dietrichs: exactly yeah
Tomasz: so it is just a question whether you want to keep some of them in the transaction pool while they are waiting for the return on you just keep evicting them. So I know that we want to keep the transaction pool minimal and keep evicting the transactions right. So I think for us it may be even configurable by the miner. So do you want to be a victim or you want to keep them. Then the question whether you want to propagate them when normally they would be evictable probably not if other clients would evict them anyway then you just don't propagate them and keep them for the miners. So when the base fee goes down they can include them. This makes sense from our perspective but I want to read this much more in detail. What you wrote and like now if with the approach that we have probably will start suggesting the users to pick the implementation of the transaction pool one of a few and a behavior so parameterize it.
Micah: one thing we have to keep in mind is that while not technically part of consensus a the various clients do need to have an agreement on what criteria will cause you to drop up here and so we do need to make sure that we do agree on at least that part.So if You have got some threshold where you're like hey you're spamming me now. I am to drop you, we need to make sure we're all kind of all the clients are in agreement that what the threshold is. We make sure we do not have one client that says no this transaction's fine or another client's no that is spam and I am going to disconnect from you. That is what we do. We don't want to take a consensus but something we do need to agree on before lunch.
Tim Beiko: yeah and I think that is almost like more of you know kind of an all core devs conversations in a way to me. It is a threshold we need to agree on but it is not gonna block anything.I do not think we will ship or not ship 1559 based on the value of that trash holds.
Micah:I was going to say something to keep in mind is that we always talk about how if there is a better mining strategy for miners will switch to it. We actually have many years of evidence that suggests that is not actually true. Miners seem to be reluctant for unknown reasons to actually write code that changes their clients significantly. We see that because it has been massive for years now there is a massive opportunity for miners to take extractable value from d5 and no one has until the mbb people basically came in and did it for them . So if we have a transaction sorting algorithm that is good enough and well technically. A minor could do something else. Our evidence suggests most of them will not and going back to the first in first out sorting, if most miners are doing first in first out then it becomes very expensive to do gas price auctions because most miners will just ignore your gas price or and we will just include the person first out. You will waste money so even if some miners defect and write their own clients that are more optimal. It would not likely affect the network and people would not leverage that because you can't leverage it unless all the miners do it. So just keep that in mind that while theoretically game, I 100% agree miners should be optimizing these things, our evidence suggests they don't for whatever reason.
Tomasz: But I feel like we want to treat, monitor miners into using something potentially suboptimal and It is okay if you do
that as a particular client implementer and it is your decision but to try to spec it which is against game theory and say okay. So we will
just do that because no one will implement their own solution. I would leave it to client implementers saying this is some suggestion for
EIP 1559. It is not part of consensus you can do that whatever way you want. If some other clients will drop you because you propagating
transactions that are not nice for them and obviously, you will adjust because you don't want to be disconnected from the network and
there will be some clients that will have a bit of more to say depending on their network participation rate right so the market share
Abdelhamid Bakhta: well that is the plan, all of this is not part of the specification. It is a set of guidelines, it is a soft agreement but yeah you are not obliged to do so.
**Ansgar Dietrichs **: Just to briefly clarify this kind of does not propose any kind of rules that are like purposefully suboptimal for the miners. This is all kind of trying to optimize to just sometimes maybe prioritize simplicity over optimization but it is at no point again this was just like an additional proposal by michael. We were talking about how we could maybe get some decisions specifically even more simple or something but in general this kind of no place, kind of purposefully chooses the not optimal.
Tomasz: Yes I was referring to the Micah suggestions and some of the Dietrichs was also suggesting before but the way trying to decide for the users how they should treat the transactions in a transaction poster. I prefer the solution which is based on suggestions where we discuss it but not try to enforce it among the clients. Just say okay so we discussed it. This is how it behaves as that works. This is not damaging.1559 but we do not want to spend too much time on it because it delays us in the actual implementation that is how I see it and it is super useful for analysis and something that I read with pleasure. I am just here saying that we won't be necessarily saying that it is exact in the way we implement it. We want to keep that freedom of saying okay transaction policy outside of consensus logic, so we want to be able to do something that will decide will be most beneficial for users.
Micah: Yeah and to be clear. I definitely do not think that we should force anyone to do this. The reason I bring it up is just because one of those things where if we all happen to own our own right clients that do first in first out. I believe that will be healthy for users of the network even though it may come at a cost a minor cost to minors and so it is one of those things where we can maybe opportunistically get a free win for users and to me that is something we should maybe think about and try for. But I definitely do not think that any client should be forced to follow the strategy. It is non-consensus just a hey you know if we do this thing maybe we get a free easy win and if we don't then it reverts back to you know what we're gonna do anyways. So it is not a big loss.
Ansgar Dietrichs: Although just to mention I personally I am not sure fully about that because I do think that this would then in turn just incentivize, kind of side channel communication with miners directly to basically pay for positioning in the blocks directly which ends up being the same thing just with more friction so but yeah that is a good argument.
Tim Beiko: I guess if we take a step back, I think the reason we wanted to do this work. There were concerns that we could not find like a suitable way to sort the transaction pool that would be kind of spam proof under 1559. I feel like you know we're definitely at that spot now where you know we have at least a solution that would not make the status. You know significantly worse or cause like a security issue.I am pretty satisfied with what we have right now. If different clients want to do different things or if we all align obviously has all like it's you know own set of trade-offs but I feel like with regards to the risk that having 1559 introduces in the transaction pool for dos vectors and things we're in a pretty good spot with this right and then if different clients again want to tweak it. I think that is a separate conversation. I guess maybe my question is does anyone feel like there's something more that we need to help justify that like 1559 is sound and safe. That is not being presented here.
Ansgar Dietrichs: I mean sounded safe under this aspect I am generally convinced that it sounded safe but of course this this only covers the kind of mempool sorting side of things
Tim Beiko: Yes and then you know I think we mentioned earlier like we will need to discuss also like how the clients want to do peer management and stuff like that. I think to me this was like the biggest potential risk with 1559 if we efficiently sorted the mempool.Can we manage your transaction pulled without it becoming crazy and yeah I am much more confident in that now. The rest kind of feels like an implementation detail at this point right where we can have long drawn-out conversations about that. It is not going to be a blocker for the EIP.
Ansgar Dietrichs: Yeah that makes a lot of sense to me.
JosephC: especially when the block is not full sorting still has a cost. So you know by appending only the miner might already find a block in that time
Tim Beiko: and we see that on the mainnet already. Right like with empty blocks that get mine. So I am fine with like you know we don't need to solve all of the inefficiencies of mainnet to deploy 1559. we just ideally have to not make any one aspect significantly worse.
Micah: Yeah I am with you. I was a little bit worried about the sorting algorithm not worried like a blocker. Just worried it was going to be hard but that this research has convinced me that it's easy.
Tim Beiko: Yeah same and yeah again like I think you know thanks a lot Ansgar for this. This has really benefited from having somebody who's like actually spent time thinking through it deeply rather than as a side thing on top of everything else. So yeah this has been really helpful.
Ansgar Dietrichs: Thanks but just briefly by the way to mention because I have it under further questions. One thing that I realized like dealing with this is just I think at some point but I think that it's not necessary before we launch on mainnet but I think at some point it's probably also like a good idea to to to get back to for one to just the aspects of what are the kind of the things that might also at some point change with ETH2 right because we will probably just want to move this 1559 over and also use on these two.But that is of course a little bit further in the future but maybe I don't know that it might just be that 1559 only ships half a year before the merge or something. So this might become relevant quite soon. Then there is one specific topic so how can we maybe long term that doesn't have to be in the first release but long term. Keep the base fee a little bit more smooth and stable even under like the kind of distribution of block times right. Right now what will happen under 1559 is sometimes you have very quick blocks and that means that they are either like the second one is either empty or almost empty and then the base three will drop quite a bit or sometimes you have like very long time periods and then that looks like congestion, so basically then the the block will be twice will be double doubly full and so that there could be arguments to maybe at some point time adjustments as well or something that also takes into account the time. Since the last block or something. Again I think all of these are definitely not necessary for the first version. Just things to keep in mind.
Tim Beiko: Yeah I agree just in general that came out in the timber off garden report that like the base fee update rule was simplistic to say the least and it is probably not a blocker to ship it right now. There is definitely some room for improvement there and I suspect it would be helpful to have actual magnet data before we were to tweak it because what we have right now probably works but it is not optimal and it's kind of hard to make assumptions about what the usage conditions will be before. We actually deploy it.
Ansgar Dietrichs: Agreed!
Tim Beiko: Cool just because we're uh about halfway through already. I want to make sure we get to the rest of any final questions on the transaction Pool sorting? okay thanks guys this is really really good. Abdel do you want to give an update on the large state test nets and where things are at and how this could work with other clients. I see that you are chatting on discord.
Abdelhamid Bakhta: Yeah I will give some precisions about that okay so should I just give my update and the demo later or I will do both at the same time.
Tim Beiko: Let's just try to focus on the Large state testnet for now.
Abdelhamid Bakhta: Yeah okay, So basically we have a large state test net the idea was to have something comparable to mainnet, so We managed to get a test net with 100 million accounts and 100 million entries in the state storage tree and yeah the problem is that we use the Besu specific feature which is to have a fixed difficulty . I forgot to ask if it was supported in Geth and Nethermind and it seems it is not. So I was asking basically Ramil that if he would be okay to hardcode it for the test net and I am also talking with Tomasz about that in the discord channel but yeah basically that will be the only trick, we would have to do in the code base to make it work on the state and again if it would easy to generate the test net again. I would restart with different parameters but it will take two weeks to get the same state size. So I would rather hardcode the fixed difficulty value in the code rather than delaying the performance tests.
Ramil Amerzyanov: Yeah we are working on it right now and we made some. Another issue with base fee calculation, so we are trying to investigate it and so it is in progress. I will write some updates today later.
Tim Beiko: okay nice and Tomasz would that work for Nethermind, the hardcode the difficulty like that?
Tomasz Stanczak: I am just implementing it now actually so we need to block handling and there are a few questions on this card. So I want to clarify how to get it ideally. I would start syncing it today.
Tim Beiko : How long does it take to sync the test net?
Abdelhamid Bakhta: Well it took roughly like something like maybe two days with Besu with a full sync obviously yeah I guess.
Tim Beiko : Yeah my the reason I am asking is if then we want to do this kind of performance test would it make sense to schedule another call and do that. synchronously with like you know all of us or not necessarily everyone here but Geth Nethermind and Basu and I don't know it's like a week from now good enough to fix the bugs and yeah be ready for that or yeah because it feels like I don't know it might be easier to do this type of testing if we are all on a call together.
Abdelhamid Bakhta: Yes maybe yeah we can just default that once the nodes are synced. Just I can submit a single transaction just to verify the consensus rules and then we can plan a call to do the actual performance test. If that makes sense?
Tim Beiko: Yeah that works for me Tomasz, Ramil do you do that work for you guys.
Ramil Amerzyanov: yeah
Tomasz Stanczak: sure any time. I will be targeting today for the producing start. We will see how it goes.
Tim Beiko: Cool yeah so yeah and you know, so if we get them fixed you know today or tomorrow uh they sync over the weekend then you know early next week we can probably have Abdel just send a few transactions to make sure it all works and schedule something for like maybe the same time next week or something. I will follow up on discord about the specific times. I think that to me this is like the last kind of big test thing we need to do in 1559 and if we can get that done that's pretty good. I have something else that's slightly related. Just want to make sure there are any other questions or concerns about the testnet?
Tim Beiko: okay uh yeah one thing I will just share my screen Vitalik I asked him to do this a while back and he did this week which was great,so the main reason for doing this test on the large state is like the fear that the large blocks cannot be handled on main net and Vitalik wrote a small explainer like why he thinks this is probably not even a problem. It is quite short. I like to encourage people to read it but at a high level. The biggest risk is knowing clients maybe cannot handle 25 million gas blocks and then if why wouldn't we just double the block gas limit and have them handle 25 million guest blocks all of the time rather than just doing 1559. He basically explains why that is the case so there is like three reasons why we cannot, just increase the gas limit a ton. The first is obviously the average block processing time will increase. If all the blocks are much bigger the second is that the risk of denial of service attack increases, if the biggest block is much bigger and the third is the storage size growth rate will also increase. If all the blocks are bigger and one thing that is the first and last of these are really only impacted by the long run. Average block size rather than the maximum block size. We see on the network, so that means you know even if we can't do those three things given that 1559 doesn't increase the average block size significantly but only kind of sublot from time to time. The only issue we have to worry about is the second one and then you know there are a few arguments why the second issue is maybe not that bad at all. The first being which is going live into Berlin will help compensate for some of the dial of service risk based on storage access. So I think this is a very good point and also kind of a reason why it would be pretty complicated to ship 1559 before Berlin. So having 29.29 helps with denial service protection and then the second argument is that obviously if we have a short-term denial of service it is less worse than if we have a long-term denial of service and 1559 actually helps here given that the base fee increases. When the gas uses more than 100 in the blocks this means that the cost to sustain a denial of service attack on the network kind of goes up exponentially with time, so you know realistically attacks could not be very long and that means that you know even if you could create a denial of service attack. You are almost in a better spot after 1559 than we are today. The cost to do this is kind of a fixed cost and then the third argument is that the block creation process itself. Today is poisson distributed and that would lead to having 2x spikes twix bikes happen on the chain roughly once a week just by randomness. This one I think is the one that is like the least fleshed out and it would be interesting to see data for the first two arguments. Yeah 1559 is like a net improvement over the status quo and the risks are probably pretty minor. So this is not to say we should not do that. The performance test I feel like we are basically there but it's really good data. I think to show that even for whatever reason. We can't sustain for like an hour a very high load or whatever 1559 probably still isn't a major denial of service risk for maintenance.
Tomasz Stanczak: Generally think that from an eip 1559 perspective the one thing that we should do now in parallel to the final testing and implementation is just to ensure that there is** very active dialogue with miners** about when the change will be introduced. What is their current stance is? They still have some concerns they would like this to address and some clearly tell the community. What the decision are the core devs trying to go against any minor concerns, is there any compromise. So how exactly the transition will look and all the miners the majority of miners, what they say about the transition process?
Micah: It is a giant can of worms.
Tomasz Stanczak: Yeah if you don't open it now it will open itself.
Micah: It already has I don't know if you hang out in the east or 1559 those three channels and then also on the youth research. If you subscribe to that there's like I don't know three new people a day that show up and complain about their fees going down with 1559 and we tried to talk to them so far. None of them have been able to formulate a solid argument besides I want to get paid more like that's the kind of the route that I have derived from most of them. It is just like I want more money. There are some other arguments that they make that they're worried about or they claim that mining will centralize in China but I think that was actually debunked earlier. Apparently I learned I didn't know this but apparently mining and Ethereum appears to be mostly in europe. I love china which was surprising to me but yeah that's like the two things: one is I am gonna make less money I don't like that and two is this is going to lead to centralization and the reason the centralization argument is kind of reasonable is because the people.When the profitability of mining goes away. The people that have the finished margins are the ones that are going to get kicked out. The people with big fat margins they are going to stick around and the people with very thin margins are going to get kicked out the belief is this is a reasonable belief that the large mining pools have the biggest margins and the small pools or single miners have the thinnest margins and so if we do something that hurts miners in some way then or decrease their profitability in any way then the people who are going to leave are going to be the thinnest margins. Therefore the non-pooled people are the non-like farm people and that can lead to centralization. I am not really worried about that because of the ethereum's price volatility. I think it has a far greater impact on that than 1559. That is my suspicion and we already have to deal with that. That is just the nature of mining is that it tends to centralize over time.
Tomasz Stanczak: Maybe the last one sorry go ahead so maybe the last three searches. We want to have on paper the analysis of what exactly is the expected. The hash rate drops based on the responses from miners. Do we lose big miners or do we lose lots of small miners. What will be some kind of document that'll tell non-miners, this is what you were making before this is what you're going to make now based on all the analysis and then based on that see what responses are and try to judge what the hash rate drop will be and how it will affect the security of the network.
Tim Beiko: so i think there's a there's a few challenges with doing such an analysis, the first is like people are obviously biased in their responses right it's like you know before the change goes live every miner has an incentive to tell you that they are gonna drop if it goes live and then if it does they are not like bound to that. I think the other challenge is we don't know there is no good way to model. How much their revenue will decrease because we don't know the amount of high tips that people are willing to pay for things like arbitrage and what not. So it could very well be that for most transactions the fees go to barely anything but for the highest paying ones. The fees still stay relatively constant and those were a majority of the transaction fee revenue anyways. I think with regards to the security of the chain. A few things worth noting is like one ethereum is still like by far the largest GPUchain and I think that would probably still be true, if we lost even a large amount of hash rate. It might be worth finding out exactly how much and that is probably the biggest risk. We don't want to be the second largest GPU chain because then you open up a bunch of attack vectors. Then the other challenge is the hash rate is at an all-time high. Right now which makes it obviously less profitable for miners given the increased competition and it's hard to predict how the hash rate will evolve because there's more than 1559 affecting it right. There is 1559 obviously but then there's the price of ether which is a big factor and there is also the willingness to pay high transaction fees which is mostly fueled by d5 right now. So I would be very uncomfortable providing an estimate and having people make their decisions based on that because it is such a dynamic thing.
Tomasz Stanczak: Yeah so for estimate it makes sense but maybe some just this kind of clear communication of this is what we expect. To be the effect of the change on miners and this is just to inform community and these miners are saying this maybe collect like are there any miners that're saying they're going to join because of that change. If the market changes even as those statements might be biased. As you say at least informing the community. What the collected opinions from minors are and what their stated actions are so the community can prepare for uh like to be to know at least whether to expect the turmoil or to expect the smith transition.
Tim Beiko: I can definitely look at it trying to collect some statements and just list the general changes. I guess you know the like philosophical argument that you like to end up with. Should miners be actively part of the ecosystem and like influencing decisions or should they be known price takers where like the ethereum protocol has certain properties and then they can choose to mine it or mine another chain or not mine at all. I think that most of the disagreements come in.
Tomasz Stanczak: I think it's tough I'm not having any statement on this one here I am just saying that we should clearly communicate what the process will be. We take the stance that even as miners strongly oppose or if they do not strongly oppose the state even as miners and mildly oppose or yeah so do not oppose whatever it is even then we decide to go forward with the change and then the community can expect that there'll be some potential risk around the change because the miners are not aligned with cordev's.
Micah: Historically it has been very difficult to get feedback from miners like you. This non-stop stream of people coming into the channels and what not complaining and saying what their opinions are but when you try to actually reach out to the big pools like F2pool and Ethermine and sparkful you get no response. It's very hard to actually talk to the farms like the farms are non-communicative. I don't know why that is but historically that has been the case. We can get people who say they are miners to show up and talk. But no one will admit to being a major farm or like a large scale fact miner.
Tomasz Stanczak: I think at least in the past we were saying that Hudson was having a channel to connect to.
Micah: Yeah he has a channel to talk to them but that channel hasn't historically not my understanding is that his channel has historically not worked for getting feedback from them. If you give them a survey to fill out ,you can just won't get anything back
Tim Beiko: I can follow up on that. We did things yeah we did get some feedback from so when we did the the first outreach, we got some feedback from miners. I think generally most of them didn't want to be identified with regards to their entity. I might be wrong some of them might have wanted but the general senses. People didn't necessarily want to be identified but I can reach out and see what people might be comfortable with and how we could aggregate their people.
Tomasz Stanczak: As the names of the mining pools that are mining blocks. They are publicly known so we can just provide at least a community saying these miners decided not to comment on the change these ones are for this ones are against and now we're just clear on that. There will be like eight or nine entities of the pools or or big miners than we see. Assuming that we can actually identify who is behind the pulse but I think this is not really a secret
Ansgar Dietrichs: Yeah I think that is important but I also think uh Tomasz had a good point in just saying that like this is something we should definitely talk about at some point on the all core devs, so yes because I think that's a proper place.
Tim: Yeah and I will try to let you know before this gets brought up on all core devs again to follow up about the miner conversation and both try to list. I think we can list the objective changes that 1559 will bring to miners. You're gonna get the tip but not the base fee. Hypotheses about how this can affect them and try to get their feedback.
Ansgar Dietrichs: But also just to be clear right the merge is probably coming within I don't know I don't want to be optimistic but like 6 to 12 months after 1559. So this is at the point at which we just sunset mining completely so yeah I think it is important to keep that in perspective. We are talking about the last 6 to 12 months of mining yeah.
Tim Beiko: Yeah but I think I like Tomasz's point where we might very well decide to go ahead even if there was say like 100% opposition for mining and just say that what other people will mind the chain and what not and that's fine. But at least we can be clear with that decision and people can expect some sort of potentially turbulent upgrade and that's very helpful for folks like say infura or exchanges or whatever to know. : Yeah so just to be clear to you I don't think that because we collect negative feedback from miners. We should like not do the change but we can make a conscious decision to do the change even though there's negative feedback because there will always be negative feedback from any stakeholder group on any large change to the network right.
Tomasz Stanczak: Yeah I am not saying here and like withdrawing from something that has quite clearly supported on the core dev channels but also not to be quiet about the lack of support from owners and be clear with the community and if we decide to say okay we're going with it even against some opposition then we have to be clear and not try to just hide it and be quiet about that so the community needs to know because it may actually lead to some potential problems during the transition. Some miners can be very adamant. If they feel totally ignored and not even included in the communication channel, so I am not saying that there will not be some heavy lobbying and campaign on twitter and so on but the more you try to hide it the more of a problem it may become.
Tim Beiko: Cool so the last thing I guess uh there were two more things I had on the agenda so Abdel put together an eip for the base fee opcode and he also had a quick demo for how to join the 1559 testnet 2718 as well. Is there anything else that people want to discuss just because we only have 20 minutes.
Micah: I would like so i would like to spec out 2718 sooner rather than later. I am not a huge fan of letting it wait but everybody else wants to continue waiting on that I will concede.
Tim Beiko: So for 2718 if we have like the test net, test over the next week or two does it make sense to do 2718 right after that?
Abdelhamid Bakhta: we can do that in parallel I think because we have the other test net to do some changes and doing integration testing. So I will not wait for the performance results to start.
Tim Beiko: Well I guess we can do it in pairs I guess Nethermind and Vulcanize can you also do it in parallel or or is it valuable to maybe just start with Besu and then add the other clients.
Tomasz Stanczak: Yeah we already have the implementation for 2716. maybe not with the latest changes that are not fully agreed on but we do have an implementation okay we can start yesterday.
Abdelhamid Bakhta: Did we agree on the transaction types we are going to use etc the value of the actual value.
Micah: we haven't spec’d that at all for like someone needs to submit a flip request. Probably me to 1559 that adds in 2718 integration and that's part of that. We will pick transaction types. I am going to most likely just pick whatever after 2930. I forget which number to use for them but at least that makes sense.
Tim: I guess if you can just re-share that pr Micah in the dev channel or something just so people can review it, that's probably a good way to start.
Micah : I need to write it first I have been waiting to write everything already
Tim Beiko: Cool if you can get started on that then we'll review it when it's when it's ready and we can get that all right.Anything else before we go to the base up code in the testnet demo. Okay Abdel over to you.
Abdelhamid Bakhta: Yeah so the create basically of code so nothing crazy. we just want to add a new evm of code to get the value of the base here of the current block and yeah so I created the pr. So basically with the value and the proposed gas price and I did the nominal case and we decided to do exactly what we do with unknown object for example if we originally end up code that has the value of the base your code we just throw an invalid operation error like we currently do so yeah nothing crazy, so I created the EIP and waiting for review so MIcah did the first review and merged in the master.
Tomasz: So what does the gas price return? What does the base fee return so the gas price will return the actual price to the transaction right?
Abdelhamid Bakhta: Yeah exactly and the base here returns the current uh basically in the block header. So yeah very simple yeah and yeah that's it about the EIP.
Micah: do any clients here think that EIP will be hard in any way or is that something that we can shoot in.
Tomasz Stanczak: I think it'll be super easy to implement at the same time if it doesn't happen at the beginning. It's not a big issue.
Abdelhamid Bakhta: let me show my screen . Can you see it? Okay nice so basically yeah this is a network status page for the new testnet so currently we have four Besu nodes. So we are close to one million blocks and yeah as I said ,we have 100 million accounts on this test and basically yeah we implemented the tool to join the test net easily. So the idea is net and 1 million 100 million entries in the state storage to build the client agnostic tool but for the moment. I only have a bezu implementation but the idea is that after that I can try to add the determination and get support if you give me just some basic stuff like a binary. Capable of doing 1559 stuff as the genesis and the conflict file and then I could try to add the determination and get support and basically you install this command line tool and then you simply run e1559 run. So it will download the config file templates . It will prompt you for a name to display in the stat so for example implement course nine and then the text that you don't have basu installed on your machine because by default besu is the default choice. I don't have the other client support at the moment. So I will install besu automatically. Okay so it prompts the command line to run the node but if you press enter it will run automatically and open the network stages page. So now bezel is running and it starts to connect to the peers. The synchronization started and yeah basically if I refresh again I have the new node and it starts to sync. So the first block is really big because I generated the tool basically to fill the network with a lot of accounts and a lot of entries in the smart contract and there is another command also in this tool. Basically it's a simple faucet so for example I want to add some it to this address to play with it so basically if 1559 for set with the address and you will get 0.5 it on the test net. Yeah okay this is a 0.5 it's and so the idea is to have a simple tool to join the test net and to have more users running the node on 1559. We also have a tool to basically submit transaction to this testnet because there is no implementation yet in the wallet provider so basically if you want to submit a 1559 transaction. you have an estimate button that will generate a pickup for you and you can submit the transaction and you have the link to the block explorer and yeah basically you can submit a 1559 transaction.
Tim Beiko: Cool anything else anybody wanted to share, discuss, bring up. Okay well yeah thanks everybody. I guess we'll follow up on the discord dev channel to set up the large state test net. Micah will also be waiting for your pr and we'll review that and then I guess we can figure out based on the test net test when we want to have another call or follow-up This is looking good yeah thanks.
- Ansgar Dietrichs
- Abdulhamid Bakhta
- Ramil Amerzyanov
- Baranbe Monnot
- Micah Zoltu
- Rick Dudley
- Tim Beiko
- Tomasz Stanczak
- Pooja Ranjan
- JosephC