Ethereum Foundation Core Devs, 2 Jun 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ethereum Core Devs Meeting #17 [6/2/17]

Description

Agenda: https://github.com/ethereum/pm/issues/15
Log of YouTube Live Comment Box During Live Stream: https://pastebin.com/JPkKt9mt

A

Because you may, by the the one point about transactions that don't have hashes.

B

A

B

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, or one like side complication to this approach, and it's not if you're a large one but like it doesn't exist.

A

Any other thoughts on that data.

C

Also, does this also affect the transaction indexing block approach, I'm.

B

Not not really, as.

C

B

Edge, the transaction index in the block is like fully deterministic or it's as if I get something that's already known as part of CEO as part of the state calculation.

C

C

Yeah, so this is fit. This feels like I'm, missing, missing a missing opcode in evn, because we have block number up code. We don't have transaction index.

B

Episode the job I guess so I can theoretically see the rationale for the transaction number up code, although it in it does seem it does Siva lower priority that some of the other things that we've been to that stuff that we've been trying to do. But that's just my instincts at this point like I'd, be theoretically fine with those transaction ID and run off. One said nope.

C

D

C

Is not high around II.

D

Wondering also doesn't play nicely with e86. Alright.

B

I'm, so the the transaction hash up code doesn't play too nicely. You guys 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 the transaction hash opcode to uniquely identify transactions in the UM li geom transaction luck, index approach would be, is totally compatible with the AP 86 and like pretty much any other idea.

E

So, are 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.

F

Okay, it doesn't sound like there's any opinions. Can everyone hear me now? Yes,.

B

F

Oh, my god like having computer issues when the calls going is the scariest thing, but anyways I'm here now and I believe that I only missed um yo Ichi talking about freezing the eeap's. um So let me go to the agenda.

F

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. Dimitri says: what's irrational, what's the rationale for having the transaction number opcodes.

B

So there was one example that was mentioned: the BTC relay one I think the idea. There is basically that Asia what 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 into future transaction and you would use the transaction number opcode to distinguish between the present transaction.

B

The future transaction and the purpose of this would be to prevent tricks where, like the contract gets accessed and that it replies to that, and then the reply gets propagated with a revert like in my opinion, it is fairly neesh. Oh.

A

I would say the priority increases just because they the revert and return data change, so it would be no, it would be timely to add it.

B

I don't know the other thing. That I would say, though, is that I'm not sure there's that much so even with without the txw opcode, you could also do the same thing by having a block, number opcode and or well. We already have a block double wrap 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 that being a good included in the same block anyway,.

A

What it yeah there's a bit of an optimization yeah.

B

Like I'm definitely not opposed to it, but it's also.

B

Yeah, just like my instinct at this point, is that this isn't important important enough to to be worth the leg. The droplets at this point.

F

Yeah I think most people um would say it might not be worth delaying metropolis over, but hmm 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 Jim, said, the initial idea was to limit the transaction rate like one transaction per block and a contract, so I'm.

B

Not I, don't think that's necessary. I think the only thing that's probably necessary, as a one transaction per block for each individual thing that might need stay. That would need to get asks so.

B

F

B

So in or thee sorry.

F

I know you can go ahead.

B

I'm 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 transit. Okay require the transactions to be that ask the questions to be or sort that ask me this really for the transaction for the block hashes to come in odd, numbered blocks and then provide all the answers in the next. Even the word watch so there's a bunch of waste I'm going to paralyze if it's with the different users.

F

Okay, um what implementation of this 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 didn't I came came in late to the conv.

B

It is fiber tip five or ten lines of Python to implement, but then, like the, it is also going to be a fairly substantial bit of effort to test yeah look I, always firm, I'm personally I'm. Getting a bit worried that, like testing, is we're gonna, provide a longer and longer to the points where block times will be on reaching past. Like past half a minute before we're able to get the droplets out.

F

So no okay cool any other opinions on that or any opinions are strong opinions either way. No.

D

I totally agree, that's 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.

F

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 very yet I would say that this isn't going to go into metropolis right now.

F

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.

B

So one sprint to me.

F

Okay, so next gender item and Vitalik, you probably need to go right. Yeah I do okay, oh thanks for coming by anyway. We'll send you the next after okay. So one thank you bye, okay, so the next item on the list uh did we go one and three or do we get through two really quickly on the agenda?

F

We're trials, I choose the metro, updates, IPs and some items we.

A

Went straight from one to three: okay,.

F

