All Core Devs - Execution #19

Transcript

[Music] [Music]

you've been listening to track number two from the album a future long ago by terracotta blue from magnitude com did you know that for only 299 dollars you'll get a lifetime access to the magnitude music library [Music] you

good morning can you hear me yes awesome all right I think let me see yeah we have enough people now all right we can get started good morning everybody or wherever it is in the world for you for the agenda the first thing is metropolis and the first sub item is Peter talking about a I P 86 or 208 transaction abstraction and specifically about how contract addresses cannot be computed

without a live blockchain and there's no guarantee that the deployed code is ours so Peter you can go ahead great both plane account I sent an old Dame

transaction to create a contract then the address of that contract will use the new scheme starting from an office and this actually has quite a few drawbacks one of the drawbacks is that this new contract scheme only depends on the unit code so the currency in the entire ecosystem out there every contract is based on some form of the owned contract which kind of just takes the message sender and the size that as the owner now since if I'm for example if I'm going to deploy a wallet that means that starting from metropolis if I don't specify some init code that explicitly sets me as the owner then me

deploying the wallet and somebody else deploying that the wallet will actually result in the same address same contract address now of course in theory one of it will fail for one of us the problematic part is that for example I deploy my wallet it succeeds then the malicious miner deploys the same wallet on an alternative chain and if the miner gets lucky and there is a reorg happening then that would actually result in I'm me losing ownership of that address now if I'm not prepared that such a thing can happen and I actually might end up not realizing that somebody else became the owner of the same contract that previously I was rightfully assigned as the owner so this

is one one of the pramatta quartz the other problematic part is that currently there is a lot of code out there that can actually calculate contact addresses client-side for example our repository also contains a code generator or binding generator which has a deploy function and when you call it it will immediately tell you that hey this will be the address of the deployed contract and then later on you can eventually pull whether some contract works whether some code was deployed to that address or not now with the new scheme that's basically not possible and the even though so the problem is that I'm

I cannot really decide if if the code deployed there is actually a result of my transaction or result of somebody else's transaction so this is and I cannot actually calculate what the final so I can calculate what the final address will be offline but I cannot calculate it I cannot you for sure say that it will be my contract so this is problematic because it's going to break every single client out there that depends on such logic and furthermore I had one more problem yes so the last problem was that from this point onward we cannot calculate contract addresses without having access to the blockchain because depending on whether we're in metropolis

or homestead the contract address will be different and this is again in my opinion problematic because I don't think any client code out there that does contract address calculation has an idea of what the blockchain state is currently they just think the transaction can or even they don't you don't even require transaction you just need an account and announced and you can get the contract address so these were my my issues that I see with with swapping out the contract deploy address for for old plane accounts and playing deploy transactions and I also had a suggestion how we could do this is that in here the idea would be that if the

sender of a transaction is the null sender then we can switch the new scheme whatever new way VIP figures he wants it wants to be generate new contract addresses whereas if the sender is not the no sender then we just keep to the old one and basically this could be enacted immediately because since nobody has access to the private key of the North's sender nobody will be able to hit the new account derivation path and inversely even if metropolis hits every code out there and that exists will continue to function properly because the only the only account that will actually break is if somebody is sending from a no sender but to do that you need

to actually send from Santa new abstract transactions without without the sender account and to do that basically then you must rely on the init code because there's actually there's no message sender that could differentiate the owner so that's in short yeah so I mean in general I'm definitely in coins to agree that making the new address scheme only apply to create to and to the specific notes and your case is the kind of much lower risk way to do it now the question is is

there any value in breaking the old scheme I'm I mean I'm inclined to say that there is a value and retiring yet eventually for simplicity but that probably should be a much further up plans much further out than the two months that metropolis will be for released in Russia but I'm guessing that eventually will be retire old accounts then the old address scheme will be retired at the same time because you won't get such transactions so it just answer to me that while we are supporting the old type accounts at all type transactions it makes sense to keep

the old functionality as is at this point simon cuenca totally agree and i think a bad idea no I'd like to speak out in favor of it I think it's a really good idea because yeah there are really sneaky sneaky catches with the way it's current at the post I think it's really good good of you let you call this sorry I know the problem but I missed a new idea what's for the biting suggestion so the suggestion was asked for for all

existing plane accounts and plane transactions we keep the current addressing scheme and we only switch to the new addressing scheme for create to and and if somebody's using the no sender meaning a new transaction I'm worried these problems I'd like that world that will alleviate the immediate issue but I'm concerned that these problems will extend to effectively any use of the new scheme and like we need to back off and see whether we can and also that as long as like we're still gonna have the issues with transaction IDs know that unique

and addresses as long as possible transactions nothing and you issue that we've been discussing maybe Nick you can quickly summarize then because that's a different issue well I think it's well it's tied in anyway I guess my concern is that we've been adequately explored the consequences of breaking a couple of key invariants and a theory and one of which is that transaction IDs refer to and using zero or one executions of the transaction and one of which is that addresses that have code that code never

changes except to be deleted and I I worried that these new changes will have a big impact on the ecosystem particularly the one about transactions between having multiple executions yes there are there kind of I guess multiple things to discuss here one is if we should make some change to a 208 in favor of like Peters suggestion the elegance of that in my opinion is that

we could basically implement that right now and roll it out in the clients and it doesn't have to have a hard set number where we roll it over and just take it out and the other is that there are some of us are concerned about the general EEP 208 in general and the consequences in that so it's kind of two separate discussions I guess does the parrot the team have anything to any thoughts about these issues so yeah I

would agree with Peter on the particular issue that he has mentioned and regarding the transaction possibly being and possibly being able to be mapped to multiple executions I'm not sure well I personally don't see that very much of an issue as long as there is a notion of canonical execution what the canonical execution how do you define it well that's up to a minor and guess whatever

reg expose use object in a transaction basically they have to decide if a second execution will be profitable to them we are we open up a vulnerability where a minor could for example execute the transaction 10 times just to screw with the clients so to give a concrete example say you're sending funds to an exchange and for - first - the transaction before it's time that nonce which means it's inclusion of locals no effect and then later at the undefined time determined again and has a fix and

they haven't exchanged know whether the transaction went through and for example if if a minor Minds transaction that essentially reverse now the exchange will see will think at least that the transaction failed and maybe the minor will add it half an hour later and if the exchange doesn't know that the transaction that previously was failed could actually get included later than it might be really messy I mean we already talked about that some

