All Core Devs - Execution #84

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] hello and welcome to the etherium court

developers call number 84 we have a pretty neat and tidy agenda this morning that doesn't always happen but luckily James who couldn't be here today broke down all of the EFI VIPs that we need to get updates on so the first one has a good amount of comments in the agenda itself but we can show a lot of that we don't need to go into the super super technicals but if we can just get an update and get any questions answered about a IP 1962 and it's BLS signature working group updates is there a couple people in here who could speak

on that oh well I can speak only for a reference in Boston plantation yeah and the spec itself back itself was actually finalized I think in almost two weeks ago and it's still not merged I don't know what was the reason otherwise the rust implementation is now complete in a sense that that passes also like it passes all the tests for basic arithmetic properties which will good expect for for implemented functions plus test packs on the test vectors from IETF spec which we actually implement

for mapping into the curve point so it can be served as a reference and can be considered as completed excellent anybody else have updates on that can anyone speak to the implementation and if it would be ready by it isn't I thought this was the one no I mean 1962 weak channels I don't know it's apparently considered to be fi but I think what's been actually included in

like a short-term future is the more narrow down recompile for only some you're right I thought 1962 was a narrow down version is it no it's still more or less my authorship so I actually was for speaking about 2537 which is now considered to be a girl coming to you know like to be included in Berlin instead of 1962 so 25:37 is the one which you said is basically finalized has the rest implementation and all that right yeah yeah okay thanks okay perfect I'm gonna put a IP - 25:37 so if you refresh the

notes it now has the right a I P number for the BLS signature working group because that's people have been calling it the BLS signature working group a little bit and that's 2537 right the more narrowed down version yeah i means i mean more viable yeah yeah and so as far as when berlin goes we can just talk about that really briefly is that something that would be ready by like what's it today april could we have that done by this month or May to start like getting all the e IPS for Berlin ready and then moving that forward to the next step of the of the process I

cannot talk about for a go implementation I mean usually Sayed who is doing to go implementation listen to the skull but he never participates which is kind of strange but I think he also made the corrections - I mean he also made the implementation and elimination was the last function which is mapping of the field element into the curve point so I think his implication is Elsa either final or close to final so we can I will chat with you personally and we can start fighting okay yeah let's start the fuzz testing for sure or it's the

one that was ongoing but now it's gonna be restarted B as the specs final and or the the implementation for rest is final - right well yeah now is this pace up from good parameters is much smaller so it should be easier to test okay that sounds good and thanks for talking to him that that would be very helpful is there anyone else who has an update on that piece because it sounds like we have rust and go is there anyone from [Music] that makes sense so so oh and mastermind

is yeah Thomas is there as well you have an update yeah just just phone to add a little comma I think there's I remembered your sir but I might be wrong but I remember there's also an implementation peacefully implementation in Javas yeah in Java so they definitely use some BR I's every here but I'm not quite sure about that but just fun to say so it shouldn't be a problem for nearly all languages that are currently being developing is to team you're asking about nanomites

not a problem on our site at all we already have the if to be allies findings we also can use if needed some simple spell bindings for whatever is used by other clients same for rust so well so does it make sense to move this accepted and try to get the clients to start working on an implementation like it seems like obviously we want to do this like we all have you know some kind of small things to figure out but it seems like generally it's it's doable for every single client is there a reason to not move it to accept it I was actually under the impression that it already was eligible its efi right so

it's like and isn't that yeah so so what more do you want so i I thought accepted was like all the clients kind of have to do it if I yeah it's a good idea except it is it will be going into a future hard fork or at least at the current time that's what that means yet it may the what hard worker goes into would be undetermined in this case we can say it's going into Berlin and then hopefully it gets into Berlin though instead of just saying it's eligible for inclusion and whenever it's in and it's got tests and it's working oh this is just a process statement it's

nothing else than a process statement to say we're moving the EIP from one status to another this isn't to say it wasn't accepted from a general sense before this is to say we're moving it from one state to another in the IP I guess yeah for more of like a practical implication is it's like if we all agree we kind of do this and we do it for pretend and yeah it makes it not easier but like just I guess hi every priority priority for us to implement it to contribute the pests and whatnot so I just want to make sure everyone's on the same page here which it seems like it is like it seems like everyone wants to do this and we should kind of get it implemented in all the clients right yes I it to me oh thanks for picking that up Tim I'm back

my internet died it does that every once in a while I'm gonna blame the new router I got I'll have to fix that all right so after that we have the EIP 2515 difficulty bomb James isn't here to talk about that so we might have to skip it unless there's anyone else who has any questions or comments about the implementation or anything else about it okay VIP 2315 simple subroutines for the evm that had some updates from Martin I think and maybe Greg mm-hmm go right

ahead either of you so I can go through a bit what has changed recently well at least changed my proposed changes which have not been merged yet so there are mainly changes to how the LD EEP is worded but some kind of structural changes in the first version there was this concept of a stack which was not quite fully articulated a return stack and it was pre-populated with the value that would be outside of the actual code size so if

