EIP-7823: Set upper bounds for MODEXP

Transcript

This altogether can make El client's implementation vulnerable for potential Ethereum chain consensus attacks. >> Consensus bugs mostly have been taking place against the pricing model and not against [music] the implementation itself. It just you know high surface area in a complex piece of code which lends to continuous attacks and [music] and improvements. >> Introducing this cap does not affect any practical use case of modex per compile. >> This limit isn't something which cannot be changed. While we introduce this limit right now, should the use case come around, the limit can be increased any time in the future.

Welcome back to Pepen, the one and only EIP series, where we explore Ethereum proposals for upgrades and those making an impact across the Ethereum ecosystem. [music] This is episode 157 brought to you by ECH Institute. I'm your host Puja Ranjan and today [music] I'm joined by Akash and Vilin from ECH team. In today's discussion, we are going to dive into EIP [music] 7823 which proposes setting up a bounds for mod expoile [music] a change meant to improve safety and predictability in cryptographic operations on Ethereum. The proposal is documented in November 2024 and

currently is in last [music] call. This is a standard track core EIP and is being considered for the upcoming upgrade. So the inclusion state is scheduled for inclusion for Fusak upgrade. To unpack this, we are joined by co-authors Alex Berghazi aka Azek and Radhus aka Radik. Welcome you both to Peep Panib. >> Hello. Hi. >> Thank you. >> We usually like to start with quick introduction. Many of our listeners may already know exit but this is the first time we are hosting both of you together. So could you each share a bit about yourself and what you are currently working on followed by what

led you to the documentation of this EIB so and so forth. Yeah, so I used to work for the ipsilon team in at theium foundation and now I'm a part of the EVM team also at the Ethereum Foundation and in the past I worked on basically EVM interum virtual machine improvements so Ethereum virtual machine object format and and a couple of things mainly related to to the EVM and this EIP also is a part of the EVM pre-ompiled contracts. Uh it's similar for messer for work for a long time with the epsilon team mostly on EVM improvements and uh this is how this EIP was on our radar. Lately I've been mostly working

on security products at the spirit and container. >> That's great. I understand epsilon team had a lot of contribution in EVM development. So happy to see this proposal finally getting into the Fusaka upgrade. Thank you for sharing about yourself and uh I understand we have a presentation. So without further ado, let's peep in. >> Yeah. So today we are going to introduce you the some context about the the IP we prepared and uh this IP you already mentioned the EIP 77823 and uh and it's related to the modex pre-ompile and uh but before we start we need to we need first to explain what exactly this pre-ompile is about. So it

was introduced in the in the Bzantium fork and basically it implements the big integer module exponentiation taking three arguments for the call data. They are the exponentiation base, the exponent and the modulus. And the size of the of each of these arguments is uncapped in theory which means basically that you can calculate it for as big argument value as you want. But in practice of course you are limited by the block gas limit which currently is like 45 millions. And assuming the block gas limit increase in near future hopefully near future to 100 million it would be possible to make a code to the pre-ompile with the input size of 256 kilobytes which is quite big and

additionally the current gas model of the pre-ompile is very very complicated and it was a source of many bugs already in the implementation of E clients. This all together can make EL client's implementation vulnerable for potential Ethereum chain consensus attacks. But Alex, would you like to add something to this part also? >> Yeah, I can. I mean, basically as a recap on pre-ompise, there needs to be a specific uh like the gas model needs to be implemented as a specific function. The calculation is happening outside of the actual performance of the action.

That's just the nature of how pre-ompiles work. And this gas model and the implementation for the gas model for mod XP has been fairly complex and it actually has been updated multiple times already. And another update is is also scheduled for the upcoming card fork which suggests that this gas model is is fairly complex to get right. And the consensus bugs mostly have been taken place against the pricing model and not against the implementation itself. And when we talk about consensus bugs here, it mostly has been about trying to find a bug as opposed to hitting these bugs during regular use cases. So when we talk about consensus bugs for mod XP, those those have been manually crafted

transactions triggering those kind of bugs and it's not really happening when somebody does something intended. Yeah, I think that's the the key point here. It's just you know high surface area in a complex piece of code which lends to continuous attacks and and improvements. >> Yeah, that was a good explanation regarding what exactly is the post in the EIP. So as we already mentioned it's planned for the end of the year. So the Fusaka fork hopefully it will happen before the end of the year and we it's already in the last call. So absolutely every e client should have it already implemented. But let's see what exactly this AIP changes in the modex pre-ompile implementation. So basically there is a one single change introduced by the cap and basically we reduce the input size

