All Core Devs - Execution #99

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

so [Music] [Music] hello everyone and welcome to the

ethereum core dev meeting episode 99 spooky halloween eve edition today we're going to have a ton of fun and games including some stuff that is halloween themed just kidding that doesn't happen in the protocol development world okay so the first thing we have is the yellow v3 in berlin discussion let's go through the yellow v2 and v3 spec update from the client teams that are here and i'll have james around that part and then we'll go over some of the stuff we talked about asynchronously in discord over the last week with the main discussion questions i'd put in there i think on tuesday or wednesday

uh so james take it away yep so looking at the the yolo v3 spec sheet on the ethereum 1.0 specs i'll put it in the chat here for people to look at i'm going to just go through and ask his client the status on whether they've merged or are they sinking or their plans to um starting with basu so is this for yellow v2 or yellow v3 ever concerned mostly about that oh i it should be a little v2 right okay yeah so we're on the yolo v2

right now we have the uh 2537 under the original pricing scheme we have the sub routines under the updated rules and we have the access lists and those outside of um the currently rlv2 um we've independently run it against get on the existing reference tests um now i still think there are some holes in the reference test i think we need specific reference tests targeting the uh rejection of the lists on reverted transactions um but other than that it looks like we're aligned with what 2929 requires for yolo v2 um we haven't done either of the two

yolo e3 ones yet those probably take about a week or two that's the wrapped transactions and the uh 2718 is that the repricing or the type transaction envelopes and the access available we haven't done any work on that yet okay great thank you um yes yes so we are also done with yodo v2 and i can also give an update that the tests the consensus tests have now been regenerated with the new uh berlin named tests which can change all

the way to and just today i updated hive to actually start using them so yeah within the next couple of days we should start seeing failures for the clients that have not made it activatable as for yolo v3 we there is an open pr for 27 18 and 29.99 which we need to review and see if it's mergable um and what else is 2565 on the table as well i think we have merged basically 25.65 but it's not activatable right now and so would that be like a week or two

of work same without a basu to get done and hard to say really um because the transaction changes are pretty large so it might i mean we're pretty slow at merging large prs so i can't really um i can't say right now okay great thank you for the um another mind i think thomas uh to come in to the meeting if he's up and around

then we'll get back to him when he is if he gets here just got in here oh perfect timing come tomorrow sorry sorry guys the time zone changed and calendar was still showing the old time and then i noticed the twitter entry from team so team great that you first like laughed if you're asking about that in my progress so we've seen today uh some uh some failure on the bear zoo nether mind ap one five five nine integration s40 berlin yellow v2 uh will join as soon as uh brazilian get his running version i think that martin was uh mentioning

this week that um it's already done for 29.29 so we should join soon um apart from that everything else is nice we're still looking for what's being added i mean i've seen two six six sixes on the agenda potentially 2935 uh myself i was working on it and it's ready so have a look at the recording from puja about 2935 what we think about it and how it can improve ethereum yeah that's that's it from us we will join whatever is there i mean like i'm not trying to say no to any ip that is decided by others we'll join and we'll do whatever is decided for yellow v3 or v2 great thank you and then open ethereum

is not participating on yolos at the moment for the last piece yes that's right cool sorry one more thing from me so we are now trying to build and connect the gmp library to support this modex repricing so you can also go with it if it's all ready and we'll add some library that will probably provide proper performance if needed so no problem with that as well okay thanks everybody um i think that's i think that's it for

the client teams that are that are participating in yellow right james yeah so then for nethermind that means you're you're mostly merged but not synced not sinking to the network yet and basu and geth are both sinking for yolo v2 yeah by the way i could also add um so riola v2 there has been zero activity uh but what we plan to do is take everything that was all the transactions from yoda v1 and replay them on your lobby 2 which should i think all the fuss fussing stuff that marius

did was done not using replay protection so we could just lift it across wow that's pretty cool yeah awesome okay and for those um tuning in or on the call that want to know what's going into these yellow specifications um there's a repository on github.com eth 1.0-s-p-e-c-s specs and i think that's in chat right now actually uh yeah so james posted those links in chat

so feel free to check those out to see exactly what commit hash to use for which eip's specification when implementing okay if that part's done i'm going to copy and paste into the chat some of the stuff from discord um here so i had three questions that i posed last uh during this week on the 27th when was that was that like a tuesday yeah that we need to figure out relatively soon in order to go forward with berlin so we're not dragging that out any longer so the first question was do we all agree

that all the eips that successfully passed the lov 3 plus eip 2565 the mod exp gas cost eip can go into berlin so that's all eips listed and yellow v3 plus eip 2565 going into berlin and i didn't see any descent um i think and i think nethermine basically said they're good to go for that the one exception will be something that i listed in question three which was um how comfortable people are with moving forward with 2537 and so but before that the other one is

our client team's comfortable with implementing the list from yellow v3 and two to four weeks of dev time um what do we think on that second question uh do people think four weeks is enough time to implement everything from yellow v3 uh for those who are you doing leolo one quick question if we're gonna do 2565 why don't we just pull that into yellow v3 is there a reason why we shouldn't the mod gas the mod exp gas repricing the reason that was given last time was just um it's so small we don't necessarily need to put it in but i guess you could

literally flip that and say it's so small why don't we put it in yeah it's going to be easier for me to code it with it as yellow v3 than it is to code it without yeah good call um james can we just change yellow v3 to add that to there uh yeah we can do that okay so yeah uh i'll have uh we'll have james go in and change that and that will um that will be what people we can just say yellow v3 at that point and not have to include other eips um so other questions on that yes just to clarify

so 25 37 and 23 15 are linked with the certain commit hash in the specification is that the exact same one as was used in geology one and two or has there been any changes at all they're the same it should be the same the reason why specific cache is linked is because um i will have another pr yeah it's good that it's it does link a specific cache i just wanted to clarify yeah there were no changes it's also to not make a mistake because um last time we had some play with the plot who merged the pr which was in the draft um so