meetings ago that the so this they that account code should signal one of three situations the first situation is this transaction is invalid and you can delete it from the mempool order or from the pool - yeah transaction executed successfully and minor got rewarded or whatever and three transaction execution is invalid but it might get valid in the future and I mean these three cases can only be detected by executing the transaction I remember that we talked

about it but I don't remember it's this little trick thesis is there documented anywhere how how what their day is how to implement that yeah I have the notes though let me find those now put them and get her in the chat and the successful version is obviously no reversion and the - and we have basically two different failure cases and I would say in both cases we have a revert with a different gap error message revert theta then again what happens if a transaction

can be executed multiple times successfully let's say three times I mean that that will we cannot sort successfully so yeah sure what's the problem assume you have an account which does not use a nonce scheme then that's what will happen I mean I don't know a faucet for example a faucet could be an example so one here one real one realistic example of a literal with the exact same transaction being executed multiple times that I couldn't see happen eventually as if there's some contract that triggers the alarm clock so let's say if there is some contract

that basically just triggers some some bounty in exchange for pinging it and getting it to do your stuff and then the party that would most efficiently be able to do the ping is basically miners so what miners would do is they would just include a dummy transaction with no signature that just includes that to add that to address and then the year contribute that transaction pings the contract it does its thing the miner the miner gets paid and that's like a blob of data liquid getting queried a bunch of times yeah in this specific scenario we can have actually multiple canonical executions which means the entire

ecosystem needs to be aware of this possibility so we are kind of just worried of the implications and we should probably try to figure out what right this would be on exchanges on various participants in the ecosystem so I yeah I mean I know that in G in general if like users should be able to in users should be able to insulate themselves from the possibility in a lot of cases so it for example if you have a

regular account then none of your transactions will have multiple canonical executions and so what could happen is multiple executions of a transit of a transaction gets sent where both of those executions lead to your own balance being increased yeah although I think in general like if like it probably I think it is were it

is probably worth it to think like basically major use case by major use case but like in the case of its in the case of an exchange for example if it ends up getting money because of a transaction being repeated twice then the way that the exchange so it should securely implement itself yes by out looking through is by looking through logs and like the log would quit in the log would clearly get triggered twice and appear in two different places but realistically that's not how existing exchanges operate today mostly still right I mean oh yes we current exchanges operators so basically in a lot of them

yeah they just look at transactions and so if you send money to them from a contract then like if they have no idea the deposit happened until the next time they do with just an entire balance wave which might be once a day so I'm not Shh like that's a status quo that I think I'll end up existing with or without anything we do at least until we manage to like get VIP 86 accounts fully adopted with logs inside of them by default I think it's I mean the thing the main thing would prevent exchanges from adopting more sophisticated ways of receiving funds is that most wallets

don't support them were sorry not most but a significant number of wallets only supports in India transactions and historically hasn't done a very good job at seen enough gas for the long calls to execute and of course they don't ones deploy a copy of the contract on every single user a trace when they and we've done this try and seem to have and then there were other days is where you transfer not ether but tokens and they'd have no I know ability to have the custom logs well in that case though the token contract itself is supposed to log the arrival yeah hopefully but but they can't the exchanges can't really enforce that well they can't they can refuse to list any token but doesn't lob correctly I'm just

I I increasingly think we have to find a way to preserve the invariant that a transaction ID refers to a single execution I I worry the first will disrupt far too large proportion of the ecosystem hmm hmm were there other comments on on this I mean what happens if we require okay sorry yeah we have to so to enforce that

with new cell accounts we have we can add the requirement that transaction IDs are unique which yeah but then like how do we do that without anything basically an entire like ever-growing map of transaction ideas some words for the state exactly that's what I want to say and furthermore we also have to require that transaction included cannot revert so at least these new star transactions because reverting is their way of signaling the nonce is not correct or whatever they use so I think that's really hard to achieve new accounts I don't thank you well yeah I don't think you necessarily have to enforce it they

have good but you have to have so I mean you need you don't and you don't necessarily in math and world transactions but it means you need something like a nonce or a hash of previous transaction or some other field that can't be repeated hmm I mean the other thing that we the other approach is to try to resolve this at like eventually I think it'll have to be resolved at kind of higher protocol layers at some point so like for example ik for example something like again instead of just providing a transaction as you might provide a transaction hash

plus what number in transaction index or something similar though like I mean like the machinery for that would take a would take longer but it does seem like they're sort of more general solutions but I mean the the deeper problem here is that the transaction has should already be unique even for transaction not including luckiest or is that not an issue yeah - 18 - things that are being identified really there's the transaction which is the message and

then there's the execution of the transaction and currently those two are synonymous because every transaction is at most one execution the envy and that's the illyrians we're breaking in why you know so mainly you to some degree we do already have a stable identifier for the exclusion which is for Teleca to choose block number across the transaction ID or a block cash plus transaction actually it would have to be a block cash actually because I've always a real will invalidate it that's not how much smog refer to a

transactions in most systems I suspect index transaction executions by transaction IDs the specific assumptions well only meaningful way because so if I create a transaction I know transaction hash but I don't know anything else so I need to be able to look everything else based on the ash what would be the consequences of requiring new-style transactions to have an honest but still allows verifications

so basically like requiring new-style transactions to having nonce and like which which nonce would it be though like what would the rules for the nonce be so the north's would still be specified in the outside transaction but the rules for validating everything except for not remain count so that sort of basically like they would do what like you would check the nonce against the two accounts and then you would increment the nonce of the two account yes I mean if absolutely necessary that does solve the problem although in the

long term I would very much like to try to move away from just that sort of stuff being necessary and my own inclination at this point is well it may be possible for us to break this variant of our transaction IDs in

the future I don't think we have enough time tomorrow before metropolis to consider it seriously enough to make sure we're not going to break things and I don't think the community places like exchanges Neath the scan and so forth have time to to fix their assumptions about this invariant and with this only apply to account abstraction or the AE IP 86 I mean yeah okay okay so we can bring this up at the EIP

level but yeah it sounds like there's enough concern that it's warranted to look at that again I would say does anyone else agree my weight I think Mick's proposal might be a good compromise in that you keep the uniqueness invariant but you can still you still achieve every other flexibility at the IP attempts to achieve the exchanges what what what what one question without up with that approach though which is that if let's

