All Core Devs - Execution #77

Transcript

[Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] you

hello everyone and welcome to the etherium core Debs meeting number 77 my internet connection is now fixed I didn't even have to call they just fixed it and some my uploads good so there shouldn't be any stream problems okay so now that we got everyone on here let's talk about the Istanbul update that happened about a week and a day ago or less than a week ago I suppose is there any update from anybody it looks like it went well we had a community call that I thought went really well during it and according to the ether nodes website the last time I checked I think it was like

95% of nodes it updated so if you were out of seeing yeah it was 97% now if nodes have updated so if you were out of sync before you are now immediately in sync because you updated because you realized oh no I'm on the wrong fork oh there's even good stuff from muir glacier we'll talk about in a little bit so now let's see here what's the next thing we got on the wrong page anybody else have Istanbul updates

Hudson Jameson: okay so now we're on Muir glacier if you

click on that link you'll see that it is in last call and we're gonna change that to final the review ended yesterday and no one raised any concerns that I'm able to see in The Magicians threat at least I had guessing they would have left it there instead of a PR

Tim Beiko: so one concern that I think was on the magician's thread is some people felt that the four million blocks was like too big of a push right so there were a couple comments I'm pretty sure it was it's either on the eep thread or on the either unlike the hard fork thread or on the actual eeap's thread I'm not sure but there were just like a couple people saying that's like

four million might be too far in the future and just wanted to make sure we about that so so no one seemed like super opposed to like pushing active difficulty bomb but it was just like the amount by which we're pushing seemed to be problematic to a couple people

Hudson Jameson: okay yeah I can see why people would think that okay but it sound like there wasn't any deal-breakers though because I'm having trouble finding it but yeah would you say that there wasn't anything that was like super like like showstopper about any of the

requests

Péter Szilágyi: so I know that

we did the release for the moon glacier last week and there have been a few comments maybe a couple two or three comments that it's not we released too soon and people didn't really or two or three people said that they don't really like it that we push it back too far but generally there is the rationalization that they posted was that this means that we are all of a sudden delaying is theorem 2.0 so for some reason people kind of link this delay to eastern 2.0 and from my perspective the two things are completely unrelated

I think

Tim Beiko: those were some of the comments I think I just

posted the thread I was referencing to you I think the one concern that at least I don't know two people seem to have was like if we if we push the bomb so far does it make it harder to ship stuff like the finality gadget which will potentially reduce issuance for minors and what's miners incentives there like upgrade to that if there's not the bomb in place anymore so it seems like there's there's at least a little bit of concerns on like the $1 side and or at the very least they're like link between $1 and $2 so yeah I shared the threat acai I don't want to like you know kind of put words in people's mouths but that seem to be

another in at the concern at the same time you know it's like one or two people had those concerns so I it's not clear to me how like generalizable they are to the entire community

and yeah

Hudson Jameson: okay sounds good um let's see I think that that is fine then I think we can go ahead and just continue to market final because there seems to be some misunderstanding with the implications would be to point at like Peter said anybody opposed

might apply

Péter Szilágyi: to these people was and I kind of

stand by it they're kind of pretty late to start debating on whether four million or three point nine or however much would be more appropriate so my suggestion is that we go ahead with whatever so that we can just release the thing and make sure that if um still functions in a month and then if somebody feels really strongly that this is a bad number I think it's completely fine to adjust it in the next work if somebody is really opposed to it for some reason

Hudson Jameson: got it okay I'm not finding those comments anywhere and I keep looking

900 I was looking in the EAP form

Hudson Jameson: okay yeah

I remember that thread okay well I don't really need to see it for it to to know it's been there because you all are talking about it so let's go ahead and move on then and just say that we will be addressing the difficulty bomb at some point it I believe it'll be before the the four million blocks hit B as we already talked about that so I think that's sufficient personally for dealing with the delay and adjusting it if necessary based on community feedback once that happens or once we get like after Muir glacier um I also encourage people who do feel

like it's not accurate to make another AIP that either adjust it takes out the difficulty bomb extends the difficulty bomb whatever you want to do so that those could be up for consideration after muir glacier

and I guess yeah one thing I'll just add

Tim Beiko: the reason I think we should still go to final is the absolute worst case scenario seems that you know if if it's if it's true that's like miners will not upgrade like unless faced with the difficulty bomb which I'm not personally convinced of but like anyways you think that as a given then it seems like in the worst case what you get is something like the finality gadget won't go live until you know the bomb kicks off which is like even one

and a half year or something like that I'm not sure how quickly the finality could go to life but it's like I doubt you'll see that and less than like six to twelve months so I the absolute worst-case scenario seems like you add maybe another like six ish months before you can deploy the finality gadget

that's

Péter Szilágyi: realistic either because so I think this whole miners will not upgrade this kind of originates from the Bitcoin world which is a fairly stable protocol so people don't people expect that to not change at all and you require quite a lot of force to change it but in the

case of aetherium people are more accustomed to our regular updates so even now we have two hard Forks lined up we have the crypto stuff that you can talk about it actually think afterwards after this one we have to eat 1x research which will if we go down that path it will require probably multiple hard Forks so it's it's not like we are freezing the serum one as as it is now

and cooling it today yeah III

Tim Beiko: agree with that and I think the worst-case scenario of like you know even if that's where untrue is not that catastrophic so I I think it's less catastrophic than like

taking it under three months to figure out what's the right amounts by which to change the difficulty bomb

Hudson Jameson: okay anybody else have comments opposition anything okay next up we have testing updates Oh actually one more Muir glacier thing so it activates on the right now once it's slated for it's slated for New Year's Eve

Péter Szilágyi: when I saw that number I also freaked out but then I realized that

there will be a difficulty increase in a couple of days that should add about two seconds every block oh great okay so it was just a rough idea so somebody please double-check it but if if what we think is true is true then it should that should bump the delay the whole thing by maybe ask for days it should definitely not happen on New Year's Eve but please