you did a return sum one time too many it would return to to a location after the code which Greg meant would be because by infinite zeroes and the way I changed this that doing so would be an error instead mm-hm and what else I updated the test cases and this is now implemented there's an implementation of this in death there has been some discussion about if we should prevent walking into a subroutine

or not and there has been no really strongly argued either case so as of now the spec still allows walking into a subroutine which basically means that you just increment the program counter and suddenly all true subroutine there is no machine error we're doing that yeah I I don't think there are any big changes to it yeah I didn't I didn't see anything really

substantial given that there's no no previous implementation to contradict and I didn't didn't much see the point of forbidding walking in the de subroutines and we're trying to just get the very minimal mechanism here and not trying to enforce very much at all on flow of control and walking into them is is useful for multiple entry points into a subroutine and no point in forbidding them I think Martin pointed out in the VIP that if you want to forbid them you can just put a stop statement before

each one so not that hard to deal with and it might be a feature so it to me it looks really solid I'm really happy with it okay so this is implemented in go would this be something that we should potentially move to accepted state today Greg and do you know about any other implementations or should we just go around the room I'm not aware of both okay what so let's say open etherium has

there been any work done on this not to say there should have been or anything just has there been no no no yet we have I I have a small working progress just Kearney to say I say no there's no implementation yet but it shouldn't be a problem for us okay BAE see no okay I get it shouldn't be a problem either but we haven't started working on it never mind as long as we have the usability for Asus already assume or

members like a team of replication Terran and it's fine excellent and then a less if you're in the room I feel like that's Ben doesn't know less I guess but maybe not well Greg did it in in one of the C++ EVM implementations yeah yeah well I'm not sure about the laughs I mean we effectively stopped working on you trying to stir so that kind of this up to the question if we're going to

upgrade to the next heart book at all no this I I started into EVM one but it's it's not complete it's just enough to to see how hard it was to do yeah but it's not EVM one which isn't really a client yet okay am I missing any other client all right let's move this to accepted then unless there's any dissent and we'll put it in for Berlin along with the 23 25 37 as far as 2515 goes the difficulty bomb

we'll have to talk about that later so I'm just questionnaire so this PR that I've opened for 2015 subroutines should we just merge it yeah yeah that sounds good to me unless anyone else has a different opinion and you're saying merger at the heat like the EIP repo yeah update the original by Greg with my proposed changes yeah I think that would be good yes yes Martin please do right Thanks

sounds good all right 25:20 that VIP 24:56 which is time based upgrade transitions I think that was Dan oh and I don't know who picked up on that if anyone did I think Dan was kind of leaving into the side but then James really wanted it that's probably true so if James isn't here we can actually not do that one this time I know Jay Jason Carver I see you're on the call and and I know you had like a bunch of thoughts

on on the eep so I don't know if there's anything that's change or that you wanted to share regarding it so I wanted to add one thing so I think ever since the the time base upgrade came up one issue that I think haven't really been solved was the fork ID thing and I'm sorry I don't know if anybody actually fixed that or not if not then then there's definitely one potential blocker

of the CIP because the fork ID is kind of kind of important especially for test nuts because every time we do a hard for test that's fall apart because it's just a mess of peers so that definitely needs to be sorted out is that something you want to sort out before Berlin but what I was saying is the time-based upgrade changes and makes for cadiz impossible so as long as for as long as the IP is not fixed to support for Cadiz I don't think it's acceptable okay I think Peter there's another option we can we can potentially just fix pork ID

I mean change not fix it's okay but we can change it it wasn't very used so we can actually look at the implementation and decide to change this back what it means first of all you've been live on gas for half a year yeah it's it's - undermined as well but I'm saying just it wasn't used unless you assume that it was used in private chains or some sideline but I'm not following what do you mean it's not used it's used on every single handshake that you make yeah but it's not introducing anything that we couldn't change backwards really yeah I guess of course if there's a way

to support have forked I support time-based things yeah that was kind of my point that it's a challenge that needs to be solved I mean we can change whatever as long as it works okay thanks for the comment is there anyone else who has comments on the time-based upgrades okay we could go ahead to Berlin timing now so as far as the timing for the hard fork we have at least two important key is that are gonna be going in to Berlin

at this point we may also have the difficulty bomb going in depending on what James says I didn't think there was any other he IP is close enough that people wanted to go into Berlin that were at the point of discussion and implementation am i is there anyone who can think of one or who has one to bring up it would probably be in the ERI list if anything I would I mean there is a this is always 2046 in agenda maybe we should also try to fit it into the Burling okay oh wait 20:46 is in the agenda we're already fi well I mean because oxy kind

of stopped to push it forward I am since the last call we kind of agreed that it would be good to redo some measurements and I did the measurements and so on also quicken piles at least in in openness you know oh it's on now we can kind of proceed with it okay that sounds good and that isn't just to for everyone to understand that change from an implementation level is just adjusting numbers right well they say EEP itself is just proposals we change coal price to the precompile from Ford and from 700

