Ethereum Core Devs Meeting #98 [2020-10-16]

okay so we're recording to the cloud um welcome everyone to core devs number 98. i just shared the agenda in the chat uh there were not too many things on it so if there's anything people want to bring up during the call we'll definitely have have some time for it i think um first up we had two new eips that people wanted to discuss the first is a pre eip for the binary tri format i believe guillaume was the one who wanted to bring that up yep cool oh yeah right okay yeah maybe you could just like give a quick overview and yeah sure sure yeah uh yeah so it's basically a proposal um like try to make uh a simple three structure um so this is the first time i i presented so i'm mostly looking to to get feedback and i would like to to create the uh the pull request afterward afterwards um yeah so it's been a back and forth there's been a back and forth with a with a few people um and uh the goal is simply to have uh two rules uh one of them is okay so clearly the first thing is that the the tree the tri is a binary binary try and uh we also wanted to have uh because apparently there's a lot of zero knowledge application to this um an input where it's just uh two um 32 bytes uh like items as an input and one 32 byte item as as the output and otherwise another thing was to get rid of rlp uh by popular demand everybody wanted to get rid of rlp uh i also tried to get rid of um extension nodes but that is clearly uh too yeah too difficult like the the number of uh hashes that need to be done if you get rid of extension nodes is just uh it's just too big um yeah so pretty pretty simple um yeah whatever yeah if you have any comments or i'm i'm happy with with any feedback oh okay so i was just wondering uh so this is the format of the binary trial itself but uh previously you had some suggestions as to how to act uh move to that format yes that's still applicable to this form do these tied together that is independent um yeah there's still this other eip indeed that i don't really want to tie because like last time peter wasn't really like sold on the idea um so yeah whatever it could happen with regenesis it could happen with uh with the overlay try method that's uh yeah that's also well and my question guillen was that it we obviously discussed this before but what is the actual number if you did not when you did not include the extension nodes versus when you did include extension nodes how many more passion how much more hashing do you need to do as an example so i don't have the exact number uh i used to have it but i lost my my ssd uh two weeks ago and i need to recalculate everything uh but it was like maybe half a second to to just when you had like one thousand just one thousand leaves in the tree uh it would take like half a second to recalculate everything on uh on an average machine okay so sorry one thousand leaves in the entire tree yeah but why would it i'm basically i think i want to yeah maybe i should just go deep into it because i don't i don't know whether this makes sense uh to me i mean doesn't make sense to me but we should look at it okay um so what basically i'm saying is that i need to verify that the extension the addition of extension node is justified because you know we kind of agreed that extension nodes do bring extra complexity and if we can get rid of them without sacrificing too much of a performance then it would be good but yeah yeah i totally agree with that uh i mean there's so many nice properties even for witnesses and things like this if you don't include the extension nodes and uh but yeah yeah the way i see it there were too many two things that really increased the complexity there was the extension notes and really the all the bit twiddling about um like yeah that is included in the hex prefix especially and all the the rlp you know rule if if your rop is less than 32 then you need to hash it sorry then you need to include this verb verbatim otherwise you you have to hash it in my in my view this is where the complexity really uh explodes um so the extension node that i would have liked to to be able to get rid of them by all means if you find a way to uh to get rid of them uh and still keep the performance uh i'm i'm all ears i was not able to to do that okay so when you were let's just uh narrow down what what kind of performance do we mean uh do we mean the performance of uh constructing the tree or like an entire tree or do we mean the performance of let's say um verifying the proof with a miracle proof uh yeah constructing the tree uh but we do not talk about uh verifying numerical proof right um i mean let me say you know i think it's the same uh it's the same problem unless uh i mean yeah verifying a miracle proof presumably there will be less leaves than rebuilding the the tree although uh so basically in if you're if you don't have extension nodes that that basically means that all the merkle proofs will have the same exact depth right even righteously yeah so and even though uh you could say that the amount of information you have to carry in the proof is still going to be small but the amount of calculations that you need to perform to verify the proof will be essentially constant and that constant will be basically depth depending on on these entire depths of the like 64 or whatever it's called yeah you know thing okay so yeah then um so basically i like i would like to separate these two things and then look at them separately like do we um you know the verification of miracle proof and the construction of the chief so i guess right yeah so if you if you look at the pr somewhere there's a link um sorry not the pr if you look at the the draft there's a link to a hack md i did to precisely explain this thing separate the miracle proof generation from the from the try and uh you could use um like extension nodes in the in the witness in the proof and then recalculate it one one at a time uh so that can be done um but yeah even then the production of a block in my view would take too long um but like i said if you can if you can prove me wrong i would be sure okay cool yeah because basically my approach to that would be just that you know again when when you talk about the calculating the the the hash of the entire tree i would also again separate it into two parts the initial calculation and the incremental calculation so you know even even if the initial calculation is somewhat slow that could be uh could be worth sacrificing if we can show that the incremental calculation is still okay um yeah um no that that's uh that's a fact and uh indeed my calculation was more about building like rebuilding the entire try uh but even then you still have so many hashes because for every bit in your key you have to recalculate we calculate the hash so doing it incrementally is going to be faster is it going to be um because basically no i think you could be because uh when you were um so basically again when you think about how you're going to um there's a logical structure of the tree which uh basically assumes that initial calculation might be very slow and there's the the physical uh sort of model where how you store it and inside the physical model you can already take into account the fact that there is a kind of extension mode and then you can basically skip most of those calculations so basically i think you can make the incremental calculation pretty much uh the same as the with the current thing because i think the the times when we really touch the extension nodes are probably quite rare statistically so i think we could work on this i think we could actually solve this problem actually i'm not sure i understand because you're saying uh every time we touch an extension or like every time you're going to write a new and you you value like a new key value you're going to have to update the extension what i'm say what i'm saying is that let's say that we could keep the same physical model that we have right now in your implementation for example because your implementation essentially has the the um whatever embodiment of this extension mode right which is essentially but you can still have this embodiment of extension nodes in your physical but by by but by having a logical model without extension so that if nothing changed in that in that node you don't need to update it so um so my my hypothesis is that the number of extension nodes are not that large in practice and uh we don't uh this statistically we can figure out how much it is that you know we're hitting extension mode and how hard can you hit them in the worst case and then maybe that that is not going to be a significant so that's what i'm saying so um sorry so i'm just having a difficult understanding you guys but i mean what do you mean uh hitting extension node don't do it extension all the time whenever the trial is not fully saturated no what that by hitting extension mode i mean modifying something which is um beyond the extension node so like uh beyond meaning like closer to the leafs because if you don't modify anything which is um which is basically beyond the extension node then you don't need to do anything with that extension because you sort of pre-cached the the hash of that sub-tree yeah so uh uh so basically i i do not have this data at hand but how often do we do we hit that uh you know the um the things beyond the extension nodes uh every time we do an uh right do you think so um because i think uh what would yeah i think i think uh i think this is the correct analysis but let me uh offer like i i need to recover the data from my ssd like what's left what's left there uh i will rerun the test and push them and publish them on uh yeah that's that's a good game good starting point yeah okay that's a good starting point um i have a question for um the node format which is currently in a spec [Music] well there is a property of k chuck hash function that it can calculate hash of 300 and uh oh of 132 bytes as fast as of like 128 bytes as fast as a hash of 64 bytes so i would say if you would get rid of uh value in a node tuple and also get rid of the main separation hash which you call the node prefix then most likely you can get uh radix four three uh having the twice performance compared to radix two if we assumed a check two five six is used okay so uh if for your information uh there's no value and that's one of the things that got dropped there there's no more possibility of storing values in uh in the internal nodes uh yeah i mean um it's i mean maybe i just read it wrong that when you say that a node n is a tuple for elements and then later on you write internal cache and leaf hash and it writes with prefix in another format uh it's just a little bit confusing for me but it's not a problem uh i mean if you uh make a putting a domain separation exactly 136 bytes then you can make kind of specialized well then you can make 128 specialized uh keychuck 256 hashes with their external fade being non-trivial and then you can use four uh and then you can hash four elements simultaneously into a single node without increasing the actual hashing time so your tree will be twice less deep uh but a time you would spend to calculate it as effectively the same okay yeah that's interesting no to calculate a node hash time will be the same so to calculate any pass it will take twice a smaller time okay that's of course uh investigating indeed cool anything else on the binary tree is it worth making this into an actual beep at this point or is it better to just uh keep iterating on the hackmd um i've got some uh feedback to investigate and integrate but so it's not gonna happen today but yeah i'll make uh i'll make a new uh when when everything is integrated okay cool and thanks for your feedback guys great uh next up on the list was uh eip 2926 uh about the chunk based code merklyzation uh i believe cena uh you wanted to bring this up yeah um hi everyone this is cena i wanted to bring up court localization directly after the binary trial because they're somehow related so the primary motivation here is to reduce block witness sizes for stateless ethereum and the the basic idea is that we we make chunks out of the code and make a merkel try out of it and replace the code hash in the account record with the root of this merkle tree and then we can use this later on when stateless ships to not have to send a whole code and the current status is that as as you might have seen there is a spec and there are some some values there missing like as gas prices for the create up code and i'm i'm currently in the process of implementing um the spec in go so i can benchmark and and come arrive at those those values and yeah i just wanted to bring it up today for some um initial feedback so happy to take any questions yeah i have one um sorry i haven't i haven't actually read the proposal beforehand so i'm sorry if i'm if i'm asking something that's already answered but how would if we do amortization of the code what would things like x code hash return i think the current proposal is that like in the code tree you would just also add the shot three hash of the code as a backwards compatibility thing yeah exactly so the code try also includes some additional metadata like the code length and the code hash for easy access to to those parameters this also might be answered in the eip and i apologize if it is is the where the boundaries for the code hashing is that something that is controllable by the solidity or contract authors like function boundaries seem like a very obvious place that you'd want to have your kodash boundaries or is it just you don't really get to choose it it's going to boundary where it does and you can't optimize for that at all i think the current approach is just um hashing every 32 bytes and like i don't actually even think that the lot that the losses of doing of uh doing it that way are that significant like just because generally yeah functions are going to be along some of the some of the people from team x did an analysis on this i don't know what their answer was but i think it did concur with that that that it wasn't compelling to to the extra complexity wasn't justified in the space savings but i didn't realize junk size was 32. that makes sense i'm not totally sure about that so um so don't take that as possible and also also we did not actually have a proper analysis of what is the optimal chunk size i don't know anybody has done that yet sort of like what is the empirically or the optimal size um but i'm not too worried about this for a moment regarding this 32 bytes um are there any guarantees such that a chunk never starts on a data segment or is it blindly 32 bytes always we're not taking any extra consideration for the data section uh the only edge case that i came came upon was so at the beginning of every chunk we store the offset of the first instruction in that chunk to be able to escape push data and if the data section at the end of the byte code has something resembling uh push up code and um and then the data for that push of code goes over the the bytecode length this is just something that has to be handled in the code um but it can be safely ignored yeah i haven't when i said that a segment that's i meant push data so what you're saying basically is that if there is a jump to another chunk we can just load it and uh in the metadata c where the first op code is and thereby determine whether the jump is valid or not yeah exactly yeah so i just wanted to say that we have you know i mean i haven't written arp for it yet but we have an alternative to this cip which will probably appear at some point so we've been doing some static analysis on the existing code in evm and so which is called abstract interpretation so what we're trying to do is that we're trying to prove for as many contracts as we can in the which are currently deployed whether they ever exhibit the behavior that they can jump inside the push data and so so far i think we have proven for 97 of the contracts that were deployed that it never can can never happen um so the um basically we're just working on the doing the proof checker and stuff like this but the idea behind this is that if we can i know for for basically that most of the programs which do not specifically kind of want that if you compile them with solidity solidity pretty much always generates the code which never jumps into the jump uh into the push data so you actually have to craft the code specifically to do that to uh you know to violate this rule so the suggestion was there if we do that if we figure out how to put that in then we can even simplify the chunking rule that that we don't even need to include metadata that means that for the contracts where we were able to analyze them we we put the flag into the account saying that this we proved that for this account there is no possibility of jumping to the push data at all that means that you can chunk them with way do you want the way you want without even needing the metadata and for those where are we cannot prove it and i suspect those are the ones where specifically crafted to be avoiding the static analysis we simply do not mercalize them interesting um [Music] i mean radical but instinctively i uh um kind of like it um have we done analysis on like what pers uh i guess the question is like how difficult is this proving and like what percentage of uh contracts are 97 97 yeah well we already proven for 97 percent of the existing contracts that that they've never joined us okay so how difficult is the proving is the next question so essentially there's two parts of that there's a proof uh generator and there's a proof checker so and we we hope to have a proof checker which is much much more simple so the proven is basically uh we use a the thing called abstract interpretation where you go through uh it's like you try to build up the graph of the control flow graph and then in the you know go through these things but once you've done it the the actual proof is uh is is uh is much easier to verify so that the verifier is actually much more simple than the prover so but now we are trying to figure out how the big the proof is going to be and how simple the the proof checker is going to end up and what i also wanted to add is that you know these um suggestions about the subroutines and dynamic jumps uh we kind of now see that if we did not have dynamic jumps in ibm then those uh proofs will be pretty much trivial but what what we could do is that we could actually go into that direction and essentially sort of back you know like backfill that that stuff right um do you know what percentage of contracts to use dynamic jumps you mean what do you mean by using dynamic jumps i mean they most of them have a jump that is not immediately preceded by a push oh no no this happens all the time because the the most common uh pattern of using the dynamic jumps is essentially calling a subroutine in solidity from different places in the code so what it does is that pushes the return address does the jump right and then in the end of the subroutine it has to pop the return address and jump back so and that is not the jump preceded by the push but it's still statically analyzable in majority of cases right hmm has there any been any discussion about a new xcode tree opcode to to expose that internally or do we not want to do that just something that came to mind i'm not i'm not familiar with that of course oh as in like adding a new op code to access the uh the tree hash instead of the uh the cash my instinct would be against um because of the possibility that we'll end up changing the treeing again later and we'll have an a a growing list of um hashes that we'd have to store for backwards compatibility fair point uh i wasn't pushing for it just to be clear yeah um by the way speaking of um other um treeing approaches um i should also bring up the something i brought up once before which is the option of using cade commitments in addition to a merkle root um for um hashing a code um basically the arguments for arcade commitments is basically that you can fairly easily generate a proof for an arbitrary subset of chunks regardless of where they're located and this proof would just be a constant size uh 48 48 bytes which has the possibility of making witness sizes for code like quite trivial it gets literally just the code that you access plus one fixed thing that is something that i i still have to look into but i wanted to pull up numbers to see how much of the code proof is for the code itself and how much is the proof hashes um right and the other thing to keep in mind is that we don't we're not just optimizing for the average case we're optimizing for the worst case right because eventually we would wants to have like gas rules around these things and so forth yeah one one other thing i'm that comes from i mean if we don't if we see this as the current one 101x and we we don't have state witnesses yet so that means we would for like a 24k contract it would consist of 750 leaves so actually loading that i mean implementation-wise [Music] do you see that we should would keep the current uh codes side by side in the implementation or should we would we actually load these 750 leaves and concat them um have we thought about that you know um yeah so in in the eip uh we currently talk about there's a segment for the transition process and we thought maybe it's it's easiest to only store the flat code right now so when the when a new contract is created uh the client mercalizes it computes the root but then stores the root and doesn't touch it again and only stores the the normal full bytecode in the database and because of this we won't need to for now change uh gas cost for call and any any other code accessing up code and later on when stateless arrives then we can we can update and change this so the proposal yeah sorry who knows go on you're still on that topic okay so the proposal as it is it would it kind of already is open to there being uh trybacked codes and flatback codes living simultaneously on the on the network uh sorry i i didn't get that what what kind of codes so the proposed the eep it would still it's not like everything needs to switch over but it would have both of the both of the types of representation simultaneously oh um so so now the idea was that you mercalize all of the contracts all including existing contracts um compute the code route for them and sort them in the count record but then only store the the full byte code and not the actual leaves and the code try anymore because code is static um and the the tree structure of the code doesn't change and and clients um from what i gathered wouldn't need to have the tree structure until status arrives is that a fair assessment yeah sounds good so i had a question about chunking in the middle of the push data if you're going to keep metadata anyways flagging if the chunk ends in the push data then could you not have um not exactly fixed size chunking but chunking that takes that into account and chunks at around 32 bytes but just at the end of every uh push data i think the problem there is that as soon as you deviate even a tiny bit from exactness the relationship between a code position and the index in the merkle tree breaks down which adds a whole layer of complexity okay i see the central theme here that i've kind of seen since the beginning is that there are a lot of little efficiencies that we could possibly add in around the edges and it seems like pretty much all of them end up not being justified just due to the minor savings that they seem to provide and the higher complexity they seem to add not saying we shouldn't look at these things but um that has been kind of a central theme along the way um okay any other questions thoughts on the the code mercurization i have a comment but not in the marketalization rather to what alexa said um i'm not sure alex are you still on the call yes i am here um yeah so back like probably in may when we looked at the subroutines and we download well we looked at we just wanted to find first of all which contracts and data contracts because i think probably the last hard fork x code copy became cheaper to utilize when loading more data as opposed to a store so there started to to appear quite a few data contracts and anyway through the the subroutines proposal martin and i we tried to analyze contracts in the the state and as of that work i had an idea um that maybe we could do a one-self validation of contracts and mark them in the account if their data were not or to say it more nicely whether they can be executed or not and i wonder if that could be just merged with your work because you're already setting a flag um and you do analysis um i wonder if how easy would it be to check if the code can be executed first of all um and leave it back what does it even mean i mean what does that mean that there's a data contract does it have any what happens if you just send a transaction to it something random you think i mean that's the thing it's not entirely clear but the the tiny heuristics we added is you know in how many steps would it terminate and what kind of inputs um but many of them would would just start with an op code which is invalid um like a truncated push or any valid of code and those are clearly not executable under any circumstances yeah so in these particular things if they start with invalid up code that our analysis will mark them as basically okay because they are we know that they're not going to jump inside the push data they just simply terminate yeah but could you have another flag saying that they will terminate immediately or they will terminate in everything we we weren't kind of interested in that specific thing we just were interested in whether they or so we were basically interested in building the control flow graph and we either so for those for the things that terminate straight away the control flow graph is very simple it's just like terminate it's just one node um so the if they if the by by chance they have a little logic which does something i think in most cases the control flow graph is still quite simple so i think in most cases if you want to make it like super weird control photograph you actually have to do it by hand so like basically you have to intentionally make this so if you're you're just putting in some kind of random data more often than not it will have a very simple control flow graph which is basically failure so one motivation for this is executable flag in the country uh would be that when a new contract is deployed um it is analyzed whether um it won't terminate immediately and if it won't terminate immediately then it's marked executable and this is somewhat a maybe a replacement to the evm versioning in the sense that um there always have been concerns when a new opcode is introduced um how would that affect existing contracts and if you already have you know old contracts which were invalid maybe because on um a non-existing op code and they're not marked executable then even after introducing that new up code they won't be executable um that was okay i see i see what you mean so um so to answer your question is that i think uh this is basically a special case of our analysis because i said that if we already uh trying to figure out these control flow graphs for anything that we see and there could be either they could be basically either we can build the controlled photograph or we can't i mean that means that we don't know like maybe it's just super dynamic but if uh if you look at this control graph and it could see that it's clearly always failing because it will be obvious from control photograph that is always failing then you can mark it as non-executable so i think what we do is basically a bit wider than than what you're asking so yes we can do that yeah just just to add some context so the analysis we did like alex um it focused on a different thing and one thing that caused problems for us were not the type of data contracts which are just blind data there's another type of data contracts which basically function that you do a delegate call to them and that you delegate call for example load segment one and then it just uh it does an internal code copy from the code to memory uh so you get like segment one and then you can continue your execution because you got that in memory and then you can do that again and load another segment of whatever is data you need to load which is cheaper than doing like x code load index one two blah blah blah or at least it's easier i don't know why but uh that's the type of data contract which is actually executable but which does contain like white random data although it should not i mean the control flow graph should not lead into that random data well basically what if you look at the um if you think about the this particular contract so when we do delegate call right from the point of your control flow graph it it doesn't really matter what this delegate quote does because it just returns with either failure or success and we know that the top of the stack will be just either zero or one and then it does not really affect the control flow graph so we can see that our analysis will probably show that this is executable contract and it does not either it basically it does not violate the property that it never jumps basically it never jumps into the jump in a push later that's what all we wanted to know for mercurization essentially yes or maybe i have uh brought you on the wrong track because i was just trying to remember all the contexts and it's actually multiple different discussions and ideas um the data contract question is just one the having invalid instructions is another one um but it would be perhaps nice to discuss this and and uh i don't think that all cordes is the best place to discuss it um yeah yeah so because because basically we are uh we're doing this control flow graph analysis not sim not just for the chord localization but uh another thing we would like to use it for is for um looking for data dependencies in the past transactions to be able to sync faster so we want to create the data dependency graph to be able to parallelize the execution and all these kind of things um maybe as a closing question should we consider like a brainstorming call like one of those breakout things or just um have like a text discussion on on the old codex channel what is the best way forward i would say that it depends on the priorities uh to be honest so i see the kind of we could we could have a probably like some sort of background discussion going on about it uh is it worth maybe having just a new discord channel i feel like there might already be one for this one there is already one i think i don't don't need more discord channels so if there are inter people who are interested in the discussion i think we could self-organize into in so if people have time and it's priority and we can talk about it because what i don't want to do is i want to create a discussion which is for something which we're going to do in like one year and at the detriment of something we have to do like in the next two months so we have to prioritize these things properly but anyway if anybody's interested in having the discussion i suggested we just have a chat and self-organize and just have a talk about it okay sounds good and yeah we can use just the basic awkwardness channel for that um so next up on the agenda was uh the euro networks uh so james shared kind of some specs for uh both yolo v2 and yellow v3 let me just post those in the chat um i guess first of all it's probably just worth asking the different kind teams where they're at with yellow v2 um and then maybe we can have a just follow-up conversation on v3 and the status there um so for v2 which was uh basically the eip2537 the bls curve 2315 the subroutine and then 29.29 uh the gas cost changes uh yeah uh artem i see you're on the call turboget is not doing uh yolo v2 right um no no we're not collecting that okay yeah we're not we're not doing yolo v2 at the moment uh because again we there's other things we have to fix okay yeah uh and then sorry i'm going on order on the screen i see here so martin uh any update from guest uh not really with we still have not actually merged all we do uh i was hoping to have that done by today but no uh however we do have um i run a little bit of fussing with the all the way to against visual gut versus isu [Music] it's pretty slow i don't know why but so far i haven't found any differences um and as for test updates i know there has been work done on the converting the these standard tests uh with two 29 29 rules on you yolo v2 and that seemingly has a pretty large piece of work because it changes all the expect sections or rather a lot of expect sections start to fail and thus the tests are do not get filled properly and dmitri is working on that and also dano has done some work on that so i don't know maybe donald knows better than me what's what's the statuses and that um yeah i've as is dimitri gets him checked in i bring him over i film with bisu and i run him on gas i haven't seen any differences yet since we got those last few issues relating to the constant values resolved so as far as reference test goes it looks fairly solid um yeah and so basically's got all three of the things for yellow v2 and we're ready to go on it as far as the evm test i updated on the bug i think it's because when we use the bitcoin ec k256 whatever it is um we do the default randomization to prevent side channel attacks and i'm thinking that it's blocking on native entropy uh we've seen that before as some of our unit tests so there's a a special flag you can put in the environmental variable to turn off that randomization and that should stop those arbitrary one to four second pauses while it's waiting for the uh native entropy to catch up um yeah just another thing that might be worth mentioning uh is that in my opinion the you know 2929 uh gets huge coverage from the existing 22 000 tests um so we'll have to look into if there's something that is not being covered but you know since it changes pretty a long list of actual normal op codes and doesn't introduce any new things i would say that it gets great coverage uh from the existing test great coverage but i do think we need to write tests and maliciously try and mess with the warm cold list across transaction boundaries i think that's the only test hole that i would want to have fixed yeah it might be that we don't actually do we have any state test with multiple serial transactions um there are some accidentally in the crate series right yeah we might need to add some custom block tests good and i think there's some called delegate call call stuff that might trip it but yeah well are they really they really i i doubt if they're really sequential transactions in a block yeah yeah yeah but something that's deliberately trying to break it i think would add value cool so i guess yeah that covers it for the base you update as well uh dragan i hope i got your name right uh you're from open ethereum right uh yeah uh basically we're not going to participate in yoga here's some current tasks that we need to focus on okay um and then uh thomas and nethermind any updates yeah sure sale 21 29 29 i was looking at it and i think we'll wait a bit until the things to build stabilizes with tests since we have uh gef and bezu on it i think when there is a test network for your lobby to just edit quickly i estimate this as a maybe maybe a day of work it's pretty complex so i want to have some tests to speed it up when we start to work on it and i was working on three other eips i don't know if they fall under yellow v2 i believe not but it's 2935 two five six five and one five five nine for sure okay uh and i think that's everybody anyone else want to speak up that i might have forgotten um i have a um request that is the icip meeting like as a part of new process that we are starting for eip standardization and network upgrade uh the consensus there was to have the change in the statuses of eip and that should be reflected at the time when we are getting into the f mirror or into the test net and all like uh at at this point of time all the eips the two eip two three one five two five three seven and two nine two nine all are in the status of traff but now the work has enhanced i mean like we are looking into devnet uh we just want to bring into the attention of authors that it would be worth considering the change of a status and they can make uh their request change without it is okay and sorry maybe i missed that what would be the appropriate status for the ones that are in progress the first one is a review and if it is past review then we can go into the last call for example like yeah yeah so review is basically like we're working on it and okay review means that the spec is at a point where other people should start looking at it draft is really meant just for i'm working on this and maybe one other person is looking at it but no one should look at this because it's not done review means we think it's done as an author other people should now take their time to look at it pretty much anything that has made it into this call is probably should be reviewed by that by now like making this call means you want other people to look at it and so you should really be moving into the review by that by the point okay good to know uh so yeah for the authors of of all the stuff that's being discussed for the yellow networks definitely worth moving the eeps um and so in terms of next steps for yolo v2 uh it seems like geth and bazoo are going to keep working on adding tests and setting up the network uh then uh another mine will probably join shortly after um and that'll kind of be it on the last call we discuss a potential yellow v3 i'm not sure that's worth uh you know if discussing now given we're still kind of wrapping up yellow v2 or uh i don't know what do people think the yellow v3 was basically yellow v2 plus 2718 the type uh the transaction envelope and 2930 the optional access lists um but it feels like on the last call i don't know people have like different opinions about how valuable this would be um whether or not this list made sense um so yeah i'm just curious if people have just general thoughts about the idea of a yolo v3 um and whether we should do it or not then if so whether the current list of each on it makes sense actually the team since you mentioned yellow v3 and 2565 is not on the list i think then it means that it's in yellow v2 so let me add something i was uh finally running the benchmarks in nethermine for 2565 and surprisingly for most of the operations on the modex the previous gas pricing was uh better aligned with the results that i've seen in nethermind and we're using this like built-in library for big integer exponentiation i already reported that to kelly and waiting for some analysis from their side on what other options do we have on libraries or whether there's something else that we can do yeah kenny i know you wanted to bring up 25.65 as also yeah maybe that's like the good uh a good time sure yeah so i think the uh the quick update is so it uh it looks like bessu has now um implemented and the test vectors are matching what they're supposed to be with the new pricing so good progress in that direction as thomas mentioned um you know when he ran the benchmarks and we looked at it with the new pricing there were some items that were down you know in the there's one i think as low as like uh seven or eight million gas per second so you know unfortunately this is another case sort of as we had with open ethereum where the native uh or the standard modular exponentiation library is is not as performant as it could be we're just starting to look at what that looks like for net and what alternatives are um you know the the first pass looks like that one is at least for net it's built for like 32-bit architectures and so you know it's it's slower for some of those reasons and so we'll look and see if there's a an easy alternative there um i guess you know that being said you know i would be you know personally interested in in if yellow v3 happens you know um you know we know that there could be a sort of denial of service vector given that some of these are down near 10 but i think you know to the extent that we could test it from a cross client perspective on making everything you know making sure everything works uh assuming we can fix this.