No problem so um with two that that's probably better, because since people had to leave um okay, so the details on implementations and II IPS 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 clients, implementation of this or yo each? If you have found any more small changes that you wanted to bring up or things that you've noticed.

E

Look through me.

F

Okay, anybody else.

D

F

I was dropped off there, we're talking about the implementation of the eats rights exactly if there's any details or implementations. It's simple at a of agenda item two, but like no one really put.

D

Anything in there so.

F

D

What I would like to mention is that I'm trying to run hive tests on the clients, and it would be really nice if all clients could gather the metro, the individual metro branches into one main metropolis branch. So we could start running the hive test or start passing some high tests on the client. That's it.

F

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 Dmitry did add some information, I haven't had a chance, but I was going to add a bullet point in there cuz less well. My last night I put a call out there for Metro testers, but I'll have Dmitry go through his progress. First.

G

Right so what philosophy credit lots of static code estimation and the light has developed test depository? Also, they are about to know she'll blow crash. It changes along these new tests and I forgot to mention.

G

We now have this new feature in a test that called state deep and an option which provide you with the state difference logs on a specific test case or specific transaction, and they turn and the ug is currently working on a documentation on how to use this test set tool and how to create new tests and I'm about to help him. With that question,.

F

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 with the Erb I guess I have a question: is the testing with hive? How is that related to the the fillers that are created in the etherium / test repository? Are they linked or are they separate? Yes,.

D

They are, they are linked.

D

The high based tests are using artifacts, which are generated from the fillers.

F

Okay, great so a good update, Dimitri um 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 that I've gotten some really promising emails um 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.

G

Right ooh, great.

F

The next item, or was there anything else with testing.

G

So now, once we finish the implementation in CBP serum, the pull request is being rushed to the PCM development and, at that moment, tests that we created also a mesh to test developer branch and from that branch I've just updated.

G

So we keep the most recent testing and test develop branch.

F

Ok sounds good, that's good to know, um let's see any subtleties, we need to work out. No one put in the items for that is there anything for sub item see any subtleties in Metropolis. We need to work out or people have noticed within the AIP is.

E

So in the throttle box, I miss being a dink today, Christian I twist nice, not in the hole because he's on vacation, but he has a message about the return date, the copy instruction, and so in the last meeting we had a discussion about what happens when we turn data copy bonds, more lights than returned, and there are still opinions cause an exception or it on zeros.

E

Christian says he is fine with either whichever is fine for him, but he requested in yeah in some may be strong and which a not strong, but it would be great if we reached an agreement in this fall.

F

Okay yeah, he actually told me a similar thing, so um 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.

F

So correct me if I'm wrong everybody, but I, think we went with the fail heart approach where, rather than filling with zeros, we just have a throw that is I as part of one of the new EIP s going to be like assigned something other than an out of gas, but operates like an out of gas, am I right on that.

E

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 ich I. Think that's why Christian asked you and yeah if the message about making a decision in this code, I.

F

F

Let me look in here trying to make a decision on this: zero filled, zero filled, okay, so I think it is Gavin and Arkadiy who disagree so um that might be still ongoing. I think the majority of people agreed on the hard throw Arkadiy. Do you want to speak for yourself, or maybe you and gaff well,.

H

Yeah sure so their agreement doesn't change, but is a majorities fine ways from an exception. That's fine with us also.

F

Okay sounds good um in that case, we're just going to go with throwing the exception and I'll put that in the e, as what we've kind of come to over the last two calls, so that the decision is made.

E

F

Thanks everybody for helping coming to that decision, yuuichi other than that was there any others. No.

F

Oh cool I think that was the major outstanding one from the eeap's Christian had gone over some of his metropolis eeap's 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 eeap's he needs to.

F

He needs to tackle in order to be done and then the last thing would be who I was forget? Who wrote the other oops I? Guess Alex beers Ozzy, he I think he's the only other person. Besides Christian metalic who's written in metropolis apt, active EEP, 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.

F

You know each Yanni IP 140 I, which is pull request, number 206 about memory offset in memory length, so I'm gonna go ahead and reach out to axe ik and maybe nikolai if he has some input on that.

F

So yeah is there any other questions or subtleties amongst the VIPs 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.

F

Okay, cool I'll go through and do a final check of 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 Daniele Ichi.

E

What I said was: okay when we have pre requests and I saw this morning, Christian proposed in some of his pre requests as much, and that process already seems like enough and I'm not really convinced. We need anything more formal than merging the NIP and maybe taking memos on the table that this one is merged.

