Ethereum Cat Herders PEEPanEIP, 12 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #9: EIP-2565 with Kelly Olson

Description

EIP-2565: https://eips.ethereum.org/EIPS/eip-2565
Slides: https://docs.google.com/presentation/d/19Jj_SDb7TkTWtNGJBZhSBicjsIaJ6LA0TLgA03jEbNk/edit#slide=id.g85efd2ddbf_0_595
Discussion: https://ethereum-magicians.org/t/big-integer-modular-exponentiation-eip-198-gas-cost/4150

Follow at Twitter:
Kelly Olson @kellymolson | Pooja Ranjan @poojaranjan19 | Alita Moore @alitamoore85

Check out other exciting EIPs in Peep an EIP: https://github.com/ethereum-cat-herders/PM/projects/2

Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Welcome back to another episode of penny and eap focus series where we have an overview of a proposal and try to understand why that is needed for the ethereum mainnet. Today our guest is kelly olsen and the eip for discussion is eip2565 repricing of eip198 mod exp pre-compiled.

A

The ap2565 is a standard track core eip, which is in the last call status. It was proposed in march this year and has been discussed in few all coder meetings.

A

This is also being considered for the upcoming berlin upgrade welcome to the show kelly, please let our audience know a little bit about yourself and your engagement with ethereum chain and then we'll dive into the presentation.

B

Yeah sure sounds great, uh so my name is kelly. Olsen uh and I've been, I guess, uh somewhat involved in the ethereum community. Really, since, uh since its launch, um most recently, I started working at a company called supernational that focuses on hardware acceleration of some of these new cryptographic primitives um and that's one of the reasons sort of why we started looking into repricing.

B

This eip198 proposal is that there's a number of these new cryptographic techniques that are coming out that can help scale ethereum with things like you know: zero knowledge, roll ups and and what have you, and so the goal of this eep is really just to um you know, make those things more, affordable and and to better reflect the cost of um of their operations. You know and match the gas price to that, um so I can yeah.

B

So I can go ahead and share my screen and uh you know maybe give a little bit uh more of an information on on this eip.

B

Okay, great um yeah, so just just to start, uh you know, as puja meant to mention this. Eip is repr repricing, uh a previous eip, eip198 and eip198 introduces a new precompile for modular exponentiation and for those that aren't familiar with pre-compiles.

B

These are essentially specific functions that are too inefficient to run inside of the evm, and so special code has to be written for them so that they can execute sort of natively. On your platform with bespoke code, that's written in and implemented in the client.

B

um This function, in particular, is modular exponentiation, uh which is used in a wide variety of cryptographic. Algorithms- and it was you know this pre-compile was originally proposed by vitalik uh to allow for efficient rsa signature verification.

B

uh So the rsa signature scheme uh is highly dependent on these sort of modular exponentiation operations, um but they extend sort of well beyond that, and really the ultimate goal of this eip is to you know. A number of things have changed over the past. You know three or four years since the cip was originally implemented, and what we found is that the original estimates for how to price the cip could be improved upon to sort of bring them in line with the costs of of other eips.

B

um You know so, just just as I mentioned uh before. You know this is a foundational arithmetic operation. um So most of cryptography relies on these sort of modular operations, um whether that be modular addition, or you know, modular subtraction, or what have you um and in order to verify some of these uh more advanced cryptographic uh functions like snarks um or accumulators or verifiable delay functions.

B

You have to do these modular exponentiation operations to check that the proof that is sent to you is actually valid, and, unfortunately, today you know, while it is possible to verify things like snarks and vdfs and accumulators in the evm, with this precompile, it's very expensive, um so it can cost. You know upwards of you know two three, four million gas depending on exactly uh what sort of proof you want to verify, and so this makes it very um you know basically expensive. You know, especially with recent gas prices.

B

uh You know this could be 30 or 40 dollars to do one of these functions in the evm, and so you know sort of with this in mind, and you know, given that ethereum is looking to move forward with using more of these cryptographic techniques, we want to make sure that that cost was was really justified or whether you know perhaps it could be optimized.

