All Core Devs - Execution #94

Transcript

[Music] [Music] so

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

[Music] foreign [Music] so

[Music] [Music] [Music] so [Music]

Hudson Jameson: hello and welcome to ethereum core developer meeting number 94 i'm your host hudson and we're going to go to the first item on the agenda greg wants to give an update on the progress of eip 1057 so greg if you want to unmute and go through that real quick that'd be great

Greg Colvin: yeah um we've been reviewing it oh gosh since about april we had up a small suggestion from the police authority on the light evaluation attack and uh kik found a uh an exploit in uh it was actually a bug in eth that

um prague pow made just barely maybe exploitable in some future time but uh within a few days we had a fix and by about may um the fix was pretty well reviewed and uh tweaked so that it didn't have a performance impact and uh right now in the agenda and soon enough uh i'll be pointing to uh a better reference implementation um of the the latest um for uh for the prog pow eip and it's it's very readable right now

there's some my inner edits to do um mainly patching up links and things like that so at the next meeting i want to actually uh take that up way back in meeting 81 we published a decision to move forward with it in 82 we backed off [Music] and it was unclear but uh the overall consensus was to go with uh with ben's compromise of just getting it up on test nets and and keeping it ready but not making an immediate decision um whether to deploy it just keep on keep

our eye on the state of the network so two weeks from now is when i want to discuss that and uh by the end of the weekend i'll put up some links to places to do that

that's all

Hudson Jameson: great um i i do want to ask i'm not seeing in the decisions made section in the notes anything about us definitely spinning up test nets for prague pow or spitting up robston or anything specific like that did we in your recollection was there like a specific test that we talked about spinning up for it or was it robston or what

Greg Colvin: um no about it two weeks those are the sorts of details

we can discuss if we decide to to move forward

okay

Hudson Jameson: i would say like i disagree that we it is a decision made that we are spinning up test nets for that because from before the meeting looking through notes and meeting 82 and 81 i i'll need to look through the videos but i didn't see any definitive consensus around that and you even i think you cited a few people who said that they you thought they had consensus around it but i don't remember them publicly saying anything about it

it

Greg Colvin: it's such a mess i don't think the consensus was so rough that that we need to revisit that i know on twitter vitalik and and on uh

vip on jitter channels uh the italic and i've yeah sort of agreed um that the rough consensus in 82 was was ben's compromise which lays it out that way and the current eip lays it out that way but it's more detailed decisions we'll need to make on on what testnet to uh to bring it up on

yeah

Martin Holst Swende: and i'd also like to so i i kind of agree that that we did talk about testaments but that also i i really think that's something we need consensus on i mean it's just a matter of spinning up a test net and those who wants to join can join those who don't don't

Hudson Jameson: oh yeah no it's not i don't mean that we have to have

consensus to spin up a test net we would for robston probably more so than just a random test net would you agree

i'm

James Hancock: something i have a question i have for the group we've talked earlier about how robston is at the point it's worth rest perhaps restarting is that still something that we think about or we still think is the case or am i remembering that

Martin Holst Swende: yeah before we go into that uh yeah i just want to answer hudson's question so the funny thing is if we are two if we were to actually do a proper one rockstar is that i don't think it would cause any

problems because any node fast thinking would start with a header chain and would immediately see like hey what what strange difficulty is this and rejected so it's a lot easier than for example if we did the hard fork with an evm change that's not immediately noticeable when you fast sync um so there's a difference there

oh okay

Hudson Jameson: cool and then um james you were asking everybody about rebooting rob or not rebooting robston but but retiring robston i guess you would say right

yeah

James Hancock: i just i remember conversations

that it might be time to that robson is is it's time to do a different one but i want to make sure i remember that correctly or if that was actually a sentiment from the group like separate of the prague pow stuff just is that something that we're considering

Tim Beiko: so one thing i'll say about robston is that what's nice in a way is it has a larger state um and i think for uh at least for 1559 it's one thing we were considering maybe either forking it like even if it's not the real robson but i think there's value in having a

network with a fairly large state that we can try things on but uh yeah that's kind of the only uh the only point about it

Martin Holst Swende: yeah i must admit i don't uh i haven't paid attention to robson does anyone know how much is actually

happening robson

Hudson Jameson: i see a good amount of dapps testing on robston i have to give roxton test ether to people on a monthly basis

Vitalik Buterin: i forget was that was zk game on robson or on

gurley robston

Hudson Jameson: i believe yeah actually i'm positive it was roxton because i offered to give them some test net eth and they actually are miners on there um

just fyi i just found that interesting that might be a better discussion for next time about retiring robston and that can be at the same time we're discussing a possible place for um a prog pow implementation on a test net regardless of which test net if that's where consensus lies um which it sounds like there are some people in favor of that which

test that is reddit using uh reddit

Hudson Jameson: oh that's a good question do we know

uh it's wrinkly okay

Péter Szilágyi: at least the original when they originally post

started experimenting it was wrinkly i don't know if they switched since then

Hudson Jameson: yeah i mean it is a test net so if we decide to take it down people would just adjust but yeah yeah i think in terms of the reddit one i think we should maybe like get through that competition before we nuke whatever they're using

well wrinkly

Péter Szilágyi: we don't want to do so and and regarding robston um i don't think it's uh it's correct to say want to nuke it in my opinion what what we can do is start a new chain and just ask people to start using that but we can't really stop anyone from using the old one and i don't think it's

it's nice to just uh delete support for the old one so i think if there's an alternative one that clients agree on people will switch fairly fast because it's just

lighter okay

Hudson Jameson: that sounds good um let me see real quick i'm gonna go ahead and lock the meeting because someone came in to try to spam it okay it's been locked okay so um next up so okay basically just to finish this so we have the notes correct um in two weeks we're going to talk

about the possibility of launching prog pow on a test net of some kind and and coordinator in line with the compromise bins compromise that we've talked about before and with that is there anything else

Greg Colvin: i'd like to hear from exit before i have to run

Hudson Jameson: oh yeah that's the next item i was meaning on the on the agenda item one sorry i should have been more clear agenda item two is the ewasm team's finding on evm384 um axic if you could just go over that real quick and see if anyone has comments

