All Core Devs - Execution #83

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] hello everyone and welcome to edition 83 of the core developer meetings getting started here this one is not going to be as long as the last three-hour meeting this one's going to be the hour and a half that it usually is and so first let's go ahead and talk about the looks

like EFI review so is that's something we should wait until after we get to some of the other the ip's James er I'd say let's see if I can do the Berlin ones quickly and then we can go into the other ones there's a lot of good proposals to talk about stuff we haven't talked about before so I want to make sure there's a good amount of time I agree okay go ahead with Berlin and EFI then I'll do the the Berlin ones so 1962 we superseded by the BLS signature working group one which that is two five three seven I don't know if alex is here yet to talk about it but there they just

finished the specification is like frozen at this point and now they're working on finalizing testing in which Alex cuz there's two in here and then Alexa Weishaupt here for a quick update I think oh you're are you on my calyx yeah they are yeah well I'm sure it just depends which form of update you want in principle spec is more or less final and frozen it was kind of the last part which was missing was gas schedule and ABI update as I promised last time so in principle right now it's only to provides implementations it will not be changed anymore or at least it should

not be changed anymore is there any any update on the hash the curve and if that's gonna fit in with the pull request was updated with information about hashing ticker so as was discussed previously caching T curve usually involves two parts one is hashing to the primary choose a filter element which is done which can be done in in EVM be and this part has more than one choice like you can use different hash functions if you want so this part we don't implement this pre-compile we leave it as the functionality which is implementable in just standard smart contract this may

be like 20 lines of code and then we do our creation which is mapping as a filled element into the curve point which is non-trivial and which is expensive and the second part is specified as a pre-compiled great thank you for putting all that together awesome and just to be clear this is the thing that is needed for phase zero of eath - right I'm not I mean this is at least how I understand what is necessary to check the LS signatures because if you have to cash into the curve point

versus purpose but like I cannot give you a hundred percent answer because I didn't check but it's most like it that's it so taking complete nothing on the each one side is necessary for phase zero you to itself the thing that both pls call 3d1 and hash the curve are necessary for is having a light clients of youth to inside of these one chain okay so it's a nice to have our rather and it's a very nice to have I think one thing that it all enable is it all enable roll ups that use these what used you as a data source before the two chains merge completely ok thanks for the info everyone

you can continue James great the other one is e IP to five one five which is the difficulty bomb freeze I haven't done very much work on that because there's a lot of other things going on right now but I will get back into updating the IP with the suggested changes from the community yippee to three one five simple subroutines from the EVM do you have any quick updates great for that my memory was VIPRE was gonna look at some kind of looking at what it actually would do in into production change I'm

not sure what Vipers up to I think Brian about it and he said basically yeah it's got thumbs up and they're looking at making use of it yeah I know we they've always been supportive I just don't know where they are as far as code it looked like you were pretty close to code complete on that it's that true yeah so I can give a little bit of an update so this has been implemented as specified in the eat as a PR for go aetherium you can run it you can produce test cases and traces from it I do have a couple of

[Music] yeah I think it should be changed a little bit and I've been trying to race some people to look at it and yeah discuss it more in depth those much the change that I proposed are pretty small doesn't change it significantly and I tried to loop in also the solidity team and Christian right Wiesner is like it feels like his bit on the fence is a little bit positive but it's not like a big driver for him I mean it doesn't seem like this opens any particularly

new doors per se now solidity solved their problems long ago yeah but I'm getting an implement it is is the step you need for people to look at it more carefully yeah so that sounds like it's getting some progress and I'm looking forward to seeing where your your suggestions come in Martin yeah I mean if great if the people always called or deep into the IBM can take a look at the discussion

and my proposed changes today it contains a hack right now and I want to get rid of that and then there's the discussion should we allow walking into a subroutine instead of jumping to it and you have a where would that discussion be is that on the is that on the etherion magicians yes discussion ok so it's on that so people there people should who are interested should go to that forum exactly please and that that sounds good to me there isn't anything else the EIP two four five six versus the time based

upgrades I've been following up a bit on this with Dano and others and there is a the reason why that we went with the time base with the look back was because the weirdness that could happen at the time of the fork if uncle's or armors were involved at the block at the time or at the time rather than just the block height and so that's why I looked back was look preferenced and Jason Carver had some feedback that we would lose some things being able to inspect like being able to know where at the head of the chain by being able to look at the current head of the chain and

know that is the valid one we lose that if we have this kind of look back functionality internal rich Richwood perspective for that so jason has some suggestions about ways we could change uncle rate rules that would perhaps address that concern and then and then if that is resolved that perhaps we could just have a time based fork that doesn't have a look-back function just say it'll happen at this time and then the block that happens happens is it and also is it look like you're referring to just that we're doing at the block after or is it that we're doing this kind of double hop after like the second block

that that is modulo zero of 1000 after it's the double commit version right thousand blocks after this then it then it becomes activated so it's the first thousandth block after a certain point in time would then be activation for you James I have a question I thought we'd skip the fact that the thing like the the formula for the time like we're talking about the time bomb right am I correct no this is the this is the working based on time instead of working based on block number yeah but that's basically the only reason why we have to fork on time versus fork on block is because the formula is wrong I have a

feedback loop if we had a good formula I mean it's okay because the variance there's some variance and the block times right and because we set up great date you know like two months in advance it kind of leaves a window based on the block time so with this instead of having you know like a week plus or minus you know a couple days on each side leading to a week of a possible range for you upgrade you can say the upgrade will happen at time X and then it's and then if it kicks you in a thousand blocks after that you basically have a four-hour window instead of plus or minus four days window yeah and even under ideal conditions for block times its we still have that my plus or minus

three days I believe if I remember correctly okay so one to one small issue with this sine of n plus a thousand approach is that at least as far as I can tell that would implicitly require putting the entire including the entire last thousand blocks of history into the state whereas currently we're only putting the last 256 blocks of I mean history into the state because of the law - opcode so it does kind have changed the requirements of what clients have to have access to you a little bit yeah and it apparently it affected beam sink and other things that people were looking at

it's change so and if you reduce the limit to two from or the delay from a thousand to 256 then I think it should not change any invariance at all because the block from 256 ago is already used by the high polish off code no that's good to know we had we had best making it a shorter time line but it turned out we were having eight trying to find the right time line wasn't the real discussion was happening was that Jason would rather have it be a zero look back but you said 256 ours already store memory so that would be in wait what I did not understand is that it is true that this 1,024 looks like a magic