it will be a little adjustment of gas prices constants only no changes in other parts of the spec and this i don't publish yet just to avoid any confusion so whenever maybe james indicates that it's fine to publish kind of a final spec for berlin i will just merge it wow i'm not i'm not really comfortable with that actually um what do you mean for changes of the gas prices or what um well actually a gas implementation is faster

than the 1962 which was used to to derive previous prices and new prices uh so you have a very good margin yeah i guess we'll have that discussion later on uh when this changes i mean it would be nice to get that those things the at least together earlier so then clients and stuff can be ready for it so well i can publish a draft or even merge it it's uh up to everyone if you just want to consider the spec final or just pick a

look at the draft well i mean once once you update the gas we need to redo some benchmarking and uh people need to give thumbs up a thumbs down if it's okay on their notes well okay i will well i will just merge it up to the call yeah let's merge after the call and by the end of today let's get a new commit hash on there um for those um that alex is merging at least yeah four and we'll put that in for yolo v3 and then with with that in mind does that change your answer any answers for two to three weeks for you

will be three or two to four weeks you mean yeah two to four weeks yeah i'm do those changes on master do they also change how errors are handled or not handled no no no it was removed so there are no changes from like logical and mathematical parts as well only changes in numeric values of the constants okay so yeah y'all don't have to have an answer for this since we we don't have you know we're not implementing v3 some of us aren't implementing v3 completely yet but um i guess i can just go through the

teams for two for a two to four week time window what does that look like besu for um finishing yellow v3 the gas repressions are easy um it seems like a reasonable time frame for the transaction envelopes um that being said we won't support yolo v2 and yellow v3 at the same time it's going to be pick one based on the hash so yep okay and this would be not having yellow v3 like done not having yellow v3 launched completed and killed in four weeks this would be having it coded up to start going with yellow v3 with between two and fourth uh two and four weeks that was the the question i think i should have been more clear

launch it in two to four weeks yeah yeah okay uh geth what about y'all possibly okay that's fine we don't have to have a complete answer today we'll have more um info on how it's going in the next meeting uh and then uh nethermind i think you already answered you're on your way um so this sounds like a good timeline yeah i mean the remaining things are must be ready the envelopes seem to be to do quickly as well 2930 goes in as well right

29 30 does go into yellow v3 yes okay and then open ethereum's not participating and oh wait are yellow is open ethereum not participating in any of the yellows or just yellow v2 uh i think we are just yellow v2 for your v3 would be super but we i need still to check that because we already started 29.30 and 39.29 is close to finish basically pass test we should be in that timeline for three weeks be ready for your weekly okay yeah we need to check that but probably we'll be okay with that timeline

okay sounds good and um you can give us an update next meeting if something changes in that estimation okay okay i think that's all the team so it sounds like we've answered question two so um question one it sounds like we have yellow v3 shaping up to include eip 2565 and to include new commit hashes for some of the eips that are getting merged today and then question three are all the teams comfortable with moving forward with eip 2537 if there are concerns about implementation or security of 2537 that will cause a significant amount of more testing time we need to know so we don't have to have

that eip delaying berlin so um as of right now we kind of are moving towards what's in yellow v3 going into berlin um and what's in there also includes 2537 however there were discussions over the past few months i guess or at least a month and a half about evm 384 as being an alternative to 2537 my understanding of the discussion there is that evm 384 is considered by some to be a safer alternative for the specifically for the use of the bls uh 12 384 pre-compiles

however there is the a few unknowns about it such as how long it'll take entirely to build out i know they've been giving updates and been working really quickly the 384 team have but um there's there's the biggest question i think and alex blassoff correct me if i'm wrong because i know you were the one who brought this point up the unknown around how much it can be optimized gas wise to be efficient for people to actually use on mainnet compared to 2537 which has been heavily optimized and if there's even a person out there who could do the optimization work to get it up to par with 2537 um so we're kind of juggling that right

now as the way i see it um anyone can jump in if i'm if i'm speaking incorrectly on the topic but um we do need to figure out if we're having 25 37 in because i know that there's been some trepidation um about putting it in for security reasons so is there anyone who has comments and or updates on the things i just discussed with this and if not i'll do more more pointed directional talking points well if there would be no like direct thoughts on this um i have actually an idea how to use evm384 and not have this work wasted

okay uh i mean well my concerns are largely two factors one is performance uh which is still unknown compared to and also compare what we will compare as a reference performance either my 1962 which is kind of slow or get an implementation which isn't gas which is uh actually faster and if you take an assembly back and it's even twice faster on top of this um so i and who would and who will make a call like if you accept twice performance uh is it acceptable in general for users but

without numbers we can only speculate here the idea i have is um like the problem there uh is there is a boundary between the evm and the internal implementation of the op codes and actually how you program them uh used and also well the current implementation of the bls 12 381 curve um is kind of uh macros plus assembly uh at least for external user and i don't know if many people would want to and be able to even review this implementation at xander's a day i personally doubt

that i could do it uh so my idea is we can use the same work so the same set of op codes which is in there namely additions subtractions and uh uh multiple montgomery multiplications and instead of this we can just uh uh re-implement like migrate the pre-compile and have an approach to write the crypto pre-compiles using this set of opcodes so it goes kind of backwards so if mathematical implementation is correct uh then the precompiled implementation will be kind of as correct and if there is some intermediate

language to write it it will be also kind of one implementation across all the clients uh but just a lowest level arithmetic implementation will be language will be client specific and language specific so we may take it will save going back and forth through the boundary of the virtual machine and simultaneously it can kind of get to the point when there is a single reference implementation between all the clients and it's well it will be single one which people didn't like uh but simultaneously there will be no consensus divergences