Alex Vlasov: yeah so some of you may remember a few

probably end of may is um when we presented this idea initially with some some first findings and this is the follow-up to that um it is much more clear about what we have done and what could be possible with evm trade for now the document is quite long and it starts with a lengthy history section i think it has really nice interesting bits of information so i would suggest for anyone who has the time to actually read that part but it also shows some of the motivation why we be considered doing this in the first place and some of those motivations mean um some prior experiments which showed that it may be

possible to actually implement some of these things we have a spree compiles on top of the evm successfully um and then we developed into the the actual goal we are trying to achieve is to support um some operations of bls 12 um 381 which which is the curve used by um e2 and also wanted by a bunch of zero knowledge protocols so what we're trying to achieve here is to to support and and propose an alternative to the eip 1962 and the ip2537 now if you read this document it might be confusing because we start with web

assembly first the main reason we have this web assembly bit in here is that there's no implementation of bls 12 on evm edo so there's no way to benchmark and and you know initially confirmed that this experiment would be useful so what we did first is we took a web assembly implementation of this curve and more specifically the pairing operation and we benchmarked that as it is in a wasm interpreter and compared it to native at this speed it was 100x lower um and the next thing i mean this is obviously not useful for anything so next thing

was to find benchmark and find the profile the the swasm execution find the bottlenecks themselves and after having identified those bottlenecks we added host functions to webassembly which you could think about as pre-compiled um and actually just three host functions here a montgomery multiplication and and then addition and subtraction host functions and with those in place we were able to get to 2x slowdown compared to native and this was only used this web assembly part was only used to get give us an initial indication that test direction

is useful um the rest of the proposal doesn't depend on webassembly at all don't be confused by that and now with evm384 we don't have a final proposal here but we explain at length what the problems are and what potential solutions are there for introducing these three functions i mentioned so of course with pls 12 you need to have these operations on 384 over at 381 bit numbers and given the evm is 356 bit we cannot just use a stack item to represent these numbers in the computation

we could use two stack items we could put them into memory etc so we describe all these different options and we choose one option to implement um and we describe all these different options what what we ended up doing and we also have links to implementation in evm1 and solidity so it can be compiled now the next actually interesting part here is what we call the synthetic loop is that we haven't actually implemented implemented the pairing operation in evm using this evm 384 instructions uh rather we have created an

approximation uh to uh a two-point pairing but two pairings and this is what we call the synthetic loop there in the appendix that the description what have we arrived at the synthetic loop um and the benchmark showed that the synthetic loop is is uh reasonably approximating the pairing um but it is a tiny bit slower so we use that adjustment factor in the the final comparison um so the next part then explains that the three different versions of uh of these even 384 instructions um how the speed evolved across those three different versions

um those were the only optimizations we ever did so the synthetic loop was implemented on the evm written and written in yule which is a language developed by the solidity team and we haven't done really any optimizations on that implementation we only use the default optimizer settings of the compiler and haven't really spent any more time on it we did however optimize the these new instructions uh we did two different optimizations and by those we were able to cut the execution time by half um and the end result was that where we stand right now is compared to rust compared to native um

we are at the 3x slowdown um and in the conclusion that you can read you know what we think this means i will try to summarize it that tiny bit there's a lot of space remaining for optimizations first of all this yule implementation of the synthetic loop is definitely not optimal yule has an issue with optimizing stack access so it does have a lot of overhead regarding that there is one other language more like an assembler for evm called huff which has been previously used successfully to to write really optimized code and we

think if a pairing operation or even a synthetic loop would be implemented using half we definitely would get a large speed up and then there's also other options to to improve the these specific instructions themselves i've listed those well we have listed those in the conclusion and regarding the next steps [Music] the the best would be to have three operations from the eip25 eip2537 the pairing and the two multi-exponentiations implemented using these instructions

because that would allow us to actually find and the the best design for this evm trade for instructions and our hunch is that we would we should definitely be able to to beat the wasm numbers which is a 2x slowdown but i think with optimizations we could even get closer uh to native than what you have seen with with this was an experiment um and what that would mean is uh that there is a good potential that using these three instructions we could actually support the entire feature set of the bls 12

curve and we wouldn't need those pre-compiles and include introducing each of those features separately um and last thing to note is that it would be possible to also support another curve the bls felt 377 and potentially other things which would require operations on on 284 bit numbers um yeah i think that's that's a summary i'm not sure if there are any questions um yeah i'm curious do you think it will be possible to reach a performance which is uh like maybe 20 to 30 percent uh just only 20 30 percent slower than

native one because it's already an expensive operation and being four times more expensive is maybe just a killing

Alex Beregszaszi: yeah i don't know whether you could reach 20 percent um i think you definitely could reach um just twice as low that that definitely would be in reach with uh i would say not too much effort um but i'm sure with enough effort put into it um you could you could get really close

Danny Ryan: so you answered one of my questions which was 384 seems like a pretty specific

uh instruction set and and if there's anything else that would be like worthwhile to use these more low-level operations which you said there are other curves um and then is one of the primary reasons for investigating this the reduction in consensus complexity is that is that a driving factor here

Alex Beregszaszi: um yeah and yes as we have seen it it's been quite a long process trying to introduce a large set of

pre-compiles

Danny Ryan: right and so this maybe also serves as a road map for how we might a framework for how we might view um

introducing crypto primitives in the future looking at more

little low-level operations

Alex Beregszaszi: um yeah exactly we actually give an example um that you could i mean exactly what you said you could you could use this as a template for any any future work another interesting tidbit is um that with any pre-compile we introduce whatever algorithm that pre-compile is implementing and whatever optimizations that precompile has for the curves and that is most likely locked down at the time of the introduction of the pre-compiled um and maybe in many cases it's not possible to apply any any improvements unless there's a consensus to do so if you only have these primitives or

primitives like this then there's there's no need to have consensus in applying any any further optimizations on the curves it can be done on the evm

