EIP-2537 Breakout Call

Transcript

uh let's go ahead and get started uh I'll grab the agenda here for the call I think the main thing that we'll discuss for the day is just settling uh the gas pricing I think that was like kind of the big open question for this EIP in Petra uh but then I think settling the gas pricing opens up a lot of different questions attached uh there was also a proposal to remove the mole promiles and instead use the MSM to Signal um mole of just one element rather than multiple so yeah I guess to kick us off um there was some discussion already on

the issue around uh these different yeah I guess gas prices for things uh Jared you had a recommendation here do you want to give us a little context on your thinking uh yeah sure um so basically what I the the argument I'm making is that if we're going to change the MSM gas model um we might as well reprise other pre-compiled that are pretty simple to reason about and I came up for with uh just a um suggestion to repic those uh just an

example repricing using um the performance of EC recover scaling them to the performance of EC recover and the g implementation of EC recover so um yeah uh is there a reason for E recover like is that how we thought about the albn curve um I'm not sure about that one in particular but I do know that when they repriced the mod XP pre-compiled it was used in the EIP uh as a justification and it's uh I don't know it's it

it's I would say with with lack of access to a bunch of different benchmarking machines for my side it's the easiest um easiest way for me to um make pricing suggestions yeah that makes sense uh I guess Barnabas oh momy have something to say um yeah I made some suggestion in April uh back on the Benchmark I had based on Constantine uh one of the easy repricing uh to do is make sure that the kyg promile and the EIP 2537 have the same price for uh a pairing like this is uh it's

the same operation basically so they should be the same and actually currently there is like 20,000 gas of difference or 10,000 gas of difference and then um yeah I mean uh I've put a link with uh my Benchmark on my own machines uh to give you a sense uh like when it's using the same library for everything because um uh when you use G for example it's implemented e recover is implemented in sep26 K1 and uh things are implemented in other uh uh languages uh or manner so I guess this will give you a better uh holistic view of the the

price okay thanks H well okay I mean h i see you here you have a section called out uh with subgroup checks I thought I saw somewhere yeah okay um I mean I guess that's like one place to start so we had kind of we had gone back and forth on this and I believe where we settled last was that we would have them uh you know where appropriate which I think is like most of the promiles does anyone want to argue for something else I'm sorry I missed that last bit to be

honest are you saying that we would uh price pairing specific to um well it would apply to like I think most of the promiles um so essentially like so yeah there's this question of I can pass in like say the points can be like U 256 and or like a 256 so it turns out that you know for all valid integers in that range only a subset are you know work or make sense uh with the actual way the curves are constructed and so you know what usually is done and maybe someone can correct me if I'm wrong but usually what's done is if you have some number you do a subgroup check uh either to say hey this is an okay number to proceed with or I

feel like there's also like a reduction you can do um but there's like a security issue if you allow sort of quote bad inputs and so then the question is like for the pre-compiled that we Expos to everyone on mainnet you know do we want to prefer uh the security and or like the safety of this and the trade-off then is like these type group checks do add computation so you know they are you know more than zero expensive so they're sort of like a security versus cost tradeoff to navigate um and you know I feel like we had said a few months ago basically hey like let's go for security so even if it's more expensive uh you know the misuse is you know the risk of misuse is much much

lower this way and potentially the risk of consensus failure if these Ed cases are handled differently I don't think it would be consensus failure like this is something we can test for and it's more like you know the clients would all do the same thing it's just not with user ones um this working yeah we hear you Kev oh sorry um yeah I guess it just depends on who the user is um once we sort of say this is the user then it's sort of easy to say whe we

should include them or not um does anyone have a candidate sort of user SL use cases well there is obviously rollups because um there will be likely the main uh consumer of cryptography and we can assume that they will uh audit their contract and uh that they know what we're doing um but uh yeah right is there is there any other um use Cas uh use cases or users because rollups we can assume that they're going to do the sub group