no check okay sounds good so and let's see two weeks is the 27th I'll just go ahead and say

Hudson Jameson: I think we should have a

meeting in two weeks it can be very very light but just talk about me or glacier and probably recommend that people who want to bring their VIP s maybe should wait for a different meetings since it'll probably be very lightly attended as my is my thinking cuz it's like the week of Christmas and other holidays are kind of around that time like there's about to be New Year's even New Year's so yeah but I still think we should have the meeting in two weeks anybody else have any comments on that

yeah I think it like me they make sense and we could put it in the agenda that's

like it's just a discuss your glacier

Hudson Jameson: or maybe we might not even need a meeting maybe we can just like decide if we want one and like a week or something cuz yeah thinking about it like if we don't need one why do it I guess

well them probably decided two days before the deadline just because a week before maybe the block times aren't that precise but maybe two days before that it should be pretty pretty clear on what God intends on

Hudson Jameson: so instead of having one in two weeks we could have one on an off

day right before Muir glacier okay we'll talk about it more on get er I guess we don't need to like truly decided in this call as long as we get to it in the next few days so people can kind of plan if they want

um what's next

Hudson Jameson: testing updates anybody have testing updates okay we can skip that one then dimitri isn't here who usually has

testing updates

now worth

Hudson Jameson: the eligibility for inclusion efi EIP review the first one is going to be

e IP 1559 that one is let me find it in the eligible for inclusion that uh and yeah go ahead yes i wonder if there's anyone here who is yep

Rick Dudley: hi it's this is Rick and Ian the dev who wrote the patches is

here as well

so

Hudson Jameson: awesome go ahead and speak on it if you'd like

Rick Dudley: yeah I mean just a friendly reminder of what it bases the the purpose of it the high-level purpose and how it achieves that high-level purpose the high-level point it's it's a VIP benefit Alec the point is to add stability to the gas ether price or the ether gas price and and also it has some other useful side effects in terms of you know removing zero fee transactions and the way it does this is basically we

add a base fee we bring the gas pricing under consensus and and then the transaction each transaction instead of having a single component in terms of the fee that goes to the miners you now have two components you have some of the gas is burned and some of the gas goes to the miners and that's that's basically it it's actually a set of you know it's a it's a phased so Vitalik wrote the skinny one five five nine which is not

what we implemented we implemented what was in the implementation study which is two phases basically because you know as we can imagine changing how transactions work oh and another major benefit is it really simplifies you no longer need ether gas station it really simplifies the user experience it's much easier to figure out what your gas fee is going to be in advance and and because it changes how transactions work you know you can't just flip a switch and expect all of the downstream tooling to have changed

night that would be you know that to me that was a much greater risk and so we've made it you know we've made it two phases so that there's a period of time where both transaction types are valid which adds some complexity um but I think it's I think it's necessary to actually get adoption without breaking everything were there any questions

yes a couple of them actually two questions so first of all it sounded a bit like you're talking about the e pass one thing and your implementation as a different thing and I'm kind of wondering which what's it discussed

today discuss the e pour your alternate version of these

Rick Dudley: yeah so it's the implementation we haven't so it's a pretty big change and the EEP was a little in my opinion a little under specified we had hopes to have a ripe e that referenced our implementation well let me actually that's that's inaccurate what I had hoped to have happen was that we'd actually do some modeling and

simulations to to sort of prove that this isn't going to blow everything up but we couldn't get funding for that so what we've got funding for was the implementation so we wrote an implementation and in that process there were changes that need to be made and you know the EIP is forthcoming but we thought it wasn't but those were separate tracks those are two different people working on those things and so the implementation was the priority and it also coincidentally frankly happened to be done first

Martin Holst Swende: okay so it sounds to me

them the at this point it's real a bit too early to make some kind of call of about attrition of but I mean since it's you have an implementation but not really an eat to discuss but I do have some also some general welcome general question about 1559 so it has this premium base fee and a premium and I don't really understand what prevents all the miners from basically colluding and setting the base fee to zero and still only accepting transactions which have

highest premium and falling back basically to the same situation we're out today

yeah so I think I think

Rick Dudley: before I answer that question yeah I completely understand what you're saying about the EIP and in the review I in my discussions with people to be frank it didn't seem as though it seemed as though this was the shortest path to having a discussion frankly since no one responded to any of my comments or anything else that wasn't and I mean they say no one responded I mean very few people responded and it didn't seem

to I was having a difficult time

getting I mean

Martin Holst Swende: I think it's fine today I just meant that we probably won't be able to like make a decision

through oh yeah

Rick Dudley: no I don't know I don't expect perfect to have a discussion about ok ok I don't expect there to be a decision today so so thank you um yeah so I there's a there's an averaging of the base fee over a large number of blocks and so the idea is that the miners would need to kind of have an overwhelming amount of the transaction volume for a long period of time to adjust the price you know they basically need to be the majority of demand so you know it's kind of a weird

but does the basically follow the

premium what does the base people so the base feed targets a half-full block so as the gas price so like

Rick Dudley: we set up an initial value that you know in the original AIP the teller sort of took a snapshot of time but it's you know the the gas price you know at the time that it's deployed and so basically the idea is that is that that that price that initial price is set and then it can only move it can only vary so much per block and the

target price is determined you know they're taking some average number of blocks and it's these are the exactly the sort of questions where I thought they were very difficult to answer and and this attack that you pointed out we sort of have this sketch solution but I felt like given the importance of the change we needed you know a lot more

engagement to actually answer that question as I see it this whole essentially basically targeting half essentially

Péter Szilágyi: if I get it correctly the idea would be that the gas tries to keep

blocks heartful and it blocks are getting fuller than the gas prices go up now the question is how does this degree relate to the dynamic dynamic block sizes because sure on earth remaineth we kind of have it fixed at ten million currently but in theory it should have been dynamic so if we add this how how will this do values in the place because as the blocks are getting fuller the miners would in theory push the block size up which would make transaction cheaper and your proposal is doing the exactly the opposite yeah I mean sorry continue