number in it there's no real explanation about why this number was picked like what is that what is it de rusha no and I said I sort of suspected when I read the IP I thought that the reason why this 1,024 block exists in the first place isn't it because two blocks might have a the same timestamp and if they do then it's not clear which one actuates the fork or is it not it's not legal for two blocks to have the same timestamp they have to increment at least one keep it then what's the issue can you just because I don't understand it wasn't really explained thing was it so if you don't have a look back the problem that they may run into a look at a certain time is that it may include an uncle

which has a previous number but it has a later time stamp and that makes these that can lead to hairy situations because whatever we don't know what changes are going to be made but let's say for example it's proper or something where we're actually changed something that would affect how we verify the uncle right yes okay I understand okay well yeah I mean I think kind of with Jason here is that I would rather say that we are let's say disallow uncle around not around that block time or something like that I think I think Jason's suggestion should not allow a block to reference an uncle

which has a later time stamp than itself maybe yes I think it does actually seem to me that these 2024 thing is just a little bit too tricky I would say I don't know and it is a magic number so usually a magic number is a sign of a bad design but I think someone around the number is in check if it ever occurred that uncle's were in fact on a later time stamp than the book that were included in and someone on the call last time talked about it I think they found

that yeah there were a couple of instances where an oculus that's more recent times I mean I mean if a minor has is on the wrong clock he will generate blocks in the future and they may not be thus because of that they will be uncle's instead of actual Canon blocks so it is a legit thing that can happen no no no I just don't understand actually do you think if there's Adam just saying that the so from my sort of intuition is that whenever you introduce the magic number that's normally a sign of a bad design and in this case you have to dig into why this number has been chosen and it sort of leads you to if there's a solution which is it

doesn't have a magic numbers usually that's the it's a better one and I think the solution which will not require going backwards from my intuition is probably going to be better one and that's the fixing uncle rules I'm wondering if it's really worth fixing for this picture well if you wonder that then you also wonder why so essentially the problem of the the the forks block-based works it does it does get accessibility with a difficulty born but otherwise yeah I mean it's four days four days period rather than for four

hours period I mean it only matters like once twice a year or something so that's why you usually the sort of the importance of such proposal kind of wanes after the fort so I would I would still not be yeah anyway that's kind of just my intuition the given the discussion happening at this point I'm less sure that this would be would be ready in time for Berlin it's a none of my thoughts at this point what I want to continue making sure we have the discussion and I was hoping Jason would be on today so he could discuss what he

was thinking and then we can resolve I'm here oh you're here cool have you been following on the conversation thus far yeah unfortunately so the your proposal for not having to look back involves something with the fixing the uncle rules and then Martin was saying that perhaps that's not totally needed for that feature so what would kind of be I don't want to misrepresent what you're saying Martin or it's not that is more oh no actually yeah so maybe I miss responses but but what I try to convey was that I maybe

think that I don't know if this eat at all is worth the complexity we it's going to take that's what please go ahead Jason sure yeah so you know my take on it is that the best way forward is to do just a time stamp based forking without any look back and just say that the you know we fixed uncle rules in the in the form of or further specify them in the form of either you know saying that uncle's can't be ahead of the including block or you know we could pick something and say okay

they can be you know up to you know two minutes out of the including block something like that but but I think it's fine to say they can't be ahead at all it did it did happen a few times at least in the first million blocks but it's pretty rare and I'm gonna be running some numbers on the rest of them just have more data on it but yeah just it just takes a few kind of clean up rules I think to to resolve it and and I don't think it takes too much but yeah I agree that the complication of doing look backs to figure out you know for me

it seems most important to be able to look at a single header and know which of the M rules applied to that header yeah about that that piece cuz I didn't I wasn't able to communicate that very well right so sue me the idea of like okay so if you have either block based forking or direct timestamp base for thing you can look at at any given header and know right away which for that header is on right so you know is it ahead or behind the spot number is it ahead or behind this timestamp okay now I know which rules applied to it you know is it what you know where the block

rewards for this block what are you know the other characteristics that that need to be verified about this header vs okay well you know I okay now I've got this header now I need to go back and look at some of the other recent headers even know what rules make this header valid that that seems kind of like a it's not worth the complexity at least not for this particular win of doing of knowing what window but being able I'm gonna time box the sub discussion will finish up the sub discussion and then move on to the next

one since we have a good number of things to get to and we probably won't get through all of them anyway yep think Thank You Hudson you're right on that and that is the Berlin currently Berlin thinking I piece but like where the conversation that Jason and Martin and everyone else was just having where's the best place to continue that is there a magician's thread we can link to and chat and on the court have getter I will find it well you continue okay that sounds great so yeah any feedback is greatly appreciated on that since that one is one we're going to put in and Berlin and do we need to discuss Berlin timing

today James in your opinion or it's getting into March I didn't know what we had originally said we were trying to kind of roughly group together as a date I don't think yet I would rather see some of the testing from the BLS stuff happen so perhaps next week we shouldn't we yeah there'll be some updates on there so at that point I'm guessing to okay thanks alright so main agenda items after that we have and again we went out of order on the agenda for those following along so we did item two before item one so the first one is e IP 2537 which we talked about yan i 962 fuzzing that's

the ec arithmetic and pairings with runtime definitions from alex blasts off and i did we just talked about that to the beginning yeah well there is a separate discussion about the funding that I wanted to start yeah so essentially well although we kind of know that this e IP 1962 which is the generalized elliptic curve pre-compose it won't go into Berlin I think it's still worth pursuing it and so far we what we have to summarize is that we have a very good accent

documentation we have implementations in three different languages we have some tests basically the first test and this is where we kind of I started to look at it and I started to and at the same time I actually happen to read a very good article about fuzzing in the region by some guy at Microsoft which actually does the fuzzing all the time and so now I started to understand the like our first of all how cool that is and secondly how can we use the more advanced forms of fuzzing to actually progress this change 9 1962 because it also came to me the realization came to

me that if we simply rely on every one like for the eighties if we only rely on the sort of manual inspection in our sort of really primitive cognition or relatively primitive cognition tools like our personal cognition to verify them then it will probably exclude most of the like very interesting but non-trivial changes like this one so because this one is definitely a complex change and and people are basically sort of feel that ok it's too complicated to be even reviewed or correctly or we need like more experts to review it so now I want to say that if we employ some

automation here we actually will be able to reduce the like a cognitive requirement for this and then I'm hoping that this will allow us to be more confident about such changes in the future so what we basically done is Giulio is always also Nicole I asked him to start looking into this and the approach that we take in is the first look at what the current phasing tests are doing and so what they are actually doing is what I call the blackbox test is that they generate random inputs in the form of like some sort of random pieces of byte strings and they try to feed it directly into the input to the pre compiles which unfortunately as far as I understand yeah because the point must be in the

