All Core Devs - Execution #86

Transcript

[Music] [Music] so

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

[Music] so

[Music] so [Music] [Music] so

[Music] [Music] [Music]

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

hey everyone and welcome to the ethereum core developer call number 86 i'm hudson and this call is on friday may 1st 2020. um we're gonna go ahead and jump into this with the berlin eips and then uh and maybe some efi or actually james did you discuss in chat that we aren't gonna really do efi much today it was in the getter i thought you said something like um during the normal efi section we'll be asking client teams for updates right say my they're the beginning of the call has to could we talk about efi or we've

been talking about berlin eips and then now i think it's it's talking about berlini ips in the context of updates from client implementers so that's kind of like the phases that got it okay so we can just take out efi then right uh if yeah well the the initial section of efi we should take out but any eips that want to be brought up as part of efi can still do that great i'm going to remove that link here in a little bit uh but yeah uh james if you don't mind going ahead we'll jump into berlin and then some of the if anyone wants to talk about an efi eip okay so we have eip2315 simple subroutines for the evm and eip2537

bls curve operations there's still an option that the that the eip for delaying for changing the difficulty bomb calculations is possible but it it still needs to have a lot of work done before it's done so we'll we'll do the bls ones first because there's more updates on the two three one five and it's just going around from the clients uh or does anyone have updates on that from the development team i don't see alex on the call so i'll just go down the clients um

baesu do you have any uh updates on that yeah for us it's ready to go the only thing that's missing is the contract addresses uh dano left a comment on on the eep itself but basically as soon as we have the contract addresses it'll be ready from trying to go alphabetically but in my head it's hard to do geth yeah so um as far as i know uh greg opened the pull request way back um i think the eip was slightly changed that we still need to to actually update the ipv because we

haven't really played uh we haven't worked on this yet but yeah i guess in general the team is in favor of the ip so so yeah uh peter actually the old pr that uh also existed once upon a time was 1962. uh no sorry we're talking about subroutines now right yeah it's curves actually that one yeah so this is what we're talking about yeah yeah you haven't been confused there for a while i went out of order and i shouldn't have in retrospect because that's going to be the shorter updates hopefully okay wait so what are we talking about

which one are we talking about now the bls curves so 2537 right uh we have not done an integration i am right now checking out this uh repository from kilik um [Music] and it seems to be written well the integration with geth is more or less done uh it would be nice i mean it's not implemented as as a go ethereum it's more important so someone needs to to adopt a bit and then we need to test it but it it's yeah so we have

quite some some work to do for vls okay great thank you um open ethereum um we have two three one five simple subroutines basically done uh we have an open pull request for it it has been reviewed multiple times so with several corrections now it just needs one final review and a final push to get it merged uh we have a code freeze at the end of this week and 3.0 release after that i believe we will make a final push to include simple subroutines in master bls we have not yet started any implementation for the simple reason

that uh alex presented his black box implementation that he suggested that we could uh include you and use but uh we decided that we need some kind of independent audit and verification before we can actually use it so so we haven't started any work on it yet okay and never mind yeah no change since last time on any of the eips so we'll most likely will be waiting for the first implementation on some tests and then we'll start working on all of this i mean as i mentioned before bls we've prepared that for etm2 so we

have it in subroutines doesn't seem to be particularly difficult to implement so everything feels all right okay uh so moving into two three one five the simple subroutines for the evm there was quite a bit of discussion that's happened on that and so let's have a time boxing session on that and we have time at the end to be able to go back to it i don't know i don't believe alex is alex on the call today i don't think he is but i think um i saw martin greg and a few other people discussing it so i just didn't know if anyone had general uh conversation topics on that

so uh i can i can just give some context uh so before the the suggestion came in uh we had just moved um so tests have been implemented state tests uh passing in both bisu and kaf and then this new proposal came in is pavel bilika and aksak and i think a few more they which addresses two points one point the trivial point being disallowing what we call walking into a subroutine and then the difficult point which is to prevent jumping in into a subroutine and additionally so previously what

could be done with subroutines is you could actually nest subroutines so you you define a subroutine and then you define another and then define another uh which is kind of quirky and odd but with their scheme instead there can only ever be two levels of subroutines and the outermost subroutine is basically the code that you start the execution with and then you can have a subroutine but if there's another beginning sub then that means that the previous subroutine ended and here's a new subroutine and what what this does

basically is is make it so so this places additional constraints on jumping and it means that whenever we jump we not only have to check that the destination is actually code and the destination is actually jumped us but also that the destination is within the same subroutine as we are currently executing on um yeah and and that's obviously less trivial than what we're doing at the moment

it can be solved in a variety of ways one way would be to do a more thorough but probably more memory consuming uh thing before we start executing another would be to do more work during the run time possibly like linear to the sides of the subroutine amount of work a lot of people have expressed some comments on the suggestion most people think it's a good idea and are positive towards it it kind of feels a bit like 615 but 615 asserted that code needs to be valid at deploy time and this does not

require validness yeah so there's no it doesn't require versioning but there's yeah we need to look in also if there is uh if there are existing contracts which would get bitten by this by this uh fact that you cannot jump across subroutine boundaries yeah i i actually have some problems with that just because i did not want a 615 style you know sort of java structured machine

i wanted simply simply a jump mechanism pure mechanism no syntax and i'm not sure this is a bad idea i understand the generating code through the llvm stack is difficult uh we're trying to support these sorts of things but the the current evm philosophy is is completely unstructured flow of control and i didn't necessarily want to change that just provide a more useful flow of control mechanism for the purpose so anyway it's a discussion that's ongoing we're not going to resolve it here

the parts that stand out to me one of them is the evaluate going back into looking at all the contract code is that something what what is the path forward for that or is that something that's determined necessary or we should determine necessary i think that would be good to decide if we can if we can't we can we can move on yeah that obviously needs to be done i forgot to mention one of the motivators for doing it this way and that is making it easier for code marketalization later on um then code could be marked like in terms of subroutines and we would