I that's suppose that if we were to remove the limit on may not this artificial 10-million gas cap and what would happen

over Kashan yeah

I'm thinking about that I don't I don't think so dynamic whoa-hoo but how do we decide what the criteria is for changing it

Péter Szilágyi: changing what

the 10-million gas cap what what

what in your suggestion how is that changed

well

Péter Szilágyi: the 10-million gas cap currently that's an arbitrary limit set by miners but based on the feel for the coal it should be pushed upward as if blocks are full

yeah that's

that's under consensus so I think it would stay effectively you're right it doesn't we don't we don't change that we just changed the price

Péter Szilágyi: yeah I'm saying is that the price so essentially the problem is that in theory what these theorem protocol specs is that if blocks

are getting full the original spec was that the gas limit should be raised now you're saying that the price should be raised but I think it should be important to touch on what happens for example what happens on a network where we don't have this limit for example in rinkeby currently we configured it that the blocks are 10 million in size but they are allowed to go up until 15 million if there's a high network traffic now in this case the the trigger for pushing the block limit up would be that the blocks are full but at the same time in your Eid this would also trigger transactions to be so expensive that the blocks won't be pushed up so I just want to make sure that we're

not accidentally murdering an existing mechanism with this one

well I appreciate that comment I think I think that it would be I mean all joking aside I think it would be intentional so yeah I mean I I think that I didn't realize Ren could be had that dynamic you know pricing also for the dynamic sizing I mean if you saw if you're creating an EIP that deliberately murders it that's fine for my perspective and what I'm actually trying to get to the do is not

to just ignore not to forget about this aspect so I'm complying with proposing an ERP that clearly states that this will be murdered I go I yeah thanks for the feedback I mean that's exactly the sort of feedback that I've been having a difficult time receiving so um thanks

Martin Holst Swende: I have another question so right now we are we there's a cap we know that even when the books are full we won't go great tell me don't know whatever it is but here in this proposal it looks like yeah will will target 8 or 10 million but actually the the hard cap is at three times that amount so it might be suddenly 24 million a 24 million girls

block would be valid am I reading it right

Rick Dudley: yeah it targets it targets much lower than right exactly so during normal

that's sort of like a congestion ceiling can like Headroom for congestion yeah that looks

Martin Holst Swende: it feels almost reckless but I mean there are some security implications about notes well having the roof three times higher than where we want to be and I think maybe want to be a bit more conservative actually

yeah I love service vector is somebody

figures out the way to attack a theorem oh you have three times as much leeway yeah I think again I

Rick Dudley: I completely agree with that and I think that yeah if someone were able to sustain that I mean as far as as far as I am concerned you know I sort of volunteered to Shepherd this EIP through I think these of course are you know I mean you guys know this stuff better than anyone else basically I think these are really great questions and these are exactly the types of questions that I was trying to surface prior to writing any code but this seemed to be what most of the people who

were giving me feedback in the community wanted they wanted to see the implementation before we answered these sorts of questions

so yeah so yeah that

Hudson Jameson: sounds like the right way to go I think it's good that you did that because then people can look at the code and then dissect it a little further than just a lot of hypotheticals I guess people would say

yeah yeah I mean it's it's an interesting process I mean

Rick Dudley: it's not how I've worked in my other professional capacities but but yeah okay so yeah I think you know I appreciate the feedback and we'll definitely keep that in mind

Hudson Jameson: yeah and taking this to like the etherium magicians thread is gonna be

very helpful I think to Rick and the rest of his team so if anyone here has further stuff after looking deeper into the implementation I think that would be important and then even more important than that in my opinion would be an update to the EIP itself even if it's not pushed through the EIP process having a PR that has the changes Rick that you and your team have implemented that might be different than the PR which I think was last updated in April that would be pretty important so that people can comment on the latest one and not have to refer to a previous specification that's not updated

Rick Dudley: yeah we'll take care of that we'll take care of that you know hopefully this week

perfect yeah and I mean it's

Hudson Jameson: it's the holidays so it's not like a huge rush or anything

Péter Szilágyi: before we kind of deflect into a different topic I just wanted to emphasize it a bit more because I kind of have a feeling that it's not to be taken as seriously as Martin intended so currently the 10 million gasps limit that the serum Network is running on well the reason why it was originally capped at 8 million because that was considered the only sane limit so that this guy Oh

doesn't murder the network and yes we did some optimizations are now people pushed up the gas limit to 10 million but but essentially we really really don't want to get into the position when all of a sudden that suppose that we it we can handle I'm just seeing around the number of 15 million and after 50 million things starting to get screwy now if you all of a sudden allow people to expand 24 million then that's it's going to be really really bad that's why I'm saying that if we kind of currently feel that the fear networks capacity is at 8 or 10 million we should really have some very very hard caps in place so

that you cannot really over blow the resource usage so honestly I would instead of month instead of a 3 X multiplier maybe a 1.5 would be a lot more saner starting point

yeah and I don't

Rick Dudley: frankly I mean we sort of went with the parameters that fatale it gave us where he gave us them so I I don't know why he picked such a large value and I don't and and so I yeah I'll definitely keep that in mind

well

Péter Szilágyi: the 3x is not a horribly bad idea if you look at the average network usage

so currently guests can process blocks in them I don't know honestly I haven't checked but maybe around 150 milliseconds so if you were to 3x that that would mean maybe half a second so that's not that bad but the thing is that this is the whatever people throw at it when they are using a theorem it's not the worst case possible attack scenario and we need to keep the limits in control for that scenario

Rick Dudley: yes so so when he did look at the distribution I do remember for me from the EIP that it was based on an assumption of block distribution that I that I thought didn't really fit reality and I think that you're touching on that