B

So uh the sort of very first thing that we went out and did in this eip is, we went and did a benchmark, um so every eip and every pre-compile has a set of test vectors and a benchmark that you can run for these test vectors. And so what you'll see here on uh in sort of this, this first column is we've got ec recover, which is um one of the main precompiles. That's that's used today and it's an elliptic uh key uh recovery um and then we have a whole bunch of uh these test.

B

Factors for the modular, exponentiation, pre-compile operation and really the main thing to call out here is that currently the pricing for other pre-compiles, like ec recover, is about 20 million gas per second. So this means basically, um if you submit a transaction, and it takes one second to verify you'll be charged. You know 20 million gas and that's sort of the standard uh pricing metric that's used across you know the evm, and also with the pre-compiles, is really trying to target um this amount of gas.

B

So when we go look at the current gas pricing and the execution time for uh these other precompiles or for the mod x test vectors, you know what we'll see is that the gas pricing is is anywhere from.

B

You know about 100 million gas per second all the way up to about 550 million gas per second, and what this means is that when you call this precompile in the evm you're gonna pay anywhere from five to twenty times more than other pre-compiles are paying right, and so this was a great discovery for us, because we said hey great, these things cost you know, maybe forty dollars or fifty dollars now, but they're unfairly priced they're, they're too expensive for how quickly this operation can be done, um and one of the main reasons why it may be too expensive is really just you know.

B

These cryptographic, libraries that are used by the clients have gotten better over time, so they're able to put in better algorithms um computers have gotten faster in the past five years, and so, while you know the pricing originally was, maybe uh you know more reflective of what it was at the time now, when we run these things with better algorithms and faster processors, they don't take as long and therefore they shouldn't cost as much. So that's really the core. The core idea behind this eip is. We did some benchmarking.

B

We found that it costs about 5 to 20 times more. What other precompiles are are costing, and we said, okay, well, let's go bring these costs back in line with these other precompiles.

B

um The second thing that we did is is also look at uh how these precompiles are are priced and how the gas is assessed. um So in the original eip 198 proposal by vitalik, which I can share here, what what this proposal does is?

B

It tries to estimate how long uh these modular exponentiation operations are going to take to run on a computer by looking at the underlying algorithm that the the implementations were using at that time, and so in this case, as vitalik calls out, you know this function is intended to approximate the difficulty of something called keratsuba multiplication, which is one of the techniques and one of the algorithms that's used by these these libraries to do this function.

B

Well, uh what we found is that, over time, more and more of these libraries have actually evolved to use a more efficient function, uh and so what we were able to do is rather than using this formula that vitalik had described here that represents karatsuba multiplication.

B

We're able to modify this formula to better represent the the algorithms that are actually being used today and, and what we did here is we ultimately took these test vectors that are already part of the pre-compile and we priced them with the old pricing formula and we priced them with the new new formula.

B

And ideally, what you would want to see is sort of this one-to-one comparison, that, as the complexity uh goes up of the pricing formula, so does the execution time and you'll see that vitalik's uh original estimate was a fairly good estimate right so for at least the sizes that we're looking at, uh he had an r squared value of about 71.71 or 71 percent.

B

uh What we found, though, is that by actually you know specifying this new complexity formula to better, you know, represent the actual algorithm that was used. We're able to bump this up to about 92 and what this means now is that the gas pricing formula is a better predictor of the actual time that it's going to take to run on your computer and that's really what ultimately we want to do when we're pricing these uh these gas precompiles.

B

So maybe I'll, just pause there. That's that's kind of a very high level overview of what we're trying to do in this eip, we're trying to make its cost similar to the other costs for that happen in the evm or that happen in other pre-compiles and then two. We want to make the gas pricing formula as accurate as possible so that everything is priced more fairly.

B

um So maybe I'll pause there and just see if puja or alita have any.

A