know that the yeah there will be no jumps across across some routines yeah i support that goal so it's it's an engineering compromise we need to work out just the minimum amount of structure to achieve these goals okay so i'll i'll put a an action item for me to reach out to alexi and make and get feedback on the merklization part um that's part of the stateless ethereum and then i don't think we should do anything with schedule yet or saying it should be or not be in berlin because it i think that's a little

premature to say that i would rather when we know more about scheduling and how long some of this stuff would take uh deal with that and there was the last part clarification on though i mean uh now we have already said that yeah this one is slated for berlin and now there's this proposed change and i would like to go back to this state where we say it's finished when it's finished and then we schedule it rather than pushing forward with the original proposal um

and then you know modifying it in a later form i don't know what what's the consensus on about this so alex just showed up if anyone had directed questions at him to one thing on that i totally agree mark martin and that that it shouldn't affect the schedule it either will be ready or not be ready but i don't think it's what i was meaning to say is i don't think it's ready to it's not fair to say it will be or won't be at this time and so it's not worth determining that until we know more sounds good and what i guess just to clarify what determines the berlin schedule is the speed at which we can do the other bls eip yes and and that means we we potentially

just ship another one eip upgrade potentially okay also before we move on from bls 12 381 curve uh jordy balina is here um i think jordy you had an update from the wasm side of this implementation is that correct well just that's uh i just made a uh a was an implementation of the bls uh corp so if any of the clients wants to use it it's available just contact me it's right there it's a native wasm code and well there is a good benchmarks so i think i'm quite comfortable with the

current gas prices more or less so and it's the the code is quite uh quite stable so it's not it's time very time constant so should not be any problem there but just uh just literally to make you know thank you all right and then uh james was that everything for berlini ips or were we still in discussion about something i was needing to check on something so i wasn't paying full attention uh um we talked a little bit alex i don't know if the about the your the the ongoing discussion for i'm not forgetting the number two three one five but if you had

anything you wanted to add short before we move on this would be good time if you're here alex um yeah sorry for being late i will listen on youtube to the recording um just from my side i really hope that we can include some of those change proposals yeah there was there seems to be general acceptance for al most of most most if not all of them so that's good and i think i think that's all been hudson

okay anybody else have any final stuff that we might have missed or coming in with an update okay next up um is any well is anyone here from 2046 for a reduced gas cost for static calls made to pre-compile there was an update for that i wouldn't want to skip them yeah that's true all right then we're good okay uh timing on berlin um that's already been discussed a second ago right james that that's a contingent on a number of things based on the new process we're doing yep okay uh next up

is eip 1057 a programmatic proof of work prog pow if you're on the agenda go ahead and click the comments because that outlines kind of what uh the new champion greg colvin wants to accomplish um uh on this call for just describing updates and a new champion and just outlining the current status of it it is an accepted status as an eip um just for those who are tuning in and maybe don't know the status of it and um it sounds like i won't speak for greg but it sounds like greg's here for clarification and updates on the on the topic so greg go ahead yeah um i don't have much to say on that except that we're we're going with what

seems to be the common understanding we don't we don't have a well-recorded decision on this but basically ben's ben's compromise proposal has been to have the code ready um have the code on a test net and things ready to go provide a deterrent to 86 for the time being and um we can we can work on a shelling point for when when we take that out of our back pocket it's in the holster we can draw it when we need to if ever we need to and um uh michael is here today and andrea is here today just to report

on where we are at in in the state of the code in the state of the testnet and so i'll just let them speak you want to go first andre or i can kind of go oh go ahead go ahead michael go ahead okay yeah so ultimately i think uh greg echoed that 0.93 baseline that had been tested audited and is currently in most of the clients i think effectively is obe so that's kind of overcome by events so right now we're looking to maybe establish a 0.94 which includes two full

two pull requests which is essentially the kick fix and then addressing the least authority suggestion to mitigate the light eval attack and again this isn't has nothing to do with mainnet this purely right now is just ensuring that i think echoing what the community's looking at of just having it on test having it ready i think it's a good due diligence to ensure that there is um you know a space for this at least for you know in your back pocket and again sets on a test net that way uh the community miners and folks can test it the um mining software that actually gpminers would use

can be tested and then it's just parked um that i think that would then give a better direction of either closing out 10 7 10 57 and then everybody understands that it's sitting on test and then we can kind of you know put a pin in it with regards to trying to push to production and i'll let andre go with if he had any other comments in that well i just wanted to mention that uh the the issues uh uh described by least authority in their uh audit results has been taken into account

for the light evaluation attack that you already mentioned and and i wanted to specify that the kicks issue which emerged after the two audits the hardware audit and the software all that were released [Music] was well not really only a pro a problem of profile but requires a whole lot change in the mining stack i mean you could not exploit the issue if you have not [Music] modified the node accepting modified

headers in after the miner has hatched the solution nevertheless we have taken into account also this problem and the pr to the official if there if the false repository which i posted in the chat right now is final and we have increased the number of light cache item accesses for each dag item from 255 to 56 up to 512 to mitigate the life evaluation attack and the input to the second keck check round has been modified

uh pretty much like in uh it has having the full digest from the first catch pass absorbed in the second one uh the the pr is final uh we are waiting for uh some few comments more uh to to get it definitely merged into uh into the code base nevertheless it's worth to mention that uh another project ravencoin is basically providing us a free test net uh because they are migrating to 094 code base with minor modifications

into their main network on may the 6th they had few a very couple of minor changes in the epoch uh width they have switched from 30k blocks to 7k 500 blocks and they have inserted a few i call vanity constants in the absorbine absorb uh absorb phase of the second ketchup rounds that's it i have nothing else to say right thanks for the technical updates y'all um so i would say that