to send like 40 which is which was confirmed by Martin said it's a reasonable number but we need to check precompiled do not get under the hood implies 700 price in Syria gas measurement in gas schedule for moles at least for open assume it's not the case so it would be safe to remember to reduce it but we can also kind of tempted to with discuss if we want to read price kind of also exists in Baku piles because it's it's kind of a free outcome since it was confirmed just you read the process of measurements the

kind of the numbers we shakem guts are much different from what is currently in pricing for almost every precompile so maybe it would be good to kind of maybe I can make a simply separate proposal but we can still discuss it today okay that sounds good let's do that so yeah like you mentioned we could do a whole separate of hope proposal if we're gonna reduce a bunch of gas cost and then that would supersede 2046 for reducing static calls the gas cost or we can just reduce static calls gas cost so what what do people think about just doing it for static call versus not

doing it at all versus doing it for all the pre compiles no no I mean right now the proposal is to reduce the static called to pre compiles and kind of calls to freak about sorry sorry yeah yeah yeah so the questions there was whether it is safe or not or maybe there was this kind of compensation for the 700 hidden somewhere in cost of creaking files which right now only life if you remain that as a result of measurements I can say that it's not the case for almost any everything I would suggest to do with pricing of one pre-compile to kind of compensate this change from 700

to 40 because i found quite a large difference with the current pricing but for I mean the pre pre compile cost of BN edition right now is a little lowers and I would suggest but for many other pre compiles the cost was found to be much higher than the computation time which it takes at least on my local computer based on easy recover metric and maybe we can either continue to discuss this like all together or I can try to post a formal improvement proposal to reprise also the pre compiles it sells up to discretion

but for for a part which is reduction of the price very pre-compiled I would say we should accept it and implement it because it's it looks safe so I know a tactic I would suggest you to not mix all these changes into a single EIP I'd rather keep the the EVM change on its own I'm not sure if I if I care too much whether the the rest of the repricing is split into individually IPS or not but I don't think the EVM change should be mixed with the

repricing pre-comp eyes and there has been also a a new draft this week to reprise modaks pre-compile and I'm not sure if the debt free pricing has also quite a bit of benchmarks presented in the draft I'm not sure if those results match at all with the the benchmarks done by by Alex but it's worth considering goes for a tea I think I didn't measure mod X because I knew that this change would come that this EEP would be made by someone's person I

talked to Kelly who actually did and let all these measurements for mod X repricing and they also didn't have any internal compensation for the current 700 gasps cold cold cost to pre-compiled so it's also safe for mod x pricing I like when you're testing it is it only one coin that you're testing it against or different implementations I tested it on open cereal but I mean just the nature of the cult functions as far as I mean hash functions should have very

very very close performance in every client and for cash phaser is the short answer is the only method on Oprah third period yeah yeah as a short answer is yes but more or less just because I I'm not proficient proficient yeah that's fine you can go or Java a job especially that's so cool was that your point Martin or did you have another comment from earlier yeah I know that was my points so yeah there's still some work to do in my opinion before we can

move on repricing them as for the original EEP 2046 I guess I mean I I can do some measurements on gif and see if it kind of makes sense to do that's stand alone with another repricing but it's gonna take a bit longer to reprice to check if if every pre-compiled what they can say say lower - okay I should clarify I mean my point was that at least from explicit test on open cerium

it looks like Karen price you know pre compiles will not be broken by inclusion of 2046 the kind of safety included but as a by-product I have found that recompile costs are quite different from what I have found and formula which I have got and just wanted to rise his point to developers and maybe someone would tell them we will need to do such measurements from other clients then it would be reasonable that he makes his proposal and fixed pricing of speaking battles yes however as you pointed out the Vienna the imperative of ethereum would actually be affected if we drop to

700 and change it to 40 or 50 or whatever it is currently on the price because I don't have a memory of us saying that yeah well or a batalik saying that yeah well whatever we have the 700 there so we don't have to we can go a bit lower than what we should well yes these three changes should ideally go together but it's only for additional recompile which is it which is very different from two numbers for which in so numbers which I found in parity or openness you very different from the current pricing

for others those are either higher priced higher than the numbers which I found or are in a good match so it's it's a minimal change I can make a formal leave to adjust it together okay um yeah if you go ahead and do that and we can talk about it next meeting and see if it would be worth it is it worth it between now and then for you to recommend for anyone to run on their own clients um some testing to see if my brain isn't working to run some testing

to see if that pre-compile cost reduction is worth it or the static calls well every pre-compile will benefit from this just from the points of calling the precompile will cost less so precompiled cost itself will not be changed and it will finally make sense to actually make the rounds blake compression function because right now it costs 12 gasp to run it for blake to be but it costs 700 on top of this to actually call this function so it will finally make sense to use some of those pre compiles the

other parts which i found are just general optimizations which will benefit smart contract users for example in reification of merkel pass or sha-256 hashes but it's kind of secondary improvement I would basically said there are two things that the clients implementers need to do one is to measure if the actual you know invocation invocation of a pre-compile an empty pickup I'll basically the M the identity pre-compile and doing that in a loop and seeing is it reasonably are we reasonably efficient enough to do that