say you send a transaction and a malicious minor in includes all right know that never mind it but if you send the transaction then like it would be an it would still be it will become invalid to do things like including it out of order yes so that will enable miners to effectively change other countenances right right yeah no so this this definitely is a concern so what miners

would be able to basically include m86 transactions going to arbitrary accounts and those accounts would be able to you know and like they'd be able just like arbitrarily push their nonsense up in that way make sure it's actually would require people to resend transactions so it's the best course of action taking this to an EIP for some type of proposal will be written up by Nick or anyone concerned or is there a an alternative

way to deal with this I don't really think we have a solution ready for this it's just a concern yep okay sounds good all right I think we should move on in the agenda regardless something though I think as we go on let's revisit this near the end so that if anyone else has any further comments and then maybe by then we can no one's gonna have a full solution I'm sure but we can still move on from here and then come back to it to say what we're gonna do so I believe that goes through agenda items 1 & 2 Peter is that

correct that cover kind of all your comments yeah all right great item oh well there's a second two in the agenda I'll have to fix that but it's the EIP 86 so same a I P and this is about the ECDSA account abstraction and transaction origin I don't think Jeff's in here but can anyone speak for any progress that's happened on that discussion yeah I actually haven't had a chance to look at it so we might have to skip that if Jeff's not in here all right cool yeah we can just skip

that one I think there has been some discussion back and forth that let me see what the last comment was cuz yeah I think there was like some people who still wanted transaction origin oh yeah actually the last person who mentioned it was let me see let's see yeah the last person who talked about it was Jeff about a week ago so I'll I'll get back with him on that and just see if he has any other comments or stuff on that the next one is the difficulty bomb a free from the parody team and Stack Exchange

pointed out that we don't have an EIP for the difficulty bomb so does anyone have a recommendation on that and actually before even that happens can anyone answer me would that be related to EIP 186 with the eath issuance or is this gonna be a separate thing so I think I may have made an informal proposal at some point which is basically that we substitute in the formula that computes the difficulty we replaced for the block number with a function that says if if premature Oppel is takes the block number if post Petropolis take the block number - like two million or two and a half million

and this basically like just cleanly delays the thing but like a year to a year and a half or however long we choose that sounds reasonable I was gonna say it - discontinuity because we wanted to continue to say yes okay sounds good any other comments or suggestions on that otherwise we can I actually am NOT even positive that should be it's an EIP well I mean hmm I guess it needs to be because it's a whole separate thing we're doing it's not really related to any of the EIP is

going right mm-hmm cool all right any other comments on that otherwise we will get a PR together once and actually you have the Vitalik if you could summarize that either just in a comment on the EIP or something or write your own niar for it that I write a comments on me I'd be 649 exactly or or open a PR for it I didn't know if a free was going to but so you know one of you can all just comments for simplicity all right great thank you okay that's all for a and we'll go back to 86 in a bit so topic be under metropolis is

updates to testing so two weeks ago we hit the ground running on bringing in outside collaborators and new people to help with testing and so I believe both yuuichi and Dmitry are here so we can just have Dimitri start if you want to give an overview of some of the testing and people coming in and then I'll have vo Ichi and then Martin if he wants to chime in as well anybody who's been involved in that so Dimitri go ahead I'm human yes I can hear you again I want to be focusing on Justin the only happened know to request 218 comment line

interface of this and being open aspect or channel and return we both get in Skype of the newcomers currently I'm working on updating watching test [Music] [Music] yeah I can show him in on that so the first testing is basically that we can

do directed passing against the EBM binaries which or there's a common common format implemented in guest and parity and also by aetherium without house it was plus yet and this test will be a lot means it will of lighter and quicker and then the existing as processed with on your crafted test and I'm hoping that Matthew frontier can help out and join in on you doing this setting up these tests as there is a new feature not exactly new visit that if you could know and use randomly

generated much code for EDM we should be a correct code with random of course okay so I think yo Ichi did you have any comments or comedy okay great oh and lastly on the the testing piece Casey just released a post and a walkthrough video that's really good

about testing with aetherium JSK see if you want to just give like a quick overview of what that's about and how people can look at it I'm sure it's just to kind of celebrate the milestone of reaching homestead compatibility on the theory I'm Jeff VM and trying to encourage contributors to help out with getting up to Metropolis cool yep so that's um on reddit right now and yeah it has some good links if anyone wants to jump in and get involved in that so yeah that is pretty much it for

testing was there any other comments on that great the next is the details on implementations of the e IPs I think death and parity are pretty much done so just looking here I'll just go ahead and say so parity are there any problems issues or questions with how you guys are implementing e IPS or is it pretty much the same as last time great and then Peter guess that's best for us so if you look at that here it's

quite a massive PR from Jeff and so it began reviewing it it turned out that it's a bit large and sing up you are so what we're mostly splitting it up into smaller pieces and we would really like to start merging in the individual pieces as we go along so basically we'll probably speak the easier PRS which probably won't change I mean easier a IPS which probably won't change anymore and just start working those as two just so that the code base doesn't diverge so that's mostly what we're doing great was that someone else have a comment or was that background noise I couldn't tell

alright great C++ aetherium a Christian or yeah yes Christian I think Android has a better overview oh yeah that's right sorry Andre grew up code made some improvements in cash donation some fix instead of call so general currently we are also done with all the ABS and waiting for the finalization by the way the static code change did you make all the other clients aware I don't know much about that maybe you know something

i-i-i was wearing the head of one and i've talked I'll hit the phone and the song when Christian asked a tough question what was the question Christian there was a subtlety in in static Hall which was implemented incorrectly and I wonder whether we made all other clients aware yeah I haven't done anything yes I I think I should take we keep the new test in the develop branch of the testicle story in form of general state test

so other clients call running tests running from develop and there are any changes so you could ask on skype that channel cosa and once we've been updating that she'd be here on we also update the test and you could see if you have any changes in the test problems ok um sunset I think did that answer your question I forgot who asked it at first actually it was just kind of a ongoing conversation ok yellow paper so yuuichi it's done except for the guest host of

elliptic curve additional scalar multiplication okay great that'll be the next thing we talk about is gas price estimation oh and then finally pyah pyah Thap or pi aetherium actually Vitalik what do you prefer for the Python client to be called because I've heard PI Thap and PI aetherium and no sci-fi it pi etherium is the library pi e that is the client that connects to the network okay they just PI a theory it was probably easy ok cool so what's the update on that I mean it's passing all pre metropolis tests I've also used it to implement