curve yeah so unfortunately that means that most of those inputs will not be valid points in a curve and they will recently just trigger the validation code and not going into the arithmetic itself so Julia can now explain what we've been doing instead studies basically instead of generating completely random piece of data as they were passing right now we are now just creating keep creating random data but granulator that actually is that actually the meaning so we create a random point that is the Turner and we

curve but they are not completely random because what's now happening is that they create a random curve with random point that might be not on the curve so what we are doing so what I'm planning to do now is basically creating a random curve and then come the figure out point on the curve and then do the arithmetic related to it also there also we found also there are like I had some problem with the with the parsing so I figure out that maybe H files is not the best for making for making this kind of first thing maybe H files is not the best framework to use because there are two

random yes because basically if you have to essentially generate the not just so what we're trying to do now is that we're trying to interpret completely random number as x-coordinate and figure out the y-coordinate also we also try to interpret them as coefficients of the curve which sometimes leads to the invalid combinations of them so you basically have to have a specialized random number so generated that generate correct curve then generate correct point on that curve and then involve invoke the computation so right yeah well I should most likely comment on this well first of all as a as

instrument as a tail that would be able to I think I seen the to look for rasslin which at least which has like simpler way to define such advanced mutation of the inputs I've seen it's available in Rastan I think it was released by Microsoft itself but I never used it so maybe you already use this and this would be a valid approach and it can be used to just be less 12h one pre-compile second I just for your information I should note that current fuzzy testing code it compiles the pre-compile does a special feature which disables most of the checks so when you feed the random strings there even while

it's complete nonsense and even well after you construct the curve and you try to feed x and y coordinates and they're actually not on the curve like a very little chance that you will hit the curve so this check is explicitly disabled but still you get complete garbage as output but this garbage is consistent like what we wanted to check as it first it doesn't crash even in this case and the second and if all these computations actually pass they will never pass in in the release mode but in principle we just test the code workflow if this computations pass even on completely random inputs they still get the same output between different

implementations it was the main yeah yeah so that's basically I think from what you said now I think this is a valid approach but obviously it's not complete so in my in some sense so I think we need three different types of testing the ones that you described which is the differential testing between implementation and then we also need a tests which test validation which could be simply what you do but with with your checks enabled and the number three is what we're trying to do is actually trying to test the algebraic properties of the res matrix so essentially we're taking commutativity associativity by linearity of points so we want to make sure that we are

generating the the points in the properly so that we can check that arithmetics is actually performing correctly yeah so if you're doing that more specific one that that checks to make sure all the properties are conserved then doesn't that kind of also include the arithmetic from the completely random point uh well at least for now for pls 1281 implementation which i made as scared of the next layer on top of IP 1962 code there are already tests for basic arithmetics so is dosages tests which basically tells you if you add up two points like if you add

the point to itself you should just get the result which is doubles point three so you just invoke different functions same way you test for CBT VD and associativity so this is already kind of in partially implemented for twelve Els but if there would be a two link available which would be like which would allow not to write this manually but spend much less time defining also scrolls this will be a great addition to fuzzy testing of whenever would be necessary to include after but does does the current first test that you first test think that you guys use does it use introspection to cover CL or good the

vector s and mutated based on that no it doesn't so we currently basically using in it in a sense that we do not have a semantics of code and try to do coverage at the moment we started off just just the first simple step is trying to using our understanding of what the the domain of invalid input is try to generate it there we probably if this goes on we probably will start looking into for example there are some optimizations for certain set of curves in the code we also want to have a like a drill down into those specific curve types to generate more points there to try to test those optimizations so for so now

the answer is no we are basically doing it manually and but that's I mean it's my point my point of view the importance of this step is to even start it's like it to me it's like a start of the independent review of the oldest things because it's like you start touching yeah oh you start figuring out what what it does yeah yeah definitely we need that I mean and it's what we've been doing for a couple of years forcing the ABS well on the lib foster path where we do actually try to maximize the code coverage and get to get the code coverage out from gas and parity and maximize both of those and if you guys can get the same I think we

could actually get good coverage in 1962 which is impossible it will now be random inputs yeah so I want what I wanted to get in this Co it's a general kind of broad agreement that what we're doing is useful and we should continue and so that was kind of the goal today for me it will be useful too if you guys form an opinion about 1960 well-formed independent opinion would in my mind be useful the while 1962 might be a look I think a little bit of an uphill battle at the moment doing it on like the BLS pre compiles as I break up approving proving it seemed like a good way

perhaps right yes I don't know about that so if somebody wanted to say something before me I didn't want to interrupt I think you're good you can talk okay so yeah I think we did the effort that we've started right now it actually started slightly ahead of the Oh at least my thinking of this and then Julia started to work on it recently before this whole sort of shift happened into the BLS what is it called three one three eight one and so I think the original idea the idea I had was to actually use this

white box passing to pass this generalized library rather than and and then drill down just as if ax curves because these we know that some of the curves that I have or curve groups I would say have a specialized implementation and then we can turn into there yeah we could you know when we are confident enough that we are we are doing a good job at the generalized curves we could probably drill down into specific ones but we are actually learning on quite a lot on our own way so yeah well you convinced me but as their other thoughts or opposition on the call currently the black box posing

the currently using is H pass which I believe it's some microsoft passing tool right well H for us is kind of branch from one of the Google employees it's not officially product but it's from one employed base I well in principle is a repository which is public it has been no bindings to kind of call all available fuzzy testers including lip fuzz FL and H fast which is hung fast I found and I usually use hung fast just because it's a fastest one and it has a

multi-core support from like from out of box for example has very poor support for multi-core testing and for some reasons we father is factor of 4 slower on my machine even when it's in multi-core mode so it's um I've real quick have you all looked into and I am I am NOT an expert in this at all but V fuzz by Guido Rankin cuz he is a friend of aetherium so he would be and I think we're using that right now aren't we Martin like his stuff you know we're using his stuff but it's based ok anyways if anyone's interested in

talking to him or like looking at what he's been working on I just posted a link to a Twitter post of his any other on that I'll go ahead yeah I just wanted to ask again exactly the same thing so it's sort of sense the generally positive attitude towards to continue this work right yeah I I would say yes and I think it's part of the problem is testing and especially fuzz testing is not a lot of people's expertise so it's hard for anyone to come up with the negative or opposition thing to it because they don't know the stakes or any of the technicals behind it

necessarily is my guess okay it's point of process I think we could leave 1962 as if I and not make it superseded with this work happening but it's not the if I can it be well then then you're probably right I forgot if it was EFI it doesn't really matter at this point is for is like I just wanted ever be like two things I wanted everybody to know that we still want to help to implement it because I think it has a much it has a usefulness beyond BLS three eight one curve it has quite a lot of potential