point from a different perspective and yeah yeah I agree that that there needs to be I I frankly don't know I mean I'm we're here having this discussion because I don't know how to demonstrate or simulate or make any sort of formal assertion about what that value should be so I mean I'm definitely open to suggestions my intuition is that you would have to run a fairly robust simulation to answer that question

okay

Hudson Jameson: was there anyone else with comments

or anything to add at the end Rick is it's best to reach out to you on a theory of magicians I'm guessing was there any other outlets that you wanted to bring up as far as how to address this or contribute

yeah

Rick Dudley: we can just keep the conversation in keith magicians that would be great I don't know what the convention is around PRS I mean the code size is relatively small obviously the impact is very large so I don't I mean when I say PRS I mean I don't know if we want to have like a name branch on our

fork that people want to interact with if they do just at me and the Gator and I'll I mean I think the link is already provided but if people have a hard time finding it or whatever we can sort of engage in the you know on github and

eat magicians

Hudson Jameson: awesome and just to extend my support on this you can reach out on telegram if you do have any questions about the EIP process or the process of getting this through for more potentially rapid discussion I'm happy to talk to you about that

alright

Rick Dudley: great

thank you

alright

Hudson Jameson: the next one that's eligible for inclusion the IP review is 1962

that one is why am I not finding it I'm here guys before this discussion Oh perfect go ahead yes who's well

Alex Vlasov: first of all I'm sorry for a distraction for the last few months because we were well I was busy with academic side publishing the paper which we had to finish otherwise on the implementations there is only one major road block right now and this is how to measure the gas cost for precompile call

for one particular family where my initial ideas and how I would do I actually fail so I was kind of simulating the calls with a lot of parameters around one big limb just drawn uniformly from available parameter space and then I was trying to do kind of multi multi parameter fitting unfortunately dependency on some of the values but it was a little bit weak so I couldn't factor them out and get a final formula so I will now have to do it another way by first dissecting the

function call in just requires which are independent and we should have quite trivial kind of a priori parameter dependencies and then I will have to just combine the three formulas but unfortunately I have to do all this measurement once again after this there are no technical problems in terms of kind of all the same stuff will be ported from the rest to C++ implementation which was done before and the same way they will be run or another facet testing to check the correspondence between those two so it's plainly just C tricycle do the work and borrow some computation time from a

cloud provider

Hudson Jameson: so this is the EIP about EC arithmatic and pairings with runtime definitions over such families as BLS 12 BN and MT 4/6 is what the EIP says right

yeah and secure family support which I have this problem is this MN t46 type of curse fortunately is also not too pleasant to work with

Hudson Jameson: yeah and I'm looking at the Fellowship of a theory magicians it looks like no one's commented since August and the

last time that someone has it was July that talked about getting some test cases and so the robotic is still that curve in order for you to generate test cases am I reading that correctly from the magician's

form

Alex Vlasov: well in the main repository where there is a Rosco is rough few test factors which were dumped just do it for four known curves which can be pulled from either various papers or just where is kind of standard repositories with curved descriptions for those I just dumped the kind of binary encoded plot which which are in a

right form for the input and then pre-compile should return some answer I said yes either boolean or just and as a series of bytes those will be available but right now house there are only two kind of implementation and like almost full-scale implementations which are both done by us one in Rastan us one in c++ and to test correspondence with between them to check all this well to check for consensus between two different implementations we do the facet testing which basically first faster the contract itself and then Elsa compares as the output result so for

this I can definitely make a huge set of test vectors but final testing should still be done by just a lot of brute forcing and passing for difference between outputs for the same

set of people's I'm wondering about the so they eat links to a matte

Martin Holst Swende: matter labs repository instead is that the master permutation

great yeah

Alex Vlasov: well there are two one is impressed which is my kind of main working repository and which I used for right now for just schedule estimation and as one is also in metal apps github emphasis c++ implementation which also his name II 1962 - CPP I

think I notice that people from UI Hurston young were interested in trying to make an alternative one I talked to them I think three weeks ago but I mean they looked at the spec sets of explicit formulas which were Elsa said where Elsa published quite a long ago it's a github but I didn't hear anything from them yet so I would consider it for for a first two implementations it will be those two and they will be tested this way for correspondence between each other

personally I would suggest that it's should because though those two implementation are all our post and bi-metal labs and it's not kind of very much independent I would argue that it's much easier to use just one because it lifts a lot of questions for a consensus results but it's kind of still the difference between those two will be very small so it's still kind of easier to use just one even while so able to test it for difference

you know

Martin Holst Swende: right but the core problem here being that

this is extremely complex stuff this is basically an EVM for complex cryptography oh I totally agree that it would be a lot simpler to just have one reference implementation because then you wouldn't actually need to specify everything in and you know just consensus by reference implementation and it feels kind of dangerous

well

Alex Vlasov: my argument is not that I don't want to have separate implementations I would want to have separate implementations but right now those two implementations that will be available and in any foreign production ready they will be Bo's done by us and will be goes down by

and was the same set of well public documents specs and all the design decisions so the difference between them is just so small most likely I mean there's also different languages but the difference which one would expect will be small so I unless every will be and next one the next one I mean for this period of time until there is no next one and pretty much independent one it's kind of less risk to use one which will not crash it will just anyway give consistent results then try to use two which are very much similar

so

Martin Holst Swende: the matter labs documentation

also contains an ABI interface description the consensus right

Alex Vlasov: well I'm I mean the binary interface is one of the simplest part and so binary interface is implemented in both C++ and Trust and I mean this is just the way how you slice a bytes and how you interpret each of those cutters is Arab paraffinic operations and I mean the ABI part it's first of all it's a repeater and it's kind of can be changed a little bit but for now it looks reasonable and for the part where's the discrepancy may

come it's much larger chance that it may come from arithmetics even while the for most everywhere are explicit and those halves those are present in a separate document was also exposed to formulas it maybe suggests jury's implementation one check or not one just went missing and there is much larger chance that that happened not in ABI but in arithmetic despite a large number of lines of code which were responsible for each of those