um what's been suggested as far as keeping prog pow and uh the back pocket isn't something that um that's still you know up for discussion etc no decision will be made today on that um at least that's kind of what the purpose of the person who brought this to the agenda wanted um but uh i guess greg did we cover everything you wanted to cover um and then otherwise i'll open it to comments more generally sure it's just i wanted people to know the status of the project technically uh where we are in the work and i think uh michael and andre have laid that out great uh any general comments on this um

at all yeah i just wanted to briefly comment on this so i appreciate the update greg andrea and michael um and yeah i just wanted to clarify uh gnosis and ethereum's position to it so yeah i think martin previously made very clear what what the position of gnosis is but this doesn't mean that the same position is true for mytherium so i just want to make clear that for open ethereum we will always follow whatever the community wants even if this is not in line with like what gnosis would like to have as a company and yeah so we will always follow basically what the

community consensus is around around those topics and uh regarding proctor i think we probably all agree that there currently is no well there's not really clear community consensus around it and so yeah i i'm happy with the current update from greg and we when you say the gnosis the obvious gnosis um stance if people weren't tuned in before what would that be so yeah so we currently believe that proctor is not needed and uh it yeah it would favor a certain party over another um without the requirement to actually like without any yeah change that would

be necessary right now and yeah so currently knows this is against cockpit okay and you just spoke more or less for the open ethereum position but i wanted to make sure artem if you had any comments as well based on the open ethereum position or if um or if that was enough said um well basically uh before a profile is ever pushed to bayonet we would like to see clear community consensus for it okay any other comments yes i wanted to make a small comment so just to make clear just to be clear it's

a personal comment so i i have no i don't want to represent the guest team here or [Music] i don't know probably there are other opinions in the team maybe martin itself himself has a different opinion so just talking for myself now essentially uh the way i see a proctol is that from a technical perspective there is absolutely no advantage of procbo from a purely technical perspective actually even the opposite it's uh from a verification point of view it it's twice as computational as intensive so blocks will take more time to verify

even if not that significant so this kind of essentially what i want to say is that uh if i as a technical person i'm looking at this whole debate there is absolutely no reason why we anyone would deploy prop power minute uh so the philosophical aspects obviously that's a completely different story and uh and i don't really want to go to that point but um i think there was a proposal previously so um an interesting thing is that robsten is more or less dead or but it's a huge test not so it's uh it's way out i think we should just murder it already and the reason why we never killed robsten was always that

we wanted to have a real test net for a proof of work that's not and i think that if we ever ever ever want to even consider procbow then the only option to keep that consideration in my opinion is to relaunch a proof-of-work test that with brockpow because that way every client can uh essentially if you can sync mainnet ether is already tested i mean we don't need an etch testnet to test your etch implementation because it's if you can sync mainnet it's fine and essentially by having a profile test that that would allow us

to have uh essentially for clients to verify that they can indeed create blocks they can indeed verify them and another thing that uh essentially having a profile test that is maybe also advantageous in that if there are asics which we probably know they are uh it's kind of super so you cannot use an asic to just do massive reorgs on the test net so that's i'm not sure why would do you do that but anyway so all in all and my my personal position is that i really don't see us deploying on main at any time soon because well our goal is to keep ethereum in one

piece and uh whether i personally like that they are a600 network versus gpus that doesn't really matter as long as the network is so for me it's more important to keep the network in one piece than to keep the network as gpu or asic so the only only reason why i kind of support uh going ahead with prop out not on mainnet but rather on the testnet is specifically to have this kind of deterrent thing so that we have something that is tested that is ready so that if uh so essentially the reason why people were against asics is that if let's suppose a single party gets too

big of a hold over the network then they can do arbitrary new yorks and yeah that's a legitimate issue i i don't think people would do that because the cost would be enormous but let's suppose it's a legitimate issue but if we have proctor ready to go then in theory we can fork over to a proctor network at any point in time yes it will be painful i understand that it won't be nice it will be nasty etc but we could do it at any point in time and i'm not sure there is a there is a reason to switch over until there's actually somebody abusing ethios okay thanks for the comment my personal

opinion sure just a very very short comment uh i'm not not talking about any decision of uh taking pro power into account uh or not uh i i just i wanted only to underline that uh the so called the light evaluation attack which uh the least authority out it uh brought to light is applicable to it hush also and uh so the increase in uh verification time from it hash to prop file 093 is only 25 26 on my personal environment

with the light verification attack mitigation which applies old also to eat hash the light the light verification timings for nodes and clients and so on doubles from in my environment from four milliseconds to almost eight milliseconds i just wanted to add that technical point sure and actually this brings up a good point where is the best place to go for progpow discussion in the latest um updates technical or otherwise well i'd invite you to join uh the if the if the false repository if you

want to add comment to the pr or the guitar power okay um the other thing oh i want to mention when people are saying ben's compromise that's actually bendy friends bendy francisco's compromise that was referenced back in when did we even have that meeting marches felt like five months so i don't know when the meeting was but it was months ago and um that was the prague based meeting that he proposed that we keep progpow quote in our back pocket so that we can have it as a deterrent for asics

if it becomes to if it comes to a point where that is a legitimate concern or an immediate concern so that is the ben de francisco compromise we won't get into today if that's what we want to do but i do encourage everyone to get a little more involved in the chat that's a personal recommendation when it comes to the philosophical decisions behind this because i do think in order to figure out what the accepted eip means for prague pal i'd love it if we could get to a point where uh we have a determination on that and if we have a you know clear-cut idea of what decision was made

instead of kind of this unsuredness based on rough notes we've had in the past that were incorrect or um streams that um you know detail different people's opinions but not necessarily entire clients opinions for how to move the eip forward status wise so that's my personal take on it and are there any final comments on this i'll make one mention um so there is an active other crypto that is spinning a version of this which is essentially 094 that can be observed um on some of the statuses now it was forked from

bitcoin so it wasn't it's not a direct etach clone but it is using the baseline plus the fixes so it's just from an observation standpoint we can keep track of that and then see how you know performance and other other testing additionally a lot of the mining software that supports frog pow was updated to um ticket you know to allow the participation both on both amd and nvidia so um there is that that point there out there so we can check and then i posted in chat um that i'd work a strategy on getting that proctest net set up all right thanks michael and thanks puja for putting the link to ben's

