All Core Devs - Execution #85

Transcript

[Music] [Music] [Music] [Music] [Music]

[Music] you [Music] [Applause] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

Hudson Jameson: hello everyone and welcome to meeting

number 85 of the etherium all core developer call I'm Hudson and we're gonna start with the first item on the agenda it is the Berlin IPS that are confirmed getting implementation updates from the clients and seeing if there are any issues anyone's having so far with that so first I'll pass it over to James to run over the run over to go over the Berlin

AI peas

the ones that we've talked about so far our VIP two three one five simple subroutines for the EVM and EIP two five three seven which is

the BLS curve operations ones that are tentatively that may or may not be included are the two five one five difficulty bomb and two four five six time based upgrades so let's start with two three one five is there any updates

or bug in the go implementation how we had other opcodes were to find us mistakes in the test

cases have been updated and I demanded with one one more test trace test case [Music] yeah implementation wise I've seen that it's it was the start of an invitation imperative I think there's a new one brewing and we will get started on making the EPS cases into actual state tests based on I guess implementations that's it I think I don't know part at the end about their implementation they're the four opening theorems apps currently under review but hopefully she being sent home

Rai Sur: you mentioned adding a test case where the test case is not sufficient in the deep was there like some corner case or was it more of a

miss reading of the you know it was

Martin Holst Swende: just a clarification I tried that cases for everything that can be a bit quirky and one of the quirk case is how long it sorry sorry one of the cases that you might have seen at the end of the code segment and when you do return from that subroutine it should continue after where it left off which is outside the range of the actual code

so as

are those things that should be

added to the EIP itself or do they just need to be

yeah I just I already added them to the pizza dough just the clarification so yeah nothing really changed in the recently just clarifications

and then there's a parody and it gets somewhat implementation

Martin Holst Swende: yes

okay is there anything from base you yeah

Tim Beiko: we also have an implementation the PR is up still under review I think so we should probably have it by the next next chord F scholars should be pretty final

great

and as we're transitioning from talking about developing the EIP to implementing it I they we previously had updates why brilliant updates have been from authors about the IP itself but moving forward I'd like to get updates I go through the Berlin AI peas but get updates from the clients on the status so for so I kind of expect that those questions will that'll be on the agenda for the next few calls until we're ready to deploy is

never mind here Thomas yeah do you need to update on day two five two three one

oh five right so

Tomasz Stańczak: we didn't start implementation but I don't expect any troubles with this

yeah that's great we can moving on to is there other things someone would want to bring up on that topic or I'll move on to the next

yeah key

okay so four to five thirty seven is the BLS curve operations who do we have on the call for representing that or is what is the the status of implementation for that yes Alex is here

Alex Vlasov: well I can reserve as

far as they know at least denna has asked me to refer him to the implements implementation it's complete and it's updated to the latest spec which was changed due to general sentiments that's kind of to sever one precompile should be made into two for clarity perspective it else was updated to reflect that IETF draft was changed recently but reference implementation and goal implementations ago implementation by owner Sabo's follows and use pack so it can be just taken and integrated

so the questionnaire so the reference the IETF

spec was changed it's just IETF back well

Alex Vlasov: it's separate document and ITF work exam without asking anyone it was changed they changed the suggestion how to what to treat as a sign of field element because there is a selection rule for square roots and you have to select one of those it was changed it became much simpler and so but it would change the output of the function obviously so the code was updated choose this new version of the

spec

another

Martin Holst Swende: related to the existing stuff in it doesn't relate at all

Alex Vlasov: as far as I know and see in the discussion it's not a problem for Easter point oh because it will be they had they were based on even much much more previous and outdated spec so for them even the previous versions of the spectrum would be breaking changes so it's not a problem for them as far as I know maybe if there is someone else here they can answer if it's I'm not in Easter point or directly but it's at least what I know right now

so

Martin Holst Swende: one thing I think we should maybe talk about this is split into two eeap's it was proposed by Donau oxic was bit against it I don't really

know I refer to Alex Stokes but I guess it makes sense to officially decide how to how to go about that

Alex Vlasov: what do mean to changing it into two

loops well the operations into two separate ones 141 and 142 well

Alex Vlasov: just following the discussion in in a pull request I changed the mapping function which before the change could take other 64 or 128 bytes and output and output also

different lengths I change it to be explicitly two separate free compiles one taking 128

bytes and 100 thinking 64 yeah it was a changing that it sells implemented so right now pop interfaces limitation so I just thought maybe they

Martin Holst Swende: weren't on that discussion so maybe we should just decide in this forum if that was a good thing or not because Donna wanted it exit was a bit against it I didn't really know and yeah I'm just curious to hear if there are people who have opinions about it

I

Alex Vlasov: maybe I should clarify such a general sentiment from oxic was to not even well right now it's

9 separate recompiles sentiment from toxic was that it should be collapsed into one was another binary interface sentiment from Dana was just that previously it was 8 that one should be separated it's kind of eyes that we have separate functions or we have one with much more complicated binary interface because before it I think people wanted to have as simple pre-compile calls as possible so one call to one function and no internal routing I change it to separate ones but it's up it's up to discussion but I think previously the sentiment was also to split it as much as possible

yeah

Alex Beregszaszi: in

my comment I made it clear that would be the ideal case from me but I know that the sentiment was really in favor of having separate pecan pies so I don't really have any hopes that it would be collapsed into you one I just really wanted to you know never bring it up but I know that the the the this has given BLS pre-compiled in its current form is as an exact result of the same discussion that it was one one complex pre compiling it was split into separate pecan pies and so I don't think my comment would would be taken into

consideration anyway

alright

Martin Holst Swende: I thought your comment referred to only the most recent but I was wrong