for inclusion for basically beat for a serum to be more inclusive for other applications and search I just wanted to sort of get the sense of whether people think it's a it's a good direction to go okay so not as an official EF I just wanted to get a sense of direction I understand now yeah I'd say go ahead as my what I'm feeling to be convinced okay any other comments on that alright EW 25:42 is next that one is for adding TX gas limit call gas limit and TX gas

refund opcodes that's gonna be Alex for stat are you on the call hello yes I can hear you great go ahead yeah okay so the situation now in EVM is that there is an opcode for gas limit but what it returns it's a blood gas limit and denote a transaction or gas limits so out of all the parameters the transaction has like value ascender gas price only gas limit is not available for a smart contract to use and it creates some limitations for for example the common use case is like to know how much gas your transaction uses and the current like best practice

approach is to like rate in solidity variable to hold the gas lift in the beginning of a transaction and lend then subscribe from it and it's also problematic because it doesn't take an account they call data cost and it doesn't give you the full picture of the entire transaction it can only work for the currents take a current caustic so tell me what what you think about it is curious so what would you do with the so my guesstimate you mean the actual original gas that was specified with the transaction yeah right what could you do with that information

but how can I like for example like which wanted it raised as the problem is we are working on a gas station network so in context of method transactions sometimes you have a bookkeeping of who spent how much gas and knowing how much gas was used and refunded and all of the parameters of the transaction is it's critical otherwise you you need to make an approximation like foot right why don't you want the operation gas because for example if you have in solidity a public function it takes a byte array variable size byte array then by the time you

have gas left you don't already know how much gas was spent on on a call data and call data load operations so like that one is lost but you will never know you're never a baby to trust the gas diameter in a way because they've done other things before they called you right right it's that's why I proposed a gas limit of the entire transaction and of the current code frame so like you can figure out what what what the situation is like I would be happy to appreciate any input on how this can be achieved or why it doesn't need to be achieved so well I might I have a when I read it first I work of course I had a knee-jerk

reaction to this in my mind because we you might remember or some other people might remember we were discussing the ungass proposal previously which is basically the way to completely hide this information from the EVM so because we kind of realized for the when we were looking into say this is here am i trying to make the appropriate the gas change is appropriate for the witnesses and and history of arp 1884 where some gas cost of separations weren't twist so we sort of realized that the intersection rules of the EVM in terms of gas or the ability for smart

contracts to to observe the internals of the of the internals of the EVM looks like a cool feature but it actually call it inevitable leads to the to the to the brittle code that will be break and broken when we try to do anything with it with the gas schedules in the same ways there's already opinion that for example the chain ID up code might actually view bad in the same way that if you because it allows two contracts to introspect with chain ID and then they start building the code depending on specific chain ID and that basically that code becomes unworkable and so my reaction to this is actually those

directly opposite be the the sort of leaking obstruction narrative yeah that's my first reaction to that yeah I just want to add some comments on the back for community issue so if if it was like three months ago I would be like really strongly opposed the CIP because because I said there's some issue but I realize do is actually the gas subtraction assume is actually a leaky

abstraction so exactly nearly impossible to entirely hide everything to gas from the UVA because after all what people can do is that is that we can check for example get check the pylons and figure out the phase of a transaction and then use that to figure out I took gas used from the transaction even if we had ungass proposal so so what my thinking becomes and somebody needs to preserve the back workability like in the in the

best possible way even if the complete recovery is impossible so I think the current what I would I what I'm clearly thinking is that a biggest offender is the the gas parameter in all this call-out codes so so from so I'm thinking if we don't - um guess we just a part of the ungass that changes of parameters things are handling inside of IBM and that might be enough for most of the backup units for example for the 84 case that will be sufficient and in

that sense the entire if entirely hiding the gas information from from EVM is impossible I think in like introducing something about the gas limit like a lot of people to access the gas limit as well you may not be that bad but I still have some holding some reservations because is I still can say I figured everything out so yet just some comments and and and me another I won't respond to add a common sounds actual

associations or for for this new codes there's one called cow cash limit I just think it might be useful if you specify it more clearly because there's some rules in the in the when you usually used to a code the cash trend is actually quite quite complex and what I know is different implementation there's I don't remember there is actually a concept of gas limit of current execution frame and I remember is it is

possible to implement this call gas limit in different ways so you have different values but it's still give you the same result so just think it might be useful if you specify that or clearly what you mean by how do you think the UVM shoot should try this this cow has limits information and also the gas to TI's cash refund there are also issues in in the implementations because we know the gas fuel segmentation that that is kind of a journal a log-log paste when you enter a

coffin and then it's create a new turn o log and when you with some cows fails so to be found at Renault is reverted but in in the whole the ECM is is implemented differently we have some substrates so in this case the cash we found value the th guys we found value might have different meanings in different clans and if you specify in boundaries and other type of the implementation to do that so that's something I think need to be fixed I'd I

don't know was the best way to fix it fixes but I just think you see something need to be fix I've been well I've been noticing ten of two general thing to two general directions happening as far as development goes the eath 1x group is working on removing some abstraction leakage and moving towards something like ungass as a way to because it really helps stateless etherium which is currently actively being developed and I'm also seeing medica meta transaction community coming forward with proposals on how to make it easier I would love to see the meta transaction community looking at the unguessed proposal and

then see what they could do or what what could be done to allow for what the this thing that they're trying to get out of this which is allowing other people to pay for other people's gas or such or I don't want to say what it is you guys are looking at but looking from what you're trying to get to in the in the frame of reference of ungass I'd really like to see I have more question so I haven't read the thread on the DC magician's only skimmed through the Yankee and so one thing that super unclear to me is what the actual real-world use case of these features would be because they only mentioned

these theoretical things that well if we have access to these fields then the contract can omit some events well yeah but it would be nice to know why right of the contract needs the event in amid these events so it could really really help understand the motivation and maybe suggest alternative designs if we knew exactly what the end goal here is so one use case that I think we demonstrated a few demos is like using a permit function of of a die contract I think we allow people to pay for gas in died without holding assyrians like not directly but using a relay

server so like the one the entry the address it actually pays for gas in the theorem receives a compensation so it is in this case it's important to know during a transaction how much has the transaction costs so like there are two parts of the transactions one is the transactions that the user actually wanted to execute and the other is dropped by a relay contract you can see the implantation a gas station network GSN so in in this case we currently we make an approximation of how much the transaction actually cost but ideally is