uh pre-proposal or proposal i suppose that he posted in ethereum magicians uh any any other final comments before we move on to the next stuff i've been following along on some discussion about different ways that we could talk about or or decide on what goes into forks and and all of that and i've been really interested in following that discussion on twitter and hope to have to hear more feedback on that i'd also just like to say that i wouldn't be comfortable um moving progpow to mainnet without community consensus that it's a that it's the right thing to do just to have that be clear for myself as a my personal stance on

that okay great anybody else all right so next up we have eip 2565 repricing of the eip 198 mod exp pre-compile i know open ethereum has been working a little bit on benchmarking and communicating some with the testing team if you are in the agenda there's a comment that's hyperlinked that you can click on uh so who from open ethereum would like to discuss that hey hudson this is kelly um actually we performed the the benchmarking so i can speak to that oh wonderful go ahead all right fantastic uh yeah so just as a quick reminder for folks um eip2565 is to reduce the the

cost of this mod x pre-compile and we came in a couple weeks ago after running some benchmarks on guest and we found that that geth was sort of dramatically overpriced about 10 to 20 x versus uh other pre-compiles and we outlined sort of three ways to uh to move forward on reducing that cost the simple was a uh or the first was a simple parameter change that would reduce the cost uh the second uh was to you know sort of modify the gas for pricing formula to better represent the actual complexity of the modex precompile and then the third would also be you know seek further improvements on gas by actually sort of ripping out the underlying library and doing something more performant and at the time

uh we had recommended option one which was just make this very simple parameter change which would reduce the the cost of the operation sort of across the board um during that conversation uh martin brought up uh i believe is martin that um we had benchmarked death only and he had said you know from his recollection parody was was quite a bit slower uh so i'm i'm just here to sort of uh sort of report out the results on our benchmarking of parity and talk about next steps um so we did go ahead and benchmark parity uh this is the the speed of the precompile across the different test vectors uh using the current sort of crate and version of of this precompile that parity is using uh and sort of low and behold our

findings are that you know martin was absolutely correct a parody is on average you know about two and a half to six x slower than the guest implementation and so you know unfortunately if we were to just go with the sort of simple pricing formula changes as recommended last time um some of the the parity operations would would be sort of underpriced from a gas perspective um so unfortunately there's a few of these that you know take quite a bit of time with the current parity library and so they're like under you know 15 or 20 million gas per second um so in terms of path forward you know we sort of have two to pass forward now so unfortunately we can't do just this simple parameter change given the current

library that parity has um so we have two options one is we can uh seek to sort of replace that underlying library and that's something that hopefully will come back next week with um some benchmarks so we are looking at more efficient uh pre-compiles um and libraries that could be used for open ethereum and then the other is to uh modify the gas pricing formula as we had recommended last time uh and so just to take a quick look at that you know if we stick with the you know some slight changes uh to the parity implementation which is basically just a version bump of the crate and implement the new pricing formula that we specified in the eip um we are able to ensure that sort of like none of the operations are are underpriced for parody so

the long and short is basically previously we had recommended changing a simple parameter unfortunately because the parity library or the open ethereum implementation of this precompile is not very efficient that's not going to be suitable there's too big of a gap between guess and parity and so what we're recommending uh currently is that we we go ahead and change the pricing formula um and that way you know we can ensure that we get this you know on average about a six to seven x reduction in this pre-compile we get more accurate pricing of the pre-compile given different inputs and we show that there's not um any under pricing on the parity side so that is the the current recommendation and the the eip can be updated for that um we would like to explore if we can stick with the simple pricing change and

just improve the the open ethereum implementation uh and so i guess you know maybe that's that's the update and the question that i have maybe for the open ethereum team um or any representatives you know if we do find a more efficient uh library to use behind this precompiled is that something that um they're open to accepting you know like sort of a pull request for um or would they prefer to stick with you know sort of this existing library that they have and and go with just the updated pricing formula um did you test against numbers 0.1 or 0.2 library uh we checked uh we actually did it across all of them so we checked against the the 1.4.4 which is currently what's there we did bump the crate

we saw that it got about 25 better uh when we we did the 0.2.6 uh crate for that's underneath this precompile and we also even tried a new uh modular exponentiation um function that's in that crate already that was added and we got some further improvements there um but even with all of these improvements to the you know sort of underlying library and selecting the right functions we're still two to three x slower than than geth um so if we do want to make you know open ethereum as performative guess we're probably gonna need to look at some other big numb library like um gmp or something to that that effect so it's it will be you know and that's

why i guess we want to get some feedback whether we'd prefer to just sort of change the pricing formula and maybe not get the full gas price reduction that we could get by matching the performance of geth or if we do want to you know sort of try and improve the implementation of that pre-compile well i guess we should try all improvements available and only if we still don't match gap here then only then we should discuss the pricing formula change that's my opinion like if you have if you have any particular improvements in mind we're always welcome to hop on our discord github and hopefully we can fix this okay fantastic yeah so that sounds like

a great next step so i mean um you know there is a path forward with this eip without any implement you know actual library changes but i think what we can do is come back in in two weeks uh with maybe a recommended library change um so we did benchmark a variety of different libraries and go um you know ideally there's there's bindings or implementations for rust that we can also do that will will get parity uh more in line with the speed of death for this pre-compile uh in fact num 0.2 pull request is already up the only uh reason it hasn't been merged yet is because there are no there were no benchmarks for that so um if we could prop the benchmark and then

we could probably start merging with the improvements to this okay fantastic i will uh i will hop in the open ethereum discord and uh and share these benchmarks with you out of curiosity so go in general is not considered the blazing fastest of the languages and curious why why is there such a big discrepancy so something is something is funky if there's a 6x that's that's surprising thing which came out uh what is it almost two years ago