Questions I just have a comment here. I remember uh uh this uh when this eip was introduced in the meeting, people were like really happy to see the kind of benchmarking it was done and uh like in my knowledge, for the first time. It was also mentioned as one of the eips that could be uh that many other eips can follow as best practices so yeah. Thank you for this great work.

B

Yeah absolutely- and I think you know one of the key uh you know components of that is just you know.

B

All of the client developers have a lot of issues on their plate right, they're, getting a number of eips, I'm sure there's you know 10 or 20 new eips that are submitted every week, and so it's really important that you come as prepared as possible into the these eip meetings, and so you know I can maybe just show briefly.

B

um You know we did a whole bunch of work originally uh in the spreadsheet, where we looked at what were the original benchmarks? You know, why was it priced this way originally um and we went through a lot of trial and error in understanding exactly you know why the original estimation was not as good of a predictor of of the computational cost says as we thought it would be right, and so I think the you know, the best thing to do is the more information you can bring into that eip process up front.

B

um It's really helpful to to sort of move it forward, um so you know just as a quick example. You know we looked at what are the original benchmarks when the eip was originally implemented, we went and benchmarked a whole bunch of libraries to understand. You know. Are these implementations today good? Could they be better? um We looked at different ways to reprice it uh and how could we get? You know, sort of a better fit uh with these different algorithms, and so I think you know in general.

B

I do know that a lot of the eips come in a little bit, half-baked, sometimes, and so I think you know it's really useful if folks can do as much due diligence as possible uh before coming in, so that the the client teams you know have those questions answered and and the process can move forward uh quickly.

C

So I have a question: uh do you mind walking through here and explaining, um I guess, sort of as trivially as possible? What exactly is happening like what these dots are on? The graph, for example,.

B

Yeah, absolutely um so, at the end of the day, the whole point of gas is to is something that you're paying for computational time right. So when, when somebody gets a block off from the network, they have to process that block and make sure it's valid before the next block comes.

B

So you have a very limited amount of time uh to process these blocks, and gas is one way to ensure that you know if a block is coming every 15 seconds, gas ensures that it doesn't take 45 seconds or a minute to actually verify the block.

B

So what you want to happen is that um gas is closely tied and the gas pricing is closely tied to the time it takes to execute on the computer.

B

So what each one of these dots is is a look at the gas price, either according to the old formula which is in blue or the the new formula which is in red as compared to the execution time.

B

um So, as a very you know, sort of trivial example you know here is uh something where the gas price with the old formula would have said that this. This should be. uh What is this 10 million gas, but the new formula said it should only be you know, I don't know 100 000 right um so, even though they both took the exact same amount of time to execute one formula was a better predictor of its execution time.

C

And so are you saying that when, for example, when I send an instruction set to a miner or to something to compute it I'm giving it a certain amount of gas and then it's saying okay, I'm going to use this formula, which is the presumably currently the blue trend line, and if the execution time is above uh the well, presumably the intercept there on that line. Then I will um say that it is underpaid and therefore cancel. The uh execution is that correct.

B

uh It's close, um but the the prices are sort of fixed. So you know in the client when you get a transaction and it's got a few instructions, you look up what that should cost and that's all based off of previous eips, so you may get a transaction and you say it uses these three pre-compiles and the total cost is 1 million.

B

Now whether that takes a half a second or 10 minutes, you're still going to process that transaction. So it's really, you know the sort of gas cost is hard fixed up front and that's why it's so important to determine accurate pricing up front.

C

B

C

Then the current determination is um overvalued, meaning that when you are going to compute the uh I forget what it's called. I think it's the module exponentiation, um if you compile, then the formula currently is going to say I should give you presumably about you know whatever magnitude amount more than you should be getting in terms of the gas price to.

B

Actually, compute that exactly yeah, so the long and short is that um what's hard coded into the clients, is they charge you too much right? um They charge you as if you're spending a minute worth of computation time, but you're really only spending one second, because of these better algorithms and better processors, and so the whole goal here. Is you know the collective users of this precompiler are all getting overcharged right unfairly. You could say right, and so the the goal of this is to say: hey you shouldn't be charging us one million.