do you want them I'm thinking about the you want to say what your reasoning is that for that Alex so we can just have that as part of the record

and we another exit ax ik Alex Bruce I see so

Alex Beregszaszi: it's coming from a developer experience point of view so for the the original for pre compiles

all D which is chateau five six ripe and the ec recover and the identity and those were supported by all the languages through language constructs but any new burp recompile wasn't and every case when somebody is making use of those freaking pies they're implementing their own way of passing data and the same image is going to happen with these nine or ten pre-compile we have seen one example of that done in the deposit proxy and the complexity

introduced there and my reasoning is that we already have this well well understood a B encoding used to read the system and I think it would be really nice to make use of that a bi encoding for the pre comp eyes because then you wouldn't need native language support but you could I mean native specifically with support for new pre comp eyes you could just rely on the standard ABI encoding to interact with pre compiles and the the reasoning test was brought up previously maybe even a few times previously and reasoning against using the API encoding

was that it's supposedly ambiguous but I think it can be made I mean the ABI in the encoding logic is strict but the decoding logic isn't but we can we can make the the encoding here quite strict so I think this this reasoning wouldn't stand but I guess the so I also made a comment there that even if we have multiple pre compares I would still prefer to use a version of the ABI encoding for the same reason but the last reason I mentioned why it could be

useful to have a single precompiled is looking into the future when maybe these pecan pies won't be pre comp eyes anymore rather they're gonna be contracts and in that case because there's such an overlapping functionality between at least some of these of new free comp eyes then you would duplicate all of them into two new contracts but this reasoning is probably too far-fetched and it shouldn't really be taken into account but the other reasoning about the using the ABI encoding I think that's about it is

the ABI encoding something that kid was but

at this point I think it would be hard to go back and and be able to meet to eath to stuff to get done so

just from a practical perspective going backwards I don't think it's really a good way right now but it's an ABI encoding something that can be resolved later or had like a ABI encoding

for these pre compiles that developers could use for a better experience there can always be implemented references normal yeah and do all pulls internal packing just obits help as from my memory martin the the primary reason to split them is

is for security and ruin reducing surface area for vulnerabilities so maybe the middle in between is to have the pre compiles in the ABI i am particularly looked at the actual format of the inputs to these pre compiles and yeah i I don't have names I think it sounds ok to use a BIS input format yeah I also think that we should keep them in the current format

separate pre-compliance though not doing changes there ok

so we should add a note to or maybe Alex you know x'q you and I could talk about getting something about the a/v eyes to be more for what did you say it like the inputs need to be more strict

Alex Beregszaszi: I mean it is possible to specify a really strict version of rules was still being capable of using the API encoding yes it is but actually you just want one comment going back to the original question which was

whether the Dupree compiled for was it like mapping well anyway the the question was whether it should be a single one where it determines the operation based on the input length or there should be two and each of them expect a specific input length and I think with the e be your encoding those should be also separate because it makes the ABI encoding also more clear and so probably my preference would be also to separate them

and I think we're in agreement about that great is

there any other thoughts on this from the group

Alex blasts off as far as spec and implementation and stuff like that how is kind of timeline or the amount of work that is like how finished is it versus not finished could you could you give spin just a second to talk give an update about that this is in contouring to schedule

yeah well I mean as I mentioned

Alex Vlasov: as far as I know the well right now they're at full to full implementations which were done specifically for this pick compiled and kind of a legacy from 1962 and those in rust which I did and another one in go which did was done by owner and site as far as I know goal implementation by

done by owner it's now also conforms to update its crack so in this sense those are complete I also started fuzzy testing surpassed code for now it's only being tested separately so just to find internal box with a lot of internal protection since disabled so far for like a day already I didn't catch in crashes later I will continue to cross test one versus another but at the moment I would say those are ready to be integrated

so what's what what's left to be done as I guess another question

okay well

Alex Vlasov: what's

left to be done is just cross test some against each other well integrating of just by facet test well I mean from it was out of the equation yeah it's fuzzy testing for integration it's not to me it's to client

developers and

so cross tests need to be finished before integration starts or is that something that can be

sincere person can be started I think my no integration can be can be started already

yeah

Alex Vlasov: integration can be started already fuzzy testing will continue anyway and it separately parallel and in any case fuzzy testing will not affect the binary interface and

Gasper

Hudson Jameson: you're having a bit alex Vlasov but i think we got the idea

yeah

I thought that was my internet so it's good thanks for letting me know Hudson so perhaps we leave next meaning to get an update from clients on plans

for integration or is that something we should talk about now Tim you have something

say I mean for basically we've already started to look at it like how we can integrate the matter labs library as part of base you and it's you know it's still a work in progress but it seems like it shouldn't be too complicated and in the next couple weeks we should have a we should have it in okay great yeah probably guest perspective I don't think anyone was gonna work out and never mind I'm expecting an interest and then open a theorem

Artem Vorotnikov: I think we had a poor request to merge 1962 but I think was Alex and it was closed today is not

merged by the author I didn't really look why but other than that we have no progress here

I see

yeah well I did change

Alex Vlasov: I did close a pull request for 1962 as it's not going to be integrated I did not perform any integration with parity for 25:57 so it's ideally I would appreciate if OPM developers can just do it himself taking into account so that sneaky forest library and it's just easy one to feed the inputs to the functions which

take bytes and output

byte great

I think that's good for that EIP is there anything else someone would like to bring up on the BLS recompile the IP back so the next one so those are ones that we've already decided as going into Berlin

and yep I was gonna say real quick I think I want to go ahead if you don't mind James and skip to the quilt item just because they have to leave in

