All Core Devs - Execution #17

Transcript

e e e

e e could you maybe clarify the the the one

point about um transactions that don't have hashes uh but they so the idea basically here is that like in a testing environment if you want to instantiate a transaction with some uh arbitrary sender and the sender could be someone else then you if you do this then like you would not be able to provide a valid transaction hash and like this is just like one complication to kind of or one like side complications to this approach like it's not a very large one but like it does exist [Music] okay any other thoughts on that okay so

so does this also affect the um the transaction index in Block approach too um not not really because the the transaction index in the block is like fully deterministic or it's uh as in like it's something that's already known as part of State as part of the state calculation okay yeah so this is uh this feels like a missing a missing a missing up code in in evm because we have block

number up code but we don't have transaction index um so the um I so I could theoretically see the rationale for the transaction number op code um although it it does seem a it does seem a lower priority than some of the other things that we've been that that we've been trying to do but that's just my instinct at this point like I'd be theoretically fine with the transaction ID that ronal said yeah I agree it's not high

priority I'm wondering also does it play nicely with e 86 aren't um so the the transaction hash op code doesn't play too nicely because you might like it's theoretically possible to get two transactions with the same hash and like that's not I mean that's not fatal but it does mean that you can't really rely on this transaction hash op code to uniquely identifi transactions um um in the um the um transaction like index um approach would be is totally compatible with the IP 86 and like pretty much any other IP so are we agreeing that of the three

approaches maybe the transaction index within the block this is the uh best to consider candidate are there any other opinions okay it doesn't sound like there's any

opinions can everyone hear me now yes welcome back oh my God like uh having computer issues when the Call's going is the scariest thing but uh anyways um I'm here now and I believe that I only missed um yoichi talking about freezing the Eeps um so let me go to the agenda um whoever's been running this since I've been gone thank you so much uh and the stream is up and the troll box has been posted for y'all's enjoyment uh Dimitri says what's a rational what's the rationale for having the transaction number op codes so there was one example that was

mentioned the BTC relay one I think the idea there is basically that a like you could ping the BTC relay contract and tell it I want an answer back and then you would only be able to get the answer back in a future transaction and you would use the transaction number op to distinguish between the present transaction and the future transaction and the purpose of this would be to prevent tricks where like the contract gets access to it replies and then and then the reply gets propagated with a revert like in my opinion it is fairly Niche um yeah I would say the priority

increases just because of the um the revert and return data change so it would be it would be timely to to add it right although the thing the other thing that I would say though is that I'm not sure there's that much so even with uh without the TX number op code you could also do the same thing by having a block number op code and or well we already have a block number op code and then basically each individual user would have to wait a single block which is probably in my opinion fine because if you send multiple transactions you generally can't count on them being in included in the same block anyway yeah it is a bit of an

optimization yeah um like I'm definitely not opposed to it but it's also yeah just like my instinct at this point is that this isn't important important enough to uh to be worth delaying Metropolis at this point yeah I think most people um would say it might not be worth uh delaying Metropolis over but H I'm looking at the side oh yeah time stamp does not change within a

block that's true right yes correct okay yeah and just to add on um Jan said the initial idea was to limit the transaction rate uh like one transaction per block in a contract um so I'm not I don't think that's necessary I think the only thing that's probably necessary is uh one transaction per block for each individual thing that might needs to that would needs to get asked so okay or even yeah so or sorry oh no you can go ahead I was just going to say so you can

definitely process an unbounded number of users within like a finite number of blocks because you could do things like require the trans okay require the transactions to be that ask the questions to be that ask be DC relay for the transaction for the block hashes to come in od numbered blocks and then provide all the answers in the next even numbered block so there's a bunch of ways to kind of parallelize it between the different users okay um would implementation of this uh is there anyone who would know how long

this would take to implement because that would have some bearing on if it would go into Metro I at this point I would venture to say it wouldn't but I I didn't I came came in late to the convo and it is five or 10 five or 10 lines of python to implement but then like the uh is also going to be a fairly substantial amount of effort to test and like I at least for I personally am getting a bit worried that like testing is g to run longer and longer to the points where block timeses will be like reaching past like past half a minute before we're able to get Metropolis out so okay cool any other opinions on that or

