All Core Devs - Execution #79

Transcript

[Music] [Music]

you [Music] [Music] [Music]

[Music] [Music]

and we should be on so good morning evening everybody welcome to the core devs meeting 79 I'll share the agenda in the chat but we have a whole lot to cover today first item that was on the agenda was ungass so I wanted to try and prioritize that which regards a time just based on the conversations and the in the chat before but way is not on so it's not a conversation we can have without way or should we try and wait for him to show up I I can probably alike because we cannot go very deep into the technical details

anyway I would be able to answer probably most questions and I also will explain what the last thing that way was saying about how it's related to the account versioning the IP for Berlin like for example he said that he wants shirt with the droid from Berlin Bush today so you want me to start to explain yeah okay so then gas was introduced a while ago by way but I didn't understand at first and I guess it's probably a lot of people also did not under help us conversation and he explained it in

conjunction with other things like account versioning and reprise of the op codes so if you look at these three things together then it starts making sense because on the on its own or any of these three things on it on their own bang gasps account versioning and repricing they basically kind of you know they they know they don't really have a lot of merit on their own but if you put them together then it actually starts making sense and then we discovered that okay so an gas might be something which will help us to make the status etherium gas surprising easier and at the last is state acetylene coal thanks to Martin

we realized that we might be able to not reprise any specific opcode to accommodate for state the city Rio but instead simply a sort of meter the gas which is used for for the witness it's also which would be much more I would say much better design because it has the proper separation of concerns so in in short the an gas proposal itself is the suggestion to remove the the ability for smaller contracts or any idiom code to observe the notion of gas entirely and which is currently possible through three different mechanisms maybe there's

more but we didn't discover anymore yet so the first mechanism is the opcode gas which returns which puts on a stack the amount of gas remaining in the current whatever frame so the second mechanism is where you when you do the call or a call like instructions you can specify how much gas is forwarded to the to the next call so this is where another point where you observe it and the third point of observation is when you hit the out of gas exception what happens is that in color and idiom semantics they it causes the current execution frame to revert and essentially cancel all the state

changes but it does not revert the the frame which is called this current frame so essentially if I do in this somebody could observe the gas it might not be very useful but but anyway so what Wei is proposing with angas essentially three main changes first is to disable the instruction gas secondly to not to stop the call like instructions from forwarding the gas and the behavior should be to forward the entire gas all the time and the third change is essentially to change the semantics of out of gas exception so that instead of reverting the current

frame it would revert all the frames and essentially the entire transaction so the entire transaction immediately fails upon the out of gas exception so these three changes I do not I probably won't be able to debate the like the technical merits of all of this but maybe we could use this just to sort of warm up so everybody can research and they own and sort of sink into this idea and now I'm going to explain why it is it's sort of it makes sense to view or them all three changes together so essentially this particular change in EVM is very disruptive like you essentially if you try to implement it as it is it will

break pretty much everything like this particular semantic changes and therefore way is proposing to roll it out together with the account versioning but the account versioning not in a sense that we're gonna have increasingly many account versions but we will only have we will only ever have two versions and no more there will be one version which is before the ungass which she calls legacy version and the second version which after ungass and that's it there will be only two versions so essentially it's like a bit which would be marking which one of this so in as you can imagine in the legacy version the semantics doesn't change everything

works as it works now a gas is observable everything is okay in the future version which is introduced together with the ungass essentially the rules of an gas applied and also the the way that account versioning is proposed the code which fade is deployed so the contracts which are deployed from a legacy code usually works for example some sort of factories they will also inherit the legacy flag and therefore we'll also be using legacy rules so everybody could probably notice that this is the way to potentially completely circumvent the like the the new version so you can easily leave out

the very generic proxy and just keep creating constructs through it after the ungass is introduced so how does this you know how does this get addressed so this is where the third change comes in is repricing so what is a way suggesting is that once we've introduced the second version initially it probably will be very very little used but then after that we start repricing opcodes but not in a way that we just choose one up code and reprise it like make it more expensive or make it less expensive but instead we are essentially repressing everything across

the board and if we needed to let's say let's say that example is a IP one eight eight four which is essentially increasing the gas of certain of codes if we had to do the similar change again instead of doing what we did in the IP 1884 we is instead leave the gas of those operations intact and then we'll simply reduce everything else and and that means that the the legacy contracts will look will see their operations being more expensive essentially if you do it more if you do it enough the legacy contracts will be priced out

and they will eventually be forced to redeploy but in the way its economic its kind of economic measure rather than like I'm gonna break your contract measure and the reason why it will work is because the miners could potentially like look at the different transactions and trying to figure out which one using legacy code which is not an apply discriminatory gas prices let's say like oh if it's a legacy one I will apply cheaper like a small gas price if it's the future one I'm gonna apply the the big one but in general case it will be impossible to predict whether the certain transaction will touch I both of them or only one of them and so forth I

think we think that the miners will not be able to do that in general case so they will not be able to distinguish them and I just apply the uniform gas price and then of course it raises the questions like how are we going to reduce the gas cost of the operations which already is like to gas and this is where we have two alternatives is a particle gas cost and way has its own proposal which is which he thinks is simple simpler is essentially ideas that when you do the call instruction you're artificially bump the gas available gas like times ten or something and then when you return from the coal you reduce it again so you create the illusion that the everything is actually cheaper but this

is basically the the summary and in a stateless etherium if we want to the reason why it would help us is that we will be able to to meter the witness size separately from everything else so we will leave the all the opcodes untouched with there's a gas price and semantics but when we charge for the size of the witness we will introduce a separate counter which will only count by how big is the current witness and so we will apply the the the out of gas exception in a case where either it's