it would be like zero zero sum so like everybody gets exactly the same amount of money and nobody like without approximations it's that's one use case it's common and like things are more I did not come up with the list of possibly use cases but arguably knowing how much the Garcia transaction your transaction used is and what the actual gas limit of this transaction was can be helpful I well the my other piece of feedback is the essentially like these these are the mechanisms because I saw

the some of the similar mechanisms is let's say in nurses wallet where they wanted to be able to let's say have a the owners of the wallet without having any ether and just submitting transactions but not to the chain but to somebody else then they can just post it and then executing it on their behalf and then basically be able to pay some some fee for it I sort of get this but I also think that maybe the even without this opcode maybe we want to too much automation on in this nine contract maybe in this use cases it's actually useful to have this automation taken out of a smart contract and applied like on the server before the you actually execute transaction I know it's

basically shades of some of the cases but maybe the way to try to put all of all of the automation inside a smart contract is not that it's not the best idea if you try to sort of to touch all the internals of the EVM because the reason I yeah I didn't mean to interrupt you I was gonna say though that I think if we were to add all this I think it would still be very very brittle solutions so if I want to make a mess transaction make a transaction or help someone else I could first make something which sets of storage slots in that filled ions thing where where I get

paid later for my storage slots and then I do the this math transaction and you would look at my origin gas and see hey you paid a lot for the cold later there and these kinds of tricks that would still make it gay mobile thing and yeah I don't think adding this would make would solve the problems that you guys are facing I think we would just lead to new new forests or problems I'm not sure I understand the problem you described like I would be happy to discuss it in a in detail but like I think they I think from my point view my

general opposition to this is not because I think it's useless but I think it's actually quite a high cost to these so these are instructions they specifically two last ones the like not the first one but the last one that's the other two which is basically refund and the gas coal limit these are the two pieces of information which are described in the yellow paper but at the moment they're not really accessible from the EVM and that means that you can always so if we want to modify the EVM we can do that because they we know they're inaccessible however if we add those things it means that we will never be able to not no never but we will be where it will be hard for us to let's

say do something about refunds like maybe change the logic and it's sort of to me it's putting the shackles on on our future ability to to to to fix things I don't know that's I think that the costs probably what would could be quite high I agree on a finger at least one of those suggestions of transaction gas limit yes totally okay to implement because while we may be a bit cautious about things like refund counter and coal gas limit which are internal to the execution of EVM transaction gas limit as more as the environment includes the

same way as gas prices seen and we never had really any trouble with the fact that gas price was there so but but in this case you can actually if you if you care about this one then you can actually pass it inside the transaction at the input if you are the one who controls the transaction creation and I think I think actually the TX gas limit that is the same kind of code as origin and origin is one of these of course that probably should never have been intimated because it has 99% of the use cases for it or bad and if someone relies on it that can be it's probably for roll on the wrong reason and I think the same way this is like the origin gas

that can be gamed in most circumstances for its use I don't yes I don't like it for that reason I think it can be substituted like if you're the person who are generating transactions you are actually controlling that number so you can pass it in as in good argument so you don't need a code for that well I guess the the use case here was that essentially if I want to I want to die or maker whatever to pay on my behalf for the transaction then I would like to tell them that hey please run this transaction but I also want to enforce that they cannot use more than some number some amount of gas and I think this is where the whole thing revolves

in that you can make even now you can grant the contract permission to take away your die and then the problem is that you cannot say that okay this transaction must not cost me more than one dollar or dollar and and I'm not sure that you can solve that without actually having access to the Gaston's yeah it's it's a different case when they smart contracts being controlled by the person who is passing this is a parameter but if as a smart contract you want to make some refunds or guarding based on the actual transaction guessing it and you cannot color this to be an input from a transaction creator insert any higher number of gasps well I guess

that basically the discussion that discussion goes into like okay if I'm not trusting anybody who's calling me is it really like I mean because if you know which contract it's called you can you can sort of say okay if that contract which could call me I can call it back and figure out what that number is I don't know I think it needs to be think thought through so this is about transaction commit so it's not a contract calling it's external transaction calling and obviously we cannot have any trust there no yes I mean if you are calling into your own contract then you can have a trust because you're you're actually the one

who creates the transactions but I'm talking about calling your own contracts here right now I mean you called the other country directly okay yeah Alex what is this is this are they learning explore further specific explanation you want to provide for what we've been talking about about the use Kies we are having or about this yeah do we need all three of these for the use case all three of these opcodes or can we get away with try the one we're talking I do think that transaction goes limit I do think it's like more most important and I see that it's easier to implement because I understand now that cause refund and called

not easily available but about the use case I'm talking and of course like there is a singleton contract on on the network and any externally on the account can make a transaction to it who is a meta transaction like as a parameter and be sure that the address will get back the money for for making this transaction from that contract or from like I don't want to go to details of the solution but but the core concept is that there is no trust between like somebody who makes a call and the contract so it's not like a contract can

take a parameter like gas limit and be sure that that is what happened because it will like pay this money back to whoever made the transaction so the contract obviously wants to calculate and know the godly me that was given in advance so but Alex at the same time the Gosling we practically you can calculate the gas usage or the gas need based on the gas opcode pass the coal data size as that that's what exact number like it's it's not that simple for like you can but one

that would depend on an opcode price of a node up code on cold data price per byte that was recently changed and ii like you would to get a precise number of course we would need to go and see which bytes or zeros and which ones are not so and again if it's a public method in solidity what's a little e does is it loads it into memory for you so then you would need to also take that into account and like I think for our use case it's not it's not a requirement for it to be public but solidity does have a poor implementation of call data structures so like it should not motivate any changes to a VM of course

but can we get a just a couple final comments on this from anybody and then just move it to the theory of magicians form and Alex if you can take some of the feedback here and change some of the the EIP I think it's missing security considerations specifically unless I'm missing it here and you can reach out to me personally to merge this if it's not Auto emergency is interested to help me out on this because I'm not actually a core developer so I'm not familiar with implementations of clients what is great all right so yeah and how can people get

in touch what's the best way to your email yeah okay I had one question sure Alex you said you were with the gas station network yeah is a gas station Network possible in the ungass world I am Not sure I'm not that familiar with an gas world but I think like from what I heard on this conversation it seems like the idea is to abstract the gas out from from the VM right pretty much so I I'm not sure about that I mean I need to look at the proposal it seems like not because like what we do is basically unchanged bookkeeping okay thanks so

much Alex and we'll move on to the next thing now instead of going to say item 4 we're gonna go to item 5 only because it is actually an EFI currently and the others are pre e IP proposals so we're gonna go to 2046 which is reduced gas costs for static calls made to pre compiles Alex Bears Ozzie if you're I think you're on here x''k you're on mute if you're talking there you go oh I thought actually I placed as a comment about this into the agenda oh look who the author sorry go ahead