um any opinions or strong opinions either way yeah I totally agree that I mean even if a a feature is Trivial it is not trivial you know the manual work behind all those test cases and they need to be written so I think that's the large part okay so assuming there's no other evidence or changes in the fact that this would require more testing or the testing resources wouldn't be there yet I would say that this isn't going to go into Metropolis right now um that being said uh we'll we we'll put down the notes of what we discussed and if it needs to be up in the next um in the next

uh uh meeting we can bring it up then as well sounds good to me okay so um next agenda item and vitalic you probably need to go right yeah I do okay well thanks for coming by anyway we'll send you the notes after okay excellent thank you bye okay so the next item on the list uh did we go uh one then three or do we get through two really quickly on the agenda which one was two uh two is the Metro updates uh eips and uh sub items we went straight from one

to three okay no problem so um with two that that's probably better cuz um since people had to leave um okay so the details on implementations and eips uh is there anybody who no one really requested to put any um like new comments from last meeting uh so does anyone have any questions or any comments on their client implementation of this or yoichi if you have found any more um small changes that you wanted to bring up or things that you've noticed h no not from me okay uh anybody else so yeah um I was

dropped off there we're talking about the implementation of the Eeps right exactly if there's any details or implementations it's sub bullet a of uh agenda item two but like no one really put anything in there so so what I would like to mention is that um I'm trying to run hi tests on the clients and it would be really nice if um all clients could uh gather the Metro their individual Metro branches into one main Metropolis Branch so we could start running the hive test or start passing some Hive tests on the client that's it okay great and yeah I think that

actually yeah we touch on that in the next bullet point as well um so let's just go on to that because that one's one where Demitri did add some information and I haven't had a chance but I was going to add a bullet point in there cuz last well my last night I put uh a call out there for Metro testers but I'll have um Demitri go through his uh progress first hi so for last week I added lots of uh static call test to cbum and the latest develop test repository also we are about to M our block Cas changes uh along with new

tests and I forgot to mention we now have this new feature in a test ad tool called State diff um an option which provide you with a state difference log uh on a specific test case for specific transaction and data and the Y is currently working on a documentation on how to use this test test tool and how to create new tests uh I'm about to help him with that question perfect okay um and then it looks like this also goes with what Martin said which was

basically that um all clients implementing changes um for Metropolis should group theirs into um a single PR in order to make uh some of the testing outside of the testing you're doing but the or I I guess I have a question um is the testing with Hive how is that related to the the fillers that are created in the ethereum test repository are they linked or are they separate yes they are they are linked okay the high based tests are using artifacts which are generated from the fillers okay great um so a good update

Demitri um uh I think that's promising and I posted on Reddit yesterday after talking to a few of you um kind of a call out to the community for um Metropolis testers I guess and I've gotten some really promising emails um between last night and now uh so I think that you guys writing that documentation is good timing and I'll go ahead and send some of those people your way uh who are interested in diving deeper cool great um the next item or was there anything else with testing

now so once we finish the implementation in CPP serum the pool request is being merged to cppp serum development and at that moment test that we created also merged to test developer branch and from that Branch uh have test updated so we keep the most recent test in um test develop Branch okay sounds good that's good to know um let's see any subtleties we need to work out uh no one put any items for that is there anything for sub item C uh any subtleties in Metropolis we need to work out or people have noticed within the EIP yes so in the throt boook I'm

pasting a link today Christian is not in the call because he's on vacation but he has a message uh about the return data copy instruction um so in the last meeting we had a discussion about what happens when return data copy wants more bites thaned and there were two opinions was an exception or return zeros and Christian says he's fine with either whichever is fine for him but he requested in uh yeah in some maybe