the you know either the execution basically consumed in tear gas or it's the witness that consumed the entire gas I haven't worked out all the details but I think it will greatly simplify the design and it will not it will help us not to basically mix everything together so that's my summary and as I mentioned that way during the opening Syrian workshop a so he had a little presentation on Wednesday when he was describing which AI peas are currently kind of already sort of accepted for well not actually not accepted but proposed or select pre-selected for the

next heart Fork and that includes account versioning it's 1702 so he mentioned that he is intend his intention is to withdraw it but so that it could be included into the later release just together with Angus and I think the the particle gas might also need to be kind of withdrawn and REE included but it's up to the authors to do that so that that's it for me I have a crew of a few questions it's now you dropped one of these the notions that essentially account versioning would only ever entail two versions yes Remy was the plan I mean the fact that we're

introducing a second version means that if if they're M key stays around indefinitely then we're going to introduce indefinite versions eventually no we basically the idea is that we will only use the account versioning only for one purpose is to distinguish between August and one year but if you introduce an account we're spending to distinguish between these two concepts why do you think why can't you see it possible that we will introduce yet a third concept which needs differentiation potentially yes but it's not at the moment we don't envisage this but by I'm happy to try to explore this whether this is going to be

like too tempting to not to do it but so I think the reason why a way specifically said that because one of the criticism of account versioning was that oh but we're gonna end up like with the hundred different versions that we have to all support so which is a very valid could just as me what we don't want to do that and we're gonna keep all this functionality forever that's why he decided to shrink its uncommon versioning proposal to shrink the scope to only distinguish between these two things and where we could talk about the you know what it might be in the future I think you have a very valid point it wasn't an intention though okay either way this was just one of those

named pigs yeah more serious question though is how do so currently let's suppose we roll this hold on gas out with a conversion and then we we have version 1 and version 2 contracts now thing happens when these contracts start to cross call each other yes for example maybe this is not even across coin which is just a version to version 2 Co so if you were saying that if I call another contract and everything gets forwarded all the gas in yes in the new version yes correct

okay but this kind of means that if I'm writing a contract which so if I'm writing the host contract the origin contract that would call out to something else then how can I make sure that if that something else has a bad core is messed up or whatever then I can still finish writing because if you for example I I create a contract that it kind of something else and that's something else gets deleted or some on okay maybe it goes into an infinite loop whatever K then grant will never actually succeed so no matter what I do to always throw out of gas which the contract which calls it will always fail

to because he since you forward all the gas if you only yes and it will also always terminate the entire transaction yeah it's useful to include it into the so let me just write it down because I don't think I would be able to answer this now but I will include it into the questions for discussion okay and just you actually reminded me what my more complicated scenario was you were saying that when we run out of gas in in this version to code than the entire transaction yes but what happens if version one contract calls the version two thing which goes out of gas so I am

Not sure but I think the idea was that you if you are in version one and you call in version two then it probably still has a reversion what I'm not sure actually so it's good question so let me write it down as well so in this actually your questions are good because what I currently disagree with with weigh on is the so my my kind of intuition tells me this is a really complex change although it doesn't might not look like this so essentially in terms of they're very very like in tiny issues but semantics and like what you

just gave two examples of the things that you know really they they could be like really kind kinds of worms so that's why I it's actually probably what I would say is that it's the the more the most complicated things that we have ever done if we do it right anything else was like really simple compared to that so that's why I thought for a long time that the prerequisite for this change is actually to some kind of formal semantics and this is what I currently started started to work on and so that we can analyze this really rigorously because the chances that something is not getting covered are very high here in this particular change because it's very it doesn't look like

it the description is very short but actually it's very complex so let me write it down these two questions to you and I will you know create a rule I don't know like I probably will we'll discuss it with way and he might add updated documentation based on model okay and by the way the other way around is also interesting what happens if version two cause version one because now former so you had this idea that if you start out in version one and everything runs in version one that's okay but what happens if I do the other way around now if I start out with

version two and everything runs in version two this means that if you read price version one all that year will be moved because I could just create this exact point just for words the co exactly so if if there is a hard rule that like any transaction either runs version one or overton two then the argument about repricing doesn't work anymore because miners could very easy to distinguish what is what is going on and they can apply different gas prices I completely agree with that so the repricing doesn't work if they're if the cross version codes are not allowed things like delegate call so the

delegate call will according to the description the delegate call will also have the same behavior they will forward the entire gas right but if I one type of contract and I delegate call that is I'm temporarily using the code from another contract mhm doesn't matter if that other contract is version one aversion - okay that's a good question only matter what I am but actually if I start out as hmm so I think you guys started to open this is really good because you actually started to open that kind of worms and worms are

coming out at the moment so and I I think it's really good because we have by the clerk have to clarify it or just sort of rethink this I wrote down the three questions so far so clarification between course calls of contract what happens and what happens without and gas when version one version two and backwards and what happens with the delegate code I think once we clarified the what happens in these cases we can have a more detailed discussion because I'm sure we can dig deeper dig deeper into this but I had one question about the state

as a theorem side if it doesn't the version if it works as a way describes and you can't have that separation of that that doesn't break a lot of things then do we do we still get what is what we need for a stateless aetherium like the benefit out of it or does the backwards incompatibility kind of remove that part so if the if the separation of the versions is does not work and that simply means that account versioning isn't going to work at all I mean it means that everybody will probably be using the version 1 and you there's