stuff like in you know like an on disk state cache and state tree pruning and that seems to have had fairly fairly good results and it's surprisingly not that complicated it's I mean it was passing a lot of the metropolis s so though more recently I've kind of let that sweat back a bit on that because I'm basically just like waiting for C++ to her for like all the C++ tests to be there so I can just try it against all of them all at once and also I remember that like last time I checked there were a few uh there are a few tests that I ran into where I was failing and when I dug into them it was because it was C++ that made the mistake

and I've been waiting for a C++ to basically fix the missed L we statistics that I know about so like one of those for example was that I think there was one test that revert a some kind of operation that basically that of what's a new conscience any piece of contracts go it in place and a like it was what like it was this weird it's this weird edge case where you have a contract with code a that the contract suicides and then the something else with code via gets

and then if both of those operations get reverted then like what should happen is the code changes from B to a but instead of change in C bus twice it changes from B to zero you good from the okay did you say that was fixed Andre okay great no okay then great all right cool so the next thing is determining gas prices for new opcodes martin i saw you were starting to do that i think someone else might have commented on that to our Arkadiy might have had some stuff so martin since

you've been talking about it the most i'll let you take it away yeah so this is mainly just a discussion point we've started getting we have some benchmark data enough for go ethereum Arkadiy reduce some similar benchmarks for parity I think someone somewhere generated or receive a key and kind of the question is how do we move on and actually determine the gas prices and when did we decide on that I think I mean it's a it's an implementation details for the client developers but I think for generating the test cases it would be good if that could be kind of set as soon as possible hmm as far as

organization of the conversation goes yeah basically as a comment and the EIP might be okay as long as we stay diligent to look to see who's agreeing on one on the gas prices is there any others so Javon for something like this it could even be as informal as just being in the core devs channel so yeah just I don't really care either one would work for me does anyone have a preference or suggestion [Music] Daniel Daniel your bike is a really really scratchy and loud yes works great go right ahead okay so I made the

comment a few weeks back about the s price of the modular exponentiation that it shouldn't be the modulus into yes I wanted to measure that but I need someone to provide me with the inputs today with the benchmark the differences Teli repeat your question again please I didn't look at it okay so I made a comment a few weeks back on the on the gas price of the modular exponentiation

that it shouldn't be quadratic in the modulus because the most of the libraries of arbitrary precision arithmetic for the kind of numbers that we're talking about they use the karatsuba methods for multiplication in exponentiation as well so they so that is much less not quadratic in the length of the modulus and I think it would be unfair to penalize people for using safe and long modular and encourage the use of short modular with the basically what amounts to subsidized s price which is what happens if it is quadratic in the size of the modules I think it was

Martin who said that he's going to benchmark it to see whether indeed it grows slower than quadratic with the length of the modulus but at some point I think this project either got dropped or get stuck on some impediment that I'm not aware of yeah so then thought about this that I made the benchmarking framework but I need the I'm not the mathematician so I don't really know the inputs to to actually submit to measure the the inputs that you want measured so we need a little feedback on that yeah I can provide that although actually I think there should be some

pretty decent inputs inside of the pie aetherium tests already I can see if I can grab that freaking file tests to actually say let me I'll just first check the Python file to see if there what the okay yeah so right okay so we have some tests for the around 2 to the 256 we have tests for around to your low 1024 I mean like basically I think the

simplest thing in the test is just like make a make a ransom number of n bits and then raise that just like I mean try raising it to the power of 2 treiber's get to the power of 3 try raising it to the power of like some I know a billion and then try that with the various lengths going from let's say like one byte 32 bytes all the way up to 4096 bytes yeah that sounds reasonable and I think that will dip will answer the question okay so yeah Martin I would say yet if

that suggestion works great if not I'm sure Daniel can like give you some feedback as you're writing that particular test yeah when I write now I can I can look back with Daniel and italic alright thanks everybody the next point is let's see so yeah we'll continue to talk about that in the core dev channel and it sounds like we'll just determine what the gas prices should be through the test cases but also if if we can do comments and the EIP that'll probably be the most coordinated that we can get for that the

next point is to review the time estimate for testing and release so I think Vitalik do you happen to have like a new number on block times for the next few months yeah I mean I did I actually updated the numbers yesterday well let me rerun through that script yeah and while you're doing that yeah so our below currently 17 seconds they they will go they will hit 22 seconds at the at the end of July so on like basically on August 1st and they will hit 30

seconds on August 28th and so they will go above 30 seconds to 38 seconds on October 1st hmm okay testing team anybody on the testing team is what's the feasibility of releasing this by September or is there a what's the progress on that how do you like to see the fastest being implemented in working on the client is a pasta thing you could cover more cases that when we run the greatest by hand okay Oh could you repeat that first

part it cut out for me a little bit yeah I would like to see us testing being implemented and running against other clients or at least a couple of weeks we could see how the clients work on randomly-generated okay yeah I understand that so as far as tests being completed for different AI peas or anything this this might be to like there might not be a good number for this but is there an estimate for how far along we are in total for completing different tests for EIP s the clients can run okay I think that oh yeah does anyone have opinions

on kind of a release I think that one thing that might help is to really wrap up especially EIP 86 which will be going over again and a little bit but I think some of those have been somewhat dragging on some of the progress that we would be making on tests I mean I'm not actually doing the tests so I might be completely wrong on that but um I think that's good that we close this out kind of like the EIP freeze that you she was talking about before but more of an informal freeze for some of these and I know a few of them are closed so that's that's good but the the IP 86 is a big one that deals with a lot of different

things so so we'll go ahead and just III guess I should say this who does anyone think that it's still okay to give a estimate of potentially doing the test net August and potentially releasing September like just kind of around that time is that sound doable or undoable to anybody in here I think that's mostly depends on when we can finalize the IPS because that so that account abstraction the app is really not video yeah I mean help for the account abstraction yet p.m. you

know I can personally dedicate a lot of times of thinking about it and giving a recommendation which will possibly be either introducing it in a limited form or basically advocating for going all the way and removing and removing at exid uniqueness but delaying the whole thing until until the next hard fork yeah I was I was gonna erase that thing again and we took focus a couple of months ago and I asked if there was any kind of thoughts if we would roll out metropolis as too hard works and I'm starting to consider that being an option you have a first hard work where we do pre compiles everything that's