whether they propose for the gas even if the actual PayPal doesn't do anything the speed of the round loop the second thing is to measure the actual execution all the break compiles and see okay so if we remove this 700 threshold are the pre compiles efficient enough or would they need to be booed we need to give an additional threshold on the actual sum whatever P compiled because I know I mean Jeff has assembly optimized BM stuff but not everyone has that maybe and but those are the two things that I see should be done on the clients you

know I think this was a the main reason why I was asking certainly agree with marking we have two totally different cases of new cases but parts of the same problem one is how efficient different implementations are in placing cannot recall on the call stack and I think it should be fine but would be great to measure it if there are any significant differences between different implementations and the other one is just measuring the become four separately okay are there any other comments on this okay thanks for running those preacher those static call analysis tests I think I'm saying it right Alex and yeah if you

want to make a more formal VIP for that that's fine or for the other ideas that's fine and then otherwise week 2046 should that try to go into Berlin then is there enough done on that that's kind of what I was thinking from what we just discussed no I mean we would still need a confirmation from Isis flags yeah this is very very important one actually if we if we manage to decrease the whole costs for the things like mistakes or any other compost this will be hugely beneficial to produce contracts it's great work I think we just need to put

some more work to confirm before it's all my property okay other clients I just have a question about this either forty like engraving stone or if it's something we believe or would depending on testing testing I would say I mean we can modify the EEP let's tweak it a bit right but it's still a number required to runs a function which estimates the gas cost itself at least you would have to run this function now of course of course my point is that I have this the Blake to compiled in mind and knowing that right now it's more expensive to

run break - when blink - it should be twice as fast as key check is at least twice as fast a check is surprising to me well it wouldn't I mean with 40 gas as right now in proposal it will not become cheaper anyway unfortunately it's exactly that's my point that's the reason why I'm asking if the clients could when they're doing testing with 40 is it engraved in stone and could be more than go lower because if you basically we go to 20 or 30 then Blake to start to be like make sense and we can a lot of yeah a lot of route of work has been done to improve like relate to efficiency outside of the ruction space and and that would be amazing for many

many application for merit reason and verification or even for state leaders you to an extent I think because of the call stack we would have to include some kind of up code for Blake in order to get the same costs as you would expect from catcher I mean apparently that was discussed before is this is out of the question so I'm fine with any price and just bringing this up because it could be I think a very efficient hash function is fundamental for many many use new use case from state of the film to America to verification to fry to many thing that if the point wants to do well in for hash functions most likely

the only option is to make up code because for exam is the most difficult part for gas estimation functions is the one for mod expert and it actually takes quite some time so for this function to run safely you would need to put something like 40 gas like 1 microsecond of execution time depending on your machine for other pre compiles their cost estimation functions are so trivial that you just need few nanoseconds if you have everything closed in the cache lines so for this the only solution is most likely to have a separate of opcode

or to have more complicated solution like different cost to call in different pre compiles but this is would be most likely too much okay so that sounds like it would be worthwhile for clients over the next few weeks to run some more testing for 2046 so that we can try to get that into Berlin is that is that kind of where we're heading yeah I just want to make a comment about the last thing you said Alex so actually before the gas doesn't have to cover the

cost the dynamic gas cost estimation function it only needs to cover the context switch because once you answered gas cost calculation you could immediately check does he have at least I don't know 200 to pay for this calculation otherwise you just exit with an error and Ito's whatever gas so you can always check they do the easy checks first so I mean theoretically we could set the the cost to 20 if it context which allowed you know that we could do that could be fixed okay no no I just

meant that even I mean human if you do the context switch and I mean even two runs a function which estimated gas for Moto X which is the most complicated one you still spend some quite some time on computations right you can just raise the threshold on that particular raise that the non dynamic gas cost of that one oh you know just do makes it constant to absorb the constant in a so as you enter the gas cost estimator you check does he have 500 guests to pay for this estimation it's not than exit than a your own waste another second anyway okay I wanted to yeah go I had to make

one comment regarding the somebody said that Blake - seems to be so much cheaper than Ketchikan I'm just looking at the numbers here and I think it's it's a tiny bit misleading if you just look at the numbers because the Blake - is only the inner loop and not everything else around it which is the case where every other hashing function we have a zip recompile and in essence no matter how much you reduce the the call cost you're always going to need to run multiple I mean in any any useful case since each round is emitted 228 bytes you may

likely want to call the pecan pie in multiple times so it's highly unlikely that you can make it cheaper then catshark as long as it's a pre compiled so maybe it would have been better to to introduce the original version of Blake - which worked like all the other hashing click on by - yes well I guess it's too late to change it now what is the particular structure to play cash I thought you just I mean you would have to run the compression function but in short input you should only run it once yeah 128 by the inputs you could I mean

at least for most like is a most common use case it would be sufficient like at least binary Merkle tree but yeah right now it's not possible and even current metering approach to Blake compression function is actually questionable but still it's it's the same way as a ketchup cashing a check meeting function is kind of invalid from its internal structure but we can discuss it on Gator okay anyone else yes actually I have a question now that