half an hour and once we get rolling on the EFI it'll probably just keep rolling so good well yeah so quote team just take a minute or two and explain what you guys are doing to get everyone up to speed yeah cool yeah this should be pretty quick so we included a link to our implementation rationale doc which goes through some of the benefits of a minimum implementation of account abstraction so this is originally suggested on the theory magicians forum by the taluk so we are moving forward on doing implementation on that and gasps there are a couple research items that we still need to figure out but most of

the main questions are already answered for this minimal implementation at least so we are going to move forward on that and we'll kind of keep you guys up to date the data that we get everything there and we'll eventually go through the formally IP process a couple of things to keep in mind so we've largely quill has largely been working on execution environments and a lot of things under a two phase two we've were focusing some or some of our efforts on this right now is it's a kind of a strong way to iterate on some of those things we want in a long term for this kind of merged eath 1/8 to

ecosystem and account abstraction some of the other things that we linked in a doc SSA and other pieces are like a natural iteration value that can be added right now to kind of get to those get to those so yeah there's there's four of us we'll keep you guys up to date on what we're doing and yeah just say go through that dock and if you guys have any cues questions just ping any of us on a quote team yeah all right thanks so much anybody have any quick questions about that this is for getting into account abstractions into eath one so like free

eath to implementation yeah for now we're focusing on eighth one and and then we have in that document we have some discussion on then what we do then to begin bridging some of this to eath - oh that's great yeah first step is on eighth one very happy to hear that this is wound forward and I'm sure Mariano is gonna be happy about it - sweet alright and then yeah

Hudson Jameson: we can move on to EFI now where's the agenda well do we can go back and forth on this

I can do the first one you do second I do the

third cuz you are or no you do first one because that's yours isn't it well I I I you moderate it but I I can talk about sure so

Hudson Jameson: first one is EIP 2515 for the difficulty BOM dia related to Berlin so I think that's James right is that what you did okay yeah so he can go right ahead

okay let me get the I updated the terminology

the feedback that I got last time we talked about this in February and January and then we haven't really talked about a sense on the call but so I'll give a general overview and find the link for the updated I think that's

in the can someone grab the link that I put in the awkward OHS chat and then put that into the thank you Tim so the the idea is to do pretty much the same thing that the difficulty bomb has done except for say that it will start on a specific block so you in a X number blocks in the future you say at that point freeze the difficulty and an increase by 0.001 percent each block perpetually so you get that do you get the effect of the difficulty increasing increasing block times and making them and doing all the same things that the difficulty bomb has done we just know exactly when it will happen the updated

design was having that linear increase happen instead of just freezing which is which is a better design so I've updated the EIP to have that information the last one thing to confirm is is it something that the group wants and then is that and if it is is it something that we that can be done in time for Berlin and the current open question is do the the increased function of difficulty should it be linear like purely linear or is 0 0.01 zero like one thousandth of a percent sufficient or from what which of those are preferenced

so going back to the group on general sentiments and stuff I did a lot of pulling them and talking to people on Twitter about it and so I've since reduced it to being what it is now so feedback on the design or change

I think

Tomasz Stańczak: James that say linear growth is a big dangerous because it's disconnected from the actual heart rate growth and it's potentially being exposed to miners reassigning a lot of mining power and spitting up the block creation which is against really the idea of the the difficulty bomb I was I was thinking

about the solution I mention it to once to you about changing the target block time instead of changing difficulty because one of the parameters of the difficulty calculation is the one that points us more or less at how often the blocks should be created so I was suggesting to grow this parameter and then we know that the whole thing will behave as it should behave so it will be automatically adjusting the block times depending on the hash wave hash rate growth or fall at the same time we'll achieve the goal of the difficulty bump so they the blocks will be longer and longer and they'll be growing ideally linearly with each block and you

still can adjust based on your main design idea of starting a particular block and having predictable time when it launches

yeah the so it does there is a potential that if it goes off the miners could rush and then they would they would rush into the end of where they no longer can catch up so the the it'll have the same effect as an eventual obsolescence of the chain because no one can mind it because it's too difficult what blocks will be so slow that it won't be

Tomasz Stańczak: but we're talking here about linear growth so with the miners we assume the exponential growth of the hash rate so there will be never

a time when they will not be able to catch up

oh

there also will at some point never be a time even if it's linear I give it doubles in about 15 days which is the current algorithm

then so

Tomasz Stańczak: no it does it doesn't matter because the thing is you remove from the equation entirely the hash rate from the previous blocks which means that you leave just a linear growth and the hash rate will be growing potentially faster than linear even if the miners do not do anything specific do you expect that the hash rate growth will be extra linear

oh there has to be some limit to actual

amount that can be done and this is it this is assuming that there that we're not working to fix it so perhaps this is an argument for having it remain be exponential so not linear growth and having it be a percentage of the last block

Tomasz Stańczak: as I say but just just leaving the parameter that targets the block length and changing this parameter would be enough and then we stay with the behavior of the function and adjusts based on the hash ray and then we're not risking that suddenly it will be more than we planned or less than we planned it'll be just linear growth of the block x which is very predictable

and something didn't want to achieve the I don't

I don't know enough about client

implementation to know which one of those is easier to put into the client

I'm

Tomasz Stańczak: not talking about client implementations at all sorry I'm talking about deuterium the the algorithm is there the defined algorithm calculating the difficulty it's taking into account the previous hash block sorry previous block time and adjusts based on the previous block time the faster the blocks are the more of the adjustment they'll be and I assumed I if I understand properly the algorithm is a linear curve which removes entirely the previous block time from the algorithm suddenly they the growth of the hash rate becomes linear and this is risky

because whatever miners do we lose the control on adjusting the times of the blocks based on the previous block

times that