in this case so are you talking about basically about the system contract which you use as regular uh evm op codes is that is that kind of the case well it's kind of evm without all the functions of evm so it will be very small like it will be set of three or four exported functions uh which you would be able to call and those functions will be implemented by ethereum client uh but actually calling them will happen without any overhead of evm itself without care about the endianness of the encoding with possibility to use the stack and not the memory in evm uh and similar

benefits so it's kind of if you look at this is actually kind of how 1962 is written there are functions namely addition subtractions and multiplications uh and those are basic ones and everything which implements a specific curve is on top of them so we can continue kind of do the same approach and evm384 or they have uh like they want to give these functions to the evm level to users and final contracts uh what i think it's possible is kind of hide it one level down and um that eventually it will be possible to just

re-implement uh republican files using this set of four functions for field arithmetics uh up to some like uh up to some uh modules and then it's kind of possible to reach the point where uh performance is going to be uh like how 1962 is written because it's also written in a way that it doesn't it's not made for specific curve it allows to capture part of the optimizations in runtime but you have inefficiencies everywhere because you cannot align constants you have to inflate sizes or

structures uh keep some references so it would essentially be the same it can be very well merged and well served as a reference creator engine sounds like this but if we if that's if that were to be a goal then i think it would be a mistake to go with the pre-compiles in 2537 right now because if we add them we have them forever and they will always be in the code base no no uh i mean we can add them and that if we would want at some point to

flip a switch those can be uh re-implemented using the same primitives and for example 2539 for similar sibling bls 12 curve it can be also implemented in a similar manner so for external observers they will be pre-compiled so there will be fixed address there will be an api internally uh yeah 25 39 and internally it would look like uh well it it will be uh an implementation which calls some uh internal functions of the node uh but those functions was will also be standardized

and namely as a source the same codes of uav m384 so is that is that a more secure way of using the the pre-compile codes or is that a more efficient way of using evm uh well it's versus trade-offs i'm curious about well it's kind of proposal which does the following it will it potentially reaches uh good performance numbers potentially at least i think that it would reach the same performance numbers as 1962 implementation well it will not reach the optimum where you can hard code everything an absolute best performance

but it still will be very fast compared to like the same price as pre-compiled surprised right now and the drawback is that it's still going to be kind of one reference implementation in all the clients yeah but it somehow also captures a bit of the worst about both cases i mean with precompiles everything can be optimized and the drawback is that you have a lot of custom things that need to be implemented on the side of the evm they are more in the consensus critical part if you were to go only with these small lego blocks available to the evm we would have a lot less

on the in the consensus layer of nodes and all the sensitive stuff and more advanced crypto would be built in layer two so we wouldn't need to be concerned about consensus flows there really well that's why it's only it's a idea and at least for now uh i mean without any uh numbers for performance and without uh even the well at least i don't have any any idea how the final contract will look to which actually implements pls twelve straight one at least curve

operations uh in any language which was chosen by guys who do it um sorry yeah yeah i mean i cannot make any judgments about this but at least the performance is crucial especially because as we had the discussion yesterday actually it was a very good idea to remove additions and multiplications all together and just leaves a multi-exponentiation operation but since we kind of optimized for very few kind of specific cases where we want our best in-class performance um like we have to keep additions and also we

have to keep up with performance so please continue martin no i was just going to say that i saw uh that axic is on call i was wondering if the expert sausage has any thoughts about the discussion can you hear us so is your mic working yeah sorry i didn't realize the time zone change um it's okay and i haven't listened on on youtube either so i'm not fully sure if i understand the discussion correctly um i only joined probably five minutes ago yes we we got to starting talking about

25 37 and this there was a bit of discussion during the week in old quarter channel where basically ibm 384 versus 2537 or both or um like what is the same approach should we do both should we do one of them and which one [Music] and blaso is talking about performance of the one versus the other um yeah i saw so i was wondering a bit about for example the performance numbers and also whether because i've seen them as two approaches that are not

like hand in hand i mean as i've seen it it's one or the other but i may be totally wrong about that so please do you have any thoughts well i mean even depending on an amount of workforce required to finish the uh evm384 and maybe some set of tools so external developers can easily implement uh new curves or maybe some other operations required uh i would be glad to see both so just in case if there is something needed then you can get it immediately without waiting for for example another compile and even going through this process but i mean i always try to optimize for

performance um so maybe it's just a personal opinion so if user is already implementation which is faster i would want yeah i in my mind we shouldn't optimize for performance if it means we need to add new pre-compiles for every curve that we possibly want to support if we can instead do the simple thing with just adding a few basic bricks and yeah well the problem here is that when you say for every new curve uh i mean in practice there will be not a large variety there occurs with specific properties which you really want and this set is very limited like very very limited

um if ever in the future yes uh sorry alex to interrupt would 384 even be sufficient for every new curve uh would it be enough for say bw6 no it wouldn't just because the field size is different and i mean i was mentioning once that's for example it may happen that for 324 bit arithmetics the cost of crossing the boundary of the evm dominates the performance so not arithmetic but just everything else maybe for 768 bits it will be the opposite and then it's

like it's a clear win it's not there is no reason to make a precompile which would implement this just because performance will be essentially the same um but for 384 well what you could do bls 1281 bls 12 377. and potentially is there uh um well there are fancy occurs for another forms of recursion and half print cycles which are b and curves over fields which are roughly 380 bits and those you can also do but other reasons this there is not much variety of choices of which i am aware

which people would want to use um uh kind of at this point in time i cannot project into the future maybe someone finds something extraordinary uh i don't think it will change the picture so um the set is limited uh and well again uh performance numbers should be there first so to make any judgments when you say crossing the the evm boundary what do you mean by that oh well i just mean that uh well if just because you executed as any