I'm thinking would it be possible I mean this is just a very large question to the client to give with the imaginable to sort of keep a pre compiled in scope after like the first call because it would be immortal if the call could be amortized over Beauty parlament like in sensation and will be independently of the of the course we're going to implement so we could imagine having more use case for the existing to come back I think that's an abstract Charlie I don't like it so one one important limitation of acting the blade I'm not

sure a lot of the pre compounds is that for or and sorry the B and 256 that so this was really weird for example a paring operation a dating the input takes as much time as actually running a paring operation and so if you want to run three bearings then essentially your pay you're paying for six so if you if you want to reuse the result of a previous one you need to do a lot of validation but I and I don't think you can really get around this to paying for this it would be super complex to to somehow track in the EVM that sub result will be but essentially the result of one operation he's already

valid so you can skip some pre-processing on it so I'm not sure you can really gain things without really really really dangerous optimizations okay thanks for the for the replay okay anyone else okay now we're at Berlin timing when James is back I'll let him go into more detail but I think personally it would be really nice if we could do Berlin by the end of May if not just mid June and I think James had some ideas too but I

don't want to speak for him yet since he is doing most of the work talking to teams and figuring out where things are at but yeah do other people have comments or ideas on on that front well I assume the reason you're saying May and June is because he too is I guess tentatively planning to have the deposit contract around June July and we want 25:37 before that's correct yes that is one factor didn't we discuss this last call and go to confirmation from the two little guys that this is it's not actually like they're depending on this

in any way shape or form they are so it does go ahead tell ya it doesn't depend on it but the pre-compile allows you to verify I assume that the ETU address is correct so it can basically make it easier to prevent loss of funds by you can you can have kind of a forwarder contract in front of the deposit contract that checks your your to address and and only forwards the Front's of the deposit if it's valid so it's it's kind of a very nice to have yeah okay thanks any other comments yeah I don't think we should schedule

anything before we have finished oops okay yeah that's a good idea who else had a comment someone spoke up all right what's me husband oh hello as I mentioned release date like implementing this building Harford in May or like early summer before actually yeah like Martin said speaking about that we need to freeze all the EMP implementation so we can cover everything we're testing yeah and a few of them are frozen from a specification perspective so for instance 25:37 the BLS signature precompiled the

narrow down version of 1962 that would be used for eath 2.0 that one aspect out completely simple subroutines for the EVM needs to be updated but that's pretty much SPECT out from what I can tell what Peter is saying is nothing nothing of this exists merged in a client today yeah yeah that's true okay yeah cuz I thought he meant like been finished specification wise you're right as far as clients go go ahead we need to be sure that there's going to be no changes and they can start working on the implementation and testing okay

sounds good and I guess maybe one other way to think about this you know you have you can like trade-off between scope and time so would we rather have a Berlin which is more likely to ship sooner but only has 25 37 or would we rather try and get a couple leads bundled together at the risk if perhaps shipping later and I'm curious with what people think you're on the call like should client implementers just focus on 25:37 get that over the finish line before you've been touching anything else how parallelizable do we think this is yeah and I kind of agree with Martin that we

won't know until they're there actually I guess all I guess they are an accepted state so yeah totally I mean very very like concretely we could say okay people just do 25:37 you know let's not look at the EVM one right now it's not even considered 2046 benchmarking until 25 37 is like fully implemented in all the clients has some tests and whatnot right yeah anyone have comments on that okay I'll just leave it to James to kind

of go through and assess this because he's been looking at it closer than I have and keep in mind that we are doing a new method of process I suppose the EIP centric forking so we don't like a second ago I almost got caught up in that we need to do timing on this but really we need to implement the IPS before we can before we can do concrete timing at all I'm a bit confused regarding 25:37 and the deposit contract which was mentioned and the same sentences is 2527 related to the deposit contract at all I I was under the

impression it isn't what I mean what it allows it first of all to be LS are different parts the premium well is to add BLS 12 381 elliptic curve operations which are just generic set which allows you to do snart's privacy and verification of parent based signatures unfortunately the parent based signature Multi signature also has a name of pls but just different P and s in authors and this bill s signature is done over this B list of curve and it and it's

what is in Eastpointe o multi signature validators over the state so it's required to have for each to point out deposit contract in its full power but it's not the only case for this freaking well but I was under the impression that the deposit contract the proposed deposit contract has been also audited and I would assume that it was done before the CIP was proposed so I'm not sure if there is any dependency but but maybe there's a new version which depends on under P console it's not a Dependencies it just allows you to verify some inputs to the deposit

contract as I understand it so because you can validate if you can validate the pls signature on 8th one I assume you can make sure that it's correct and that the the data you're providing in the contract call is is right and that means that you could set up a contract in front of the deposit contract that checks that before sending your funds and so the deposit contract works but today I think you could put it doesn't do validation on those parameters because if one can't read those curves all right because somebody mentioned that the maybe Hudson you mentioned that