nothing you can do about it you I six you have to design the entire entire like Stata CT room on the premise that everybody is still gonna be using version 1 so you will not get any of the benefits of sort of so essentially the plan was with the ungass the reason why it would help because if we if we start to economically kind of push out to version 1 and we know that the the usage become let's say negligible then for the purposes of pricing the witness we can simply ignore anything that happens with version 1 because it's gonna be super expensive and we are design our

providing logic based on version 2 so if we know that ok this is the version 1 pays so much that it will definitely cover any kind of witness that will arise and version 2 we know that we can do ungass it that's why we can price more correctly however if the the version separation doesn't work out and we could not price things out then it means that this logic is not gonna apply anymore and we have to design based on version 1 which is basically where we lost all the benefits I hope that I explained it clearly enough yep yeah that helps okay and I also like the moving it out of Burton so we have more time because anything that would

have to be coordinated with contract code is just gonna take yeah the reason why the account version was pushed out of Istanbul because we realized it's not useful yet and I think on its own in Berlin it's also not useful yet so there is nothing it sort of a trick that requires it but if we have something which actually depends on it critically then you know it could be done yeah so the reason why I would also say that account for training is fine as long as there's actually something using it because otherwise we kind of run the risk of introducing some semantics which

nothing uses but make everything down the line more complicated yeah takes a lot the next cipher for the background on this I think it's really helpful to get everyone up to speed and just oh sorry go ahead yes aiexander interesting the stateless client-centered a few important and I'm clearly not I mean yeah we've done gasps would you be able to publish for years for other people to learn about the topic and maybe a print like somewhere linked towards the way orientation the presentation you mean the one that I

mentioned yes please yeah so the one that he mentioned wasn't actually telling a lot about Angus it was simply going through the EIP he's in Berlin and essentially saying which one are already implemented in parity and which one are easy and essentially the conclusion was that like if all the Berlin changes could be implemented in priority or whatever you four would open a theorem without major really texture so it actually could be done in like a low resource mode and there wasn't really a lot of information about ungass at all so I would rather actually do something separate for that please do yeah there isn't things an agenda which describes the so if you go

to the agenda for this meeting so when feature asked like do you have any links so after that somebody posted a link to the ways description of this yeah yeah that's probably the best place I don't know if there's an each magician thread that discusses this because I think ways ways resources kind of a yes blog post is yeah but I expect we will we will get onto it in our group we're just basically getting started like we haven't gone that far yet just a little bit of patience and I think we will

start creating resources on that great thanks anything out son I'm gas okay I would say yeah I would say that we should make the ungass and those proposals still as EFI but also just note I just as a motion of the order that it is unlikely for targeting Berlin like those changes yeah I think the challenge so yeah it's out of Verdun and I don't think I'm gas actually has an EP so I think way way roll it down sort of on his website but I don't think it's been made into a proper EEP so we

probably know that it's definitely unspecified and from my personal opinion it can only be properly specified with with some sort of formalization got it so yeah I guess we probably just want to keep this you know at top of mind but I'm not sure James if there's like something we can actually put in EFI so so what I would say that I don't know what EFI is by the way it like eligible for inclusion yeah it's yes at this moment we are like not there and we will go into refining specific

like because as I said we just opening a can of worms and we need to address all the questions and everything and whenever we have some new information we'll present it if they don't have a new information we will probably just keep researching yeah that makes that make sense I'm great moving on just because we've already sort of a third of the call in next thing to be discussed was EEP 24 64 which is around the 865 protocol I think this was yours Peter yeah so a quick tid are essentially this is

the IP is about making transaction propagation more optimal in the network I'm not sure how many of you implemented that's working protocols here and if you're in but when you are propagating blocks the way block propagation works is that we have 25 to 50 years depending on client and whenever you receive a new block you stand that block in its entirety to I don't know four five six seven of your peers and you just announce it's the rest and the reason why this is good is because if a block has 50 kilobytes then something it's - only a small number of your peers is enough to propagate it through the network as long as the network is

healthy but if there are some degenerate topology links for example if if you have a small sub network that's behind the firewall and there's only one gateway connecting it into the mini theorem network then it can happen that that link doesn't get chosen to be sent for the whole entire block to be sent over and then by also announcing it we ensure that if we for some reason didn't propagate it to somebody then we still announce it and that somebody can retrieve it from us and this is nice because it means that if we have 50 peers and we sent the block to seven of them and which I know is a few hundred kilobytes of data and for all the rest we just send a 32 byte or give or take

announcement that hey there's a new block with hache if you want it come get it and then it usually clients what they do is whenever they get a block announcement they wait about half a second and if the block doesn't arrive from any other peer then they actually go and retrieve it now this is how block propagation works it works really well we can probably make some minor optimizations but it's fine now if you look at the network bandwidth usage of the theorem you'll see that there's actually a huge chatter in the network and this huge chatter is caused by transaction propagation now a boast to block propagation transactions don't have support for announcing a transaction or requesting a transaction

so essentially the only way nodes can learn of transactions is if somebody pushes it to them and this is problematic because you cannot cannot do this same trick as you did with blocks where we just send a trying to send a new transaction juice up to some of our peers and let the others discover it because there's no way for them to request it and we can there's no way for us to announce it that hey there's a transaction with a given hash come get it if you want it and this causes the bandwidth usage of the theorem to be kind of huge so I know our book notes for example are doing around let me check a number around one megabyte per second wait they are doing