net performance problem um that would be uh you know one of my one of my preferences because i think all the teams that are planning to uh participate in in yellow v2 or v3 uh have now have now uh implemented that and have have the test vectors passing just to note uh when you mention like seven or eight millimeters per second what is the how does that compare to the other precompiles uh i think that's an important metric normally targeting 40 40 million per second in nethermine for all the operations yeah were you getting that from like shot a bit six and like yeah yeah yeah yeah yeah all right yeah i mean i think this is like it depends a lot if you have a turbo boost on or off in your basement this is one of the major things that i think you know and maybe it's something that i'm uh could potentially spearhead sort of moving forward you know on i think you know as we move forward and these pre-compiles are more important right for things like roll-ups and and are getting more use the gas repricing situation is not um it's not crystal clear right we've got multiple different clients um you know what you know is 15 million gas per second the right you know number like that's what ec recover is on geth it's as low as 15 million other folks are targeting 30 or 40. you know there's no standard like are we on a four core macbook at two gigahertz are we on an eight core at you know five gigahertz so i think one thing at least in my perspective that would really help on these repricing things moving forward is like maybe even to have an eip to to specify like a reference configuration for uh how to reprice these things because i think you know it's very hard to do apples to apples on any of these things when people are running them at different frequencies different number of cores uh levels right and that's that's the problem when we try to when we talk about these absolutes guess per second and i really don't like that i think we should just try to get them to be you know roughly in par with each other right and i think that's a that's a great uh point i mean you know if you go back and look at some of these other eips you know some target to try and get them on par with ec recover but as i mentioned with you know something like death that's closer to 15 million gas per second whereas you know nethermine's been targeting 30 or 40. uh well even with what it's important here right now there is a optimization there sorry what was that alex uh i would say another and as alex comes first or like nothing about thomas thomas okay well i'll come well i say because obviously i agree that we cannot talk here about the absolute number so the way i would report it is that the gas results that we see on those particular test cases for modex make it one of the slowest if not the slowest operation after repricing and it's much slower than other precompiles yeah well the problem with non absolute values as even worse uh as martin mentioned they use sha-256 which is elsa as a result of measurements for 266 eep is quite different on different platforms and implementations um and even now if we if we continue to use this recover as something like a baseline uh and we assume that everyone uses t library first of all you can compile it differently to get quite different performance if you really want second with recent optimization since there and expiry of dependent on multi-fast multiplication uh you will get a bomb points there like in a factor of 30 at list if you try to estimate the gas price as a gas per second constant based just on c implementation of easy recover so i would say the absolute constant is on the way here based purely on the frequency for such operations yeah well i disagree and the platform of course i i mean i'm i'm a little bit inclined on maybe not an absolute number or some sort of range or some sort of minimum with alex because ultimately you know we have an inter-block time and we have a gas limit and we have a gas per second so like the the goal is to ensure that execution happens you know in a within a bounded amount of time right so it does seem to me like you you know if we're saying execution can take up to one second of the inner block time or two seconds or three seconds you know we should be able to translate that into a gas per second no i don't agree actually no what we should do is make sure that whatever the use i mean whatever runs on the evm whether it's a simple loop or it's uh crypt operations to a pre-compile if the miners have decided it's 50 million gas then it doesn't matter what what we execute it takes roughly the same amount of time whether it's a simple loop or if it pre-compiled or that's the like goal and if it takes too long time then they will have to lower the gas limit to make it faster again and as long as we have it balanced it's not like someone can some blocks will suddenly take a minute just because hey someone used the precompiled to do denial of service as long as it's balanced on like your everyday hardware whatever that is so i don't i don't think we should have this idealized uh reference hardware where we yeah i don't i don't think that works will work as well if you understand then to use a measurement because even if we try to do it with the current ones uh like there are two options one of them we measure each of those and calculate some gas per second constant based on each of those and then we have to ideally linearly reprice each of those up or down assuming that the initial formulas for gas are even correct and they are not for some functions so at least the baseline of some flexibility to 35 with turbo boost off to get some and it was basically what was done in fall 25266 like say that there is a constant on your computer benchmark everything and set a gas formula and it works forward perfectly but it doesn't work backward because you cannot say that your formula was correct in the first place especially if it's for variable length inputs i wanted to say something so yeah it's it's a very complex problem about what to do with these free compiles because yes i do see that when italic said to me on twitter that you know they're calibrated to 20 million gas per second i might first always like what why is this happening uh because what i think we should expect is that let's say that if they are now calibrated to whatever right 20 mega mega gas per second or lay over 30 whatever that number is and so that means that if we were to lift the gas price or the gas limit for any reason then one of the things we have to do is to raise the the cost of these operations again because otherwise they will be the denial of service vector so essentially the only reason why you could essentially lower the cost right now is because the bottleneck is elsewhere like say in state access if you remove the bottleneck from elsewhere so that you're kind of you can increase the gas limit then most probably this the pre-compiles will become the bottom the next bottleneck that you would need to remove if you want to the system to to grow and then i think we either have to be comfortable with the idea of raising them up again after we've lowered them which shouldn't be as surprising for people or we should say if that is the not desirable we should look at the um let's say that the the reducing the cost of operation is not the only way to make it relatively cheaper the other way to make it relatively cheaper is to increase the gas limit so we should look at it both from both perspective not just from the sort of single perspective yeah yeah generally agree that we should be looking at what the current bottleneck is and whenever we create a gas price repricing that introduces a new bottleneck then it's potentially a problem so what i'm just suggesting is that after repricing the modex with the current library in a inanimate becomes a bottom line so the repricing would make it worse um which means that we just have to think whether we can look for a different library here we need to have a library to to use that would be with proper licensing so just because we're kind of spending a fair amount of time on this is it worth kind of time boxing or moving the conversation somewhere else uh let's move forward okay so nethermine you'll look at a different library um and and i think it's worth having the conversation around like what's the right benchmarks uh offline so i thought of this call um yeah i mean maybe one question for tomos you know in terms of yolo yellow v3 you know do you think that uh you could run forward with 2565 using the current library for now just to get the cross-client tests of eip2565 i mean since we're changing only pricing there's like almost no benefit in uh doing the cross-client testing everything will be covered probably by the consensus tests it's not the particular type of vip that benefits so much from the cross client testnet it's no problem to edit but uh it sounds more like pushing into the test net with a hope that it would be there rather than just benefiting from from testing it i think it's relatively easy one to include an important one and i think what we should do and you make it more likely to be included is just suggest one library uh senior signals plus library that can be compiled and added and it should be super simple we don't use this big integer library the native one you never mind anywhere else because for all the 32 byte operations uh we we have now a separate uin256 library so this is the only place because here we can have arbitrary length of numbers okay great yeah we can do that okay um and so yeah for yolo v3 i guess um we had a list last time again which had the 2537 2315 2929 which is yolo v2 and then added to that 2718 2930 um given that like only geth and bass you have done yolo v2 um and other clients are not doing it is it worth having a larger yellow v3 how the different client teams feel about that um is it worth are there other things we want to include in it yeah what are people's thoughts on that it's probably worth mentioning sorry go ahead go ahead thomas oh thanks sorry the 2935 because to answer your last question whether is there anything else that we want to add on tuesday there will be this presentation from me on 2935 uh so if if people will be interested and think to include it then this is the one that i want to propose but apart from that i uh i don't have strong opinions about yellow v3 v2 so in between the bezel gas and other projects yeah so one uh thing that the presentation thomas was talking about it's about people and we invite all the client team and people who have any questions on these particular proposals uh earlier we also did uh an episode for 2565. i'll share the link in the agenda for people to refer and for the next proposal the cat editors will make an announcement how we can join the call okay for yeah go ahead for yellow v3 just as a reminder this i don't know if this came up in all corners or one of the other media many meetings that we now have um yellow v3 appears has turned into pre-berlin and so i know the original intent that ever that we wanted for yolo was it's yolo doesn't matter what goes on here it doesn't mean it's going into berlin but that has changed just naturally to this is pre-berlin so if something doesn't make it into yolo v3 then it sounds like it probably won't make into berlin so keep that in mind for do we want of elo v3 and what will be in it that that seems to be the implicit kind of what's happening um yeah and i guess of yolo but that is how it's working yeah i guess that's worth digging into because especially based on like thomas is just commenting about 2565 if that's something that doesn't benefit from being as you know part of of a yellow network um i i assume we could still make it into burden um yeah i think it's a good example actually i believe that two five six five can make it to berlin without participating in the multi-client test net um it's just a matter of finding one more library not too difficult we just need to resolve this small problem and testing should be entirely encompassed in the consensus test and i guess the other option is we don't have a yellow v3 and we just you know come up with the final list for berlin in a couple weeks uh the people feel like that would be a better approach might be reasonable um because i know i see james press switches on the call and i know last time around you had some questions about uh was it 2539 uh your other bls curve i believe um and and the fact that it was quite similar to the one included so um yeah i i'm curious what like from someone who's a bit more like outside the process than just trying to get something in what what do you think would provide you with the best outcome oh you might be on mute james we can't hear you um show you is unmuted and yeah zoom just no sound coming out yeah um so would anyone oppose like not having a yolo v3 and just moving straight to to having a berlin test net list and that means that 2718 i think is the kind of change that definitely requires multi-client testing it can be in a separate uh eip specific testnet which i wanted to suggest to focus more on the ap specific testing okay and you're saying that that would be prior to having it that's part of the burden list right like we'd want to see it running on some sort of test net before we decide whether or not it's in yeah okay oh and james you're back yeah we can't hear you can't still no we can yes perfect okay um sorry i've been uh holding my tongue through the conversation a little bit and uh then was muted when i tried to talk so i i don't want to be just someone like outside this process that's trying to get something in i'd like to be sticking around long term and contributing uh so i'm gonna speak against my own interests a little bit here it feels like the uh every two weeks we move the goalposts back on yolo v2 and yolo v3 by two more weeks um so we last week decided that there would be a yellow v3 and that its eip list was set uh uh two weeks ago sorry and now we're kind of reopening that and questioning the decisions we made two weeks ago i would love to get some kind of like uh defined process around this um so that issues like whether uh you know me coming in as an outsider with an eip uh so that you know like issues like what eips get in and what the deadlines for those things are are like you know set and we can know those in advance so we don't end up with this kind of process mess every two weeks amen yeah this is kind of attention i strongly agree on that uh dano had put an eep forward i think a year ago that tried to address some of that the eip 1872 where we could kind of preset some dates in the future for when we would actually have the mainnet hard forks and that allows you to uh um you know go backwards and set deadlines for stuff um and i guess the reason why this process would burn in is maybe a bit flunky is it's the first time we've tried these yellow networks we didn't have a fixed date for burden so i agree it kind of leads to like growing and reducing the scope uh and and uh and kind of pushing things back if what people you know care about the most is uh just having things move forward then yeah i think it makes sense we keep yellow v3 as is um and then maybe we have one last like free berlin uh it wouldn't even need to be a test that i guess it would just be like running this state test so um the people feel like that would be a better approach so we do yellow v2 which is basically done you know in the next week start implementing yellow v3 which i suspect will take us uh another two-ish weeks um and maybe set like a final date for inclusion to berlin for stuff like 2565 to be resolved i think we were waiting for 29 29 being tested covered implemented in know the clients and this is me the main the layer of berlin i'm not so sure um for me i think 27 18 seems like big um is it going in in berlin 27-18 it's part of yolo v3 or whatever that's worth and so is 2930. and other changes i don't think it was planned for berlin is it now 2718 is it is sorry 2930 is depend on 27.