yeah I just there was no well well like no one was pushing for it even while it was there for a loom for a long time and it's a word to you as it proposals before it to juices price and Martin also posted his emulations at number which is in Ian's a proposal is reasonable for reduction so I just wanted to propose that it should be eligible for inclusion and so think we should result is just check that current gas price for blake pre-compiled does not include this like virtual 700 gas

depends into its pricing and I think it should I think it doesn't and I think no like the ways how the benchmarking is made it never takes is 700 gas into account the benchmarking for picking past right now just calls the raw pre-compile code with some data without any stock for a stack you know like context changes so we just tell tells you the number of actual execution time and then there is in principle no obvious problem why not to include this maybe it's up to discussion to what range of addresses it should be used but this change would help a lot especially

if you do a lot of hashing like if you want to check the Merkle tree for example you do a lot of individual invocations of k check function or any other hash function it would help a lot same way for applications with LT Carrick medics if you do a lot of point additions or multiplications you pay a huge price penalty just because you pay 700 for invocation of the function which calls itself more like much less like roughly half but so I would want to see this included especially if they were already measurements done on this and even while oxic is not that active in it anymore

alright I want to like to also agree with Alex on this one a blake for instance should be faster and cheaper than the k check in practice it's not obviously because it's a pre compiled at 7 and grass is just not even like like we can't even think about it to use it for anything except like begging d cash and so Alex are you saying that the benchmarking being done for for instance the BLS curves are potentially mispriced because of the fact that we are pricing static call at each mark would implement it in a way

that the execution time and the gas schedule for pre-compile would be secure execution time of the precompile so he just takes the raw data and feed it into the input you don't touch this 700 part which is only due to EVM conventions and as far as I believe all the freaking files right now are priced in this way and I can guarantee you that BN precompile surprised this way and be a less pre-compile l surprise this way because I I did surprise you so pretty usually it's the cost of the pre-compile should not and at least as far as I understand for most of them it does not include 700 in any form so it's just the

benchmarking and the gas price in the country pre compiles it just what is an execution time for a given input like what is the cost of the solution time so you virtually when you call them you pay 700 gas for nothing ok Martin get a comment yes in theory I agree 700 is too much my measurement on guest shows that yeah sure we could go way below that and I totally do not agree when you say that there is it's not been factored into the cost of any of the precompile because it definitely has and we we have priced precompile thinking that yeah well we still have

the 700 so this this should be good enough and if remove that and set it to 40 or whatever then yes we need to do redo all the work in benchmarking all the pre compiles to make sure that when we lose this margin we do not get possible and I'm not opposed to that but it's someone needs to put in that week of work or whatever how many days it is to gather data and do the analysis and put the actual numbers up can you name specific free compiles for which we did something like this because I oh I check the work of Sark on 11

or eight and like my working beuliss I can be sure about this if you tell me other ones maybe it's just easier to check them and well I mean we have like compiles I need to check all them well I mean there was a recent reduction of the price for beyond curve and the benchmarks from there just the way ours they were done and I said I just used the same kind of benchmark to measure ap 1962 and OH and BLS 1281 and and those did not include 700 gasps depends so the price

is there are just pure executors and there are more intentionally yeah yeah and if you see that potentially all other are measured in some mixed way then it may be just easier to remeasure them right I mean I'm not saying I'm against it I'm just saying we need to measure everything and make sure that we measure it kind of in the same way in same across all we can't just assume yeah removing 700 doesn't affect anything it is all good we need to actually show the numbers it's just bouncing yeah can we just formally

cancer replace the nodes and wear that for any other pre compiles or changes precompile costs should not invoke say 700 guests depend so people would not do something like this later and it would be much like and it shows a kind of meaning of the pre-compile pricing would become a genius can I suggest quite a question for more to Martine for guess Alex for understanding how what which would be a benchmark what are the expecting runtime of the entire block for the VM today what is the upper limit we define as acceptable I think which I would say that somewhere

around 200 milliseconds is kind of a norm this isn't going to expect it so running the pre-compile and called it like until we film the block and see what either curate the price of calling it would be like good way to to see how thing going let's say we put the calling of the of the pre compared to carry 240 gas and then just completing the entire block putting the block with this sort because this operation would be a good benchmark or is it something that would do what we do would you do to push it to test it I can keep a simple like the recipe how I did the benchmarking and

you basically take your favorite ice cream implementation and you try on your own machine to run the benchmarks for easy recover and old PNP compiles like additional multiplication and pairing and Tony will get some set of numbers which will tell how much gas you pay per second of execution time on your machine on my machine it depends on a pre-compiled cold and it's ranges from like 22 to 40 so I use a number of 35 as a conservative estimate and then I price and then I cry sleepy IP 1962 in this

form so you can do this like the simplest way and you can even most like in grabs a coat yeah I think I think what you're describing is some science based of the etherium / benchmarking repository right yeah I mean the logic is the same as just as he can say parity code and rah it's the same the rest the four just for some context for you guys where this came up in Berlin I mean Istanbul in the conversations the CIP and generally everyone was like yes were we were supportive of it it would be it makes sense 702 we need to go at lower just there was

certain things that were hairy like this that that needed to actually be verified before we figure out what the real number should be and just saying oh let's shave off a hundred was was not really due by finding out what actually is safe and all that stuff so if if Alex or Lewis from your end are able to put in that work I I could see this going through pretty pretty easily yeah I agree I will need to check internally if we have a sunbed we've to do it in my in my site that Alex Alex to see if he can find some bandwidth yeah and what I'm thinking is for things like this like boring stuff like benchmarking that takes up you know time I think Martin

said like a week time or less we might be able to do bounties in the future because it's not like I mean this is you have to know some low-level code but there are people who don't attend these calls that could definitely do it if there was a sufficient enough bounty so maybe and I know we've done that before for testing and fuzzing and that's worked out so I think that's something we could try if we can find someone willing to put up that money or the ef4 open aetherium or any of the other groups or people who are interested in this going in could you would you think of doing like Twitter Cole or someone like to earn a Twitter message saying anyone this is like the CIP is can be useful if we need someone to do the work

and someone would like maybe if people could come in and and could pitch in some cash for two to super-sis these benchmarks yeah doing that that'd be a good first step and then using a platform like get coined to organize that would be giving it more publicity and more outreach to the devs already on there so yeah that's a good idea and if you want talk to me offline about that I can say kind of my opinions on best way to reach out to a wider audience about doing something like this but I do think it's valuable I'd say we should move it in a motion to good move into EFI it's already in the FI it is I believe so if this is 2046