one megabyte per second download upload just to shuffle the transactions and there's absolutely no point so the way currently is its implemented is that since there's no announced mechanism and no retrieval mechanism we just send the transaction to everybody so if I have 500 peers and I will send that single transaction to 500 different places problem is that if I have 500 peers I will also receive the transient transaction from 500 different places so it's a huge waste of bandwidth and essentially dcpip is kind of tiny all it does is is it defines a few more network packet types one of them is announcing a transaction so that the same way that we

can announce a block by hash we can announce a set of transactions by hashes it introduces a retrieval request so that if I know of transactions by hash but I don't have them that I can retrieve them and of course they reply that okay here's the transaction and my hunch is that this should cut down the global bandwidth usage of the theorem by at least an order of magnitude and yeah kind of that so does the IP div has some some minor details in it feel free to read it I don't you want to go into those but yeah our question is whether does anybody oppose this I know that

we've talked with another mine they like it as far as I know the Trinity team also responded they made some suggestions which we incorporated question is is does anyone else feel that this div should be changed a bit or or can we go ahead with with deploying something like this on the network strongly in favor of this one very very good improvement yeah so to clarify this is not a hard work and if there's no session we will probably merge this in in the coming week so just a just another quick note if you

if you look at the Eid we also linked in a poor request that implements the same gas and that pull request is huge I mean it's thousand or almost two thousand lines of code and I think it's important to highlight that supporting this Eid takes maybe about 20 lines of code so the rest of the 1000 plus lines is all about the plethora of optimizations that the CIB enables us so that we can we cannot essentially cut down so many things I have a one question so is this is going to be backwards compatible which means that if somebody doesn't support it they will still be falling back to 264 yeah so so

this is the same way as with each 64 so all notes so that b2b protocol supports running arbitrarily many versions of these sub protocols on top of one another and for example parity didn't implement yet East 64 I'm not sure whether they people but we have absolutely no no plans of cropping support for either 63 or 64 okay so for a fine so it means that it could be implemented like gradually yeah no that's so that's a nice thing that as long as the as long as the spec is approved so that client developers agree that this is direction we want to take it's completely fine for each clients to implement it and roll it out whenever

they find the time is there a place where we're keeping track of which eath protocols each client supports and then which ones to dip rate at some point if all of them agree oh yeah we actually are like on the last three so we can forget the last one for anyone or something like that well not really no I think it's so probably the reason we don't have it is that each 63 was backed out when a theorem launched so I mean it's a you could assume that everybody implements is 663 because that was the first official version and then the first upgrade to this was made by us last year

in November so it's this is the first time when we actually made it upgrade as for all protocols I know that before 63 there was 61 and 62 but 61 was only implemented by I guess and C++ but since EPP theorem is not the biggest rage now I think they even they implemented 62 and 63 so eventually we just dropped support for the older ones so nobody was running these 61 and 62 anymore so we just moved it out of gas and I think the same thing can be can be done done again if apparently ever upgrades to 64 65 etc then well we have the blue tones which are constantly we have we are logging

exactly what protocols and what protocol messages are coming and going so if none of the boot nodes log old protocol messages anymore that's a pretty strong signal that that protocol already died out of the network so does anyone have objections to this otherwise should we just move it to last call okay great so let's move this oh sorry go ahead was the was the IP merge is a trust yeah let me check I don't know so we should probably merge it as a draft and then merge it move it

the last call at the same time is that possible I don't know Malik's yeah I think the IP one is kind of under specified in regards to this there was only yeah I think there's not no strict rule I guess it's it's really only relating to the people on this call and and since everybody seems to be an agreement I guess it should be fine yeah and to be clear right yeah I think

it should go to last call because like we discussed a couple calls ago that'll trigger a bunch of alerts for different peoples and and we can get broader community review on it which I think probably won't happen if we just go to draft is there anything from the base you you guys or thoughts on this dad oh okay so let's let's move this one to last call and obviously merged merge it in as we do that next one on the agenda was a

IP 23:48 which is about validated EVM contracts I think that one is dados yes yeah sorry about that I started by being late I just slept in I didn't sleep in too long time to 348 so since the last time this came in I added a couple of changes to address some of the concerns that were brought up by Martin and Carl um the first movie to change that I added was I added an extra rule in the validation I pointed out that there's like a code segment that exists before the begin data and after the begin data and as part of the validation I limited the size of that to the contract size

that can be stored on the block chain there's a couple of ways you can work on this block change storage limit you can do it in the knit code although I don't know how you can make it terribly useful because you're still limited on building in memory the second way we're actually seeing on the network is where you can pass it in as part of the transaction I'm already seeing roll-ups that are in excess of 32 K and now at 128 K so the data those are mostly data storing all the information about the particular zkt roll-up that they're doing to get those stored by addressed and young so that's the first major change that I put in the second one that I put in

to specify the the particulars of the header there was a previous recommendation that had EF - EF 0 what is the header and I adapted that it's EF EBM the hex EF which is the eye of two dots under Lasky and to clarify that when you start running a validated contract you start at PT equals 4 to keep all the XD code copies you know relatives the zero indexed those are the two major revisions that I did on to try and address some of the concerns that I've heard and I want to know at this point are there other concerns and people reviewed this what other adjustments might need to be looked into yeah so could you just clarify it so

what does the fix or other does this elevation run on init code the audition is not running any code in order for the validation to run you must have the header in the code the 0x EF 0 6 5 au x 7 6 o X 60 there's the first 4 bytes of your code and it requires a versioning spec the block team must turn on version code so it must be a virgin white count that's run again if either those aren't true the validation does not rot okay so my question then is is it possible for me to trigger the ability to run on init code but they were create so that would