yeah sure yeah I mean but it's just kind of a sign of how how big this heap is if there's a

full API implementation which isn't even mentioned in the core EEP uh yeah because API

Alex Vlasov: design was kind of flexible and the time we started to make it I can kind of make it freeze and solid but I don't think it would help anyone I mean having an ABI implementation without sin restless it's not something which you would want to have for independent implementation but I mean for for firms experience of previous round of asset testing between to implementation to implementations we have found a set of discrepancies which were kind of checks at some stuff was

empty or not for example but we didn't find any discrepancy in ABA parsing code between our raft and C++ limitations for example so it's just from a critical experience there is much smaller chance to get an error there

so

Danno Ferrin: my concern functions with a lot of different ways that you need to pack the parameters with a lot of different ways we need a cage the gas wouldn't be conceptually simpler just to have each one of these pairs of function and curves have their own individual call and we could easily isolate the testing cases that way

it's I mean

Alex Vlasov: this is not a problem and yes we

can have the 20 separate formal pre compiles for each of those kind of my point is there is that the way how you pack the parameters in each of those it's just so similar that basically there are only I think two bytes in ABI right now we specify each of those calls and everything else is kind of uniform awake how you encode for example an integer using survive it's a big-endian representation so I mean two bytes address which call you do and the rest is just uses the same set of

functions to slice this light and iterate them in some way so there is no in dependency between I mean even if you separated to 20 separate function calls which is still fine they will have they will still have very similar-looking way how you would call them so they will have their own kind of binary interface and when I maybe I did use the ABI a little bit wrong this is just a way how you pack the parameters mostly and here's two bytes to specify which call you want to

me

Danno Ferrin: why do we even need those two bags I mean you also know what's the issue with the

gas calculation there's different gas calculations for each curve and then to calculate this in the implementation or you know giant switch statement which way thing could be easier just to say that this curve has its own set of functions with this gas calculation rather than this curve you do this giant four-way switch depending upon which curve you are on and then you go down these complex things

I mean

Alex Vlasov: just from the way how they implement I mean just from any perspective curves implementation would be done as the difference between those is just literally one switch statement which is much simpler parts and the rest of it I mean for every function will use what the the entity which is a finite field

and no matter which of those calls you will use you will have to first specify the parameter of this finite field and then such parsing will be done inside the call to any of those 20 functions anyway so there is no good in dependency between them that's why I when I was and when I working on it right now I just didn't separate them because there is no good separation between them kind of any single kind of the switch statement at the beginning yes it tells you which functions you call but after this all of those 20 functions they just use the same set of primitives to do their work

since there they're not that much independent and the same is for gas I mean it still will be the same way you just choose to which function you call to to do the estimations

Danno Ferrin: but from a design perspective the first thing you do jump into a switch maybe that's an indication that should just factor those out as independent functions yes there's a lot of reuse behind the scenes but why do we need a hider behind the switch

yeah

Péter Szilágyi: so also highlight that it's completely fine to have one single function implementation wise within the EVM that just does a big huge switch and then calculates everything the way that's cleanest the reason people are suggesting the 24 or however many

pre-compose is because the EVM is kind of all the other operations are structured in one way and if we were to have 24 freaking powers then yes maybe behind the scenes those 24 peak empires would just call the exact same single function but it would avoid introducing an extra encoding idea or concept into the EVM code itself so currently you can just say that you want to be on 256 multiplication call this pre compare these are the parameters done whereas here you would also all of a sudden also have to specify that not only do I want to call this pre-compiled but I want to call something within this pre-compiled and the question is that is there a particularly good reason to add this

extra complexity in the EVM level because of course we can make it generic and make a single big switch statement within the EVM implantation but a DVM co level is their reason to have this extra complexity

Alex Vlasov: first of all I should note that such switch statement would anyway was like if happen not at the level of EVM but inside of the implementation because well at least how it's done right now I'm in the pre-compiled implementation just takes a set of bytes as input and internally parses certain holidays most likely I was expecting that this will be the way houses date is passed from say EVM just a pre compile but this is very

minor issue the reason why I didn't want to put it initially is it just as a solid example in any of those calls even if there will be 20 of those the first parameter will always be the same and this parameter will specify the modulus of the finite field over which one want to work and define occur so even if there are 20 of those independently you will still have to specify the parameters which are very similar for each of those calls its and this is not a huge switch statement anymore those independent calls that's why I decided that that it's kind of backwards the same way if you have a lot of similarity in the way how you call

each of those then most likely you don't want to separate them from just logical perspective I correct I don't have any argument that we should do one way or another strictly if you want 20 separate function calls and perfectly fine with this I just described why I didn't put it initially

Péter Szilágyi: so for me having an extra ABI abstraction layer just to have one single modulus I mean I I don't care if funny-funny function calls will have the same first parameter and you have to set it so unless so what I'm trying to vote against is adding extra ABI complexity

just to hide something a bit further down the stack

Alex Vlasov: okay I mean if this is a kind of decision I will separate this function it is a required number of sub goals it's not a problem from any perspective it's just this decision was never kind of reach to the final point and I have always said that I'm fine with any of those and easily some kind of if there is consensus that we should make it 15 separate goals that I will make it 15 separate calls it's not a problem

I think it would I mean

Martin Holst Swende: from another perspective I think it

would be good to actually I have a hard time to make out what are the exact operations that are supported and I go to the implementation on their side it's very hard I mean it's very hard to figure out so what exactly would it be five millions or 20 different or 50 different methods I mean what exactly are the operations I think I think they is kind of vague on that

yeah well not being able to read math operation what looks like is the most formulas mounted yeah well it is form is different due to

the use of specialized algorithm it's a rough few documents which describe it but if word yeah yeah

Alex Vlasov: maybe I should just really update it once again because you know it okay I will handle it to have a better description you know in short what's a precompiled does it's a high-level it allows you to do right now seven different operations one first of all throughout operations which are arithmetics on elliptic curve defined over the prime field and there are three