B

You should be charging us a hundred thousand, that's okay!.

C

So I think uh we have sort of um to not go off of like off topic. I think we should continue and maybe try to get through the rest of the slide, because I think up at this point it's pretty clear what what the problem is and what the solution is perfect.

B

Great, so, let's, uh let's just dig right into the the eip as it stands today. So um you know, as we mentioned you know, really. The motivation here is is to bring the pre-compile in line with all of the other costs on ethereum other pre-compiles and operations in the evm.

B

The current formula uh is in eip198 is specified uh with sort of three main variables. It has this multiplication complexity formula which tries to determine uh how big of a multiplication you you have to do it has this adjusted exponent length uh variable which determines how many multiplications you have to do, and then it's got this, um what they call the the quad g-quad divisor, which is really just a way to normalize that with the rest of the other gas prices.

B

So this is just a simple parameter that you can move up and down to bring this in line with the the current prices.

B

So the first thing that we recommended in the eip is to replace the original multiplication complexity formula with this simplified one and the simplified one is what gives you uh you know, sort of the this better fit here right. So when we use the simplified formula versus the one that vitalik had originally done, uh we get a better estimate of the gas cost. So that's the first recommendation of the eip.

C

And just let me quickly, sorry uh when you say a better, I just want to say one thing with that line: it's it's under the assumption that different jobs might take different amount of times, but on average the general uh price will be equivalent to what is actually being used. Is that correct.

B

C

Could you maybe say that one more time sure so? For example, you have the red dots right and you have a couple dots that are off the line, because this is the best fit um linear curve right.

C

This gas price formula is not built to be exact for every single computation, but rather on average.

B

Yes, that's, that's, that's exactly right, and um you know what I would say is is, rather than even exactly average, it's more that we target the worst case. So um what we actually do in the cip is.

B

We know that, for instance, some of these ones are maybe underpriced we're going to just shift this line by modifying this g quad divisor, to ensure that nothing is underpriced, because the last thing you want to do in ethereum is have something that's underpriced, because then that means it's potentially a denial of service vector someone could submit a whole bunch of these transactions that are all underpriced and it takes someone an hour to validate it.

B

So this trend line sort of gets us the formula, that's right, and then what we're going to do with this g-quad divisor is just sort of move it down a little bit to make sure that everything is priced either priced accurately or overpriced, because but just less overpriced than it would have been. Basically.

C

And that's a really great point that I think you should come back to later, so I can try not to go off topic but because I remember during the um all cordes meeting there was a discussion about clients worried about that very um vector of denial of service vector. So right that same um explanation later sorry, do you mean interrupt you.

B

No, no! That's that it's a great question. I think it's a a very important thing for for folks to be thinking about. um Okay. So, as we mentioned, you know we sort of um we modify this multiplication complexity formula from the original one in 198 to this new function. This moves us from sort of the blue line uh to the red line. uh From that previous uh thing, the second thing that we do is we update this value of g quad divisor.

B

So before you know, we knew it was overpriced and this had a different value. So we just changed this value so that we are getting close to that 20 million gas per second and then the last thing you know again just to address this um denial of service pre-compile.

B

What we found is when we looked at the the original eip198 spec is that there were some very small values that actually were underpriced like very, very small values that probably no one would ever use, but they were underpriced, and so what we do with this last update is just say no matter what, if you call this function, you're going to pay at least 200 gas, um and this is again just to make sure that um nothing is underpriced, because we don't want any denial of service vectors here.

B

So that's that's really the whole specification. We basically update one value to three: we put a maximum of of uh 200 and we also uh changed the.

C

Complexity formula.

B

Maybe it is a yeah, it's a minimum of 200 uh exactly if, when you sort of type it up into python, you say take the max of this or 200. So, but yes, it is a minimum of 200.. That's correct um the rationale, I think you know we've already sort of talked about before you know we had this current complexity function. uh We realized we could make a better one. That's that uses you know is more in line with how clients are actually doing these operations.