an old comment was that parity does exponentiation by squaring but plan to optimize it i don't know if they ever did yeah i think i think uh that's sort of the right direction martin right so the first one thing was that um rust used to operate on sort of like 32-bit limbs versus you know 64-bit limbs which is what's in your you know processor today and so that was that was one of the issues i think this bump to 0.2.6 um you know i think maybe some of that was changed so that's one one element and then to martin's point um yeah there are more efficient algorithms so the big number library uh for gef for instance well if you're doing a large exponentiation we'll go into

montgomery representation and uh do those exponentiations and then come out at the very end and so if you're doing you know sort of large exponents it's much more efficient i don't believe any of that's actually happening on at least with this the big numb library that parody is using today so i don't think it's a rust performance issue per se as so much the the algorithms that underlie the the big number library that is is being used uh by parity okay are there any other comments or questions on that okay kelly as far as next steps or any

requests for um for i guess review on this what would you say is the your ask yeah so i think the ask is um what i'd like is is to come back in two weeks to present uh if there is a better library that we can use and then i think you know we sort of have i'd like to move towards eligible for inclusion in that next meeting i think we'll have two options one will be to change the pricing formula one will be to change the library underneath parity what i'd like to do is come with a strong recommendation that says you know this is possible or this is possible and then based off of that uh moved eligible for inclusion okay that's very clear thank you so much yep thanks everyone

okay next on the agenda we have a pr to change the work the phrase hard fork to network upgrade and eip1 and in general not enforced obviously but to try to change the common vernacular across other efi eips or other efi related stuff and eips etc i think that is tim if i'm not mistaken so tim do you want to go ahead sure so this is something that came up a couple times in the eipip meeting um it seems like on ethereum there's a couple things that are different with regards to upgrades and hard forks and then uh i guess bitcoin where this kind of originally came came from um but over the past couple

years you've seen kind of the ef blogs use network upgrades rather than hard forks um and i think this is probably something we should adopt just more broadly the main reasons for that are first of all uh like just the expectation that upgrades will happen fairly frequently on ethereum is quite different than uh on other networks where hard forks are kind of these uh dramatic and and uh and uh kind of uh very rare events um the second the second bit is just around uh i don't know one conclusion that was reached on on eipip is hard forks are often like the result of a network upgrade that that is contentious uh so that the the

kind of base case here where everything kind of goes smoothly is just like an upgrade and if people decide not to upgrade then they're kind of forking off um and the third bit is just around clarity uh for communication so a lot of times when uh people think of hard forks uh especially like in the past years as we've seen on bitcoin uh people think like oh i'm gonna get some free coins on on whatever the other chain is um and again this is probably something that like we don't want to be like associated with most ethereum network upgrades um and and that this way people don't have to worry like whether or not they're gonna get another coin and and whatnot um and so this pr i had up uh specifically changed it in eip1

uh but then i got some feedback that if we're actually going to do that we should probably you know have like a broader change across the entire eip repo so like we use kind of these meta hard four tips and and whatnot so basically just change all those for network upgrades um and this is obviously like a small technical change but a pretty big political and philosophical one so i wanted to get feedback on it here so my question when would we would we use the vernacular hard fork when it is contentious so for instance when the split between hca or eth and etc happened

yeah yeah i think that's kind of the way to think about it and i mean not uh to ramp on on progpal but say you know we had brockpow go live on the network and then you know some people decide not to upgrade and then there's two kind of forks of ethereum then i think that would be like an upgrade that resulted in a hard fork if that makes sense no we call those changes chain split yeah that is that is a good point or network yeah i mean the the terms as i've learned them a long time ago is that it's a hard fork if it's a non-compatible change so that if you don't update you're not going to take part of it it's a soft fork if you change something and

restrict the set of valid post states instead of expanding them so that even if you don't upgrade you can follow along and this has been kind of confused with the chain split and the chain split can be you know caused by a hard fork but and i guess they've been like confused together in people's minds yeah got it yeah i think that makes a lot of sense right uh and and i think i'm not sure what's the best way to clarify that where i think we want to separate the kind of you know normal case of a network upgrade slash hard fork on

ethereum with the kind of exceptional case of a chain split and i'm not sure how to best phrase that like my pr was based on what the ef uh used in in their blogs and whatnot um but yeah i'm not sure what's the best way to just separate those concepts and make it clear to people these are different categories i believe a any upgrade is is presented as a as basically a pr on the existing code bank case so it's going to then make a hard fork um to pick it up on the network if everything goes fine uh one chain survives

if things uh don't go fine uh we wind up with the chain split um it's so the chain split is is a post state and uh the hard fork is how we how we do the upgrade anyway sure so that's kind of more or less how it is today um at least at a technical level and i can speak to why i changed it to network upgrade on the blog because for the past i don't know however many hard forks i've been using the term network upgrade instead of hard fork when describing a change based on martin's um definition

and i changed that because i was looking at how z cash did it and how zcash did it made it very clear to their constituents that they are um not having anything that is giving free coins not having anything that is controversial not having anything that is necessary or i should put this way not having anything that is openly known to be controversial at the time of the upgrade so um that's kind of why i changed to that because there was a lot of scams going on and i prioritized the um making it more clear to the broader non-technical community than keeping with a

dogma of technical terminology and trying to educate people on what that means because it takes a paragraph to three paragraphs to really define the differences as we've kind of learned today i see it as a an uphill battle either way or one i was initially in the camp of technically it's a hard fork so we should go for that terminology but as i thought about it more trying the amount of time i've spent thinking about it of course i'm going to think about it technically in the way that i think about it but for someone approaching it without a lot of experience without even like understanding having a more specific understanding of how

blockchains and such work that you have to get to a very deep level just to explain the concept and there we have a lot of uh inherited baggage from the way the bitcoin community uses the term hard fork so even if they're somewhat technically the same socially they're very different and so either we would need to somehow convince everyone or or educate people that hard forks don't mean what a lot of people think they mean or we can use terminology that naturally has people come to the conclusion other opinions on the call