the deposit contract may be a plan for this summer and if if we could roll out some of these including the 25:37 that could be beneficial to the deposit contract maybe just for a general audience including me it would be nice to have you know what you guys explained just now I've written down somewhere and and maybe based on that functionality one could also select a subset of 25:37 which might be easier to roll out by the deadline or it may not be but at least just having this indication what is the

connection between the two I think that would be nice to have I just posted it in the zoom chat Alek Stokes has been working on this he wrote a medium article and I just copy pasted the relevant paragraph in the zoom chat here yeah that's the one he posted within the last 24 hours so that one's yeah real new so that should give a pretty thorough explanation I think was that would that answer your question Alex if that article has these of the explanation yeah I mean I guess I don't need to read it first

of Mercia for me I think a nice addition would be to see what exactly what parts of this precompile would this verification use how what would they basically saw that it could be that uses this well what parts of it it will use it will basically use the mapping function like the last one in the list for its proposal is a paying function and most likely it will use multix initiations in a one group and few multiplication multiplications and additions in another one so it will basically use a reason yeah as far as I

remember yeah I mean is this is from judging on how Billa signature works itself so when you mention multi exponentiation multiplication and addition you have it for both G 1 and G 2 here and so you meant that it's going to use all of those well Els signature allows you to have ambiguity in a sense you can aggregate public keys either in g1 or g2 it will give you a trade of I see we have a larger signature and cheaper aggregation or you will have smaller signature but more expensive aggregation so it's up to you final implementer how they do it yeah both both options are valid yeah I guess my

final comment regarding the D plan times in like end of May for Berlin and I think there are a lot of really nice proposals in terms of VIPs for Berlin just to name a few the EVM subroutines this one all the repricing but it seems to be a lot of changes which it doesn't seem feasible to be done in a month so probably we need to make a selection okay yeah yeah I don't know if we explicitly need to make selection but yeah it might be

good ideas Tim said to set the priorities as far as priorities go what what are they does anyone have a suggestion for what should be prioritized well I cannot judge anything about the complexity of subroutines and how to implement them but well just from so I mean because this 2567 is very small subset of 1962 and zebra were

already nine to six to two implementations tested on them in a much larger scope I mean the code base is is there and like and thrust and go are like at least 95 percent ready as they can be used by other clients as just a libraries the C part is more challenging but it can also be improved I mean the piece is only one function is your suggestion to use the 1980s 1962 our code base but each of the clients would implement this limited interface of 25:37 but still use a 1962 code base to

accomplish the actual operations yeah I mean that 1962 code base and its functionality can be kind of downgraded to say we don't want curve to be supplied in real time we just hard code one curve and just run all the existing code and arithmetic on top of the single curve which reduces the number of edge cases a lot so it's now fine to except if there's a freaking bomb I mean it's not I don't say that it's the only way you can always take another specialized implementation for Bill s12 381 and just do also say using this other implementation it's just and

everything you will need on top of is a binary interface but you could easily takes existing implementations which implement every single separate function in this proposal because some implementations may or may not have multi associations for example and some of them may or may not have the most recent version of the mapping from field element to the curve because there was a change in IETF spec around three or four weeks ago and it may or may not have been implemented okay if I were to pick which ones are important I'd say at

first place is 25:37 and second place is 2315 and in third place is 25 15 but that's just my just from looking at it I think that the 2537 is probably high in importance if if the EVM one is well specified and it's done I think that's all so it makes it easier to do it sooner rather than later because if like for 2046 which we were talking about earlier all the different clients need to run benchmarks kind of figure out

which values make sense and whatnot that seems like it's it's just gonna take longer to coordinate then all of us implementing kind of the same spec so that would be my personal the difficulty bommai I haven't followed so I really don't know so yeah if client implementers are looking for priorities here as far as coding 25:37 I think has kind of been roughly talked about as the number one priority and then 2315 seems like it's very spec down and ready to be implemented actually I was just reading this blurb

regarding 25:37 and the deposit contract and this this blurb suggests to me that the deposit contract will remain unchanged this audited as it is but people would be encouraged to use this proxy which does the signature verification in front I wonder if it is any plan to get the proxy audited which seems to be kind of hard to do if you don't even have any kind of code accomplishing that and it also depends on a pre-cum fine but if it's not going to be audited and then we're we're sending people to use this unaudited

contract for deposits I mean on unaudited proxy I don't know who is exactly responsible for Eastpointe or deposit contract cuz I'm not but it wouldn't stop them to have the proxy contract audited even before the precompile is accepted because I mean the set of is the functionality of the precompiled binary interface are fixed in the spec and like and the cryptography of verification for signature and validation of all think links can be audited so I just from it's okay you can

make a solid contract once again that cut out a lot for me you might have to repeat like the last 15 seconds oh sorry I mean to answer is about the strategy of this proxy contract you would be the person who actually does this and I'm not and I'm not responsible for this but if nothing stops them from auditing a solidity part by just treating the pre-compile as a black box which does these arithmetic operations for you assuming this if recompile is valid it will allow you to do so to do the audit so I don't want to you