really not not as but pretty easy to test and very well-defined on how to implement and then have second heart work with abstraction yeah I mean because you know our backs against the wall with that with the time bomb yeah so I had so like one example of an alternative Road for AP 86 and this is one that I would early came up with during the course of this call is we would add an invariant that says you can't have two distinct two transactions with the same TX ID in the same block then he would require the S value of an EIP 86 transaction to just be the block

number and then you would basically you're just four people are using the ipv6 transactions to just send out a bunch of copies for like block numbers that are beside each other so like there are those kinds of options but basically my concern is that if we're going to do like if we're going for whatever if we end up doing a staged rollout of the IP 86 itself then if I'd prefer like stage like stage one should be forward compatible with stage two and if we can't achieve that then it would be worth like basically delaying the whole thing until we can properly you all proper release of it all at once when you say the whole thing do you mean

the entire hard work from metropolis are delaying that no I mean like so like I mean an EIP 86 plus the machinery required for users said handle it safely and preferably even like actually do things like make accounts with it yeah I mean this also presents another opportunity because I know there were a few other AIPS that didn't make it into metropolis but that could be potentially look I mean that would that would be kind of a slippery slope to start including more AI piece for a second quote metropolis yeah fork but I like the idea of two forks mainly because it's editor of iterative rollout of features and this is a real big feature

list with the number of VIPs we're dealing with so mmm whoo is there anybody who wouldn't be in favor of splitting metropolis into hard Forks and mainly to get the difficulty bomb diffused but to have a pretty a pretty firm deadline on getting the second one out remember long time ago it was made for adding changes to the p.m. not by heart works but by air people are almost like havin small EAP proposal it's easy to implement and make a smaller heart work than a huge charcoal with lots of changes the first time we were speaking

about this I think one of the one of the suggestions was to focus on the their line and see what we can get ready so there are multiple things that can go into metropolis some are simpler some are more complicated can't we just try to figure out what what we could start testing right now so that we will be confident would be ready by September so we keep the city we keep the date fixed because that's the that's the ice age we know that at minimum ice age fusion would go into that hard for but we start coming up not exact with all the changes that we want to get in just for instance Zeki is not a free compiler is that

something that relates to the other ones and we can change you can see which I ideas are simpler or more easy to test and make sure that they are ready by September and to be ready by the time dirty they must be testable by August or July yeah I think that would be fine so and I guess yeah that was a good question Alex the does I I guess II I P 86 if that is taking if that is taken out of the first of multiple or two hard Forks would that affect any of the other AIP is going in and pretend particularly the pre compiles and it would technically make some of the privacy feature is

marginally less useful basically because like if you have a break signature then if you if there is if you can't do things like spends from a reg signature using a null Center then you would basically have to have ether in an account and then that that ether an account could be a privacy leak but like that's only well that's only one of the use case of the the sort of tech so V not necessarily because it is already possible for you to send and interact with a contract without having without having it your own account by signing a message and having the net contract read

the message and you can even add some other some other feature where the contract will spend a little bit of easier to the person selling it so this is yes for worried about yeah no I mean I agree that that's definitely possible which is why I say marginally like the basically the reason why that approach is like in is not optimal as there's two of them right one of those that you just you would have to rely on some third-party intermediary Taito to an issue a cough up the money and the other one is that like you still incur I'm easy I mean efficiency because you're like pointlessly verifying and EC recover are an ECDSA signature on top of

the rank signature so it gets not optimal but I agree like it's totally fine as an initial approach yeah it's not optimal but it's not broken and it's something that it's not and also I would disagree I granted the third-party for that but I can find a whisper message send a I can find a method energy a whisper and have a contract say the first person to put this contract to put to pay for this transaction who get Exeter and then you have you're not relying you have you you can have a bunch of competitive competitor services listening to whisper messages and paying for okay um so yeah

I think that I think y'all are both saying pretty much the same thing that it would just provide one less specific use case but that it can still be achieved or the ring signature a situation that y'all are suggesting could still be achieved through a different means and so that would just be making sure that that the community and anybody who is implementing these is aware that it is not fully it does not have all the original promises yet because it would need to be further shirt up in the next the hard fork after the next one for the features of VIP 86 to apply to the features of the pre compiles that effect ring signatures so

yeah that doesn't sound too bad at all yeah so I think the too hard fork idea is good I think between now and then we should definitely keep discussing EIP 86 but there's enough that's that there's enough at stake and that affects enough of the future stuff with serenity that I think it deserves a second hard fork now that I'm kind of thinking about how complex it seems to the heart of the tests should be fixed for that currently all the tests assume that there is only one heart for metropolis so splitting some of the changes away would mean

every general state tests will need to test more network so this is global change that takes maybe a little bit of time maybe a week or so digest so you each in your estimation would what what's your opinion on the one verse is too hard for kind of understanding some of the stuff that's going in and how the tests have been written from from both sides so Dimitri has already given an estimate that the read is a time' dvds would be possible and that's assuming

only one kind of agree with that so I'm not saying that need of it right now at all I might mistake that 86 is not so problematic I believe so but maybe I'm wrong if there's big big concerns about if 86 or any of deep some yes that's an option it's an option to split out data yeah I don't think splitting it into two hard Forks is ideal but it's gonna depend on between now and the next core

dev meeting how much gets accomplished with the dialogue for some of the she's brought up by Peter Jeff Coleman and Nick so I think that my suggestion would be that we all focus on e IP 86 between now and next meeting because I think there's a good chance we can work through a lot of the thought behind how to solve some of these problems and then if we can do that then having it be one hard fork would just go ahead as it's been scheduled because if we can finalize 86 between now and the next meeting in two weeks I think we'd still be on track for one hard fork and if not and it like is determined that there's a

lot more complexity or problems than initially anticipated then we can discuss the too hard fork thing again the next meeting any other thoughts on that I think that sounds reasonable yeah all right great so yeah the summary of that is there's now the potential to be too hard Forks that's likely not ideal for rewriting tests and a few other things timing wise and it would just kind of put more stress on having to do that just because hard Forks are stressful currently until we get on a on

a rhythm so yeah we'll talk about that more in the next meeting and until then focus on e IP 86 to solve some of the problems I might even try to make a list of some of the unsolved issues and questions regarding 86 and put it in a comment and put it in the core dev channel the next thing is the oh I have gas limit increase update I think everyone knows about that though a few of the mining pools targeted a much higher gas limit in the six millions so the gas limit has been rising to that level does anyone have comments on that because I saw there was some discussion back and forth on some of the mechanisms behind the block gas limit increase and