other up code in evm it means you do all the other stuff in evm which you have to do during this opcode processing plus i don't know how much time does it take to re-encode big end in little and then so compare all this to one single uh operation let's say montgomery multiplication well like let's say eighty percent of magnitude multiplication and accounts at addition cent subtractions have say a share uh indirectly um so i wanted to reflect to some something else you you said that the um the implementation of bls12

using gim384 uh it's just hard to to achieve um and the implementations for other curves so just to to give maybe a brief update on that um there is almost a completely working pairing uh implementation used in gamingmp384 um and that is uh done by paul and it's not just handwritten for that you know specific operation it's rather a system to to write these operations so what uh what we're doing is we have a code generator script uh which is right now written in python

which generates the which has the building blocks for the pairing um implemented and it generates optimized code using dvm trader for opcodes and what this allows is that i mean one of the reason it was done display because we had these different versions of the evm 384 um and this way it was easy to change how the the arguments are encoded but it also provides a much more readable um i guess source code because the end result what you want is is something highly optimized and um i guess what i wanted to say is

that this is almost finished um which you know hasn't been the the case i i guess when when this entire discussion started it looked much worse that it may take you know forever to to have an implementation of any bls file operation over evm384 because there's just a lack of um of people who understand this crypto and understand evm and are willing to write this should we have found such people i think that there would have been an implementation for a long while um but at least we started to do it

ourselves and and it's almost finished um so i think you're in a much better position to have final numbers to compare against um and another response to what you said that this is still limited to 384 bits which is correct um but the same and the same kind of uh instructions could be introduced for uh bigger bit bits and to cover more curves ideally it would be nice if this could be fully dynamic so you could have a single opt code where you specified a bit bit i guess that could be possible if you would have that as a immediate argument and you still put some limitations on that

um but that goes i guess more into the direction of the same d proposal in a way um so we haven't proposed that we only propose to to address 3d 384 bit but the same way you could introduce three more up codes for seven um and 768 bits so one thing that i'm um a bit concerned about obviously performance whether we these can be written performance is a question but um given the expertise needed to write the crypto and given the expertise needed to write the evm um and that there's a very small set that can do that um how

i'm worried about our ability to assess the safety of actually uh writing these low-level operations crypto operations in the uvm whereas when we write them in standard libraries it is hard but there are experts that are available to audit and there are techniques available to do formal verification uh both of which on some bls libraries are being completed today um and i'm just worried that we're gonna have very complex evm byte code with little ability to and not to um speak against the incredible efforts going on your team but i i don't know if there's an additional three or four people that can then spend the time to evaluate uh the correctness um thoughts on that

oh sorry so last thing i looked at the implementation i actually don't remember what it was but i think it was a set of scripts which were just uh placing instructions for the uh implementation so i mean you say i think that was for alex b uh and the evil whoever could speak to it um sorry hardware well okay um i mean this is the only concern here would be it can we also like it should be good then to also check the code generator and optimizations used in this are uh

same and sound uh it's also not my uh area of expertise but yeah it's a good point that someone brought whether there is even if there is a tooling which other people would be able to use for example to write some other curve operations using this set of tools i mean it is necessary to otherwise no one would be able to actually get their hands in and implement some crypto but then we need to also treason about the sanity of these tools themselves and for performance numbers the last numbers i seen it was exam comparison was a old version

of 1962 which was then updated and then um as a reply maybe from paul maybe not from him uh it was that well the latest uh commit for 1962 is actually twice faster and it's what's kind of reflected in uh new pricing for 25.67 so um the numbers are changing i see there was a huge progress on evm384 it's just a question down to what this progress can go and also down to what this progress can go in every particular client because there was else a note that

such implementation is go is like 1.5 times slower than in evm 1 for whatever reasons without those numbers it's not possible to make uh uh like to like not possible to reason about whether it's good to replace a brick and mortar altogether with this uh or it's not i would say performance matters so it's not but eventually if this work is complete and everyone is satisfied that it's safe then it can be also included as a tooling at least whereas the people to write crypto and evm like maybe very well specialized crypto

okay so um axic what about you so i would like to to give um answer to danny as well but i will start with very briefly maybe responding to this performance question um so back i believe probably in april uh when when all of this work started and discussion started circuit and the initial results were posted alex you you said that the speed of the precompile at that given time was was already at the at the um at the speed which makes it feasible for your use cases

and and that is the speed we should target and anything slower than that is unacceptable um and we actually are quite close to that speed if not matching that speed now since that time i understand that the the the speed of the pre-compile may have increased um but it doesn't really stop from this old statement to be valid um you know that the performance requirement has been met and now with the pre-compile speeding up sorry now with the pre-compressed feeding up since the pre-compile hasn't gone into the chain at that point um i guess we do have the ability to

maybe use a faster version of the pre-compile to go into the chain but if you assume that maybe it has gone into the chain in april then would you have a chance to upgrade the pre-compile to be faster um i think upgrading pre-compiles is is quite a lengthy process if you look at all these repricing discussions and compared to that you do have an ability to to optimize code using even creative power up codes you don't need a hard fork to do that so that's just response to the speed but danny to your question regarding complexity um basically your question i get the

the feeling that that people may think that this um i guess crypto code using these uh even 34 of codes uh looks complicated and is is like magic but i would argue that it actually isn't um the even 34 op codes are basically just those same very building blocks which many of the bls 12 implementations actually use internally and they have those building blocks um and they use that in the higher level operations and evm 384 i mean any implementation using inventory 84 does the very same um so as long as you can in terms of like verifying this you

basically have to um you can't detach the the op codes the uh at least in in terms of verifying the let's say a pairing operation via ls4 pairing operation uh any evm uh you don't need to provide a proof for the opcodes you you only need to provide a proof for uh whether those op codes are used correctly now then separately you do need the proof for the codes themselves but if you want to verify a let's say an assembly implementation of the same you have to provide the proof for the entire process in the same verification so i would and those building blocks are