18 and there is a very strong belief that we should not do 2929 unless we also include 29.30 and so there's also a strong belief that we should include 29.29 so those three basically kind of come together as a package either we include all three or we don't include any of them is kind of the situation and so since 2929 is very strongly desired that's pushing all three of those into berlin that's causing berlin to delay while i wait for all three of those that's what i meant if we'll have 2929 implement it everywhere and agreed on it will practically mean that berlin is ready because whatever was required for 21.29 will be included as well yes think if you consider 2932 or 2929 to be dependent on 2930 then yes that is true and the thing is it's it's not from a technical perspective it's like from a ux perspective right 2930 allows yeah to not break or to keep accessing certain contracts yeah the the fear is for those that haven't been following along 29 30 we'll introduce access lists which will make it so it is possible to not have your contract completely inaccessible because of 2929 gas repricing because you'll be able to use access list to get those gas prices back down to where they were if you absolutely need to but it is not required by anyone to use them so the fear is if we do 29.29 without 2930 then there will be contracts maybe that are completely inaccessible because it's no too expensive to call them i think the 2929 is the only appeal at the moment with enough of the feel of urgency that that's why we delay everything else just to have 29 29 packaged properly and it ended up being slightly more difficult that we were planning as just raising gas prices now it's it's trying to solve a few more issues and it comes with other things do we think that there are any other eaps without 29.