know make this conversation too long and so maybe my closing comment from my side would be that if we are prioritizing 25:37 for this reason that we should really encourage I guess the e 2.0 teams to write this proxy contract and work I guess with you guys on 25 27 because if if that is the reason for priority then it better be ready by the time it's deployed well it's kind of unfortunately that well it's kind of Prairie the sentimental priority is that well east

pointer needs it but it doesn't reflect that increase police still want to but yes every question we can continue after so don't get me wrong I think it's a really good feature and it's explaining that nerve so I think it's a really good good feature and it would be really important for the deposit contract but it would be really nice to actually have half this this proxy okay so does everyone have kind of a good idea of the priorities now is there

anyone else who has comments okay Martin do you want to talk about EIP 2583 penalty for account try missus yes thank you so this e p-- tries to address a shortcoming on all the current implementations of notes due to how our state try has grown over the years and previous efforts to address this has been to raise certain gas costs which are now 700 and woody page and 84 anyone 50 and that half doesn't really work for

us because what we would need to do to address the worst-case scenarios is to raise it by a couple of words of magnitude more and we can't really do that unfortunately so what this does is it tries to enact a penalty whenever you hit a part of the try well a missing account in the in the try and it effects the all the ex topper Asians including balance X balance so whenever you do one of these operations on an inexistent address there will be a penalty post operation penalty and it would also

affect the cold turrets however the colder bits would only be affected if you call into or cold referring to something which doesn't exist in the try and also doesn't don't some value and the way this has been designed it means that it won't disrupt existing contracts because yeah there's really very seldom a reason to call something without sending it an a ether and then not expect things to go badly

whenever you do that when you're doing Xcode Herricks cod sighs or call it is something which doesn't exist you normally want to exit your flow at that point solidity has built in to do an Xcode size check whenever you do a regular call just to see that it doesn't suicided and if that makes code size check fails it doesn't really matter if they go out of gas where it's a river with some other reason right AB today with the on a 10 million block 10 million gas block it would be possible to do around 14,000 try lookups and if

we were to add a penalty to that about thousand we could lower it to 41 percent and increasing the having a higher kind of it and that doesn't really make sense because as Peter found there's a kind of attack to this another mechanism which you can do whereby you invoke it by another call so that in the end you can you can escape the penalty but pay an extra 750 or so in gas so yeah so this is this is one proposed

so to deal with state attacks which has the downside but it's it has upside but it doesn't disrupt a lot of things it hasn't downside that it can be partially bypassed and passed notes we can't just raise the penalty and get it more efficient that's the unfortunate side effect so I wanted I was hoping we could implement some kind of protection either this one or some alternative variant pretty soon hopefully by the next hard work but their bid so I would just like

to hear people's opinions and potentially start the discussion on other alternative ones I know that yeah x''k pointed out that there have been some discussion in the stateless stateless ethereum click about having some kind of global penalty counter which can also serve as a witness size counter later on and such a scheme you could have some view if you made in a global penalty counter and whenever the penalty counter exceeds the remaining gas you would basically stop the whole transaction schemes like that could be implemented they would have other side

effects on layer 2 for example a multi sound where a couple of the recipients and they would no longer limbed I mean previously if you do multi son and his son recipient 2300 gas all they could do with is earn that and return with an error but with a global a refund counter they could do more they could influence the global states and burn more than those 2300 they could yeah start chipping away and making the whole outer transaction right so I guess that's the next Avenue

approach and see explore that but at least so I'm put this out for public now and yeah I'll be glad to get feedback I don't know if maybe we don't have talked talked about time to talk about it in depth on this call today but I think this is an important problem which we need to look into so may have a short question about all this tech because I mean you want you make a penalty when you call non existing contract with amount equal to zero

yeah but the problem is the available amount it's like 10 in a minus 18 issue um it's negligible but still not zero and yeah maybe that's not so greatly explained but if there is a transfer of value there is already an additional nine thousand gasps added to the cost okay yeah well insist keys yeah sure and if also if the coldest nation does not exist there's a twenty five thousand guests like onboarding easier so we I sent you thousand tokens and it checks

your balance is CEO Jason doesn't have any ether so let's just convert five hundred tokens directly to ether instead and send it to the his contract so you know I send you some tokens Sal you have both some ether and some tokens you can immediately use your tokens that is one contract that actually would be with yeah they would be affected but the I mean you just have to pile up some more gas on that that's a really really expensive thing to do because they incur the the 25,000 gas for since your country your address doesn't exist

they also incur the 9,000 for transferring ether so they're already I mean they have already high gas costs to do this kind of transfer and if we had a little penalty of thousand I really don't think it would affect them in a large way okay so I guess with this penalty the point really is that if you are doing something legitimate that where this penalty through there's a false positive then the penalty is not really that big as it hurts you particularly but the whole

point of the penalty is to essentially prevent you look from looping and doing nasty stuff okay other comments on that okay thanks Martin Dimitri and anyone else do we have testing updates yes go right ahead oh yeah I have reworked the code which and generate blockchain tests and now get