pretty much the same as as they are when you write them in assembly or c or other languages and and understood i i would say practi the practical question on my end is do we have if we if we had these implementations completed uh do we have someone or multiple parties that we think are capable of auditing them or do we have someone who's capable of uh formally verifying them you know from a practical standpoint i would say we do um i mean just one example you have kevm if you only want to look at the evm part um that being said of course k

evm doesn't support even trader for operations so that would be extra work but i i don't really think this is um you know this is something which would take just verifying uh like a vls12 pairing on even trading four i don't think that would take you know in order of like two years or three years or something like that um and i do think that the the baseline tools are available um but yeah i do agree that it's a it's probably not as straightforward as uh i don't know verifying the rust code because not many people have done that so

um not to i don't want to take the whole meeting on this topic um so the primary question i had in asking this is less about the if 384 is a good idea it's more like if it should completely replace 2537 because of people's concerns over optim or over um security and if there's you know um if it's more efficient and things like that those kind of questions those those need to be discussed because otherwise berlin could be pushed out all the way till well into next year if we keep doing this so we need to come to a decision of are we

going to be putting both in or at least putting in 25 37 and then deciding on 384 later or are we scrapping 25 37 because of problems that we deem too important to put into the chain right now if 384 is going to solve them so that's kind of how i see it and personally i think we should have both of them in because i mean i don't know i'm not a client dev so i don't know about like like client bloat from having stuff like pre-compiles in the um code that then are like not used after a certain amount of time but looking at i guess i think about it as how long

will these be usable until eth2 type of logic can be used instead for more general purpose stuff or is this going to be used you know a long time from now go ahead martin doesn't matter how long they will be used they will always depress them so if there is a vulnerability and that can cause a consensus flow in one of them um then it will be there it will be sitting there for years so so that would just be a safety concern then right okay so if that's the case then thinking about it does that sorry maybe this is a dumb question but

that's independent of whether we do one or two of them right like if we do say evm384 didn't exist you know there is a security risk about potentially having a consensus issue with 25 37 and vice versa like if we didn't have 25 37 you know there's still the risk there so it's like you know obviously there's like twice as much risk because we do two things but there's no like they don't multiply in any way it just leaves a which is more attack surface the more stuff yeah exactly because we'd add two things to the protocol rather than one right yeah but i wouldn't count them as like one thing or two things it's more like how much attack surface does the pre-compiled make

quite a lot and how much attack surface does the uh individual of course make and it's it's not like they're equal i think it's more like mobile businesses yeah it's more like moving the streets from uh yeah that we did a good job and in implementing the pre-compile or users uh right we can move the implementation from the platform into layer 2. that's that's what i'm doing yeah and simultaneously i also responded to the argument about performance like it was uh and performance yeah it was for well first of all it was from the day one an invalid comparison

like you would compare uh uh as a kind of the most general implementation uh for carouse medic up to some extent of course of 1962 which well had some performance there but since a half year later it's now twice as good and before this even before this point all specific implementations which potentially used by the clients and namely gas they are even faster than 1962 right now at least 1.5 times uh and my local computer if there is no assembly involved anywhere so now it's a question well is we spend a year uh

testing and optimizing and doing all this work to give users a tool which is as cheap as possible or like as we comfortable to moving forward with the prices so we leave ourselves at least 1.5 time margin in performance uh and its varieties compared to let's say guest implementation at least um and well there is a tooling for user which is a and ethereum is a platform so we try to serve uh and especially very specific needs in this case or we say well guys you have to place three times the price just because we were scared to even try to break it

and i wouldn't make this call for uh end users and wasting someone's money um the other issue at play is that open ethereum is going to try to have an audit or actually i'll have open ethereum speak speak to speak to this because i just saw a comment in the agenda but is there something like an audit that might happen depending on if we're going forward with the cip um jargon or um marcelo yeah this is marcelo we're concerned about this because the audit for eip23537 is quite expensive so we want to make sure it's going to be included in berlin fork

yeah because right now we're more and more seemingly if he just feels on the fence about it people do so yeah that's what i'm trying to get clarity on so we can move forward with stuff so martin when you keep bringing up the security concerns it's hard for us as non-security professionals to gauge how drastic of an issue it is compared to other security concerns for any other eip yeah so in my i can't really put a number on it it's

obviously a lot bigger concern because us node implementers and client implementers who knows everything about how the evm works and the semantics of this and that we cannot meaningfully audit the code we cannot meaningfully check that the test cases are as you know and that they cover um it's a big unknown and we can implement this and just hope that yeah everything will work out there might very well be consensus issues um that's not the end of the world um

i don't know what do people feel i mean i i would feel a lot better with having smaller smaller surface on the platform layer and help people build the crypto in layer 2 as much as possible and 384 doesn't do that though right 384 is still layer 1 completely i thought 384 just enables people to build the complexities on in the application layer yeah okay we don't have to show everything in the consensus there oh when you say layer two you mean the

virtual machine layer you don't mean like okay got it yeah nothing normal okay oh go ahead so then the if let's say we were to do it um is the amount of work to make sure it's safe it just still feels like something like it's going to take longer than two or three to four weeks to get this figured out to get which part figured out uh today to get be it to do the work for the bls precompiles to be well uh this might be a good time for my updates about that sure

um so this is going to be pretty boring as all good fuzzing updates ought to be um so uh you know we have been running a fuzzer on eip 2537 and 2539 for a while now uh it was running on like eight cores until recently and we bumped it up to 32. uh so in for this particular fuzzer uh alex wrote it it's aware of the algebraic structures and generates valid and invalid inputs to uh fuzz the rest eip 1962 library against the golang implementation that's currently in the draft

go ethereum implementation of 2537 so one iteration is two executions of each precompile once in rest and once in go we've been running it for a little under a week on 32 cores and have done about like 270 million iterations uh with no issues or incompatibilities so far um and we did an additional million rounds using the go ethereum rpc to get like the full end-to-end integration test um yeah like that's the whole update is we've been running this for about a week on 32 cores we expect to keep running this for uh several more weeks