if it would be a good idea to change that I think Matt and metallic and a few other people were talking about it yeah so I basically just raised the points that it's the guy even though it is like a 42% gas lemon it's not really as significant as departure from status quo because it's like half of that is only counteracting the capacity decrease we've seen because of the ice age so far and the other half will basically counteracts the capacity decrease we'll see from the ice age until we do the metropolis fork and hopefully by the time metropolis actually hits will have sub ma will have a bunch of optimizations in the column in the clients and that are currently and that

are currently in the pipeline so I'm not I'm not like personally worried about the consequences of making the gas when we go up the um as far as mechanisms go like basically I think the concern is is that we haven't really seen the like the automatic adjustment mechanism doing a very good job and I think the reason basically is that in order for that becket ism to do a good job first of all either literally everybody has to be complying with it plus with the watch it needs to be two-thirds full or two-thirds of minor C to be complying with it and the block she needs to be

hundred percent full and realistic will end up having slack in both dimensions so one possibility for example is that instead of targeting one-and-a-half times the average usage we could target twice the average usage and this will make it be more more willing to go up to go up during high load if that if if that's what we want the other thing that we proud that at least I want to see more discussion of is like some of these more interesting dynamic proposals that basically say keep voting the gas limit up but then if you see a block that takes more than let's say one and a half seconds to process then cut your target down by a factor of two and then just like what the thing fight its own

equilibrium I I really like that idea although I think it needs to be restricted to only voting it up when your blocks are full because otherwise if something works idle for a while it will implode it up to the next and when you say like judging by the prick by the previous processing time is that like based on your own client who's mining the processing time cuz wouldn't that have like depending on what you have that that could that could ski things I mean yeah so it would it will totally leads to different clients just voting for different things all over the place I like the goal I think is for it still leads to an equilibrium that generally satisfies most miners okay yeah and so

for something like that that would just be like a new EIP that would could eventually be put in but from what you said earlier and I think from what other people have said this isn't something that is bad enough that we need to have that be our focus over anything else in Metropolis right now yeah yeah so it's not a protocol future right it's just something that guess what I have to do imperative decided to my strategy oh that's right but even if you change the default mining strategy unless you're forcing a reset every time they say boot up to a updated gather parity node that they would need to change it themselves right and the suggestion was to actually change the gas dynamics in code into the

clients so that they adapt to be different Oh Oh yep sorry and Arkadiy do you have any comments on that from parodies and I just want to say that I'm pretty sure most mining clothes override the defaults and specify them they were for a secret yeah I think I think what the problem with that is mostly because so mostly fools define their own because the defaults are actually sensible enough for example during the dus attacks there are problems that blocks

took five seconds to process an hour obviously arriving fools are angry about that but if the algorithm would have adjusted automatically I would have brought down the gas price gas limit to half of it then maybe nobody would have cared so it's again I think I think it's a nice thing to actually to give a possibility to the miners and obviously it's up to them if they take it or not okay but yeah that is something that can be changed at the client level to at least anyone new coming in or updating who hasn't done their settings could have those new settings okay or I guess that's more yeah that yeah that's for both clients actually all right cool

okay great I think there'll be more discussion on that than any other comments okay and then the last one the IP 186 reducing the etherium issuance before proof of stake if you go to the agenda and scroll to the bottom the last comment outlines vitalik alex van descend and niks comments on that so the talaq since you brought up that and chat you can start with your ideas on it this was the issuance reduction yes exactly yeah so basically I'm you know the proposal that I had was to do a one-time

cut down of the of the issuance and target the target the amounts basically so that the amount of issuance per second after metropolis roughly equals the amount of issuance per second right before metropolis so in practice if let's say the block time is something like 25 seconds when we do the switch then the drop would be from five years or to something like three ether and [Music] these idea here basically is that I mean first first of all I think it's have having levels of levels of issuance that are

higher than current levels is from security from a security standpoint we not necessary and I would I would say it's even an especially given recent price levels it's probably quite equate excessive and wasteful um from a point of view from a more kind of political point of view you could our onion you could argue that pushing the pushing the block reward up to five yeah and pushing the ants keeping the block reward for a second constant are both kind of maintaining the status quo policies and if as far as out of out of those two of the lower the lower one seems more

prudent I and also a in the in the longer term this would probably ends up being like being the first decrease of several where the next decrease after this would be whenever we end up by switching over to hybrid of stake and then the third decrease would end up happening when we go from hybrid proofs take based to a foolproof snake though obviously the details behind the letter two are still in progress okay great and then we'll just go with I guess Nick next what was your comment I didn't know I was going to be asked for coming no

sorry I was like you so you said on the on a get her that my own opinion has evolved I'm terribly in favor because it's a step okay actually yeah never mind actually you didn't have that yeah you didn't have the long common Alex that Alex did you want to comment on your stuff freezing whatever I think it's of course we don't have any any target goes on Casper right below that we don't know

how much right but I think that would have a lot okay so it sounds like it's about setting expectations and then helping it not be - right now it's just it's - it's not helping security with how high it is it's to the point where it could be lower and still be fine so what would this go into metropolis Vitalik or would this be after yes so this would basically be simultaneous with the difficulty bomb delay okay so in that case there might need to be and let me look real quick I think hunter island or whatever has a new there I think either said there needs to

be a new AIP oh I see okay nevermind he just put a different thing about the difficulty bomb diffusion so yeah if we could have we could either use the CIP or write a new one I think this one was based on different assumptions and some figures from last December so I might ask him or anyone else in this channel who wants to to do another one based on metallic suggestions or vitalik if you want to pick that up it's up to you start braiding each of Price crashes - let's say so I would say that at

current levels but basically intuitively speaking right the probability that so like my kind of instinctive opinion right now is that the three ether per vlogger rate should be safe with either prices anywhere above maybe the twenty to fifty dollar range now the five ether rate in that case is logically speaking going to be safe at anywhere from these twelve to a thirty dollar rate and I would argue that if ether crashes crashes hard then it's probably going to crash really hard and so the probability if we see that kind of hard crash the probability it'll land in exactly that's silver where the three ether rate is not safe but the five