checks Alex mentioned validating BLS signatures from validator so I guess that involves uh bridges yeah and I mean I just feel like there's a whole host of applications you can imagine um that come down to validating you know what validators have signed over so those to me I think are like the two big ones um but also yeah guess that's almost another one is like Bridges from other chains as well could imagine using this possibly people um like uh I guess uh uh flash Bots or um uh iGun layer if they want to do reaking and verifying uh some of the

consensus stuff yeah so yeah and point being it's just like okay can we validate snarks in like a nice way that would be the up use case and then can we validate BL signatures in a nice way and I think those are like kind of the two buckets of things I I don't know like what I would say is start from let's make like assume the most sort of secure thing we can AKA like expose the safest API and see what it cost if it's you know way too expensive for anyone then we can evaluate like ways to make it cheaper probably at the same time making it less

safe but even with rollups it's like okay like if it's only going to cost like a little bit extra gas to do the sub check groups the the subgroup checks for them like I don't see why we wouldn't just go ahead and do that I think the argument is that uh if you call the promiles multiple times you're doing uh redundant subgroup checks so exactly that's that's that's that's the you know also in my opinion the the the most important reason that uh it should be possible to turn off the S group sub Lo check for for this PR compiles because uh in other case in my opinion in very very very in the lot of

cases it would be just useless because they will be paying for uh unnecessary so great so should we like there are two ways if we want to turn this off assuming we're okay with security implication one way is to create uh separate subgroup check of codes uh what pre compiles or the other way would be to add uh a flag like uh a Boolean to say um a skip subgroup check for example which means it forces people to think about it yeah this will this will

complicate a little bit the gas model for for this precompile but that's one of the one of the the the the the the flag also can be added to U not in the globally to all the the the sets the all the points in the set but also for each point uh for each point um specifically so with additional flag for example using the spare bits at the beginning of the of the point oh sorry of this of the point yeah just to be clear are we only talking about removing sub group checks for the MSM uh I think it's also scalar multiplication

yeah I agree soaron as um uh so when I when I did some benchmarking on uh think it was Friday just looking at gark uh the cost to perform the sub group checks and then the the glv uh was not all that uh much more than doing the uh whatever the naive like double and ad uh method that can take any input uh so it

seems like there should be no reason to remove the subgroup checks on scaler mole like there's and and this is just one library of course but um yeah it just doesn't seem like we gain anything from removing them for scaler mole from scaler mole yeah on on the other I also I also made the the the the benchmarks uh with for the multiplication for G1 and G2 and uh the maybe not naive method but the method with window and compare without subgroup check comparing to the method with using gfile and subgroup check check which is

required for glf uh so I get the same results or very similar for G1 and for G2 uh in using I'm talking about the blst library and for G2 um even uh even the the so so so for G2 the the GLS algorithm is used there for G2 but but basically it was much S faster and even with subgroup check it was uh it was faster than than naive method without subgroup check I mean naive by naive method I mean the window method which is uh which is subgroup check resistance resistance right so I think the only

reason to have the subgroup check um on The scal Mod will be for consistency um so if if you do MSM with one input and then you do a scal mile um it may give you different results depending on like if one of them has a subgroup check and the other doesn't uh I'm not sure if this is important for people yeah I mean it seems good to have the ability to disable the subgroup checks but I think we need to ensure that we're going to have a deterministic result with all the different

implementations that we have um if I understand correctly if some implementations might use endomorphism acceleration and some might not um so yeah something just need to try this um it's not safe to use endomorphism without subgroup checks so um um when I implemented the precompile when uh subgroup check were required I use endomorphism and if it's not I just don't use them and in MSM um well I don't think people are doing MSM off over a thousand points uh

in the evm but who knows uh endomorphism are um not worth it in my benchmarks and gar does not use them at all all for MSM anyway yeah I have I have I'm not 100% sure but also blsd doesn't use uh doesn't doesn't use the um the the the endomorph his acceleration for MSM at all it is just a just a p p algor of window so it's it should be it should be um it should work uh on whatever Pro from the curve you

