 Could you maybe clarify the the one point about transactions that don't have hashes? So the idea basically here is that like in a testing environment if you want to instantiate a transaction with some arbitrary sender and the sender could be someone else then You if you do this then you like you would not be able to provide a valid transaction hash and like this is just like one complication to kind of One like side complication to this approach. It's not if you're a large one, but like it does exist Any other thoughts on that? Okay, so So does this also affect the The transaction index in block approach too I'm not not really the edge the transaction index in the block is like fully deterministic or it's 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 fit this feels like I'm missing I'm missing a missing upcode in EVM because we have block number Upcode, but we don't have transaction index so the I Get so I can theoretically see the ration L for the transaction number upcode although it in It does seem a lot. It does seem a lower priority. That's 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. I'd even run off once it Yeah, it's not high priority I'm wondering also, does it play nicely with e-pages six? So the the transaction hash upcode doesn't play too nicely because you might like it's theoretically possible to get to transactions with the same hash and Like that's not I mean, that's not fatal, but it doesn't mean that you can't really rely on this transaction hash upcodes to uniquely identify transactions in the The Transaction like index some approach would be it's totally compatible with the IP 86 and Like pretty much any other IP so we agreeing that Of the three approaches, maybe the transaction index within the block this is the 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. I Having computer issues when the calls going is the scariest thing, but in any ways I'm here now and I believe that I only missed Yoichi talking about freezing the eeps So Let me go to the Agenda Whoever's been running this since I've been gone. Thank you so much and the stream is up and the troll box has been posted for y'all's enjoyment Dmitri says what's a rational? What's the rationale for having the transaction number opcodes? So there was one example that was mentioned the BTC relay one I think the idea there is basically that Asia 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 opcode to distinguish between the present transaction the future transaction and the purpose of this would be to Prevent tricks where like the contract gets accessed and then it replies and then and then the reply gets propagated with a referred Like in my opinion, it is fairly niche Oh, yeah, I would say the priority increases just because of the They revert and return data change. So it would be It would be timely to add it the other thing that I would say though is that I'm not sure there's that much so even with Without the TX number opcode you could also do the same thing by having a block number opcode and Well, we already have a block number opcode 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 Included in the same block anyway Yeah, there's a bit of an optimization Yeah 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 to be worth delaying metropolis at this point Yeah, I think most people Would say it might not be worth delaying metropolis over but I'm looking at the side. Oh, yeah timestamp does not change within a block. That's true, right? Yes, correct. Okay Yeah, and just to add on Jan said the initial idea was to limit the transaction rate like one transaction per block and a contract So I'm not I don't think that's necessary. I think the only thing that's probably necessary is One transaction per block for each individual thing that might need state that one needs to get asked so Okay, so even yeah So or the Sorry, I know you can go ahead I'm just gonna 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 transit. Okay. I require the transactions to be said that asks the questions to be That ask me to see really for the transaction for the block hashes to come in odd numbered blocks And then provide all the answers in the next even numbered blocks So there's a bunch of ways to kind of paralyze if it's really different users Okay What implementation of this? Does 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 didn't I came came in late to the convo And it is five or ten five or ten lines of Python to implement but then like the yeah, it 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 we're gonna run a longer and longer to the Plates where block times will be like reaching past like past half a minute before we're able to get the droplets out so okay, cool any other opinions on that or Any opinions or strong opinions either way, yeah, I totally agree that I mean even if 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 That being said Well, we'll put down the notes of what we discussed and if it needs to be up in the next and the next Meeting we can bring it up then as well Sounds good to me Okay, so next gender item and Vitalik you probably need to go right Yeah, I do okay. 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 did we go One and three or do we get through two really quickly on the agenda? Which one was to choose the metro updates EIP's and Some items we went straight from one to three Okay, no problem. So With two that that's probably better because since people had to leave Okay, so the details on implementations and EIP's is there anybody who no one really requested to put any Like new comments from last meeting so does anyone have any Questions or any comments on their client's implementation of this or yo ichi if you have found any more Small changes that you wanted to bring up or things that you've noticed No, not from me Okay Anybody else? Yeah, I was dropped off there. We're talking about the implementation of the eats, right? Exactly if there's any details or implementations It's a bullet a of agenda item to but like no one really put anything in there So what I would like to mention is that? I'm trying to run high tests on the clients and It would be really nice if All clients could Gather the metro Individual metro branches into one main metropolis branch So we could start running the hype test or start passing some high 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 So let's just go on to that because that one's one where Dimitri did add some information And I haven't had a chance, but I was gonna add a bullet point in there because less well my last night I put a Call out there for metro testers, but I'll have Dimitri go through his progress first right so for last week added lots of static call test CV serum and The latest develop test repository. Also, we are about to manage our block hash changes along with new tests and I forgot to mention we now have this new feature in a test that to called state diff and An option which should provide you with the state difference logs On the specific test case for specific transaction and data And the UG is currently working on a documentation on how to use this test test tool and how to create new tests I'm about to help him with that question Perfect, okay And then it looks like this also goes with what Martin said, which was basically that all clients implementing changes for metropolis should group theirs into a single PR in order to make Some of the testing outside of the testing you're doing but the or I guess I have a question Is the testing with hive? How is that related to the the fillers that are created in the aetherium slash test repository or are they linked or are they separate? Yes, they are They are linked Okay, the hive based tests are using artifacts which are generated from the fillers Okay, great So a good update Dimitri I think that's promising and I posted on reddit yesterday after talking to a few of you kind of a call out to the community for Metropolis testers, I guess and I've gotten some really promising emails between last night and now 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 Who are interested in diving deeper? Okay, cool Great The next item or was there anything else with testing? So once we finish the implementation in CPP serum The pull request is being merged to CPP serum development And at that moment tests that we created also merged to test developer branch and from that branch high test updated So we keep the most recent test in develop branch Okay, sounds good. That's good to know Let's see any subtleties we need to work out no one put any items for that Is there anything for sub items see any subtleties in metropolis we need to work out or people have noticed within the Yes, so in the trolley box, I am pasting I think Today Christian height-wisner is not in the call because he's on vacation, but he has a message About the return data copy instruction So in the last meeting we had a discussion About what happens when return data copy wants more bytes than returned And there were two opinions was an exception a return zeros Christian says he's fine with Either whichever is fine for him, but he requested Yeah, in some may be strong Okay, not strong, but it would be great if we reached an agreement in this or Okay. Yeah, he actually told me a similar thing. So 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 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 Rather than filling with zeros. We just have a throw that is As part of one of the new EIP is going to be like assigned something other than an out-of-gas But operates like an out-of-gas am I right on that? We saw 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 the EIP I Think that's why Christian asked you and Yeah, they've done message about making a decision in this call. I see okay Let me look in here Time to make a decision on this Zero filled zero filled. Okay, so I think it is Gav and Arkady who disagree so That might be still on going I think the majority of people Agreed on the hard throw Arkady. Do you want to speak for yourself or maybe you and Gav? Oh Yeah, sure. So the argument doesn't change, but if the majority is fine with from an exception That's fine with us also Okay, sounds good In that case, we're just gonna go with throwing the exception And I'll put that in the EIP as what we've kind of come to over the last two calls. So the decision is made Okay, great Okay, thanks everybody for helping coming to that decision Yoichi other than that was there any others? No Okay, cool. I think that was the major outstanding one from the EAPs Christian had gone over some of his metropolis EAPs to Kind of figure out some of the final stuff behind them This was one of the major ones and then I believe Vitalik is aware of some of the EAPs he needs to He needs to tackle in order to be done and then the Last thing would be who I always forget who wrote the other EAPs I guess Alex Bergs Ozzie he I Think he's the only other person besides Christian Vitalik who's written a metropolis active EAP The only other one was the revert opcode 140 and I think if I 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 Which is pull request number 206 about memory offset and memory length so I'm gonna go ahead and reach out to AXIC and Maybe Nikolai if he has some input on that So yeah, is there any other? Questions or subtleties amongst the EIPs 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'll go through and do a final check 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 we're done. Yoichi What I said was okay when we have pull requests and I saw this morning Christian proposed On some of his progress that's much and that process already seems like enough I'm not really convinced we need anything more formal Merging and EIP and maybe taking memos on the table that this one is merged Maybe that's enough. I think and maybe the focus should be on driving the existing bureaucracy working adding more bureaucracy Okay, I agree. I think that getting the entire EIPs repo and some of the processes that are newer Completely worked out. It is gonna be more important than adding another formal process on top But between this upgrade and the next one it probably be good to Have some kind of formal process So, yeah, we'll kind of table the freezing thing unless we run into a reason why we really need to have it there At that moment I was hearing from Dimitri that Okay, well since EPs were keeping changing We couldn't estimate when the test would finish but Well, one thing is When testing starts Then we find the problems and that might cause EPs to change. That's one thing So the start of testing is not the final point That's one thing That's one thing. I'm worried about this reason thing. The other thing is Um, what was it? Let me look No, okay, I don't Yeah, I raised this from my graph. So yeah, that's my main thing That's changed my mind about this reason process Okay Great. So on that note, I think actually that's a good segue to sub-item D under agenda item 2 Which would be review time estimates for testing and release. So I'm not sure if Martin Dmitri 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 a reminder of the timeline we gave last time it was basically sometime between July and September we would start the release of the testnet to Robson 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? 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 believe the first thing to be done is to estimate the amount of testing work Assuming no ifs change and then I mean we see we will see if it's too soon Okay, if we have enough time, why if we would be late already and then I mean we can start talking about how much more ifs changes we can accept or actually not anymore and There I'm seeing I 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 gonna be a few things coming into motion Including getting a little bit more volunteers finishing that documentation that you and Demetri And I think Martin were working on that he referenced earlier. So Yeah, no problem. There doesn't really need to be any changes to our rough window. We said last time So, yeah Demetri or Martin, did you have a comment or Demetri? Did you have any questions for Pavel? No, he just mentioned that he has a new unit test and I wonder The unit test will be run only on the CPP client But if you find a way to convert it into a state test, we could run it on every client due to Transaction execution on the state, for example I have a question about AP frozen frozen Do we have a label on github which could show which EIPs are accepted and stable And the most latest latest version for metropolis We don't have that right now, but what we're going to be doing is After today on the main there's gonna be two things so there's gonna be on the pull 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 and then also on the actual EIP like are the EIP repository github front page where we have a list of accepted EIPs We can also add a column to there I'm totally open for suggestions on what would be easiest 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 PR is effectively ready or complete Yeah, that's how I see it to merging would be equivalent to free, you know, what I'm quote freezing the the EEP Yep, exactly So did that answer your question Demetri or did you have a suggestion on that? So issues on github they will stay Is that label I could sort from all of the issues and see which one the latest EIP proposals and the specifications Yes, we can do that 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 EIPs, you'd be fine Okay, so on closed Issues Yeah, so it's gonna be Yeah, it's gonna be kind of two things if the issue in the PR are closed and it's been merged 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 Merging meaning like in the PR We just like close the PR or the pull request and then In the actual repository, there's a marked-down file with the specification in there permanently Oh, I guess you'll see Let's see how it works sure Cool, and then anything else I think Pavel was gonna comment on what he's been saying in the sidebar about Potentially converting it to a state test maybe It's a unit test for block hash contract. Oh Pavel we can't hear. Oh, there you go Yeah, I think I have some issues with their microphone Okay, I'll try it Amplify it a bit So this is regular test for for any Ethereum contract So it's it would be hard to convert it directly to some kind of state test and in this particular case You sometimes want to fake the state to to at least have like some kind of state of last 12 million blocks and might be hard to do it in the regular way I'm doing that because there is some interest in changing the the code contract from the AP with something better optimized and I know the Solidity team is working on on different implementation and This is this is a good test test bed for it to to actually replace the code in the Python Python tests and And check if it has the same properties So so all of that can be fine in a pre-quest in the IP's repository, so I I'm not really prepared to like Give any final Opinion about that because I started yesterday and there's still working progress Okay, great And then Nick you just yeah, you just gave kind of a little bit of more insight into the change And I'm sure you'll include that in his test or his EIP Yes, I'll write a message on the IP with a post change I think based on my own little tests that should actually simplify the code as well as making it more general But as I was saying in the comments Although I committed to to rewriting myself a couple of meetings ago I'm not sure I'm enough time in their future So if Pavel is already working on it and happy to be great if he's prepared to take a look at that Yeah, I would definitely Okay, hey, thanks Dmitri Pavel and Nick Were there any other comments on that? On any of this that we just talked about Okay. Yeah, if there's no more comments, I think that we're pretty much covered here 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 and My computer might be fixed by then so we might actually have something then Thanks for coming and I'll see you guys on the next all-core dev Shoo, thanks everyone Bye