yeah and then also just as a point of process as we were talking about earlier 1962 is an EFI and we looked through the notes and it looks like there so who's just said in meeting 78 it was entered into EFI I didn't find anything explicit I saw some stuff that might have been implying that it was I really think that what Tim said about it being tentatively accepted on an meeting 66 which was in the summer of last year it was tentatively accepted before EFI was a thing and so it got grandfathered into EFI because it was tentatively accepted

and I I can't find where that particular I guess pivoting point happened but that's what I think happened James or others we all remember it that way or remember Sam right that sounds right I remembered that that that sounds how it happened there was there was a day where we did a hold were where we basically said things that were tentatively accepted were moved into EFI cool are there any other comments on that okay we have a little less than 10 minutes and we have five pre e IPS to go through what we can do if we either don't get through all of them or we don't get enough discussion on each one which we won't is to bring them up first

next time since we spent a lot of time updating on some of the AFI and berlin e IPS and we can dedicate some time to these pre e IP proposals so let's spend about two minutes on each one so the draft of transaction post data a new field and transactions that cannot be read by the EVM is e IP 22:42 and I believe that is John Adler if you want to go ahead and just give an overview and where people can learn more and then we'll do that for each VIP hello can you hear me yes we can great I was thinking of more giving since they're all related I was thinking of more giving kind of motivation for all of them together oh you are you all these e ip's yes oh then yeah I do that

you have like nine minutes because I think other than that there's nothing else pressing is there James nope okay yeah go ahead right so the so - I'm here on the call to kind of get some initial kind of high-level opinions on whether these pre AE IPs or even worth pursuing if there's strong opposition then obviously that means that there's no point for us to bother expecting them out and implementing them and testing them and so on but in the absence of strong opposition then you know that's what we're going to be doing so the high-level motivation for this is to generally make roll-ups both optimistic and ZK variety have access to

more data availability and all their nice features so it starts off with idea that for all the roll-up constructions generally what you want is you have a bunch of transaction data in the roll-up that's posted on chain it's called data and then you want to have an authenticated commitment to this data and this needs to be done on chain so you're either going to be doing a simple hash or you're going to be Merkel izing it and then additionally for optimistic roll-ups for fraud proofs you also want to do things like Merkel branch verification so we note that computing authenticated commitment and doing things like verifying America branch these things are pure functions they

don't write to the state and more importantly they don't read from the state since they're pure this means that they can be multi-threaded so you know you can imagine a situation where let's say you know a huge amount of transaction volume is moved to a rollup then you can if you target four computers you can have four commitments to these to these transactions and a rollup and then a CENTAC eight a commitment to these data blobs like you can extend to get four of them in this in the span of one block that you could do now if you did them in parallel for example that's kind of the high level motivation so obviously there's going to be a number of details and whatnot that

we can complain about at a later time but this is you know for now this is kind of are there any strong objections to the following proposals so the first one is a new field in transactions this can't be touched by the EVM and then specifically this I call this post data just for lack of a better name the second EIP is allowing execution over post data using any pre compiles or any pure pre compiles and this will allow multi-threaded data availability processing and things like miracle branch verification which could be useful in other contexts for instance if you have a stateless contract the

third one is adding Yui new pre compiles for Merkel ization and Merkel branch verification which is really only useful with you combined with the above the fourth one is reducing the gas cost of call data to about two gas per byte and similarly setting the gas cost suppose data to somewhere around that and lastly a up a new app code for the current transaction hash which is potentially useful for optimistic roll-ups and might be useful just in general and it's kind of orthogonal to the other four in terms of what it provides so that's basically it does anyone have any questions or any

strong opposition that these things will never never be viable and should never be even experimented with all my questions are so I'm actually curious so essentially if I understand correctly the net total effect that this would have on the chain is that we would have certain transactions that are kind of huge now if it's there's one if we say that it's two gas per byte then we could end up with a transaction currency that's five megabytes in size and that would be valid which also means that we could end up with a five mega byte block

which would be valid that was correct yes this would also reducing the cut the gas cost of call data would also I guess it wouldn't have to but it would probably be simultaneously included there will also be a simultaneous increase in the maxbox eyes just in terms of bytes but this is not it is not necessary to also increase the max block size to say five megabytes you know I guess my question is that this does have a few practical limitations I mean the implications from the EVM is is a different discussion that's what I'm talking about now but from a data storage and data distribution

perspective essentially five mega byte blocks would be a significant hit so to say I mean they could cause some significant issues in a network first up to a theum the networking protocols will not be able to propagate that so I'm not sure that so honestly if you were to produce 500 byte blocks one after the other I'm almost certain the network would choke on it if it gets a 500 ID block every 15 second so that's definitely some thing that needs to be that would also need to be solved those objectives and the other issue is that if I if you allow five mega byte blocks then running

a quick calculation essentially that would permit the etherium chain itself to grow by 28 Giga bytes per day that's a big number so currently the the chain table essentially all the receipts all the headers blocks everything is 127 Giga bytes for the past 4 years and your proposal would allow to create 25% of that per day so essentially one year's worth of growth creatable per day that's correct yeah so there's a few rebuttals not to the point but to the implication

that this is an issue or the explication so if you look at the cost of a hard drive it's it's very cheap you know it's maybe like 50 bucks for one terabyte hard drive so it comes out to maybe a couple dollars a day worth of storage costs or less and this is assuming you know you buy a performant harddrive do you buy like you know one that just for archiving data because you can store this on a hard drive not an SSD then you know you're potentially looking at under a dollar a day in terms of storage costs so this is not you know inherently significant but this is also only two full notes most yeah that means that the storage cost so if I have eight thousand nodes in network then you just dump

eight thousand dollars worth of cost per day cumulative cost so if if so let's suppose that currently theorem doesn't have chain pruning or anything similar which means that these $1 keep adding abstract hundred days it's actually hundred dollars yes but chain pruning can be implemented fairly or not also knows need to store all this Oracle data can be implanted really sure if you want to retain that I don't love that any that's okay I'll do

it I think there's a few things that have been brought up in the last five minutes and basically some of the storage cost some of it is how to improve the network layer to support this Oh Peter I think I think you're like I'm getting echo from Norma my crappy oh there we go okay so if you could John and whoever you're working with on this the group I would love to see like a blog post that just explains like in a paragraph what a rollup is in case someone doesn't know and then eat for each one of these a ip's like you could put in the EIP itself this stuff like the motivation

