Ethereum Core Devs Meeting #14 [4/21/17]

today's mostly going to be about Metro uh but there's some other stuff too and yoichi had um some questions that kind of dive into how we're implementing some of the eips in Metro so that's the main stuff today uh let's start with agenda item one uh so that's going to be EIP 186 uh the last call we had talked about um discussing it a little bit further um between uh before this call to see if there was uh any other opinions and also to get some of the opinions of the researchers who were in Malta last time so uh just a quick overview of what's happened since then um 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 uh talking about it and you know there weren there wasn't a in my opinion a bunch of people who were looking to make that change uh there was still to me kind of a consensus around the the people who would implement the code that it would be better to be risk averse in this case uh for Metropolis coming up so uh let's start out with um yoichi and anybody in the F uh the Berlin office uh do you all have any opinions on it uh anybody who wasn't here last time or any new opinions [Music] I'm anyone to say anything maybe nothing oh say that one more time I couldn't hear maybe nothing nobody saying nothing anything oh perfect okay cool vitalic did you have anything I think you discussed a little bit on Reddit but uh what 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 back is that anything like is anything at least in for my intuition anything over two and a half is like safe enough but going beyond that will kind of introduce at least some risks um 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 and the reward is going to come down anyway once we start start the pro of Stak switch um so it's like it's it's not the sort of thing that uh let's see how should I say this like pract I mean practically speaking like the difference between cutting it down to like even to take the bottom and two and a half and F and just pushing it all the way back up to five um in inside of metropolis is only going to be something like uh a couple million maybe two to three million ether so it's uh 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 or applicable either way though on the other hand like given that we're going to be McKing around with mining rewards anyway and because we're delay delaying the Ice Age like it's I don't like I don't see an 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 um and 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 um overall or be delayed for a different thing uh does anyone else in the room have a different uh perspective or any other opinions no I'd say just uh keep keep an uncontroversial hard work as uncontroversial as possible yeah I I would tend to agree with that um so yeah I think that's the end of that um discussion point then let me see real quick something I just lost my agenda here cool all right so the next agenda item um so this one yoichi brought up um EIP 86 uh which is um talking about the create instruction uh he was saying that there were some discrepancies between the EIP poll request as written and the implementations across clients uh yichi do you want to expand on that a little bit yes so dcip is about uh account abstraction and as part of that uh specification point three talks about changing the way uh it calculates the address of new contracts but but interestingly it only talks about create transactions but not about create instructions so when the evm hits create instruction it does create something but it's not a create transaction so there's some ambiguity if this EAP changes both create transac and create instruction or it does just change the create transaction and we keep the create instruction as it is it seems like well literally the E text looks like looks like it changes only the create transactions not instructions but all implementations I saw uh kind of agreed on changing both especially the create instruction so I need some clarification Which Way We are following I me due to the fact that we also add a new uh creation op code in this uh proposal then the this means that the old creation op code retains its semantics uh so yes Christian made an argument for one option and that's why I chose the same in the yellow paper request 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 a clarification here changing the external so the create transaction is an external interface to ethereum okay I'm back to life great contracts Pon I don't think this one is working um could you what's that about new create up code uh yes so if this same if um talks about creating a new kind of create instruction uh where uh different sources can deploy the same code on different different addresses uh it's called create psh or something so yes this introduces a new instruction so the intention of the E seems to be that it create stays as it was before correct right and do we have someone who would Champion the case why create would change um so basically the idea in general is that we want it to be possible to or and like possible and very easy to have create they like have um addresses that are very specifically bound to one particular piece of code and so that people can either like send money or send tokens or do other things to those addresses before the accounts are are get created and the problem with the current creation contract creation approach is is that because the address only depends on the sender and the nons there's like 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 put whatever they want into the creation Cod is the contract code and it's still the same address either way so this would so this CIP would address as code dependent and this actually would allow you to create contracts where like the the addresses pH 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 um Regular ecdsa I might want to directly have a multisig or I might want to directly have something based on Lamport 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 um 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 uh basic and pay out of out of that money as if you as if you going to the minor um that that that story can go with the external accounts and the contra to both so uh so this kind of doesn't answer this specific question if the create instruction will 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 op code so part of like part of that EIP is um accounts that the the the scheme for addresses that get created externally gets changed um but as far as the create op code 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 um the scheme like the scheme works even if it's contracts that are creating other contracts and not just the like me mechanisms from the outside okay so actually I don't need really strong argument for changing the create instruction I just needed a clarification and I got the clarification now and I think this request text can be improved but I don't think that the already done implementations need to change that so I'm happy about this so uh I I'm I'm fine with this point agenda number uh three so maybe have something take take over yeah I just just to clarify uh you as I read the comment that you put on the agenda [Music] um so do these implementations these pull request change the create instruction or do do they add a new OP a new create instruction um they add a new create instruction and the old on yeah yeah so the old one is retained yes the old one is there but uh the old one create the old one creates accounts in a different position after Metropolis yeah no no the hold on the old create op code should still create accounts in the same position right oh on the same position okay then okay I misunderstood you in that case the CP PSM Pro request should be updated and the parity implementation should change the upod gets a new name but the same number did I understand it correctly no that's not correct uh the old create is still the old create okay create psh p2sh different creation address and corre me if I'm wrong so the behavior of the old of the old create op code is unchanged and a new create op code is created with equivalent functionality except a different address address so now I here the old create instruction will not change its Behavior I see okay then um with this I will poke implementers and say that and I raise issues and comments on Main the cpsm and Par I have a related question though um to this proposal um what happens if I could address a contract some uh and I later on self-destruct that contract then you can create yet another contract at the same address you can do that or you cannot with this with no with this op code yes so all right so you don't actually know that um I mean it can 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 there will be free ways an address for a new contract is generated first with the cre cre transaction and that generates an address from the code hash second is the create op code that generates it by R concatenate concatenating sender and what n and the Third Way is create a new create instruction that generates it from yes white can canate and sender and yeah okay that's clear and the second question I get 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 so the create instruction can create well basically doesn't check if account exists just checks for the code that correct yeah okay it's clear thanks okay awesome so the next item is so that clears up um what is number two on the agenda um change the addressing stre create okay so um yoi also had another comment in here about um 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 uh yichi do you want to just uh go through those as well so um there are certain accepted Ys and I assume we are seeking to implement those for Metropolis but some of these have some missing numbers and so on um so the first thing is for the elliptic curve related stuff um we don't have the gas prices yet and another thing is for the blockhead obstruction thing we don't still have the get Cod cold um okay so regarding the um 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 some like 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 veg Mar s on the go on like the parody version and the Go version and uh see like see how long it takes before we make a final decision that's reasonable okay so that so that that's kind of solved by just uh as things go on like it's accepted but then we're going to just tweak that at the end once we get the um stuff going okay yeah 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 no problem really um I I just thought we should have these text ready and pretty before we actually perform stuff that that that was my assumption and I kind of tried to find Okay cool so it sounds like um just looking over the list I the pairing check and the group Edition on elliptic curve are things that sound like it's going to come with time but that we can put kind of aemp value in uh the thing with the getter code on uh EIP 96 is that something that's the same case or something that can be answered for e96 it's um I mean I can provide a get I mean at least the one version of the getter code hold on let it should be up here somewhere I don't see I I don't see it right now but it but I can provide that that's fine okay sounds great okay yes Dam these points are resolved all right great so the next thing uh would be removing Med state from receipts um so that is EIP 998 which yeah EIP 98 it looks like there's a difference in implementation between um uh go and CP or go and CP plep do it one way and parity does it another so um EIP 98 is the one that makes that that removes the intermediate State Roots correct yes that's correct so um looking at this is there me see if there's any indication or Andre you're in the room uh would you be able to uh talk about what the difference is sh uh do you hear me hello yeah can you hear yep we can hear you um so there are two options in the EIP specification one is removing the root hash all together from the rlp structure another one is replacing it with zero hash so yeah and looking at the code I noticed that parity seems to modify the rlp structure and we and go just uh 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 Network so we prefer to keep it that way I agree removing is better it's it's nice to have smaller receipts I mean it would 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 I agree with removing cool uh does 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 um so yeah that's pretty much all of the um questions uh oh there there is one on the blockchain and state route changes so EIP um 96 I think it might be numbered 86 uh pavle asked about keeping the addresses a pre-compiled contracts continuous why are we jumping from uh 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 for the jump right so my reason my reasoning for making them separate is because these like the um addresses for a96 like they're not it's not actually a real precompile it's just a plain old regular contract with a piece of plain old regular code that happens to have like a privileged status 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 a related question to this EAP so the contract is inserted into the state when the transaction happens and it changes the state Ro is that correct um hold on so can you repeat that uh so the B hash managing contract when the Metropolis transition happens it is inserted into the state and changes the state yes it's inserted into the state in the exact same way as the D forco moved ether around so in that EX in the exact same kind of position okay so it's not a pre yeah okay okay great um 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 Dimitri uh what we're wanting to get with this update is figure out where each client is at and get an update on the test um uh 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 um yoichi made that comment earlier so what's the next action and it sounds like just cleaning them up so uh just being more Vigilant in the eips to make sure that they are um that they are matching implementation and um the actual EIP spec uh so for this oh did anyone have comments on that cool okay so um on the testing update Demitri you're at the Berlin office right yes that's right I'm here in bin perfect okay so uh just if you give us an update on the testing um 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 uh so the so that test Fields will be prefixed by 0x all of the Hax Fields all of the hashes and so on so I was working on that and um mostly all of the test now will be in this format and some minor change about making all Fields prefixed with z x and yeah you could see that and Yan is implementing this new changes just to uh create instruction and yeah next thing I plan to do is uh to make test coverage for this new e86 realization of three and four okay great and then is there anything um that we want to or is there anything that um 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 um 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 keeping updates to that file and then you could cheack which test cases were already implemented then game and uh those that are right are still not done and should be done as soon as possible also there is a too uh list and then that's the task that I'm working on right now or in the future okay great I'm going to go ahead and copy and paste that document uh here mhm yeah all right 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 um okay cool Nick just joined um Nick if you go into the agenda we just went over a um pretty much items one and two and then any of the comments that yoichi and Andre had um so if you have any questions about any of those uh let us know kind of at the end of the call but all of them are resolved pretty much all right thanks sorry for my cutness yeah no problem so uh posted Metropolis test so it looks like we have an update on that um if there aren't any more General comments or things about that we'll move on to the clients um so let's see let's start with um go uh so the go client what is the update on implementing Metro I think there's still that um PR with the checklist uh for what's been implemented but are there any comments or um 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 me oh Nick yeah du so yeah Nick what's uh do 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 uh he's got two PRS out one to do some refactoring one to implement the actual Metropolis stuff uh I don't have a more detailed insight into whether that's 100% or just 90% okay great yeah that's that's that's find enough approximation for this call and looking at the PRS I I browsed them I think a few days ago it's it seemed like it was more or less done um so uh that's go uh now we'll do parody yeah so we mostly there's just one EIP that needs to be implemented that is return data size or whatever yeah that's it okay great and then um we'll wait a second um the Berlin uh team is got dropped off the call and then they're going to be added back on uh Jan uh do you have updates for the clients you work on uh well there there's no active development on Ruby serum now and uh I am I and my team is working on P serum uh P serum has a uh I have merged state revent is pv62 branch and it's running well on a server now uh there is a panel which is currently at about 2 2.7 million blocks and it's continue processing blocks and there uh and we are also working on death f2p we are adding Nat uh function to that P2P so so you can run a Pineo from a from your home from your home local network and we are adding concurrent syn synchronizing to uh that P2P of python of Pye so basically we are trying to um we are trying to fix py not so it can keep up with other uh implementations like guess and then I think we can uh start to implement Metropolis features okay um I I've started implementing at least the some Metropolis features so the revert op code is passing all the tests like there is an implementation of e of EIP 86 although it is a bit old so I'm not so it may not be fully compliance 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 uh C some tests for some experimentation for Casper but it just needs to be like reparameterized a bit um 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 um then on the and there are a couple of the there are still a couple of VIPs 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 um thanks for the update on that um and then uh we have the Berlin team back so if I could get updates on C++ and then um Martin Bey if you want to give an update for JS I didn't um know if the priority was more on the ewam side or uh 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 that's true here's P compil the list of of our progress you I send the link so yeah in general we kind of still halfway through through all of them three IPS still not started three are already implemented and merged and soing progress okay great yeah this is this is a good list um 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 uh great and then uh if uh Berlin if you get back online just get off mute and uh let it let me know that you're on and then I can um see about the JavaScript oh you're back great yeah my Wi-Fi cool hey is is Martin there or Martin beey specifically what you should give an update about JS related activities uh right now I'm just adding working adding the backend facility through building hardare functions uh JS um we've been adding uh we haven't done any Metropolis related work so far except uh I've done a little bit with abstracting out how the account addresses are generated for the new crates but that's only update for Metropolis made last two weeks did you hear this yes yes I heard the whole thing thanks thanks so much Martin all right so we have um I think that's is that I miss any clients I hope I didn't yeah I think that's everybody and um vitalic you were the one who specifically raised the um point of bringing up um testing and specific implementations was this uh satisfactory or was there any other outstanding questions I don't think there were any other outstanding questions no okay um so looking at the date uh oh by the way what once we wrap up the Metropolis stuff there's an EIP 599 uh that Nick wanted to bring up and discuss so we'll get to that but um as far as having enough time to uh throw this into the test net um and test on stuff should we what's the opinion of us starting to set some um more more strict timelines uh what right now what we have is a kind of a tacet goal of end of June um so what what are the thoughts on setting up either block numbers or getting some either dates or something together for implementing stuff on testnet h i I personally feel like there's still like there's still a bit too much uncertainty to uh get this to 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 and passing tests so to within with like Med medium high priority and once it's looking like we're either kind of um all all clear or close to it then we can then we can agree on a date all right sounds good to me um yeah um from a from just from a kind of St Ice Age stand point iul is continuing to go up and that is and that is continuing to make a the a a later launch of metropolis more like more and more tolerable by at least a couple of weeks so okay yeah and then then there's um and what what you're talking about I guess is the is the block time changing yeah okay so right now right now if we get the fork out by 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 19 seconds okay cool um sounds good so yeah that that this will be uh we'll just kind of bring this up again next call and just re recalibrate to see if there's any changes for specification needed sounds good great all right so Nick um you wanted to bring up EIP 599 um it's in the all cord devs getter channel uh and I can I think I'll open it and paste it on the Google link as well but uh go go ahead nick uh so this is a proposal to um add a sort of a transaction time to live field uh to transaction rlp um the goal here is that currently uh managing transaction pools is a bit of a show there's no good way to expire out old transactions um and that means that attackers can potentially cause a lot more trouble in a do from a Dos point of view than they should be able to they can spam out transactions and as long as the transaction remains valid and there's some balance in the account um we have no way to evix these spam transactions other than executing them if you attempt to evict them yourself then chances are it'll just be relayed back to you from another node that doesn't treat it as old transaction so what I'm suggesting is adding a field uh an optional final field to a transaction which speci ifies that the transaction must be mined before the stated block um and any transaction whose uh block number uh is before the current block number is immediately discarded and may not be relayed um and any transaction whose uh include before block number is too far in the future uh should be treated as um sort of hostile and generally not relayed um so the idea is that this in addition to making uh do tax 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 um the I've tried to struct the proposal so that um existing transactions would still be fine so nodes have to accept um uh accept blocks that contain transactions with far future time stamps or with oh you know block numbers or with no block number um but they will generally avoid relaying them okay so and this is I I think that this was brought up last meeting right when we were talking about um uh handling transaction propagation issues is this in that same category yes perfect okay um so in this EIP is this something that you were thinking of having um is this an like Metropolis or just something to kind of work on between now and when we would want to implement it um I mean I think it's reasonably straightforward so optimistically it' be nice to include it in Metropolis but I think that depends on what implementers think uh of you know how how contentious it is and what Implement is think in terms of how hard it will be okay so um I think that um yeah I think that this can be brought up in more detail next meeting as far as this meeting goes does anyone have any initial reactions for um thoughts on it uh whether it's a good idea and complexity for implementation um yeah so as far as implementation complexity goes I'd have a preference that if we're going to start Ming around with transaction formats to a greater extent than e86 does then like we may as well do it properly and what I mean is that we may like I have a like as one example of a thing that I would like if I just sent a draft VIP kind of change around transaction typ transaction formats and the idea is that we that we have a more kind of regular way of including um transaction version numbers and transaction Network ideas yeah fair enough um do you have you written up a draft for that already or yeah like it's number 232 oh okay great is there any other comments from any of the other uh devs yeah uh I want to add a comment that I I think this change is also good for um dep developer uh for for DS because um there's a problem for for the the system outside eum now is that when when you send a transaction you are not sure uh when when will your transaction be um be included into the blockchain and and until you see your transaction on the Chain you you don't know uh if you should send another transaction or or just wait so with such a um 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 I agree with that I think it would be very useful um so just for the implementation stuff on this this would require a hard Fork right yes yes okay um anybody any other Dev uh comments on this so I feel we should do the uh the um uh transaction field simplification thing uh dead so I feel like I mean it was it was proposed by metallic I can't I don't have the link right now but I feel that you know this would be more appropriate so adding fields to transactions is uh General like I mean special purpose Fields adding special purpose field so transactions is kind of uh yeah weird I I guess from an implementation perspective I mean I wouldn't call it a particularly special purpose field but I agree that if we have an idea for a more General abstraction then that's better a better idea no 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 field you can put whatever you want and then have some standards around that yeah um I mean there's so there's two ways of kind of abstracting this right so one of them is that we uh like do basically Nick's like Nick's proposal but we do it in do it inside of uh my suggestion for uh 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 uh make um the uh like maximum block field block number field part of uh EIP 86 transactions that we would and just like recommend people to add a add a checker for the max walk number in the validation code okay H interesting in general I I I support the proposal so this is maybe was not clear before but I do support this proposal as an implementor because uh there is really no way like Nick has has has it right there is really no way to like put a limit on transactions at the moment and so this helps yeah well I will so I'll read vellex 232 and reread 208 20886 and uh update my proposal accordingly for the next meeting okay great because yeah if we if we start consolidating the other eips that were kind of trying to tackle similar problems I I think that would um be make it make it a better case to included Metro potentially um yeah all right great I'm also one other thing that we get though is that there's another like given that we and if we do have a bit of time before like bet becomes necessary and one way that we could use that time is to include more but the other approach we could take is to be a bit more conservative and like taking taking extra months to do security audits of everything yes I I'm generally on board with the the more cautious approach um on the other hand um 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 we have to balance like if we can do it simply and in a way that we're confident does not add lots of complexity that it's probably worth doing right okay okay great yeah uh so I 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 uh timing of implementation since it seems like it's been accepted so far sounds good great um were there any other um non-agenda topics or comments or anything anyone has not right now okay great so I think that's it uh thanks everybody for coming and uh keep up with the eips um uh especially keeping them updated and getting the specs uh validated so that we can start um Shing the implementation and the testing on them uh so yeah thanks everybody have a great weekend and uh see you next meeting next meeting bye bye bye bye thank you bye bye bye [Music]