ether level is safe is seems fairly low okay thank you okay so you have italic did you want to write that up or do you want me to just get hunter island to read to revise his yeah just like I mean look the EIP ax here is basically very simple right it's just like a one-time thing that says if the block number is greater than or equal to the metropolis for walk number then replace the block basically multiply all block reward related parameters including beef base block reward nephew reward and Uncle reward by a factor of X where in this case X does a 3 over 5 hello oh there's nothing yeah there's nothing behind the

scenes it's just literally just changing it okay no problem I mean what's the only tricky thing is just to make sure that we change like all the constants including the uncle and nephew stuff okay sounds good so the last thing Nick wanted to bring up the IP 658 which was involving embedding transaction returned data and receipts I'll put that in chat and get her but Nick you can go sure so the basic sort is that up until metropolis it's been possible to knows the feeling you know stare surance if your transaction failed or not based on the guess which in which people rely on I think quite heavily with the

introduction the revert opcode that's no longer the case and with current api's have be very difficult for people to determine if their transactions exceed or not it's possible for a full node to really execute the transaction and tell you what its return code is but that's not possible for fast notes think you know from before their cover point and it's not possible for light nodes so the speed proposes adding either the returned data itself and the status code to the receipt in place of the intermediate states which we were already deleting or adding a set value to the stage sorry to the receipt yeah so I think the only people who've

commented on that recently have been Peter and Casey and so Nick Casey's in case you might be able to say this better but I think he was talking about how this might mess up like client stuff Casey what was that one about oh no I was saying that in principle it's possible to janu transaction even like clients can you transaction traces yes that's true however it would be a very intensive like did the upper bound on that is very high for a light client this term so transit a transaction could affect a contract with a lot of stake and do a lot of operations sure yeah so

this is that in order for a lifetime to figure out that the transaction that reverted what happened there is the only the only way is to actually trace it out of that transaction consume four million gas and touch everything then the lifetime would actually need to download a lot of stuff yeah so so what I've what I'm curious the feedback on is first is this a good idea or is there a better option and secondly if it is a good idea should we store the actual return data in the receive field or store a hash of that briefly storing the actual turn data as simplest in terms of accessing it but storing a hash has the advantage of the length of the field not changing

and the - type not changing but the disadvantage that you can have yet another thing you need to sync and you have to add a new message type to the the wire protocol mr. Fitch return data I personally prefer if only the hash would be stored and the reason is mostly because then the data structures don't have to change because so if we were to store the entire error message then that means somebody might insert an arbitrarily long error message to work we need extra pricing problems so I agree that that we need to consider pricing I'm not sure it's a problem because they already had

to pay for the memory in order to return the data and I'm not sure that reading it out of the receipt solves the problem because it still so it is worth noting that in the context of the logs we do charge eight gasps per byte of just data that gets put into a log could we get away I mean it would it will increase the scope of this change but could we get away with charging a by eight gasp per byte of data in return data that sounds like good so that would have to be done in the top level call only and that seems like a weird change yes so the the corner case that you want to

solve is no speaking after the transaction failed or not do you really want those to explicitly know why it failed or are we happy with so in my mind the main purpose is knowing it failed but if we're going to fix this it seems to me to make sense to fix what I at least see as an omission of not being able to get return data from top illegal transactions okay um I I haven't been able to look into this enough Nick is this related to EIP 98 for med state from receipts there's this a different portion of it

it obsoletes 98 by using their fields or something else okay hmm interesting okay yeah we can talk about this more on the EIP and then get her uh does anyone else have any other comments on it so just to highlight the problem imagine that you issue a tract so currently you create a transaction with two hundred thousand gasps and then you look at the receipt and you see that hundred thousand gas was consumed and then you know that it failed and then you might want to trace it or whatever the issue is that if with the introduction of the rebirth of code let's say that two hundred thousand gas consumes only fifty and then you have absolutely no clue whether it was

successful or not basically you cannot doubt whether it was successful or okay any other comments okay great and then I did say we would go back to e ip3 um so I'm wondering why the revert of cold doesn't consume more remaining gas maybe it's just easier to make river top coal consumed or gas there I think it's extremely valuable to have a way to like

make transactions fail or make internal calls fail and return data without burning a huge amount of extra gas so one very simple example is that if you look at a lot of recent icos the majority of transactions end up coming in like after the ico hits the capper after it expires and so they fail and because of this these transactions often ends up consuming like two hundred thousand gas and when in reality they could have gotten away with consuming like half of that or possibly even lower but possibly it's something like thirty thousand so I could see at the revert opcode actually like decreasing the effects that ICO specifically having network congestion but more than a factor of two I would I would I would

make one comment here is that's a virtual shouldn't in my opinion revert shouldn't like so if you've used up like ten thousand gas and then we call roburt the cost should not be ten thousand gas because you are doing like there's a there's a bit of an extra cost to actually reverting the state so it should be like 1.5 X 2 to X maximum you know or up to the gas limit on the amount gas you start that far so far I say I mean go ahead oh that's not something we impose at the moment you can revert when you've only got a loss rate you can fail when you've only got one guess left and it may actually be cheaper because although you have to rewind things in memory it's stuff that

you don't have to write such as you know like basically in all major Op relations well all you've all you're doing is you're basically just going back through the journal you're going walking backwards through the journal and you're doing a single memory operation for every single storage operation that you did going forward so the ratio between memory and storage tends to be very high so I don't think like these extra expense you're incurring is particularly high yeah fair enough I guess I guess if you run out of gas that's a reverb as well so one thing we learned during the these US taxes that the costs for reverting is already priced in into the the actual operations

so if you do not revert you kind of pay a lot pay a bit more gas than if you would revert okay let's see all right I think that's all the agenda items was there any other comments on that EIP good to get get that decide decided

pretty quickly now if we want what do I use to receipt it to for and if I can reuse it as Nick has proposed so all inputs please can anybody hear me yeah RJ what's up yeah I was just um I had a thought on it do we want to go ahead and encode this into the API at all like an error type at all and make this kind of standard well with the revert that is you do you mean encode to format the prevent data should take yes

I think that's something that should be left up to ERC's and their contract legal standardization yeah I'm sure some of it will end up implementing some kind of at least de facto standard throw that it supports of I refer my questions actually I also have a question if pretty word every word wouldn't return any error message but there was some way to get way to get on the interface the the the exact revert which which ended up reverting