Alex Vlasov: uh i would highly doubt that it's the case for at least simple curl curvatic and pairings but maybe for other ones like it would maybe affect the fact that if uh ietf draft changes or maybe mapping of the point uh into the curve then yes it would be easy to update as just a solidity code or just low level assembly but basic arithmetics which is largely

used for pairing some multiplications and additions if there is some updates here and if this is a recent update an algorithm and if augustine is valid answers should always be consistent

yeah

Martin Holst Swende: um so my five cents uh i think this is totally in the right direction because having these really large really complex pre-compiles um which also has this slightly quirky call semantics where you can call them aesthetic calls and

delegate calls or call codes and there can be errors of various types i just think it has to resist the complexity um so we've been doing some fasting the last couple of weeks uh mainly with guest versus nethermind uh found two two consensus issues regarding the bls pre-compiled implementation not in the actual math but in the basically called semantics um so i'm a lot more positive towards adding this small

primitive system yeah

Vitalik Buterin: and just uh i guess i'm a matter of seeing like just how

efficient we can make the assembler primitives be like if we can't get close to any of the native efficiency and then we could definitely get away with just not having any more pre-compiles in the future

Hudson Jameson: and then i think greg do you have something

Greg Colvin: um yeah i was looking uh way back we've got the a b and c in the bm 384 section um and here we've gone with you know just 384 bit numbers in memory uh as opposed to using two stack items which would let you do i guess up to 512-bit arithmetic and the main issue there was

just stack pressure and a separate option to talk about is the stack is just very small compared to the size of the caches on current ships so making a bigger stack could remove stack pressure as a design problem

okay

Hudson Jameson: um i think if we can move this to the ethereum magician's form if you go in the agenda and click on the agenda item you can see the magician's form that's linked um at i think it's also linked in the actual evm 384 post but it's also in the agenda under axics comment um do you have

anything final to say

alex axe

Alex Beregszaszi: um yeah yeah just to close this off um it would be really nice if whoever is interested in exploring this further and and has experience with implementing bls 12 or any other curve operations it would be it would be really nice to work together um and he would be interested in helping optimize the code and maybe come up with optimizations on on the instruction side um but we would be looking forward to someone who who is capable of of implementing the actual logic on the evm itself

Greg Colvin: this is really nice act so uh thanks for

this now i've i finished moving across the country in the middle of a pandemic so i can try to spare some more cycles on this thanks

James Hancock: um um does this how does this fit in with the subroutines uh eip that you proposed earlier greg

is this it's independent i think yeah i think it's independent looking at this

Hudson Jameson: my question was does this throw eip 2537 out the window for berlin if we were to go with this this would be in its place right yes okay um

is this something we should this is something we should probably decide on pretty soon then like by next meeting at the latest if not just offline and chat um because we would need to update a lot of different sources that are saying we're going with 2537 and then also start work on implementing this if we're going to put this into berlin am i am i correct there or

Alex Vlasov: i think the biggest issue would be if performance which is kind of acceptable for this kind of operations uh will be reachable for um using this approach or not like because four times is is very expensive

i mean verification of one snark would take one quarter of the block i think at least

well

Alex Beregszaszi: it's more like three times not four times

Alex Vlasov: well i mean it's still in order of uh like right now verification of blonde proof on the completely different curve is uh half a million gas plus minus some optimizations uh with pls which is heavy curve and with this penalty on top it would be factor of two just because the curve is heavier and another factor of three so it will be 3 million per snark which is kind of totally i would say totally unacceptable for

this kind of applications and this wouldn't be a solution

Martin Holst Swende: right so just uh to add to that i i don't think we should consider performance in those kinds of absolutes right now we're at the point where state access is too cheap i'm gonna have to rebalance it which is going to mean that computation will from where we are at now we will favor computational intensive over

i o intensive operations so

Alex Vlasov: yeah uh i mean there was this questions earlier like how much time is spent uh by the miner to actually evaluate all the transactions in the block and assemble it um and if it's done this way it will just like it will increase this time uh in some edge cases if block is maybe and like your block limit is changed and if block is over filled with one kind of transaction and not another so it's still questionable i i would even say that uh any uh miner who would want to increase his profit he would just swap

all the sequence of operations which is basically the paying check implemented with this set of up codes by some huge function which will just read the memory and do it natively and just give the same result

Hudson Jameson: um would this be a good time wait martin would that would what you just said go into vitalik's idea that he posted earlier in the chat is that what you're talking about

for

Martin Holst Swende: yeah that was what i referred to

yeah okay

Hudson Jameson: in that case let's just go into that topic because it's very related to the rest of this um and vitalik if you could go over your idea and then we'll do yolo after that

Vitalik Buterin: yeah so basically the thing that i'm proposing is just to do a kind of fairly quick and dirty short-term gas cost changes to increase the gas costs of opcodes that touch storage so this includes slo this includes the entire est ext family this um includes the entire call family with an exception for pre-compiles and for um contracts and slots that have already been touched one act when accessing this transaction and the idea would be that the cost of those opcodes could be bumped up to some number that's made maybe between 2000 and 3 000 and the reason

why i think um this this is valuable and there's two reasons so one of them is it's a pragmatic short um short-term security improvements to the chain uh so there have been especially with increased gas limits there have been a lot of concerns around a kind of dos attack transactions that basically try to make blocks take as long as possible to process by uh focusing entirely on storage accessing operations which seems to be the most kind of underpriced thing in that regard um and so just kind of heavily bumping up the gas cost of those operations would decrease that cost by a factor of uh or would decrease the block processing time

by a factor of something like three which should be a kind of very useful corrective for what's um um what's happened since from both the recent gas limit increases and just kind of the passive increase some that that's been happening in the future historically and will happen in the future because of the state size slowly going up so that's the first motivation and the second motivation is that in the long term uh we do want to have bounded uh witness sizes uh including for fully stalish clients and this is something that's useful for example in an eth2 context uh and in the context of uh

being able to have a communities bureau of verify block to be able to expand the multiple shards and so forth and the regenesis roadmap does give like does include a feature for bounding gas costs in the context of partially stateless clients but kind of in addition to that uh bounding with bounding witness sizes for nodes that are completely stateless ends up also being important so basically this would end up serving both of those functions kind of short-term scalability and or short-term security improvement and uh kind of medium term pushing the ecosystem toward more um witness optimization would both be served by this and