take um so I guess do people agree with the consistency issue and is it an issue at all uh so essentially if if the Scala multiplication has the subgroup check it's inconsistent with an MSM of size one if the MSM doesn't have a subgroup check we could combine this with the other proposal of just getting rid of the the m to simplify things and and just using MSM in that case that would be the same as having the Scala Mal but without the subgroup check and not using the

endomorphism it's just that we have one less uh precompile uh because internally I think evm one they just did a if statement on the MSM size and then they're just doing a scal model yeah I think uh I'm not sure if Pavo can can hear us now because uh and uh yeah so so that's proposal by made by Pavo to change this uh this this promiles list and remove the mes um and we have some uh I think uh um PR draft

PR with which implements the multiplication using just MSM with one point right uh so does anyone I guess the higher level question does anyone think that MSM of size one and a Scala model should be different uh that should give the same result and same error message uh but I don't know if removing this like the simple scalar is um useful for uh audit code uh readability uh you don't have to double check uh how many

inputs you have when you are reading the code um to not too sure if removing it is worth it right uh I'm not super convinced on removing it either um but yeah so I think everyone sort of agrees that MSM of size one should be equal to a scal of M of size a scale of Mo uh which means that if we remove if we keep the if we keep the subgroup track plus gov for scalea M then we'll need to add it for MSM uh

as well or at least for MSM of size one when you say same result I assume you're talking about the actual output but also are you talking about performance or like cost um no I think it's if you have an error because uh something is not in the proper subgroup both the MSM and the scalar Mill of size one should give the error but it's not the case if one has subgroup checks and the other does not right would the scalar mole cost the same as the MSM with input

one yeah I agree on that that that it should be the same cost ex the same errors right uh so if we keep subgroup checks then the MSM will have a if statement that uh that does the glv endomorphism plus the subgroup check if we remove subgroup check then I think the MSM would probably still have to have a if statement but it just does normal scaler um because PPP Ander of size one is probably going to be a bit more expensive than just doing a regular scal mod I haven't checked um it's not really

that much more expensive uh I don't have a special path in Constantine and the speed is the same okay so we probably don't need a f statement if there's no this is like implementation detail uh people can do whatever they want uh for for would matter yeah I mean but we need to like the gas cost have to make sense yeah MH okay cool yeah so if we remove or keep them then they'll be the same it's just all about behavior um and I think most people agree they should be the same behavior so that goes to Jared's question on why we want to what's the

point of sort of keeping the glv Plus subgroup versus not having it it's whether we want the MSM to have subgroup checks or not right so if I let's say I'm like a you know a ro or just maybe some user like what does it look like for me to do the subgroup check myself is this something I do offchain and then does it matter like would I ever want to like prove onchain that I was inside the subgroup I guess is the question um so it's pretty it's for most it's context specific depending on whether you trust the input if you trust the input then

you can have a reasonable then you will know if it's like in the grp or not if you don't you probably want to do it at the beginning of your computation and then not do it again because all the operations should keep you in the sub group and so how expensive would it be to do on chain uh the subgroup check yeah uh I'm not sure we have any gas pricings for them at the moment but it depends on like how many points you have as well I haven't benchmarked the subgroup

checks alone but it does make like a very significant difference to the overall um gas costs um wa so do I understand correctly so you're saying that um it would be easier to keep them the the subgroup checks for Scala M because they're used by more implementation and so we'd have to keep them for MSM of size one uh oh so what what I was saying is that um if you look at Scala Mal and isolation it doesn't really make sense to remove the subgroup check because without the subgroup check uh you have this sort of basic Scala M algorithm

that's roughly the same performance as with the subgroup check plus the optimization but if you look at the consistency between Scala all and MSM um if you keep subgroup check for Scala then it makes sense to keep it for the MSM but we've just seen that keeping it for MSM is actually adding a lot of cost um and is that cost because we're doing like is there like we're still only doing the subgroup check once per input right it's not that we do it like many many times yeah but the thing is uh MSM is sub linear uh but if you the subgroup check you have to do uh one per point so