B

um With this g quad divisor, you know, we said: hey we're going to move it down, um so you know, maybe just to to speak a little bit to your point. You know we wanted to make sure if this 20 million gas per second is fair pricing right, we have a straight. You know one one to one correlation here with execution time and gas price. We want to make sure that we any of these dots, are always over this line and that what that means is.

B

It means that we're always uh we're never under pricing any of these, and so the very key thing I guess maybe to take away and understand this graphic. Is you know this is fair pricing, the yellow line?

B

This is what pricing was before and we're trying to move it somewhere in between the two, so it's cheaper than it was, but it's still not presenting a denial of service vector because it's more expensive than the completely fair pricing, that's really the takeaway, um and so the benefit is that you do get cheaper pricing uh than it was before, but you're not introducing any new risk to the system because you're ensuring that it's always taking at least that 20 million gas per second price.

B

um Maybe the last thing just to talk briefly about, is um you know these test cases right? So there was an original set of test cases. um The clients are going to go implement these three changes uh that we talked about, and so they need to make sure that you know the four different clients or or maybe more that are out there that they're all in sync right. So we need to make sure they're all getting the same answer um once they update it, and so what we did is we updated the test vectors.

B

So we said you know before they all agreed that when you ran this test vector you sh it should you should get 204. Gas is the answer. Now they should get 200. um and you can really see the net uh reduction.

B

You know here's a test vector that used to cost 285 000 gas, and now it only costs 87 000.- and this is really you know. This is the whole of why we did this. Is that everybody's going to get about it's going to be about four times cheaper than it would have been uh before? So that's, that's the long and short of um sort of the eip walkthrough.

B

So it's fairly simple, um but certainly you know, a lot of a lot of work goes into it to make sure that uh you're not presenting or or adding any risk into the ecosystem.

C

It definitely requires a lot of background checking. uh Thank you very much for your work on this. It's a very impactful uh change to the gas calculations.

B

Yeah, absolutely um so, maybe just to to to summarize um this is what the new uh eip pricing looks like right. So before, if you remember you know, we had some things that were up to 500 million gas per second right.

B

Well, once we implement the new pricing formulas, those changes we recommended you'll see that all of these test factors are over the 21 million gas per second, but they're substantially lower than they were before, so something that used to be 500 million gas is now only 165 million right, um and this is really the net net of the change is that everything is much closer to this fair pricing here.

B

So what's the status of this eip, um so benchmarks have been conducted for both uh geth and open ethereum. um We did a performance analysis to to basically figure out what the right new pricing formula was that balanced, uh the cost reduction that we wanted to see with um the denial of service uh prevention that that we needed to have. um We have draft implementation in geth and open ethereum, uh and we also have the eip in in last call status, which should uh be moving to final here in in the next week or so.

B

um So what are some of the learnings? You know, I think the first one is, you know, engage as early as possible with the client developers to get their feedback on the proposal. um So you know when we originally went in with the cip.

B

We sort of had a range of options and said these are some different ways that we can tackle the problem um and- and it was really you know, informative to get that feedback from uh the various developers so that we could craft a proposal that that was going to be acceptable to them.

B

um You know when, when any time when you're doing gas pricing, it's not sufficient to just look at one client and we had a ton of struggles here um and a lot of time spent because, uh for whatever reason, the the library and the function that open ethereum was using was much worse performance than the one that geth was using, and so you know you need to ensure that you don't prevent, or you know, create a denial of service for one client right, because what could happen is if get or you know, open ethereum is really slow.

B

Someone could spam a bunch of these transactions. The guest notes are fine. They'll proceed with life because they're fast, but the open, ethereum ones all get. You know, kicked offline or you know unsynced or you know, lagged behind on the head of the chain. So it's really important to you know not just look at geth, but also look at the other clients, because client of diversity is, uh you know, sort of a goal of the ethereum ecosystem.