be now right now the instruction 0x kia is not a valid eb in instruction right now so if you try to load a contract with the validation it would you know happily story in code come time to execute you quickly unfailing out when the first PC that's in season invalid instruction how to deal under the old sets of instructions and so if you try and put a validated contract out there you wouldn't get anything out of it no I mean in this EEP you see right if we if with this you

on minute code we're not yes and so it would validate only the first three two kilobytes of code it hits the one by 1032 it'll throw an invalid code exception hi-c so that will be an added validation them rights just caught it yesterday right I added another step in there as you're validating the code once you get past 32 megabytes and haven't third series mailings 32 kilobytes or whatever the contract with minutes that just want to put a 4k actually yeah once you hit once you get past that stop validating it's

not bad anymore because you really can't figure out where the begin date of it because that begin data bite could be hiding a set of multi-byte instruction like the pipeline of bush you any other questions any other concerns about this particular adjustment so what is the next step here you're going by Martin model at this point do

be eligible for inclusion was not committed so someone would need to implement it and most important stuff the implementation it is ready to reference tests yeah there's champion I think that would follow me to get it implemented it and get the reference test written and then it comes back again once reference tests and everyone can look at it security before it's generally right for all clients to implement it quick question if I understand it correctly this assumes a new account version that is an EIP yes the triggers on the new account version requires the 1702 account version that's so much for having only do a calculation that would be nice yeah you missed that part of the conversation

that I'll put the first I think 30 minutes of the call when we were discussing on gas there's a proposal around just having the account version and you only activate once when we do on gas yeah so that's so doesn't require for we could combine this whatever I saw before I mean they're talking about changing a call from scenario mr. v re-enters having are using six arguments so you're gonna need something like a header in the code to say by the way this is this is the new version of the code got it so it's go ahead Martin yeah I

was gonna I'm reading through the motivation and so the second motivation is that we don't need to do a jump test validation and it's third one is to improve JIT and those are practical in my opinion although I think the second one I don't think there's a big improvement because it's pretty fast solution but the first motivation about the evolve of bbm and it strikes me as kind of vague and could you elaborate the bits on the real on the practical impact for that corporation okay so the

biggest thing that this will unlock is the ability to add new multibyte instructions the only multi-buyer instructions we have right now for to push series of instructions we're there to push than a bunch of data that's part of the byte stream and the reason why i meani to validate the code before we can add any multiple by push instructions is for jump tests for example if you had an old invalid instruction that became a morning by and then you put the jump test inside of what's that multiply would consume all of a sudden you have created a new thing that has been valid to be jumped into code it was once valid is suddenly now invalid because he added a new instruction where there was a

bunch of noise data that you could have jumped into and then now you you can't that was one of the test cases that was brought up in response to us 650 it was Greg's old standard that was one of the test cases that you know this was was critical and was topping it from going forward so by putting the validation in we can make sure that in the code segment that invalid codes aren't there so don't have a situation you know like say an air in transcription suddenly making the code unusable so if you can add my instructions later you don't have to worry about going back from validate

contracts to say oh by the way the jump mmm sure about it because it feels like simply validating that in the same passes we are doing now in the gentlest validation it's much simpler and much less complex to me all this suggestion we're dividing [Music] but I'm sorry my internet you

if it seems to be my husband Claxton throwing to just improve numbers but how do we keep if you all deployed contract still working is my concern we want to keep us working working as it is have any expected rules and not all the sudden and validate what's on there we can't just say well don't do this because of the time we announce it then tell me deploy it we should expect people will deploy broken contracts to try and exploit it and what is the current basically required where's the multibyte opcodes

are required currently I mean push it's 40 fi that okay so but I assumed that the people we talked about adding more multibyte instructions yeah those not initially this is the first step because when they tried to put it all in with with the EDM evolution 650 it got you know who's just too much it wants to handle right this is getting multiple steps okay we first identified the actual like piece it will need it and

when we agreed that they'll be needed then we will have to ready the proposal on how to do this but but this also means I mean not only the this also means that it will be easier to add new up codes right right you see not multiply single might be easily read off that and make sure that they are just sitting dormant Donecker and does this one also and for static jumps somehow or not yeah does it it does yes I think it can

I think it's part of the there's a heading for static jump violations I don't think so yeah yeah 6:00 6:15 was totally ruined by this issue Alex you you had a you had an EIP which also was was ruined by this issue didn't you miss Alex they're clapping yeah Alex's been answering but it was his

proposal yeah gladly that was on the way that swapping there was another one going along with it that they're going down the the paired pushes rather than just do the multiply instruction but in general allowing undefined opcodes to be scattered through our through our files is is just wrong yeah definitely Craig will be saying does as needed and looks fine and Donna you've also done a lot of research on this ones and it seems like an awful

recommendation for me yeah I would I would like to have heard ways thought about this one because she has also been a lot doing a lot of championing about different types of I mean it proposed three separate version of versioning but yeah I don't have anything against it to step in right now and this is a one sorry one day one general thought I had is that it's the usually and this is something that I would like to address with the semantics is that usually it's

very difficult to from the IP format I guess we're using now it's usually pretty difficult to estimate the the semantical impact of this change on to because as we know there will be a lot of interesting edge cases so I would like to spend more time looking at this somehow but so I sort of caught me unawares this particular thing but I don't yeah so it's very interesting but I also I'm where I'm wondering how this is going to play together with like with the account versioning and ungass as well and whether this particular so whether the path that we're going into good because