for each of the argument to maximum 1 kilobyte. So this means that the total input size of to the pre-ompiled contract will be about 3 kilobytes because it depends on on the exactly defined the way how the input is defined but basically it should be at maximum about 3 kilobytes and um what happens if the input is larger than the limit. So then of course the pre-ompile execution stops all the gases passed to the pre-ompile call is consumed and an error is returned on the stack. And it's also worth mentioning that introducing this cap does not affect any practical use case of modex pre-o compile and they are usually related to to the elliptic curve

cryptography where the modex is used as a primitive to build more advanced elliptic curve ACC algorithms or to asymmetric public cryptography. >> The the interesting tidbit of information here is how mod XP came about. There has been a proposal prior to mod XP to support RSC verification which has been a fairly simple pre-ompile and the main reasoning for that was being able to sign transactions with RS keys and validate like existing RSA signatures which has been used in for example ENS when you are proving a regular domain through ENS and not like an ENS specific domain. So that was the

origin of the mod XP. The cordas have decided to make a more generic approach and not let have like a specific RSC only solution and this turned out to be a good idea in in some ways and a bad idea in other ways. The bad part we're trying to address now. But the good idea was that this provides flexibility for other use cases and it has been utilized in various elliptic curve applications but not only and the reason we want to make these changes before going into more in-depth analysis is there are two main improvements in the short term. And the two main improvements the first one is really you're trying to simplify the gas model. Even though this EIP doesn't actually change the gas calculation, it does make it easier to arrive at cleaner

algorithms for the calculation because it doesn't have to consider as many edge cases. And the second one which is like a short-term improvement, it makes it actually easier for ZKVs to have an implementation or more specifically have an efficient implementation. It has been possible to have efficient implementations in ZKVM for specific the upper band makes it easier for the generic case as well. These are the short-term improvements. But if we look ahead in the future, this also makes it easier to create more generic implementation of MODXP. There has been, you know, a long-standing push to maybe generalize pre-ompiles. And even though I don't think it's on the agenda anytime soon, I think there have been like

recurring attempts at that. And a change like this would make that effort easier. And what's important to mention is this number we arrived at doesn't limit any existing application. And if we look at the the next slide with the actual analysis is that we have conducted this I don't remember now the exact duration. The EIP itself lists the starting and ending block number which encompassed several months and during that period of analysis there hasn't been like any case where it exceeded 513 bytes. It has been mostly around the 32 well more specifically 256-bit and 384bit applications which

indicates it has been used around ECC and there was also a spike around the 10 248 bits which indicates RC use cases and a 512 means the highest key has been 40 97 bits and nothing above. So this validated our assumption that nobody is really using it for anything beyond like large RSCA keys. We did observe a number of cases with invalid inputs but those seem to have been either mistakes or specifically crafted to be invalid as supposed to be something useful which has failed. It's very important to note that obviously this is a backwards incompatible change. After this sizes above won't be able to be executed. They

will end with a failure. But as I said, we haven't really seen such use cases. We haven't actually heard anyone saying that there would be a use case above this number. Coincidentally, certain ZKVMs already have chosen this limit and they have arrived at the limit independently from us with a similar reasoning. So this limit actually is already in place in certain number of chains and they haven't really seen any negative outcomes because of this limit. So I think we are fair to say that there won't be any adverse effects but obviously it's a breaking change. So over to you Radic.

>> Yeah. So and uh in the end of this presentation I would like also to give you an update on the on the status of the CIP introduction and um now it's already implemented in all the execution layer clients and uh it's also has a dedicated like a test set in the execution spec test repository which cover all the corner cases for the CIP and it was already introduced to to the hleski test net at the moment like week ago it was introduced And in the next week or a week from now it will be also live on Sepia and two weeks after it will be already on on Hoodie test net. And regarding the the mainet the mainet update of course it

will happen together with the with the Osaka fork which is planned for now at the end of the year. Hopefully it will happen but yeah in in worst case it should happen in the beginning of the next year. So yeah, and that's all we have for you regarding this uh very small change in the modex pre-ompile definition or specification. And now we think it's time to answer some question you have for us. >> Thank you for providing the overview of the proposal. This presentation was short and sweet but it definitely make a lot of sense. I do have some questions collected for you already. My first question here would be about the change.