kind of operations which you can do there it's an addition of points multiplication of points by scalar and multi exponentiation which is just where I finish it way how you can say from consecutive course of multiplications and additions of intermediate results those are three functions then there is a set of functions which allow us to do the same three prime principal operations addition multiplication and multiplication but not over the curve which is defined over the prime field but over the curve which is defined over the extension right though and this is usually in most of the literature is used as labeled as a g2 subgroup so those are

three more operations and the final operation is incorporation which is supported only for specific families of curves for which for a label so if I explicitly separate all them I will get to the number which is which is roughly 12 well 11 independent

calls

Alex Beregszaszi: can I raise 2 different arguments not with the design just in general I think it's kind of premature to argue about a BIA encoding it how any of these operations should be

laid out before there are actual example codes using this recompile because eventually what what should be also part of the decision is the cost contracts have to incur while interacting with this pecan pies and secondly the dev ex experience had to actually interact with these pecan pies so I guess from a language perspective having the current IB encoding or having individual pre comp eyes are both kind of bad because it requires specific implementation in each language or if

there is no language support and it would be some kind of an inline assembly maybe another option would be just to follow the standard ABI encoding and by that it would just look like a contract the pre comp I wouldn't look like a contract and calling a specific function and it would be clear you know what the function including is now probably the arguments against using the standard ABI encoding would include that it may be just too big and therefore if we actually x-men how the pre comp I would be used so I guess in the pairing case

it would be fine but for doing repetitive additions it would be just too big of an overhead and the other I think people will say regarding the a/b encoding that it it may be just ambiguous but I think that can be argued I think he can kind of shortly answer both I I never heard about using standard encoding it may be an option I just didn't meter this and still the cost of parsing is cost of parsing is negligible compared to originals but I didn't estimate the cost of actually kind of forming say array of data in

memory and during this call this part I didn't estimator we don't have a solid answer with this for developer experience as the I will link this to the guiter just to cabbage kind of stated somewhere there is an example of how one would call the recompile with the current ABI at least and yes this is kind of setting the parameters into say a huge memory huge chunk of memory but this is how you do it right now

anyway - called me and Britain pile

Alex Beregszaszi: on the example I actually meant a real life

example contract where tests would actually be beneficial which is not just like calling a single function on the precompile but rather I would assume in in any case you would call it a bunch of times different functions on the pre-compiled so I think if complete real life example would would I think we necessarily - to actually reach a correct decision on the design

okay okay okay okay okay I get the example yeah

Alex Vlasov: I think I can kind of quickly write the equivalent of the current snark way for every fication kind of a routine but for how it will work which is pretty vile I

think this would be a good example so there is a large reuse of the parameters in principle which is possible to push the efficient to the limit must like a developers will want and such optimization needs to be done only once that yeah it's not a problem to make one real life example

Martin Holst Swende: great

Alex Beregszaszi: just one more comment regarding the cost you mentioned I think there are two important costs both from the developer slash EVM side so that one the cost of preparing the message for a pre compile because we want to keep that cost low and second the actual cost of the call the data sent through the call I think there the cost on the

pre-compile side decoding any of these is negligible because we're creating the free compile in the first place because you think it's cheaper to do calculations on the client as opposed on a VM so we want to keep the cost for the the contracts the lowest possible

yeah well

Alex Vlasov: for this part there will for example if one would want to call this pre-compile to do the same set of operations over the B and curve obviously there will be some overhead in terms of message being prepared in memory because one would have to specify more parameters but after this and the part which I measure for a gas cost

right now is the second part which involves parsing which is negligible and then actually kind of also arithmetic which is required mostly because I don't have a way to affect how expensive is a cost of memory human memory can in a VM in a VM but still even for simplest operations right now is the cost of my rough way of rough calculations was their cost of four means the memory chunk is is at maximum 15% for a simplest goal then they chant and then the actual work of the pre-compiled intermediate and this ratio will go

substantially down for for cold for pre-compiled which will involve more affinity operations

just

Péter Szilágyi: to give an example for I think what's about x''k was referring to is that for example you are saying that your current ABI encode and you have two bytes that switch on various internal things and there it could actually happen that just setting constructing in memory that two bytes in the idiom will be a lot more expensive than just to have the pre compile and just to call it in to it or maybe instead of using two bytes just using two 256 bit integers so these bytes shifting operations are kind

of expensive in the EVM and it can be surprising to so actually what I'm getting at is that if you pick an encoding that is as tight as possible that might actually cost more than making a looser one

yeah

Alex Vlasov: well this part I didn't estimate and well as reason for having to custom API section a little bit simplifying my own work because the way how the one scalar is encoded and well also furniture is they're just basically large unsigned integers is there is one byte which tells how many bytes address it after it encodes this number and then there is a sequence of bytes which are which is interpreted as

a peak Indian encoding and with the Naza limitations that the top byte should be meaningful so it's not not zero and this is was a kind of very simple set of checks which I would need to do and this it will allow else me to quickly estimate over how large numbers I will have to do my arithmetic which is kind of which is also beneficial to do the the quick gas schedule checks without actually parsing the full set of bytes and then checking again how many beats I actually have there if I have the redundant encoding by using the for

example fixed chunks of by 32 bytes this was a reason well it was kind of another reason to do the custom API so that's why I didn't even eval 8 maybe it's actually easier to it was a standard API versus I don't have an answer it's just another piece of work

Péter Szilágyi: I guess we could we could always just check and see maybe AXA could so if we have an actual contract a real use case then maybe it will probably be a lot easier to just check that ok if we were to encode it with your ABI or with x6 ABI or just a dumb binary encoding which would be or preferable and

probably something we can try out if we have actually live codes to play with

so you're

Alex Beregszaszi: probably my main message is that we we definitely should have actual EVM implementations of contracts using the Dupree compiled or any other pre compiler which is proposed because otherwise we're going to end up with a situation like we did with Blake to where the design had no input from how you would actually use it from within the EVM and it ended up being suboptimal in some cases and I think that applies even more today as precompiled because