that's a

fairly and a simple change consensus-wise all right are there comments on this

Alexey Akhunov: yes i have a selection here i have a kind of this is the the generic kind of thought about all these um so we've tried to do this before the the kind of the bump up the i remember the latest ap was 1884 right when we bumped up the price of your operations um so the question is that since then the the blood gas limit came up as well so i think uh not probably as so it used to be eight million when this eip was introduced now it's 12 million okay so it's 50

increase and the bump was three times so do you expect or does anybody expect that simply not well that's basically after this bump we simply going to have just a lot much larger gas block limit

Vitalik Buterin: it's it's definitely not my own intention to push for to push for much higher gas limits um or like or you well actually it'll be even clearer like i personally would oppose mining mining pools trying to increase the gasoline to a number that's even higher than that than 12 and a half million the goal of this is um to kind of compensate for things that we've already had and at the same time recognize that even the 800 the 800 level and the 700

level that we chose second of years before that would probably still a little bit too low

Danny Ryan: you know the time like time and estimated time processing like worst case dos block right now

Vitalik Buterin: my understanding is that it's in something like 30 seconds and this my my proposed numbers would push it down to about 10.

right

Alex Vlasov: um i don't know if someone has a statistics on like how many calls on average does one transaction make but i assume taking until accounts are limited um

contract size and current approach to modularity with a lot of delegate goals would it potentially impose a burden on like a modern style of making smart contracts that will make them like more expensive especially something uh fancy one like uh the exeggutors or just texas themselves there is some statistics like this

Vitalik Buterin: uh yeah so we actually do have a way of estimating this indirectly and the way that we do that is that we've i can we we've done numbers on estimating witness sizes

for the purpose of one point x stuff and so we've get we've gotten witness sizes of i think is somewhere around a 600 kilo 600 kilobytes or so and so from those numbers we know that the number of these of these calls is going to be such that i think as um i reca as i recall it would be somewhere uh somewhere in the end of 10 to 20 10 and 20 range in terms of how much more expensive average average things would get but we could definitely estimate this more precisely

yeah

Alex Vlasov: kind of related question uh uh but it's more from a modern hardware

perspective with like accessing uh like looking at the location uh on the disk would still it would have like high latency to find and start really but then you would get a huge bunch of data uh potentially for free um maybe would it be reasonable to maybe increase the contract size limit a little kind of

compensated

Vitalik Buterin: um i mean i'd definitely be happy to like i would personally definitely be okay with that um and then well the thing that we want

to keep in mind also in the long run is that in the long run we would probably wants to move toward a regime where contract contract code has either a much larger limit or no limit because we have code localization and we would be charging for chunk so and again and in that context like basically having your code be in one contract versus having your code be again or split among a bunch of a bunch of different addresses would be would be almost equivalent potentially but i would definitely seek in of personally be okay with a with a slight increase to max contract size

and especially if it helps alleviate the effects of developers

um okay uh barton

Hudson Jameson: did you have something no no uh i think you're muted martin if you're talking

Martin Holst Swende: oh yeah i didn't know it was my turn so i just i mean this proposed change i'm all for it and it's technically very simple and i guess the big problem is that um and this is something the community should know is i mean it is going to break stuff 1884 broke some stuff most of it could be fixed

if we bump it from 800 to 2000 some things will be irrevocably broken and yeah it's kind of like we have to just decide yes this is worth it for the future of ethereum and you know um i just want to want to hear panorama's thoughts on that um i think it's worth it

so in terms of the classes of things that would break like the main the biggest one is um like 2 300 gas calls that are that do a storage lookup followed by a log right

do we know like i also know that there is yeah i would say so that one and also law isn't it things which uh so i'll link to the security considerations for making for um yeah it's a lot of storage shook ups and then those do something on 2300 gas right because like 2 300

Vitalik Buterin: gas things can't cause state changes so that would not end up like causing coins to get lost

Martin Holst Swende: no right but it can if you have a wallet which accepts

either

Hudson Jameson: so in my opinion what we would need is a

write-up on this similar to the really excellent one that martin did for 1884 that would outline the reasoning and what would break as to the primary things of the write-up um and then also an eip would need to be written to i guess propose this in the first place um so vitalik did you want to do that

yeah and i'm i'm definitely happy to talk to martin and anyone else who wants to reach out and start coordinating that

Hudson Jameson: yeah because i know it's going to get really sticky when we say things are going to break because it was already a it was already a kind of thing to educate the public about whenever 1884

happened so getting the getting all the information on document before actually telling everyone this might be a thing would probably be better i say that as only 50 people watch this so live so i'm guessing not many people are going to figure it out well i guess tim has his tweets but yeah either way let's get it on paper and uh go from there sounds good um anybody else have any comments on that

James Hancock: i think there was a proposal floating around for increasing the contract size limit is that did someone remember who or if that was a thing

Vitalik Buterin: so that

that definitely is a thing that's been floating around in the context of happening simultaneously with codemoralization and i'm not i'm not aware of it in in other contexts though

okay i must be remembering the ethonx stateless theory of conversation

Vitalik Buterin: yeah it's like the thing with code mercalization right is that if we switch to if code is moralized and if we charge per chunk and if we load witnesses by chunk then like there would be like code would basically functionally be another kind of storage and there were being basically no harms from a contract storage even going all the way up to like a gigabyte if we were to potentially allow um creating a contract over the course of many transactions

so that's a thing

Alexey Akhunov: yeah and also the the the reason why you we kind of it would be harder to do it right now is because you would need to have a very weird pricing for the call for like for the call for example because you you know you would not be able to predict pretty much like what how much the call is going to cost but if you do it in the context of witnesses that the witnesses already will be charging enough for the um for the for the depending on how much code you're actually using and the same kind of goes into the um these the proposal that has just been discussed for raising the cost of the um the the certain operations is of course

if you look in the future that you know if we or had the something like stateless ethereum or genesis already that wouldn't it wouldn't have been required uh it's we only do it is because we can't do the other things quick enough