it's linear if you do the subgroup check so the Slowdown is big but uh it depends on the size of input like I don't know if there is enough gas cost to do uh a th um uh Point uh in MSM which would be noticeable like the difference between linear and sublinear I think for G1 the absolute worst um test case that uh either Martin or Marius was able to come up with that would fit within a 10 million block gas limit was 4,800 points but that doesn't Factor the

cost to set up the call to the pre-compile so it seems like maybe a thousand could be doable but right I mean do we have a sense of like you know let's say I have like a nice snark scheme that's relatively modern do we have a sense of how many points I would need to verify um one of the thing that might use this for verification would be maybe the vle trees uh not too sure but uh do they use this ver tree uses IPA I would assume

that there might there would be a pre-compile for it if we was to do um verification of it um for most snarks uh for GR 16 there's not a lot of points yeah there's not a lot of points anyway so it just gets limited by pairings for PL um I guess that's my question is how realistic is it going to be for a user to come and need to multi like verify you know feed thousands of points into MSM oh I see um it's a good

point not sure if I check just normal plunk there is one uh sorry 1 2 3 4 five six 7 8 9 10 11 12 13 14 15 16 um like about 16 like we can just say 20 msmf size 20 for like regular plunk okay so I don't think you'll get up to like a thousand right and I guess my other

question then is like is it actually so I guess yeah like let's assume we keep sub checks for everything there's no way to toggle them off or on like is it actually like for inputs that people are going to use say in the next I don't know even five years is it really going to matter I think we we don't know because we we we don't know the we don't know the users of this of this yeah so well very isyn yeah yeah I'm in touch with them but uh I sent them email and also asked them to to join the call but not sure if anybody from from them joined sorry I

cannot see the list of the of the of the attendees and uh and yeah so I can only wait until they answer but we can also try try to reach someone else uh yeah um another question uh that might help to solve this is uh let's say we launch uh we subgroup checks uh would it be possible in the future to keep the uh recompile ID and remove the subgroup check and add it separately uh like would it break people uh uh if the contract didn't work before I assume that with the sub group check they won't

um deploy it because uh it would be uh uh it wouldn't pass the subgroup checks um and for those that work uh well they would need to modify the contract to explicitly do the sub group check but [Music] um I think it might be uh forward compatible to add them uh later and remove them from the original uh pre compiles you mean add as a separate pre-compile later yeah yeah I mean I think we should try to keep the abis the

same so it would be weird if you had written a smart contract that you know has some knowledge of this bit for turn like turning them off or on and then yeah in a future hard Fork that just becomes valid although I guess you could it I mean without a flag without the bits like you just keep the precompile as is okay but then so why would we do this because we deployed it it turns out this was way too insecure and so we need to fix it in a lighter heart Fork uh no I think it would be it would be that it's deployed of subgroup tracks and then people are like this is too expensive uh and then I guess you remove

it and everyone who was previously deployed is still safe it's just that newer contracts now need to uh explicitly do the subgroup check is that is that is that right Mommy uh well I'm not sure if they are safe because uh previously they would they might need to be modified um that's uh but I mean uh the question is more can we can we do some something uh uh today so that we can keep the we can be forward compatible if we decide to do subgroup check

um uh separately oh I see uh oh okay yeah that's correct I guess the only way to do that would be that the contracts deploy today and let's say we add a flag and that flag always has to be true okay um so they get the option to put a flag in but it just always has to be true it just means that if you change the behavior then it doesn't break their contract once it's uh like once you allow false yeah it's a bit hard to make a

decision because the use cases or the users who uh will be using it are sort of not present right so like yeah who would be good to talk to then like ZK sync what about like scroll or maybe even Tao uh Tao is using um it would be more like um uh sp1 risk zero uh because Tao is integrating them but basically okay yeah as as as a job we have also we have also additional options so to postpone it and wait until the evm max

will be ready and Implement everything in VM Max uh you mean postponing postponing the EIP postponing exactly postponing the EIP because again again but but but but do we really know who really does need it and why we why we are we adding this if you look at the I think it's one of the EIP where people are always asking wow this has been proposed in 2020 it was almost shipped and actually shipped in uh parity uh by mistake in 2021 in Berlin and