i like it i kind of i know that every time we are closing in on any form of uh hard fork or network upgrade uh reddit and twitter and all essentially everybody starts asking that hey do i get coins do i have things so there's obviously people are misunderstanding it so it might it might help i think from the community perspective the developers are very well aware of the difference between the hard work and the uh network upgrade as as this has been discussed just now

so uh for uh you know uh communities perspective if we are going to use the generalized term and if we can go ahead and define the term in a in a broader way in eip1 or somewhere else that would be helpful but using the general term to uh publicize what we are gonna do like what we are bringing up with this upgrade and to avoid confusion going ahead with uh network upgrade uh would be better that's my personal opinion just to add to that one thing that so if we want to so i can imagine that uh there will be some voices raising concerns that yeah but then you are kind of hiding the fact that

network upgrade is a hard fork so i think that if we want to stick to this term then we essentially in eip1 or wherever we could essentially make it abundantly clear what a network upgrade means and yes from a strictly technical perspective that means a hard fork so it's i think it's important not to try to hide this fact so we should obviously make it really really clear that network upgrade and hard work are kind of equivalent but uh if in communications we were to use the network upgrade then it would probably lead to less ambiguity for for people who aren't that technically inclined i i really like that and i guess coming

back to mark martin's original point like yeah i do want to make sure we we have you know some technically accurate definition um so would it make sense to then add something in eip1 which is you know these are network upgrades aka you know hard forks strictly speaking um and they also kind of define that they don't necessarily result in a chain split right but like there's the risk that they will but chain splits are kind of a potential outcome of the upgrade um and then to just use network upgrade when we talk like about the upgrade itself so on the meta eeps and things like that okay hmm yeah i agree with that as well

um and this might come down to the eip editor's decision although there's not really a clear-cut um process for who makes a decision to make this type of definition change uh generally it is discussed in the community through a pr and the eip's repo um alex berzazzi did mention that we should probably bring it up in this call just to get opinions and see if there's any kind of official or unofficial buy-in that we can get from the core devs um so are there any other comments anyone want to like say this is a great idea or this isn't a great idea kind of a thing because everything seems to be leaning toward

yes but again we're having a lot of people from the non-technical social side also speak up okay um so we've brought this up in the meeting tim in my opinion the next step would be to bring this up broadly as a pr that we advertise over reddit twitter any other like chat rooms any other places that we can get some community input from and then move it to last call uh if it doesn't receive any further any kind of dissent like outward descent while also checking with the eip editors to see that there's nothing process or otherwise that we are violating

yeah that makes sense i guess the process bit that was hard is um because this is a pr2 eip1 and not a new eip there's kind of no status associated with it right um so i i don't like alex do you have any suggestions on that given you're you're an editor or greg even because i think yeah thank you yeah yeah yeah i mean the the discussion is just to to use the different terminology than hard fork and that's not only relevant to eip1 but maybe to the hard fork meta eips and maybe other parts of the the repo as well

yeah so exactly correctly yeah so if i do say you know like a wholesale change in the eip repo um and add this explanation in eip1 um that's still not like adding a new eip so it won't have like a status associated with it like the draft last call and whatnot um and i'm wondering what's like the best way process wise to go forward from there i don't think you have any any process to be honest for change proposals to to eip1 or anything like that pierre anarchy go ahead james i have a suggestion or an idea that while we've been talking about this that we could i think it sounds like

the core devs are leaning towards saying yes on this kind of change so it we could have a section in efi that is for prs like this so we can make it eligible for inclusion as not as a status but just as a like a marking as the same kind of idea of a blessing from the core devs and then with community feedback and going through last call somehow then might be a good way to kind of resolve this yeah and this is to solve a process issue with these active vips which of which eip1 is the only active vip we have or i should say an active status which means it is a fluid and not a final eip ever and usually an informational document so

let's do this so we don't take up too much more time let's move this to that pr we have a link to it in the um agenda and we'll start pushing out that out and maybe even mention the core dev uh getter again hey can anyone come in and comment on this or give your approval or disapproval and we'll move on from there yeah and to be careful yeah i'll try to get this done i guess in the next couple days but there is some work to do on the pr to get there and i'll share that once it's done do we need to open a magician thread for this because this mostly leans towards us and if we need for the discussion probably we can go ahead and do that then we can capture it and

yeah i'll do that once uh once the final pr or i guess modified prs is up i'll post each magician's thread and people can use that or the pr itself to discuss okay thanks tim hudson is it worth saying or motioning that the there's consensus on the core devs on this idea kind of as like a a known item that people can reference i think so does anyone think it isn't that that that is not the case okay then yeah i would say that there is consent amongst amongst the core devs who spoke up on this therefore there would be consent uh as there is not descent

so we can add that to the uh decision items yes we can add that to the decision items um there's a long way of saying yeah i think it's accepted so i guess i'm the one who decides that now um let's see what's the next thing on here oh the state tree what was that yeah the next one is guillaume oh yeah go right ahead hi uh yes so i was uh this is the this is uh a pr is still not merged but i wanted to to collect some feedback and it stems from uh from a meeting we had in paris the it1

ethonics meeting we had in paris about converting from from the hexary tri to a binary tri format and uh yeah basically there were uh two methods being discussed before before that there was the stop the world approach where you just stop producing blocks and everybody converts the the try and when and after a while when you estimate enough time as elapsed for everybody to to be up to date you start you start minting blocks again with the new root and the other method that was initially proposed was to convert branches in the try as they are written one by one so this approach uh you know

combines the best of two worlds and well tries to at least and uh and the idea is that instead of uh instead of stopping the world you you lay another uh try on top of the previous one so you make the the classical try read only and you add this a new field in the block header to say this is an overlay try and every time you've write you go right into the into the overlay try so uh the the best ride the initial try is left read-only so that you don't have to restart your conversion all the time so that's the conversion happens in in the background process and when you read you first check if the

