Ethereum Core Devs Meeting #16 [5/19/17]

I made a couple of suggestions so B basically what we want to have is we want we want it to be possible to figure out what the gas cost of the whole thing is in O in O of one time and in O of one memory reads so the suggestion I had for modex was that we would take the the bit length or sorry the bite we would take the the bite length then we would look at just the first bite and if the first bite has is a um has less than eight bits then we would kind of appropriately discount it so like one example would be that if you have three bytes and the first bite is 255 then the exponent liks would be counted as 24 if it's three bytes and the first bite is let's say three then the bite length would be counted as 18 now if you have let's say 10 bytes and all of them are zero bytes except for the last then the bite length would still be counted as a 9 time 8 or 72 because that's just the way the algorithm works but you can argue basically why the hell are you throwing in a value with pre with a leading zero bytes in the first place so that that basically is all I had to say on all those gas costs [Applause] so what would be the step next step to actually deter I think so to determine on the otic curve side I'd say and possibly just a I mean agree on preliminary gas costs for the purpose uh for the purposes of testing and then maybe or or perhaps all the other thing we could do is just have I like actually no I think the Practical thing to do is that we agree on some preliminary gas cost for testing purposes then we get to the point where we're passing the tests and then we actually see how many milliseconds it take C++ go and parody to run through some of the test uh some of the test cases and we uh go from there to figure out what the final values are at least that's one approach um on the modex side I think we would need to first of all figure out in principle what is the right like whether or not we're going for this bit length approach and if so what what approach are we taking in principle and then the next step would be of finalizing a very precise definition so I did some uh performance measurements on uh the pairing function in C++ and uh it resulted in roughly 60,000 gas times the number of uh pairs plus 40,000 if we target 20,000 gas per millisecond I'm not sure if that Target is correct wait okay um so my next question is though is what numbers do a g and parody get so I I would prefer to um avoid final finalizing the gas cost until we have uh enough numbers from all the clients to make to make sure that we're creating a reasonable guess per second floor on all of them yeah we should wait with setting the constants but it would be good to finalize that algorithm for modx pretty early guess yes so we'll do the same Benchmark by next meeting yeah so maybe all three all three sides do a benchmark and also all three so a g c Bus Plus and parody should also figure out what uh what FL makes sense so I will I think like the most principl way to figure this out would be to just basically see what is what is the most uh what is the floor now so I guess that for elliptic curve I mean in general elliptic curve addition should be constant I guess and multiplication also depend on the size of the of the scalar right um I I would argue that there's not much benefit in making multiplication depends on the size of the scaler because pretty much all multiplications I've ever encountered in cryptography multipli by random 256bit numbers and so I don't think we really lose much by just going straight to the worst case right this point yeah I mean there's some use in okay you can kind of abuse multiplication to compute the inverse or something like that but that would be a large scaler anyway so yeah so maybe we'll put uh the the numbers that Christian have for now uh to like start with something and to actually do some tests and the next meeting or before the next meeting uh if if we get more benchmarks we can adjust that but I would go with the numbers that we have so far last ex last exam okay that's perhaps just sorry um is 20,000 gas per millisecond a reasonable number or what do the other thing others think um so I recall that we arrived at 20 at 20,000 gas per millisecond because we looked at basically what are the what are the most most inefficient other op codes that we had and we got something like uh 20 million like 15 to 20 million gas per second in the worst case you is that correct uh so I think I did a comparison with with other pre-compiled contracts and uh internally with uh malm mod I think yes so maybe yeah in general I think 20 million gas per second is definitely fine yeah so I guess the the other bench it would be good if the other benchmarks could also uh uh yeah check that with other pre-compiled contracts um so what what thoughts do people have on them on the modex issue I I have a comment on that one because um if anyone can hear me yes um the idea was there to accommodate the the fact that we have 256bit uh memory stores so crafting the the request is kind of optimized for 2056 bit and but the content might be much less so what if we only can the topmost 256 bit and assume if say the exponent is like a, bits we assume that the bottom 700 x bits must be set and we only consider top 256 so then it's only you know the exposure is limited so basically the exact proposal I have except that instead of looking at one the top one bite we look at the top 32 bytes um yeah yep um I'm okay with that I mean this is a this is a constant effort and can be priced in with the yeah Baseline yes yes so yeah vitalic do you see what Hudson is writing in the yes let Valic let vitalic know to proceed when the next item when done with gas yes so basically the other concern I have is that I wanted to just basically like kind of accentuate the facts that with the facts that uh the revert op code can return things we actually like basically it was Joseph for BTC relay pointed out that we actually are making a major economic change which uh or at least a a significant economic change which uh in some ways does break BTC relay's current model and the change basically the problem is that BTC relay worked and potentially a lot of there were other applications might also work by charging some very small amount in exchange for reading some uh some value from the contract State and so the idea is that this is like one way to do a paid Oracle and with the revert op code what you can do is you can basically call to a contract then in in from a from the contract make a call to BDC relay or whatever other thing get the response then in the outer contract you would hit use the revert op code and you would revert the response and this way the payment that you would make that you would make for in exchange for the response would be reverted but you would still get the data out and so I Bas this is something that's not not possible to do easily now so like right now basically the easiest way to kind of cheat these contracts out of data is by uh basically asking for ask for Merle proof of the state and this is arguably sub much more much more expensive whereas here all we have is just basically a tower of two calls and that's and that's all he needs to circumvent any any kind of pay wall so I can uh add to that a bit um go ahead yeah we discussed this a few weeks ago and uh so that's why I opened that ticket against PTC relay but the thing is that um even without return data you can always do the same thing with the revert and return one bit at a time so you can do an oracle you can quer BTC relay is this header valid is this transaction valid get it back and if you don't if all you want is on so how EXA how exactly does the one bit Oracle work uh I think I oh I see you would you would revert and you would use the amount of gas that you revert with I would either revert or I would not revert and I well but if you don't but if you don't revert them the payment goes through yeah but you can or you can revert in a different place um right but if you revert any a different I see so you could have like a tower okay and basically get yeah so you can you can extract one bit of information that way and you can do it uh yeah so one way to do it today is is the magic with the you mentioned another way is to actually use uh throw you can do it the same way but it's much more complicated because especially for BTC relay it's not constant how much it costs uh so it will be easier to do that with something which is constant there's a sample code in the chat for BTC relay yeah right well r doesn't cutting out sorry can anyone make sense Andre I think you're cutting out yeah Andre I think your audio messed up so so I've never found the paying for oracles case particularly compelling simply because it is so it is entirely plausible to just fetch the data from the state and and create Merle proof so that's only difficult so long as nobody's put up a mirle Oracle um I've always I think the if the arguments would be then they have to charge AR so the argument would be I think that even though a payment of 25 cents might not be defensible a payment of let's say one cent still would be defensible because the cost of either of these attacks would still go higher than one cent and one cent might be all that you need in order to pay for the transaction fees of uh maintaining one of these systems I just I don't think that it's a property that we should strive particularly hard to protect because uh doing so disables other useful use cases and ultimately once the data is posted to a public blockchain relying on artificial barriers in the VM to prevent people from reading it just seems like it seems like the wrong approach to take okay that's fair um if no if other people agree I'm fine with it a question so essentially right now you can trick the BTC relay by making a throw and making a call into your same um verification and then uh uh checking the result of the throw to see if it's verified or not and avoiding the payment right now yes but you basically have to know how much gas BTC relay will consume and you would have to uh to set a low amount low enough amount of gas um to to be able to distinguish between the natural failure and your explicit throw so it's difficult to do today I see so I was reading the the the example by Alex to try and understand how it works and now I see why it does this gas calculation there all right thanks hey guys can you hear me now I think I fixed my audio yes y oh excellent yay um okay so uh was that it for that um item yes okay what was decision that go ahead what was the decision on this item that uh we just don't want to put any division barriers yeah I think so that's what it seemed like uh was there anyone who was like heavily opposed or would it have an alternative okay cool um and that covered that covered the revert op code correct metallic I was fixing my audio so only caught half of that yeah I think we're going ahead with revert as is great all right um so the next one is yoichi uh talking about EIP 96 um so go ahead Yi yeah it's toity um in EIP 96 uh 256 blocks into Metropolis the block hat instruction can change its internal working and then the same EIP also says the gas cost for Block cash should change from 20 to 800 or something my question is if this gas cost change should happen at the first block of the Metropolis or 256 blocks after that um hold on should the gas price okay um there's a link in the agenda that actually discusses it and points out in the code I believe where where he's talking about if anyone needs to look at that yeah I'm looking at this now so I think we did agree in one of the previous calls that we would uh to make a change to EIP 96 so that to restrict it so that technically you could argue that one way to implement not EIP uh implemented would be to not change the behavior of the blash op Cod at all um so did the does the gas cost increase um oh I see him yeah at I'm checking in previous meeting notes right now to see if uh this was discussed but but I definitely remember that too so I did we I think we said that I I want to look at the notes before I make any comments I'm pretty positive we said that block HH would continue to return only6 most recent hashes and if you wanted older ones you'd have to call the new Oracle contract and if that's the case yeah if that's the case it seems like we could change that back so the price won't change and the um you know the functionality won't change yes that's a reasonable choice and shall we go along that so the gas cost increas is only uh 256 blocks after Metropolis starts well I'm suggesting that we needn't increase the gas cost at all because it will continue to operate as it used to um and if you want to exess Old the stuff you have to call the arle contract yes yes uh that that that's very just so one thing one thing i' one thing I'd suggest is uh it just as an as an experiment see if we can kind of like basically I want to see how long would it would it take to do a million basically a million rounds of uh calling the uh delegate calling the block cash contract over and over again just to see that if someone decides to decides to implement a kind of historyfree uh implementation then you know would they have would they incur any you know like extra difficulty is there yeah fair enough is this 96 we're talking about 96 yeah okay I'm basically what I'm what I'm trying to make it possible to do is I'm trying to make it POS I'm trying to uh make it possible to make an implementation of uh the of the protocol that does not depend on any kind of History access that's done in the state and that doesn't require any kind of ADD additional weird data weird data structures in which case implementing the block hash op code would be would be basically just either calling that contract or just reading it reading its storage once and now we could of course argue that those particular St storage keys are going to end up being in the cache so it's not it's it's not like this is a particularly serious issue but I'm basically trying to wonder if 20 if a gas is low enough for that kind of implementation or whether something slightly higher would make sense I would propose to increase the gas cost and those clients which can use the old implementation they might be saving time by that H but we should assume that every new client would implement it through the Oracle that's my proposal okay if we if we increase the guas cost can we just do it on the Metropolis block instead of 26 blocks after yeah I think that's more consistent okay with all the cost of changes yes no yep we didn't I don't have notes uh talking about this specific part of 96 but I posted the ones I did find um if anyone wants to read those to kind of see the what what we talked about previously on that but it sounds like we came to a res resolution on that uh yes I think I got an answer on my question so I ask to change his text to clarify this point to clarify that the gas cost has increased to uh I'm not asking about the amount I'm asking about which block shall the cost change um the metrop block then okay okay yes and that's enough that's I have I have one question about uh the CIP uh so if we are going to deploy a bite code to that contact why don't we charge the actually the C cost of executing it um so there's actually about three different ways to implement this one of them is to execute the G one of is to execute the code one of them is to read that particular account storage um I also argue that a discount might be prudent because if someone tries to call this contract a whole bunch of times then it'll just end up being in the cash on the other hand though I could see how it's How how it would be kind of a very principle upper bounds to calculate the exact Bost and charge that so yeah I plan to do it but didn't have time so far okay personally I'm not overly worried about a conservative price because I don't expect many contracts to call it and those that do probably won't call it much yeah and I think like 800 will be fine because like it's still it's basically one call anyway and know I can't imagine there'll being applications that'll be willing to that'll be afraid of pay of paying a lot for block hashes and but that's uh yeah like like B Bally I don't really expect there to be applications that needs to kind of spam block hash reads enough for for even if a substantial increase to be a a substantial issue for them yeah my S exactly okay point is also about the same EIP uh the next point is about the nons of the system account the system account is after Metropolis suppose for this block has contract in the beginning of every block so this INR so notice that it is a call and not a transaction right so transactions increment nonsense calls don't a call transaction would increment a nons and a call from the evbm would not increment the nons so I felt ambigious correct so by call I mean a call I mean a call from the evm and I that's how I usually use the word call but I'm happy to clarify that so the nons would not be incremented correct so the code pathway that you should use to implement cp96 should be the same one that you would use in like the callop code okay cool yeah Andre and I had some disagreement about this so it's great have an answer uh can we move to the next item that's a that's a different EIP yes okay sounds good the next point is about e 98 the intermediate State removal uh when you read the if text literally the change starts one block after the Metropolis hard Fork block but uh I guess it's typo so I guess that's change start at okay cool and that was it yes it should be greater than or equal to I can update that right now okay cool uh my last point is actually well maybe not pity it's about the 21 return data copy when return data copy want to copy more than returned what should happen um currently the body of the text says zeros that's the same as all data copy but Nick suggests exceptional holds um I think both are reasonable uh I think at least we should GA opinions here and try to reach a consensus okay um my my own view as I've over stated in the is that um reading past the end of an array is almost always in error and therefore we should treat it as such um and that silently returning zeros is likely to lead to under bugs and I know there's an argument for consistency but I think we should fix the issue where we can rather than introducing it into new OP codes okay yeah I don't see a real technical issue with Nick's [Music] suggestion uh apart from that uh we will have two very similar op codes that behave differently um more weate in implementation and testing and remember in DM to spe but that's just mental costs all the other address spes are well defined to be valid for all addresses and yeah should should be the same for consistency but I think as I as I said I I think consistency is a weaker argument than this is the wrong thing to do like should be consistently wrong if we can avoid itop also then because uh there is at least one contract currently on the blockchain that will fail if code copy sorry no if called dat a copy um throws an exception because it deliberately reads four bytes past the end oh okay so I think I commented on the issue but I can't find the comment anymore so it might be lost altogether um Nick so uh what is the what is the problem we're solving here it is the problem of incorrect encoded input data right um well it's it's anything where it tries to read data that doesn't exist silently returning zero is in my mind extremely likely to lead to undetected errors and uh very unlikely to be the in Behavior but if if the return data is uh fully specified to always be uh virtually infinite and contains zeros then what is the error we're dealing with but the the actual return data isn't infinite so like the the contract that returned the data specified the return link and if you then try and read past the length that was specified by the the returning contract that should be an error because the data doesn't exist I mean so what I want to say is that when we compare this to the the error to that that sparked this discussion and the error was incorrectly encoded uh user input data then uh we have a different situation here because the data we're dealing with here is usually uh created by um yeah we we don't have wa sorry errors here what error spark the discussion I I'm I'm arguing this in in a vacuum I think purely that reading past the end of an array should be an error because the the data should be undefined and um not just silently filled with zeros I can't think of a single situation where filling it with zeros is a good thing I want to ask Greg uh what this means for even 1.5 because in even 1.5 it should be easy to detect potential exceptional for fors before executing the contract by just scanning the code and I think introducing a new kind of exceptional hold might make this more difficult rig oh trying to find the unmute button I I agree with Nick that it's totally wrong that that we treat it that way I've been told it made the description mathematically simpler I don't know if you have an opinion on that um I also agree I wouldn't want to extend the mistake Beyond The Domain it's currently in and yes if we insist that um that all code is going to be validated before it's run we can we can catch things like this um much more easily and I think I think Martin's here I believe that would be true for WM also but Greg wouldn't that be a a new kind of runtime exception condition that cannot be validated before actually evaluating it it didn't sound like it but I could well be misunderstanding um I don't think you want to have me take time to reread the EP and think about it more at this very second so because uh the the memory offsets are not constant and known to the validator of the contract uh you cannot check it uh before deploying the contract there you have the the the indexes are are Dynamic so you can PR compute them on time okay but but wait a second this this discussion is uh not relevant because call data copy always copies to memory and there we anyway have a dynamic gas condition so whether we run out of gas because we run out of gas because we have to enlarge memory or because we access uh return data Beyond its length that doesn't matter much does it we only have one throw instruction it has no data we don't distinguish why it throws and you also uh I assume don't uh you don't think you can statically determine whether that throw instruction is reachable or not you just assume that if there is one that it could potentially strong but we can determine whether any instruction is reach to really what if the condition is uh if this uh piece of uh B code evaluates the true then throw oh that sense of reachability yeah so I mean the same would seem to apply if for called out of the copy you can't statically determine in all cases whether it can ever happen but you can you can if it's impossible you can say so for certain but if it's possible you just have to say maybe exactly and I think the same would go for call that copy py into the array so just to clarify uh when anyone says call data copy we that person most likely says return means return copy I also made the mistake before so yeah now I hear people with three different opinions and it's not reasonable to except expect uh consensus in this call so uh shall we agree to continue this discussion on the place linked from the agenda so actually I'm I'm in different is there something strongly for uh yeah zero was arguing for consistency between different instructions yeah AR do you want to elaborate on that well yeah my point is that it just makes a simple definition okay yeah I I think that there are more people in favor of explicitly instead of filling the out of- bounds array or out of bounds air with zeros to actually just not let it happen and throw in air is what I it sounded like the majority of people were for that am I wrong that was the impression I got I I'd be curious what vitalic thinks as well I'm fine either way personally although one thing I will point out is that I remember there was um resistance to doing things like uh like so like one of the reasons why for example the division op code in the evm returns zero when you divide by zero instead of throwing is that we did not like at least some of us did not like the idea that you can have a parameter dependent throwing and like basically they like the idea that um the E that op code should only throw because of like actual out of gas and that any anything that happens after the out of gas step it should is uh should like basically not throw under any circumstances and throwing on bad return call data would kind of conflict with that I think that that confuses developers or at least when I'm developing like everyone I've talked to the thing they have the most problems with are the fact that throws don't act as a lot of modern programming languages would act when something is thrown it's not always just one single error it's usually gives a little more indication so if there's any interest in providing more information on throws in the future I think this would be a good first step personally well I think revert will do that to some degree um at least the throws generated by code rather than by the VM okay right so it sounds like we're we're pretty much mostly in consensus that um the behavior should be that it would explicitly threat an error rather than uh fill with zeros am I accurate on that I guess so I guess all right yeah yoichi uh is that in that point of discussion is there any other comments yes I asked exactly this point perfect okay um the next one is yoichi he has a proposal for freezing eips uh for to allow for testing for Metropolis actually hold on just to go back on just to go back on that one point um one thing I realized is that back um back when we were discussing EIP 5 versus E8 versus return data copy and so forth I recall one of the one other proposal being B so at the the original problem that we were trying to solve is basically how do you deal with variable size return data and I remember one of the proposals being that you would so right now the way this works is that before making the call you would expand the memory for to cover the full range of the input and the full range of the output and one of the proposals was to switch to the full range of the input um so expanding the full range of the input at the start and then expanding to the output but only expanding to as much output as as was actually provided after the call was made and this was a in some ways a a very nice a nice solution except that I remember that it ended up falling out of favor precisely because it introduced this this uh idea that the uh an operation inside the VM might throw because of something because of the actual execution of the operation and not just because of because of initial gas computation issues and so if we're willing to abandon that principle perhaps we'd be willing to go right back to eap5 and E8 but would you the there's still a big difference here so the uh accessing return data Beyond its length can be I mean the there is there are even the other core proposal there the error condition would only be checked after the call returned it which is a much later point in time than uh the point where you read the inputs for a return data so it's still um so I guess though that the point is from just from the point of view from the point of view of kind of making a software abstraction I think the argument in favor of kind of Purity is that you want to be able to break down every single VM execution into two parts where one part just does gas consumption and the other part does just um like ex execution and only the first part can throw but that's I mean if I do a m load at a very high memory point or if I do a call data copy with a with a high end point that is the same thing both depends on values on the stack oh okay I can yeah I can see that um so oh do you have any other comments on that metallic no that was the only comments I had okay um yeah um okay so I think it still stands that because some opinions have shifted or become less strong on the fact uh that we can you know throw for things other than just being out of gas airs that we can um we that that is still the or the conclusion is still that uh on that EIP um the behavior would be throwing an air rather than uh filling with zeros I guess yeah okay cool I think I I think I followed all that um the next uh thing is yoichi proposal to freeze eips to allow for testing um Dimitri Martin wend and I had a call on Monday discussing the testing for Metropolis there was an agenda or uh there was a topic how how much of the tests have we covered we couldn't answer because the Eeps are still changing and some of the look stable but there's no indication that these stable looking e will not change so we don't know how many of theps will not change and we don't know how many test cases are ready so my proposal is to introduce a notion of freezing a KNE for metropolis and after KN is Frozen for Metropolis basically it cannot change until Metropolis uh if there is a s problem deeps can be dropped from Metropolis or if the fix is very easy and everybody says well we have enough time to test this Um this can this change can be made but this has to go through uh unanimous everybody agrees vote in the P meeting and my question now at this point is shall we should I try to write an meta about this process or shall we there's an opinion if there is an opinion shall we shall stay away from these kinds of formalities I like the rigidity of your idea um and the fact that it will allow for things to be a little more clear in the E repository which is still pretty messy um the the people maintaining it have just been busy with other things so I think that um one thing is to yeah a meta um and this actually goes back to what um Alex Bazi put as a meta e it hasn't been uh accepted yet but it's just basically a file that says here's the Eeps and Metropolis and along with that we can amend that to have a column that states when an EP has been finalized or um no more changes will be accepted to that EP uh except in the event like you said of an um exua circumstance uh potentially where there would be a bug found or maybe there's an EP with a small or maybe an un like a a consequence that you discover while testing that it relies on a different EP uh that's been finalized so I I think that that's fine uh we should kind of uh you know be flexible as we move along uh in saying that you know depending on the size of it just try to have a lot more open communication between the dev teams when there is an issue to immediately get feedback so we don't have to rely on the actual audio all core Dev call since it only happens every two weeks but otherwise I I think it's a great plan I see I see and addex has already made a comment in the group group chat so I will try to write up something and show it to Alex hson and anybody interested and in the next meeting I'm coming with some more detailed draft Yeah I think that'd be good and people can also close their Eeps um their PRS or whatever or put a comments saying I'm done and then the editors will go in and um you know approve it add it to the repository and then actually close the pr and any you know issues related to that and only reopen if necessary um so are there any other comments um on this plan anybody opposed or have an idea about it looks fine to me great all right awesome uh the next item is any subtleties we need to work out with regards Metropolis um does anyone have anything on their mind as far as a subtlety or something that may have not may have not been discussed or uh we need to discuss um I think the talic you wrote that as a as a topic did you have anything in mind I H didn't have anything as actually I think I might have had well there's the one that I've been talking about for a while but that we uh I mean I guess technically it's part of uh I think it might be part of 86 that um uh creating a contract fails if it already has if the the destination address already has code but I was more thinking in mind like smaller things that have to do with like uh the way that nonring works or gas calculation or like other boring details of that sort that sounds like something yeah that sounds like it would be need to be defined in the EP and as imp ation goes through I feel like people would ask those questions but yeah everyone should feel free to voice those concerns in both the Eeps and the allord dev chats I know yoichi's been good about that when he's been applying them to the yellow paper okay so yeah if there if no one had anything for any quote subtleties um yeah well one thing is the point that faan raised about the origin to this new transactions is that something we need to talk about because the issue he raised is that origin will basically be totally useless for the new types of transactions and his proposal was to use uh the verifier contract as origin so asking more generally is there a use for TX origin at some point it was banned because people deemed it being insecure so yeah people haven't really used it much in a while doesn't that just mean uh the transaction where it originated from even if it hops through multiple other accounts the account that created the actual transaction so I think the original use motivating use case was it was so that contracts could fund transaction centers for gas payment but I would say with EIP ep6 that's not really necessary because we can open up ways where any contracts down the chain could just pay for gas directly so there isn't a need to actually take it out of the system it would just be pretty much useless yeah pretty much I I think it's a bit of a meus personally and I hope uh solidity removes it from access to it from future version just to bring accidentally treating it as something useful uh so so Martin did that somewhat answer your question yeah okay great um any other subtleties okay great um so as far as um the time estimates and testing and release let's first just kind of go through the teams and see where everybody's at um uh we'll start with yichi since he's been doing some of the yellow paper stuff and I think what we've talked about today is kind of outlined where you're at basic yeah but I'm supposed to speak now no maybe do you hear us yeah ah okay we thought we were dropped from the internet um the yellow paper so I have created an A P PR request for every if considered for Metropolis I believe it they are mostly up to date this the and yeah some predictions made about well that that was agreed today um that's the Yow paper status I've been reading the Metropolis changes in cppm GM and parity and I'm halfway through it okay great I'm back on okay cool and then we'll go to um gu if there's someone here I think maybe pav or okay I'm back so um okay that was uh yeah python I think that's everybody um C++ team or um Demetri testing if yall have updates we got actually walking and um we implemented the lips lips snars and um the test are ready and GUI just now test that wait um what what were you just saying I'm saying I'm saying that snar test and are working and um you could check it against python okay great um have you checked python test against the C++ yet not yet um maybe anything stopping you from doing that um currently Yi has bu crunch he could do that well okay then I then I will do that okay what were you saying yichi uh there's no block because that was what I was trying to say okay great um and was there anything else uh either yoichi or Demitri on the testing end um for I think I saw a new e about standardizing the way that test are formatted through Json is that correct oh yeah you have a consensus issue is Jason files format and how integers um encoded in Json files for tests so someone from python team um insists that integers should not be prefixed by zero leading zeros and um and prob think that that's nonsense to prefix to add zerox prefix to contract hashes and other hashes uh so you have quite often issue there okay and you said that was between the python Json files that are submitted this how how the test to reads the tests okays not have a format for Json test files which everyone agrees okay um well what let's do this the eep's out there so um if anybody here who has who does submit those kind of test files could go in and comment and uh if no one if or if not enough people comment on it we can pull in some people who submit and see if we can come to consensus on that um uh hopefully soon so we can get those standardized for when we're submitting more for Metropolis sound good well yep okay um the next item let's see oh actually yeah was that it for testing I'm currently working on stud call test and it will take a while I see that static call EAP is the most static one so there will be lots of test coming from okay sounds good um so the next thing would be time estimates for testing and release um so I think because of the price spike we're given a little bit more time and it's looking like because of the um the there's a lot more testing that has to go on because of so many Eeps we might need to look to more of a July release is my opinion um balic I know you'd been thinking on that what's what's your opinion yeah so I can just run the um uh age script again um with the latest numbers let me just do that right now just for for the fun of it um okay um hold Dam Ice Age uh so the current difficulty has gone up to 428 but the block time has gone up to 15.73 the time stamp has gone up to 14952 and the block number has gone up to 373 3126 okay so if we want to maintain a 20 second block uh keep the block time under 20 seconds then our deadline is July 14th and if we want to keep the uh block time under 30 seconds then our deadline is September 12th okay that gives us a good amount of time um so is anyone willing to and I I think it sounds like from until we freeze these Eeps we're not going to have a great estimate on testing would that be accurate uh yoichi and Demitri at least and once I start working on particular a um I sometimes find um issues when making tests and I need clarification on some EIP so you see the questions about EIP they might pop up when we start working on tests okay yeah the feeling I'm getting is late June would be the absolute earliest for a release and that's if a lot of things go really well with testing um does anyone have any other opinions that's again just my opinion based on just kind of seeing an overview of all of this and they won't make it in July okay you're saying it should be later than July yes okay sounds good so um what is the time you want to reserve for testing on the test net so the the distance between test net hot fork and Main net hot Fork H get [Music] your oh metalic you cut out try talking again can another people here I can hear now or at least I thought I could can can you hear me now metallic yes I could hear you okay you're cutting out off and on but just try talking again I think we can hear you now um hold on internet getting CRA okay if you need to disconnect reconnect that's fine um until then was there any other comments on the timing and things like that uh other than metallic there was a mention of testet um testing so when would the test net Fork happen and when would the main net happen um which test net are we talking about my assumption is robon unless we create a new one I'm not sure I've heard both things mentioned in the past few months um I mean it has to be a test net where all clients can particip pit so this SP interuption I would say yeah does g not support uh koven so C ethereum supports neither ah I see okay so yeah it would have it would need to be robon then yeah I was thinking either robon or rink B I don't know how to pronounce it but yeah if if C eum can't then uh it has to be robst yeah and I think it should be Robson because that more accurately reflects the basically what the current conditions are it's a proof of work test net uh that consistently gets attacked whereas you know koven and rank B are more controlled so that wouldn't reflect true conditions all right let hope nothing nothing bad happens during the testing period like it happened like last week something happened to the test net again it exactly we can also go ahead I was gonna say we can also do um uh a robsten reboot where we you know start from a either a snapshotted and minimize or or compacted um Genesis block or just a a clean Genesis block um in order to yeah and perhaps impose a you know a hard cap on the on the gas limit to prevent any kind of attacks and um yeah so just saying we don't have to you know um keep RS and going we can do a reboot or uh you know a refresh um in preparation for testing the the hard fork okay sounds good yeah so we have a lot of options it seems like and I think this is something that doesn't need to be decided today necessarily dropped out again does it make sense to increase the meeting frequency okay I'm back my phone is freaking out um can everyone hear me still yeah yeah I don't think it needs to be decided day because um uh yeah because it'll be months before at least uh Beyond uh what was the estimate you gave Demitri you said um after July is when we'd be able to test or it was after July when we'd be able to launch not not able to launch we need more time for tests oh I see I see what you're saying okay I thought you meant that the test wouldn't be done before July okay um okay so it sounds like we can't really get a block number down today um but between now and next meeting we're going to have uh the freezing of some of the Eeps and we're going to potentially have a little more standardization with the uh and um also we can start looking at what it would take to do an alternative to just using what robsten is today and doing either a reboot or um some type of configuration change um Casey I think you have already looked because you were involved in um getting robon back on its feet a few months ago would it be signif would it take significant changes to do some of the things you mentioned no not significant at all okay would it make a sense to have a change freeze deadline and after dead deadline nothing can be changed in any of the Eeps and if something is not in a state you're happy with that it just dropped just iterating on on 's free proposal I think that's an okay idea except for the fact that some of these Eeps were decided on um related to other Eeps so I I believe static call revert and a few of those other ones were all intertwined in a way that made them work together best if they were all implemented so for something like that I feel like that would be an issue am I incorrect in thinking I I think those those are actually fairly specified okay so yeah they might not be as interconnected uh vitalic can you hear us now yes I could hear you now okay so uh Casey just while you were gone Casey brought up that uh we likely would need to use robsten because we would need to use a uh test net that the clients can all support and additionally if we want we can because there's been a lot of Robson attacks lately we can do a reboot and configuration change to like limit you know gas uh or um uh what was it again Casey yeah hard cap on the on the gas limit as long as um so the hard cap would be test net only right and I mean it it's a soft Fork it was what uh you know parody tried to do um during the original attack but right we can enforce it as a soft for just uh you know by um putting the majority pointing the mining power um at the at a minor that imposes the limit right yep so that that's probably the route will go and then uh Dimitri stated that um we wouldn't be able to re be releasing until August and until then we need to figure out the length of time that at test net would need to be on and uh so for instance like the test net needs to run for two weeks or six weeks or four weeks or what uh what opinions did you have on the timing and anything like that vitalic I am personally I'm inclined to say two weeks should be uh should be fine um the justification being that and practically speaking for all the previous cips we've uh two well two weeks is more is more we time than we've ever had for a hard Fork um and also like I'm not sure that any more time will help much especially given that I like the B of the uh error catching is going to be done uh before everything even gets released okay uh yeah that that sounds like um a fair point uh with I guess the caveat of that would be if there is an issue found the uh I guess it would be extended in that case correct okay that sounds reasonable so let's just say this um it definitely won't be the end of June and if things go right over the next few weeks we're going to have a number of things such as freezing Eeps and some testing improvements um additionally if there is um anybody on this call or who listens who is able to help with testing and wants to pitch in uh please reach out to myself Dimitri yichi or uh Martin Hol swend and uh we can get you hooked up on that uh we could use all the help we could get in that area um so yeah if anyone can devote any kind of resources that that would help move things along uh for Metropolis okay um I think that is pretty much the end of that so the conclusion to that bullet point would be that we don't have a date um and there's going to we're going to know a lot more the next meeting but it's definitely not going to be end of June and the testing time for uh the amount of time a test net would be running before we actually launch would be at minimum two weeks um and we'll have more discussion on that next meeting okay um let's see the time uh we have a couple of minutes um so Christian if you wanted to just get some feedback on your thing real quick that can be the last item all right um so um yeah de developers often face the problem that they it's it's quite hard to see when the user interface needs to be updated and also wallet developers uh currently have no way to see whether an external account uh gets receives an transfer via an internal call so um it might be beneficial to implement something like uh yeah a a listener filter uh index data structure that is uh filled or triggered whenever an account is touched by anything uh inside a transaction um yeah arari said that something like that is already implemented by parity and what are other client developers thoughts on that I've I've proposed this for go etherum before um building bloom filters for all the accounts that were in some way Touched By Request so that you can narrow narrow it down um at the time it wasn't hugely popular because You' still have to actually trace the calls in order to to determine what change um or you know potentially uh check balance before and after the block but I still think it it could be worth doing um I guess the other objection was take out more disk space [Music] Arad do you have an can you name a number about how much dis space that that needs well I'll have to look it up but from the top of my head it's like additional 20% for the databas size oh um how big is the balloon filter in in blocks at the moment for [Music] topics it's 256 bytes right so if we assume a similar size um we're talking about let's see about another nine gigs gigs no sorry n saying of blo blockchain plus overhead um which you could probably expect next database to be about the same again um more so even if we're using the transform Blom filters that we're currently adding to G so the size over here may not be significant okay so um the size wouldn't be significant for GU um any other clients have any comments another objection is that uh clients wouldn't be able to um you know execute these queries yes and ultimately this is either this is client specific or we Define an API for it in which case it's an RPC thing rather than a consensus thing like I don't think there's any reason to add this to consensus personally I mean you that's don't have to trust uh a response I mean so if an account was touched they can always verify by by rerunning the transaction and yeah it's very hard but a client could maliciously leave out a change so you don't to take that yeah that's what I want to say sorry I mean it's still very useful even if it has that property I would say yeah I think it's useful as a as a client side optimization anyway I mean the idea is you you register a call back whenever your accounts are touched and when they are touched you just read their state again so and you can also read the state at regular intervals to avoid uh the the the attack of not being notified okay so is this already an EP Christian I don't know yet I I just didn't know if this was referencing an e or if this was just an idea I mean yeah we should focus on Metropolis anyway but I just wanted to get some some feedback okay sure no problem um cool so yeah feel free to epy that and uh to trademark that term and uh yeah I think that is the last agenda item did anyone else have anything um or did anyone read anything neat in the troll box that they want to announce um something that we may have not known I didn't understand anything in the troll box so I had no idea what they were saying all right cool well there's no other topics yeah I should invite uh anyone with ideas about address check sums um I'm working on the address check sum uh format so uh yeah come talk to me yep I would like to talk okay let's do it cool all right uh anybody else all right talk to you guys in oh go ahead Nick no I was I was just going to um ask the parody folks whether they were going to implement DNS anytime soon to the list good cool yeah all right all right uh thanks everybody talk to you all in two weeks bye right