wouldn't a annotation just similar to the to the next pack or actually part of Matt's back would do the job so isn't the point of returning something just to to identify the error so having it free text error message I think is a huge overkill and I agree with Peter that the hash might be enough but even the hash might be too much so just some way to identify which of the three words got executed I think it's helpful to look at it the same way you would an exception and an LP programming language that may

contain our battery information about the reason for the call fails and I don't expect that it will be a Texas train normally but if that information would never actually be processed by a contract if it only needs to be displayed to a human that doesn't belong to any rotation rather than you know EVM code second so if that if what revert returns as a free foreign text would never actually be

will never actually be processed by by a contract by another contract it's only purpose is to be displayed to human rather than no why do you say we'd never be processed by another contract well because you don't want contracts per sync general messages no no again it's not an error message it is the return data in case of the reverb the same way they returned data from materials return data so if you throw an exception then it would contain the binary encoding

settings actions fields I see I am wondering whether like a third option for each member was it again the one I just proposed 6:58 would be to simply use the midstate field as a return code zero or one and a net return data I'm loathe to do that personally because I think it's it would be very useful for people to be able to

access returned data from a transaction but that is more a nice-to-have than essential effects so if it turns out to be impractical to to embed the written data directly or to add new RPC calls that could be a simplest of all worlds approach so just a short comment for me I think it would be very valuable to have the return data both in success and failure case for yeah transactions available do you have any opinion Christian on whether it should be included in plain

text in the receipt or as a hash I don't think that I mean I don't think a hash would be quite useful I mean I would say we should see in the same way as events are used right I mean they can also include playing data I guess the difference is we don't explicitly charge for return data or universe touring return data because we don't presently we recharge for the memory expansion

required to return it only so but that that can be changed on for a top-level transaction carpet it can't be but it is vitally wanted out that's an odd exception to make in terms of gas costs so personally I would be in favor of

reducing their seat fee for a hash in Metropolis and if we're gonna reuse the receipt for actual plaintext data I think it should be postponed to the for Captain propolis if we were gonna do that and I would suggest using it just for Oh to impound emanating returned data is a new field of message host metropolis because it's a hash then you pretty much have to add the and get return data and returned as a wire legal protocol options even just two hours into and whether it succeeded or not if you say so if success means that your

return code is zero and no data is returned with it and you could always check whether it's a theater field just you have it unfortunately there are a lot of existing contracts that get called externally that returned out although my Allen this is another question whether we want that they think it to be available and accessible or not but I mean even if you don't care about making it available you won't be able to tell if it succeeded or failed if the Heche includes they've returned asthma because you can't rely on just two million I am at my point was that who don't include that data in that it was successful but isn't that what I just suggested well I suggested that if

we were going to talk about adding returned data field later than in the meantime we should only get the status code not the hash to return data if we add the hair should return to anything you have to be you have to where they get returned data why protocol call in order to be able to tell even if it succeeded well I mean you enroll can be too bad missing you that nothing or both zeros if it succeeded whatever special absolute and the crab and then you could add the network on to be actually figure out the failure that seems I know it seems like a non special case to not return the hash of the

returned as result succeeds but return the national another reason fails yeah well I guess it's for me it's I don't really care that much about that does that if we return everything if we return the hash of the return dating us on a successful faulty then we really do need that extra Network packet yes I agree so I think but Madden was suggesting that we could return hashes now and claim data later but I would say as if we're planning to airplane two hours later as an extra field then we

should just return status code only now and not other words edges at all I mean maybe even we could add planed a tourism technology field now I don't know how much that would add to the complexity so in that case intermediate state will be repurposed just return code and then a new field with the years into the endless gen data okay but then the size of the intermediate hash would go down from 32 bytes to essentially 1 by yes but you could still do a massless into the same

type of you I don't miss that I guess this is an implantation video but at least in the etherium if the field size is validated and arathi decoding so if you were to say that the our opt-in size should be one byte exactly but we allow unmarshal anything to 32 bytes and I can see something's going wrong okay I mean we could specify 32 parts of zeros but it seems wasteful well yeah my guess if we're so if we consider adding the

second of the domain data then we can we can add the boolean field just dropped the intermediate hash as in droppers entirely or just his father B and say two zeros because I don't think we would have with 86 by then was 96 998 I don't think we would have filled it with zeros would be so we would have already encountered the sushi well so that my only point is that if we're going to modifications on the structure any way that we can do arbitrarily invasive modifications because it doesn't matter but I I'm trying to compare to what

right what the default is which is 98 I don't like either of the proposals of 98 called fulfilling when it states that if you died 4 zeros so it all you would have had to make changes regardless oh yeah that's right I know I give the proposal implemented in GUI theorem is to drop the field I'm thinking okay that's also a structural change that's it okay so does that mean people are in favor of just changing the receipt to drop that field and add two new ones that seems like I'd still personally

prefer to find some way to not make structural changes but look let's limit make points out it is already a structural change yeah with the doll foundry pictures well I mean unless we unleash we use that exact same 32 bytes in specifically in some way or of course no either - yeah yeah or like the slightly more structure changing but not to structure hng a thing to do would be to replace it would be to replace it

with some other number of bytes like 33 33 bytes if we want to buy a bit in a hash or if we still want the variable size thing just like make it a byte array so if you're going to change it from a fixed into byte or anything else and that's a structural change it doesn't matter them how much it changes yes but it's a yeah but like it's a specific kind of structural change that's easier to implement because it's like it's backwards compatible in the sense that it goes from being a 32 byte array to being a general byte array and 32 byte arrays byte arrays are a subset of general byte arrays hmm fair enough but if you have a strictly typed

language then you are changing from a hash to something much more relaxed right size okay I think that wraps up that was there any other comments Nick or can we bring that to the EIP I think we should take it offline I'll take it home see yeah yeah yeah if you could do any comments on your VIP or 98 that either summarize or if do any conclusions that partial conclusions we've come to that be excellent okay so that's pretty much it I don't there anything else anyone

wants to say or anything to bring up all right so before we go focus on a IP 86 let's try to get that wrapped up because that'll help with testing and making sure that we can get a deadline set for metropolis go ahead and look at Nick's proposal and also a TI p 186 that one's less controversial 186 as far as metallics formula he proposed and then finally if you haven't purchased DEFCON three tickets go do that and yeah just like reach out if you need to know the website or anything like that but go ahead and get them before they're gone all right thanks everybody see you in two weeks