this is actually just one first step in the path right whether this path entails us to have a multiple versions introduced because I it does it and then this sort of it interplays with what I just said in the beginning of the code that okay we want to have only one only two versions ever or maybe we'll have only three versions ever so yeah so there's the enables multiple models we have you know versions where there's a version zero and that version one is version zero plus these odd codes the particular future that I would prefer to wear we don't really run sinful versions of the EBM if you run invalidated mode it just unlocks more operations you still have the old ones

that you disposed so what what I would say is that we probably should identify so the advantage of so of bundling everything together of course is that you only have ever two versions but obviously the disadvantage is that you don't you basically end up with a huge release with a huge heart fork which you don't want so maybe what we could try to do is that figure out the path where we could have still two versions but we can add stuff to it so what could what does the obviously we need to be a proper order of adding things like what is the first thing need to be added what could be added next without ruining that

version I mean like the sort of backwards compatible change of that version so it looks like this one for example could probably going to be one of the first because it actually establishes a better better platform for backwards compatible additional new stuff I would say but I would look at it add links from this perspective so if we're gonna take anything out it would have to be operation we're gonna change what the call operations do it has to be done in the first step all right Danno do you have a sense of if you want to pursue this for I could be upcoming

berlin or or kind of later in the time schedule there's four simple context the way he had said that he wants to move everything post berlin including account versioning i tend to agree with that I think it's been officious for me to get a prototype written and then all the other clients implement it by Berlin I think that's quite ambitious I'm willing to go along if other people think it has to be done but I think moving it out to London okay any more comments on this if not I think we're moving to another one of

Danos eeap's 24:56 the time-based upgrade transitions and I think so Jason no I don't think he's here but he had a comment on the agenda I'll just like we did for for people watching but he says he's kind of negative about an implementation that requires looking up a bunch of historical headers to decide which vm version applies to a given header and to be clear this is related to the time-based upgrade transition so using your time stamp along with a block rather than just the block like we do down yeah recommended to change that might not get us don't have to do this complex to face firing is if we just

require that all bombers have to have a time stamp equal to or less than the header they're included in so the question there is what would that impact network wise and would that adjust the problems where we can just fire on a specific time right if those things are work I'm fine jumping there Martin you said something yeah I wondering why it matters Wilmer um so if there's an armor that is so let's say that that block is before the transition and onwards after the transition and there are some really expensive changes like a change to a proof-of-work algorithm as an example given it gets kind of choppy at that

point so we want to but then we because when you validate you just validate the header no it doesn't buddy or haven't stood up into first yeah me to two pages right so the armor can't were saying it the Omer parent can't be before the first checkpoints so I was advocating Jason's position that we get rid of the C point checkpointing then we just the transition at a particular time oh did you update that no I did nothing to eat this is this is Jason Carver's a proposal that he didn't formalize in a neat but this is the thing he would rather see and if you know honestly it's

a bit simpler and if there's no network problems it does seem like a more reasonably route when he gives you to code but I thought there was issues with just sitting the hard work on a specific time but what you should expect from the Palmer not being on the same fork that's the omer validation is just a simple header validation so usually it's not a big person problem but what if the hard work includes changes to the header validations yeah then we'll just apply the old-style validation to that protocol omer we've done it in a pass like we had honors on the different Forks and you're validating them because you could actually the double fork require different header validation and what if people start generating plumbers far in

the future that's another concern so what are we discussing are we discussing yuri poured in ancient scanner proposal even though so brief they recap that again might have unless on marine so Jason standard proposal is just instead of looking back at blocks to see if it's been activated we simply branched on a time and the one changed the protocol to solve some of the concerns that were voiced was that they would require that owners be at were prior to the time in the block being valid so this would this wouldn't require the

change that prevents day for in the future honors but the requirement for them to be not later it's a bit too strict because at the given block would like them to homer so I would just it we may agree to that and just not set it to be equal or less just at 10 seconds 15 seconds whatever they both die me something given network I think I think actually would be a good idea even in separate just in itself to have that rule on almost that they must be older than then now look 50 minutes queued we

currently give clients to receive blocks but it's easier to validate now yeah there's no reason for an owner to be in the future there's no legitimate reason prove me wrong um it can be if you have the time to synchronize between two different miners and one miner is just one second lighter and it will just broadcast the block and the other miner will pick it up and we'll just milliseconds after will find its own block it will publish with that Homer it will be still valid because obviously consensus is one of the part of agreeing on what the actual timing sir but if

you're in yeah I mean that omec could be picked up in the next block yeah so maybe we should have some leeway there yeah because all the planks right now we get a 15 second in the future 10 and 40 in the future of any what we see for now it's not like Bitcoin when they get two hours of skew I think our clients give only 20 seconds so if we codify that in the honor roll then it's something we can point to pretty pretty efficiently as well as they want this is why the clients think this magic number two I remember previous research saying that

it takes about seven seconds for something to be propagated the one thing I don't like about pure timestamp solution is that it's impossible you need to do binary search to figure out what block we've worked on if you're for example like clients or doing a fasting for something right and this is the sort of thing where during in fork it a bit choppy but after the fork you can identify it you know to the exact term when people updated clients and you can put in a suggested start search point so the binary search could just be to the

bottom fourth block after I'm still trying to get my head around the differences between what the having the time locked they saying at a certain block then this point in the future will four versus this version yeah we have a great table this until Jason can come on and discuss it or we get more in session in the forum so I'm having to table it yeah I was gonna say if it's if it's possible to like get some of those you know arguments on like the eath