to clarify the new the new design isn't linear it is it is an exponential curve that start it just starts out at a certain point at a certain difficulty so and but I do I am curious as to the group because the in the in the code itself it checks whether it's less than 10 seconds or greater than 20 seconds and then it has a a in effect and the mathematics of it is also kind of a little bit hard to

to parse so is changing those variables over just having over having a extra linear increase on hash rate over time is there a preference to the implementation I get that for me both of those end up in the same place in the case that it is and it's not as a super linear or whatever you want to call it equation or if you're increasing the time they both get to the same place so I would be curious from the client implementation side which would be a preference it's from that is the design they're both good

and

Tomasz Stańczak: implementation is

really such a simple thing here that's just fine liner the difficulty calculation sir I think we should just discuss the the function itself whether it's correct risky or what's the outcome will be in the end and I think that any function that tremors removes the previous block time from the calculation I wouldn't be happy to introduce such function to the difficulty

boom

can I get some other thoughts here like perhaps Martin or the basic team on preferences

or yes

Martin Holst Swende: I need to ask a

question first so with your the proposed the first one that you proposed what would happen if there was a large increase in hashing power as the linear thing started then the linear it would rise up a lot

faster right yes we would not adapt the block so there will be quick quick box

Martin Holst Swende: and the linearity would rise very quickly where else with what Tomas proposes it would to the hashing power more gracefully

right it sounds that sounds mean like perhaps a simpler model to to keep using the time instead of just block numbers but yeah I'm I don't know it sounds like it to me

all right I mean I some help on changing the design I get I'm making sure I get that right it's my concern like that that can be resolved

Hudson Jameson: I lost my link here okay so that one then I'll just cut that would be more discussion offline I'm guessing

yeah well

I get so if is there more people that would agree with the preference that it having just addressing time would be a better function here cuz I'm happy to do that I just like to know that's the direction I should go from

like the group like is yeah I think that would be better than linear increase like like mark emotions uh what if there's a large heart rate miners coming

in so I will you know problem for I seen the problem for the crunchy that bass you you have any thoughts

Tim Beiko: on my end one day I would just like to see if we're looking at these different models is like if there was a way to graph different scenarios and just kind of give a high-level overview like kind of like Marlon said what happens if

there's an increase in hash rate and and whatnot I know the the EF team have done that for 1559 I just shared a link in the chat here something similar to that I think would would be valuable also as we're discussing this with the community to see like hey you know this is the current bomb here's why it's it's bad here's this different proposal here's what happens if the hash rate increases decreases you know the kind of basic edge cases

yeah but I think well so one thing that I think would be illuminating the way I see it these two different things that we're discussing right now is that in one proposal you have block numbers on the x-axis and on the other

proposal you have calendar on the x-axis and I think would we do we preferred linearity of graph with time on the x-axis we want linearity on the graph with block numbers on the x-axis another I think is a key difference between what were discussing right now Thomas is what would you respond for that

Tomasz Stańczak: I understand but I don't know how exactly I'm just trying to find the plot that you were

using whether there was time or block number on the x-axis generally um I think that what we want to have is more or less we want to target their axis like take those two approaches to be equal so like the growth of time is more or less similar to the growth of the block number on average and then for the difficulty bump you actually want them to start diverging so they over time the while the the time is expected to be stable the block number will be expanding and then the plotting would be with the time would be better with the growth a more or less I would like to have the block time on the y-axis and

the time on the x-axis and show how the difficulty bomb would cause this particular chart to behave say I want the difficulty bomb change if we decide to change it because it's not like I really need this change then I'll like the block times to keep growing and then we want to see different scenarios whether we assume the linear growth of the block time or the exponential growth of the block time or like step by step as it was in the past like an exponential of steps these are the functions that I would like to look at and then I would like to adjust the difficulty calculation function to lead us to one of those preferred scenarios so I see I see margins pointing like

mentioning how we would like to chart it and how I would like to discuss it

it's

so I'll work on charting and so we can have a better discussion about it and then we'll have that be done offline

so that's all for that Hudson

Hudson Jameson: okay sounds good next up we have the time based updates ew 24:56 that's the one that Danno did and then I forgot who took up on that if anyone

I can

I can take over for this one okay so J's we had two calls ago I'm Jason Carver was on and we talked a little bit of

this and we arrived at a this is my read of the of the group and and if I'm wrong on this please correct me but it seemed like if we could do time based forks that that would be preferable the issue is if we do it with the current uncle rate uncle rules then we have that to have a look back function for it to be safe and that's not preferential for due to some to client developer user experience and then also user experience for contract developers to fix and the other option is to fix the uncle rules

and so that you can have just a time and not have to have a look back function but that seems to be possible yet complicated and so the the what's left for that EIP one by will will need someone to chance to champion moving it forward and to understand is it desirable enough from the community or the people that would want it that it's worth the trouble of putting in and I don't know the best way to answer that last question that's kind of the status of

Eddie IP

Hudson Jameson: is anyone championing it

not at this point

okay

Hudson Jameson: I think it should be dropped off from discussion if no one's championing it since that's one of the requirements for something like this to move forward in the first place and otherwise it's just gonna slow down chat

Martin Holst Swende: yeah I agree we think discussing this every two weeks and not really making any approach

just having the same back of course yeah I'd say yeah if this if the

Hudson Jameson: if someone wants to be a champion on this feel free you would talk to James me and Danno about it or really either one of us three and we would connect you where you

need to go to be the new champion on it

next is the IP 2046 reduced

Hudson Jameson: gas cost for static calls made to pre compiles and the last time we talked about this we had we were talking about how we can how this measurement has been done and open etherium and was found to be safe to you know reduce those cost but that it would need to be looked at on different machines on different different machines and different clients if I remember correctly and then there was some a lot of discussion on oh we can lower this these other pre-compile costs and we can raise these other cost so I don't know