James Hancock: thank you that's really helpful

okay

Hudson Jameson: um anybody else on that before we move on

okay

Hudson Jameson: um from there let's go to what was item three and now item four yellow or andor yolo v2 testnet and berlin state test update and just

berlin update in general i'll pass this to james to do that one

James Hancock: thanks edson the what is the status of everyone getting on yolo if i remember correctly that was a goal of last uh last call was for remaining clients to be able to sync so we

could fuzz

Martin Holst Swende: i'm not sure about that was it

Hudson Jameson: i'm not sure i don't know if i remember being the that being the goal i remember we were going to go toward that

James Hancock: i don't know if we said by next meeting or did we say we're going to discuss it for the next meeting

Hudson Jameson: that could have

been it

yeah i think so i i requested that clients would add yolo v2 or berlin for definitions for state tests so they could be fast i don't recall if we mentioned anything about actually running a new generation the next generation i mean

James Hancock: we talked about it but i'm not sure if we decided nothing we talked about we didn't decide about doing a new one but i do remember i think was it is it baisu or someone else maybe that maybe that was about the state tests or not about

it

Hudson Jameson: yeah i'm remembering it now it's it was the state test for yolo or for yolo berlin and to do that for the definitions

um so basically was there anything on that

Martin Holst Swende: yes also pretty the last couple of days we managed to throw bisu into the mix of clients being fast and i think so if i remember correctly marius found two um vulnerabilities but not yeah i don't know if these guys won't mention it anything um i don't think it was bls specific though um i mean specific um but we have done fasting for the beta stuff and for subroutines

yeah another mind gets mostly a little bit of parity but parity also implemented the static holes the pre-compiles are cheaper so it's a bit problematic too fast for that and but it's a lot still finding bugs but it's getting better i guess so i guess the question do we want another pre-burden test net and if so what would be in it

Hudson Jameson: that doesn't sound like a bad idea but tim go ahead

Tim Beiko: i was just gonna say it kind of seems like there's eip or not eip but evm 384 that we were talking about considering uh there's all these gas cost changes um with like the gas cost changes are fairly simple to implement um so would we want those in berlin and then if there's the evm uh proposal does that mean we removed 25 37 um yeah it just seems to me like um there's maybe like some clarity missing about like what we want to do before splitting up the testnet i mean sure we can

but i yeah i'd like to understand what do we want to get out of it if we're if we're doing it

James Hancock: and i don't know from [Music] i'm still kind of up in the air about whether the evm changes or having both or having one replace the other or have one be one further i really would we would need to investigate more i think before making a good decision i just would have been thinking back on the conversation i felt similar to him that that that that change i think we need to

review its effect on berlin or not

Alexey Akhunov: well i would suggest this i mean i know what people are trying to say but they're just not they're just not saying it i think um so i would suggest to do this so we had the yolo with where two aips were basically included which was the bls and the structure well [Music] so what first thing to do is to separate them okay now what i would say is that don't plug them together anymore so now it's step one step two now you've got basically everything separated from each other we decide which are the of the so then

we've got two other eips we're just arriving one about the gas repricing and another one about the well it's not aip yet but the proposal which potentially could supersede bls okay so sort them in the order of priorities which one is the most priority one and so forth and then uh it looks like and then look at the levels of readiness so it looks to me like if we feel that the um the subroutines for example are kind of didn't have any issues so far uh then i would suggest to repackage the the berlin uh with the subroutines plus the gas changes

and then leave the other two uh for the for the further sort of analysis uh because i think we need we need a bit more time to to do work on the 384 evm384 so why don't we just do that

James Hancock: and i think the other one to consider is the x-mod gas changes that we've discussed a couple of times i'm forgetting the number of the eipd off the top of my head

so when you're saying the gas changes with what changes are

Alexey Akhunov: you you know the the the thing that just the vitality just suggested you know the making things more expensive i think because i said i should have seen that out of all everything that we're

discussing this is probably the most urgent one um like if you're completely honest right

yeah yeah i tried to uh try to ship it as penalties before and then as karma and all of that because yes yeah whatever um so yeah this is

Alexey Akhunov: the most urgent one um because it addresses the the issues that are already could be reality um and then sort of james what did you say the other one was

uh there was the the eip that changed the gas prices

Alexey Akhunov: has it been tested already like is there any so what is the i mean

we could sort of we could sort of try to include it it depends on whether we want later on just try to split them up again or not so it's just like it's it's a sort of this game of uh if you bundle them up too early then you might need to it's like a did you put the baggage in the airplane and then somebody doesn't arrive or something like that you have to get kind of unload the baggage before the airplane airplane leaves in this this is kind of the situation like are you sure so if you don't mind doing that so how many iterations of the test night you want to do if you don't mind doing that let's just package up the ones that we think they are pretty much uh ready or urgent or whatever

and just go on this basis because they shouldn't be this kind of guilt about because this is what i'm kind of sensing in this like oh but what about this one so there shouldn't be like any deal about okay we leave this one behind and because the other thing which is more urgent just came up or something like that

James Hancock: uh that certainly makes sense to me and i i was listing it as that i think is in the list of ones that are ready enough to be considered

yeah

Alex Vlasov: if i made here like uh making the priorities is great but for like um from what i see from all their effort which is

put to five implementations of pls uh it looks kind of ready for me because there is no problem with arithmetics and the hardest part of the implementation there was also no problem with yellow v1 for exactly this part there was only a problem with integration of this of these libraries um so i would consider is ready uh i don't believe that making people didn't pay close attention to the spec house

Martin Holst Swende: but i mean it it's in the math or if it's an integration

Alex Vlasov: well i mean if it's in a must you would want someone outside to fix this error but if it's internal in a client and a known

code base it's what was discussed earlier what would happen if something happens with this consensus issue then someone would have to fix it and this would be someone who uh has an experience with writing the code like this but as it happens there is no problem with the hard part there is a problem with the part which is uh closer to the people who contribute to the client code base every day and not make large mass packages um right it's not a problem

Martin Holst Swende: because it's not your problem

Alex Vlasov: no i mean uh the first uh opposition for a breakable which is uh like one of the positions for