magicians dread I think that would be valuable as well like it seems like there's a lot of edge cases and whatnot to think through and and getting more eyes on that this is probably a good thing to do yeah Jason points to their a - oh I think we should move it to the forum at this point I was a bit concerned last week when there was no objectives it's okay so yeah let's move that conversation back there to each magicians next up was 1962 I saw there was an update given on that on the agenda but I don't know if there was more that people wanted to discuss on the call so I put it there just in case

well I have please all the progress because it's basically just updates and optimizations into the recent form to the github so is there are no direct questions I can just save people's time on this and you can continue you so I do have a question you mentioned that there's a good version that at least for now uses the 64-bit assembly go assembly it's just but I'm not the one who writes it I linked the person horizon I and I think site should be

here on the call let me check well it is he wanted to attend at or at least listen to it maybe he YouTube channel but we just chat in telegram and he's the no sir I will add the link to his work actually forgot to link to the repo but it's kind of more or less pure assembly and for now it will not be as a platform compatible the reason I idea how can you care you can still do it and go without templates and generics by using kind of continuation within a very old form basically make

like 12 copies of the same file with different constants but it we will not try it until at least this version is fuzzy tested is and as feature complete as other Joe yeah I guess that was mostly my here my concern to that I mean it's nice if somebody ported to what to go I'm just curious about how how stabilities on how reliable it is because so if it if it goes down to assembly I mean I know goes assemblies a bit more simplified but still if it is an assembly optimized then that's probably something that we cannot

meaningfully review I mean I'm I barely understand that some day I may be I could definitely not review it or validated that it actually does what it's supposed to do well assembly parts there is only very basic arithmetic so like how you do the multiplication or plus model reduction of two numbers everything else is normal code which you can breathe which uses model is the same optimizations which I have in rust plus minus some specifics or go in terms of like no reallocation variables we use them and don't get

garbage collection example the like kind of to reuse the garbage collection but others in this yes it's not yet portable but for now all the fussing earth which I think's here in a site encountered were in parson of the by new interface reservation in arithmetic we tried few test vectors and had and had an agreement from those at least you hmm oh yeah I thought if you have a link to the actual thing done I would really appreciate it and to link it's um it's for question XK here yeah I don't

yeah okay I'm an extra question is this the CIP the the the the codes are going to to give to the various implement are either going to be independently audits by an external auditing company or or another independently from a finger matter it is plan I didn't plan to do any external audits is the best thing I could hope is to have independent implementations in like in Morrison one programming language and agreement between them in fuzzy testing more or less practice it's three will in terms

of as soon as you pick particular formulas from particular papers and all those actually compelled together and placed in one PDF document you cannot like implemented different ways I would say as like as a like it's a short answer I didn't plan to try to make an external audit and even trying to find someone who would agree to do this be very non-trivial and most likely time-consuming expensive so for now we rely on at least I rely on the fact that there are a few implementations done by

different people and which use different even like different approaches how you would implement it in different languages and as soon as they all kind silent same out to date on the same input data and on some set of predefined test factors they all sit inside on a solid results like kind of testings I by linearity of cravings I would say this as it's a it is already very good sir okay okay thanks for the are you sure any other questions comments on 1962

okay next one on on the list was 1559 I think Trent you posted a comment about that I don't know if you had an update to give or if anyone else has an update or comments about it no I didn't have a specific comment I was hoping somebody from the implementer team would be here but it seems like there's nobody here apparently okay yeah I know we had a discussion about it the couple calls ago I'm not sure what the status is would with

Ducklin at this point I do I do have an update on thinking about the tiny of deployment for it okay yeah and I just as I've been reading more about it one of the concerns is minor collusion or and then be manipulating the fee in some way and the more I thought about it the more I think that the order in which this should be done is would be to have product pal be done first and then have EIP 1559 as a way to combat that which I know is a giant can of worms but that is where am I thinking has been recently

can you expand on what you mean by manipulating a collusion by minor yes so the if if a bunch of minors wanted get together and say hey let's lower the fee lower let's increase our minor what minor tip we would allow and then have the base fee slowly be chipped away down like that would be an actual attack that they could do and the only and the reason it's hard to do now is you don't really gain a lot it's currently and as far as minor it is difficult to coordinate among minors but as a six have a harder have a like if a six are

harder to get then there is this possibility that market power could be developed among them and I mean that in the economic sense of they would be able to enact prices that wouldn't that a free market otherwise wouldn't allow and the way to get rid of that would be to have a it easier for people to get into mining and not have and not have that be through you can there's two ways to to get market power there is you're either you're either everyone so you can choose and that's monopoly or the other one is you can get keep strong enough that the current participants don't have anyone that could come in and work underneath and

provide a lower price okay interesting I'll have to think more about that yeah have you have you maybe you should add that to the magician's thread and see what the implementers think about that vector well it's already in the security considerations it's the look it's alright it's the what to do about that security consideration it's where I've been thinking gotcha you

great any other comments updates about 1559 okay so that's it for the eeap's to review did anyone else have an e p-- they wanted to discuss if not the next thing was testing updates does anyone have testing updates then e IP IP meeting number one I think Hudson had a comment in there I wasn't part of the

meeting I don't know if no Hudson did not have a comment sorry yeah did did anyone want to comment about that yeah the next meeting is next Wednesday okay yeah I can give a little brief about what first meeting was conducted on January 15th and the participation stress it was quite decent the best part of the group was that about half of them have actually pushed or tried to push at least one IP at one point of time so the discussion was around the present concerns around the current AIP process