value you're looking for is in the overlay try and if it's not there you go to the base drive and when enough time has elapsed you decide that everybody should be up to speed on the conversion so you convert you switch the the tri route uh the base try route to uh to the its binary version and then you there's a second phase that begins where you slowly start merging the try back a couple a couple more than a couple but let's say a couple hundred um accounts at a time and then uh when all the when the overlay tries

empty uh you just dropped the extra uh root that was uh for the overlay try and you continue uh with the binary try um yes that's the general idea and uh i just wanted to to make sure it was a scene and uh and you know have a discussion about it so one thing that is super unclear to me is that so the original so the simplified simple version this whole stop the world thing is in theory it looks like well you just keep using the current try up until block x and then calculate the binary try and then start using that for block x plus one but but this is just the

[Music] essentially this is just how the thing works as a black box but internally there's absolutely nothing stopping you from generating the binary try three weeks before the hard fork and maintaining the the binary try and the hexory try concurrently so currently at least in geth the the try data processing the rights after a block is about after essentially committing the changes to the tries i don't know 25 to 50 milliseconds so that kind of means that if we were to maintain concurrently two tries then maybe that would be 50 to 100 milliseconds overhead per block

which is not really significant and there's absolutely nothing stopping you from from starting the tri-conversion literally weeks before and then just maintaining both tries i i don't really see why why we would create a much more complicated thing at protocol level when we can keep the protocol and the consensus stuff trivial and just let client implementers implement the thing and make sure that the try is ready when the time comes well first of all it's not that much more complicated it's just a different uh sequence of evidence um but it's the same concept and that's it but the point is that you are moving stuff into consensus

right and the the second reason is because when you have a phase you have a justification for uh for increasing the the gas price whereas if you do this over uh like before uh you you you're excuse me you are going to see an increase in gas price but uh there's no real uh protocol justification i don't see what the link of gas prices into any of this well you're going to have to cro like when you do of right you're going to have to draw to write double right yeah and so how would you uh i mean that that has to be impacted somewhere so there will be i mean there will be a

natural miners will notice that it takes longer to verify and execute blocks and thus they are incentivized to raise gas prices right yeah or lower the the amount of gas can be consumed but they're going to have to increase price in that in that case they increase gas prices across the board whereas if you just increase the price of uh the store the store or the create uh in in uh yeah the create instruction then you are you know why and you can justify why you're doing this for a short period of time but your proposal is not tied to and i guess uh pricing changes right uh it's mentioned it's not uh

yeah i don't have the the suggestion yet because i'm still running uh prototypes but i don't have but yes it is mentioned in uh the eip for me that seems like an extreme overcomplication over just so as i said i don't think the rights have a significant enough impact so that miners would start bumping the gas price and if miners do bump the gas price a bit for a week by twenty five percent i just had a number well so be it i mean the i think it's still a lot safer to have the gas prices be a bit higher for a week than to to introduce a lot of complexity at the

consensus layer where clients can go out of sync so even one single fault in the consensus will cause a much bigger fallout than whatever gas price miners might bump but again i i'm not confident i i don't think so i don't know how miners act but i don't really see a reason why they would pump the gas prices just because the block takes 25 milliseconds more to execute maybe they will but i mean okay 25 milliseconds um sure i i don't know how long per block it would take but uh from what i see it's quite a lot of

uh calculations to be done so um yeah 25 milliseconds okay depends how long of course uh ahead of time you you actually perform it but you for that period of time you still need to maintain the you still need to maintain both tries yeah but so in gath we we already do a similar thing when we generate a snapshot where we essentially we are processing blocks and while we are processing blocks we are generating the snapshot and on with the live node that is actually processing it takes about nine hours to generate the secondary data structure so that my guess would be that it should take a similar approach that if you want to

if you have the hexer try and you decide that okay you want to switch over to the binary one then maybe 24 hours before the fork is enough to start generating it so yeah i mean that's that's also the the case of um yeah of my approach it would be also roughly 24 hours i mean it's based on the same technologies the is the snapshotter um yeah um where was i um yeah if you uh if you do that i mean once again if you keep writing at the same time you still have the update problem you still have the running uh yeah i don't uh like you you still have this problem where you you try to generate something and you keep

right as you are converting it those nine hours that's if you're not interrupted if you keep writing back to it um [Music] uh just if you can finish up those last thoughts yeah anyway uh indeed it's uh it's kind of a technical detail so let's not go into it so essentially my point really is that i think it's more advantageous to keep the protocols the consensus protocol simple even if that means the client implementation might get a bit more complicated because to me it seems safer it's much simpler to just test out that your code works okay on the various load and not have to worry about

the interplay with somebody else's node in the network uh if i can make a comment as well briefly so i made i made a proposal to uh some changes to guillaume's proposal my change would be to to make things simpler by only producing empty blocks thus no deletions and no complications like that and only it would only amount to a couple of thousand changes during this period so that could easily be be merged again in the duration one block and if we so on the other extreme there's peter's variant we just switch over and that's easy to do for guests which

have a flat file layout in the snapshot but it might be more difficult for other clients uh there could be some some saying it could be some grace period where peter's proposal where we have for the for 24 hours before this switchover there are empty blocks so there are minimum accesses and rights to the state to give the clients more time if they have to move from try to try instead of going from a flat database model to a trial just an idea that's it okay guillaume where can people go to discuss this uh so there's um there's uh well there's the pr already and uh there's also a link in

the pr to the uh what's that called to the um research yeah absolutely okay thanks thank you so much um next up we have um eip 2315 simple subroutines for the evm analysis so this is a post in ethereum magicians where analysis has occurred um i think this was paul uh andre and alex right who who put this up we just we discussed this in the beginning of the call okay that's what i thought there's more to go this we can go into it but by just connecting together is there any more to go into on this