breaking ball which is hard which involves some cryptographic variations was what happens if something happens with consensus issue like who would be responsible to fixing this problem and well i mean i didn't have any um opposition to take this responsibility and try to help if it's necessary uh like i don't know the process but i'm up for it uh and now i see that this is the same risk and as integrating as any other would it be the modex or static call and i say just from not from the perspective it was

a long time while it's all kind of done on inside but people are um like with berlin being more and more and more postponed uh so i'm more and more and more as a priorities uh but i just don't buy sets uh like uh op code for 384 arithmetic given its current state will ever reach the performance which would be close to native which was the whole reason to have the uh pre-compiled the first place to have it in a reasonable price in this case people will most likely stick with the bn curve which is kind of unsafe

and is limited in many aspects

Hudson Jameson: how long would it take to figure out um the performance metrics that you're requesting uh i guess axa can answer that one maybe

Alex Vlasov: oh yeah i'm not uh especially in uh evm and it's internals sure how you would be able to marry those together but from what i see here it's not just a problem to get the fast arithmetics in which is i would say most likely can be done with kind of acceptable overhead the problem is how you write the pairing function which which uh exec has described length there is no

benchmark for pairing because it's difficult to write i don't know how difficult it is but i would say it's insanely difficult taking these accounts limited capabilities so the benchmark there is synthetic it's just a number of operations it doesn't take into account any any control flow and logic and difficulties which you would just encounter trying to glue it all together so i would say it's a huge effort it's great effort but it wouldn't be completed in a reasonable time frame i would say half a year at least and that it gets close to the uh like well let's increase the cost of uh disk access operations and decrease the

cost of computations and let's see what happens after this uh and we will become in a completely different state of things in half a year when it may be may will be radio maybe it will be set it will be in a state that well it's a great effort but unfortunately the performance will never hit the goal

Hudson Jameson: uh what would you say would be the implementation time would it be something like half a year

and yeah i just want to reflect the the synthetic benchmark that there's no control flow in it there actually is um so it's not just just running some of those operations that there is

uh control control flow in it uh of course it doesn't hundred percent match uh the real implementation because if it would then we would have real implementation um but it's it's more than just crunching the same operations uh over and over again no i

Alex Vlasov: i don't say this is just doing uh on the same input data for six thousand and seven hundred multiplication no i mean there are two problems here one is the performance of the basic operations which uh uh i mean can be solved more or less uh i hope can be solved more or less with uh various streaks starting from assembly uh for the mass itself and maybe doing something clever with uh with either the stack on memory uh

management uh just but the second part which i see is more is much more difficult is what you described trying to implement to actually implement all this uh pre-compiled using one of the languages as a eulog and i would say this would be much larger problem it's very non-standard and not many people who usually write this kind of stuff uh they work with it i would be glad to help but uh i just have all the doubts that it will ever hit the performance which is even two times slower than their uh than the native one

Alex Beregszaszi: so i'm actually quite optimistic

uh on the speed because i know that we have done a really bad job at optimizing any of this and we chose yule as an implementation well as a language for implementation because it was the easiest to deal with but it's just too high level to to write this in an optimized way at least too high level today and half is half has been used to for implementing easy mole on bn128 with quite an amazing performance and half looks more like a a mix between assembly and c plus templates um so i would say that is quite close to

what people optimizing curve operations in in c or go with assembly would do so i don't think it would look so alien to to anyone who has done such optimization before so i think it it wouldn't take you know years to accomplish that um i cannot give like a 100 accurate uh idea how long this would take um but i think if there are at least two different teams working in two different aspects then we can get and the two different aspects would be

one one team or person implementing just a pairing operation for example in half using these ops another team which likely could be the wasm team is optimizing the the the op code in the evm um i think this process shouldn't take longer than if you have the right people this shouldn't take longer than um one or two months and this should give us already a good hint whether we can reach you know good performance um of course you can spend infinite amount of time optimizing it but i think just getting a

first confirmation if you have the right people that it doesn't take that long implementing everything is on top of that um but just reaching the decision point i don't think would take five six twelve months

okay yeah

Hudson Jameson: i'll go ahead lexi just to finish it up

Alexey Akhunov: so yeah i just i just want to finish it up basically just uh i'm not going to talk about technical details but in more general i do understand alex's kind of frustration that it looks like there's a lot of work to be been done and so sort of we keep hitting the wall on this stuff and it's it is clearly that we are hitting the wall because uh but it's not because uh there are basically like

people on the other side who don't really want this to happen but simply i think it's because the um we don't actually have so much uh this specific expertise in the in the implementing teams yet maybe we will get that expertise and that's why it takes such a long time to for everybody to sort of get comfortable with this because you know you don't really want to be running the code that you're you don't you're you don't understand or you don't actually kind of sure that it works and this is i so it does take a time and i think but it it gives us uh the good direction where in if we want to do these things better and and quicker we do have to sort of bring this

expertise into the teams and hopefully i mean for example one of the things that could come out of the actual proposed project is that somebody will have to re-implement this again i mean because you know we don't really have a lot of people who could actually implement bls 3081 and i don't know like how many people are actually comfortable with that stuff that's all

so yeah that's basically my yeah by

James Hancock: let's say that we we do as alex saying we move we get to the point where there's a decision we we have some kind of testing and it makes sense and then two months from now we get to a decision point that makes sense but after that point do we have someone who

could write bls pre-compiles into that instruction set well do they exist

it's kind of all together i think what is it meant

Alexey Akhunov: what i want to push back on is basically this sort of idea that we are kind of running the we're basically running like a corporation here is that we have to give like you know we have to say okay in two months time we this should be done we can't do that because we actually we don't know how much how long it's going to take we are running on a very tiny margins in terms of like resources and everything so it has to come into the account that you know things could take longer and

longer and longer and like it is how it is basically

yeah

Martin Holst Swende: uh just a trap stupid question but if we were to do the avm 384 wouldn't that mean that we shove the the large problem uh all the complexities into layer two and we implement some rather rudimentary things in our layer and then we don't actually have to care about whether someone implements the algorithm maybe or c correctly because it's on there too and it's it's not