okay so from hearing everything right now where my mind is is that hmm i guess um i guess i have a question for alex um aksak um so aksak 384 when what's the earliest it would be ready in your opinion is there is there any way to know that right now well the op codes are ready um but i guess the question is whether uh let's say a pairing operation fully ready yeah mounted on three before

um i mean it's really hard to tell because right now it's um it's mostly just us working on the implementation but we do um especially recently we do get important feedback from um from others um on this topic um but based on the the progress of the past uh i would say four weeks um um because in in the past four weeks in the fir so like uh two weeks ago we got the mirror loop done and the last two weeks we got almost did the entire final exponentiation done um so based on this progress i

i really hope that um we should we should have it done in by next all codex but no wait you know i cannot cannot really promise but that wouldn't be that would i mean that work wouldn't need any hard forks or anything to finish you just deploy it right as long as we the hard part just needs to have the the new op codes um yes that's correct i mean the the having test implementation uh the pairing implementation the the main reason it is being done is to have a fair comparison in terms of uh speed and and cost

does anyone else have any major opinions on this especially from a timing perspective that i've been trying to hone in on i had a i had a question about like let's say if we move let's say if we to if we next over the two weeks we have discussion and then decide that the this one will be not in berlin but in the next fork how hard is that to remove from yolo in a from like a practical perspective 10 minutes when's the when's the earliest we estimate berlin might happen and the latest just for reference earliest is um three two to three months

yeah mid january or something right didn't we talk about that the other day yeah i think when we looked at the schedule like if we rush things a ton which i don't think we should we could maybe get it out by like mid-december but i think mid-january-ish is probably a better estimate and this assumes you know like it's kind of like if you don't think about bls for a second and you just look at everything else and assume the process goes goes smoothly yeah so taking out bls mid january or even keeping it in mid january is a possibility yeah taking out the arguing about bls right like

yeah oh yeah how long it could take with arguing about the ls that's your the mind's the limit danny it can be as long as we want berlin to take um if we don't get bored on this well we can simply pick a number which we say well if performance is within this from [Music] go with sirium's library on the same machines and uh well like then this number is okay for everyone my my issue is less with the performance because even if we assume that both get to a performance that's acceptable it's the the time the timeline and and interaction with the community so if if i'm if i'm thinking about 384 realistically

that's like a year for all of the before the hard fork and the optimizations and all that stuff has happened and so then i there are scaling solutions like layer two scaling solutions eth2 people that are essentially wanting to use the bls curve and are are unable to and if we say hey guys like are we comfortable telling them to wait a year for so that we can be more comfortable with the pushing the security stuff or conversely do we say um maybe this is the bls stuff is too too much to do in the next two weeks or so

so we instead have a fork for it early next year in like march or april that means that they wait like four or five months versus a year but we still get time it's it's more of the timing stuff i guess is the like uh because we could have both and allow the community to use the to use the features yeah and what used to kind of happen is i think some of us are i remember just kind of making decisions before like older core dev meetings of just like we're doing this

but i don't really feel comfortable doing that with the bls thing and i don't think that'd be fair anyway so i think in absence of a decision there will be no action um for that reason so that might delay berlin and that might um involve just going forward with berlin without bls and then figuring out the bls issue later i would i would tend towards the latter of the of of the taking it out of berlin and saying that it'll be in the next thing but have the next thing be sooner yeah something like that could work out for sure i feel kind of bad because i know it'd be useful for some verification stuff on eth2 um and that there were other you know of

course all the stuff that james wants to do to um and his cello and stuff like that want to do with um with using this curve but yeah i can speak to the e2 context um there's two main reasons that people want it one would be to add additional verification to the deposit contract uh to prevent uh loss of funds in some cases uh this this is not requisite um any tooling that you're using should protect you um and that has been a major um push in the past few months um additionally beyond and also for genesis deposits we don't expect that

this would this pre-compile would help so it would be in subsequent deposits that it might help so it doesn't it's not going to have a tangible impact on uh many deposits that are going to happen over the next couple of months um the longer term thing that we're very interested in is um e2 like client verification inside of eth1 uh efficient like verification which would require a bls precompile at which point the eth1 chain can learn about the data layer of e2 and rollups and things can leverage that scalable data later before a merge so that's the major one that's easily 10 to 12 months out and so but

if we do get to that point in which we have scalable data later on eth1 and can't e2 and can't use it in each one then it kind of sucks uh so that's the main sure i can immediately disappoint you that for this particular purpose as was discussed yesterday on uh in your discord channel uh there is some kind of fun with uh with uh addition operations of the point curve points which requires inversion which potentially may be prohibitively expensive if there is a inversion is implemented using the evm of codes

well not prohibitedly but you will get like three times amplification factors on top of the sub-optimal performance before and that's specifically on bls segregation yeah right i don't have a good handle on how that might affect but this is probably like one transaction that some actor is sending with uh 128 maybe 256 aggregations and one signature verification um per six and a half minutes so i don't know if that is cost prohibitive uh but it would definitely be worth

well i mean it's just a factor of like more than uh single digit potentially more than single digit number so it's what i call prohibitive uh but it also depends who will be paying this cost if you don't care then why not well i mean i definitely need to fit it into a single block uh but right then it still could be prohibited prohibitively expensive yeah uh danny for let's say that bls stuff was march april of next year does that work with the timelines of things you're talking about for the longer term yeah on the longer term stuff that we're interested in um [Music] yes yeah so i i don't i don't feel