strong Lang okay not strong but it would be great if we reached an agreement in this C okay yeah he actually told me a similar thing so um I I think that the last call we had so yeah Christian just said I just want a decision to be made I don't really care what it is um on that topic from last time so correct me if I'm wrong everybody but I think we went with the fail hard approach where uh rather than filling with zeros we just have a throw that is as part of one of the new eips going to be like assigned something other than

an out of gas but operates like an out of gas am I right on that um we saw uh more people agreeing on that and but actually the other party didn't say they agree and actually even after the last call the discussion still went on on the E I think that's why Christian asked you and yeah left a message about making a decision in this call I see okay um

uh let me look in here time to make a decision on this zero filled zero filled okay so I think it is gav and arade who disagree so um that might be still ongoing I think the majority of people agreed on the hard throw um arade do do you want to speak for yourself or maybe you and gav well yeah sure so the argument doesn't change but if the majority is fine with from an exception I mean that's fine with us

also okay sounds good um in that case we're just going to go with throwing the exception um and I'll put that in the EP as what we've kind of come to over the last two calls so that a decision is made okay great okay thanks everybody for helping coming to that decision uh yoichi other than that was there any others no okay cool I think that was the major outstanding one from the Eeps um Christian had gone over some of his Metropolis Eeps to uh kind of figure out some of the final stuff behind them this was one of the major ones and then I believe vitalic is aware of some of the Eeps he

needs to um he needs to tackle in order to be done and then the last thing would be who I I I always forget who wrote the other Eeps um I guess um Alex Bazi uh he I think he's the only other person besides Christian vitalic who's written a metropolis act active EP um the only other one was the revert op code 140 and I think if recall that that one's pretty pretty solid I don't think there's been much debate on changing that in a while let me look oh okay actually you have a comment

at the bottom yoichi on EIP 140 uh which is pull request number 206 about memory offset and memory length uh so I'm going to go ahead and reach out to axic and uh maybe Nikolai if he has some input on that so yeah is there any other questions or subtleties amongst the eips um or ones that aren't done that need to be kind of people need to be prodded to kind of finish up final points on okay cool I I'll go through and do a

final check um uh sometime after this meeting and so we can kind of get those frozen I wasn't here for the first of the call but was there anything new on the whole Frozen thing or did you just kind of give an update on which ones you thought were done Yi uh what I said was okay when we have Pro requests and I saw this morning Christian proposed on some of his pre requests that merge and that process already seems like enough and I'm not really convinced we need anything more formal than marging a nip and may maybe taking memos on the table

that this one is merged um maybe that's enough I think and maybe the focus should be on driving the existing bureaucracy working than adding more Flags or more bureaucracy okay I agree I think that getting the entire Eeps repo and some of the processes that are newer completely worked out is going to be more important than adding another formal process on top but between this upgrade and the next one it probably be good to um have some kind of formal process um so yeah uh we we'll we'll kind of table the freezing thing unless we run into a reason why we really need to have it there um at at that moment I was hearing

from Dimitri that if keep okay well since ifs were keeping changing um we couldn't estimate when the test would finish but well one thing is when testing starts then we find problems and that might cause ifs to change that's one thing so the start of testing is not the final Point um that's one thing that's one thing um I'm worried about this reason thing the other thing is um what was it um let me look up

um no okay I don't yeah I raised this from my draft so yeah that's my main thing um that's changed my mind about this reeing process okay great so um on that note I think actually that's a good segue to sub item D under agenda item two uh which would be Review Time estimates for testing and release so um I'm not sure if Martin deichi or yoichi have discussed this amongst themselves or if anyone has an opinion it doesn't have to be like anything definitive but has there been a change in any of the timelines we gave

last time and just to give it a reminder of the timeline we gave last time it was basically sometime between July and September we would start the release of the test net to robon for two weeks in order to then move to doing the main net release after that if nothing goes wrong so is there any changes to the um July to September timeline for it to be completed I believe um none of us has a good estimate on the amount of work to be tackled

so I I I believe the first thing to be done is to estimate the amount of testing work and assuming no ifs change and then I mean we see we will see if it's soon okay if we have enough time or if we would be late already and then I mean we can start talking about how much more changes we can accept or actually not anymore and there I'm seeing there okay actually at least I am not seeing enough Precision okay yeah that's totally fair and I think that between now and the