if we concluded anything last time that was like a substantial next step other than to say that the Blake to cost is higher than cat check and that would be discussed offline I'm not sure if anyone took up on that or not and also that improving gas cost of like two may help the move to state less aetherium I don't think we had anyone who could confirm that last call so this is just going over what was discussed last call about it I think this is AK 6e IP and he's champing at am i right or is someone else doing that Alex

so you know only caught my name is

Cherise you're talking about 2046 yeah basically saying

Hudson Jameson: are you the champion currently of the CIP and are there any updates to it from your end from any discussions you've had

yeah I

Alex Beregszaszi: probably am a bad champion of it and and Alex Vlasov has done quite a few benchmarking steps we discussed it on the last call but I think neither of us have have done I mean I mean in the last Oh perhaps two weeks ago but I don't think neither of us have done anything to incorporate those results into the IP okay I think that tests the status yeah you probably

still don't have like a final idea what would be a good proposed where you what Alex did was benchmarking the pre compromise to make sure that none of them would be a risk if we were to reprise the aesthetic call and the finding he had is that to pre-comp eyes i if i recall correctly ec mole or you see ed and so I think these two are slightly under priced so they would need to be increased

Hudson Jameson: Martin did you have something

Martin Holst Swende: yeah I think I took it upon myself to do corresponding benchmarking

yes no okay that sounds good so tired I guess yeah I just wanted to ask Alex we also had doing these benchmarks for base you kind of on our to-do list I just want to make sure we didn't get to it we just want to make sure it's still a valuable thing for you you asking me or Alex blasts off are you I mean either right but you were sticky about it just recently yeah I mean I listen it maybe isn't it mainly for you as a note implementer it's valuable to you have those to make sure that a note

will be able to keep up regardless of what what prices are so yes sorry and and I guess on the last call there was a discussion that maybe lowering the prices even more and I was just wondering how like how those those uh I guess ideas were moving along like well obviously once we implement it or what a benchmark and make sure that it works but it does it does it is it valuable if we say beds for I can try to find what's the lowest possible price that works and that's you know and and bring that back at the EEP yeah

Alex Vlasov: well if I may add a little i started writing much more

radical proposal in a sense that we should really reprise all the pre compiles by like having more soar approach to it and also be more restrictive what would be performance differences between different clients just because for example an implementation in which is used by open cerium is definitely is just very slow compared to everything which exists for last two years starting from the worktop seed cash and now implementations of 1962 and there I wanted to include the proposals that we actually make call to

the precompile to be 0 and always absorb the cost of doings gas estimation into the precompile cost itself so it will basically increase constant contributions but we will now pay a reasonable price for what precompile actually does and this potentially will make blake viable and there will be also there will be also changes to catch a pre-compiled to better reflect its internal structure that actually doesn't make any difference between 0 and 100 cent weight 28 bytes but I'm not done with this back yet

Hudson Jameson: I really like that idea of doing a broad sweep of all the pre compiles and seeing what can be adjusted to make it more efficient and clients to more not efficient well I guess efficient but also as like fast as possible and clients any other comments on that at this point I think for this one we'll talk about Berlin timing in a second but it doesn't sound like there's any we're kind of just still doing some

measurements right now and then this new IP is being developed by alex last Sauve so that is the latest for that one

so I mean particularly well yeah doesn't have anything to do specifically but if he does one that's like would supersede it then that would makes that would be something that could make sense

Hudson Jameson: okay so the clients just need to do more tests or the measurements that sounds good so that's all for EFI James do you want go over Berlin timing

yes were pretty close

to I'd like to kind of a good estimate of what the implementation were in the integration time it would take to get the BLS CIP done because it sounds like that's the one that would take the most work at this point is there a sense for how long that would actually take from the clients I guess that's something we could say it will be done in four in four weeks and then we can have a chestnut running for four weeks and then we can hit go on the fork

Martin Holst Swende: yeah I don't know what Peter says I would say no sooner they cannot be

integrated before anytime sooner than four weeks what would you say Peter

I mean are we talking about the single Yankee or a single appear with nine pre compiles beerus created bill as 1281 curve operations so so i probably me something but our current timeline is based on just having two yetis in berlin rights so vo is one simple subroutine

that and possibly the difficulty bomb

one if it is simple enough to have in but it not something that we should push back anything for so those two plus maybe the difficulty

people on and I think it'd be better so

Hudson Jameson: from what Alex blasts off said there is a gov'ment ation and arrests implementation but it hasn't been closely looked at by the client implementers it's just been implemented outside of the the poor client implementer team is that accurate

yeah okay

Hudson Jameson: so if that's the case then until they look at it I don't know if there's going to be a good estimate as

my guess for that one for simple subroutines that's something that they have been or that most clients have been implementing or have implemented and we talked about that earlier and I think I think most people said it was on its way to being implemented and it wasn't too too bad right

yep

okay so rather than say how long let's do the list of priorities like we did last time and just say that the BLS 12 381 curve operations should be a priority unless someone disagrees so that we can by next time have a better idea of Berlin timing and we don't kick the can down the road

anybody opposed to that or have any comments or alternative ideas

Tim Beiko: maybe just like highlighting both the eeap's like if I guess clients can look at 23 15 and 20 and they BLS one and and yeah try to get the implementation started if possible and then in two weeks we'll have a feeling for how far along they are

yeah

Hudson Jameson: I think that's the best we can do today in my opinion anybody have a different opinion how does that sound James this is kind of your

no no no

that

sounds great to me