29 that we really want to push before pushing 29.29 i don't think so right so this one is already included but uh i think that 2537 the bls cricopal was another pretty important one um even though we might not ship berlin prior to the deposit contract going live um deposits into eq will keep coming and i think there's a lot of value in being able to validate those deposits on chain just as a refresher the is are there people who still demand 29 30 in order for antoine go in i don't know if we actually know that this will break any contracts there's just a fear that it will and i personally i'm okay with breaking things but i know i'm much more aggressive than most people here so is that still desired do we still demand 29 30 if we're doing 29 29 so i think i believe that if we don't things will break and users will be very very upset with ethereum that's okay that's not for me though as long as there's someone here that really strongly believes 2930 should go in then i'm on board um i just wanted to very briefly raise that or like just raise the question how how confident are we that um there are indeed any any contracts that would there would be that would basically break um between 29 20 which one i i think i i i got the number wrong but but like because because i just think uh adding a new new transaction type with access lists i i think there are concerns around like the usability of access lists in general with like some use cases might might not blend themselves with like some static state access concerns there it to use which um exodus anyway and then obviously that is a rather large commitment to adding in your transaction type that then has to be like carried along more or less in in in to infinity and if it turns out that it will not ever really be used i i just i'm not necessarily against it i just basically want to make sure we we think it it's really necessary and that that's a trade-off we want to yeah so one thing that we could do now that i'm fairly certain that the implementation is in line with specification since i've matched it with visu i can really do the same analysis that i did on gurley that is take a couple of blocks re-run the transactions on 29 29 rules and see if they start failing and if they start failing see if they also would have failed if more gas had been given externally i'm sure i will find a couple that will still fail um so yeah such an analysis i can do it's quite intense i mean it's a lot of work to weed out the some of the results but if yeah if you want some extra clarity if these cases are actual um i can see if i can find a couple of such cases although if i don't find them we won't know that they don't exist because you know i can't do it for the entire um entire chain how unreasonable is it to how unreasonable is it to just run the entire blockchain just set the gas like arbitrarily set the gas limit for per block very high and run the entire chain see if there is any single transaction in the last six years or whatever that has ever used more than 10 million gas with the new guest pricing yeah like none of the clients have an easy way to do that yeah well i out of the way remember like yeah on the block yeah so you can see if we don't have a way to distribute the whole gas prices no well it would basically be like full thinking uh but a lot slower yeah it's weak somewhere does do any other clients have an easy way to do that just out of curiosity like that would be a good ideal test we do have the way to do it um and it's uh you know because i do actually do do the sports for cold traces and at the moment i think it would run for about two days or something to do something like that uh yeah there is a possibility to do that um although i wanted to actually suggest the potential alternative to eip 90 29 29 because as a lot of people know that i'm still mildly opposed to that um so yeah but i was gonna just ask because we started to look at this more specifically a couple of weeks ago and one thing we did is that we looked at the using some kind of filtering uh bloom filters for example and we were able to successfully defend against the the most potent attacks that were that basically the eip 2929 designed to to protect against so obviously those so this filtering you need some nuances but essentially it's the way to do it without changing the rules um although there are still attacks that are hitting not the absent data but they're hitting the existing data but they're these attacks are a bit harder to mount and they're probably not gonna you know you cannot sustain them for a long time but we are looking into those as well so i still think that the ip99 2929 is is too complex for um for what it needs to do i have the same feeling actually and the plan actually and actually i'm going to um we will share because we're doing an analysis now on different type of filtering we've basically what we have already done is which works so we've done the bloom filter very simple implementation of bloom filter with i mean we took uh let's say half a gigabyte one filter and also a quarter gigabyte boom server with 15 functions and so with the half a gig so that's only for accounts and so the half a gigabyte boom filter is able to protect perfectly from the uh from the so basically it has zero false positive when you try to read the non-existent accounts if you reduce it to let's say a quarter gigabyte then the false positive rate is something like 0.01 or something like this and then we're also going to look at two other filters like cuckoo filters and stuff like this because they allow deletions but generally i think we might be able to find a way to kind of at least uh protect against those attacks and move on to the next level which is the kind of more expensive attacks but it could still be executed um and as i said that it doesn't require the change of rules and doesn't require this basically i think the ip is becoming a bit too complex from my point of view yeah i mean the way with what you need to do with bloom filters is more or less the same we need to do with a flat db that you need a layer of bloom filters that goes back as far as you would want to be able to handle the reorg um it can be done um well basically with the um with the cuckoo filter you actually can handle reorgs pretty well because you're you can delete from it as well as insert into it so with the bloom filter the problem is that you can't delete stuff from it so we have basically two minutes to go sorry to kind of jump in here i'm not sure what's like the best next step here because yes we do have the lesser yellow v3 and yolo v2 but is it even worth implementing all this stuff if there's a high chance that we don't uh end up doing it uh i'm curious what yeah what people feel is like the best next step uh for 29.29 and then the bundle of 27 18 and 29 30. is that worth also just discussing async go ahead sorry no sorry um so i was just kind of saying all that i'm still a pro 2929 and 2930.