B

um You know in general, this 20 million gas per second is is what you want to be targeting for when you're setting gas, uh it's the rough area, um but you want to shoot for this in the worst case scenario right, so you know, in our case, we did have one that got down to 28 million right, and so this is where we said.

B

Okay, we're going to pause, we're not going to reduce this any further, because in the worst case scenario, it could be at this 20 million and we don't want anything underpriced, as we mentioned before.

B

um I guess the the last couple things you know. um Ideally, you know when you submit in the ip. As I mentioned, the client teams are very busy, there's multiple clients that are going to have to upgrade. So if you can minimize that implementation complexity as much as possible, that's great! You know. One of our original eip proposals was much simpler. It was hey instead of this number being 20 change it to 200..

B

It was literally a one character, change um that would have got us a 10x improvement, but unfortunately that didn't work for open ethereum, um but that would have been the ideal case right is that you make it that simple that the clients go in, they press one button or they add you know one line of code and and you've made the change um you know. Sometimes libraries do need to be changed for clients.

B

You know in the case of open, ethereum was much slower than geth if they do need to change and you want to help open, ethereum or a client determine what library to do use. It's really important that you understand what their requirements are. So we did a lot of work on benchmarking for open ethereum, but at the end of the day they said.

B

Oh, we don't want to use this library because it's tough to build on windows, so that was a requirement that they had, and so we said, okay, let's go find, let's go find another library or let's change the pricing formula uh to make sure it works, um and then the last you know last piece I'll say here. Is you know, gas pricing is a bit of an art. You know we're trying to get everything.

B

You know to be priced at at least 20 million gas per second, but not much more right so that it's fair, but you know to price this. You really need to understand what is the hardware doing underneath it? What are the algorithms doing? What is like the actual cpu doing those will help you come up with better formulas. If you actually understand how this gets executed to get those better pricing formulas and that's what we were able to do with this eip is we knew what algorithms you know libraries were using.

B

We know how we knew how the multipliers actually work in the cpu, um and so that's that's really important, and you know. Last but not least, you know. The number one priority here is is to be conservative, with the pricing to prevent denial of service risk. So you know selfishly everyone would like gas to be as cheap as possible and nobody wants to pay gas or transaction fees.

B

But you know it's important that the network is is secure and so number one priority is is really make sure you're not introducing new risk into the ecosystem, so tentative plan. You know in terms of next steps. uh You know the eip will move to final status this month. um The eip still needs to be implemented in in bessu and nethermind.

B

We'll then test this in a multi-client test net likely yolo, v3 it'll get implemented on a normal test, it like gourley or robsten, or what have you uh and then hopefully in the berlin hard fork this this repricing will actually come to mainnet and people start to see the benefits of of the improved pricing formula and the lower cost for these operations, and that is, uh I guess, the conclusion but happy to answer any questions that you may have.

A

Thank you for this, uh so I have a question on the benchmarking on and on the client implementation side. I remember uh in in one of the all coder meetings it was mentioned that geth has asked for some rework and that I think, would be considered for the consideration of this particular proposal for the v3. So do we have anything on that? I mean like.

B

Yeah, that's that's a great uh question, so the the most recent uh all-core devs call is that geth had said. We've implemented this. It looks good from our perspective, but we need to know that it's good for bessu another mind right um so that uh what we've done is since we've we've reached out to both of those teams, the basu and nethermine team. We've said: hey, could you run the benchmark um and then we can make sure that again it's 20 million gas per second or more for all of these test factors.

B

um So the hope is that we get that. um You know at the latest before the next all-core devs call. But ideally you know we would get that. You know sometime. uh You know in the next couple of days.

C

Great, um do you mind it? I think that that pretty succinctly covers the whole eip. Do you think there's anything else that was sort of um not covered or, as I guess, trivially as possible, do you think was? Is there anything else that you would like to clear up a bit.

B