anybody i don't think so yeah i didn't think so either i don't think i don't think alex was here during that discussion he has anything to add though yeah alex said he he was gonna watch it later on youtube but alex if you do have anything feel free yeah i have nothing still haven't watched it on youtube no problem um eip 1559 implementers call update um i believe that is tim yeah so i just wanted to share the status update on this um basically there was the implement there was a first implementers call for

uh eip1559 yesterday uh the the eip has been worked on kind of on and off for the past year uh but where we're at is the guest implementation is mostly done uh the vulcanized team is working on that on baysu we also have an implementation that's working um and uh can interoperate with the get ones so we've managed to send sort of 1559 uh style transactions across a small kind of local network um on the call there was a kind of counter proposal for 1559 uh by uh dan finley from metamask uh i'll post it in the in the chat here it's a 2593 um and

and basically the proposal would be that instead of having this base fee plus tip model um you would just select kind of what's the minimum fee you're willing to pay uh what's the i think maximum fee and how how many blocks you're willing to wait so that uh your transaction uh price would just be increased block by block kind of in this uh following this curve when you submit it um so the bulk of the call was kind of discussing the trade-offs between those two proposals um and and the next steps from here are uh are to kind of run a economic analysis of the two and see

uh what the trade-offs are in more details and whether or not it's possible to combine them so one idea that came up is that 1559 has this tip parameter um which in times of high stress on the network basically uh falls back to a first price auction so maybe instead of using the tip you could have something like this this escalator fee uh instead um so so the the ef robust incentives group is gonna look into that um on the on the client side us and the vulcanized team uh are gonna try and set up a small test net uh to test a bunch of the parameters that were kind of chosen arbitrarily in the eep and make sure that they work and see if there's

actually some better uh better ones we could use um and finally one thing that came up uh was just like the user ux of these changes um so metamask is going to take a stab at what the different proposals would look like from a user perspective um and we might try to get the community bound yep um to get some more proposals of how you could represent uh these uh these different models um and and the plan is to have another follow-up call in a month um yeah that's basically it right any comments on that okay um i've left this on the agenda i don't think it was requested but i know

we've been talking about it a lot lately eip 2583 penalty for account try misses and i think that's usually martin um so martin if you had any updates for that or otherwise you can tell me to take it off the agenda or keep it on for next week or anything um you can take it off i have been convinced now that there is a much better model which was originally from alexi um using gas and oil as two distinct things and i think it solves the whole problem a lot better and also ties in better with witness and equanix so something we want to start doing now

is putting eips to withdrawn uh when they are withdrawn i guess uh so if you could change the status on that so we can merge it and officially take it off the record that'd be awesome um make sure that it isn't yet we need to add the withdrawn tag back into the bot that checks formatting just as a heads-up oh okay so that that that that tag doesn't really exist yet as far as the bot is concerned so okay um next up is testing and i know martin put an update um at the bottom of the agenda as one of the comments

um martin do we would just want us to read that or do you want to go ahead with it we have time if you want to say it yeah okay yeah we did quite a lot of work on hype another mind and visual are now uh almost first citizens um they will be when they can run the consensus tests um we've did yeah but they were looking around a few of the other tests so hive does consensus test that's what it's mainly known for but there's also peer-to-peer products which test some some vulnerabilities that may occur in the implementations it also contains graphql suite it also contains a sync test to see if

the clients can fast sync between each other's um that's it about hive and it's at devops.io not the old address yeah we're also working on this state transition tool because we in the go ethereum team don't really want to maintain the re-test deep client implementation but we want to replace it with this binary executable and to that effect we have tried to narrow down a specification on how such a tool should look in case other clients also want to implement [Music] one of these and the meter is working on trying to get them first while running

status with them and then running generating blockchain tests using this little tool and that's it for me anybody have comments on that okay review previous decisions made in action items i want to talk about this real quick as a just a process discussion we ran into an issue where some of the older notes had decisions and action items that were inaccurate so we want to develop a new or just improved way of having checks done for that and maybe having the notes be a little bit more clear so the cat herders will talk among

themselves about how to do that um if anyone from the core dev meetings has comments on that uh feel free to give them to me or pooja or attend one of the ethereum cat herder meetings just let us know otherwise i don't think we should go over the decisions and action items on the chance that they are inaccurate until we make it so that the system is a little more tight but if anyone wants to go over those on your own and you see a mistake that that would be greatly appreciated to do review of them we also i think another thing we want to change is to have hyperlinks um on the eips because right now it's all just

an eip number and then what was happening with it so that that would take a lot of scrolling to go back and forth so that that'd be a little thing does everyone does anyone have a disagreeing opinion on that or a comment so maybe one thing that would help the cath herders is if we could be a bit more uh prompt in updating eip status after the core devs calls because i think a lot of times it's it's easy if there's a ptr say today i don't know we agreed uh i'll take the last one we discussed uh martin state try eep um or state try miss eep um if that's withdrawn it's much easier

for somebody who's taking notes to link to the pr even though the pr is not merged but at the very least it's there saying like okay we're gonna update this that withdrawn and that's like an actual action that was taken um rather than to try and parse you know what's like the rough consensus and and and bubble that up into an action because then you're basically leaving the interpretation of like these often unclear decisions uh to the person who's who's writing the transcript that's a really good point tim and where there's going to be other process changes during the calls that we'll probably discuss on the core dev getter cat herders meetings and eipip calls depending on where they fall including maybe explicitly saying if a decision has been accepted

um as rough consensus i that's that might be a controversial decision that we would make if like we were to go forward with that process change so i invite anyone interested to just talk to me and i'll bring you to the right chat room or call to discuss these things further um do we have any other comments on that or final comments or things that we haven't brought up that or that i missed we have an extra two minutes let's all give ourselves a pat on the back for that good job everyone we we made it we got through this really long agenda today so we'll see each other in uh two weeks on may 15th at 1400 utc uh everyone have a great weekend thank

you thank you thank you thank you so much thank you cheers all [Music] [Music]

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

[Music] so

you