uh yeah people really want this uh if only to have MSM uh um available as a precompile yeah so so let's let's reach out to these people and ask them if this uh this uh this this specification is okay for them and uh we can decide if the subgroup check is needed or not and we want to implement this this this other way one way to view this is that whatever we do uh whether we use subgroup check or not uh it will be much faster than doing things uh on chain um at the moment so yeah and maybe we can just sweeten

the deal with gas price yeah that's that's also an option or to or to at least uh for now implement the the pre compiles which does not require which which don't require the subgroup check so they cannot use the the the super fast algorithms and then uh with this additional flag for example which now is zero and and then allow people to define a flag which will uh which will mean that uh that you that that the that the subgroup check needs to be done before something like that I don't know um K to answer your question is

slower than b254 but uh the b254 gas price is uh very overpriced with the current state of uh um pairing Library speed and yes there is a secrity argument um of the number of uh security bits uh of b254 which is kind of inadequate today is it only the the pairing that's overpriced uh not only uh let me look at my um I think

most where um I have a PR on Gaff that uh switches out the cloud flare implementation and I think it's like a 10x for some of the some of them but all of them have an improvement W I think this I think everything was overpriced on the b254 uh uh precompiled cost I ask because I feel like there was already years ago there was already a repricing to reduce them by a large Factor because I think uh like Zach Williamson implemented EC Mo cheaper on chain yeah with v

trudel okay but okay so they're still very slow uh but that was already back in 19 or 2020 so it was 5 years ago um I I guess the the point is that um people are currently using b254 um like the rollups and they're not doing it sort of inside of the evm and I guess if if this is too expensive do they still stay on b254 there's a security argument but I I

don't know if most of them uh have brought this up like do they do they really care about the security argument right now I would hope so uh so I don't know yeah like I think there's grounds to ship this curve in the evm uh the security argument is one um again also I think this the bls2 curve is just sort of a newer curve that more people are using um and also there's a very important news case again of the consensus layer so I think I mean yeah it's I don't think we should really dig into shipping this pre-compiler or not

on this call um but yeah I can try to get in touch with some of the people we listed and figure out like API wise what it makes sense to them another thing to think about or ask then is are there other questions around the gas benchmarking that we have um I think there might have been one around the MSM and and how it works because there's a question of like multi-threading and then how that bundles into how we think about benchmarking the gas cost what were people's thoughts on multif frighting I think Jack

uh mentioned that you you're going to ship with multi multiple threads but Benchmark on single threads and I think evm um I think the the death team thoughts were uh along the lines of it uh being hard to uh have a benchmarking environment where you can uh accurately simulate like so so when the node is running live um we don't just have it's noisy right the the CPUs may be like drawn in for other things um and it's hard to replicate that in a benchmarking environment and then

uh yeah I think just beyond that it's just it's just work that that uh is is not uh paid for by the gas model um right uh I guess one consequence of this is that it there is no rationale to then increase sorry decrease the gas cost in the future right because let's say we let's say all nodes go up to like uh eight CES uh because we're only ever benchmarking on a single core even if msms become twice as faster in production you can't argue to then decrease their cost right

because he on a single thread they're same yeah sure yeah if we're thinking about the worst case then you know even if you have eight cause it could always be that you know they're busy doing other stuff so for the worst case I think we'd still have to think about the the single core performance um yeah we did the same thing for um benchmarking as well um and MSM runs very slowly with one core um like I think based on those results we have to increase it but um without the subgroup checks it's it seems fast

enough even on one call okay I see and uh I guess just out of curiosity if someone was to push an MSM algorithm that was fast on a single core meaning the latency was pretty low but on multiple cores it wasn't fast how do we gas Benchmark that like it's slower on in production because it's not made for multiple cores uh fast on One Core uh serial and slow parallel right um I think today it would be safe

to like let's say bench on two cores because even the Raspberry Pi 4 which we kind of MD uh when launching uh the conens this layer uh was already four cores uh I this brings the question uh what is CPU uh the earlier CPU that we want to support uh the slowest uh would be Raspberry Pi 4 Raspberry Pi 5 that we kind of use to uh uh do we want to make the eum uh decent on this Hardware so I think Mark and Jared were