three tests it can generate all the blocks in tests and it means that test generation is no longer dependent on alert whatsoever or so we can actually use any clients that support our pesky protocol to generate the test now I took a look at vm tests and audited to blockchain test so that can now be also run on high the vm vm desert be had for since the beginning and it wasn't a different folder we haven't really used that and one was a new feature yes I have launched a web page with their statistics of returns to th execution on supported clients like go islets and

basil so you can visit that page and see how the test run is going and you can contact me if you want to integrate your client to that statistic page and also I have one proposal one sec I talked to nazerman client there's and they are not quite happy user testing protocol so I thought maybe we can organise a call between core client developers and figure out what can be in next steps how can we make the testing better what would be the approach to run the tests or generates a test this I also

discussed with Martin I think we should make testing Cole with core developers on this matter so that's it that's what I want to discuss in addition to a call maybe some kind of chat channel how the chat channel we have on this Court it's called testing yeah that's not actually public one well there's one called test on getter and I think it might be linked up let me check no but I can link that up if you want me to Dimitri I'm gonna make the testing

channel can we make the testing channel public from discord yes okay I can do that today I'll just write a note for that and then it's gonna be connected to this guitar channel I can post that right now in chat and and the all core devs chat so just go there to coordinate that's where that's where Dimitri can be found as well all right think that's where is the die post the right link Dimitri under test yeah that's right okay great idea no one else have

comments or questions on that okay some of the last stuff there is a survey the EIP IP group has a survey out thanks for everyone for getting this together it's really it's like six questions it's really easy and I'll post the link to it and here and and the all core devs getter if you could fill it out this is gonna give us kind of a nice overview of the direction we should go in as far as how the group's going right now what we're working on is a few different things in parallel one of them is

improving ew1 the two main ones I should say or is improving the IP one and then fixing the bots the EIP bot to get get it documented the one that Nick Johnson and macaque Makoto and getting that documented and like inline comments and making it so that if we add something to EIP one like a new header that it can keep up with it so that's the main thing and then this survey is gonna be used to help us move into the next some of the next phases of how to improve EIP one another initiative i guess is the VIP page on it

right yeah so the EIP page on aetherium dot org there is a good are you could explain that one Tim because he actually I haven't been to that chat room yet sure I mean it's it's pretty self-explanatory just having a page on a theorem at work that gives a high-level overview of what are each why they matter and and that's redirects people today eats websites so the goal is not the replace the each website but to just give a kind of high-level introduction to the community and and and direct anyone who's interested there yep and the other thing that happened the other day was a smaller call with Sam a web developer from the etherium org team

about moving the etherium a IPS from the IPS dot a Syria morgue /e IPS for SEO purposes and to integrate it with aetherium org that's still very up in the air there's a lot of unanswered questions with that so that's not a final decision by any means that we would be doing that but we were exploring that possibility and seeing if it made sense from a bike perspective of SEO benefits versus you know do we actually want it integrated with aetherium org so it gets convoluted from a technical specification to you know whatever you know aetherium dorks message and purpose so we're trying to

figure that one out still and you can contact me if you want to be involved in those discussions I know axe ik has been involved a little bit in those and so has a few other people puja so yeah let me know if you want to be involved in that or if you want to be involved in the EIP IP process we have a telegram chat and I can add you if you just reach out to me we have calls every other Wednesday at 1500 UTC right pooja or is it 1400 do we know or Tim 1500 UTC on Wednesdays or every other Wednesday and the next one is this upcoming Wednesday mm-hm

anyone else have comments or questions on any of that and then finally reviewing decisions from the last meeting meeting number 83 EW 25 37 in 1962 would be discussed under EFI and to be continued in the eath Magicians for a thread under review for efi as 23 15 and 25 15 and then eligible for inclusion pending as 24:56 I think a lot of those from the last meeting were like one of those like self-explanatory we just need to restate them because people were confused but that didn't necessarily mean that was the first time we were making all those

decisions decision item 83 point one was he asked on a proposal for fuzz testing by Aleksey for continued fuzz testing on 1962 and whatever narrowed scopes there were of that which you know the conversation for that continued today decision item 83 point two was work on e IP 2542 to include only one of the three opcodes proposed which one was 25 42 again or sorry 25 if we have 42 I forgot what that one was let me look it up wasn't that one of John Adler's yeah new op codes for

transaction gas limited called gas limit and a third one so yeah John's gonna keep looking at that according to the decision item action item 83 point 1 which is different from the decision items was that bounty for the prerequisite benchmarking efforts of ATI P 2046 would be explored I didn't end up exploring that but it sounds like Alex stepped up and did that anyway so thank you Alex and it looks like we're gonna get some benchmarking done from other clients before this is implemented so we can still look out for this for a future thing but I don't think we need a bounty at this time because that would probably just slow

things down but I'm open to other opinions agree okay anyone else that's all that's all for reviewing 83 does anyone else have any final things we ended the meeting in time yay we'll see you in two weeks on the 17th at 1400 UTC bye everyone bye wear masks wear masks [Music] [Music]

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

[Applause] [Music]