we discussed a few suggestions on how to improve and that have been documented I'm going to share the link of the document for those who could not attend the meeting and are interested to know what we did in like the video of those those have been updated on the etherium clattered github so we created a repository and we are gonna maintain it for every forthcoming meetings with the video and the notes there the next meeting is scheduled on 29th January at 1500 UTC there is a telegram group for a IP IP it is not published for the spam

boat reasons so people who are interested they can reach out to Hudson at Hudson at ATM dot o-r-g or just drop a note at aetherium cat little Skeeter that they are interested to join the telegram group and I will take it from there so yeah that's it from the update site if anybody has any question I can okay thanks puja for the update um next thing on the agenda was Peter you had posted about an RPC spec issue I don't know if you wanted to discuss this on

the call or if you just wanted to put it up there for visibility well it's not I don't know how much discuss it I think it's something I think should be fixed I put it on the course so that if somebody opposes it become they can invoice it essentially when you retrieve a block on the RPC api's if the block is the pending block then the spec states that the number field in the results should be known and from my part so not just a number of a percent for the minor the hash and some other few fields now obviously the minor it makes sense to leave it as no because there's no miner involved same goes for the hash since

you don't really know what the hash of the pending block will be so it's it doesn't make any sense to return it however it also states that the number should be null and I think that's actually wrong because the same way that the pending block actually has a parent hash which which references a real block if it has a parent that we would then we know specifically what the number of depending block is of course by the time it gets included maybe there will be three other blocks and whatnot so of course you cannot rely on this block being final but we know that this thing will should have numbers something something and furthermore since transactions can access the number of the block that they they are executed in

also means that transaction execution can depend on this number so if we just say that well pending blocks don't have numbers that's kind of a little white lie because transactions executing inside do have access to that number so I don't think we should hide it from the end user so essentially this was something that we fixed in the last gas release I mean fixed it by turning it into low and some people already started complaining that it broke one of their pools gonna be investigated and we kind of decided that although our latest release confirm so the spec I think the spec should be fixed and we should revert that change so is anyone opposed to actually

including the block number of the pending block in the reply I think that is enough and then I'll just update the spec and I'll also update well regard is changing yes so that we continue to return the block number sounds good and yeah I guess it's also worth noting that on the agenda where you posted this there were a couple people that gave a thumbs up to it so it seems if there's no objections here as well yeah seems reasonable to go for it not objectionable question are there any conformance sweets for the JSON RPC calls there are not there should be a

saying I guess the problem with these conformist sweets is that you need to actually set up a meaningful chain so that you can fire RPC requests against it and you need something like that in a cross-site a passable way there was way back I think Fabian for the seller wrote one but that was even before her frontier launch so just tested a fuse of a subset of the RPC calls originally before them and then boss rock on Alan Kay today tree rock one okay there are lots of test seeds that we don't use yeah cuz that goes on the second

question I had on because I know like I guess away sis is trying to spin up work with the open RPC stuff is this something that we should owner should we encourage like the Oasis group it's bidding up to own it and run with it and we fully adopt it it's more of an open discussion question I don't have the answer I'm looking for so me personally I'm not a fan of open RPC because so I think open RPC its own open up is essentially kind of a clone of swagger maybe it did there's there is a new name for it open rest I don't know what what the name is but essentially that's specifying or spanking a restful cause

there's a standard for it and that thing has been kind of embraced by a lot of industry players big players and it's been a really pushed hard so it's we can assume that swagger is kind of a standard however we open our PC well open our PC positions itself as the spec for our PC but really is just a team that put it together for aetherium so the reason I'm not a fan of it is because it was safe it is specifically made for a theorem done and nobody else uses it then I it's not really a standard so it's not really I know I just don't want to incorporate a

standard that's actually not least one another I'd much rather go down the path of creating the flexible test suite that somehow okay well I mean I wasn't meaning up the can of worms not open our PC just about that I always the standards group that some people are looking at forming you know who would have jurisdiction over creating it and declare again but yeah I don't really have an answer on that after going through the call going through all the awkward as stuff I think we have the recipe for doing it right which is we have groups that are willing to dog food and are working on it and have pain points and that we can it's

almost like you're doing it in house but in house is an in protocol so as far as making a standard so we can make another standard having a group of people go to another room and then decide hey this is how the standard should be versus we have people that are using it and we can build it so they can use it better and we know why they don't like it so let's make it easier for them like that feedback mechanism feels like it we have the recipe to make it work cool you okay I let this rig I had some weird echo so that was the last thing on the

agenda we don't have the notes from the previous call yet so we can't really review the action items unless anybody remembers anything that was important that we should follow up on or otherwise if people have anything else they want to discuss in the last four minutes we can do that okay I guess one thing I would want to bring up but probably for the next call two weeks from now is it seems like we have a lot of stuff that's kind of in flight for Berlin and then some stuff that's starting to shape up for London so it might be good to have like an ASIC discussion of you know what

could be ready to ship when what's like how early or later all of these proposals I don't know if anybody else thinks that would be valuable yeah I would agree cool so yeah maybe we can we can kind of have that as an action item for next call but over the next two weeks to just try and follow up with the teams and and if you had a champion for an EP that try and get a feel for how far long things are what's like a realistic timeline to get this to get this done and then based on that we can

maybe see you know what can be bundled together what should be standalone and and what are the dependencies across various initiatives cool is there anything else anyone wants to bring up otherwise we get through minutes back okay oh yeah thanks everybody see you all in two weeks thank you thanks [Music]

[Music] [Music]

[Music] [Music]