saying that even if you have four or eight cores they could just be busy doing other stuff um um yeah uh this happens um when you for example you syn uh and you have some cores that do gossip but at one point they get stuck uh while waiting uh like maybe the processing is waiting for the network or the network wait for the processing to be done uh as well but I guess for me I prefer to bench on one or two cores uh to be conservative another dat Point here is

the sort of like standard machine that we do all the devops testing on is 44 so I believe I left to comment to that point uh on the PM repo and yeah that was kind of where that was coming from um but if you bench with go you can add uh dash dash CPU one and you it will run on a single core right yeah no I mean we can bench with any number of cores the question is like how many do we want to Target um and like yeah I guess there's a question of like well yeah okay if your other CES are busy that's a complicating Factor but that's really hard to

predict yeah Kevin in response to what you're saying about if there was a version that was slower with multiple CES I think we would still just have think to think about the worst case so what whatever is worse out of one core or like multiple core scenarios just like the the worst of all cases um you have to price based on that and Mark you're saying that there was an issue with the subpro checks like that was relevant to the benchmarking that you've done yeah so benchmarking on One Core um with the subgroup checks is is uh MSM is is too slow sorry G1 MSM specifically is too slow um so if we were to disable it

then that would bump it up to sort of an acceptable level or alternatively uh we could just increase the the price and keep the subgroup checks yeah so in my Benchmark uh the G1 MSM with uh two inputs I was doing uh 120 um megga per second and with 128 it fell down to 40 uh yeah it wasn't scaling uh as expected while uh pairing for b254 was uh always 200 megga P per

second uh so the the formula was really good uh for this one yeah but but but for praying uh pairing you for pairing input you don't do the the sub uh sorry you don't you do the subgroup check on for the for the second Point yeah g uh you have to do subgroup check for every points with pairings uh yeah but for G and pairing you the the group is uh the group is equal the the basically the points on the curve so for for G1 so but but of course for G2 you have to do the even the BLS uh 12 381 uh pairing uh

precompile has good pricing uh it's very it's constant uh even up to eight from 1 to 8 points um it's just that it's a a bit highly priced because I do 220 megag on a laptop CPU okay I guess where I'd want to start from is if we have you know the promiles mandatory subgroup checks and even on a single core uh it sounds like

if we do this then it sounds like the EIP is out of date in the sense that some things will need to become more expensive gas cost wise uh does anyone know what those numbers would look like uh I give some uh in the price suggestion question uh I can relink um directly to the oops to that part okay because then from there I would then try to get you know one of these ZK rollups to just give us like sort of a test Vector of what they would expect to like how they would expect to

use this and we can get final numbers on the actual gas cost and then you know it could be the case that this is fine and we're good if it's too expensive then we can think about ways to make it cheaper um and that seems like the way forward to me because yeah just sounds like there's too many unknowns to really make a call right now does anyone disagree with that approach yeah I think maybe my preference would be to increase the price of G1 MSM and then maybe just add these uh these a flag even like if it's just a dummy flag to MSM and pairing to

have the option maybe to disable it in the future even if we don't implement it now yeah that's reasonable um I wouldn't want the promiles I mean yeah I just the main the main thing there is just like the more we have the more complex they are the harder they are to test and then it starts touch un like hard Fork timelines so um it's also a pain to implement in ZK VM if you do Flags because uh one thing I I forgot is that when you do a a ZK VM or evm uh you have to prove all the possible paths

so if you implement uh the flag uh you'll have to do both uh with and without subgroup check uh uh for uh in the ZK evm a circuit that does both which is ex complex okay so I guess equivalently if we just kept things as they were then we could always just add an identical operation or identical operations without subgroup checks um and that would have the same uh effect uh that's true uh but the it means we have more promiles uh I'm