and the security considerations and the technical specification but if you can boil that down to something that's like blog able I think that would help us look at it from a whole perspective and then be able to respond on like an ethereal magician's thread with this part of it you know has implications on the network layer this part of it has implications on the storage layer this part of it etc that's how I would suggest going forward with it if I were doing this instead of you so what my thoughts on that my suggestion can I can I show my suggestion to go ahead with best to be more kind of more but to be constructive

is that as Peter right to said that yes this kind of expands the these suggestions they do expand the demand and if your network and we don't know like whether what's going to happen if it happens so I think I would say that the prerequisites for doing that would both be potentially improve me improve in our status quo on the on this infrastructure like like block or not just a block storage because it's actually over simplifying the saying that you know have one back for megabyte or whatever it is is oversimplification of the problem because this whole thing has to be shuffled around network as

well when we people when we add nodes so we at the moment there's nobody actually actively working on the chain pruning and so I would love somebody to do that as a prerequisite to to putting more pressure on these elements so I understand that these are these things are quite promising they roll ups and stuff like this but I would like to see more investment in the infrastructure as well because otherwise we'll have a very choppy sort of top top-heavy system where there's a lot of applications and trying to build on top of it and then try to you know okay and you need this

and we need that but we also need to think about the infrastructure which which is currently like yeah it's it's a very thin thin and narrow so that's my sort of feeling that needs to be done together into the entry structure I just wanted to react with up what that X is what that X is saying right now and actually we had I had the same issue when we work on 2028 it is very hard or sort of there is no static cool on what is the technical requirement we want to keep over time or the technique cost of running a node over time and all of the improvement we're making here and the

one that John is talking about as direct all the parameters basically depend directly on those sort of premise of the cost of running in infrastructure so I would be very happy if we could also put to help dcpip which I find super interesting sort of define what we want to be the cost to run an unto the network also and I guess I can take this offline with John I discussed a long time ago to review on the if your magician and I still do not understand how this e IP does help and optimistic roll-up and I will be very excited to and a second question related to the

pre-compile using methi threaded also sort of I think fall back into the premise of what kind of machine are we expecting nodes to run so just very there are B to take this offline with you and I have a direct chat to to see where where where one slit brings this and how we can yeah go ahead PR and then make Alex go ahead and yeah I just wanted to ask much more technical question like why do you want a separation between the Cole data and some abstract other data to which you cannot have access others and : z pure functions on it it wouldn't be it wouldn't it be much better solution and actually usable for everyone to be able

to not just copy all the code data into the memory but maybe map it to some chunk of the memory and don't pay for this allocation so you can actually read it because it's already in the memory so you just you already receive it all over the network and loaded into the EVM so maybe it would be like a pure solution usable or more than one application but just being able to address their cold data in pieces and run whatever you want on this and just read it directly or use it directly without paying like a double cost of copies is called eight in the memory yes

that is potentially a good suggestion so one of the motivations for having this in a field that you promise will never be touched by the EVM is that you can essentially do a bunch of computation on it and then just evicted entirely from memory right like you know you can do things like pre process transactions that have post data in future blocks that aren't the current ones you're validating or you know things in the mem Pole and stuff you can do all this pre-processing and then just just you know discard the post data essentially from RAM you no longer have to keep it there but more or less mental Gus a huge part to this anyway like even if you don't process the end you never intend

to write a transaction you can even discount it altogether and just keeping some memory pool until it decides it to what included I don't know how it affects example same principle it can be an attack on Samantha you just shoot something which is huge data which will never be included that the memo will have to execute this to prepares the transaction I had I had one more suggestion for the John Adler side that to look into the stateless aetherium effort because there is some as far as what hardware and things could run and expectations there is discussion about that as stateless if you're in

progresses so that would be I'd recommend check looking into that as part of your work that's correct one point I was going to bring up earlier but then I guess people started giving suggestions which is which all very helpful thank you is that you know one of the things that are being proposed or say there's a theory right now is blocks that are in the order of one to two megabytes so you know doing something like what I'm proposing here is essentially from a networking perspective and nothing else it's kind of a dependency for stateless aetherium to ever be viable so no it's not it's not quite the same actually so but yeah let's we're not gonna go in detail right now so I don't think you can compare them one-to-one and also I want to react on the the current size of blocks today

and I guess Jeff can can can also comment when we did the post analysis for 2028 we sort of like we sort of crashed soft machine because of some of the title block and today you basically do not have that big blocks do to order to client mutation and eternal mutation is in the sauce practical imitation of the network so it's all in the assumption that we are this is already possible today is actually not true ok so Peter you had something to say and then we'll wrap it up if us John had something really final yeah just just wanted to quickly add just so that

people don't go on don't go off on some wrong path if anybody wants to look into chain tuning that's super nice I would be really happy for it just take care of one issue a lot of contracts depend on logs and filtering past events so if you start pruning the chain and you drop past events and some contracts might go dead I mean nuts contracts sorry some gaps for example I know auger akasha these are the two I always bring up essentially then this was the part where I stopped my chain pruning efforts is the next step would be actually to just go out into community and see what you

would break if you worst you will start to delete past blocks and past dogs it would be really awesome to be able to do it but it it would break some things I think wouldn't know what things break so that I just wanted to mention it I did suffer great John any last words and that sounded like like menacing anyways any last comments no I mean these are all good suggestions I'll keep them in my and then follow up with the relevant people at a later time offline right great thank you so much and yeah look at the chat for some people who are talking about that because I know that Tim said basu was working on pruning a little bit and stuff and just we

discussed this in chat we found that there were a few calls where the where we talked about 1962 going into EFI and so I would motion not to leave it so James do you wanna kind of summarize that real quick before we go just to know what we're doing with 1962 and even if we can put it on for next agenda but like where we are on it yeah there was a call in November where things that were tense attentively accepted for Istanbul were moved into EFI and 1962 was part of that group and then we had this we had the longer discussion into it but it was also it had like an asterisk of things need to be more figured out and then we've since had the discussion about the

BLS pre-compile and doing that as the strategy initially first so I and I last call we did we talked about superseding 1962 for the BLS pre-compile and having the strategy be create precompile moving forward for individual curves with today's discussion on alexei working on tooling for a path to making 1962 like secure and viable for for from them from the group perspective I'd say we should leave it as EFI as that work is progressing I would agree does anyone else have opinions on that okay bring it up and get her if you do we can always

re-approach this next next call if there are any strong objections to that but it's it's it's been in the FI I don't think that'll be a problem all right we are ten eleven minutes over time thanks you all for sticking around and we'll have notes out in about a week and we will meet again in two weeks I think what's happening then is that April 3rd all right we'll meet again in two weeks unless the world has ended bye thanks [Music]

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

[Applause] [Music]