E

Maybe that's enough fighting and maybe the focus should be on driving the existing vehicle working on adding more bags or more video question. Okay,.

F

I agree: I think that getting the entire oops repo and some of the processes that are new or completely worked out. It is going to be more important than adding another formal process on top, but between this upgrade and the next one it'd probably be good to have some kind of formal process so yeah. What will kind of table the freezing thing unless we run into a reason why we really need to have it there.

E

um That moment, I was hearing from Demetri that it's okay, well, since ifs, were key in 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 it's the change. That's one thing. So the start of testing is not the final point and that's one thing: that's one things I'm worried about this vision thing. The other thing is um um that made of are.

E

Not okay, I, don't I raised. It is from my graphics, oh yeah, that's my main thing. um That's changed my mind about displeasing process.

F

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 to me, cheerio each II 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.

F

We would start the release of the test net to rob stone for two weeks in order to then move to doing the main net release after that. If nothing goes wrong, so there any changes to the july-to-september timeline for it to be completed. I.

E

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 the estimated amount of testing work, I'm, assuming no ifs change, and then I mean we see. We will see if it's a lager if we have enough time well, if we would be dead already and then I mean we can start talking about how much more exchanges we can accept or actually not any more um there I'm seeing I there. Okay, actually at least I, am not seeing enough precision.

E

F

Yeah, that's totally fair and I think that between now the next meeting, there's going to be a few things coming into motion, including getting a little bit more volunteers, finishing that documentation that you and Dimitri 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, Dimitri or Martin. Did you have a comment or Dimitri? Did you have any questions for Apollo.

G

No, he just mentioned that he has a new unit test and I wonder the unit testing would be run on the mCP client, but if you find a way to convert it into a state test, we could run it on every client, Deut transaction in educational state. For example, I have a question about APU frozen closing and do we have a label on github which could show me GIPS accepted and stable and the most less latest version for metropolis? We.

F

Don't have that right now, but what we're going to be doing is, after today, on the main there's going to be two things so there's going to be on the pull request itself: there'll be a label like a github style label, for whether it is I guess we're ready to implement from metropolis. So there'll be some kind of very clear label of no more changes to this and then also on the actual, a I like or the EIP repository github front page, where we have a list of accepted e IPS.

F

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.

A

Yeah, that's how I see a two merging would be equivalent to free. You know what unquote freezing they eat.

F

Yep exactly so, did that answer your question to me. True, did you have a suggestion on that.

G

So issues on the table leg of stay is that label I could sort from all of the issues and see which one the latest CIP proposals and specifications know that I.

F

Yes, we can do that. The the I will say that the issue and the pull request may close, though, but as long as you sort by labels that also include clothes, di PS you'd be fine.

G

Okay, so on clothes, useless room would be possible on clothes. Yes, yes,.

F

So it's going to 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 and the pr I-- we just like close the PR or the pull request, and then, in the actual repository there's a markdown file with the specification in there permanently. Oh.

G

I guess you'll see yeah once until game. Let's see how it works. Sure.

F

um Cool and then anything else, I think Pavel was going to comment on what he's been saying in the sidebar about potentially converting it to a state test. Maybe.

G

In the unit test for workers, contract.

F

Pavel weekend here out, there yeah yeah.

G

I think I have some issues with their microphone: okay, I'll, try to amplify it a bit, so this is trigger or contest for for any achieving contract.

G

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 do at least have like some kind of state of last twelve million blocks and might be hard to do it in trigger way and 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.

G

The solidity team is working on on different implementation, and this is this is good test test bed for it to actually replace the code in the Python Python tests and and check if it has the same properties.

G

So the way all of that can be find in requests in the eyepiece repository, so I'm not really prepared to like give any final opinion about that, because I started yesterday and there's still work in progress. Okay,.

F

Great and then Nick you just get 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 a IP I.

I

Guess I'll write a message on the IP with the post change I think, based on my own little tests that should actually simplify the code as well as making it more general and but as I saying in that comments and although I committed to rewriting it myself a couple of meetings ago, I'm not showing their time in their future. So if Powell is already working on it and happy to that'd, be great. If he's prepared to take a look, a bath.

G

Yeah I will definitely come. Thank.

F

You look at them: okay, hey thanks, Dimitri, Pavel and Nick. Were there any other comments on that on any of this that we just talked about.

F

Okay yeah, if there's no more comments, I think that we're pretty much covered here. There's 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.

A

Q thanks everyone bye.

F

F