cool all right unless there's anything else we'll move on to item number four this is e IP 2565 repricing of the EIP 198 mod exp pre-compiled and I believe that was before

before we do that should we just say out loud the process point for the time based one so that can be recorded yeah it came up a lot

because oh yeah sorry I forgot what she IP that was okay you were talking about the thing we talked about in chat right on the road doesn't zoom okay yeah so

you

can go ahead for the record

so we

it's come up because it's on the berlin list without a champion it doesn't make sense to move it so I'm moving to remove that from the berlin list but keep it remain as efi with the tag for a request for champion and we'll see if someone shows up but until then we don't need to talk about it on this call my motion for that

Hudson Jameson: yeah sounds good to me and if there isn't a champion this is something that the e IP IP meetings can look at for the process flow of something being made into EFI and then losing a champion because we don't have a process flow for that right now

okay going back to the IP

2565 repricing a mod exp precompile that's Kelly I believe

Kelly Olson: hey everyone yeah so I just wanted to take a few minutes to introduce the EIP to 5 6 5 as Hudson mentioned it is a repricing of the mod X pre-compile which is e IP 198 VIP 198 was introduced a couple years back by Vitalik for modular exponentiation operations which are sort of a foundational arithmetic operation for a variety of cryptographic operations I believe vitalik introduced it for RSA signature verification we've been using it for vdf proof verification and it's also relevant for things like snarks and

accumulators in a variety of sort of other cryptographic operations as we started using this I'll just share my my screen here shortly what we saw is that the pricing of this EIP which you'll see these blue dots here was significantly more expensive than some of these other pre compiles on the order of you sort of hundreds of millions of gasp per second whereas other pre compiles you know most recently the Blake to EC recover are all sort of in this 20 to 30 million gasp per second range and so sort of the core of this proposal is to change a single parameter in the pricing formula in a IP one 98 from a value of 20 to 200 and

what that would do is it would shift this sort of blue curve here to pricing in line with this yellow curve now so we get about a 10x reduction in the cost per operation and it still remains sort of more expensive than some of these other things like the Blake precompile and EC recover but provide sort of good practical for this pre-compile with very minimal implementation changes so basically just changing this parameter from 20 to 200 we did explore other ways to improve the efficiency of this precompile so one of the things that you can also see if you look at this is that we did devise a a more accurate out pricing

algorithm which can sort of be seen here for different input values into the precompile versus the existing one so you can see we have an r-squared of like ninety percent versus twenty percent and this is because this new algorithm better relates to sort of how the lim based arithmetic is done in big integer libraries currently we're not recommending making this pricing change because it is I guess maybe has a higher implementation cost than just changing that parameter although it's certainly something that were open to and wanted to get some feedback from from folks on and then finally I guess the last thing I'll say is we did also look at the

efficiency of sort of this pre compile in the library that's used today versus some other big integer arithmetic libraries there are further gains again here by switching out this underlying library but again this is not something that we're recommending at this point because it has additional implementation complexity so the overall summary is basically what we would like to do is change a single parameter in this e IMEI P 198 pricing formula from 20 to 200 which will bring the pricing you know closer in line to you know some of the other precompile switch around this 30 million gasp per second

Martin Holst Swende: I have a question sure so those benchmarks that

they did what what was the underlying implementation

yeah this is using the existing GAF implementation so these are all yes these are all using death

Martin Holst Swende: because on old benchmarks we did see that mod X could be like cut in half at least on death but apparently was actually or under protest and there was a note that they did the exponentiation by squaring plan to optimize it I have no idea if they've done so much they still do exponentiation by squaring so yeah I don't know how how if these benchmarks

that you have shorted out in the EEP are actually sustainable

entirety

Kelly Olson: yeah that's it's a great question Martin it is something that that we looked into we haven't run those benchmarks yet we did notice though that since no sense the CIP was implemented I believe that there were you know some changes to this pre-compiled I'm not sure if that was the underlying library or maybe there are more cosmetic changes but we did see that at least there were some commits against short of this pre-compile in the codebase so I think you know we we could certainly look at it for parody as well to see you know sort of sort of what they have and and what their benchmarks

look like

Alex Vlasov: even while I don't work in parity client I looked at their implementations before and the problems there at least before was I'd say they use the native big integer library which is kind of standard thrust library for this and internally this library uses 32-bit limbs instead of 64 or modern processors which makes it highly inefficient wellguess uses native go library provided by Google which uses optimal lip service so I think simple update or center line library would be sufficient to parity

just bombs the version yeah

Kelly Olson: thanks Alex that's that's

great feedback and I think you know we'd be happy to take a look at parity and either run the benchmark or or come back and you know crowd any updates on that if folks would like you know as I sort of shown here there's a variety of other benchmarks that that could be used like or other libraries that could be used like GMP or open SSL so you know I suspect that you know similarly for parody there there are those hopefully hopefully their library is already efficient enough to sort of absorb this this gas reduction but that's something that we can add into the EIP is is a benchmark on parity

Péter Szilágyi: so just to point out something so probably

if you start using open assets and stuff like that the reason they will be a lot of esters because they will probably use all kinds of sin vs SAE AVX etc instructions which as far as I know go does not use but the downside is that you are pulling in a big soup of C code and also like using a bit of portability so for example if understand that we are using for example open SSL if you have open SSL installed and use it as a shared library usually everybody is fine so if I if I have a VX and great my open SSL will be faster if you don't have

that yours will be slower but go does static linking so if essentially if we build gap on some machine which has a VX and then you try to run it on the machine which doesn't have it then it will blow up and if you do it the other way around then you just lose the performance so you get you right you start introducing these kinds of strange