So the change limit actually this CIP puts a hard limit of 8192 bits on input is that limit based on real usage or just future proofing. I remember you mentioned that nobody has to have a bigger limit and uh people are generally under the limit. So just curious what is the main reason to have this limit. >> Yeah. Yeah, so as mentioned is there there are two reasons we decided to introduce this exact upper bound. And the one is that basically for little usage nobody will need of higher values for this exact arguments of this pre-ompile. And the second one was that we just analyzeed the blockchain and we noticed that absolutely nobody use it in

the for a different sizes of of the arguments. And uh because we wanted to make this pre-o compile like a more secure and uh and easier to implement especially from the perspective of the gas model we decided to to introduce this change. Alex, >> I would add maybe two points to this. One, the usual use cases around signatures, whether that's RSA or elliptic curves. And one of the the main benefits of elliptic curves without being a cryptographer is it can provide similar security guarantees at a lower key size compared to RSA. And there has been always a battle to use as little data with as high level of security as possible which suggests to me that and

it seems like you know elliptic curve is is kind of a winner at least in blockchain. It suggests to me that people are unlikely to go towards RSA with large key sizes you know from that you can think that unlikely that if we stay within signatures unlikely that somebody would need something higher that being said this limit isn't something which cannot be changed. While we introduce this limit right now, should the use case come around, the limit can be increased any time in the future. And the increase obviously will need to have some research and and validation that it won't cause any adverse effects. It is much easier to increase than to reduce any of these limits.

>> Got it. So it was mentioned uh in the proposal as well as during the presentation that the root problem it is trying to solve is like sometimes they create consensus bug like in the past we observed some consensus bugs and we are trying to solve that problem especially against pricing model that was mentioned so I'm trying to understand here were the bugs tied to extreme or unrealistic input size or in general whatever size was at the moment >> they mostly have been uh clearly abusive inputs So the the way the calculation works and the way the data is formatted because the inputs are variable length there's kind of like a header section saying how long each of these fields are and then the fields are coming after that and so

in order to even calculate something one needs to parse this input and then do the calculation and then for the processing it needs to be parsed as well and there have been bugs around the parsing itself where people try to like overlap any of these fields there have been bugs with truncation but clearly most of these cases are specific specifically crafted to exploit a bug as opposed to be something useful. >> So basically unrealistic parameters we're trying to to be best. Okay, that makes sense. Well, my next question is with respect to failure. It was mentioned that no one asked to increase the size limit and it was found to be the most optimum one and if some contract exceeds this the pre-ompile will stop. What will happen after that?

Is it a safe failure or could it be breaking something upstream? No, it's a like basically when you call the preo compile, you just make an external call from to the contract address which in this case is 05 and uh and it means that if the call fails, it means that basically the color contract perspective it will just return the error to the color stack and so it doesn't break like execution of the whole transaction. >> So basically this is safe even if it is broken. It's not having a cascading effect or breaking something really big here.

>> No, I I don't think so. >> That's obviously good to know. Well, I'm uh trying to understand the impact on developers and projects. Obviously, people who are working on different streams may want to learn more about this proposal. So, I'm trying to understand for teams working on maybe ZK system, wallet and bridges. Do they need to update anything because of this change or have authors received any kind of comments from tab developers or infra team on this particular proposals? >> Nobody needs to really do anything unless they they try to exploit what you expect.

>> All right. So that is so only malicious parties can think of using things and changing their parameters to in order to make that kind of exploit. All right. You mentioned that this proposal is not directly involved in gas calculation. I'm curious what are your thoughts on compatibility or relationship with another proposal 7883 mod exp gas cost increase which is also there with the Fusaka upgrade. >> It was a couple of months ago already when we were talking about this um second pre-ompile which also changes the the gas model for this exact pre-ompile.

But from what I recall now, I think it even makes the second proposal easier to define because it's it limits a lot of uh or it cuts off a lot of corner cases from from the testing surface. >> So this second pre-ompile is it already like in form of EIP or still under the phase of research? >> It's like a second change to the same to the same pre-ompile. Yes, it's it's in the form of in the form of the AP. Yeah. >> All right. That's good to know. >> But they are compatible this changes. They they were also roughly proposed at the same time and there has been awareness from both parties.

>> Mhm. >> The way this price calculation works, it usually establishes different bands based on the input sizes and one band has a a price calculation in one way, a different band has a different way and there's always like a fall back you know for anything out of balance. What is the calculation? Usually I think it has been like three such bands in the past and even this new proposed change keeps the three bands just as the way that the pricing is within those bands and the uncap band now has a cap or can have a cap and this is you know the part which reduces the testing area.