uh No, I think uh I think that's about it. I mean, I think you know just the only comment would be you know, moving forward for folks. um You know certainly make sure you're engaging with all the different development teams and that you're, you know constantly getting that feedback and refining the proposal um and yeah. That's what it that's what it takes to move forward.

B

C

uh Now, do you mind if I ask a couple off topic questions like I guess about the future or whatever else. So one interesting thing to me uh that I thought I saw while watching this was this idea that you're over compensating, so the the price for a certain precompiled, for example, would be um would be equip would be always greater than or equal to the slowest client in an ideal world.

C

So a faster client then is going to have more bang for their buck in terms of accepting those orders, because it will take them shorter amount of time and they'll be paid as if it was taking them longer. Is that correct.

B

um So the you know, every all clients will sort of um they're all going to pay the same gas price. So what it really means is if, if let's say geth is faster than open ethereum, it just means that that geth is going to complete validating that transaction um before the open, ethereum one. You know all all nodes have to process all transactions, um so you're going to pay the cost you're, always going to pay the same cost right for whoever processes, the transaction, whatever minor process. Is it so uh yeah?

B

It really just means that you know faster clients are faster they're, going to use less computer resources, they're going to finish the transactions quicker. That sort of thing you know the goal is that all clients can keep up, which is why we price them so that even the slowest one can keep up with the chain, but some clients will just naturally be faster, and all that means is that they're going to finish validating these transactions quicker.

B

It does mean that it's going to be more overpriced on those clients right like if, if, for instance, open ethereum didn't exist, we could we could make this uh precompile probably twice as cheap, um but unfortunately you know fortunately or unfortunately, you know, depending on the way you look at it. You know open ethereum exists. We want them to stay synced with the main chain, and so we need to make sure they can process these transactions and therefore we need to charge more because they are slower.

B

C

The thing that that's really interesting to me, for example, is this sort of uh micro economics of the way that ethereum works in terms of the miners and their incentive to perform.

C

So in other words, what I'm trying to say is that, with this set gas price, it's interesting because if you are, you know, if you have, if you're at the highest level or as you just described, you might be overpriced, and so therefore, uh new clients from the future clients are encouraged and incentivized to produce something that can produce or that can copy sorry perform that computation more quickly. So they can do more and therefore earn more money and that's an interesting sort of like uh self uh leveling.

B

Right, yeah, that's the one thing I'll say is that um you can't? You know you can't earn more money, because there is a gas limit in ethereum right. So, even if a guest node could process twice as many transactions, they can't include more than 12 million worth of gas in a block.

B

So it's kind of unfortunate because you know you sort of uh you have the situation where you're only as fast as your weakest link in ethereum, you know, and if you're faster um it doesn't get you anything really like I mean it makes your node run faster. It uses less computer resources, that's great, but you don't make any more money. uh Unfortunately, because the ethereum protocol caps, the total number of gas that can be used uh in each block, and today that number is like uh 12 and a half million, or something like that.

C

That seems like a missed opportunity, but uh very interesting. uh Thank you for explaining yeah, okay, all right! Well, puja. I think I'm good. uh I don't have any burning questions. Unfortunately, thank you so much kelly yeah. Absolutely it's my pleasure.

A

Yeah, I think this presentation is really good. We can now uh wrap up the discussion. I'm hopeful for this proposal to make it to the yolo v3 version and ultimately to the berlin upgrade. Thank you kelly for joining us and uh also to elite for helping us understand the proposal better. With your questions for people watching us on youtube, you can contact kelly on twitter, kelly m olsen, uh the contact for the author and the rest of the crew. Members of this meeting are mentioned in the description box below, along with the presentation uh shared.

A

We will also provide the link to the proposal. If you have any questions, comments or concerns about this particular proposal or any other, please feel free to leave a comment.

A

Let us know which proposal you would like to see. Next in the series we need, your love and support do like share and subscribe the atm cat, herders channel and let other community members know about the dependencies, see you next time with another proposal till then this is your host puja ranjan signing off take care. Thank you thanks. So much pooja.