comfortable making a decision between bls and evm384 but i will push berlin out i will push the the uh the the the bls eip out of berlin because it's just taking too long to to it's like put it keeps it keeps holding back all the other stuff we're doing okay um yeah i agree with that anybody else have opinions on that yeah i think that we should split berlin into this separate pops one for bls and 10 evm changes for combo changes second for 29.29 plus 29.30 and potentially 2718 and the third path

for anything else that we already tried to add because now we're free to five months for berlin people will be pushing very hard for adding new things and they'll start being oh i i just declare for my comment i would say berlin would come out in like the two to three months maybe december january but if the bls stuff would be after that yeah all he's saying james is just saying release everything in yellow v3 except the bls curve stuff by mid-january was the was the his implication that this one is very similar oh okay i'm trying to show that we should

already show people the path for anything else that we can start to work on on it in parallel uh so people don't see that work as serialized and waiting for berlin to happen if berlin has some delays around 29 29 for example because people will be pushing for addition of the new face i like this 266 is one example like we already mentioned it that's potentially being added okay i got what you're saying okay well what we'll do is unless there's something major that happens between now and the next meeting let's not have bls um like 2537 or obviously uvm 384 um in the next berlin hard fork and

we'll either do a thing where we split berlin into two like we've done before with um other hard forks or um we will we're by the by that time we're gonna hopefully uh by the time berlin happens we'll hopefully have had a plan in place and more organization around how to get eips through the process that's more clear for the public to come into a meeting and pitch their idea and their implementation and their eip and be able to successfully do that without being roadblocked by other eips is that kind of what you're trying to accomplish thomas yeah sorry just um just showing the

people path for things outside of berlin to happen in case berlin is delight so they can start to see that maybe simpler changes may come before berlin if berlin is delayed so it just starts showing some parallelization of the bundles of heaps okay that makes sense okay so there's that decision has been made just for the pronoun taker basically unless otherwise indicated over the next two weeks before the next meeting bls or 2537 is out of um yolo or should we take it out of yellow two to be

to be clear james no it would be yellow v3 so take it out of yellow v3 and delay it beyond whatever the next hard fork is going to happen yeah unless someone is feeling really strongly otherwise i just i i uh sure um okay so there's that um we already had a fuzzing update from james thanks james um so that's that off the agenda so agenda item two is account abstraction discussion 2938 or eip 2938 um sam are you on the call i am and so is the rest of the quilt team oh excellent um so i think where we left off at the

last discussions we were we were looking for feedback figuring out what the process was going to be um and we were wondering what we need to do to get it to the constituted for inclusion state um is that is that where we left off yeah i i think that's basically it um i i think it's not another big issue for now just because obviously right now the awkwardness is mostly focused on berlin and this is definitely not part of that discussion or even if it's like real and will be split split up or something that will definitely not not land um in any of those um but yeah basically i think i think last time actually uh i think maybe it was martin or something um right to who said that the gut team wanted to to

have a look i'm not sure if you had time time to do so uh yet um but also just in general basically what uh i i'd just be interested or we would just be interested to to to hear like what what like remaining stepping stones there would be for for fun ep like kind of protection to just um be moved to consider conclusion um i am sorry i personally have not uh reviewed it sorry about that yeah i mean no voice obviously um but then the question is just um just because we would like to to to make some progress here doesn't just make sense to to i mean i i

i assume obviously you're you're busy right now like the guest team in general is probably rather busy right now um is that like a like how how much effort is is it for free for you guys to to determine i i'm not sure um basically like what i'm saying is basically like i'm not fully sure what the threshold here is to to move to considered for inclusion what what exactly is the standard that that an efp has to has to meet um and and how much effort is that to evaluate basically uh my clients or martin go ahead uh that the the consider for inclusion doesn't mean that we'd understand

or know how what the eip would need to be to actually be included it's a there's a there's a the small assumption that if if apr that was like sufficiently incorrectly formatted would be accepted by the core devs so it's actually i think lower than what you're going for at this moment okay then a question so so so does it still mean that like some at least some very basic approval by the by the gut team is still necessary though like no not obviously approval in the sense that we would want that to be included more like that that looks feasible or something yeah i don't know just it's just a

little bit um hard to pick out exactly um yeah i think you got it right there um it's not like if it's gonna be included for sure for sure but like um if it's possible would it be possible kind of a thing and if it would be supported on a on the just a general level yeah the client teams would decide that so that'd be like geth open ethereum nethermind and um baysu okay and then where would the best place be to to follow up on that because i i think ideally basically i would just want to maybe talk about it next awkwardness then again to to finally maybe move it to cfi so so where where would i

best follow up there uh to remind people to give feedback i'd say the all core devs chat and the ethernet discord but martin what was your comment no i was going to say the same thing yeah opened up this corridor some other discord yeah but that's probably the best and should we do a breakout room for this maybe or is that not really uh we've um we don't need a whole breakout room yet for it um but what we could do i mean account abstraction already has its own channel and eth r d right yep okay it looks like yeah and it's actually pretty active so what we can do is if you wanna you can

end the ethernet discord you can tag people like um if you have questions for certain teams you can tag whole teams by doing um at uh and then the team name so like at geth or at turbo geth or at nethermind etc and that'll ping people from there and then if you don't get responses from some of the teams or if you're interested in talking to certain people talk to me or james hancock uh and we'll connect you with the people you can talk to yeah i think for the breakout room if if you compose the eep and el cordev's and we can review it there it feels like we'll have a better like a better understanding of what

might be the specific things we want to discuss maybe on a call uh once everybody's read it and and people kind of have uh a better understanding of it sounds good although i would say like maybe like main discussion of the ep is probably better placed at the point of time after like the main berlin effort if it is done because i think there there would definitely be like need to be quite a bit of discussion on whether this is actually makes make sense on mainnet or or not but but i i do think right now it's probably it's it's a bit too early in the process um yeah but but okay then then our uh we will follow up um over the next two two weeks basically and then hopefully we'll be in a position to

