 Today's mostly going to be about Metro, but there's some other stuff too and Yoichi had Some questions that kind of dive into how we're implementing some of the EIPs in Metro. So that's the main stuff today Let's start with agenda item one. So that's going to be EIP 186 the last call. We had talked about Discussing it a little bit further between Before this call to see if there was any other Opinions and also to get some of the opinions of the researchers who were in Malta last time So just a quick overview of what's happened since then I There hasn't I was going to put a reddit post out about it, but then I kind of saw You know people in the thread about the last discussion notes from the last all-core dev meeting Talking about it. And you know, there weren't there wasn't a in my opinion a bunch of People who were looking to make that change there is still to me kind of a Consensus around them the people who would implement the code that it would be Better to be risk averse in this case for Metropolis coming up. So let's start out with Yoichi and anybody in the The Berlin office. Do y'all have any opinions on it anybody who wasn't here last time or any new opinions? Say that one more time I couldn't hear Maybe nothing nobody's saying that Okay, cool the talak. Did you have anything? I think you discussed a little bit on reddit, but what do you what's your view on it? Yeah, I mean I think Well, the view I gave in one of our Skype chats a while back is that anything like Is it anything at least in what for my intuition anything over two and a half is like safe enough but going beyond that will Yeah, I kind of Introduce at least some risks For just from a safety standpoint Okay, and so what would you say about the need to put it into Metropolis? Is there is there really one at this point or is this something that should be addressed for a Different hard fork or not at all? I Mean the reward is gonna come down anyway once we start start the proof of stakes which So It's like it's it's not the sort of thing that Let's see how should I say this like a practice in practically speaking like the difference between Cutting it down to like even to take the bottom end two and a half and fought and so just pushing it all the way back up to five in inside of Metropolis is only going to be something like a Couple million like maybe two or three million ether so it's So it sounds like it's not really something that's That important or applicable for Metro I mean, it's not it's not that important to replicable either way Though on the other hand like given that we're going to be mucking around with mining rewards anyway and because we're delay delaying the ice age like it's I Don't say you know, I don't see you in extremely strong case in either direction, I guess Yeah, I'm kind of thinking the same way and in most cases. I feel like the status quo for when that happens within Hard forks that I've seen is that when it's kind of not that strong in either direction and there's no one really And then I don't there's no people who are going to implement it really championing the idea that it probably should just kind of remain in discussion Overall or be delayed for a different thing. Does anyone else in the room have a different perspective or any other opinions? No, I'd say just Keep keep an uncontroversial hard work as uncontroversial as possible Yeah, I would tend to agree with that So, yeah, I think that's the end of that Discussion point then Let me see real quick something. I just lost my Agenda here cool. All right. So the next agenda item So this one you know each you brought up EIP 86 which is Talking about the create instruction He was saying that there were some discrepancies between the EIP pull request as written and the Implementations across clients. Yoichi. Do you want to expand on that a little bit? Yes, so DC IP is about Account abstraction and that's part of that Specification point three talks about changing the way it calculates the address of new contracts but interestingly It only talks about to create Transactions, but not about create Instructions so when the EBM hits a create instruction It does create something, but it's not a create a transaction so it does some ambiguity if This EIP Changes both Create transaction and create the instruction or it does just change the create Transaction and we keep that create instruction as it is it seems like Well, literally the EIP text Looks like looks like it changes only the create transactions not instructions But all implementations I saw Kind of agreed on changing both Especially the create instruction, so I need some clarification which way we are following I mean Due to the fact that we also add a new creation opcode in this Proposal than the this means that the old creation opcode retains its semantics So yes, Christian made an argument for one option and That's why I chose the same in the yellow paper prerequest But Alex had a different argument Maybe it's a good. It's better to keep create instruction as it is because when we change that we might break some existing Contracts, so I kind of need the clarification here So the create transaction is an extra interface to you okay, I'm back alive great contracts pattern I Don't think this one is working You know, but what's that about the new create opcode? Yes, so if this same EIP Talks about creating a new kind of create instruction where Different sources can deploy the same code on different different addresses ah It's called the create p2sh or something so yes, this is a new instruction So the intention of the EIP seems to be that they create states as it was before correct right And do we have someone who would champion the case why create would change? So basically the idea in general is that we want it to be possible to or in like possible and very easy to how create they have addresses that are very specifically bound to one particular piece of code and So that people can either like send money or sense tokens or do other things for those addresses before the account story or get created and The problem with the current creation Contract creation approaches is that because the address only depends on the sender and the nonce there's Like that basically it's the the actual contents of all the addresses are under the full control of the sender because the sender gets to um Like whatever they want to into the creation code into the contract code and it's still the same address either way so this would so this EIP would DM addresses code dependent and This actually would allow you to create contracts where but the addresses for those contracts do depends just on the On what the code is so like one one user story for this for example is Let's say I have no money and I want to start receiving money But I also do not like I do not want to have an account that uses Regular ECDSA I might want to directly have a multi-sig or I might want to directly have something based on lamp or signatures or whatever else so what I would do is I would privately kind of simulate the creation of the contract privately like figure out what the Address would be with that piece of code then it would give people that address and people could send money to that address and then when there's enough money in the address then you could create the contract and Based and pay out of out of that money as a few as a fee going to the minor No, that story can go with the external accounts and the contracts both so So this kind of doesn't answer This specific question if that create instruction We change so okay, so first of all there's There's two ways to create contracts right so one of them is externally and one of them is through the create opcode so part of a part of that EIP is Accounts that the the scheme for addresses that get created externally gets changed, but as far as the create opcode I Think the main reason to change that is well There's two main reasons one of them is consistency and the other is so that The scheme like the scheme works even if it's contracts that are creating other contracts and not just the mechanisms from the outside Okay, so actually I don't need a really strong argument for changing the create instruction I just needed a clarification and I got the clarification now and I think this EIP request The text can be improved, but I don't think that you already done implementations need to change that so I'm happy about this So I'm fine with this point Agenda number three So maybe have something taken take over Yeah, I'm just just to clarify You issue as I read the comment that you put on the agenda So do these implementations is pull request Change the create instruction or do they add a new opcode a new create instruction? They add a new create instruction in the old one. Yeah Yeah, so the old one is retained Yes, the old one is there but the old one create the old one creates accounts in Different position after me to the police Yeah, but no no the old one the old create opcode should still create accounts in the same position, right? Oh on the same position. Okay, then. Okay. I miss understood you in that case The CP PSM pre-quest should be updated on the party Implementation should change The opcode gets a new name, but the same number Did I send it correctly? No, that's not correct The old create is still the old create, okay You create PSH P2SH Different creation address So the behavior of the old of the old create opcode is unchanged and a new create opcode is created with Equivalent functionality except the different address Yeah, so now I hear the old create instruction Will not change its behavior. I see Okay, then with this I will poke Implement us and say that and I raise shoes and the comments on main DCP PSM and the party I Have a related question though to this proposal What happens if I address the contract thunder and I later on self-destruct that contract Then you can create it yet another contract at the same address You can do that Or you cannot with this with it. No with this opcode. Yes so all right So you don't actually know that I Mean it can vary from transaction to transaction whether that address actually holds some code or not theoretically Yes Right Just curious Now we can carry on Okay, I'd like to clarify a few things So after metropolis will be free ways and address for a new contract is generated First with the create transaction That generates an address from the code hash second is the Create opcode that generates it by r.o.p. concatenate concatenate in sender And what nuns and the third way is create a new create instruction that generates it from Yes, why can't you Nate and sender and yeah, okay, that's clear And the second question again that you mentioned a use case when the account Receives some balance and only after that a Contract is created for that for that address Yes, so how would is that possible to the create instruction? can create No, basically doesn't check if the account exists just checks for the code Correct. Yeah Okay, that's clear. Thanks Okay, awesome. So the next item is so that clears up What is number two on the agenda? Change the address history of create. Okay, so, um, you know, she also had another comment in here about The some of the accepted EIPs are not yet specific enough to form a protocol consensus So what's the next action and he gives three examples you each you do you want to just go through those as well? so There are certain accepted EIPs and I assume we are seeking to implement those for metropolis But some of these have some missing numbers and so on So the first thing is for the elliptic curve related stuff from we don't have the gas prices yet and another thing is for the Blockhead the abstraction thing. We don't still have that get our code Okay, so Regarding the gas costs for pairings I think the reason why that hasn't been specified yet is because I mean like Christian has come up with Possibilities for the gas price But the reason we haven't set things in stone yet is because we wanted to see how we wanted to get benchmarks on the govert on like the parody version and the go version and See like see how long it takes Before we can make a final decision That's reasonable Okay, so that so that that's kind of solved by just As things go on like it's accepted, but then we're gonna just tweak that at the end once we get the yeah stuff going Okay Yeah, so I mean like if we need if we need to do it for testing purposes Then we could just like agree on some temporary gas price now But then if it's just for testing then we might as well make it zero Sure, sure. I'm no problem really I just thought we should have these texts ready and pretty before we actually perform stuff So that that that was my assumption and I kind of tried to find missing Okay, cool. So it sounds like Just looking over the list. I'm the pairing check and the group addition on elliptic curve are things that sound like it's gonna come With time, but that we can put kind of a temp value in the thing with the getter code on EIP 96 is that something that's the same case or something that can be answered I'm pretty happy 96 it's some I mean I can provide a big get I mean at least that one version of the getter code It should be up here somewhere I don't see it I don't see it right now, but but I Can provide that that's fine Okay, sounds great Okay, yes, then these points have it all All right, great. So the next thing would be removing med state from receipts So that is EIP 98 which yeah, the AP 98 it looks like there's a difference in implementation between Go and CPP or go and CPP do it one way in parody does it another So I'm EIP 98 is the one that makes that that removes the intermediate state roots, correct. Yes, that's correct. So Looking at this Is there let me see if there's any indication or Andre you're in the room. Would you be able to? Talk about what the difference is Do you hear me? Hello. Yeah, can you hear it? Yep, we can hear you So there are two options in the IP specification one is removing the root hash all together from there I'll be structure another one is replacing it with zero hash So yeah and Looking at the code. I've noticed that parity seems to modified RLP structure and we and go just Replace it with zero hash So we should come to some agreement here Yeah, so we choose to remove it completely because it seemed more cleaner and We already deployed it on common networks, so it preferred to keep it that way Well, I agree that removing is better It's it's nice to have smaller receipts I mean it will be kind of pointless to like put 32 bytes of zeros into every single receipt just because you know It used to be there so I agree with removing cool the CPP have any comments Okay, I think it's not going to be a big problem for us to remove it also. So yeah, I agree All right, cool Great, so that that part's covered So yeah, that's pretty much all of the Questions, oh there there is one on The blockchain and state route changes so EIP 96 I think it might be numbered 86 Pavel asked about keeping the address as a pre-compiled contracts continuous. Why are we jumping from? Contract 10 to contract 20 I can post the link to the comment But I was kind of curious about that too is there a reason right so my reason my reasoning for making them separate is because These like the gem addresses for a IP 96 like they're not it's not actually a real pre-compile It's just a plain old regular contract with a piece of plain old regular code That happens to have like a privilege that is in the protocol Like I'd be happy having the address be pretty much anywhere, but it's still a kind of different kind of thing Okay, got it sounds good Yeah, so Related question to this year P. So the contract is inserted into the state when the transaction happens and it changes the state route Is that correct hold on so You repeat that So the work has managed in contract when the metropolis transition happens Mm-hmm. It is inserted into the state and changes it Yes, it's inserted into the state in the exact same way as the Dow foreco moved either around so again That is in the exact same amount of possession Okay, so it's not a pre-compile. Yeah, okay Okay, great So the next item and the last official item are the metropolis updates So I think the best way to do this is to start with Dmitri what we're wanting to get with this update is figure out where each client is at and get an update on the test And we've already kind of another note I put in there was that some EIPs are accepted But not specific enough to form protocol consensus You know each you made that comment earlier. So what's the next action and it sounds like just cleaning them up So just being more vigilant and the EIPs to make sure that they are That they are matching implementation and The actual EIP spec So for this. Oh, do you want to have comments on that? Cool. Okay, so on the testing update Dmitri you're at the Berlin office, right? Yes, I'm here in Berlin. Perfect. Okay, so just if you give us an update on the testing Anything changed from last time and kind of the progress and where we're at Yes, it was a person who asked me to update the format of all of the tests So the so that test fields will be prefixed by Zero X all of the hex fields all of the hashes and so on so I was working on that and Mostly all of the tests now will be in this format and Some minor change about making all fields prefixed with zero X and You could see that and young is implementing this new changes to Create instruction and Yeah, next thing I'm planning to do is to make test coverage for this new EIP 86 realization of point three and four Okay, great. And then is there anything That we want to or is there anything that You need from the other core developers Is there any other comments you have about this that can kind of help you and is there a I don't know if this is really applicable because I'm not as familiar with How the testing infrastructure works, but is there a like percentage done for testing for a lot of these metropolis EIPs that are Completed spec wise Yes, there is a file on Google Docs that I posted you last time We're keeping updates to that file and you can track which test cases. We're already implemented same up to green And those that are right are still not done and should be done as soon as possible also the result to do At least and then The task that I'm working on right now No in the future Okay, great. I'm gonna go ahead and copy and paste that document Here Alright great, so Let me just make sure I can get out of this Oh, and I just broke my thing just a second. Okay fixed it now Okay, cool. Nick just joined Nick if you go into the agenda we just went over a Pretty much items one and two and then any of the comments that yoichi and Andre had So if you have any questions about any of those Let us know kind of at the end of the call that all of them are resolved pretty much All right, thanks. Sorry for my kindness and a problem So posted metropolis test so it looks like we have an update on that If there aren't any more general comments or things about that we'll move on to the clients so Let's see. Let's start with Go so the go client. What is the update on implementing Metro? I think there's still that PR with a checklist for what's been implemented, but are there any comments or Questions or any showstoppers for implementing it that you want to discuss? Oh, actually, I'm looking now. Do we have anyone from the go team? I Think Felix left That's me. Oh Nick. Yeah, duh So yeah, Nick. What's deep do you have an idea of the update for Metro implementation for go? And the last I heard from Jeff he was most more or less done. He's got two PRs out one student factor in one to the actual tropical stuff I don't have a more detailed and fighting to whether that's 100% or just 90% Okay, great. Yeah, that's that's that's fine enough approximation for this call and looking at the PRs I browse them. I think a few days ago. It's it seemed like it was more or less done so That's go now. We'll do parody Yeah, so we're mostly done. There's just one e.i.p That needs to be implemented. It is return data size or whatever Yeah, that's it. Okay, great and then We'll wait a second The Berlin team is got dropped off the call and then they're going to be added back on Jan do you have updates for the clients you work on? Well, there's no active development on Ruby server now and I and I and my team is working on PI server by serum has a I have merged state revamp is PV 62 branch and this running well on a server now There is a panel which is currently at about 2.7 million logs and these continue Processing blocks and they're and We are also we're working on that few to P we are adding an 80 Function to that P2P so so you can run a panel from a From your home from your home local network and we are adding concurrent synchronizing to That P2P of Python of panel so basically we are trying to We are trying to fix panel so it can keep up with other implementations I guess and then I Think we can start to implement metropolis features Okay, I started implementing at least some metropolis features So the revert opcode is passing all the tests Like there is an implementation of yeah of a EIP 86 although it is a bit old So I'm not so it may not be fully Compliant with all the latest stuff that we've agreed on but that'll be very easy to change once the tests are there um There's EIP in 90 96 and 98 are Theoretically implemented back from about a year ago when I was doing some Some tests for some experimentation for Casper, but it just needs to be like reparameterized a bit The the pairing stuff is like it's done as a piece of as a piece of code But it still needs to be kind of plugged in and made into a proper pre-compile then On the And there are a couple of yet. There is still a couple of the ideas that aren't done as well That aren't done. So static call is not done a couple others aren't done either Okay, sounds great Thanks for the update on that And then we have the Bart Berlin team back So if I could get updates on C++ and then Martin BZ if you want to give an update for JS I didn't Know if the priority was more on the e-wasm side or implementing Metro and that kind of stuff So we'll start with the C++ team They probably have some connectivity issues still in the room Here's a pile compiled the list of progress Yeah in general we kind of still halfway through all of them Three episodes still not started Three are already implemented and merged Several in progress. Okay, great. Yeah, this is this is a good list Cool So they're mostly all in progress and there's just a couple not started more than likely pending some of the final specs Great, and then if Berlin if you get back online just get off mute and let it let me know that you're on and then I can See about the JavaScript. Yeah. Oh, you're back. Great. Yeah, my Wi-Fi Cool. Hey, it's more to me. Is Martin there or Martin BZ specifically Right I'm just having working on adding in the back and the sliddy through building offer functions Look in your jazz You've been adding We haven't done any metropolis related work so far except I've done a little bit with abstracting out How the crack dresses are generated for the new crates But that's the only you know update for metropolis made in the last two weeks Did you hear this? Yes. Yes. I heard the whole thing. Thanks. Thanks so much Martin All right, so We have I Think that's is the dynasty clients. I hope I didn't Yeah, I think that's everybody and the taliki were the one who specifically raised the Point of bringing up Testing and specific implementations was this satisfactory or was there any other outstanding questions? I don't think there were any other outstanding questions. No, okay So looking at the date By the way, well once we wrap up the metropolis stuff There's an EIP 599 that Nick wanted to bring up and discuss so we'll get to that but as far as having enough time to Throw this into the test net And test on stuff. Should we what's the opinion of us starting to set some? More More strict timelines. What right now what we have is a kind of a tacit goal of end of June so What what are the thoughts on setting up either block numbers or getting some either dates or something together for implementing stuff on test net? Hmm I personally feel like there's still like there's still a bit too much uncertainty to get this To agree on hard dates right now. I mean I'd prefer that we make a that we make a commitment to just get stuff running and running and pass it and passing tests so to a within With like medium medium high priority and once it's working like we're either kind of All clear close to it. Then we can then we can agree on a date No, it sounds good to me. Oh Yeah, I'm from a from just for me you kind of stand I say just the end points I in Difficulties continuing to go up and that is content and that is continuing to make a leader launch of metropolis more and more and more tolerable by at least a couple of weeks so Okay, yeah, and then there's What you're talking about I guess is the is the block time changing Yeah, okay, so right now if we get the fork out by a June 20 I think June 25th then and the difficulty stays as it or the hash power stays as it is now Then the block time will actually not go above around I think in 19 seconds Okay, cool Sounds good. So yeah, that this will be We'll just kind of bring this up again next call and just recalibrate to see if there's any changes for specification needed Good Great. All right. So Nick You wanted to bring up EAP 599. It's in the all-core devs getter channel And I can I think I'll open it and paste it on the Google link as well, but go ahead Nick So this is a proposal to add a sort of a transaction time to live Field to transaction our LP The goal here is that currently Managing transaction pools is a bit of a shit show. There's no good way to expire out old transactions And that means that attackers can potentially Cause a lot more trouble in a deal from a DOS point of view than they should be able to they can span our transactions And as long as the transaction remains valid in this imbalance in the account We have no way to evict these spam transactions other than executing them if you attempt to evict them yourself Then chances are will just be relayed back to you from another node that doesn't treat it as an old transaction So what I'm suggesting is adding a field an optional final field to a transaction Which specifies that the transaction must be mined before the stated block and any transaction whose block number Is before the current block number is immediately discarded and may not be relayed and any transaction whose Include before block number is too far in the future should be treated as Sort of hostile and generally not relayed So the idea is that this in addition to making DOS attacks harder by limiting the maximum lifetime of the transaction also allows people to publish transactions that they know will either Be executed quickly or not at all, which is good for time-sensitive operations And that's it the I've tried to strike the proposal so that Existing transactions would still be fine. So nodes have to accept Accept blocks that contain transactions with far future time stamps or with you know block numbers or with no block number But they will generally avoid relaying them I Okay, so and this is I think that this was brought up last meeting right when we were talking about Handling transaction propagation issues. Is this in that same category? Yes, perfect. Okay So in this EIP is this something that you were thinking of having Is this in like metropolis or just something to kind of work on between now and when we would want to implement it I mean, I think it's reasonably straightforward. So Optimistically it'd be nice to include it in metropolis, but I think that depends on what you think of you know How can how contentious it is and what implementers think in terms of how hard it will be Okay, so I think that Yeah, I think that this can be brought up in more detail next meeting as far as this me goes Does anyone have any initial reactions for? Thoughts on it whether it's a good idea and complexity for implementation Yeah, so as far as implementation complexity goes I'd have a preference that if we're going to start mucking around with transaction formats to a greater extent than the IP 86 does then Like we may as well do it properly and what I mean is that we may like I have a as One example of a sort of thing that I would like I kind of change around transaction site transaction formats and the idea is that we kind of that we have a more kind of Regular way of including transaction version numbers and transaction network ideas Yeah, sure enough If you version up a draft tonight already or yeah, look it's number 232. Okay Great. Is there any other comments from any of the other devs? Yeah, I want to add a comment that I I think this change is also good for Dapp developer for for dApps because there's a problem for For the the system outside if there are now is that when when you send a transaction, you are not sure when When will your transaction be? Hmm be included into the blockchain and and until you see your transaction on the chain you you don't know If you should send another transaction or Or just wait so with such a Change, I think you can You only need to wait for a certain amount of time and and that's very useful Okay, cool. Yeah, good comment. I agree with that. I think it would be very useful So Just for the implementation stuff on this that this would require a hard fork, right? Yes, yes Anybody any other dev comments on this? So I feel we should do the the Transaction field simplification thing So I feel like I mean it was it was proposed by Vitalik I can't I don't have to link right now But I feel that you know, this would be more appropriate. So I didn't feel so transactions is No, I mean special purpose fields and special purpose fields the transactions is kind of Yeah, we're I guess from an implementation perspective I mean I wouldn't cause a particularly special purpose field But I agree that if we have an idea for a more general abstraction and that's better a better idea Okay, so so that would be just instead of having like adding a new field every time you want to add functionality but but just doing a Kind of feel you can put whatever you want and then have some standards around that Yeah, I mean there's So there's two ways of kind of abstracting this right so one of them is that we like do basically Nick's like Nick's proposal, but we do it in do it inside of My suggestion for Changing transaction formats and the benefit there is just that basically makes it easier for us as as protocol developers to Change transaction formats in the future I mean the other proposal is that we don't bother for now, but instead we make on the like maximum block feel a block number field part of EIP 86 transactions that we would And just like recommend people to add a checker for the max block number in the validation code Okay Interesting in general I Support the proposal so this is maybe Before but I do support this proposal as an implementer because There is really no way like Nick has has it right There is really no way to like put a limit on transactions at the moment And so this helps Well, I will so I'll read the talix 2 3 2 and reread to a to write such 86 and Update my proposal accordingly for the next meeting. Okay, great cuz yeah If we if we start consolidating the other EIPs that we're kind of trying to tackle similar problems I think that would be make it make it a better case to Include in Metro potentially Yeah All right, great. I'm also one other thing that we get of though is that There is another Given that we and if we do have a bit of time In one way that we could use that time is to include more but the other approach we could take us to be a bit more Conservative and like taking it taking extra was to do security audits of everything Yes, I'm generally on board with see the more cautious approach on the other hand I do think we do have a real potential DOS issue here, but we are fortunate. No, these exploiting so I think we have to lift a balance like if we can do it simply and in a way that we're confident does not add lots Complexity that it's probably worth doing right. Okay Okay, great. Yeah, so I think well when we have more information next meeting about the changes You've made that'll that'll help a lot and we can start making some firmer decisions on Timing of implementation since it seems like it's been accepted so far Sounds good Great, um, were there any other non-agenda topics or comments or anything anyone has Not right now Okay, great. So I think that's it. Thanks everybody for coming and Keep up with the EIPs It's especially keeping them updated and getting the specs validated so that we can start Sharing up the implementation and the testing on them So yeah, thanks everybody. Have a great weekend and see you next meeting