it's it's a lot more complex so yeah my advice is that we should have actual examples probably written in solidity and maybe also some in using a line assembly and that should be one of the main drivers for the the design of the ABI or how to interact with the precompile

Alex Vlasov: yeah well it's a recent example of such code already and I will just link it together so it doesn't get lost

Hudson Jameson: all right I there is an EMV or that there is an EVM see binding that was posted in the chat by axe ik so if

anyone's interested in that you can check out the zoom chat was there any other comments on this otherwise this was a great discussion and we can take everything back to the magician's for this

yes I have

Martin Holst Swende: my kind of last comment is that based on the specification I don't think it's possible to write consensus agreeing ii implementation I think it's only possible to do that by

adapting existing code and I think that's the problem well I don't say that the specificity quality is kind of top one but you know

Alex Vlasov: and it will be still

appended but right now specification maybe it's just in two separate places now I will check it again there are two documents one is about basically the ABI and the verification of the input parameters and another one listed formulas which should be used to get the same explicit

results

Martin Holst Swende: right but they only define the happy path they don't define the actual long happy path

and

they do define exceptions and especially is arithmetic one it defines exception but luckily for us by how they how you can implement this arithmetic if you use

this for most explicitly there are only two exceptions in arithmetic so most of the except exceptions which will kind of which will kind of tell that precompiled didn't output any data there are only two exceptions which happen in the arithmetic so it's just propagated and the pre-compiled call just returns an error and there is much larger set in the ABI which is just verifications that also parameters were encoded correctly and except of this if you just use the formulas and you just do the maths and just write this at the end of the day you will always you will just get the

same result just because this is how

the arithmetic works for us if we did also check before so for example you can

Péter Szilágyi: have at least for a lot of crypto curves you can have invalid parameters for example I know division by zero just stupid example and the thing is that this needs to error out the exact same way on all

implementations

Alex Vlasov: yes you're correct and this is what else is actually there blonde Wayne under light each case in arithmetic this edge case is basically telling us that you don't have the

inverse of the element which is actually the same as you haven't kind of division by zero in this case if you encounter it anywhere in your code you just propagate all the way up and say that well my code just didn't produce any output and this is an error if nothing like this happens then at the end of the day you will get the same output in terms of it will be meaningless yes it will be meaningless for any practical perspective but it will be the same set of

fights yeah so I but this is like an interesting question because for example

Péter Szilágyi: in the go implementation of of the various crypto

curves various compiles if you input junk it will actually not so if you just throw the whole thing out for example that this point is not on the curve bye-bye so it won't just start computing chunk and returning you the computation results it will actually refuse to compute it because it

just does some pre checks and okay okay but let be kind of Clara Francis

this is part of the checks which I go for checking the input parameters when you actually do in a lot like chickens that Samsung is on the curve is input check in what I have mentioned

before and there are a few of those but the list is fine it is not very large and when you go into just formulas and foremost and formulas there is only one edge case and after you did all the checks if they passed on the same input data then after all the four notes you will get the same answer so there are checks for inputs yes and those are well the same as you just mentioned largely and few additional ones but yeah if you get into one of those checks you basically get an answer there is no result from pre-compile so just an error on a large scale but if you didn't hit

out any of those you will get an answer which is always the same if you just use the same for mode

Hudson Jameson: okay was there anything else oh all right thanks for the discussion again we'll just take this to a theory of magicians and continue working on this thanks for taking your time to be on the call Alex

oh well

sure I mean I apologize for delay with

all the Stoppard's I mean I I always have I always had an intention to make this

work and finish this good anyway I mean if we if we had time before this anything yeah with all the hard work stuff and other things oh I want to go back to Muir glacier just real quick because I realized I didn't actually check with each client to see if they have a compatible version the etherium cat herders want to release a blog post and so does blog etherium org with a link to all the clients that have Muir glacier so let's just go through each client that's on the call and see where everybody's at we know get has a client

that's Muir glacier compatible is there any other information we need to know about that or do we just go to the latest version no pretty much the latest version is the only one that's compatible make sure to state the numbers on the call so if people listening like yeah because if they less than a week from now or whenever so I think it's $1.99 I think it is - alright confirmed great let's say a less Oh Paul can't Paul doesn't have microphone that's right I'll just check a left manually then unless someone else can speak to it alright nevermind Ansel reading the

latest version one point two point six okay I'm going to interrupt you just to confirm these versions also have the wraps don't think of you good right yes Robson block number and all the tests passing and the maintenance numbers okay thank you perfect parody for party Lee we merged the block member to master but we haven't made it release yet in spite of the beginning of next week okay the beginning of next week we can

do a blog then and that still gives us three weeks roughly a little less maybe and then we have that might be everybody who am I missing as far as a client or important but sorry BAE c36 we have K perfect am I missing anybody else did anyone have a confirmation for Alette Paul doesn't have his microphone working so

we'll just have to look that Hey well we haven't done anything yet hopefully you will do it like in the beginning of the next week okay thanks for the update perfect um cat herders are there anything else that I'm missing as far as speaking Samir glacier this could be pooja or Tim it can be occurring earlier so in other post we are trying to suggest that it if coming around this January 6 do we need to amend it like in the sample test net when it appeared a

couple of days before they saw kind of panic so can we change the date so that people should be prepared earlier well honestly I would suggest that before New Year's Eve everybody should really update so currently the if the block numbers were consistent with the current speed then it would actually land on New Year's Eve and either scan is showing the 30th now I'm not sure how they do their calculations but yeah so it's like New Year's Eve or before so we shouldn't yeah yeah so can we put a tentative date as like 30th of December I'll go ahead