an rs

Alex Vlasov: what do you mean

for um that

Martin Holst Swende: it would

probably be quicker faster on the platform layer to implement uh the rudimentary stuff the small bits and pieces uh maybe it would take longer for layers for someone to figure out how to efficiently

implement

Alex Vlasov: uh no i mean my doubt here is that this efficiency will never be reached that it's just unreachable for this architecture um okay i mean the performance gap we will still remain even with all the effort which is put in there which will at the end of the day result something's been a factor of two uh far from optimal and you should understand that 1962 is

not even the fastest one it's kind of a safe one uh from from the zoo whole implementations and full-blown optimized versions exist and they have twice the performance i think it's in uh some cases so it's it will be still comparing like uh writing bls 1281 in native code without assembly and acceptable performance uh was not that much of an effort but uh to kind of be just beat this performance and get close to it from what i see and like from all my previous experience experience i would say that for this purpose

it would be necessary to implement all those operations uh all these 384 bits modular operations in assembly plus there would be need to be either some change for stack sizes or some clever tricks to have all the memory uh prefetched maybe something like this and then have an efficient implementation in one of those languages which actually proposes and from this perspective this is enormously different amount of effort which is required to write and which will potentially result in never reaching the points of equal or even twice worth the

performance uh compared to average implementation in negative code not even saying the best implementation the fastest one

okay

Hudson Jameson: well there's only one way to find out which is to evaluate it over the next few weeks it sounds like because there is enough support for that for what axic proposed today that i don't think we should just drop it off before more discussion uh and there is the ethereum magicians thread where people can collaborate and figure out what we're doing there as for the rest of the berlin stuff there were a lot of ideas presented today and we do need to do a better job of i don't know how to explain it like we

keep changing stuff a lot which feels bad but it's not bad in itself because we do need to update our expectations when things come up like the security concerns um but we might need to get on a better cadence of making these decisions so what decisions do we want to make for next meeting or between now and next meeting

so i have a question uh sure it seemed didn't the legacy propose or

Martin Holst Swende: did they actually add to spin up or to define a new um yolo with the italics upcoming gas cost changes and

subroutines

Hudson Jameson: i think he did for once the eip was written right okay yeah and that's a good idea

man

James Hancock: i think we could add the mod x vip to that as well okay unless people have reservations about that

it

Hudson Jameson: sounds good to me

Alex Vlasov: the only question was for uh uh open ethereum uh team which couldn't get the performance library uh in their code base so which stopped from all the previous actions i think

well

James Hancock: it ruled out option there was an

option a and an option b and it ruled out one of those but there still was a proposal for one that had been benchmarked on all the clients an acceptable level at least at least to the point where it could go on at yellow in my opinion um in general i like alexi's plan i'll be transparent that i'm a little worried on the like the the end of being able to do on-chain verification of bls signatures uh to switch gears at this point i'm concerned it would push it much

farther even though the evm and all those things could happen in months the actual implementation of the bls would happen months after that because someone has to figure out how to do the instruction sent to optimize for it and all of those things and that's barring that that it is all things are working as we hope it would um so the there still is value to having the on-chain verification for the eth2 deployment and i'm just wondering out loud if it's if the effort of finishing testing and doing the fuzzing would end up being less than waiting on uh 384

yeah waiting on 384 and then by waiting on the decision for 384 implementation and then someone has to implement after

i said from the

Alexey Akhunov: i said from the beginning that it wasn't a good idea to try to create this dependency anyway and just work on the assumption that it might not happen in time that's okay uh so i don't know like what do we have to be stressing about not completing the bls by the time that phase zero launches i think is it still is anybody stressed about it still

Hudson Jameson: i was but i'm not anymore after your um after you just said that

yeah i

James Hancock: i don't

see it as a stress i i see it as we are very close to having we are closer to having finished the eip for bls

Alexey Akhunov: well it wasn't nice to have i think uh at least so it was never like but nice to have might not happen right

Alex Vlasov: um yeah so it's it's a point that everyone sees this as a kind of requirement from east 2.0 uh like they don't have other options um [Music] maybe you've seen that there is uh like zero more and more obligation player two solutions and isn't arcs in general uh which also depends on

this kind of operations and even more dependent on the performance so this operations but it's just most likely out of attention of

course yeah

James Hancock: i don't want to over focus on the e2 dependency sort of thing it's more of we are pretty far along to be able to have this be shift and there still is value of it shipping so um if we have to if we have to weigh moving it possibly six to nine months versus a few months of finishing testing

Alexey Akhunov: i mean if somebody basically came up to me or to us and said definitely that this is the most nobody actually done that everybody was just saying oh yeah that could be good it could save like it could reduce some risk but nobody actually said came and said this is a requirement and therefore i'm actually assuming that

it's not required

Alex Vlasov: i can say this is a requirement because it's part of the thing i usually do every day uh i mean i can deal with uh with different scenarios whether it exists or not

the reason why

Alexey Akhunov: the reason why it's not a requirement is because the initial like remember that that that day when

justin drake said on reddit that the phase zero will be shipped in 2021 and the same day he changed his mind and it's going to be shipped in 2020 i mean from that even from that i could see that there is no requirement because now it has to be shipped in 2020 regardless of whether i don't know

so i like

James Hancock: whether it's a requirement for eth2 there is still value is there value in the eip in having bls precompile outside of that

oh

Alexey Akhunov: yes there is a value

right so question so i'd

James Hancock: so i want to focus on that that value is close to being executed on regardless of uh it's it's tied to e2 or not

like for getting putting that aside completely and saying that there is value to be had from the bls precompiled being on being there for things like plonk and all of the and and implementations i want to be able to use it i i think that's what i was hearing alex saying that for him it is a necessity not and and he's not referencing anything with

e2

Alex Vlasov: yeah this that's correct uh interpretation i mean yeah so so for me i can deal with different various consequences when and how it's implemented uh but it's just because i have resources and options and plans how to do that other ways