not sure how comfortable uh people are with uh adding uh what four more promiles um well I mean if we're worried about the number of precompilers then we could always get rid of the scal mile um and then we could just add the two more and then that would be the same amount of pre- compiles overall so I think it just becomes like a timing question like if we get to a point where we're ready to ship pectra and this EIP is holding things up it will be pulled out so I'd rather like not really touch

the high levels of this EIP at the moment um at least personally and then I guess like I in that case I would kind of want to think about this other option of relax vacine constraints in the future so that yeah maybe if it becomes an issue then we can say okay for the pre-compiled we have that are already deployed uh you can take the subgroups out and we also have the option to have um you know yes possibly other pre-compiled for subgroup checks uh and I think that would also work in terms of the Ford the you know forward compatible notion we were talking about earlier yeah I mean I guess the only thing is

we'd have to be careful about removing them um when contracts being built kind of assuming that they're there which is kind of why I prefer the idea of having identical ones that are different so just sort of a drop in replacement yeah right so then maybe we should ship without subar checks so get used to them but but then people will uh some might make mistakes and right blame us yeah yeah yeah no okay um could can't people use like uh um what are they called like open

Zeppelin libraries like e recover I guess also has some uh foot guns that and isn't a recommendation to just use open zaplin but it's extra uh mental load to oh be aware that you need to use uh checked arithmetics uh for you 256 be aware that you need to check etc etc and uh at one point where people uh are trying to get their audit ready they for forget thing um if they do the audit or sometimes they just ship to production and uh it's a inter and that push the button or

whatnot yeah I guess that's fa it's just that I when I think of anyone using these promiles I think of someone who knows what I guess I don't know who the use case the users are I just yeah but if you look at uh for example uh let's Pi Monero Monero uh Dev are uh V know cryptography Etc and back in 2017 they had a bug that could have broken their blockchain because they missed uh subgroup checks so we're almost at time also by

the way that's very scary for mon um we're almost at time so I will do my best to find people who give us somewhat of a Target in terms of things we should uh actually build towards like use cases I would then try to take the most conservative approach that I laid out essentially saying yes there are subgroup checks that the pre- compiles do we're on One Core uh and then kind of go from there just to see you know if it's actually too expensive for the users we have in mind and and I think that will give us more information to know which direction to go in um yeah does that sound okay to everyone okay

cool um any other closing comments one one next breakout then yeah um well okay so what what can we do it sounds like we can think about updating EIP uh right because it sounds like the EIP is a little out of date with this uh sort of set of constraints that we agreed on um that's something we can do and I think also uh trying to find some formulas uh for uh MSN uh well for the costs of everything uh um would be helpful as

well so that we can discuss specific formulas for the repricing the gas price do we need different formulas um well the for MSM the scaling is wrong uh for pairing the cost is too high um and I think it's fine to focus on BLS uh 12 curve because uh even if they end up uh priced lower than b254 this this will encourage people to switch uh which is um uh a bonus for security right I mean yeah I'm not

really thinking about the other curve um but yeah if it was somehow more attractive say economically that would be great so do we want to Target EC recover then as uh when we're coming up with these gas cost formulas uh for me I worked with uh like a Target um million gas per second and try to price to get those uh assuming like a laptop CPU uh from uh trying to get uh good performance on a CPU from 5 years ago

let's say so I mean we there's also other pre compiles than EC recover that we could potentially base this against to get a wider range of comparison and um I think you were mentioning for B Basu uh that there were issues with the granularity of EC recover and terms of the overhead of uh ffi um yeah actually and we uh we bumped our uh version of uh sep 256 K1 recently and that gave us a little bit

uh little bit of a performance boost there and really I think some of the some of the benchmarking uh test Suites that have been uh you know pointing fingers at basc recover performance are perhaps not uh not as ACC as they could be and we're seeing pretty consistent EC recover performance so that's why we went ahead and based uh our our initial cut at the MSM gas costs off VC recover cool I think G is fine using EC recover as a base um but yeah uh we are at time and at least I have to

hop um but yeah hopefully this was helpful and um yeah we'll at least get to this on the next ACD if nothing else uh and then from there we can coordinate on if we need another breakout or not okay cool um yeah see you good okay bye thanks