next meeting there's going to be a few things coming into motion um including getting a little bit more volunteers finishing that documentation that you and Dimitri uh and I think Martin were working on that he referenced earlier so um yeah no problem there doesn't really need to be any changes to Our rough window we said last time um so yeah uh Dimitri or Martin did you have a comment or Demitri did you have any uh questions for pble no he just mentioned that has a new unit test and uh I wonder uh the unit test will be run only on CPP client but if you find a way to convert it into a

state test we could run it on every client due uh transaction execution on the state for example um I have a question about e Frozen Frozen do we have a label on GitHub which could show which eips are accepted stable and the most latest version for Metropolis we don't have that right now but what we're going to be doing is after today um on the main there's going to be two things so there's going to be on the poll request itself there'll be a label like a GitHub style label for whether it is I guess ready to implement

for Metropolis or there'll be some kind of very clear label of no more changes to this um and then also on the actual EIP like or the um EIP repository GitHub front page where we have a list of accepted eips we can also add a column to there um I'm totally open for suggestions on what would be easiest um I guess the third thing for that is also merging the PRS is more or less a declaration of finality so that is also something that we'd be doing when a uh PR is effectively ready or complete yeah that's how I see it too merging

would be equivalent to uh free you know quote unquote freezing the the E yep exactly so did that answer your question to metri or did you have a suggestion on that um so issues on GitHub they will stay and with that label I could sort from all of the issues and see which one the latest CIP proposals and the specifications okay uh yes we can do that um the the I will say that the issue in the pull request May close though but as long as you sort by labels that also include closed dips you'd be

fine okay so on closed issues it would be possible on closed ises yeah so it's going to be um yeah it's going to be kind kind of two things if the issue and the pr are closed and it's been merged uh then that means it's included in fact actually being merged is like the ultimate signal that it is ready ready to go for Metropolis um merging meaning like in the pr I we just like close the pr or the pull request and then uh in the actual repository there's a markdown file with the specification uh in there permanently oh I guess we'll see in the next once it

will be we'll see how it works sure um cool and then uh anything else I think pav was going to comment on what he's been saying in the sidebar uh about potentially converting it to a state test maybe means a unit test from cont oh pav we can't oh there you go yeah I think I have some issues with the microphone uh okay I'll try it uh amplify it a bit uh so this is regular uh test for for any uh ethereum contract um so it's it would be hard to

convert it directly to some kind of state test and and in this particular case you sometimes want to fake the state to to at least have like some kind kind of uh state of last uh 12 million blocks and might be hard to do it in the regular way I I'm doing that because there is some interest in uh changing the the code contract from the EAP with something uh better optimized and I know the solidity team is working on on different implementation and this is this is good test uh test bad for it to to actually

replace the code in the python Co python tests and and check if it has the same properties so so all of that can be find uh in a proquest uh in the IP's repository so I I I'm not really prepared to like get give any final uh opinion about that because I started yesterday and there's still work in progress okay great um and then Nick you just yeah you just gave kind of a a little bit of more insight into the change and um I'm sure you'll include

that in uh his test or his EIP uh yes I'll I'll write a message on the EIP with the proposed change I think uh based on my own little tests it should actually simplify the code as well as making it more General um but as I was saying in the the comments um although I committed to to rewriting it myself a couple of meetings ago I'm not sure I'm going to have time in the near future so if Powell is already working on it and happy to then it' be great if if he's prepared to take a look at that yeah I will definitely it out okay hey thanks Dmitri pavle and Nick um were there any other comments on

that um on any of this that we just talked about okay yeah um if there's no more comments um I think that we're pretty much covered here um there should be a lot of stuff between now and the next meeting in two weeks which will be I believe on the 16th on a Friday um and uh my computer might be fixed by then so so uh we might actually have something then um thanks for coming and uh I'll see you guys on the next allore Dev thanks

everyone bye cheers by bye e

e e e

e e e

e e e

e e e

e e