it's uh in general uh as as a core of the like what we do as a company we try to open our tools and uh expertise a little and i understand there are people who would be willing to do something with this uh but they wouldn't have any resources to do it some other ways which are possible workarounds and i don't want to infer like even while i can overcome uh potential problems uh it's not on like there are other applications and not to say that bls is a like de facto standard if and if there would be any cross chain interactions and new various type of signatures and for example witness compression with

polynomial commitments which is kind of discussed on a in a discourse channel it would need a curve which is secure and which has other capabilities like having like being able to commit to much larger polynomial than the current bn curve and it would be a requirement in this case but it's all still kind of insecure and it it needs to be a possibility for people to use it and that people will actually find an application i never proposed it out of the strict requirements that it's for peace 2.0

okay

Hudson Jameson: let's take this to discord because we only have nine

minutes left um but i think this is important that we decide this relatively soon what direction we're going if possible um so axic between now and next meeting what can come what can be brought up as far as better idea performance metrics and stuff is that something reasonable to bring up in the next two weeks

yeah

Alex Beregszaszi: maybe if the document and the results and and the code gets um gets more reviews yeah maybe we could have better idea at the next meeting

okay

Hudson Jameson: and thomas did

you have something to say

Tomasz Stańczak: we are discussing here a big decision whether we deliver ethereum which is slow because it has to be generic and it's general computer we deliver for the for the users of ethereum something faster and i'm like until they understand both approaches i mean i understand why i would like to not introduce precompose because it's it will look very strange in five or ten years when you look back why this can become past or even added but now it makes perfect sense because we just deliver for the users and improve the visibility of the evm for the teams that are building on top

of it and we're just ensuring the community actually gets delivered what they really need and because they're on the bleeding edge they need something fast and because only fast things at the leading edge have any value when you go to the market and this is the question we are asking ourselves now right what do we deliver as

ethereum

Hudson Jameson: good good way to put it okay well we'll have to talk about it more offline uh unfortunately or we can have a whole another meeting dedicated to this decision at some point if we want to do that if someone proposes that to happen um next up we have the raw benchmarks for eip2666

i think that was alex um uh right

Alex Vlasov: yeah i mean i found i got the benchmark results from ultimate your client and assembled them in the table which is now in the pm issue and i've also reposted to the magician spread and post a link to the core devs but preliminary results are uh and i've used this as a kind of ideally should be placed in conjunction or after earth is part partially together with 2046 that's if 2046 is introduced and the call to pre-compiles is reduced to 40 or 100 gas uh depending

on like uh if that would be possible to put some optimizations in peso or not then for example as a result of this uh to be on a safe side it would be necessary to adjust cost of pn additional multiplication and all other free compiles are on the safe side so there is no internal problem with performance and there is no need for compensation for this 700 like reduction of the 700 guests on the call but as a next step it is definitely possible to reduce uh pricing on uh hash functions which are

like two of those separate compiles with sha and rayqumd and on the opcode of keycheck itself also new formulas uh represents the internal strategy of hash functions much better so they actually follows like a internal execution called logic and how it depends on the length of the input so it's all captured in this heap i most likely remove and introduce separately is a proposal for different handling of gas being burned on air it will be separate but i think putin 2046 in berlin is always a simple reprice would be an

additional multiplication would be a great step and later on we can reprice the

rest of the free compiles

Hudson Jameson: anyone have a quick comment okay um the next one up is the um eipip meeting we have come to consensus within the people who attend those meetings of new eip statuses um edson if you want to go over that really quick there's also a link to a hackmd that goes over what each of them mean and we don't have to go through the entire thing but just kind of uh what the goals are and um point people out in the document we came

to

yeah i can go over it quickly uh let me share my screen so these are um how the new statuses would look like i don't think there's an image of the old ones um notable changes are the removal of accepted um so the the trend is um separating the hard-four coordination process from drafting eips itself um so they would be drafted and then the decision to go into mainnet would be separate from the actual repo

um there's an introduction of a review this is so we can get more feedback from reviewers before last call movement from draft to review means the author is finished writing his portion of the draft and is looking for external feedback and then stagnant with withdrawn um the replacements for accident inactive um where stagnant is um over some time has elapsed since the last change and it's automatically moved there or withdrawn uh it's what withdrawn is

it's intentionally removed and there's no intention of moving the eap forward then final means that the spec is frozen that the eap is frozen um these are these statuses will be applicable to every single eap in the

eap repo

Hudson Jameson: um with the exception of living living would only be for those eips that are in um that are specifically like eip1 right

yeah so living is short for living document which means that the document is meant to be updated and never meant to be final

all right

Hudson Jameson: any comments on this okay thanks for the overview edson um we

will be looking to incorporate this and other changes uh into a pr that then we'll go through uh community review next up on the agenda we have ethereum cat herder survey results but i feel like two minutes wouldn't give it justice to really walk through what we found and evaluate that based on the meetings we had in july so would it be okay i think puja was going to present this if we just presented it next meeting and just make it an earlier item

say that one more time i couldn't hear

Pooja Ranjan: i'm good with that

okay perfect

Hudson Jameson: um and then finally

uh we have migrated from the getter to the eth r d discord you can click on that link to get into the ethernet discord um and we have an all-core devs channel in there we also have a section for eth 1.0 that we can add sub channels to um that that is just on request if there's something that is like um maybe even something like these eips we're talking about today with the bls signatures and stuff might need its own room um but if that comes up we can discuss it within the all core devs channel under general under the eth r d discord any questions on that there's also really cool channels about

like account abstraction regenesis 1559 and stuff like that already so it's a it's a really neat place to hang out all the cool kids are there let's get active um the last thing is review previous decisions and action items looks like um there isn't really that many and i think we covered everything because alex blassov went over the benchmarks um uri clarman was going to recheck prices and calculations for eip 2780.

i don't know if yuri's here today or someone who can speak to that and then reach out to the awkward devs chat options and present that next call i yeah we came up with going to the discord um that's all the actions required and i think that's it for this meeting does anyone have anything else before we go okay thanks everybody we're next meeting is september 4th 2020 at 1400 utc everybody have a great weekend cheers

[Music]

[Music] [Music] [Music] so [Music] [Music]

[Applause] [Music] you

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