bills time constraints right yeah no it's a great point I mean I think you know just to to reiterate you know our our hope is that as we go benchmark parity that you know right now at least the repricing doesn't require any change of the library under death right so with no sort of underlying library changer or

pricing algorithm change you know it still stays sort of in line with the pricing of other pre compiles you know I think our hope was is that we'll see the same thing for parody so as Alex mentioned maybe there's a simple version bump maybe the parody library is already using you know an improved library from the you know versus the original benchmarks you know we certainly saw in the case of the in the case of gas that got about 2x better and these are just from underlying improvements in in the NGO bigint library essentially math /big which i think is what what guess is using now so you know it's it's highly likely that you know parody has also seen similar improvements and so i guess at least at this point you know

maybe the action item is to benchmark this for parity and to to see if there you know in terms of speed are on par with jeff and if so then the recommendation is just make this very simple parameter change from 20 to 200 and not change the pricing formula or underlying libraries okay great I mean I unless there are any other questions I think that's it so I think you know maybe just to reiterate next steps we'll take a look at will go and run the benchmarks for parity for the test test vectors that are there and then we will take a look at what that is sort of what that implies from a sort of a gas per

second for a parity you know ultimately our goal is to keep this pre Kyle you know ensure that this free compile is more expensive than sort of the other precompiled right so we're not trying to move this down below like pricing of ec recover or the plate to pre compile and if we can achieve that with this this simple parameter change then and that's what we'll be advocating for all right

Hudson Jameson: awesome one last question and you might have said this and I just missed it but this repricing what is the ultimate goal of this as far as

like use case goes yeah sure so modular exponentiation is sort of used in a variety of cryptographic operations so verifying RSA signatures

verifying verifiable delay function proofs accumulators RSA accumulators as sort of a replacement vs like merkel routes or something like that verifying snarks so there's really sort of a broad number of cryptographic operations that will benefit from this repricing okay awesome anybody else have any comments I just want to say that's a great justification and this is what we love to say for every single EAP it's kind of few sentences that tell us why we change things also give the community they'll review why we implementing things

Kelly Olson: thanks appreciate it

and thanks for the feedback everyone we should save it for the

VIP IEP meeting yeah actually Kelly where's that posted uh this the CIP it is just under the IPS not a theory about organ oh I meant the

Hudson Jameson: the document you just displayed on the shared screen

oh yeah that's it's that is the iake actually so I just place it in the zoom link here oh okay

Hudson Jameson: sorry I thought it was I got a PDF or something

okay cool next up we have VIP 2602 disabled null hash message verification for ICI recover pre-compile and I forgot oh that was a way yes yes oh so the background

is we had EC recover pre-compile and that pre-compile basically does signature verification and sip to 561 a curve so the thing is is we also just learned like last week on this so the same is so the pre compare we have is actually pretty low level and and it allows the user to directly pass any hash the bugs and it turned out if you pass the new hash which is basically

just zero zero zero zero zero zero zero then it turned out in this case the signature can be forged so so it's a it's not safe to use easier cover in this case at all to actual to actual like crypto seeing is actually that if you use easy recover without a proper hash function and the whole thing is just physically unsafe so with a proper hi function there's nearly zero chance you get new hash but if you're if the

contracts are doing something weird and just happened to have a new hash and this simply comes and sees so with so yet he actually just just proposed to just disable verification for new hash like I'd also when wind to message hash with the unturned is easier compile the messages message hash is new hash then we basically don't we just return false just just do the same thing I spend the EC recover receive an invalid signature

so yeah so there's basically so there's a nearly zero zero valid use case for new hash I do and it's actually possible there's some contract might have missed use that because I mean for the free comparative default parameter is new hash so if if the contract forgot who pass as the message in some cases and they you can get into these tracks and we actually fund our to contract on the call it has net that tries to validate a

valley signature against a new hash message so that's that's entirely on says yeah and and here so I think I think is in is okay sets this is a easy with her function is pretty low level it does specify the hash a dope but I just think is is good if we can encourage those effective road construction so just disable those and save seeing especially those accessing that ice no zero no valid use case in the block ten yeah so yeah that's a

pretty intricate introduction about is yeah T

Martin Holst Swende: sounds good

Hudson Jameson: anybody have comments or questions about this EW intro

thanks during this week

Alex Vlasov: which could be potentially usable or used by some contracts already I just was looking for a link for it you know in a chat so if you just disable using this error message cache it can become a wallet I think that this is up to implementer if you don't like

it should be posted as security vulnerability and contract developers either should upgrade or should never should put an explicit requirements to not have their hash if they actually want to verify the signature and not to use any facts around it but forbidding it right now may affect properly properly working contracts which actually wanted to use this

Tomasz Stańczak: I wanted to erase exactly the same thing that Alex mentioned about the existing contracts but if we if we can confirm that this is not the case if there are no contracts to do that now then maybe it's worth to

to fix it the way

we suggest okay can explain more so it's a valid use case of new hash well freak was posted by metallic a lot of time ago Alex you're breaking up sorry I cannot do any thing with my turn right connection but if it doesn't improve just yeah it starts improving okay let me try to read was anyone else

gonna speak upon waste question my mouth can you expound on which Alex Martina think I'll exposed it

Tomasz Stańczak: link in the chat that mentions one of the use cases that Vitalik was suggesting

donates research so I from my understanding this looks to be a way to get like cheaper cheaper like gas price for so it's so easy and

or you see a new operations like by abusing they usually recover so something like that from understanding well

Alex Vlasov: it was a treat posted by metallic to not abuse well to not get cheaper operation I mean you could always write elliptic curve point multiplication or addition a solidity contract and then yes it will become expensive but there was no any form of precompile which allows you to do curve operations over sick P curve so this was a clever trick how you could abuse it to get a multiplication function and addition