>> That's [snorts] good to know. My next question is about a mention of EVM Max. I understand the proposal is already in last call. So we are considering that this is almost final and uh we may not see any changes but out of curiosity since EB max is not currently on the Ethereum road map. Do you think we must keep the mention in abstract motivation on rational or we can just skip that part for now before it moves to final? >> I think it can be removed. I mean it doesn't really hurt to have it there. As we mentioned there are other reasons other important reasons beyond anything like EVMX. If any of those reasons are missing from the motivation then we need to add them. I don't think they are but we definitely going to do like a a

review of this call. >> Yeah. So basically the EVM max was the so just to make sure that people know what's what it was it was the VM so Ethereum virtual machine modular arithmetic extension it was a set of instruction which basically make easier and uh cheaper from the perspective of the gas cost to implement any more advanced cryptographic primitives basically the EVM max and on the eof which was rejected like a couple months ago. So this proposal was prepared before this happened and um now I think it's worth to change the this motivation. So removing EVM max but I'm not so sure if PVM max never happened on mainet actually I'm a fan of it so maybe

it will happen someday. >> That's a [clears throat] good optimistic note here. Yeah it's good to know that you people are open to review it and see if any changes could be made before it moves to final. You have to be optimistic if you want to introduce any EVM change actually. >> Yeah, that's very true. Well, we are talking about some changes that we can bring in future and some challenges that we have faced. So, I'll be curious to hear if you guys have uh encountered any specific challenges or any specific incident that you would like to share with the community while documentation of this proposal or maybe implementing this EIP.

>> No, I mean this is really one of the more simpler ones. Obviously the only challenge in a proposal like this is having good data, good analysis which is convincing enough that it has covered the reasonable cases. For us it hasn't been like a huge challenge because we have done analysis like this before. But if somebody else would like to prepare a change like this obviously they may need to get up to speed and how to perform that. I think that's that's the key part for me any such change otherwise it's it's fairly straightforward. So the challenging part is the analysis and the data that needs to be gathered for making any further changes in future.

Well, my final question for you too today is about the feedback or engagement metrics that you are hoping to see or maybe collect once this proposal is live on mainet. Have you guys thought about any metrics that people should keep track of? I mean, you know, this is more like a security um motivated change as opposed to like a feature. So, we don't really expect an uptick in use cases here, but we would hope that the number of consensus bugs may may get reduced. That would be, you know, our goal and you know, hopefully we can see it with a metric. But obviously consensus bugs are multi-layered. So, a change like this may not be fully enough to, you know, get rid of them, but it certainly should

reduce the number of occurrences. Yeah and to add to this I think that uh some good sign that this is a good proposal and people like it was that when we proposed it actually when Alex proposed it on during the ICD call during the call absolutely every clients was in favor to this change and hopefully it will also allow us to make the E clients developer life easier in the context of blog gas limit increasing >> maybe we can also keep track I don't know how but keep track of implementation like how many security projects project is trying to implement this and make use of this. Not sure if there is a practical way to collect this metrics. Well, um I think I'm done with my list of questions. Any final message

that you would like to share with the community from this platform? >> I would probably reiterate what Radic said in regards to needing to have a lot of optimism when proposing EVM changes. I think that's that would be our key message. >> Yeah. Actually our our main goal when we when we are proposing the changes to the to the existing pre-ompiles is to make the pre-ompiles better in any way basically especially from the security and consensus bugs vulnerability perspective which in the case of the pre-ompiles is especially is very important and u pre-ompiles are basically basically really nice gadgets

we have on have inv PM but on the other hand they are also a source of many different consensus issues potential consensus issues. >> Thank you for sharing that message. That wraps up our [music] conversation on EIP 7823. A big thank you to both of our guests for sharing their context and motivation behind this proposal. Such discussions help understand the core protocol work and bring more awareness to the challenges that editor, author or client team may feel while they are working on having [music] an EIP bringing up to the Ethereum mainet. We are looking forward to see this proposal on the mainet

[music] soon. Dear listeners, if you are interested in learning more about this and want to share your experience maybe implementing this proposal, please check out the link to discussion available in show notes and you can share your thoughts, comments and feedback with the [music] authors. We thank you for tuning in. Stay connected, stay curious and we'll see you in the next episode. Cheers.