and one of the things i think missing from the bloom filter approach is we would then have to integrate that to the sync or everyone would have to sync from zero to share that data around oh no that's not necessary because you're you don't have to sink from zero to to construct the filter you need to just simply iterate through the state and build the build it initially so uh that's that that could be done or you can even like uh what you can do as well is that you can download the the pre well not pre-made but because because actually everybody's balloon filter has to be slightly different so that they cannot be attacked [Music] but then we're adding an extra complexity that you have to mess with your sync system and then you're gonna have to salt your blue filter seeds so it's not i don't think it's any simpler than 29.29 well yeah we could approach more complex okay so i guess we should probably also just continue that conversation on the core devs chat i know this is yeah not kind of a great outcome in terms of clarity of process uh but it feels like uh it's it's probably worse to push like a yellow v3 forward if we don't have clarity on that especially given that the implementation on yellow v2 is is not fully done um hopefully we can agree kind of maybe async on what the yellow v3 spec would look like um does that make sense for everybody and i don't think that's twenty nine sorry 29 29 if we know what happens with it we will know what happens to berlin and which other eips will come in that's like everything else is just dependent on this one this one was considered critical yeah it got a bit more complex it has some dependencies it doesn't have an agreement around it and uh everything for berlin and whether it's yellow v2 v3 if we want to bundle the aps together everything collapses around 2929 so why do we do test nets which will be separate for each eip to allow people who wait for those eips to actually push them forward because many of them are totally independent from 2929 or we bundle everything for one big berlin and we'll be delighted by two or three months so what are you suggesting i suggest to stop binding the eips or apes into into yellow v2 v3 allow people to actually push for uh if specific test nets like that will be able to show that two three clients can sink on particular e for example two seven eighteen or two five six five or like this one doesn't even require testnet but but things like whatever other people are suggesting because they're waiting for berlin to be defined like here james comes over and says there is something that is potentially important for them and potentially useful for the network and it's totally not dependent on 2929 but they are locked there they're waiting for that and i feel paralyzed so we need to have a path for them to uh to if they want to spend time and provide the the working prototype that shows this is how we can implement this change and all the clients to agree uh so i have a proposal for this and and it's in a way it's iterating over two great things that we were discussing in the last year one was the eep specific upgrades which is fine but it only gets much much stronger with the ips specific testers that we started introducing recently uh with eip-1559 i think by binding these two things together we can show exact path for any external teams how they can deliver the fully tested described and analyzed if specification that can be easily pushed all the way to mainnet if everyone agrees that it's beneficial for the network for particular use cases or an improvement and stop bundling things and making them delay just because some things are not agreeable yeah and i think james actually your your team was already working on a test net for eip 2539 right oh yeah uh it's been running for a couple weeks we've been buzzing the uh implementations against each other um yeah so maybe again we won't resolve this three minutes over the call but james if you can share that test net uh on the core devs getter chat that would be great uh so people can have a look at it um yeah uh yeah sorry i said that this for this gator chat still uh so on the the the discord uh that would be good and then the other thing that was on the agenda which we we can maybe very quickly cover is uh we were talking on discord uh this yesterday i think about the fact that uh most clients seem to be working on a sort of flat database approach um uh so get a snapshot at bc we have bonsai trees nethermine is working on on something as well and turboget is obviously architected like that from the start um and because we're all working on kind of different flavors of it it might make sense to set up a call to just uh discuss that and share notes on it um would people be up for that generally and that we can maybe find a time on the on the cordex chat if that makes sense yep okay cool i'll i'll i'll post something on the courthouse chat right after this so we can we can coordinate the time any final things that can be covered in less than a minute before we jump off okay then uh thanks everybody see you thanks everyone just come bye-bye