function was kind of cheap you could implement it in solid eating so I don't know any exam solid examples who uses this but since it's an old trick maybe someone does but I don't think there is any way how we can verify this no one does use this trick it should be considered more pre-compiled vulnerability in san notes a pre can file the particular contract vulnerability than in principle say pre-compile or vulnerability

Hudson Jameson: okay anybody else have any comments

well you can check

Paweł Bylica: you can check if it's used by implementing the check in there in the crowd that's saying the blockchain from the beginning

yeah I remember I remembered we didn't like this this one was actually due to concerns this issue like we had on Idaho presume master crunch so so the upstream tidak didn't update so the ICCP to fax came alive we did an update the rust library data update and I did this new hash message tech and we

sort of needs that for rel so during that time I don't think we broke two magnets but we did fund like wire to contracts on the porch and in the goalie last night so I still don't know what they are doing or are they just are they using this tree called or is it's actually like trying to actually verify a new hash message yeah but I I'm not sure about the either but yeah so so the thing is we we had we had new hash message in Goleta as well but I don't think we found any other ballots yes

like and this from our knowledge okay anybody else all right

Hudson Jameson: next up we have VIP 2583 penalty for account trying missus that's Martin

Martin Holst Swende: yes so I talked about this two weeks ago the idea has been expanded a bit with some alternatives and in general I'm curious to hear if I know the developers feel that I've taken it looked at at this and have any thoughts

about whether it's worth pursuing I personally believe that it most definitely is denial service protection yeah so people please do you have an opinion about this

Tomasz Stańczak: I was looking at it an interesting step to take in exploration also on our research on stateless clients and it's charging for the tree access from weakness generation so even even if we in the end don't implement it in the form as its suggested it's definitely worth exploring and even playing with it and shaking what the outcome is

Hudson Jameson: if you just said it's um good for stateless

aetherium is their coordination being done with state the stateless aetherium team on this or is this something that wouldn't be applicable

yeah context okay however as I said it was from markings message on the stateless aetherium channel sorry marching for interrupting no problem now it's gonna say that

Martin Holst Swende: I see it as something that should be implemented kind of as soon as possible may not because there's a pressing need for it whereas for stateless is more of a research project that can be taken one

step at a time and I'm not sure if they're I mean I think there's a pressing need for it and I'm not sure if there's enough time or interest from the I think people are working on the status tough or have 100 problems that are going to be solved eventually and this is maybe a priority number 95

Hudson Jameson: okay that helps me understand it a lot more thank you

as

Martin Holst Swende: from my perspective it's like one of the most pressing problems on mania right now

Tomasz Stańczak: I mean definitely in favor of this monster that's it's a good thing to

understand I just mentioned that you will be also a great addition for stateless if you're about obviously there the timelines in the research group are totally different

sir yeah a way prepared to

Martin Holst Swende: do you guys have any thoughts about this

proposal or animal from another area not not not really I mean it's a

Wei Tang: it's not hard for us to implement so

Hudson Jameson: Martin is this something that I know last time we talked you didn't want to move to EFI yet is this something you'd want to try to move to EFI with today or does it need to be cleaned up more

Martin Holst Swende: it doesn't need to be

clean up more about I think it needs to be get more input from 432 variants so the initial proposal has a floor that makes it if you put the penalty above around 7 or 800 it can be bypassed so there's no point in doing that where else start to alternate here which changes decide it's a bit it also makes it possible to set an arbitrary high penalty yeah but there have different downsides because they'd break backwards-compatibility in different ways yes I think we should have

somewhere I just want some more discussion on that and not necessarily decide I'm only if I or not right now

yep

Hudson Jameson: that sounds good anybody else okay we have about a minute left I think that gives us enough time for Dimitri to do a quick testing update

Dimitri if you want to go ahead

Dimitry Khokhlov: oh yeah one minute

I think a new approach that we could take on testing and these are go teams there was a proposal up

Hudson Jameson: you're cutting out Dimitri we can't hear you

anymore to implement a

system transaction and state refresh and some is an idea it's a concept I concerned your link for discussion and and there is thing to implement it with a core team as I say they can support this approach and I think that having a tool that can produce a state-transition can be useful and easy to implement them on client depth so they don't me just try to do it and see how it goes and I would like to hear feedback from other client developers on what do they think about this approach and how difficult it would

be to support for them eventually yeah and I'm standing right now in chat

Hudson Jameson: great if you could write that all up in chat because you cut out a couple of times suppose the link and write it up you cut out enough that like just rehashing that over text is gonna be a great idea

okay I sent a link to chat so there's a discussion I invite developers to discuss this and send some feedback how how difficult for them it would be to implement okay thanks so much we are

Hudson Jameson: out of time do the e IP IP survey please if you haven't done so we really want a good

amount of core developers and e IP editors to do it but also anybody who's ever looked at an EIP can do it so I'm posting that in getter I'm posting that in YouTube chat and I'll probably post it to Twitter once again so please participate in that if you haven't already and we will see you all in two weeks

on when they oh go ahead point Oh process did EAP two five six five the repricing of the Mata X go and efi or is that something we should do next week

Hudson Jameson: next week at minimum because it just got introduced

alright

perf and

Greg Colvin: Hudson ah no discussion I just like people to know that I've taken over as champion for the prompt eow proposal

Hudson Jameson: okay that sounds great you said with Christy or of Christy's proposal

Greg Colvin: with Christy's blessing

blessing okay you know champion

Hudson Jameson: okay great we will talk to you all on May the 1st at 1400 UTC in two weeks thanks everyone goodbye

thank you handsome boy cheers all [Music] [Music]

[Music] [Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.