to decide on cfi um in two weeks yeah that sounds great yeah sorry sorry if that was a little confusing but yeah if you have any other questions offline feel free to reach out to me as well or james hancock or um yeah but anything between like there's you have clients with specific questions with specific clients or just the process in general uh reach out to me and i'll make help make sure that those get those lines get crossed awesome yeah nice thanks thanks for them awesome okay um before we go james can you pull up the calendar link to the all core dev and like ethereum pm calendar to post in chat and then the all core devs chat and discord that'll

be helpful for the time zone changes that have come up and are coming up for certain places around the world um there is a calendar that james created that has stuff like the eth2 call the 1559 calls the all-core dev calls that kind of stuff um and it adjusts with time zone so if people want to uh add that calendar to their calendar software there's a link that uh will be posted in this chat and in the um all core devs chat and discord or in the eth r d discord so that'll be helpful for people with the time difference um the last item we only have a few minutes left but this is this will

be a quick one there's been issues on robston uh does anyone have an overview of those issues i don't think there's anything we can do because it's out of our control as far as i know but does anyone have an update on the issues and if there's anything to glean from that i think the block gas limit was lowered right i just want to know if there's any if it's if it's something that's going to work itself out or if it's something that needs to be something done about i don't think we can do anything but uh who was talking before micah maybe yeah the the very short summary is that basically very few people mine on roxton and so if

someone gets it under their skin that they decide they want to take over ups and it's relatively easy and when they do it's kind of random what what damage they do sometimes they just simply don't mind any transactions like they just disable transactions or something and so there's mine empty blocks for hours or days on end or they will lower the gas limit or they'll raise the gas limit or they will just like just basically be a pain on roxton and the only thing we can really do is just get people to mine robson which means get people to throw 18 down the drain so can we create a permissioned ether chain where we have it hash so we can still

verify the behavior of testnet in the case of using various block times and random block producers but at the same time use the list of block producers to addresses that we have control over would another thing is like maybe client teams can just run a minor i don't know what the hash rate is on robson though like is it it depends on whether it's under attack or not yeah when they attack when the attacker shows up it skyrockets and then exactly disappear there's

nothing it takes like hours before the drops low enough that anyone can find a block because that's the thing i don't think like for example for us that basically we wouldn't mind setting up like one gpu or whatever the mine on it but obviously you know it's very cost it's cost prohibitive to like set up a large amount of hash rate on the network yeah i remember um i think the ef set up a really beefy instance um to mine robsten and we've like left it on accidentally and we're like just like majority minor of the network for a long time accidentally that was a funny story um so yeah um does even i mean i guess is

there anyone like really begging us to get robston back on track or aren't most people using a poa network like gourley or rinkeby i've had a couple people reach out to me yeah i heard some people reaching out and asking what's happening because i think the gas limit in blocks was something like 600 000 which means it cannot deploy any 39 000 wow yeah maybe that the not enough time to figure it out but and so it's just i just we just tell people it'll work itself out eventually

i mean yeah i don't think that's actually true yeah it might not work itself out it could just stay under attack oh man um i think thomas's solution i think would solve the issue if we're willing to do that like it would give us a proof of work test net that is not constantly under attack otherwise i think we have to just hope that the attacker gets bored though they have they've been doing this for i don't know how many months so i don't know if they're going to get bored like this might just be such a small drop in the bucket for the attacker they don't care yeah we can create a very small change

for the clients where if robson if robsten chain then reject any blocks that are not from the list of addresses like super simple chain uh change i think for all the client devs do i assume right martin what do you think another guy yeah well you also have uh you know fast something uh if you run into problems because we try to verify um i don't know written eve see i guess i think that's the i mean it's a new consensus only okay if someone wants to spearhead that um let's talk about it on the all core dev chat and discord or put it on the

agenda for the next call since we've run out of time and i don't think we would anything would happen in the next two weeks anyway unless we spin up some minors so yeah if someone wants to do that or take the initiative and invite others to do it just talk on the chat and or talk to me and i'll spread the word i'd be happy to do that all right do we have anything else before we go it hasn't i placed a 2666 to the comments to the this meeting but i don't know if you placed this to the agenda 26.66 yeah uh oh sorry i missed that comment completely okay yeah to propose it for on track for

discussion i see okay um yeah do you want to talk about that for a minute we're already over time well i mean all the clients developers have sent me their benchmarks or i did it myself for a guess and open ethereum so the final numbers which are derived in this pre-proposal are what's right now the state of the art uh for all the clients at least it was at the point in time when it was last updated so it should not include uh so we should not add any dos attacks but will streamline prices of uh doing these operations into what these operations actually do

under the hood and what is the current performance so in the essence it's simple constants change got it okay any comments on that anybody okay yeah let's make that one of the first agenda items next time if that's okay alex and um we can go more in depth well i mean we can if there are no huge objects that we can just put it into the yellow v3 and then we could get it into the berlin it just like it's the same way as people wanted to put modex which is also simple constant changes uh in the yellow way three i don't see

why we should not do this the same there's other considerations i'm guessing we haven't looked into but is it really as simple as just like all the benchmarks are in is there anything else that needs to happen um i mean client developers already did everything for me so i was able to derive the final numbers for formulas i'm saying from their performance numbers i don't think we should split anything new into yellow v3 uh when like three minutes always do on the whole time yeah i'd agree with that i think that set a bad precedent i mean we can discuss it next time but not this time yeah yep that sounds good

um okay so yeah let's bring this up next time first thing sound good um yeah well it's a simple constant change so even if we discuss it next time we can still put it into the berlin without much trouble if we want to yeah we'll we'll see okay anybody else have anything okay time zone change everybody be aware of that for the call in two weeks the next call is going to be at 1400 utc on november 13th 2020 uh thanks everyone for coming bye cheers thank you bye thank you [Music]

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

[Applause] [Music] so

[Music] [Music] [Music] you