Peter it's kind of hard to say because the difficulty just got bumped six hundred blocks ago so I don't know that's quarter of an hour half an hour ago which kind of means that probably all the estimates are a bit off now so that's I don't let's wait until two more days and see see whether the numbers change the estimates that ethers can and we can all suggest so does it make sense then yeah to release the blog post on Monday hopefully parody can have a release by Monday and like we can release it end of the day America's time so that means that you know parody I think you're all in Europe so it's kind of well past the end of the day and we could use whatever

numbers are on ether scan Monday and that should give it a couple days to like readjust it's it's it's estimation given the the difficulty change just kicked in does that make sense that would be something we could do what my suggestion would be would be to just say and big bold letters have this done before the end of the year but that say the estimation is currently plus minus five days between January 6th or on January 6 plus minus five I think that doesn't really work for the worst-case scenario like the worst case scenario is like the 30th or the 31st I would almost

be more comfortable saying do this before Christmas in a way yeah okay yeah let's let's reassess on Monday I'd say don't they just see if that's changed awesome yeah we can definitely talk more than and if it needs to be on Tuesday cuz of other clients releasing that'd be fine we don't even have Trinity on the call or aetherium j/s so I can reach out to them manually or we can just head up there get our channels

Hudson Jameson: um I think we're nearly done here let me go back to the gender if I could find it I have 30 tabs up and right now don't I

where to go all right guys almost there I've been going through all my tabs well I'm just gonna go back to it again anyways we have one more EFI and basically that EFI is not truly a new VIP that we're discussing it's kind of a just a formality that we need to all agree on for putting EIP 10:57 programmatic proof of work into EFI because it was already accepted and other all core devs decisions back to basically a year ago multiple times

so is anyone opposed to adding prog Pao to the list of EFI is granted that we've before any of this process was discussed we made a decision on it it kind of seemed like a like at least to James and I it seemed like a like a something that we would need to do just for procedural reasons so if anyone does have a comment on that feel free to talk to the getter or bring it up here the EIP IP the EIP improvement proposal meeting I've dropped the ball on that a few times we

haven't had it yet and then I kind of started thinking about it and everyone's slowing down because of the holidays so it might be better just to push it till January unless there's a different opinion on the call and until then I can make a telegram and start you know getting people on that to have ideas and suggestions from those who've expressed they wanted to be involved in it because I think yeah at least way and I think Danna reached out and I'm a poojas gonna be a leader on that one and a few other people wanted to be involved so I'll make a telegram for that and then probably the next coordinate meeting just ask again who wants to be in it and it can add more people along the way and then in January we'll address it in a formal meeting after we've collected

some ideas in the telegram any comments

okay review previous decisions and action items from call 76 the last one let's see here how does it have oh oh I'm on the wrong thing sorry

Hudson Jameson: 76 is done I merged it today because there was a few Corrections that need to be made so if you go to p.m. / all quartet meeting / meeting 76 MD it's gonna have the decision so II I P 23 48 was listed as accepted and final that is

the validated EVM contracts let me go to it to make sure we're all on the same page

okay

Hudson Jameson: I wonder why we have it is final is that

it a typo it's 23 84 and that's probably the IP I'm not sure but just like yeah looking at it because 2387 is the Muir glacier heart Fork yeah key and so 23 84 was the actual change in the upgrade got it

Hudson Jameson: can someone let Brett know to change that

okay

Hudson Jameson: thanks

pooja also the EIP 2387 is put to last call that one oh that one is the hard fork metaphor Muir glacier the other one if it's so 87 is the meta and 84 is the difficulty Baum delay IP itself there's just one e in the meta got it okay so this just basically covers me or glacier okay if that was the decisions made that's fine

both of theirs

Alex Beregszaszi: last call was supposed to end yesterday

Hudson Jameson: yes

because

Alex Beregszaszi: we said initially just to take the standard two weeks but

since a couple of comments came up and Peter mentioned earlier on the call maybe maybe it should be extended because it cannot be considered final yet or well I'm not sure you know what's the status of them really

Hudson Jameson: honestly I'd say that they are both both Muir glacier ones are final at this point because we address the concerns that were brought up in the comments by saying that we are going to in one way or another address the overall idea of the difficulty balm or after after Muir glacier comes out so I think that that's sufficient but if

anyone has a dissenting opinion speak up

Péter Szilágyi: at this point in time nobody will start debating and backing out and releasing new clients for a brand new changed heart Fork so we're going to go with it either way

Hudson Jameson: yeah that is kind of the reality of it

I think there was one one comment on the the wording of the EIP itself regarding 23 84 and the comment said the AAP refers to suppose the previous I can't find it but anyway it it says that adi

opinion refers to the previous difficulty balm delay VIP and just explains the difference which is the block number but a person who raised the issue said that the other one actually deals with reduction of the block rewards and tcpip should also mention that the block rewards are unchanged but there was only just the technicality on the wording of the

IP

Hudson Jameson: okay um if that needs to be addressed who thinks that needs to be addressed is that because like the last difficulty bottom

adjustment did deal with an issuance reduction I believe but since this one doesn't why does it need to be included did they explain that in the comment

the two last ones hadn't had the reduction

Tim Beiko: I agree it might make sense to you have like that one-line change to say specifically this one doesn't I think the meta EEP might capture some of that I know James have had like a added a section about like the rationale of like why we're doing this upgrade and

Hudson Jameson: okay now there's I mean it won't hurt to

put that in there so I would say that yeah let's just ask Eric to add that line in there and hold it on last call until and it pushed it too far I should say push it to final once that line is added does that sound good I hear no

dissent that's that's cool is that it that's it for right now let's say the next calls in two weeks and because we can have

just a really short call if we need to and if there's not much on the agenda I can almost put it as like a semi optional call on the getter so we'll we'll make note in the agenda itself that this will be a light call and that people shouldn't expect a lot to get done so if you are coming to talk about an EFI EIP you might want to wait till the new year so yeah call them two weeks anyone else have any further stuff to talk about all right everybody have a great holiday and we'll see you in two weeks bye

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

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

[Music] [Music]

[Music] [Music]

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